Performance is one of the big watchwords in the IT industry; nowhere is it more often used than in the database arena, and it's usually not a good sign. End users know nothing, really, of the inner workings of the database yet they are the first to point the 'finger of blame' at the database when the processing speed slows or queries take longer than they would like to return data. [For end users performance is time, and the longer a process takes the more dismal performance seems to be.] Yes, there ARE times when the database is at fault -- 'missing' indexes or stale statistics can cause execution plans to change, as can inserts and updates to heavily transacted tables (which many times goes back to stale statistics since they now no longer accurately reflect the data and its distribution in the table). Bugs in the database software can also cause issues by causing the gathered statistics to miscalculate values or generate 'useless' frequency histograms, such as on single-valued not null columns. Such histograms can direct the optimizer to choose a path it wouldn't normally choose when the statistics and histograms contain useful data.
Here is where the problem can get complicated: it may
At the first sign of trouble many look to the DBA to investigate the database for bottlenecks or other performance-robbing possibilities that surely must exist. Oracle provides at least two tools in releases 10.1 and later to investigate the database for performance problems -- the AWR report, a general overall 'picture' of the database 'health' that can give direction to such a quest and the ASH report, a more detailed 'picture' for a given window of activity that provides more detailed wait information. These utilities should be used at the first report of performance issues to determine if the problem is database-related or caused by another area, such as the operating system or network. Starting with the AWR (Automatic Workload Repository) report the two sections to begin an investigation, in my estimation, are Wait Events Statistics and SQL Statistics. The first provides a system-wide view of the waits encountered and the times those waits consumed. Background Wait Events and the Wait Event Histogram sections can provide some insight into what was occurring during the report window; waits to watch are I/O related waits (reads, writes) which can signal issues with a query plan or issues with the storage (is not addressable by the DBA). The SQL Statistics lists SQL statements in order of several areas, including overall elapsed time, consumed CPU time, I/O wait time and physical reads. The SQL statistics can usually point to 'bad' plans, making performance problems a database issue because such plans are the result of bad or stale statistics. In 11.2 and later releases, dynamic sampling can mitigate missing statistics by automatically sampling the data prior to generating a query execution plan. We won't get into the details of using these reports to effect database tuning procedures as that's a topic for another article. The intent here is to provide a means to determine IF the problem is a database issue or if it's caused by outside 'forces'. For releases earlier than 10.1 Oracle provides Statspack, the pre-cursor to AWR and the next step after the original database snapshot utilities utlbstat and utlestst. This utilility can provide a very good snapshot of database activity, although not quite as robust as the AWR report. It is still available in 11.2 if you would like to install it. AWR and ASH are utilities that are part of the Diagnostic and Tuning Pack for OEM, and thus need to be licensed if they are to be used. Statspack doesn't require such a license.
The ASH, or Active Session History, report digs deeper into important wait events and timings, providing a better picture of the wait activity during the requested window. Again, use this report to initially determine if the problem is database-related; if that is the case then this report should provide a wealth of data aimed at directing your database/query tuning efforts. If there is no indication of database problems then other areas are likely at fault. Waits to examine from both reports include SQL*Net more data to client, Disk file operations I/O and os thread startup. The first wait in that list can be an indicator of network problems, the second storage issues (array problems, pending disk failures) or CPU issues (excessive time for O/S thread startups can indicate over-taxed CPUs, which may be caused by other, non-database processes).
After examining reports generated by AWR, ASH or Statspack if you find the database is not the source of the performance issue you may be able to discern which area outside of the database is the likely suspect. SQL*Net more data to client waits, if the time per wait is relatively high, can indicate problems in the network layer. Utilities such as netstat can show configured network interfaces and network traffic data on those interfaces. Example output is shown below:
]$ netstat -ginw Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg bondeth0 1500 0 5084620269 0 0 0 3923352780 0 0 0 BMmRU bondeth0:1 1500 0 - no statistics available - BMmRU bondeth0:3 1500 0 - no statistics available - BMmRU bondeth0:4 1500 0 - no statistics available - BMmRU eth0 1500 0 42182099 0 0 0 21397203 0 0 0 BMRU eth4 1500 0 305021 0 0 0 281488 0 0 0 BMsRU eth5 1500 0 5084315248 0 0 0 3923071292 0 0 0 BMsRU ib0 64000 0 2419856775 0 1 0 2178061942 3 271 0 BMsRU ib1 64000 0 21305668 0 0 0 0 0 0 0 BMsRU lo 16436 0 4495752311 0 0 0 4495752311 0 0 0 LRU $
The utility reports transmit and receive statistics, including dropped packets and packet errors. Running netstat -ginw may show which local interface is having issues; send such output to the Network Administrator so he or she can interpret the results and take appropriate action.
What if the problem isn't the database, and it isn't the network? The next area that can adversely affect performance is the storage tier. Statspack and ASH/AWR reports also provide disk read and write wait information. Again, if the wait time for an individual read or write wait is high (for example, a single wait over 300 milliseconds) it may be the storage that's at fault. As disks age their performance can deteriorate as the alignment the platter had when new is compromised by wear and tear around the spindle. Firmware can also be an issue, especially when disks are upgraded and the firmware is not. This is not an area for the DBA to assess, but it is one he or she can report to the Storage Administrator for further investigation.
Network-related issues may also be a problem with either the local network interface card (NIC) or the cabling. This is, again, a task for the Network Administrator to assess and address, but you may be able to 'point' him or her in the right direction with output from the ping utility. Provided you have two or more systems that can 'see' the same endpoint a ping comparison may show network problems local to the database server. For example if server A can ping server C with response times less than 20 milliseconds and server B, using the same subnet, reports ping times in the 100 millisecond or greater range this could indicate either cabling issues or a NIC that may be misconfigured or failing. This isn't likely to be valid if the two servers are on different subnets which is why it's necessary to get the Network Administrator involved as soon as you suspect a network issue. He or she can provide needed configuration data and can better analyze and diagnose such problems.
And yet another area where performance can suffer is at the operating system level. A system starved for CPU, memory or both because of a temporarily high load can severely slow down database processes along with many other non-database-related services. The System Administrator may need to be called in on the issue to report what processes were running during a particular period when response time was slow. Remember that the end users equate performance with response time; a large, resource-intensive report that runs once a month can seriously slow down other database activity during that same period. System backups can also consume resources normally available for user and database processes. Knowing the period of poor performance can greatly assist the System Administrator investigating the issue. If it's a defined window, for example from 8 PM to Midnight on Tuesdays, the System Administrator can track down the process causing the slowdown by monitoring the system activity during that period. It may be a process that can't be stopped or rescheduled, but at least the end users will know what is causing their normally fast transactions to run much slower than usual. As mentioned before when you know it's not a database issue get the Administrators of the suspected systems involved, because the earlier you get more eyes on the problem the faster the cause can be found and a solution put in place.
The DBA is the 'go-to' person when the database is to blame for performance issues (long run times for specific queries, as an example). But, when the DBA finds nothing awry in the database, other parties may need to get involved. Again, just because it seems to be the database at fault doesn't mean that the database IS at fault; it could be other, related areas affecting performance. Knowing what database reports can be of use is the first step in being able to assess a situation so other areas, such as network and storage, can be brought in if need be. Knowing who to involve is just as important as knowing that a performance issue exists. Communication is key in these situations; a network or storage administrator may ask for additional information regarding the problem; this is where the AWR and/or Statspack reports may be helpful. Learn how to generate these reports now (if you don't already know) so that when you need them you can concentrate on the issues at hand rather than how to generate a report.
Performance is a term that can have a broad interpretation, depending upon who is doing the interpreting. End users may more often report performance issues when a report that ran fine yesterday now takes much longer to complete because all they may see is their process running slowly. Knowing when the problem is the database and when it isn't is key to getting such issues diagnosed and resolved. Hopefully this article has given you some tools to help in that regard; use them wisely and communicate well so that you can be part of the solution by knowing who else to involve when it isn't the database that is at fault.