Oracle DB Time is an important indicator of the performance analysis of the Oracle database in the time dimension, by gradually break down the index, navigate to the Top Event waste of resources or resource contention, so by reducing waiting, and minimize the use of resources per request to achieve the purpose of optimization. This paper describes Oracle DB Time, and gives examples demonstrate Oracle DB Time.
A, Oracle DB Time
is apparent from the figure:
DB Time (Request Time) = DB Wait Time (DB wait time) + DB CPU Time (DB CPU service time)
The above equation does not include the time waiting for the right DB background process on time and CPU overhead foreground process non-idle time.
Optimization is not just to reduce the waiting. It is intended to improve end-user response time per request or minimized average resource use. Sometimes these need to be adjusted together, but in other cases, there are trade-offs. For example, using the parallel query, parallel query or parallel DML is more use of system resources to achieve rapid completion of the transaction or the completion of inquiries and other related businesses. In general, you can adjust the way is to reduce or avoid prolonged occupation or excessive consumption of system resources. Once when footprint is reduced, which means that resources can serve more requests to achieve greater throughput.
FIG apparent from the above latency is the sum of all waiting for the various resources database instance. CPU time is the sum of the actual time spent working on the request. These times are not necessarily of a CPU and a waiting time blocks. Typically, the process will experience a short wait DB resources, then a brief run on the CPU, and repeat this operation.
Thus optimizing resource database includes reducing or eliminating waiting time and reducing CPU time. This definition applies to any type of application, online transaction processing (OLTP) or data warehouse (DW).
Note: The system displays a very busy longer DB CPU time, which may swell at other times.
Two, CPU and latency adjustment dimension
When adjusting system, the CPU time is very important to compare and latency of the system. By comparing the CPU time and the wait time, you can determine how much time is spent on useful work and how much time is spent waiting on resources other processes may hold. As a general rule, CPU time, the dominant system usually dominant system requires less adjustment than the waiting time. However, CPU may be caused by excessive use of SQL statements caused serious. The proportion of time to wait for CPU time always tends to increase as the system load increases, a sharp increase in latency of contention is a sign, and must seek good scalability.
When the increased waiting time tends to indicate resource contention serious, adding more CPU to the node or nodes to improve performance, with little success. Conversely, as the load increases, the proportion of CPU time is not significantly decrease the system can better expand, and most likely to benefit from adding a CPU or actual application cluster (RAC) instance.
Note: If the CPU time is part of one of the top five events, the Automatic Workload Repository (AWR) and Statspack report shows the CPU time and the wait time before the five events section.
Three, DB Time Case Studies
1, AWR report head
- environment
SQL> the SELECT 'Leshami' Author, 'HTTP: //blog.csdn.net/leshami' Blog,
2 '645 746 311' QQ from Dual;
AUTHOR BLOG QQ
- ------ ---------------------------- ---------
Leshami HTTP: // Blog. 645 746 311 csdn.net/leshami
. 1
2
. 3
. 4
. 5
. 6
from the figure shows, in the natural elapsed time of 10 minutes, the time it takes to call DB layer 432.12 minutes. That is about 43 times the natural time, the database is busy.
The current database logical CPU is eight, so that each CPU average service time is 432.12 / 8 = 54.015min
As described in the foregoing DB Time, DB Time = DB Wait Time + DB CPU Time 54.015min therefore require further confirm whether the real usage.
2, Load Profile
from the figure shows,
DB Time (S) lines, each time a second nature, as DB Time corresponding to 43.1s, 43.1 * 10.02 * Based on projections 60/60 is about equal to the head of the DB Time 432.12 minutes.
DB CPU (s) line, each time a second nature, CPU overhead is 0.1s, i.e. 10.02 * 60 * 0.1 = 60.12s, that is to say the time spent on the CPU only about 1 minute.
Redo size line, redo generated per second, more in line with OLTP database business scenarios.
Executes and Transactions also shows that the current business scenario for the OLTP type.
3, the first wait for the event
Pictured top wait events, in general, the database waiting for a long time.
write complete waits, waiting time is 15,629, average waiting 29322ms, accounted for 60.28% of the entire DB Time
above time sum, sum of 25,593, calculated with Load Profile 25851.6s (43.1 * 10.02 * 60-60.12) close.
Through the above calculation shows that the current database is not idle waiting more serious.
4, the host CPU load
on the host CPU load graph.
The host CPU
during the reporting period, "Load Average" begin / end value representing the size of each substantially run queue of the CPU host load rise, increased from 1.19 to 4.86
% the User + 1.0% + 0.6 = the System = 1.6 Thus idle CPU that% Idle% to 98.3
% WIO represents the proportion of CPU IO wait, here was 7.4%, meaning that the current system bottlenecks IO.
Examples of CPU
% the Total CPU, the CPU used in this example the proportion of the total CPU -%> Total CPU for Instance of
% the Busy CPU, the CPU is used the total ratio of this example is used Cpu ->% of busy CPU for Instance
% DB waiting Time for the CPU (the Resource Manager) refers to a resource manager used when a user is limited and the session using CPU, while the generated waiting. It will produce resmgr: cpu quantum wait for the event, if they have to wait for the event needs and values RSRC_MGR combine judgment. The solution is to limit the need to modify the resource plan.
The following calculation combines the operating system statistics, see the data behind Screenshot
% of busy CPU for Instance= （DB CPU+ background cpu time) / (BUSY_TIME /100)= (40.53 + 6.57)/ (7919/100)= 59.4%
% of Total CPU for Instance = ( DB CPU+ background cpu time)/( BUSY_TIME+IDLE_TIME/100) = (40.53 + 6.57)/ ((7,919+471,596) /100) = 0.98%
%DB time waiting for CPU (Resource Manager)= (RSRC_MGR_CPU_WAIT_TIME/100)/DB TIME
5, time statistical model
Pictured time on a statistical model.
sql execute elpased time period dominated that time is consumed mainly in the implementation of the above SQL.
These correspond to SQL execution to wait for an event to see the front of the Top Event, that is to say wait and contention outstanding.
Note that this time the model index inclusion relationship there Time Model Statistics add up to more than 100% the case.
6, the operating system statistics
over the operating system statistics screenshot
waiting time is 35287 centiseconds IO
7, the operating system level monitoring
Device: rrqm / S wrqm / SR / SW / S rkB / S WKB / S avgrq-SZ avgqu-SZ the await the svctm% util
SDB 0.00 142.00 15.00 230.00 288.00 1,116.00 11.46 3.94 16.16 4.08 the 100.00
SDA 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
DM-0 0.00 0.00 0.00 12.00 0.00 48.00 8.00 0.35 29.00 2.50 3.00
DM-. 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
DM-2 0.00 0.00 16.00 360.00 296.00 1068.00 7.26 4.38 11.71 2.66 the 100.00
Device: rrqm / S wrqm / SR / SW / S rkB / S WKB / S avgrq-SZ avgqu-SZ the await the svctm% util
SDB 0.00 142.00 12.00 218.00 96.00 1060.00 10.05 3.33 13.98 4.35 the 100.00
SDA 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
DM-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
DM-. 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
DM-2 0.00 0.00 14.00 360.00 160.00 1060.00 6.52 4.36 11.36 2.67 the 100.00
. 1
2
. 3
. 4
. 5
. 6
7
8
9
10
11
12
13
operating system level,% util to 100, await time is about average service time svctm4 times that there IO overload, which AWR waiting in reception waiting process echoes.
8, preliminary conclusions
1) was observed by top wait events, as well as the OS level, the current major bottleneck in IO.
2) If no enables asynchronous IO, consider enables asynchronous IO (the OS level and simultaneously turned DB)
3) SQL optimization to reduce excessive IO load, but can also be considered where the optimized SQL package, stored procedure
4) of hot objects partition and separate index, the inverted index design
----------------
Disclaimer: This article is the original article CSDN bloggers "Leshami", and follow CC 4.0 BY-SA copyright agreement, reproduced, please attach the original source link and this statement.
Original link: https: //blog.csdn.net/leshami/article/details/73554856