Database Tuning Methodology

Michael R. Ault OCP Certified DBA DMR Consulting Group

Database Tuning Methodology

Begin With Physical Design
Proper use of RAID Proper Controller/Stripe Usage OFA (Optimal Flexible Architecture Normalization/Denormalization Sizing and Placement DB block size and other parameters Optimizer Mode

Database Tuning Methodology

RAID Usage
RAID 0/1 - Striped and Mirrored (or shadowed) Good for all types of files, both read and write RAID5 - Uses striping combined with parity disk Good for read intensive files, some write penalties

Database Tuning Methodology

Proper Controller /Stripe Usage
Spread across controllers, not just disks Use as many disks as is feasible (4 minimum) Stripe size a multiple of db_block_read_count Striping, db_writers, PQO all go hand-in-hand

Database Tuning Methodology

Disk Controller 1

4-disk Stripe Set

Example of Improper Striping

Database Tuning Methodology

Disk Controllers

4-disk Stripe Set

Example of proper striping

Database Tuning Methodology

OFA (Optimal Flexible Architecture)
A standardized method of file placement A step towards isolation of function Requires analysis of usage patterns to properly implement Allows for flexibility in file placement

Database Tuning Methodology

ORACLE_BASE /var/opt/oracle ORACLE_HOME /var/opt/oracle/product/7.3.4 /oracle1/ADMIN/dbname /DATA/dbname /CONTROL/dbname /LOG/dbname /LOCAL/dbname /TAR/dbaname

Database Tuning Methodology

/oracle1/ADMIN/dbname bdump udump cdump arch export adhoc create pfile logbook

Database Tuning Methodology

Normalization
Most databases attempt to use 3rd normal form Every attribute must relate to t whole primary key and only to the primary key Good in theory but hard to implement 100% Based in preventing insert/update/delete anomalies

Database Tuning Methodology

Denormalization
Used to real world the data structure Usually items that are always retrieved together will be placed in the same table and the keys combined Usually used for report type information As long as allowance is made for any possible anomalous behavior ok to do

Database Tuning Methodology

Sizing First must size tables, indexes and clusters Then size tablespaces SWAG avg_row_len*num_rows*1.5 (tables and clusters) avg_key_len*num_keys*1.5 (indexes) More accurate Use Admin guide or my book! Always size for 1 year as a minimum If using PQO allow enough freespace in an index tablespace for n*num_pqo_slaves initial extents

Database Tuning Methodology

DB_BLOCK_SIZE and Other Parameters
DB_BLOCK_SIZE is not able to be reset without rebuilding the database, size it as large as you ever will need Set other MAX parameters to what makes sense, but they are able to be reset with a control file rebuild

Database Tuning Methodology

Optimizer Mode
CHOOSE or RULE I have used CHOOSE since 7.2 CHOOSE dependent on analyzed tables Can get to 70% of the performance for nonoptimized code Good for ad hoc or changing environments

Database Tuning Methodology

Optimizer Mode (Cont.)
RULE
Good for well known predictable environments Good for non-ad-hoc environments Requires a more hands-on DBA

Database Tuning Methodology

Tune Application Statements
Full table scans Proper Index Usage HINTS Bind Variables Use PL/SQL

Database Tuning Methodology

Full Table Scans
Used to be always bad Now if scanning size/PQS is smaller than an index scan makes sense to FTS If a table is large and must be FTS, then consider manually striping it in V7 or use O8 table partitioning If not using PQO, FTS is bad If using CHOOSE analyze or FTS will result

Database Tuning Methodology

Full Table Scans (cont.)
Use EXPLAIN PLAN Can do automatically using: SET AUTOTRACE ON EXPLAIN Can get statement timing using SET TIMING ON Can use both together

Database Tuning Methodology

Example using AUTOTRACE:
DCAR: SET AUTOTRACE ON EXPLAIN DCARS: select * from dba_running_stats where rownum<10 .(rows not shown) 9 rows selected. Execution Plan ---------------------------------------------------------SELECT STATEMENT COUNT STOPKEY TABLE ACCESS FULL DBA_RUNNING_STATS

Database Tuning Methodology

Example Using SET TIMIMG
DCARS:set timing on DCARS:r 1* select * from dba_running_stats where rownum<10 . (rows not shown) 9 rows selected. real: 1282

Time is in 1/100 seconds (7.2 and 7.3)

Database Tuning Methodology

TKPROF
Used against trace files Must set SQL tracing on either at database or session level Should set TIMED_STATISTICS to true Gives explain plan, timing and row counts as well as CPU related stats

Database Tuning Methodology

PQO (Parallel Query Option)
Use in terminal 7.2 and 7.3 releases If full table scans are have tos then do them in parallel with stiping or partitions In O8 everything is parallel if partitioning or striping is used. Stripe to the same number of disks as degree of parallel or partition to as many disks

Database Tuning Methodology

HINTS
Hints allow control of the optimizer Tells optimizer to use a specific action Can be used with DELETE, SELECT, UPDATE commands Placed as a comment usually after the keywords DELETE, SELECT, UPDATE

Database Tuning Methodology

HINTS (cont.) Example: SELECT /*+ hint */ <body of select>;

Database Tuning Methodology

Hint + Meaning Must be right after comment indicator, tells Oracle this is a list of hints. ALL_ROWS Use the cost based approach for best throughput. CHOOSE Default, if statistics are available will use cost, if not, rule. FIRST_ROWS Use the cost based approach for best response time. Hint RULE Meaning Use rules based approach, this cancels any other hints specified for this statement. This will not be available after ORACLE7. Access Method Hints: CLUSTER(table) This tells Oracle to explicitly do a cluster scan to access the cluster

Database Tuning Methodology

Hint FULL(table) Meaning This tells the optimizer to do a full scan of the specified table. Tells Oracle to explicitly choose the hash access method for the table. Transforms a NOT IN subquery to a hash anti-join. Forces a rowid scan of the specified table. Hint Meaning INDEX(table [index])Forces an index scan of the specified table using thespecified index(s). If a list of indexes is specified, the optimizer chooses the one with the lowest cost. If no index is specified then the optimizer chooses the available index for the table with the lowest cost.

HASH(table)

HASH_AJ(table)

ROWID(table)

Database Tuning Methodology

Hint Meaning INDEX_ASC (table [index]) Same as INDEX only performs an ascending search of the indexchosen, this is functionally identical to the INDEX statement. INDEX_DESC(table [index]) Same as INDEX except performs a descending search. If more than one table is accessed, this is ignored. Hint Meaning INDEX_COMBINE(table index) Combines the bitmapped indexes on the table if the cost shows that to do so would give better performance. INDEX_FFS(table index) Perform a fast full index scan rather than a table scan. MERGE_AJ (table) Transforms a NOT IN subquery into a merge anti-join.

Database Tuning Methodology

Hint USE_CONCAT Meaning Combines OR conditions in the WHERE clause into a compound query using the UNION ALL set operator. AND_EQUAL(table index index [index index index]) Causes a merge on several single column indexes. Two must be specified, five can be. Hints for join orders Hint Meaning ORDERED This hint forces tables to be joined in the order specified. If you know table X has fewer rows, then ordering it first may speed execution in a join. STAR Forces the largest table to be joined last using a nested_loops join on the index.

Database Tuning Methodology

Hints for Join Operations: Hint Meaning NO_MERGE (table) This causes Oracle to join each specified table with another row source without a sortmerge join USE_HASH (table)This causes Oracle to join each specified table with another row source with a hash join Hint USE_NL(table) Meaning This operation forces a nested loop using the specified table as the controlling table. USE_MERGE(table,[table,...]) This operation forces a sort-merge-join operation of the specified tables.

Database Tuning methodologies

Hints for Parallel Operations Hint Meaning APPEND This specifies that data is to be or not to be appended to the NOAPPEND end of a file rather than into existing free space. Use only with INSERT commands. NOPARALLEL (table) This specifies the operation is not to be done in parallel. Hint Meaning PARALLEL(table, instances) This specifies the operation is to be done in parallel. PARALLEL_INDEX Allows parallelization of a fast full index scan on any index.

Database Tuning Methodology

Other Hints: Hint CACHE
Meaning The blocks retrieved for the table in the hint are placed at the MRU end of the LRU list when the table is FTS. The blocks retrieved for the table in the hint are placed at the LRU end of the LRU list when the table is FTS.

Hint PUSH_SUBQ

Meaning This causes nonmerged subqueries to be evaluated at the earliest possible point in the execution plan.

NOCACHE

Database Tuning Methodology

Use Bind Variables
Creates reusable statements Prevent filling up the shared pool with garbage SQL Any difference in a SQL statement makes it a new statement and thus non-reusable Helps prevent pool thrashing

Database Tuning Methodology

User Text Executes ---------- ------------------------------------------ -------DCARS SELECT SUM(item_amt_mtd)FROM billsum WHERE 1 region_code= '32' AND region_dealer_num = '0725' AND catalog_number = 'PARTS' AND year_num >=(TO_NUMBER(TO_CHAR(sysdate, 'YYYY')) - 2) AND year_num<= TO_NUMBER( TO_CHAR(sysdate, 'YYYY')) GROUP BY year_num ORDER BY year_num DESC

There where several hundred copies of the above SQL in the SGA with the only diference being in the region_code and region_dealer_num

Database Tuning Methodology

User Text Executes --------------- ----------------------------------- -------DCARS Select Descr from CODE 10372 where Code_Table_Name = :1 and Code = :2

Notice the above code has been reused 10372 times. This is because of the use of bind variables (:1 and :2)

Database Tuning Methodology

Use PL/SQL Tables instead of database tables for temporary holding
Memory IO is several orders of magnitude faster than disk IO Use of UTL_FILE allows formatting of output to file Use of DBMS_OUTPUT is also possible with anonymous PL/SQL

Database Tuning Methodology

Tune Memory
On some platforms Oracle must be relinked to go bigger than ~250 meg You shouldnt exceed 50-60% of available memory Size kernel parameters properly (shared segment size) Size swap and paging files properly (4 times physical memory)

Database Tuning Methodology

Tune Memory (cont)
Set semaphores properly Set open file limit and number of processes properly Set process private memory size properly I suggest setting these to their maximum for your configuration.

Database Tuning Methodology

SGA Sizing
DB_BLOCK_BUFFERS SHARED_POOL_SIZE LARGE_POOL_SIZE (Oracle8) Log Buffers

Database Tuning Methodology

DB_BLOCK_BUFFERS
Usually 1/100 to 1/200 of full DB physical size so for 20 gig 200 to 400 megabytes Total SGA not more than 50-60% of segment size or failure to fork errors may result

SHARED_POOL_SIZE
Depends on system usage, ad-hoc requires more, all stored package and canned query requires less.

Database Tuning Methodology

SHARED_POOL_SIZE (cont)
ORA-04031, ORA-07445 errors can result from a too-small shared pool Performance that is peak at startup and declines also symptom of too small or trashing shared pool Shared pool is for sharable code, not throwaway SQL Pin large/frequently used objects

Database Tuning Methodology

LOG_BUFFERS and LOG_BUFFER_SIZE
usually I size at redo log size or a fraction of redo log size, the default is too small The number of buffers is usually ok at default Watch redo log waits and increase log buffers/size until they minimize Waits can also be reduced by adding more redo logs

Database Tuning Methodology

When are DB block Buffers sized correctly?
When buffer hit ratio is high AND when db block waits are low A high hit ratio doesnt mean there is no contention for blocks Use the X$CBRBH and X$CBCBH tables and the DB_BLOCK_LRU_EXTENTDED_STATISTICS and DB_BLOCK_LRU_STATISTICS to monitor block hits gained or lost by adding/removing buffers

Database Tuning Methodology

Tune Proactively
No users in SYSTEM tablespace No rollbacks in non-rollback tablespaces Temporary segments in temporary tablespaces Verify space before you start Allow for parallel builds Require new SQL to be fully analyzed and explained

Database Tuning Methodology

Tune Proactively (Cont.)
Validate new indexes use the provided UTLDIDXS.SQL , UTLOIDXS.SQL and UTLSIDXS.SQL scripts. Limit ad hoc SQL usage Analyze before it is needed Periodically use UTLBSTAT/UTLESTAT or automated sampling scripts

Database Tuning Methodology

General Gotchas
Watch out for C_TS# corruption bug Watch for disable/enable constraint errors
Index storage and table definitions are not persistent and must be restated on enable

Database Tuning Methodology

Owner Index ---------- -------------------AGCD SYS_C001131 SYS_C001133 SYS_C001134 SYS_C001135 SYS_C001136 SYS_C001162 . USR_PK XRF_PK CAT_GRA Tablespace ---------DATA_TS

INDEX_TS

Database Tuning Methodology

Proactive Tuning
Be sure you have enough and properly sized redo logs on separate platters or controllers Be sure one segment per DML user in rollback segments Watch alert log Monitor file space usage One some systems SQLTRACE is turned on

Database Tuning Methodology

Inherited Applications
Immediately check sizing, extents and file placement Check chaining and fragmentation Check indexes for browning Monitor SGA usage and shared pool usage Library Hit Ratios

Database Tuning Methodology

Browning is calculated by using the calculation:
(del_lf_rows_len/decode((lf_rows_len+ del_lf_rows_len),0,1,lf_rows_len+del_lf_rows_len))*100

Database Tuning Methodology

Example Browning Report: NAME Deleted Bytes Filled Bytes Browned -------------------- ------------- ------------ ------I_ARHIST_3 15,091,329 361,274,732 4.01 I_AR_TURN_DEALER 394,488 823,958 32.38 I_BUNDLE_BO_2 19 95 16.67 I_BUNDLE_RESERVE_BUND 9,705 52,203 15.68 I_BUNDLE_RESERVE_CATVER 17,736 67,179 20.89 I_CHECKPNT_1 19 19 50.00 I_CURRENT_SETTLEMENT 1,125 1,290 46.58

Database Tuning Methodology

Library Hit Ratio
Library area suffers contention Use:
select namespace, gets, gethitratio*100 gethitratio, pins, pinhitratio*100 pinhitratio, RELOADS, INVALIDATIONS from v$librarycache

Database Tuning Methodology

Example Report:
Get Pin Library Object Gets Hit% Pins Hit% Reloads Invalid --------------- ------- ----- --------- ------ ------- ------SQL AREA 439,864 92.83 2,997,952 97.60 5,338 607 TABLE/PROCEDURE 127,146 97.31 1,455,108 99.66 1,049 0 BODY 4,459 98.45 4,468 98.19 12 0 TRIGGER 9,937 99.22 9,937 99.22 0 0 INDEX 361 1.11 361 1.11 0 0 CLUSTER 33 48.48 21 42.86 0 0 OBJECT 0100.00 0 100.00 0 0 PIPE 21,918 99.98 24,220 99.98 0 0

Database Tuning Methodology

Latch Contention
Monitor using the v$latch and v$latchname views:
SELECT a.name,100.*b.sleeps/b.gets ratio1, 100.*b.immediate_misses/decode((b.immediate_misses+ b.immediate_gets),0,1) ratio2 FROM v$latchname a, v$latch b WHERE a.latch# = b.latch# AND b.sleeps > 0;

Database Tuning Methodology

Example Output
NAME RATIO1 RATIO2 ------------------------------ --------- --------cache buffers chains .0000 row cache objects .0007 shared pool .0299 .0000 library cache .0003

Database Tuning Methodology

Block Contention
SELECT class,sum(count) total_waits, sum(time) total_time FROM v$waitstat GROUP BY class;

Database Tuning Methodology

Example Ouptut
CLASS TOTAL_WAITS TOTAL_TIME ------------------ ----------- ---------data block 2485 1873 undo block 18 1 undo header 4 3

Database Tuning Methodology

Check Environment For Proper Settings
The oraenv program does this on UNIX Checks:
OS version Ulimit settings Swap settings Disk mounts Disk freespace Environment settings System Tables Semaphores Shared memory Oratab entries Tracing settings

Database Tuning Methodology

Shared pool usage
select sum(a.bytes)/(1024*1024) shared_pool_used, max(b.value)/(1024*1024) shared_pool_size, (max(b.value)/(1024*1024))-(sum(a.bytes)/(1024*1024)) shared_pool_avail, (sum(a.bytes)/max(b.value))*100 shared_pool_pct from v$sgastat a, v$parameter b where a.name in ( 'reserved stopper', 'table definiti', 'dictionary cache', 'library cache', 'sql area', 'PL/SQL DIANA', 'SEQ S.O.') and b.name='shared_pool_size';

Database Tuning Methodology

Example Output
SHARED POOL USED -----63.87 SHARED POOL SIZE -----135.00 SHARED POOL AVAIL -----71.13 SHARED POOL PCT -----47.31

Database Tuning Methodology

If shared pool greater than 90% may need size increase Size needs could be due to garbage SQL SQL_GARBAGE view helps to sort this out

Database Tuning Methodology

SQL_GARBAGE View
create or replace view sql_garbage as select b.username users, sum(a.sharable_mem+ a.persistent_mem) Garbage, to_number(null) good from sys.v_$sqlarea a, dba_users b where (a.parsing_user_id = b.user_id and a.executions<=1) group by b.username

union select b.username users, to_number(null) garbage, sum(c.sharable_mem+ c.persistent_mem) Good from dba_users b, sys.v_$sqlarea c where (b.user_id=c.parsing_use r_id and c.executions>1) group by b.username;

Database Tuning Methodology

Example Select against SQL_GARBAGE
column garbage format 9,999,999,999 heading 'Non-Shared SQL' column good format 9,999,999,999 heading 'Shared SQL' column good_percent format 999.99 heading 'Percent Shared' break on report compute sum of garbage on report compute sum of good on report compute avg of good_percent on report spool rep_out\sql_garbage select a.users,a.garbage, b.good, (b.good/(b.good+a.garbage))*100 good_percent from sql_garbage a, sql_garbage b where a.users=b.users and a.garbage is not null and b.good is not null; spool off

Database Tuning Methodology

Example Outptut
USERS Non-Shared SQL Shared SQL Percent Shared ---------------- -------------- -------------- -------------AULTM 502,520 606,937 54.71 DCARS 18,319,609 21,081,924 53.51 HEARONB 14,966 19,185 56.18 MCNAIRT 39,956 212,468 84.17 QDBA 26,329 1,949,775 98.67 RCAPS 3,636,691 6,993,564 65.79 RCOM 269,398 85,575 24.11 REPORTS1 156,824 292,641 65.11 SECURITY_ADMIN 20,583 8,137 28.33 SYS 63,034 1,165,528 94.87 -------------- -------------- -------------avg 62.54 sum 23,049,910 32,415,734

Database Tuning Methodology

Shared Pool Thrashing
Caused by excessive garbage SQL Results in repeated scans of SQL hash codes When there are several thousand SQL areas that are not reusable, this impacts performance Happens in Ad-Hoc environments where bind variables arent used

Database Tuning Methodology

Pool Used 150
Meg

100 50 0

121

181

241

301

361

421

481

541

601

Measurement

Pool Used

661

61

Database Tuning Methodology

Perf ormance 400 300 200 100 0 Measurem ent Perf ormance

1/100 sec

Pool Usage 140 120 100

Meg

80 60 40 20 0 M e as ure m e nt

Pool Usage

Database Tuning Methodology

Summary
Tune OS and file layout first Tune application statements Tune memory Tune Contention Inherited applications need special attention, look at structure and memory usage (usually you are stuck with application)