Performance Tuning: by Suresh.R

Performance tuning
By
Suresh.R
RubricsConsulting
Factors affect the system
 Design issues
 Poor schema design-expensive SQL that does not scale
 Poor transaction design-locking and serialization
 Poor connection management-response time and
unreliable systems
 Physical implementation of application
 Moving to production with bad I/O strategies
 Production system uses different execution plan than one
tested
 Excessive memory usage-applications do not release
memory
 Inefficient memory usage-memory leaks put stress on OS
virtual memory subsystem
www.Rubricsconsulting.com
Factors affect system (contd..)
 Incorrect sizing of hardware components
 Bad capacity planning of all hardware
components
 Software limitations
 Application servers, database servers cannot
handle beyond what it can
System Architecture
 Hardware components-perform one task
 CPU
 Memory
 I/O Subsystem
 Network
 Software components-perform many tasks
 Divided into functional components
 User interface
 Business logic
 Managing user requests and resource allocation
 Managing data and transactions
 Configuring the right system architecture for requirements
Steps in identifying problems
 Talk to users, determine project’s scope and performance goal
 Collect operating system, database and application statistics
from the system when the performance is both good and bad
 Evaluate the claim (sanity check) and observe the OS of all
machines involved, list any over-used resources and for any
errors
 Build a conceptual model of what is happening on the system
using the statistics
 Propose a series of actions
 Validate that the changes made have had the desired effect,
otherwise repeat the last 3 steps
Top mistakes
 Bad connection management
 The application connects and disconnects for each database interaction-totally un
scalable
 Bad use of cursors and shared pool
 Not using cursors result in repeated parses
 Use bind variables
 Applications should not generate dynamic SQL
 Bad SQL
 One that uses more resources than appropriate
 Getting database I/O wrong
 Poor layout databases over available disks
 Redo log setup problems
 Small size redo logs cause frequent checkpoints
 Less number of redo logs-database wait for ARCH process to finish
 Long full table scans
 Use locally managed table spaces to reduce recursive SQLs
 Deployment or migration errors
 Missing indexes or incorrect statistics
Wait events
 Wait events are statistics incremented by server
process that it had to wait for an event to complete
before being able to continue processing
 Symptoms of wait events with respect to performance
[only symptoms and not the real cause]
 A server process can wait for following:
 A resource to become available, such as buffer or a latch
 An action to complete, such as I/O
 More work to do, such as waiting for the client to provide
next SQL statement to execute – idle events
 To improve response time, reduce the time spent by
server process waiting for event completion
 Set TIMED_STATISTICS=TRUE to see how long the
each resource waited for
Dynamic views- wait events
 V$SESSION_WAIT- displays resource or events for
which active sessions are waiting
 V$SESSION_EVENT- summary of all events the
session has waited for since it started
 V$SESSION- contains detailed information on the
object that the session is currently waiting for (object
number, file number, row number ) and the blocking
session responsible for the current wait
Dynamic views- wait events
For example
If v$system_event indicates the largest wait event (wait time) ‘buffer
busy waits’, then by querying v$waitstat, will know which block
type has the highest wait count
 V$SYSSTAT- contains overall statistics for different parts of
oracle- rollback segment, logical and physical I/O, parse data
 V$FILESTAT- file I/O statistics for each file
 V$ROLLSTAT- contains detailed rollback and undo segment
statistics for each segment
 V$ENQUEUE_STAT- detailed enqueues statistics for each
enqueue, including number of times an enqueue was requested
and the number of times an enqueue was waited for and wait
time- place item in a queue for database resource
 V$LATCH- type of a lock for SGA buffers, not ordered one
Important Waits
 Buffer busy waits
 Free buffer waits
 Db file sequential read
 Db file scattered read
 Enqueue waits
 Library cache latch waits
 Library cache
 Library cache pin
 Library cache lock
 Log buffer space
 Log file sync
Buffer busy waits
This event is commonly caused SQL> select * from v$waitstat;
when multiple session are
trying to read the same block or CLASS COUNT TIME
multiple session waiting for a ------------------ ---------- -------------------------
data block 2 0
change to complete in the sort block 0 0
same block save undo block 0 0
segment header 0 0
Causes save undo header 0 0
 To determine the possible free list 0 0
