Chandra,
Below are the responses I was able to get to your questions:
YOUR QUESTION: Can you advise on archiving the TDSTATS database ,statsmanager user setup. I read the manual and it says above two are not part of dictionary backup and we need to add in our archive process in case any disaster recovery for restore and resync stats. Can we do weekly archive?
Viewpoint does not provide for archiving of metadata such as Stats Manager job definitions. If the job is not needed anymore, it can be deleted through the portlet. Viewpoint will remove any collected data related to stats (which includes job history and analyze, automate, cleanup, and collect reports) according to the data retention policy set for the Stats Manager collector. You can view this setting in the admin Monitored Systems portlet.
YOUR QUESTION: For the clean up log tables from TDSTATS , what will be the best practice to setup.
RESPONSE: Periodic clean up of TDStats historical metadata can be enabled via Viewpoint and the suggested practice is to start with the default setting of purging results older than 30 days. See chapter 18 Managing Space for TDStats in the Automated Statistics Management Orange Book for more info.
YOUR QUESTION: From the portlet , we can find duration from the jobs history view. Is there any API can provide the total duration of the specific job. TDSTATS.CommandsHistoryTbl and tdstats.SelectStatsExecutionHistory gives by tables wise. I am looking to find total duration of the jobs from any API / any table from tdstats repository.
RESPONSE: Stats Manager defined Collect Job names are not explicitly stored in the TDStats repository which instead uses "RunIDs" to uniquely identify the execution of the RunCollect API on behalf of a given Viewpoint job run. However, when defining Command Lists for a particular Collect Job, Stats Manager embeds the job name in the list name which in turn is stored in TDStats column CommandsListTbl.CmdListName. The value stored in this column can be used to filter rows in CommandsHistoryTbl for given job or to call API SelectStatsExecutionHistory. You are correct that TDStats command history data (including start and end collection times) is stored at the table level but you can aggregate on RunID to compute the total time for a run. Although the summed times from TDStats may not exactly match the separately tracked Viewpoint job time, they should be roughly the same.
For example, given a Stats Manager Collect Job named 'CollectTPCH', the following query would sum the collection times for each run:
SELECT RunID, SUM(TimeStamp_Diff_Seconds(C.StartTimeStamp,C.EndTimeStamp)) AS TotalRunTimeInSecs
FROM TDStats.CommandsHistoryTbl C, TDStats.CommandsListTbl L
WHERE C.CmdListID = L.CmdListID AND
L.CmdListName = 'com.teradata.viewpoint.statsmgmt.CLFCollectJob-CollectTPCH'
GROUP BY RunID
ORDER BY RunID;
note: TimeStamp_Diff_Seconds is a UDF whose definition was posted by dnoeth on Teradata Forums
Thanks, -Carrie
Chandra,
Below are the responses I was able to get to your questions:
YOUR QUESTION: Can you advise on archiving the TDSTATS database ,statsmanager user setup. I read the manual and it says above two are not part of dictionary backup and we need to add in our archive process in case any disaster recovery for restore and resync stats. Can we do weekly archive?
Viewpoint does not provide for archiving of metadata such as Stats Manager job definitions. If the job is not needed anymore, it can be deleted through the portlet. Viewpoint will remove any collected data related to stats (which includes job history and analyze, automate, cleanup, and collect reports) according to the data retention policy set for the Stats Manager collector. You can view this setting in the admin Monitored Systems portlet.
YOUR QUESTION: For the clean up log tables from TDSTATS , what will be the best practice to setup.
RESPONSE: Periodic clean up of TDStats historical metadata can be enabled via Viewpoint and the suggested practice is to start with the default setting of purging results older than 30 days. See chapter 18 Managing Space for TDStats in the Automated Statistics Management Orange Book for more info.
YOUR QUESTION: From the portlet , we can find duration from the jobs history view. Is there any API can provide the total duration of the specific job. TDSTATS.CommandsHistoryTbl and tdstats.SelectStatsExecutionHistory gives by tables wise. I am looking to find total duration of the jobs from any API / any table from tdstats repository.
RESPONSE: Stats Manager defined Collect Job names are not explicitly stored in the TDStats repository which instead uses "RunIDs" to uniquely identify the execution of the RunCollect API on behalf of a given Viewpoint job run. However, when defining Command Lists for a particular Collect Job, Stats Manager embeds the job name in the list name which in turn is stored in TDStats column CommandsListTbl.CmdListName. The value stored in this column can be used to filter rows in CommandsHistoryTbl for given job or to call API SelectStatsExecutionHistory. You are correct that TDStats command history data (including start and end collection times) is stored at the table level but you can aggregate on RunID to compute the total time for a run. Although the summed times from TDStats may not exactly match the separately tracked Viewpoint job time, they should be roughly the same.
For example, given a Stats Manager Collect Job named 'CollectTPCH', the following query would sum the collection times for each run:
SELECT RunID, SUM(TimeStamp_Diff_Seconds(C.StartTimeStamp,C.EndTimeStamp)) AS TotalRunTimeInSecs
FROM TDStats.CommandsHistoryTbl C, TDStats.CommandsListTbl L
WHERE C.CmdListID = L.CmdListID AND
L.CmdListName = 'com.teradata.viewpoint.statsmgmt.CLFCollectJob-CollectTPCH'
GROUP BY RunID
ORDER BY RunID;
note: TimeStamp_Diff_Seconds is a UDF whose definition was posted by dnoeth on Teradata Forums
Thanks, -Carrie