For SPECjAppServer2002, the baseline database configuration is easily obtainable by extracting configurations from existing publications. However, a good configuration for one system may not be optimal for others, due to hardware and software differences, dual-node or multi-node categories, and the use of disk arrays. For Oracle, statspack data can be collected. It is usually not easy to understand the statspack data, and having it reviewed by experts is a good idea. For SQL Server, not only can the performance data be made available through PERFMON, but it is also relatively easy to understand. The basic idea is to reduce disk access as much as possible by watching counters such as Buffer Manager\Buffer cache hit ratio and Memory Manager\Total Server Memory (KB).

A common way for database systems to reduce the impact of I/O is to reduce it (through the use of memory) and to make it fast (through the use of multiple disks in a RAID array system). Not adequately optimizing for the use of memory can result in a performance penalty of orders of magnitude. Once that is done and a high hit ratio is obtained (e.g., >99% for SPECjAppServer2002), further performance gains due to the use of RAW partitions on disk arrays was found to be about 10%. Another 10% SQL server capacity can be obtained by making a few changes such as setting the following values:

• sp_configure lightweight, 1
• sp_configure recovery, 32767

Our focus here is to remove the database system as bottleneck and thus affect the tuning of the application-server performance. Therefore, once a reasonable database configuration has been found, further tuning on the database system may result in low return on investment.