extent map 0 0
causes, first query 1st level bmb 0 0
V$SESSION to identify the 2nd level bmb 0 0
value of ROW_WAIT_OBJ# 3rd level bmb 0 0
bitmap block 0 0
when the session waits for bitmap index block 0 0
buffer busy waits. For file header block 0 0
example: unused 0 0
system undo header 0 0
SELECT row_wait_obj# FROM system undo block 0 0
V$SESSION WHERE EVENT undo header 0 0
undo block 0 0
= 'buffer busy waits';
18 rows selected.
Buffer busy waits (contd..)
To identify the object and object type contended for, query
DBA_OBJECTS using the value for ROW_WAIT_OBJ#
that is returned from V$SESSION.
For example:
SELECT owner, object_name, subobject_name, object_type
FROM DBA_OBJECTS
WHERE data_object_id = &row_wait_obj;
Block contention corrective actions depends on the type of block

involved
 data blocks:
 Reduce number of rows per block whether changing pctfree/pctused or
reducing the DB_BLOCK_SIZE.
 Check for 'right-hand-indexes' (indexes that get inserted into at the same
point by many processes). You can use reverse key indexes to distribute
the different information.
Buffer busy waits- actions
 segment header
 Use freelists or increase of number of freelists.
 Extent size too small can cause contention on the
header when the table grows regularly. Consider
increasing the extent size for the table.
 undo header
 Add more rollback segments to reduce the number of
transaction per rollback segment.
 Reduce the value of the parameter
TRANSACTION_PER_ROLLBACK_SEGMENT
 undo block
 Consider making rollback segments larger in exclusive
mode
Db file sequential read
 This signifies a wait for an I/O read request to complete.
[I/O is normal, but avoid unnecessary I/O or Slow I/O]
 A sequential read reads data into contiguous memory
 A sequential read is usually a single-block read, this wait may
also be seen for reads from datafile headers (P2=1 indicates a
file header read)
 Parameters: P1 = file# P2 = block# P3 = blocks
 file# This is the file# of the file that Oracle is trying to read from.
 block# This is the starting block number in the file from where
Oracle starts reading the blocks. Typically only one block is
being read.
 blocks This parameter specifies the number of blocks that
Oracle is trying to read from the file# starting at block#. This is
usually "1" but if P3 > 1 then this is a multiblock read.
SELECT sid, total_waits, time_waited FROM v$session_event WHERE
event='db file sequential read' and total_waits>0 ORDER BY 3,2 ;
Db file sequential read- action
 Reducing waits
Block reads are fairly inevitable so the aim should be to minimise
un-necessary IO. This is best achieved by good application design
and efficient execution plans. Changes to execution plans can yield
orders of magnitude changes in performance.
Following might help in reducing waits:
Db file sequential read- action
 Check for SQL using unselective index scans
 A larger buffer cache can help - DB_BLOCK_BUFFERS
 A less obvious issue which can affect the IO rates is how well data is
clustered physically.
 Eg: Assume that you frequently fetch rows from a table where a column
is between two values via an index scan. If there are 100 rows in
each index block then the two extremes are:
 Each of the table rows is in a different physical block (100 blocks need to
be read for each index block)
 The table rows are all located in the few adjacent blocks (a handful of
blocks need to be read for each index block)
 Pre-sorting or re-organising data can help to tackle this in severe situations.
 See if partitioning can be used to reduce the amount of data you need to
look at.
 It can help to place files which incur frequent index scans on disks which
have are buffered by an O/S file system cache. Often this will allow some of
Oracles read requests to be satisfied from the OS cache rather than from a
real disk IO.
Db file scattered read-wait
 This wait happens when a session is waiting
for a multi-block I/O to complete
 When oracle does multi-block read count?-
full table scan, full index scan
 Oracle reads up to
DB_FILE_MULTIBLOCK_READ_COUNT
consecutive blocks at a time and scatters
them into buffers in the buffer cache
V$SESSION_WAIT- individual waits details
V$SYSTEM_EVENT- system wide wait details
Individual waits
 Parameters
 P1-File#
 File id from which oracle is trying to read from
 P2-Block#
 Starting block number in the file from where oracle starts reading the
blocks
 P3-blocks
 Number of blocks oracle is trying to read from the file# starting at p2
