IntroductiontoEXPLAINPLAN

TheEXPLAINPLANstatementdisplaysexecutionplanschosenbytheOracleoptimizerforSELECT,UPDATE,
INSERT,andDELETEstatements.Astatement'sexecutionplanisthesequenceofoperationsOracleperformsto
executethestatement.Thecomponentsofexecutionplansinclude:
Anorderingofthetablesreferencedbythestatement
Anaccessmethodforeachtablementionedinthestatement
Ajoinmethodfortablesaffectedbyjoinoperationsinthestatement
EXPLAINPLANoutputshowshowOracleexecutesSQLstatements.EXPLAINPLANresultsalone,however,
cannotdifferentiatebetweenwelltunedstatementsandthosethatperformpoorly.Forexample,ifEXPLAINPLAN
outputshowsthatastatementusesanindex,thisdoesnotmeanthestatementrunsefficiently.Sometimesusing
indexescanbeextremelyinefficient.ItisthusbesttouseEXPLAINPLANtodetermineanaccessplanandlater
proveitistheoptimalplanthroughtesting.
Whenevaluatingaplan,alwaysexaminethestatement'sactualresourceconsumption.Forbestresults,usethe
OracleTraceorSQLtracefacilityandTKPROFtoexamineindividualSQLstatementperformance.
CreatingtheOutputTable
BeforeissuinganEXPLAINPLANstatement,createatabletoholditsoutput.Useoneofthefollowing
approaches:
RuntheSQLscriptUTLXPLAN.SQLtocreateasampleoutputtablecalledPLAN_TABLEinyourschema.The
exactnameandlocationofthisscriptdependsonyouroperatingsystem.PLAN_TABLEisthedefaulttableinto
whichtheEXPLAINPLANstatementinsertsrowsdescribingexecutionplans.
IssueaCREATETABLEstatementtocreateanoutputtablewithanynameyouchoose.Whenyouissuean
EXPLAINPLANstatementyoucandirectitsoutputtothistable.
AnytableusedtostoretheoutputoftheEXPLAINPLANstatementmusthavethesamecolumnnamesand
datatypesasthePLAN_TABLE:
CREATETABLEplan_table
(statement_idVARCHAR2(30),
timestampDATE,
remarksVARCHAR2(80),
operationVARCHAR2(30),
optionsVARCHAR2(30),
object_nodeVARCHAR2(128),
object_ownerVARCHAR2(30),
object_nameVARCHAR2(30),
object_instanceNUMERIC,
object_typeVARCHAR2(30),
optimizerVARCHAR2(255),
search_columnsNUMERIC,
idNUMERIC,
parent_idNUMERIC,
positionNUMERIC,
costNUMERIC,
cardinalityNUMERIC,
bytesNUMERIC,
other_tagVARCHAR2(255)

otherLONG)
DisplayingPLAN_TABLEOutput
Displaythemostrecentplantableoutputusingthescripts:
UTLPLS.SQLToshowplantableoutputforserialprocessing.
UTLXPLP.SQLToshowplantableoutputwithparallelexecutioncolumns.
TherowsourcecountvaluesinEXPLAINPLANoutputidentifythenumberofrowsprocessedbyeachstepinthe
plan.Thishelpsyouidentifyinefficienciesinthequery,forexample,therowsourcewithanaccessplanthatis
performinginefficientoperations.
ColumnDescription
STATEMENT_ID
ThevalueoftheoptionalSTATEMENT_IDparameterspecifiedintheEXPLAINPLANstatement.
TIMESTAMP
ThedateandtimewhentheEXPLAINPLANstatementwasissued.
REMARKS
Anycomment(ofupto80bytes)youwishtoassociatewitheachstepoftheexplainedplan.Ifyouneedtoaddor
changearemarkonanyrowofthePLAN_TABLE,usetheUPDATEstatementtomodifytherowsofthe
PLAN_TABLE.
OPERATION
Thenameoftheinternaloperationperformedinthisstep.Inthefirstrowgeneratedforastatement,thecolumn
containsoneofthefollowingvalues:
DELETESTATEMENT
INSERTSTATEMENT
SELECTSTATEMENT
UPDATESTATEMENT.
OPTIONS
AvariationontheoperationdescribedintheOPERATIONcolumn.
OBJECT_NODE
Thenameofthedatabaselinkusedtoreferencetheobject(atablenameorviewname).Forlocalqueriesusing
parallelexecution,thiscolumndescribestheorderinwhichoutputfromoperationsisconsumed.
OBJECT_OWNER
Thenameoftheuserwhoownstheschemacontainingthetableorindex.
OBJECT_NAME
Thenameofthetableorindex.

