Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 

 

 

Oracle UNIX Monitoring RAM Memory Consumption Administration

Oracle UNIX/Linux Tips by Burleson Consulting

Monitoring RAM Memory Consumption

In the UNIX environment, RAM memory is automatically managed by the operating system. In systems with ?virtual? memory, a special disk called swap is used to hold chunks of RAM that cannot fit within the available RAM on the server. In this fashion, a virtual memory server can allow tasks to allocate memory above the RAM capacity on the server. As the server is used, the operating system will move some memory pages out to the swap disk in case the server exceeds its physical capacity. This is called a page-out operation.  Remember, page-out operations occur even when the database server has not exceeded the RAM capacity.

RAM memory shortages are evidenced by page-in operations. Page-in operations cause Oracle slowdowns because tasks must wait until their memory region is moved back into RAM from the swap disk. The remedy for memory overload is to add more memory or to reduce the demands on memory by reducing sort_area_size, implementing the multithreaded server, or reducing the values for shared_pool or db_block_buffers.

As we briefly noted in Chapter 1, there are several remedies for overloaded RAM memory:

* Add RAM - Add additional RAM to the server

* Reduce Oracle RAM - Reduce the size of the SGA regions by down-sizing the shared pool or data block buffers

* Implement the Multi-threaded server ? Implementing the MTS will reduce RAM demands by shifting RAM demand from individual Program Global Areas (PGS) into a shared large_pool inside the Oracle SGA.

* Tune SQL ? You can often tune expensive SQL statements to reduce the demands on the server

Next, let?s move on and take a look at how to build an easy UNIX server monitor by extending the Oracle STATSPACK tables.

Capturing Server Performance Data Inside STATSPACK

Now that we have seen that vmstat can provide useful information about the status of the Oracle database server, how can we create a mechanism for monitoring these vmstat statistics? As we noted from our discussion of vmstat, system-level resource contention is transient and fleeting, and it is often very easy to miss a bottleneck unless we are constantly vigilant. For this reason, we need to create an extension to the STATSPACK tables that will constantly poll the hardware and collect any data relating to resource contention.

The concept behind this extension is to execute the vmstat utility and capture the performance information within an Oracle table called stats$vmstat.

While this technique works very well for monitoring the Oracle database server, these operating system statistics can also be used to monitor the other computers in your system. These include the application servers (Web servers) and the Oracle database server. We will show you how to collect vmstats on a remote server later in this chapter.

A Script to Capture vmstat Information

It is a simple matter to create an Oracle table to store this information and use a script to populate the table. Creating the automated vmstat monitor begins by creating an Oracle table to contain the vmstat output:

cr_vmstat_tab.sql
connect perfstat/perfstat;

drop table stats$vmstat;
create table stats$vmstat
(
     start_date          date,
     duration            number,
     server_name         varchar2(20),
     runque_waits        number,
     page_in             number,
     page_out            number,
     user_cpu            number,
     system_cpu          number,
     idle_cpu            number,
     wait_cpu            number
)
tablespace perfstat
storage (initial   10m
         next       1m
         pctincrease 0)
;

Now that we have defined an Oracle table to capture the vmstat information, we need to write a UNIX script that will execute vmstat, capture the vmstat output, and place it into the Oracle table.

The main script to collect the vmstat information is a Korn shell script called get_vmstat.ksh. As we noted earlier, each dialect of UNIX displays vmstat information in different columns, so we need slightly different scripts for each type of UNIX.

The idea is to write a script that continually runs the vmstat utility and then directs the results into our Oracle table, as shown in Figure 3-4.

Figure 4: Capturing vmstat output into a STATSPACK extension table

The script shows the vmstat capture utility script for the Linux operating system. The scripts at the Oracle Press Web site contain complete code for a vmstat script for all of the major UNIX dialects.  Go to www.oraclepressbooks.com to get the code.

Note that you must change this script in several places to make it work for you:

* You must set the ORACLE_HOME to your directory:

ORACLE_HOME=/usr/app/oracle/admin/product/8/1/6

* You must set your ORACLE_SID in the sqlplus command:

$ORACLE_HOME/bin/sqlplus -s perfstat/perfstat@testsys1<<EOF

* You can change the duration of samples by re-setting SAMPLE_TIME UNIX variable:

SAMPLE_TIME=300
get_vmstat.ksh (Linux version)
#!/bin/ksh

# This is the Linux version

ORACLE_HOME=/usr/app/oracle/admin/product/8/1/6
export ORACLE_HOME

PATH=$ORACLE_HOME/bin:$PATH
export PATH
SERVER_NAME=`uname -a|awk '{print $2}'`
typeset -u SERVER_NAME
export SERVER_NAME

# sample every five minutes (300 seconds) . . . .
SAMPLE_TIME=300

while true
do
   vmstat ${SAMPLE_TIME} 2 > /tmp/msg$$

# run vmstat and direct the output into the Oracle table . . .
cat /tmp/msg$$|sed 1,3d | awk  '{ printf("%s %s %s %s %s %s\n", $1, $8, $9,
14, $15, $16) }' | while read RUNQUE PAGE_IN PAGE_OUT USER_CPU SYSTEM_CPU
DLE_CPU
   do

      $ORACLE_HOME/bin/sqlplus -s perfstat/perfstat@testsys1<<EOF
      insert into perfstat.stats\$vmstat
                           values (
                             sysdate,
                             $SAMPLE_TIME,
                             '$SERVER_NAME',
                             $RUNQUE,
                             $PAGE_IN,
                             $PAGE_OUT,
                             $USER_CPU,
                             $SYSTEM_CPU,
                             $IDLE_CPU,
                             0
                                  );
      EXIT
