8/10/2019 10g_perf

http://slidepdf.com/reader/full/10gperf 1/4

Database Tuning ImprovementsIn this section we will outline the new and improved features regardingdatabase and instance tuning. Oracle has introduced some good features

that enhance self-tuning and automated tuning. They are summarized asfollows:

User initiated Bu er !ache "lushing

#utomated !hec$point Tuning

!%U !osting

&ynamic 'ampling

Tuning Transaction (ecovery and )asy *onitoring

User initiated Buffer Cache Flushing

In the past+ we had a facility to ,ush the shared pool. The " U'' #()&%OO clause of # T)( '/'T)* lets you clear all data from theshared pool in the '0# 1system global area2. This is a useful feature toclear e3isting data and re-load fresh data. 4ow+ with 56 g + it becomespossible for users to ,ush the cache bu ers also.

Before 56 g + Oracle used to internally ,ush the bu er cache bloc$s asneeded. The " U' ' #()&%OO clause is useful if you need to measurethe performance of rewritten 7ueries or a suite of 7ueries from identicalstarting points. Use the following statement to ,ush the bu er cache.

SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

owever+ note that this clause is intended for use only on a test database.It is not advisable to use this clause on a production database+ becausesubse7uent 7ueries will have no hits+ only misses.

The following e3ample shows the e ect of ,ush bufer_cache . There are86+666 rows in the table 9 %O I!/()! .

SQL> update P L!CYREC set sum_assured " sum_assured # $%;

%&&&& r'(s updated.

SQL> )'mm*t;

C'mm*t )'mplete.

SQL> sele)t '. B+ECT_TYPE, su-str '. B+ECT_/AME,$,$&0 '-12ame , -.'-1d , -.status, )'u2t -.'-1d0 3r'm 45-6 -, d-a_'-1e)ts ' (6ere -.'-1d " '.data_'-1e)t_*d a2d '.'(2er " 7/YUSER7 8r'up -y '.'-1e)t_type, '.'-1e)t_2ame,-.'-1d, -.status ;

B+ECT_TYPE B+/AME B+9 STATUS C U/T B. B+90

8/10/2019 10g_perf

http://slidepdf.com/reader/full/10gperf 2/4

::::::::::: ::::::::::::: :::::: :::::: :::::::TABLE TEST$ <&%= 3ree TABLE P L!CYREC <& $ )r ?TABLE P L!CYREC <& $ 3ree @<=TABLE P L!CYREC <& $ )ur <?

SQL> alter system 3lus6 -u33er_)a)6e;

System altered.SQL> sele)t '. B+ECT_TYPE, su-str '. B+ECT_/AME,$,$&0 '-12ame , -.'-1d , -.status, )'u2t -.'-1d0 3r'm 45-6 -, d-a_'-1e)ts ' (6ere -.'-1d " '.data_'-1e)t_*d a2d '.'(2er " 7/YUSER7 8r'up -y '.'-1e)t_type, '.'-1e)t_2ame,-.'-1d, -.status ;

B+ECT_TYPE B+/AME B+9 STATUS C U/T B. B+90:::::::::: :::::::::::::: ::::: ::::: :::::::::::::TABLE TEST$ <&%= 3ree TABLE P L!CYREC <& $ 3ree &

Automated Checkpoint Tuning

!hec$-pointing is an important Oracle activity which records the highestsystem change number 1'!4+2 so that all data bloc$s less than or e7ual tothe '!4 are $nown to be written out to the data ;les. If there is a failureand then subse7uent cache recovery+ only the redo records containingchanges at '!41s2 higher than the chec$point need to be applied duringrecovery.

#s we are aware+ instance and crash recovery occur in two steps - cacherecovery followed by transaction recovery. &uring the cache recoveryphase+ also $nown as the rolling forward stage+ Oracle applies allcommitted and uncommitted changes in the redo log ;les to the a ected

data bloc$s. The wor$ re7uired for cache recovery processing isproportional to the rate of change to the database and the time betweenchec$points.

"ast-start recovery can greatly reduce the mean time to recover 1 *TT( 2+with minimal e ects on online application performance. Oraclecontinuously estimates the recovery time and automatically ad<usts thechec$-pointing rate to meet the target recovery time.

Oracle recommends using the ast_start_mttr_target initializationparameter to control the duration of startup after instance failure. =ith56 g + the Oracle database can now self-tune chec$-pointing to achieve

good recovery times with low impact on normal throughput. /ou no longerhave to set any chec$point-related parameters.

