0% found this document useful (0 votes)
162 views

Managing Oracle On Linux

This document provides an overview of monitoring and tuning Oracle database performance on Unix/Linux systems. It discusses monitoring and tuning various system resources like CPU, memory, and I/O. It describes common Unix tools like top, sar, vmstat, iostat for measuring resource usage and identifies metrics to monitor for each resource. It also provides recommendations for reducing bottlenecks on each system resource.

Uploaded by

obeidat_dba
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
162 views

Managing Oracle On Linux

This document provides an overview of monitoring and tuning Oracle database performance on Unix/Linux systems. It discusses monitoring and tuning various system resources like CPU, memory, and I/O. It describes common Unix tools like top, sar, vmstat, iostat for measuring resource usage and identifies metrics to monitor for each resource. It also provides recommendations for reducing bottlenecks on each system resource.

Uploaded by

obeidat_dba
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

Managing Oracle on Unix /Linux

INTRODUCTION

• Kernel

• Shared Memory
• Semaphores
• File Handles Parameter
Basic Tuning Methodology

Tune the Database

Tune the Hardware

CPU
Memory
I/O
Standard Measurement Tools

Linux has measurement tools that are common


to UNIX platforms:

• Top Resource Consumers : top


• System Activity Reporter: sar
• Virtual Memory Statistics: vmstat
• I/O Statistics: iostat
• System Log files: /var/log/messages
Monitoring and Tuning CPU

Is the CPU a bottleneck?

• How many CPUs does the machine have?

• What is the load average?

• What is the load factor?


top
top

Top is an interactive utility.


? - to see list of options.
u - allows to identify a single user for

the display
s - to change the refresh rate.
k - to kill processes if top is run by root

user
CPU Measurements

Identify the following CPU statistics and interpret them:

• CPU Idle Time (%idle)

• CPU Time Spent Executing User and System Codes


(%user, %system)

• Processes Waiting for CPU Time (run-queue size)


(runq-sz)
mpstat

• $ mpstat -P ALL 1 2
vmstat
sar
.
iostat

.
Interpreting CPU Measurements

Observe cases where the system has:

• High idle time with poor response time

• Too much time spent executing user code


• Too much time spent executing system code
• Run-queue size more than double the number of CPUs

• Extremely high context requests per second


Reducing CPU Bottlenecks

• Schedule non-time critical jobs to run during times when


CPU is less loaded.

• Too many batch jobs cannot be started simultaneously

• Reduce the demand on CPU by eliminating unnecessary


work or offloading work to a different server.
Memory

Types – Real & Virtual

Measure memory utilization and paging. Significant


memory statistics include:
 Total Memory
 Context switches
 Pages in and out
 Inactive pages
 Demand rate
top
/proc/meminfo

.
vmstat

.
sar

.
Interpreting Memory Measurements

Observe cases where the system has:

• High Swap Memory Usage

• High Page ins / Page outs

• Low inactive Pages.


Reducing Memory Bottlenecks

• If we determine that memory is the limiting factor in our


system, then:
Increase memory resources
Decrease memory demand
Export/Import File Compression Utilities

• Create a special FIFO file named " exp.pipe" :


$ mknod exp.pipe p

. Use any compression options,

$ bzip2 < exp.pipe > exp.bz2 &


exp.gz - compressed file
& - Used to run the process in the background.

. Now use the normal export command with file=exp.pipe

$ exp …… file = exp.pipe ……


Import

• create another file " imp.pipe " as in step 1

• $ bunzip2 < exp.bz2 > imp.pipe &

. Use the normal import command with file=imp.pipe

$ imp file = imp.pipe …..


Tracking an Event in Unix/Solaris

• Truss
Traces a process's system calls, dynamically loaded user
level function calls, received signals, and incurred machine
faults.

Example:
 Imp (command line options)
 ps -ef | grep imp
Oracle 3725 3720 0 13:43:07 pts/7 0:00 grep imp
Oracle 3714 3663 0 13:42:27 pts/1 0:00 imp
 Truss –p 3714
