***Tunning suggestions***
Database recommendations:
1- You can find a section of "Database Tuning" over the Stat 6.3.0 Sys Admin Guide on page 222.
2- Make your DBA take a look at the "STTEMP" tablespace for STAT repository to make sure enough space and resources are allocated to this tablespace.
*Make sure that the NextExtent properties have a minimum of 256k (1 or 2 MB is better). Also, check every tablespace about the spacing issues. Possible out of disk space or related.
3- Check for Invalid views in the Stat database schema, if any invalid views are found, compile them.
4- Restart your Stat Database.
5- Open a command line window on one of the PC's experiencing this issue then run a tracert command to Stat DB host. Look for the number of hops.
*Note: Most of our customers have latency values of less than 200ms. Please, pay attention if you have more than this value in each hop.
6. Purging old CSRs might also help. In this case, follow the next kb article: https://support.quest.com/stat/kb/124060/purge-old-csr
7. You can also try by running the following Stat maintenance jobs:
Purge Audit Tables
Purge Deleted Archive Sets
Purge Error Log Tables
Purge Migration Event Tables
*If you want to know how to define them and have a brief functionality description for each one of them, please look into the Stat 6.3.0 System Administration Guide, page 165, topic "Defining Agent Jobs".
Is your environment also slow when migrating? If so:
1- Archiving and migrations are performed by Stat central agent. Have there been any changes on the Stat agent machine or networking, firewalls, etc? Make sure there is enough space in the file systems on the Stat agent host especially in the file system for STAT_HOME.
Is your environment also slow when saving CSRs? If so:
1- Please check the following kb: https://support.quest.com/kb/68882
Here are a few comments about the performance tuning:
- The more memory and disk space the CA has, the better the performance will be.
- Also consider the network. How far is the SCA from the stat DB and ebiz DBs?
The more hops it’s has to go through, then most likely it will take longer to process archive sets, migration, jobs and etc. To have better performance, we would suggest the SCA be closer to the stat DB and ebiz DBs.
- Do not have agents in debug mode for a long period of time unless support advised doing so for troubleshooting purposes.
- Try to clear out the server.log every other week. We only need to keep the current log for troubleshooting purposes. If there is no problem, then you could delete them and maybe just keep 1-2 day logs.