AFAIK there are no "official" standard scripts (but when you ask your Teradata PS they can probably provide you with some).
The process is similar to DBQL when you want to keep a history:
move the data to a temp table/delete the old/merge it into the history table
The history table are usually clones of the dbc tables with lots of COMPRESS and might get a better PI and PARTITION BY date.
During the merge you might do some some cleanup/rollup to reduce the datasize.
Especially in TD14 the dbc.EventLog (session history = dbc.LogonOff) will grow very fast and should be maintained, too.
Other tables which are usually not historized, just "delete rows older than x" are sw_event_log and the rc* tables.
And i prefer not to keep lots of days in dbc because when you got a system with SSDs/Virtual Storage all dbc tables are considered hot (and old DBQL/ResUsage is defintely not hot).
In best case you move all the rows to temp: FastPath delete without Transient Journal -> much faster (but historization scripts might be a bit more complex). Of course you need to create a UNION ALL view which covers both, dbc + hist.
AFAIK there are no "official" standard scripts (but when you ask your Teradata PS they can probably provide you with some).
The process is similar to DBQL when you want to keep a history:
move the data to a temp table/delete the old/merge it into the history table
The history table are usually clones of the dbc tables with lots of COMPRESS and might get a better PI and PARTITION BY date.
During the merge you might do some some cleanup/rollup to reduce the datasize.
Especially in TD14 the dbc.EventLog (session history = dbc.LogonOff) will grow very fast and should be maintained, too.
Other tables which are usually not historized, just "delete rows older than x" are sw_event_log and the rc* tables.
And i prefer not to keep lots of days in dbc because when you got a system with SSDs/Virtual Storage all dbc tables are considered hot (and old DBQL/ResUsage is defintely not hot).
In best case you move all the rows to temp: FastPath delete without Transient Journal -> much faster (but historization scripts might be a bit more complex). Of course you need to create a UNION ALL view which covers both, dbc + hist.
Dieter