OBJECT_INSTANCE
Anumbercorrespondingtotheordinalpositionoftheobjectasitappearsintheoriginalstatement.The
numberingproceedsfromlefttoright,outertoinnerwithrespecttotheoriginalstatementtext.Viewexpansionwill
resultinunpredictablenumbers.
OBJECT_TYPE
Amodifierthatprovidesdescriptiveinformationabouttheobjectforexample,NONUNIQUEforindexes.
OPTIMIZER
Thecurrentmodeoftheoptimizer.
SEARCH_COLUMNS
Notcurrentlyused.
ID
Anumberassignedtoeachstepintheexecutionplan.
PARENT_ID
TheIDofthenextexecutionstepthatoperatesontheoutputoftheIDstep.
POSITION
TheorderofprocessingforstepsthatallhavethesamePARENT_ID.
OTHER
Otherinformationthatisspecifictotheexecutionstepthatausermayfinduseful.
OTHER_TAG
DescribesthecontentsoftheOTHERcolumn.
DISTRIBUTION
Storesthemethodusedtodistributerowsfrom"producer"queryserversto"consumer"queryservers.Formore
informationaboutconsumerandproducerqueryservers,pleaseseeOracle8iConcepts.
Pstart
Thestartpartitionofarangeofaccessedpartitions.Itcantakeoneofthefollowingvalues:
nindicatesthatthestartpartitionhasbeenidentifiedbytheSQLcompileranditspartitionnumberisgivenbyn.
KEYindicatesthatthestartpartitionwillbeidentifiedatexecutiontimefrompartitioningkeyvalues.
ROWLOCATIONindicatesthatthestartpartition(sameasthestoppartition)willbecomputedatexecutiontime
fromthelocationofeachrecordbeingretrieved.Therecordlocationisobtainedbyauserorfromaglobalindex.
INVALIDindicatesthattherangeofaccessedpartitionsisempty.
Pstop
Thestoppartitionofarangeofaccessedpartitions.Itcantakeoneofthefollowingvalues:

nindicatesthatthestoppartitionhasbeenidentifiedbytheSQLcompileranditspartitionnumberisgivenbyn.
KEYindicatesthatthestoppartitionwillbeidentifiedatexecutiontimefrompartitioningkeyvalues.
ROWLOCATIONindicatesthatthestoppartition(sameasthestartpartition)willbecomputedatexecutiontime
fromthelocationofeachrecordbeingretrieved.Therecordlocationisobtainedbyauserorfromaglobalindex.
INVALIDindicatesthattherangeofaccessedpartitionsisempty.
PID
ThestepthathascomputedthepairofvaluesofthePstartandPstopcolumns.
COST
Thecostoftheoperationasestimatedbytheoptimizer'scostbasedapproach.Forstatementsthatusetherule
basedapproach,thiscolumnisnull.Costisnotdeterminedfortableaccessoperations.Thevalueofthiscolumn
doesnothaveanyparticularunitofmeasurement,itismerelyaweightedvalueusedtocomparecostsof
executionplans.
CARDINALITY
Theestimatebythecostbasedapproachofthenumberofrowsaccessedbytheoperation.
BYTES
Theestimatebythecostbasedapproachofthenumberofbytesaccessedbytheoperation.
CreatinganExecutionPlan
ForanyspecificSQLqueryyoucanseeSQLexecutionplan.InSQL*Plusyoucanissuethe"setautotrace"
commandandthenissueyourSQLstatementtoseetheexecutionplan:
SQL>setautotracetraceonlyexplain
SQL>selectenamefromempwhereempno=12
ExecutionPlan

