Note that these buffer quality values are only guidelines. In some cases, a database instance can still run well with apparently low buffer quality. Therefore, to avoid unnecessary investment of time and energy in optimizing the buffer quality, check t he database response times using t he workload analysis.
->Keep your database engine running! The database is the heart (engine) of your SAP system. If the database instance does not respond, the entire SAP system will soon stop responding. Regularly monitor the fill level of the database log area (for example, the redo log files for Oracle, the online log files for DB2 for LUW, or the transaction log for SQL Server) or the file system .
->Ensure that the database server has sufficient CPU and storage capacity. More than 20% of the CPU should be idle, and the paging rate should be low .
->If your database system has a profile parameter that limits the maximum number of physical processors that the database instance can occupy, ensure that this parameter's setting is neither too small nor too large .
->Ensure that individual hard disks are not showing more than 50% utilization.
->Check that the configuration and performance of the database buffers are adequate, as previously outlined .
->IdentifY any SQL statements that put a heavy load on the database server. An extremely expensive SQL statement is one that takes up more than 5% of the entire database load in the shared SQL area (measured in reads or gets).
->Do lock situations (exclusive lock waits) occur frequently?
->Ensure that update statistics for the cost-based optimizer are updated frequently, regularly check the consistency of the database, and look for missing indexes.