14.3. Tuning the Disk Subsystem, Database, and SAP Application Layers

At the end of the day, a well-tuned application running on a properly configured database can mask a multitude of hardware and OS shortcomings. But the opposite is true as well—oversizing a system is a common way of addressing unknown capacity-planning issues or dealing with unclear peak demands. Oversizing is by no means cheap, either, as the term implies. I therefore submit that tuning is best accomplished by working consistently up the SAP Technology Stack, from infrastructure to hardware, OS, database, and then application and integration layers. I typically use major and minor test iterations to stay both focused and on track. In other words, once I get the infrastructure squared away, I test and tune before moving on to the next layer in the stack, using tools and utilities discussed in Chapters 6 and 7. The same approach holds true for all layers, especially with respect to hardware (where misconfiguration can severely dampen your tuning efforts elsewhere). Once the hardware and OS layers are optimized, I then turn my attention to the database layer, testing and tuning the layout of data files and tables, logs, temp/sort space, and more.

Next, I review and test configuration changes to SAP itself, being careful to never circumvent SAP if my tuning efforts force me to make changes that impact the underlying database. That is, I never make changes to the database outside the control of SAP, because these changes can not be tracked or validated by SAP, increasing the risk of error and misconfiguration along the way. What this means is that all database-relevant SAP system tuning is done from the SAP application layer—changes I might make in terms of creating or deleting indexes are a good example. Also, any changes made to buffering database tables must be done through SAP as well.