0SELECTSTATEMENTOptimizer=CHOOSE
10TABLEACCESS(BYINDEXROWID)OF'EMP'
21INDEX(UNIQUESCAN)OF'PK_EMP'(UNIQUE)
ForevenmoredetailedSQLexecutionplanstatistics,seetheTKPROF(SQLTrace)utility.
ReadinganOracleExecutionPlan
MygoalsforSQLtuningwithexecutionplansaresimple,"Fetchtherowswhileminimizingdatablocktouches":
Eliminatesuboptimallargetablefulltablescans:Ensurethatthefastestaccesspathtothedataischosen.The
executionplan"FULL"isthekey.
Usefastesttablejoinmethod:Theoptimizermustchooseintelligentlybetweennestedloopsjoins,hashjoinsand
startransformationjoinmethodsandthesearedisplayedintheexecutionplan.
Ensureoptimaltablejoiningorder:SQLwillrunfastestwhenthefirsttablejoinsdeliverthesmallestresultset.
Insum,Ireviewexecutionplanslookingfortuningopportunitiesasfollows:
Addindexes(especiallyfunctionbasedindexes)
Changetheoptimizerparms
EmployMaterializedViews
ImproveCBOstatistics(especiallyhistograms)
Cachehighusesmalltables&indexes
Tunethelibrarycache(cursor_sharing,etc)

Adjustsegmentstructure(largeblocksizesforindexrangescans,small
blocksizesforrandomOLTP)
GlobalTuningwithExecutionPlans
Myplan9iandplan10gscriptsareinvaluableforholisticSQLtuningbecausetheyexaminev$sql_planand
dba_hist_sql_planandplotsummaryexecutionplans,identifyingpossibleunnecessarylargetablefulltablescans
(thatmayresultfromamissingindex).
However,intherealworld,allSQLtuningexpertsmustbeproficientinreadingOracleexecutionplansand
understandthestepswithinaexplainplansandthesequencethatthestepsareexecuted.Tosuccessfully
understandanexplainplanyoumustbeabletoknowtheorderthattheplanstepsareexecuted.
Readinganexplainplanisimportantformanyreasons,andOracleSQLtuningexpertsrevealtheexplainplansto
checkmanythings:
Ensurethatthetableswillbejoinedinoptimalorder.
Determinethemostrestrictiveindexestofetchtherows.
Determinethebestinternaljoinmethodtouse(e.g.nestedloops,hashjoin).
DeterminethattheSQLisexecutingthestepsintheoptimalorder.
ReadingSQLexecutionplanshasalwaysbeendifficult,buttherearesometrickstohelpdeterminethecorrect
orderthattheexplainplanstepsareexecuted.
Orderingthesequenceofexecutionplansteps
SQLexecutionplansareinterpretedusingapreordertraversal(reversetransversal)algorithmwhichyouwillsee
below.Preordertraversalisafancywayofsaying:
1.Thattoreadanexecutionplan,lookfortheinnermostindentedstatement.Thatisgenerallythefirststatement
executedbutNOTalways!(seeexampleherewheretheinnermoststepisnotthefirststepexecuted).
2.Inmostcases,iftherearetwostatementsatthesamelevel,thefirststatementisexecutedfirst.
Inotherwords,executionplansarereadinsideout,startingwiththemostindentedoperation.Herearesome
generalrulesforreadinganexplainplan.
1.Thefirststatementistheonethathasthemostindentation.
2.Iftwostatementsappearatthesamelevelofindentation,thetopstatementisexecutedfirst.
Toseehowthisworks,takealookatthisplan.Whichoperationisfirsttoexecute?