Low hit rate for table scans: <percentage>%, <number of> scans, >number of> rows read, >number of> rows qualified

During tablescans, there is a poor ratio of read lines to found (qualified) lines. In almost all cases, this means the search strategy is poor. This can be caused by the application (missing or insufficient indexes, and so on) or by a problem during the cost-based SELECT optimization in the database kernel. Scanning large tables can considerably reduce the performance of the entire system due to a number of negative affects (I/O, overwriting the data cache, CPU load, and so on).

First, rebuild the internal database statistics to determine if the database optimizer can find a better search strategy and therefore avoid tablescans. You can use CONTROL to update statistics, or use the UPDCOL tool from an operating system command line. As large amounts of data may need to be checked, these statements may run for a long time and should therefore not be started during active applications, if possible, which will also help to avoid any lock conflicts. (stopsap r3 - Update Statistics - startsap r3).

If this is not successful, check the statement that triggered the tablescan. You can do this by starting the diagnostic monitor or an R/3 SQL trace, and then checking for any long-running statements where the EXPLAIN statement is used to check the search strategy used by the optimizer.