Database time or database request time is the time that R/3 considers necessary to access the oracle database.
The database time plays a role at the following points:
The statistical records from STAD (formerly: STAT) and ST03N (formerly ST03) contain the database time as a component.
The ABAP trace from ATRA or SE30 displays the database time in comparison to the ABAP time.
In transaction SM50 or SM66, if you see work processes accessing the database (for example, “sequential read” or “update”), the database time is running for these processes.
Only standard SQL commands, such as INSERT, UPDATE, DELETE or SELECT are included in the database time. DDL commands, such as DROP, CREATE or TRUNCATE are ignored. Instead, their times are part of the processing time in STAD or ST03N. The same applies to COMMIT and ROLLBACK that are also not considered part of the database time. As part of the statistical records (transaction STAD), at least the “Commit Time” is displayed, so that you can determine the significance of COMMITs for individual transactions.
The assumption that the database time determined in R/3 is the time that is spent in the Oracle database is incorrect. In many cases, the Oracle database is the crucial factor for which time is consumed but there are also other situations in which much more than half the database time is lost outside of the Oracle server.
It is therefore important to understand which components contribute to the database time:
Oracle client: SAP calls functions of the Oracle client software, through which a connection and communication is created with the Oracle server. The time spent by the Oracle client is part of the database time.
Network: Even the network between SAP and Oracle is included in the database time. This also includes the local communication overhead if SAP and Oracle run on one machine.
Oracle server: Finally, the time spent by the database server is also part of the database time.
You can only determine the exact details of how the database time is made up if you monitor the transaction concerned at runtime. Afterwards, you can still only make very limited assertions. In general, the following procedure is available:
In the first step, determine whether the database server is responsible for the majority of the database time by carrying out a wait event and CPU analysis. Generally, the database server is responsible for the majority of the database time, meaning that you can carry out an optimization in accordance with SAP Note 619188.
If the time consumed on the database server is significantly lower than the database time logged in R/3, the other components of the database time (Network, Oracle client) must be analyzed in more detail. This is a substantial task, you can refer SAP Note 1100926 for this.
Resource bottlenecks (CPU, memory) may also cause delays. Therefore, check whether there is a CPU or memory bottleneck on the application server.
Increased times in the Oracle client can be consumed if a very high number of SQL statements have to be executed. This is the case, for example, if a large number of FOR ALL ENTRIES statements are executed with long value lists and small values for rsdb/max_blocking_factor or rsdb/max_in_blocking_factor. Under these constraints, you can carry out a test increase of the blocking factors, of up to 100, for example (see, for example, SAP Note 556764).
In some cases, it is useful to analyze the CPU consumption of the R/3 work process. To do this, you can use the CPU button in transaction SM50 or SM66. When you run the transaction concerned, compare the degree to which the CPU time in transaction SM50/SM66 increases in relation to real time. The proportion of time during which CPU is consumed cannot be lost in the network.
— The fact that the total of the times in STAD is greater than the response time is also evidence of increased client activities. This constellation is triggered by the CPU time of the Oracle client being assigned simultaneously to the database time and the CPU time.
— An Oracle client trace in accordance with SAP Note 562403 may help to analyze Oracle client activities.
You can use operating system dependent tools such as TRUSS, TUSC or STRACE to create operating system call traces which contain information about time consumption within operating system calls. For further details, contact your operating system partner.
— You can use the SIGUSR1 and SIGUSR2 signals, or the command line tool sapstack, to take a current stack trace of the R/3 work process (SAP Note 659856). If you take several inspection samples, you can largely identify in which routine the process spends most time.
— The average database time is affected by many factors that are irrelevant to the efficient running of the core business processes. Up until SAP Kernel 6.20, for example, a large number of internal ADM messages may be included when the average database time is calculated, which significantly lowers the average. As of 6.40, this effect no longer exists, which is why the database time apparently increases. In reality, however, the database performance of the business transactions has not changed at all.
In this respect, the average database time should not be defined as a key performance indicator (KPI). Instead, you should examine the individual database times for the most important transactions of the business process.