Upload
tarun-chaudhary
View
216
Download
0
Embed Size (px)
Citation preview
7/27/2019 DB_Tune.ppt
1/67
Database Tuning Methodology
Michael R. Ault
OCP Certified DBADMR Consulting Group
7/27/2019 DB_Tune.ppt
2/67
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
7/27/2019 DB_Tune.ppt
3/67
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 writepenalties
7/27/2019 DB_Tune.ppt
4/67
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
7/27/2019 DB_Tune.ppt
5/67
Database Tuning Methodology
1
Disk Controller
4-disk Stripe Set
Example of Improper Striping
7/27/2019 DB_Tune.ppt
6/67
Database Tuning Methodology
2
Disk Controllers
4-disk Stripe Set
1 43
Example of proper striping
7/27/2019 DB_Tune.ppt
7/67
Database Tuning Methodology
OFA (Optimal Flexible Architecture)
A standardized method of file placement
A step towards isolation of function
Requires analysis of usage patterns toproperly implement
Allows for flexibility in file placement
7/27/2019 DB_Tune.ppt
8/67
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
7/27/2019 DB_Tune.ppt
9/67
Database Tuning Methodology
/oracle1/ADMIN/dbname
bdump
udumpcdump
arch
export
adhoccreate
pfile
logbook
7/27/2019 DB_Tune.ppt
10/67
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
7/27/2019 DB_Tune.ppt
11/67
Database Tuning Methodology
Denormalization
Used to real world the data structure
Usually items that are always retrievedtogether will be placed in the same table andthe keys combined
Usually used for report type informationAs long as allowance is made for any possible
anomalous behavior ok to do
7/27/2019 DB_Tune.ppt
12/67
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 forn*num_pqo_slaves initial extents
7/27/2019 DB_Tune.ppt
13/67
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 youever will need
Set other MAX parameters to what makessense, but they are able to be reset with acontrol file rebuild
7/27/2019 DB_Tune.ppt
14/67
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 non-
optimized code Good for ad hoc or changing environments
7/27/2019 DB_Tune.ppt
15/67
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
7/27/2019 DB_Tune.ppt
16/67
Database Tuning Methodology
Tune Application Statements
Full table scans
Proper Index Usage HINTS
Bind Variables
Use PL/SQL
7/27/2019 DB_Tune.ppt
17/67
Database Tuning Methodology
Full Table Scans
Used to be always bad
Now if scanning size/PQS is smaller than anindex scan makes sense to FTS
If a table is large and must be FTS, then
consider manually striping it in V7 or use O8table partitioning
If not using PQO, FTS is bad
If using CHOOSE analyze or FTS will result
7/27/2019 DB_Tune.ppt
18/67
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
7/27/2019 DB_Tune.ppt
19/67
Database Tuning Methodology
Example using AUTOTRACE:DCAR: SET AUTOTRACE ON EXPLAIN
DCARS: select * from dba_running_stats where rownum
7/27/2019 DB_Tune.ppt
20/67
Database Tuning Methodology
Example Using SET TIMIMGDCARS:set timing on
DCARS:r
1* select * from dba_running_stats where rownum
7/27/2019 DB_Tune.ppt
21/67
Database Tuning Methodology
TKPROF
Used against trace files
Must set SQL tracing on either at database orsession level
Should set TIMED_STATISTICS to true
Gives explain plan, timing and row counts aswell as CPU related stats
7/27/2019 DB_Tune.ppt
22/67
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 inparallel 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
7/27/2019 DB_Tune.ppt
23/67
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 thekeywords DELETE, SELECT, UPDATE
7/27/2019 DB_Tune.ppt
24/67
Database Tuning Methodology
HINTS (cont.)
Example:
SELECT /*+ hint */
;
7/27/2019 DB_Tune.ppt
25/67
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 willuse cost, if not,
rule.
FIRST_ROWS Use the cost based
approach for best
response time.
Hint Meaning
RULE 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
7/27/2019 DB_Tune.ppt
26/67
Database Tuning Methodology
Hint Meaning
FULL(table) This tells the
optimizer to do a
full scan of
the specified table.
HASH(table) Tells Oracle to
explicitly choose
the hash access
method for the
table.HASH_AJ(table) Transforms a NOT
IN subquery to a
hash anti-join.
ROWID(table) Forces a rowid
scan of the
specified table.
Hint Meaning
INDEX(table [index])Forces an index
scan of the
specified table
using thespecifiedindex(s). If a list of
indexes is
specified, the
optimizer chooses
the one with thelowest cost. If no
index is specified
then the optimizer
chooses the
available index for
the table with thelowest cost.
7/27/2019 DB_Tune.ppt
27/67
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 asINDEX 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 scanrather than a table
scan.
MERGE_AJ (table) Transforms a NOT
IN subquery into a
merge anti-join.
7/27/2019 DB_Tune.ppt
28/67
Database Tuning Methodology
Hint Meaning
USE_CONCAT 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 speedexecution in a join.
STAR Forces the largest
table to be joined
last using a
nested_loops join
on the index.
7/27/2019 DB_Tune.ppt
29/67
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 sort-
merge join
USE_HASH (table) This causes Oracle
to join eachspecified table with
another row source
with a hash join
Hint Meaning
USE_NL(table) This operation
forces a nested
loop using the
specified table asthe controlling
table.
USE_MERGE(table,[table,...]) This
operation forces a
sort-merge-joinoperation of the
specified tables.
7/27/2019 DB_Tune.ppt
30/67
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 INSERTcommands.
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.
7/27/2019 DB_Tune.ppt
31/67
Database Tuning Methodology
Other Hints:
Hint Meaning
CACHE The blocks
retrieved for the
table in the hint are
placed at the MRU
end of the LRU list
when the table is
FTS.
NOCACHE The blocksretrieved for the
table in the hint
are placed at the
LRU end of the
LRU list when the
table is FTS.
Hint Meaning
PUSH_SUBQ This causes
nonmerged
subqueries to be
evaluated at theearliest possible
point in the
execution plan.
7/27/2019 DB_Tune.ppt
32/67
Database Tuning Methodology
Use Bind Variables
Creates reusable statements
Prevent filling up the shared pool with garbageSQL
Any difference in a SQL statement makes it anew statement and thus non-reusable
Helps prevent pool thrashing
7/27/2019 DB_Tune.ppt
33/67
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
7/27/2019 DB_Tune.ppt
34/67
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)
7/27/2019 DB_Tune.ppt
35/67
Database Tuning Methodology
Use PL/SQL Tables instead of databasetables for temporary holding
Memory IO is several orders of magnitudefaster than disk IO
Use of UTL_FILE allows formatting of output tofile
Use of DBMS_OUTPUT is also possible withanonymous PL/SQL
7/27/2019 DB_Tune.ppt
36/67
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 (sharedsegment size)
Size swap and paging files properly (4 timesphysical memory)
7/27/2019 DB_Tune.ppt
37/67
Database Tuning Methodology
Tune Memory (cont)
Set semaphores properly
Set open file limit and number of processesproperly
Set process private memory size properly
I suggest setting these to their maximum for yourconfiguration.
7/27/2019 DB_Tune.ppt
38/67
Database Tuning Methodology
SGA Sizing
DB_BLOCK_BUFFERS
SHARED_POOL_SIZE LARGE_POOL_SIZE (Oracle8)
Log Buffers
7/27/2019 DB_Tune.ppt
39/67
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 queryrequires less.
7/27/2019 DB_Tune.ppt
40/67
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 trashingshared pool
Shared pool is for sharable code, notthrowaway SQL
Pin large/frequently used objects
7/27/2019 DB_Tune.ppt
41/67
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 logbuffers/size until they minimize
Waits can also be reduced by adding moreredo logs
7/27/2019 DB_Tune.ppt
42/67
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 theDB_BLOCK_LRU_EXTENTDED_STATISTICS andDB_BLOCK_LRU_STATISTICS to monitor blockhits gained or lost by adding/removing buffers
7/27/2019 DB_Tune.ppt
43/67
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 startAllow for parallel builds
Require new SQL to be fully analyzed andexplained
7/27/2019 DB_Tune.ppt
44/67
Database Tuning Methodology
Tune Proactively (Cont.)
Validate new indexes use the provided
UTLDIDXS.SQL , UTLOIDXS.SQL and UTLSIDXS.SQLscripts.
Limit ad hoc SQL usage
Analyze before it is needed
Periodically use UTLBSTAT/UTLESTAT orautomated sampling scripts
7/27/2019 DB_Tune.ppt
45/67
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
7/27/2019 DB_Tune.ppt
46/67
Database Tuning Methodology
Owner Index Tablespace
---------- -------------------- ----------
AGCD SYS_C001131 DATA_TS
SYS_C001133
SYS_C001134
SYS_C001135
SYS_C001136
SYS_C001162
.
USR_PK
XRF_PK
CAT_GRA INDEX_TS
7/27/2019 DB_Tune.ppt
47/67
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
7/27/2019 DB_Tune.ppt
48/67
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
7/27/2019 DB_Tune.ppt
49/67
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
7/27/2019 DB_Tune.ppt
50/67
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.00I_CURRENT_SETTLEMENT 1,125 1,290 46.58
7/27/2019 DB_Tune.ppt
51/67
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
7/27/2019 DB_Tune.ppt
52/67
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 0OBJECT 0100.00 0 100.00 0 0
PIPE 21,918 99.98 24,220 99.98 0 0
7/27/2019 DB_Tune.ppt
53/67
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
FROMv$latchname a, v$latch b
WHERE
a.latch# = b.latch# AND b.sleeps > 0;
7/27/2019 DB_Tune.ppt
54/67
Database Tuning Methodology
Example Output
NAME RATIO1 RATIO2------------------------------ --------- ---------
cache buffers chains .0000
row cache objects .0007
shared pool .0299 .0000
library cache .0003
7/27/2019 DB_Tune.ppt
55/67
Database Tuning Methodology
Block Contention
SELECT class,sum(count) total_waits, sum(time)total_time
FROM v$waitstat
GROUP BY class;
7/27/2019 DB_Tune.ppt
56/67
Database Tuning Methodology
Example Ouptut
CLASS TOTAL_WAITS TOTAL_TIME------------------ ----------- ----------
data block 2485 1873
undo block 18 1
undo header 4 3
7/27/2019 DB_Tune.ppt
57/67
Database Tuning Methodology
Check EnvironmentFor Proper Settings
The oraenv programdoes 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
7/27/2019 DB_Tune.ppt
58/67
Database Tuning Methodology
Shared pool usageselect
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';
7/27/2019 DB_Tune.ppt
59/67
Database Tuning Methodology
Example Output
SHARED SHARED SHARED SHAREDPOOL POOL POOL POOL
USED SIZE AVAIL PCT
------ ------ ------ ------
63.87 135.00 71.13 47.31
7/27/2019 DB_Tune.ppt
60/67
Database Tuning Methodology
If shared pool greater than 90% may needsize increase
Size needs could be due to garbage SQL SQL_GARBAGE view helps to sort this out
7/27/2019 DB_Tune.ppt
61/67
Database Tuning Methodology
SQL_GARBAGE Viewcreate 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.executions1)
group by b.username;
7/27/2019 DB_Tune.ppt
62/67
Database Tuning Methodology
Example Select against SQL_GARBAGEcolumn 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
7/27/2019 DB_Tune.ppt
63/67
Database Tuning Methodology
Example OutptutUSERS Non-Shared SQL Shared SQL Percent Shared
---------------- -------------- -------------- --------------
AULTM 502,520 606,937 54.71
DCARS 18,319,609 21,081,924 53.51HEARONB 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.11SECURITY_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
7/27/2019 DB_Tune.ppt
64/67
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 impactsperformance
Happens in Ad-Hoc environments where bindvariables arent used
7/27/2019 DB_Tune.ppt
65/67
Database Tuning Methodology
Pool Used
0
50
100
150
161
121
181
241
301
361
421
481
541
601
661
Measurement
Meg
Pool Used
7/27/2019 DB_Tune.ppt
66/67
Database Tuning MethodologyPerformance
0
100
200
300
400
Measurement
1/100
sec
Performance
Pool Usage
0
20
40
60
80
100
120
140
Measurement
Meg
Pool Usage
7/27/2019 DB_Tune.ppt
67/67
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)