Archiving Strategy for Request Center
Our RC tablespace is now over 8 gig and we're interested in any archiving strategies that may exist. Performance is not an issue, but when it come time to upgrade it makes for an extended process. Also how is this done without impacting the DATAMART content.
newScale is introducing incremental ETL for the datamart with the 2008 release (later this year).
Emir is right that you can then reduce the size of your RC (transactional) database while still retrieving some historical information from the datamart. This functionality will be available after upgrade to 2008.
To answer your DataMart question: nS has started doing Deltas nowadays (not sure since which version) so you would have to upgrade to that before you can do archiving ...
I was just going to post about this actually... I'm interested in everyone's archiving of the RequestCenter database (not Datamart). Our database, with attachments, is pretty large, well over 20 Gb.
We're moving to a custom attachment solution which will slow the rate of growth down significantly, but I'm interested in how people are archiving or managing their Databases:
- Do you use the purge script and erase old reqs?
- Do you delete ServiceLink messages after a certain age?
Is any of the 8 gig ServiceLink messages? NCC has two scripts that will delete ServiceLink messages for tasks that have been completed more than 14 days ago. Have you checked the size of the XtrMessage table?
We submitted an enhancement request years ago for a archiving feature...still have not seen anything on the roadmap as of yet. Our DB is 35GB+
Yep, ours just passed 40 Gb when I checked more recently! Some kind of formal 'product-ised' archiving feature would be awesome.
There are 2, and soon to be 3, methods available for reducing the size of your DB:
Requisition Purge Utility
This utility is freely available to all customers starting with newScale 2008.1. The same utility applies to 2008.2, 2008.3 and 9.1. The documentation and utility are provided with the software.
ServiceLink Purge Utility
This utility is freely available to all customers starting with 2008.1. The same utility applies to 2008.2, 2008.3 and
Thanks for the info, the BEEE clean up looks good also; are there any estimates on the kind of space recovered using that process? We're looking forward to it.
With regards to a more formal Archiving process, should we submit an enhancement request for this? To submit one, do we need to propose a strategy/feature or is it something we can leave up to Product Management?
Regarding the BEEE cleanup, our development team has tested it on seveal customer DBs and provided me with the following:
Large Customer DB
Original Size: 170GB
After ServiceLink cleanup: 128GB
After BEEE cleanup: 96GB
The BEEE cleanup will result anywhere between 15% to 40% disk space reduction, depending on workflow complexity and the ratio between open and closed requisitions (the more requisitions that are closed, the more data will be removed).<