This method reduces the time re7uired for cache recovery and ma$es therecovery bounded and predictable by limiting the number of dirty bu ersand the number of redo records generated between the most recent redorecord and the last chec$point. #dministrators specify a target 1bounded2time to complete the cache recovery phase of recovery with the

8/10/2019 10g_perf

http://slidepdf.com/reader/full/10gperf 3/4

ast_start_mttr_target initialization parameter+ and Oracle automatically varies the incremental chec$point writes to meet that target.

The target_mttr ;eld of v$instance_recovery contains the *TT( target ine ect. The estimated_mttr ;eld of v$instance_recovery contains theestimated *TT( should a crash happen right away.

"or e3ample+

SQL> SELECT TAR ET_MTTR, EST!MATE9_MTTR, C PT_BL C _DR!TES FR M 5!/STA/CE_REC ERY;

TAR ET_MTTR EST!MATE9_MTTR C PT_BL C _DR!TES::::::::::: :::::::::::::: ::::::::::::::::: <? @@ @& $=?

=henever you set ast_start_mttr_target to a nonzero value+ and while*TT( advisory is O4+ Oracle !orporation recommends that you disable1set to 62 the following parameters:

L _CHEC P !/T_T!ME UT

L _CHEC P !/T_!/TER AL FAST_START_! _TAR ET

Because these initialization parameters either override ast_start_mttr_target or potentially drive chec$points more aggressivelythan ast_start_mttr_target does+ they can interfere with the simulation.

Easier Transaction Recover !onitoring

&uring the second phase of instance recovery+ Oracle rolls bac$ uncommitted transactions. Oracle uses two methods: >"ast-start on-demand rollbac$> and >fast-start parallel rollbac$>. Together+ these twofeatures help to increase the e iciency of the recovery phase.

Using the fast-start on-demand rollbac$ feature+ the re7uiredtransaction>s recovery is handled ;rst. If a user attempts to access a rowthat is loc$ed by a terminated transaction+ Oracle rolls bac$ only thosechanges necessary to complete the transaction? in other words+ it rollsthem bac$ on demand. !onse7uently+ new transactions do not have towait until all parts of a long transaction are rolled bac$.

In the fast-start parallel rollbac$ method+ the bac$ground process '*O4acts as a coordinator and rolls bac$ a set of transactions in parallel usingmultiple server processes. This feature is particularly useful when asystem has transactions that run a long time before committing+especially parallel I4')(T+ U%&#T)+ and &) )T) operations. '*O4automatically decides when to begin parallel rollbac$ and disperses thewor$ among several parallel processes.

/ou can monitor the progress of fast-start parallel rollbac$ by e3aminingthe v$ ast_start_servers and v$ ast_start_transactions views.v$ ast_start_servers provides information about all recovery processes

8/10/2019 10g_perf

http://slidepdf.com/reader/full/10gperf 4/4

performing fast-start parallel rollbac$ . v$ ast_start_transactions containsdata about the progress of the transactions.

There are three new columns in the 56 g release that assist monitoring.They are @I&+ %@I&+ and (!A')(A)('+ as shown in the description below.

SQL> des) 5FAST_START_TRA/SACT! /S /ame /ullG Type :::::::::::::::::::::::::::: :::::::: :::::::::::: US/ /UMBER SLT /UMBER SEQ /UMBER STATE ARCHAR@ $ 0 U/9 BL C S9 /E /UMBER U/9 BL C ST TAL /UMBER P!9 /UMBER CPUT!ME /UMBER PARE/TUS/ /UMBER PARE/TSLT /UMBER PARE/TSEQ /UMBER !9 RAD =0 P !9 RAD =0 RC SER ERS /UMBER

The above is an e3cerpt from the bestselling Oracle56g boo$ Oracle&atabase 56g 4ew "eatures by *i$e #ult+ *adhu Tumma and &aniel iu+published by (ampant Tech%ress.

*i$e #ult+ one of the world>s top Oracle e3perts+ has ;nally consented torelease his complete collection of more than 86 Oracle scripts+ coveringevery possible area of Oracle administration and management.

This is the de;nitive collection of Oracle monitoring and tuning scripts+ andit would ta$e thousands of hours to re-create this vast arsenal of scriptsfrom scratch.

*i$e has priced his collection of C8 scripts at DEF.F8+ less than a dime perscript. /ou can download them immediately at this lin$:

http:GGwww.rampant-boo$s.comGdownloadHadvHmonHtuning.htm