EOF
   done
done

rm /tmp/msg$$

Because of the differences in implementations of vmstat, the first task is to identify the columns of the vmstat output that contain the information that we want to capture. Once we know the columns that we want to capture, we can add these columns to the vmstat script to put the output into our table.

Run queue

Page-in

Page-out

 

User

System

Idle

Wait

Dialect

 

column

column

column

 

column

column

column

column

HP/UX

 

1

8

9

 

16

17

18

NA

AIX

 

1

6

7

 

14

15

16

17

Solaris 

 

1

8

9

 

20

21

22

NA

Linux

 

1

8

9

 

14

15

16

NA

Using this table, you can adjust the capture script according to your operating system. You customize the script by changing the line in the script that reads the vmstat output and places it into the stats$vmstat table. Here is a summary of the UNIX dialect changes to this line.

HP/UX vmstat Columns
cat /tmp/msg$$|sed 1,3d |\
 awk  '{ printf("%s %s %s %s %s %s\n", $1, $8, $9, $16, $17, $18) }' |\
 while read RUNQUE PAGE_IN PAGE_OUT USER_CPU SYSTEM_CPU IDLE_CPU
IBM AIX vmstat Columns
cat /tmp/msg$$|sed 1,3d |\
 awk  '{ printf("%s %s %s %s %s %s\n", $1, $6, $7, $14, $15, $16, $17) }' |\
 while read RUNQUE PAGE_IN PAGE_OUT USER_CPU SYSTEM_CPU IDLE_CPU WAIT_CPU
Sun Solaris vmstat Columns
cat /tmp/msg$$|sed 1,3d |\
 awk  '{ printf("%s %s %s %s %s %s\n", $1, $8, $9, $20, $21, $22) }' |\
 while read RUNQUE PAGE_IN PAGE_OUT USER_CPU SYSTEM_CPU IDLE_CPU

Linux vmstat columns

cat /tmp/msg$$|sed 1,3d |\
 awk  '{ printf("%s %s %s %s %s %s\n", $1, $8, $9, $14, $15, $16) }' |\
 while read RUNQUE PAGE_IN PAGE_OUT USER_CPU SYSTEM_CPU IDLE_CPU

Internals of the vmstat Capture Script

It is important to understand how the get_vmstat.ksh script functions, so let?s examine the steps in this script:

1. It executes the vmstat utility for the specified elapsed-time interval (SAMPLE_TIME=300).

2. The output of the vmstat is directed into the /tmp directory

3. The output is then parsed using the awk utility, and the values are inserted into the mon_vmstats table.

Once started, the get_vmstat.ksh script will run continually and capture the vmstats into your stats$vmstat table. This script is an example of a UNIX daemon process, and it will run continually to sample the server status. However, the script may be terminated if you server is rebooted, so it is a good idea to place a crontab entry to make sure that the get_vmstat script is always running. Below is a script called run_vmstat.ksh that will ensure that the vmstat utility is always running on your server.

Note that you must make the following changes to this script:

* Set the file location variable vmstat to the directory that contains your get_vmstat.ksh script:

vmstat=`echo ~oracle/vmstat`

* Create a small file in your UNIX file directory ($vmstat) called mysid. This file will contain one line and specify the name of your ORACLE_SID.

ORACLE_SID=`cat ${vmstat}/mysid`
run_vmstat.ksh
#!/bin/ksh

# First, we must set the environment . . . .

vmstat=`echo ~oracle/vmstat`
export vmstat
ORACLE_SID=`cat ${vmstat}/mysid`
export ORACLE_SID

ORACLE_HOME=`cat /etc/oratab|grep $ORACLE_SID:|cut -f2 -d':'`
export ORACLE_HOME
PATH=$ORACLE_HOME/bin:$PATH
export PATH

#----------------------------------------
# If it is not running, then start it . . .
#----------------------------------------
check_stat=`ps -ef|grep get_vmstat|grep -v grep|wc -l`;
oracle_num=`expr $check_stat`
if [ $oracle_num -le 0 ]
 then nohup $vmstat/get_vmstat_linux.ksh > /dev/null 2>&1 &
fi

The run_vmstat.ksh script can be scheduled to run hourly on the server. As we can see by examining the code, this script checks to see if the get_vmstat.ksh script is executing. If it is not executing, the script resubmits it for execution. In practice, the get_vmstat.ksh script will not abort, but if the server is shut down and restarted, the script will need to be restarted.

Here is an example of the UNIX crontab file. For those not familiar with cron, the cron facility is a UNIX scheduling facility that allows tasks to be submitted at specific times. Note that it schedules the run_vmstat.ksh script every hour, and runs a vmstat exception report every day at 7:00 A.M.

00 * * * * /home/vmstat/run_vmstat.ksh > /home/vmstat/r.lst

00 7 * * * /home/vmstat/run_vmstat_alert.ksh prodb1 > /home/vmstat/v.lst

Now that we see how to monitor the Oracle database server, let?s examine how we can use this technique to report on other Oracle-related server. This technique is very handy for reporting on Oracle Web servers and application servers.

 

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.


 

 
��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster
 
 
 

 

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.

Verify experience! 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.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational