#server #remote #monitoring, #oem #for #unix #server #monitoring
OEM for UNIX Server Monitoring
Oracle Tips by Burleson Consulting
OEM Outside the Instance
Using OEM, the Oracle professional can now get access to external information that has never been available before in a single interface. This is very important because it removes the need for the DBA to have any experience with the cumbersome OS command syntax required to display server-side information.
For example, in UNIX the DBA needs to know the command-line syntax of various UNIX utilities, such as SAR, glance, top, lsattr and, prtconf, to display server metrics. The OEM screens now allow seamless access server-side performance metrics including:
� Oracle server-side file contents in the form of the alert log and trace dumps.
� Oracle archive redo log file performance.
� Server OS kernel performance parameter values.
� Server OS characteristics such as the number of CPUs, amount of RAM, and network.
� Historical capture of CPU and RAM activity.
A quick look at the OEM display screens for external information shows how this relieves the DBA of knowing hundreds of server-side commands.
Oracle10g OEM quickly reveals the status of Oracle server-side file performance and error messages, including the alert log file, archived redo log status and file system status as shown in Figure 19.28.
Figure 19.28: A partial listing of the AWR metrics from inside OEM
The ability of OEM to monitor server-side metrics makes it a one-stop tool for monitoring both Oracle and the server. A Systems Administrator may no longer be required to buy expensive tools to monitor the server and the data files. Best of all, the Oracle professional now does not have to worry about a server-side problem (i.e. file-system full) causing an Oracle interruption.
From these OEM interfaces, the DBA can display and manage all server-side Oracle components without having to sign on to the server. This is a blessing for those Oracle professionals running UNIX servers who may not be fluent in cryptic UNIX commands and the complex vi editor. In Figure 19.29, the display of server ODS details including all OS kernel parameters is shown.
Figure 19.29: The OEM display of server-side performance parameters
The DBA can now throw away the checklist of cumbersome OS commands to display server hardware characteristics. For example, the following is a list of the cryptic commands the Oracle UNIX professional would have to know in order to display the number of CPUs on their Oracle server:
cat /proc/cpuinfo|grep processor|wc �l
psrinfo -v|grep Status of processor |wc �l
lsdev -C|grep Process|wc �l
ioscan -C processor | grep processor | wc -l
The Oracle10g OEM issues these commands on the DBA�s behalf and displays all hardware characteristics in an easy-to-read display as shown in Figure 19.30.
Figure 19.30: The OEM display of server-side hardware configuration
OEM does much more than display the server parameters and configuration information. Oracle tuning professionals know that a shortage of server resources may cause slow performance, and OEM now quickly displays the relevant CPU and RAM metrics. The main performance display screen in OEM now display a current summary of the CPU Run Queue and RAM paging as shown in Figure 19.31.
Figure 19.31: The HOST CPU section of the main OEM performance screen.
Here the DBA can quickly see if a shortage of Oracle server resources is causing a performance bottleneck. Assuming that the instance and SQL have already been optimized, this server-side information can give immediate insights to server resource shortages:
CPU Dispatcher Run Queue: Whenever the server processors are overstressed, the run queue exceeds the number of CPUs. For example, a run queue value of nine on an 8-CPU server indicates the need to add more or faster CPUs.
Server RAM Paging: Whenever the RAM demands of a server exceed the real RAM capacity, the servers Virtual Memory (VM) utility will page, transferring RAM frames to a special swap-disk on the server. Assuming the SGA and PGA regions are optimized, paging indicates the need to add RAM resources to the server.
The OEM also tracks server usage over time, allowing the DBA to quickly see those times when a hardware-related constraint is happening as shown in Figure 19.32. This display reveals the historical CPU usage, and a display of a self-defined threshold alert status, as defined by setting a threshold alert for the Average CPU (%) OEM Metric. is noted.
Figure 19.32: The OEM historical tracking of CPU consumption.
OEM also tracks server run queue waits over time, and combines the CPU and Paging display into a single OEM screen so the DBA can tell when server-side waits on hardware resources are being experienced as shown in Figure 19.33. This is important because Oracle performance issues are often transient in nature, with short spikes in excessive CPU demands. Because of the super-fast nature of CPU dispatching, a database might be CPU constrained for only a few minutes at a time during different times of the day. The time series OEM display can reveal a quick visual clue about those times when a CPU or RAM bottleneck is being experienced.
Figure 19.33: Server CPU run queue and RAM paging values over time
OEM has a drill down function which allows the DBA to easily click on any area of the graph to obtain detailed information.
Even though it is true that a CPU bottleneck exists when the run queue exceeds the number of processors, this condition does not always mean that the solution is to add processors.
Excessive CPU can be caused by many internal conditions including inefficient SQL statements that perform excessive logical I/O, non-reentrant SQL inside the library cache, and many other conditions. Fortunately, OEM allows the DBA to go back in time and find these conditions, even though the immediate run queue issue has passed.
Because of Oracle�s commitment to extending OEM beyond the boundaries of the Oracle instance, all areas of server utilization can be tracked over time as shown in Figure 19.34. Shown below are the specific times when the server exceeds the maximum CPU capacity, and the total time spent by active Oracle sessions, waiting and working.
Figure 19.34: Oracle server time-series resource component utilization
Because of the clarity of the color OEM display, the total components of Oracle wait times including CPU time, concurrency management overhead (locks, latches), and I/O can be clearly seen. This display also shows the times when CPU usage exceeds the server capacity.
To fully understand how to customize OEM for maximum benefit, a brief tour of the OEM exception reporting mechanism and how it displays the predefined alerts will be provided.
You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts:
Burleson is the American Team
Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals. Feel free to ask questions on our Oracle forum .
Verifyexperience!Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications .
Errata? Oracle technology is changing and we strive to update our BC Oracle support information. If you find an error or have a suggestion for improving our content, we would appreciate your feedback. Just e-mail: and include the URL for the page.
The Oracle of Database Support
Copyright 1996 – 2016
All rights reserved by Burleson
Oracle is the registered trademark of Oracle Corporation.