Following is the output of TOP (as you will notice the CPU is idle most of the time)
[oracle@xxx oracle]$ uname -a Linux xxx.aaa.bbb.com 2.4.21-47.ELhugemem #1 SMP Wed Jul 5 20:30:35 EDT 2006 i686 i686 i386 GNU/Linux [oracle@xxx oracle]$ lsb_release -a LSB Version: 1.3 Distributor ID: RedHatEnterpriseES Description: Red Hat Enterprise Linux ES release 3 (Taroon Update 8) Release: 3 Codename: TaroonUpdate8
I would appreciate any help/pointers.
10:44:34 up 9 days, 1:45, 1 user, load average: 1.01, 1.05, 1.01 204 processes: 203 sleeping, 1 running, 0 zombie, 0 stopped CPU states: cpu user nice system irq softirq iowait idle total 0.0% 0.0% 0.9% 0.0% 0.2% 25.9% 72.7% cpu00 0.0% 0.0% 0.0% 0.0% 0.7% 0.0% 99.2% cpu01 0.0% 0.0% 3.3% 0.1% 0.1% 0.0% 96.2% cpu02 0.3% 0.0% 0.0% 0.0% 0.0% 51.7% 47.8% cpu03 0.0% 0.0% 0.3% 0.0% 0.0% 51.9% 47.6% Mem: 4095396k av, 4077192k used, 18204k free, 0k shrd, 10516k buff 3092572k actv, 599188k in_d, 71368k in_c Swap: 4088532k av, 234500k used, 3854032k free 3721384k cached
Dude wrote:I don't think the system is overloaded. If you see the output of TOP in my original post, you will see that CPU is idle most of the time & load average is well within acceptable limits.
The OS can show you various statistics, but you cannot use this information to determine whether or not the Oracle Database is using the available resources efficiently. The system might simply be overloaded showing bad performance, from which you cannot conclude whether or not the system is operating normally.
I suggest to shutdown the database and do a few I/O troughput tests of various sizes to see if the disk performance is what you would expect from the hardware. You could try a simple "dd if=/dev/zero of=/dir/testfile bs=1G count=1" for instance to check how long it takes to create a 1 GB file. You can also download and install the free Oracle Orion tool for a more realistic test suitable for Oracle database systems. If these tests do not show any unusal performance, your only option will be to check RMAN v$session_longops for example.I am afraid I won't be able to shut down the DB as it is a LIVE one. I did the basic throughput test you suggested but not sure if it reveals anything
I can see records in v$session_longops but any conclusion derived from that would be "as reported by Database".
[oracle@xxx oracle]$ time dd if=/dev/zero of=/tmp/testfile bs=1G count=1 1+0 records in 1+0 records out real 0m17.287s user 0m0.000s sys 0m5.130s
You may find iostat shows you something (or nothing .....)
iostat -xtc 5 5 on both machines ( i think i use iostat -xtcnz 4 4 on solaris at the momemt).
I'd possibly run some vmstat's as well in case anything shows.
While my datafiles are on local disk, the backup location (FRA) is on a NFS mount.So perhaps something is eating up your network performance and slows down your backup to FRA.
My intention here is to validate what is reported by database with what is reported by OS.Why do you think you can? Does your system require more CPU or I/O or RAM than usual? A problem in your database does not necessarily mean a problem for the OS. If you have a problem with the OS however, it will affect the performance of your database. I suggest to check the performance and wait statistics in RMAN and your database. You may also want to check /var/log/messages for any errors. What about your virtual machine, are you using the correct kernel and PVHVM drivers ?