This content has been marked as final. Show 7 replies
My comments in this thread would also apply to 9.3.x versions: Re: DRM Web is very slow 220.127.116.11.0
If it has been getting a lot slower lately, you might want to explore whether regular database tuning has been done, i.e. are log files getting cleaned up and is the transaction history table getting cleaned up regularly.
Also, how frequently are the versions being finalized and copied? If you're keeping the same version active for more than a month or on the outside a quarter that can create problems that you won't be able to tune your way around.
We are using SQL Server for the database and rebuilt the index of the database everyday.
I will check whether there is a process to regularly clear the transaction history table and clean up the logs.
Apart from the above, is there really any specific database settings that we need to apply on
DRM database or a specific tuning exercise on the DRM application itself?
Every month, we copy current version to a "temp" version. Once the "temp" version
is updated with the latest hierarchy, we delete the current version and copy the "temp"
version to become the current version.
My knowledge of SQL Server is somewhat dated, but from memory we used to have jobs that periodically archived the data, dropped and recreated the tables, loaded the data, and the rebuilt the indices and constraints. DBAs told me that this was necessary in SQL Server to prevent the performance from degrading over time. This may not be required any longer but might be worth exploring.
If you're copying versions monthly and deleting old versions your transaction history should pretty much be self maintaining.
Once upon a time the transaction history for versions was kept even if the version was deleted, but for quite some time that hasn't been the case. When that table gets large it isn't unusual to see as many as five or six additional indices added to keep queries generated from the UI performing well for various combinations of selection criteria.
For Example you have cleared the transaction history table ( Deleting a Version) and you wish to check certain properties for it's previous value on a Node,
you can use STATS category to see when was it changed but that doesn't capture what was changed ( properties).
It's completely depend on your Business requirement to call clearing transaction history as a Best practice or not.
Edited by: Murali Pasumarti on Mar 12, 2013 11:11 AM