(block#)
SQL> execute sys.dbms_system.set_ev(&&SID, &&SERIAL,
10046, 8, ' ');
-- activate level 8 extended SQL tracing.
******* run all of your processing here *******
SQL> execute sys.dbms_system.set_ev(&&SID, &&SERIAL,
10046, 0, ' ');
-- disables extended SQL tracing.
System wide wait
 If the TIME spent is significant in waiting for multi-block
reads then determine which segments oracle is
performing the reads against
 V$FILESTAT- read/write, blocks read/write statistics
 Determine if multi-block read is happening to a file
SQL> select PHYBLKRD/PHYRDS from v$filestat where file#=1;
PHYBLKRD/PHYRDS
-------------------------
1.76337715
 Ratio >1 shows that multi-block read is happening
 Check which sessions are doing multi-block read
SQL>SELECT sid, total_waits, time_waited FROM v$session_event WHERE event='db file
scattered read‘ and total_waits>0 ORDER BY 3,2;
 it is worth tracing those sessions which are

doing multi-block reads to see if it really required
Reduce- db file scattered read wait
 Partitioning table can reduce the amount of data
scan
Locks
 Oracle uses different types of locking
mechanisms:
 Enqueues- database objects [ tables, indexes]
 Latch- for shared memory structures- it uses exclusive
access to memory structures in SGA
 Locking modes
 Exclusive- prevents concurrent access –ex. Update table
 Shared- share mode on resource-does not allow other
session to modify while providing concurrent access to that
shared resource
 Null- other session can acquire a lock and it invalidates
session’s private cached information upon invalidation of
the resource structure
Locks contd..
 Sub-shared- provides shared access to part of the shared
resource rather than the whole object, this mode is used so
that exclusive access to other parts of an object can be
provided
 Sub-exclusive- this mode is held to provide exclusive
access to a part of a shared resource, while other parts of
the resource are being concurrently accessed
Locks Mode Compatibility Table

Oracle decides at runtime
whether to allow the
session to lock a particular
resource of to enqueue the
request of the lock in one
of the linked list (waiter,
converter)
Locks
 Oracle kernel enqueue service layer is
responsible for all managed enqueues
SQL> update emp_hisal set ename='SURESH' where empno is null;
1 row updated.
SQL> select id1,id2 from v$lock;
ID1 ID2 ---------------------- identifies the
---------- ----------
262162 4021
50714 0
SQL> select object_name from dba_objects where object_id=50714;
OBJECT_NAME
----------------------------------------------------------------
EMP_HISAL
Blocking session
Session-1
SQL> update emp_hisal set ename='SURESH' where empno
is null;
1 row updated.
Session-2
SQL> update emp_hisal set ename='SURESH' where empno
is null;
SQL> select * from v$lock;
ADDR KADDR SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK

-------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------- --------------------------------------------
21F473D4 21F474E8 145 TX 327681 873 6 0 231 1
21F16990 21F169A8 145 TM 50714 0 3 0 479 0
21F168FC 21F16914 150 TM 50714 0 3 0 89 0
2266399C 226639B0 150 TX 327681 873 0 6 89 0
Blocking session contd..
SQL> select sid, username from v$session;
SID USERNAME
---------- ------------------------------
145 SCOTT
147
150 SCOTT
153 SCOTT
SQL> select row_wait_obj#, row_wait_file#, row_wait_block#,
row_wait_row# from v$session where sid=145;
ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#

------------- -------------- --------------- -------------
-1 4 1400 0
Instance tuning
 The main Oracle memory caches that
affect performance are:
 Shared pool
 Large pool
 Java pool
 Buffer cache
 Streams pool size
 Log buffer
 Process-private memory, such as memory
used for sorting and hash joins
Automatic SGA memory management
(ASMM)
 ASMM simplifies configuration of the SGA, to use ASMM, set the
SGA_TARGET initialization parameter to a nonzero and set
STATISTICS_LEVEL=TYPICAL/ALL
 Set SGA_TARGET = amount of memory that you want to dedicate
of the SGA
 MMON will monitor the SGA usage
 The MMAN process will take some regular memory snapshots to
evaluate the needs and thereby the dispatching of the usable
memory.
 In response to work load on the system, the automatic SGA
management distributes the memory appropriately for:
 Database buffer cache (default pool)
 Shared pool
 Large pool
 Java pool
If these automatically tuned memory pools had been set to nonzero values, those values
are used as a minimum levels by
ASMM
 If you set SGA_TARGET to 0, Automatic Shared Memory
Management is disabled and you can manually size the
memory pools with the DB_CACHE_SIZE,
SHARED_POOL_SIZE, LARGE_POOL_SIZE, and
JAVA_POOL_SIZE
 The following pools are manually sized components and are
not affected by Automatic Shared Memory Management:
 Log buffer
 Other buffer caches, such as KEEP, RECYCLE, and other
block sizes
 Streams pool
 Fixed SGA and other internal allocations
 Parameters associated with above memory buffers are
DB_KEEP_CACHE_SIZE, DB_RECYCLE_CACHE_SIZE,
DB_nK_CACHE_SIZE, STREAMS_POOL_SIZE, and
LOG_BUFFER initialization parameters
Sizing Buffer cache
 Buffer Cache Hit Ratio
 The buffer cache hit ratio calculates how often a requested
block has been found in the buffer cache without requiring
disk access
SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME IN
('db block gets from cache', 'consistent gets from cache', 'physical
reads cache');
Using the values in the output of the query, calculate the hit ratio
for the buffer cache with the following formula:
1 - (('physical reads cache') / ('consistent gets from cache' + 'db block
gets from cache')
ASMM
 Configuration, set following parameters in parameter file
 STATISTICS_LEVEL=TYPICAL OR ALL [TYPICAL-collection only major
database statistics ALL- collection of all statistics, database + OS]
 SGA_TARGET=<some value>
 SGA_MAX_SIZE=<max size>
The SGA_TARGET will be limited by the SGA_MAX_SIZE value. The
SGA_MAX_SIZE cannot be modified dynamically
SQL> alter system set sga_target=100M;
System altered.
SQL> show parameter sga
NAME TYPE VALUE
----------------------------- ----------- ----------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 164M
sga_target big integer 164M
SQL> select component, current_size, min_size, user_specified_size from
v$sga_dynamic_components;
DEFAULT buffer cache 24 24 24
ASMM contd..
 have any free memory available to SQL> select current_size/1024/1024
grow the dynamic sizes? "CURRENT_SIZE" from
SQL> select * from v$sga_dynamic_free_memory;
v$sga_dynamic_free_memory;
CURRENT_SIZE CURRENT_SIZE
----------------------- -------------------
0 136
SQL> alter system set
sga_target=164M; So you dispose now of 136M free for SGA
System altered. expansion.
SQL> show parameter sga
NAME TYPE VALUE

------------------------------------ ----------- -----------
pre_page_sga boolean FALSE
sga_max_size big integer 300M
Increase/reduce the SGA_TARGET
 You have the means to change
SQL> select component,
dynamically the size of the sga_target.
current_size/1024/1024
"CURRENT_SIZE", min_size/1024/1024
SQL> alter system set
"MIN_SIZE",
sga_target=200M;
user_specified_size/1024/1024
"USER_SPECIFIED_SIZE" from
System altered.
v$sga_dynamic_components;
SQL> show parameter sga COMPONENT CURRENT_SIZE
MIN_SIZE USER_SPECIFIED_SIZE
NAME TYPE VALUE ------------------------------ ------------ ----------
------------------------------------ ----------- ----- -------------------
pre_page_sga boolean FALSE DEFAULT buffer cache 60
sga_max_size big integer 300M 24 24
DB_CACHE_SIZE has grown from
24M to 60M.
Viewing information about Dynamic Resize Operations
The following views provide information about dynamic SGA resize operations:
 V$SGA_CURRENT_RESIZE_OPS: Information about SGA resize operations that are
currently in progress. An operation can be a grow or a shrink of a dynamic SGA
component.
 V$SGA_RESIZE_OPS: Information about the last 400 completed SGA resize
operations. This does not include any operations currently in progress.
 V$SGA_DYNAMIC_COMPONENTS: Information about the dynamic components in
SGA. This view summarizes information based on all completed SGA resize
operations since startup.
 V$SGA_DYNAMIC_FREE_MEMORY: Information about the amount of SGA memory
available for future dynamic SGA resize operations.
Determining which segments have many Buffers in the pool
 The V$BH view shows the data object ID of all blocks that currently reside in
the SGA
COLUMN OBJECT_NAME FORMAT A40
COLUMN NUMBER_OF_BLOCKS FORMAT 999,999,999,999
SELECT o.OBJECT_NAME, COUNT(*) NUMBER_OF_BLOCKS FROM
DBA_OBJECTS o, V$BH bh WHERE o.DATA_OBJECT_ID = bh.OBJD AND o.OWNER !=
'SYS' GROUP BY o.OBJECT_NAME ORDER BY COUNT(*);
KEEP POOL
 If there are certain segments in your application that are referenced frequently, then
store the blocks from those segments in a separate cache called the KEEP buffer pool
 Memory is allocated to the KEEP buffer pool by setting the parameter DB_KEEP_CACHE_SIZE to
the required size
 The memory for the KEEP pool is not a subset of the default pool
 DBAs can determine which tables are candidates using v$BH view
 By keeping frequently accessed objects in memory, we can avoid I/O
 Size of the KEEP pool can determined by adding blocks of the objects you want to
keep in memory, use DBA_TABLES.BLOCKS and DBA_EMPTY_BLOCKS to
compute number of blocks
Memory tuning
 RECYCLE Pool
 Configure a RECYCLE buffer pool for blocks belonging to those segments
that you do not want to remain in memory
 The RECYCLE pool is good for segments that are scanned rarely or are not
referenced frequently
 SHARED POOL
 Library Cache Statistics
 RELOADS
 INVALIDATIONS
 free memory in the shared pool at peak times -V$SGASTAT
 To examine each namespace individually, use the following query:
 SELECT NAMESPACE, PINS, PINHITS, RELOADS, INVALIDATIONS FROM
V$LIBRARYCACHE ORDER BY NAMESPACE;
 To calculate the library cache hit ratio, use the following formula:
Library Cache Hit Ratio = sum(pinhits) / sum(pins)

 SELECT * FROM V$SGASTAT WHERE NAME = 'free memory' AND POOL
= 'shared pool';
Memory tuning
 Dictionary Cache Statistics

 PARAMETER
Identifies a particular data dictionary item. For each row, the value in this
column is the item prefixed by dc_. For example, in the row that contains
statistics for file descriptions, this column has the value dc_files.
 GETS
Shows the total number of requests for information on the corresponding item.
For example, in the row that contains statistics for file descriptions, this column
has the total number of requests for file description data.
 GETMISSES
Shows the number of data requests which were not satisfied by the cache,
requiring an I/O.
 MODIFICATIONS
Shows the number of times data in the dictionary cache was updated.
Memory tuning
 CURSOR_SHARING
 CURSOR_SHARING to EXACT allows SQL statements to share the SQL area
only when their texts match exactly. This is the default behavior
 CURSOR_SHARING has been set to SIMILAR or FORCE -Oracle first checks the
shared pool to see if there is an identical statement in the shared pool. If an
identical statement is not found, then Oracle searches for a similar statement in
the shared pool. If the similar statement is there, then the parse checks continue
to verify the executable form of the cursor can be used. If the statement is not
there, then a hard parse is necessary to generate the executable form of the
statement.
 Log Buffer Statistics
 The statistic REDO BUFFER ALLOCATION RETRIES reflects the number of times
a user process waits for space in the redo log buffer
 SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME = 'redo buffer
allocation retries'; The
value of redo buffer allocation retries should be
near zero over an interval
Memory tuning
 PGA Memory Management

 Sort-based operators, such as ORDER BY, GROUP BY, ROLLUP, and window functions
 Hash-join
 Bitmap merge
 Bitmap create
 Write buffers used by bulk load operations
ASMM to MANUAL
 can revert the ASMM mechanism at any time by
setting the SGA_TARGET value to 0
SQL> alter system set sga_target=0;

Performance Tuning: by Suresh.R

Uploaded by

Copyright:

Available Formats

You might also like

Performance Tuning: by Suresh.R

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Performance Tuning: by Suresh.R

Uploaded by

Copyright:

Available Formats

Performance tuning

Block contention corrective actions depends on the type of block

 it is worth tracing those sessions which are

Locks Mode Compatibility Table

SQL> select object_name from dba_objects where object_id=50714;

SQL> select * from v$lock;

ADDR KADDR SID TY ID1 ID2 LMODE REQUEST CTIME BLOCK

ROW_WAIT_OBJ# ROW_WAIT_FILE# ROW_WAIT_BLOCK# ROW_WAIT_ROW#

NAME TYPE VALUE

Library Cache Hit Ratio = sum(pinhits) / sum(pins)

 Dictionary Cache Statistics

 PGA Memory Management

You might also like