Received signal #20 , SIGWINCH, in read () [default]
Read (0, 0xEF655EA4,1024) (sleeping ………..)
Read (0, “ scott\n “,1024) = 6
Lseek(3, 5120, SEEK_SET) = 5120
Read (3, “\0\f\OCE\O\O\P” .., 512) = 512
Write (1, “ password : “,10) = 10
Ioctl (0, TCGETA, OxEFFF30C) = 0
Ioctl (0, TCGETS, OxEFFF384) = 0
Ioctl (0, TCGETSF, OxEFFF384) = 0

 ps –ef | grep 3714


Oracle 3714 3731 0 13:47:57 pts/1 0:00 imp
Oracle 3743 3714 0 13:53:27 ? 0:00 mydb
(DESCRIPTION= (LOCAL=YES) (ADDRESS= (PROTOCOL=beq)))
Oracle 3747 3706 0 13:59:57 pts/6 0:00 grep 3714
I/O Measurement

Criteria for Measurement

1.Volume:
-Volume of data being handled.

2.Speed :
-Transfer rate, Wait time and
Service time are monitored
•READ / WRITE OPERATIONS

.
•REQUEST QUEUE SIZE

•TRANSFER RATE

•WAIT TIME

•SERVICE TIME
Tools for measuring I/O

1.I/O STAT
2. Sar
3. vmsstat
• $ iostat -d 2 4
I/O STAT
• Linux
• Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
• dev8-0 7.10 18.31 125.16 80095708 547572178
• dev8-1 0.02 0.42 0.14 1833186 606334
• dev8-2 52.06 395.60 896.02 1730727488 3920045878
• dev8-3 0.02 0.42 0.13 1840394 576328
• dev8-4 51.95 388.55 896.73 1699884394 3923163422

• Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn


• dev8-0 0.00 0.00 0.00 0 0
• dev8-1 0.00 0.00 0.00 0 0
• dev8-2 1.50 0.00 24.00 0 48
• dev8-3 0.00 0.00 0.00 0 0
• dev8-4 0.00 0.00 0.00 0 0
• Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

• dev8-0 3.00 0.00 96.00 0 192


• dev8-1 0.00 0.00 0.00 0 0
• dev8-2 3.50 0.00 56.00 0 112
• dev8-3 0.00 0.00 0.00 0 0
• dev8-4 4.50 0.00 84.00 0 168
• Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

• dev8-0 0.00 0.00 0.00 0 0


• dev8-1 0.00 0.00 0.00 0 0
• dev8-2 1.00 0.00 16.00 0 32
• dev8-3 0.00 0.00 0.00 0 0
• dev8-4 0.50 0.00 8.00 0 16
Sar

• $ sar -R 2 3
• Linux
11:21:11 PM DEV tps rd_sec/s wr_sec/s
01:23:24 PM dev1-1 -771.14 2.49 279.10
01:23:26 PM dev1-2 -1215.08 6.53 202.01
01:23:28 PM dev1-3 109.05 1.01 107.04
Average: -626.21 3.34 196.33
vmsstat
$vmstat 1 2

bi bo
1 1
3419 808

bi: Blocks received from a block device (blocks/s).

bo: Blocks sent to a block device (blocks/s).


Interpreting I/O Measurements
• High request volume or queue size overall

- means that the I/O devices are unable to handle


the rate of I/O requests or the channels in the
I/O devices are too slow.
• High request volume or queue size for one
device
- indicates that I/O may not be balanced
across available devices.
• High wait times
-Indicative of hardware problems or I/O slaves in
use.
Reducing I/O Bottlenecks
• reduce i/o through application tuning or memory
tuning
• increase i/o by parallelizing I/O
-multiple disk controllers
- multiple disks
-multiple data bus adapters
• select hardware carefully – storage arrays
(RAID) may be preffered.

• keep different file types like redo ,undo,temp on


different disks.
Physical reads and Physical writes can be obtained
Datafilewise by combining the V$ datafile and
V$ filestat.
Devicewise no of block reads per sec and block writes
per sec can be obtained from I/O STAT report.
When we observe that in a single disk there are more
read/write taking place and if that disk has more than
one datafile with more no of physical reads and
physical writes ,
Then we can move one of the datafiles to a device with
a less Read/Write activity and reduce the I/O
contention and ultimately improve the Database
performance.
Thank you

You might also like