RT table Cleanup

[Bhavpreet_Bains_7888]

Hello,

We recently noticed that the RT table has grown very large. We already have DB maintenance setup on automic for reports to be deleted that are more than 90 days old. 

However, when we pulled in the rt database by using query select * from uc4.rt, there were entries with RT_TimeStamp of April, 2016.
All the entries that has the RT_TIMESTAMP filled has 
RT_Type: ACT,  RT_CONTENT: null and has some data in RT_MSGINSERT.
The rest of entries has
RT_Type: Log, RT_TIMESTAMP: null,  RT_CONTENT: has some data and RT_MSGINSERT: null

Also, in the unload jobs of DB maintenance, there are only a few entries (2-5) for deletion for RT table.

I am not sure if I am doing something wrong because of which it's not deleting the entries from RT table during unload of DB maintenance. Also, I want to understand why the log entries in database doesn't have the timestamp and old act files are still there.

Thank you.

[Anon Anon]

That depends basically on your DB.REORG Settings.

For example here are my settings:
keep 14 days and at least 10 Versions

If you have a job that runs just once a year you will have reports back to (2007) - theoretically - i know....
because you defined AT LEAST 10 versions to keep

if a job runs 24 times a day you will have 336 reports to keep (24 x 14days)

- same with your DB.Archive settings (if you perform archiving before reorg)

there are some stumbling blocks when settin gup REORG Processes in Automic - there are some hints in documentation and xome Technical articeles in support portal.

if REORG process is set up ok its possibly this:

https://automic.force.com/support/apex/CommunityArticleDetail?id=kA4b00000004TBxCAM

BTW - it could be helpful having a look at the RH table (Report Header)

[KesavanElangovan]

We are in a similar spot. 

Does the data in RT table gets unloaded as part of the DB Maintenance? this table for us has been growing through out and the earliest date we have record is at the time of system install, more than 18 months. 

 

All the DB Unload job logs indicates only deleting rows from tables MELD, RH, AH and OH. 

 

How do we unload data from RT table? Can UC_UTILITY_REORG be updated? 

[Alain Moisy]

Check also the value set for the no_archive_check parameter in the ini file of the ucybdbre and ucybdbun utilities. This may exclude records that have not been archived. If you do not run the archive utility, ucybdbar, no record is flagged as "archived". And with the setting no_archive_check=0, records will also not be flagged for suppression, or suppressed even if the deletion flag is set !

[KesavanElangovan]

Thanks Alain, This morning I updated the no_archive_check=1 on both ucybdbre.ini and ucybdbun.ini and ran the JOBP.AE.MAINTENANCE

 

However results of running the maintenance job with the default configuration didn’t yield the result we were expecting(unload data older than 60 days) for AH, RH and RT tables.  It seems like the REORG job does not flag the older records to be deleted except for MELD table.

 

Jobs are running with default configuration of 30 and 60 days – any data earlier than those dates should be unloaded, however the earliest data in RH, RT and AH is from june of 2017(time of our environment install). 

[Alain Moisy]

Hi,

In the UC_UTILITY_REORG variable in each client are you setting the parameters like follow :

 

AH  =>  TRUE 0030 TRUE 0006

RH  =>  TRUE 0030 TRUE 0006

MELD  =>  TRUE 0030 0030

VERSION_CONTROL  =>  TRUE 0030 TRUE 0005

OBJECT_AUDIT  =>  TRUE 0030 TRUE

 

AH/RH  =>  keep 30 days AND 6 versions of any statistics and reports

MELD =>  keep read and unread messages for 30 days

VERSION_CONTROL  =>  keep old version of objects for 30 days AND 5 versions at least

OBJECT_AUDIT  =>  keep audit records for 30 days and remove them ONLY if extratced and saved in csv file

 

If you have such setting and some jobs are running only once a year, there are records in AH/RH that can be from the las 6 executions so up to 6 years back !

 

Note :

 

There is a parameter auto_reorg in the ini file of ucybdbre and ucybdbun that is set by default to 365 to remove forcfully all records older than 365 days. You can change it if you do not want to loose records olde than 365 days to the max value you want.

 

Note 2 :

 

If you have obsolete definitions that runs last time a year ago i.e., the AH/RH associated records will stay in the DB as long as the definition is existing. That's why it is recommended to export/unload obsolete definitions as backup (you never know who is going to ask you to run them again =-) ) and remove them from the clients to cleanup the associated statistics and reports ..... Could be also interesting to generate the report or list of the available statistics of those objects for historical recording in that case (all start/end time, status, etc ....).

 

Sorry to be long but seems that you have some issues in some of the settings maybe if only MELD is cleared.

[Alain Moisy]

FYI for one RH records there is one or more RT records as RH is for Report Header (main information about the report generated)  and RT is for Report Table (details of the report, in one or more 8K records usually)