Top Ten TM ART Database Tuning tips. And one to grow on.
People love the down-home goodness of TM ART monitoring so much they keep adding monitors to it until it pops like a ripe watermelon at a Gallagher show.
And the performance bottleneck of TM ART is usually the TM ART database.
So here are the Top Ten TM ART database tuning tips.
1. Rebuild the SV_TimeSeriesData indexes. This is documented in the Admin Guide. This tip is the most important one. TM ART uses the SV_TimeSeriesData table a lot. It is usually 50 to 70 per cent of the size of the entire TM ART database and is written to constantly update with monitor results.
2. Give the database more virtual memory. This tip applies to most databases.
3. Do not share the database server computer. I know that in kindergarten you were taught to share but you gotta unlearn that. Do not run your payroll application on the same computer as the TM ART database.
4. Do not share the database server software. So do not have your account receivable database use the same database server as TM ART.
5. Do not share the database disk space. You do not want some unrelated backup to slow down TM ART.
6. Enable Persistent Result Data. Information regarding Persistent Result Data is in the TM ART Administration Guide starting on page 107 here: http://documents.bmc.com/supportu/documents/13/94/441394/441394.pdf
I first started telling customers to turn on this feature because it would prevent the loss of data if a TM ART hang happened. But then I noticed that when customers turned on this feature the TM ART hangs decreased or disappeared.
7. Use the new DataDelete instead of the old one. The new one is documented in the TM ART Getting Started Guide which is here: http://documents.bmc.com/supportu/documents/25/99/442599/442599.pdf
See Chapter 7, Data Deletion utilities.
The old way is documented in the Admin Guide starting on page 109 in the section named Reducing Repository Size and Stabilizing Performance on the Database Server.
8. To be on the safe side, Oracle DB SGA may need 6 - 8 GB of memory allocation.
9. Do not put the database on a VM. Yes, we all love VM's but since you do not want the database to share anything it is overhead for no good reason.
10. AppServer computer needs to be at least 6 gig. This is the OS Virtual Memory, not a database or Java parameter. Having only 2 or 4 gig of virtual memory on the computer where the AppServer runs causes performance problems.
11. Reduce unnecessary TrueLogs. TrueLogs are 100 or more times bigger than ordinary monitor results. Writing a lot of TrueLogs can slow down a database.
I’ve used the steps described here to help many customers get better performance out of TM ART by getting better performance out of its database. I hope this info helps you avoid issues. Please rate it below to give me feedback. To see more like it, see BMC Application Management Pulse Blogs Posts.