Explain Plan and Tkprof

2/27/2015 UseEXPLAINPLANandTKPROFToTuneYourApplications

http://www.dbspecialists.com/files/presentations/use_explain.html 1/23

UseEXPLAINPLANandTKPROFToTuneYourApplicationsby Roger Schrag Database Specialists, Inc.

About Database Specialists, Inc. Database Specialists, Inc. provides remote DBA services and onsite database support for your missioncritical Oracle systems. Since 1995, we have been providing Oracle database consulting in Solaris, HPUX,Linux, AIX, and Windows environments. We are DBAs, speakers, educators, and authors. Our team iscontinually recognized by Oracle, at national conferences and by leading trade publications. Learn moreabout our remote DBA, database tuning, andconsulting services. Or, call us at 4153440500 or 8886480500.

IntroductionInthispaperwelldiscussanoverviewoftheEXPLAINPLANandTKPROFfunctionsbuiltintotheOracle8iserverandlearnhowdevelopersandDBAsusethesetoolstogetthebestperformanceoutoftheirapplications.Welllookathowtoinvokethesetoolsbothfromthecommandlineandfromgraphicaldevelopmenttools.IntheremainderofthepaperwelldiscusshowtoreadandinterpretOracle8iexecutionplansandTKPROFreports.Welllookatlotsofexamplessothatyoullcomeawaywithasmuchpracticalknowledgeaspossible.

AnOverviewofEXPLAINPLANandTKPROFInthissectionwelltakeahighlevellookattheEXPLAINPLANandTKPROFfacilities:whattheyare,prerequisitesforusingthem,andhowtoinvokethem.Wewillalsolookathowthesefacilitieshelpyoutuneyourapplications.

ExecutionPlansandtheEXPLAINPLANStatement

BeforethedatabaseservercanexecuteaSQLstatement,Oraclemustfirstparsethestatementanddevelopanexecutionplan.TheexecutionplanisatasklistofsortsthatdecomposesapotentiallycomplexSQLoperationintoaseriesofbasicdataaccessoperations.Forexample,aqueryagainstthedepttablemighthaveanexecutionplanthatconsistsofanindexlookuponthedeptnoindex,followedbyatableaccessbyROWID.

TheEXPLAINPLANstatementallowsyoutosubmitaSQLstatementtoOracleandhavethedatabasepreparetheexecutionplanforthestatementwithoutactuallyexecutingit.Theexecutionplanismadeavailabletoyouintheformofrowsinsertedintoaspecialtablecalledaplantable.YoumayquerytherowsintheplantableusingordinarySELECTstatementsinordertoseethestepsoftheexecutionplanforthestatementyouexplained.Youmaykeepmultipleexecutionplansintheplantablebyassigningeachauniquestatement_id.Oryoumaychoosetodeletetherowsfromtheplantableafteryouarefinishedlookingattheexecutionplan.YoucanalsorollbackanEXPLAINPLANstatementinordertoremovetheexecutionplanfromtheplantable.

TheEXPLAINPLANstatementrunsveryquickly,evenifthestatementbeingexplainedisaquerythatmightrunforhours.Thisisbecausethestatementissimplyparsedanditsexecutionplansavedintotheplantable.TheactualstatementisneverexecutedbyEXPLAINPLAN.Alongthesesamelines,ifthestatementbeingexplainedincludesbindvariables,thevariablesneverneedtoactuallybebound.Thevaluesthatwouldbeboundarenotrelevantsincethestatementisnotactuallyexecuted.



YoudontneedanyspecialsystemprivilegesinordertousetheEXPLAINPLANstatement.However,youdoneedtohaveINSERTprivilegesontheplantable,andyoumusthavesufficientprivilegestoexecutethestatementyouaretryingtoexplain.Theonedifferenceisthatinordertoexplainastatementthatinvolvesviews,youmusthaveprivilegesonallofthetablesthatmakeuptheview.Ifyoudont,youllgetanORA01039:insufficientprivilegesonunderlyingobjectsoftheviewerror.

Thecolumnsthatmakeuptheplantableareasfollows:

NameNull?TypeSTATEMENT_IDVARCHAR2(30)TIMESTAMPDATEREMARKSVARCHAR2(80)OPERATIONVARCHAR2(30)OPTIONSVARCHAR2(30)OBJECT_NODEVARCHAR2(128)OBJECT_OWNERVARCHAR2(30)OBJECT_NAMEVARCHAR2(30)OBJECT_INSTANCENUMBER(38)OBJECT_TYPEVARCHAR2(30)OPTIMIZERVARCHAR2(255)SEARCH_COLUMNSNUMBERIDNUMBER(38)PARENT_IDNUMBER(38)POSITIONNUMBER(38)COSTNUMBER(38)CARDINALITYNUMBER(38)BYTESNUMBER(38)OTHER_TAGVARCHAR2(255)PARTITION_STARTVARCHAR2(255)PARTITION_STOPVARCHAR2(255)PARTITION_IDNUMBER(38)OTHERLONGDISTRIBUTIONVARCHAR2(30)

ThereareotherwaystoviewexecutionplansbesidesissuingtheEXPLAINPLANstatementandqueryingtheplantable.SQL*Pluscanautomaticallydisplayanexecutionplanaftereachstatementisexecuted.Also,therearemanyGUItoolsavailablethatallowyoutoclickonaSQLstatementinthesharedpoolandviewitsexecutionplan.Inaddition,TKPROFcanoptionallyincludeexecutionplansinitsreportsaswell.

TraceFilesandtheTKPROFUtility

TKPROFisautilitythatyouinvokeattheoperatingsystemlevelinordertoanalyzeSQLtracefilesandgeneratereportsthatpresentthetraceinformationinareadableform.AlthoughthedetailsofhowyouinvokeTKPROFvaryfromoneplatformtothenext,OracleCorporationprovidesTKPROFwithallreleasesofthedatabaseandthebasicfunctionalityisthesameonallplatforms.

Thetermtracefilemaybeabitconfusing.MorerecentreleasesofthedatabaseofferaproductcalledOracleTraceCollectionServices.Also,Net8iscapableofgeneratingtracefiles.SQLtracefilesareentirelydifferent.SQLtraceisafacilitythatyouenableordisableforindividualdatabasesessionsorfortheentireinstanceasawhole.WhenSQLtraceisenabledforadatabasesession,theOracleserverprocesshandlingthatsessionwritesdetailedinformationaboutalldatabasecallsandoperationstoatracefile.SpecialdatabaseeventsmaybesetinordertocauseOracletowriteevenmorespecificinformationsuchasthevaluesofbindvariablesintothetracefile.



SQLtracefilesaretextfilesthat,strictlyspeaking,arehumanreadable.However,theyareextremelyverbose,repetitive,andcryptic.Forexample,ifanapplicationopensacursorandfetches1000rowsfromthecursoronerowatatime,therewillbeover1000separateentriesinthetracefile.

TKPROFisaprogramthatyouinvokeattheoperatingsystemcommandpromptinordertoreformatthetracefileintoaformatthatismucheasiertocomprehend.EachSQLstatementisdisplayedinthereport,alongwithcountsofhowmanytimesitwasparsed,executed,andfetched.CPUtime,elapsedtime,logicalreads,physicalreads,androwsprocessedarealsoreported,alongwithinformationaboutrecursionlevelandmissesinthelibrarycache.TKPROFcanalsooptionallyincludetheexecutionplanforeachSQLstatementinthereport,alongwithcountsofhowmanyrowswereprocessedateachstepoftheexecutionplan.

TheSQLstatementscanbelistedinaTKPROFreportintheorderofhowmuchresourcetheyused,ifdesired.Also,recursiveSQLstatementsissuedbytheSYSusertomanagethedatadictionarycanbeincludedorexcluded,andTKPROFcanwriteSQLstatementsfromthetracedsessionintoaspoolfile.

HowEXPLAINPLANandTKPROFAidintheApplicationTuningProcess

EXPLAINPLANandTKPROFarevaluabletoolsinthetuningprocess.Tuningattheapplicationleveltypicallyyieldsthemostdramaticresults,andthesetwotoolscanhelpwiththetuninginmanydifferentways.

EXPLAINPLANandTKPROFallowyoutoproactivelytuneanapplicationwhileitisindevelopment.ItisrelativelyeasytoenableSQLtrace,runanapplicationinatestenvironment,runTKPROFonthetracefile,andreviewtheoutputtodetermineifapplicationorschemachangesarecalledfor.EXPLAINPLANishandyforevaluatingindividualSQLstatements.

Byreviewingexecutionplans,youcanalsovalidatethescalabilityofanapplication.Ifthedatabaseoperationsaredependentuponfulltablescansoftablesthatcouldgrowquitelarge,thentheremaybescalabilityproblemsahead.Ontheotherhand,iflargetablesareaccessedviaselectiveindexes,thenscalabilitymaynotbeaproblem.

EXPLAINPLANandTKPROFmayalsobeusedinanexistingproductionenvironmentinordertozeroinonresourceintensiveoperationsandgetinsightsintohowthecodemaybeoptimized.TKPROFcanfurtherbeusedtoquantifytheresourcesrequiredbyspecificdatabaseoperationsorapplicationfunctions.

EXPLAINPLANisalsohandyforestimatingresourcerequirementsinadvance.Supposeyouhaveanadhocreportingrequestagainstaverylargedatabase.RunningqueriesthroughEXPLAINPLANwillletyoudetermineinadvanceifthequeriesarefeasibleoriftheywillberesourceintensiveandwilltakeunacceptablylongtorun.

GeneratingExecutionPlansandTKPROFReportsInthissectionwewilldiscussthedetailsofhowtogenerateexecutionplans(bothwiththeEXPLAINPLANstatementandothermethods)andhowtogenerateSQLtracefilesandcreateTKPROFreports.

UsingtheEXPLAINPLANStatement

BeforeyoucanusetheEXPLAINPLANstatement,youmusthaveINSERTprivilegesonaplantable.Theplantablecanhaveanynameyoulike,butthenamesanddatatypesofthecolumnsarenotflexible.Youwillfindascriptcalledutlxplan.sqlin$ORACLE_HOME/rdbms/adminthatcreatesaplantablewiththenameplan_tableinthelocalschema.Ifyouusethisscripttocreateyourplantable,youcanbeassuredthatthetablewillhavetherightdefinitionforusewithEXPLAINPLAN.

Onceyouhaveaccesstoaplantable,youarereadytoruntheEXPLAINPLANstatement.Thesyntaxisasfollows:



EXPLAINPLAN[SETSTATEMENT_ID=][INTO]FOR;

IfyoudonotspecifytheINTOclause,thenOracleassumesthenameoftheplantableisplan_table.YoucanusetheSETclausetoassignanametotheexecutionplan.Thisisusefulifyouwanttobeabletohavemultipleexecutionplansstoredintheplantableatoncegivingeachexecutionplanadistinctnameenablesyoutodeterminewhichrowsintheplantablebelongtowhichexecutionplan.

TheEXPLAINPLANstatementrunsquicklybecauseallOraclehastodoisparsetheSQLstatementbeingexplainedandstoretheexecutionplanintheplantable.TheSQLstatementcanincludebindvariables,althoughthevariableswillnotgetboundandthevaluesofthebindvariableswillbeirrelevant.

IfyouissuetheEXPLAINPLANstatementfromSQL*Plus,youwillgetbackthefeedbackmessageExplained.AtthispointtheexecutionplanfortheexplainedSQLstatementhasbeeninsertedintotheplantable,andyoucannowquerytheplantabletoexaminetheexecutionplan.

Executionplansareahierarchicalarrangementofsimpledataaccessoperations.Becauseofthehierarchy,youneedtouseaCONNECTBYclauseinyourqueryfromtheplantable.UsingtheLPADfunction,youcancausetheoutputtobeformattedinsuchawaythattheindentinghelpsyoutraversethehierarchy.Therearemanydifferentwaystoformatthedataretrievedfromtheplantable.Noonequeryisthebest,becausetheplantableholdsalotofdetailedinformation.DifferentDBAswillfinddifferentaspectsmoreusefulindifferentsituations.

AsimpleSQL*Plusscripttoretrieveanexecutionplanfromtheplantableisasfollows:

REMREMexplain.sqlREM

SETVERIFYOFFSETPAGESIZE100

ACCEPTstmt_idCHARPROMPT"Enterstatement_id:"

COLidFORMAT999COLparent_idFORMAT999HEADING"PARENT"COLoperationFORMATa35TRUNCATECOLobject_nameFORMATa30

SELECTid,parent_id,LPAD('',LEVEL1)||operation||''||optionsoperation,object_nameFROMplan_tableWHEREstatement_id='&stmt_id'STARTWITHid=0ANDstatement_id='&stmt_id'CONNECTBYPRIORid=parent_idANDstatement_id='&stmt_id';

Ihaveasimplequerythatwewilluseinafewexamples.Wellcallthistheinvoiceitemquery.Thequeryisasfollows:



SELECTa.customer_name,a.customer_number,b.invoice_number,b.invoice_type,b.invoice_date,b.total_amount,c.line_number,c.part_number,c.quantity,c.unit_costFROMcustomersa,invoicesb,invoice_itemscWHEREc.invoice_id=:b1ANDc.line_number=:b2ANDb.invoice_id=c.invoice_idANDa.customer_id=b.customer_id;

Theexplain.sqlSQL*Plusscriptabovedisplaystheexecutionplanfortheinvoiceitemqueryasfollows:

IDPARENTOPERATIONOBJECT_NAME0SELECTSTATEMENT10NESTEDLOOPS21NESTEDLOOPS32TABLEACCESSBYINDEXROWIDINVOICE_ITEMS43INDEXUNIQUESCANINVOICE_ITEMS_PK52TABLEACCESSBYINDEXROWIDINVOICES65INDEXUNIQUESCANINVOICES_PK71TABLEACCESSBYINDEXROWIDCUSTOMERS87INDEXUNIQUESCANCUSTOMERS_PK

TheexecutionplanshowsthatOracleisusingnestedloopsjoinstojointhreetables,andthataccessesfromallthreetablesarebyuniqueindexlookup.Thisisprobablyaveryefficientquery.Wewilllookathowtoreadexecutionplansingreaterdetailinalatersection.

Theexplain.sqlscriptfordisplayinganexecutionplanisverybasicinthatitdoesnotdisplayalotoftheinformationcontainedintheplantable.Thingsleftoffofthedisplayincludeoptimizerestimatedcost,cardinality,partitioninformation(onlyrelevantwhenaccessingpartitionedtables),andparallelisminformation(onlyrelevantwhenexecutingparallelqueriesorparallelDML).

IfyouareusingOracle8.1.5orlater,youcanfindtwoplanqueryscriptsin$ORACLE_HOME/rdbms/admin.utlxpls.sqlisintendedfordisplayingexecutionplansofstatementsthatdonotinvolveparallelprocessing,whileutlxplp.sqlshowsadditionalinformationpertainingtoparallelprocessing.Theoutputofthelatterscriptismoreconfusing,soonlyuseitwhenparallelqueryorDMLcomeintoplay.Theoutputfromutlxpls.sqlfortheinvoiceitemqueryisasfollows:

PlanTable|Operation|Name|Rows|Bytes|Cost|Pstart|Pstop||SELECTSTATEMENT||1|39|4||||NESTEDLOOPS||1|39|4||||NESTEDLOOPS||1|27|3||||TABLEACCESSBYINDEXR|INVOICE_I|1|15|2||||INDEXUNIQUESCAN|INVOICE_I|2||1||||TABLEACCESSBYINDEXR|INVOICES|2|24|1||||INDEXUNIQUESCAN|INVOICES_|2||||||TABLEACCESSBYINDEXRO|CUSTOMERS|100|1K|1||||INDEXUNIQUESCAN|CUSTOMERS|100|||||



Whenyounolongerneedanexecutionplan,youshoulddeleteitfromtheplantable.YoucandothisbyrollingbacktheEXPLAINPLANstatement(ifyouhavenotcommittedyet)orbydeletingrowsfromtheplantable.Ifyouhavemultipleexecutionplansintheplantable,thenyoushoulddeleteselectivelybystatement_id.NotethatifyouexplaintwoSQLstatementsandassignboththesamestatement_id,youwillgetanuglycartesianproductwhenyouquerytheplantable!

TheAutotraceFeatureofSQL*Plus

SQL*PlushasanautotracefeaturewhichallowsyoutoautomaticallydisplayexecutionplansandhelpfulstatisticsforeachstatementexecutedinaSQL*PlussessionwithouthavingtousetheEXPLAINPLANstatementorquerytheplantable.YouturnthisfeatureonandoffwiththefollowingSQL*Pluscommand:

SETAUTOTRACEOFF|ON|TRACEONLY[EXPLAIN][STATISTICS]

WhenyouturnonautotraceinSQL*Plus,thedefaultbehaviorisforSQL*Plustoexecuteeachstatementanddisplaytheresultsinthenormalfashion,followedbyanexecutionplanlistingandalistingofvariousserversideresourcesusedtoexecutethestatement.ByusingtheTRACEONLYkeyword,youcanhaveSQL*Plussuppressthequeryresults.ByusingtheEXPLAINorSTATISTICSkeywords,youcanhaveSQL*Plusdisplayjusttheexecutionplanwithouttheresourcestatisticsorjustthestatisticswithouttheexecutionplan.

InordertohaveSQL*Plusdisplayexecutionplans,youmusthaveprivilegesonaplantablebythenameofplan_table.InordertohaveSQL*Plusdisplaytheresourcestatistics,youmusthaveSELECTprivilegesonv$sesstat,v$statname,andv$session.Thereisascriptin$ORACLE_HOME/sqlplus/admincalledplustrce.sqlwhichcreatesarolewiththesethreeprivilegesinit,butthisscriptisnotrunautomaticallybytheOracleinstaller.

TheautotracefeatureofSQL*Plusmakesitextremelyeasytogenerateandviewexecutionplans,withresourcestatisticsasanaddedbonus.Onekeydrawback,however,isthatthestatementbeingexplainedmustactuallybeexecutedbythedatabaseserverbeforeSQL*Pluswilldisplaytheexecutionplan.Thismakesthetoolunusableinthesituationwhereyouwouldliketopredicthowlonganoperationmighttaketocomplete.

AsampleoutputfromSQL*Plusfortheinvoiceitemqueryisasfollows:

ExecutionPlan0SELECTSTATEMENTOptimizer=CHOOSE(Cost=4Card=1Bytes=39)10NESTEDLOOPS(Cost=4Card=1Bytes=39)21NESTEDLOOPS(Cost=3Card=1Bytes=27)32TABLEACCESS(BYINDEXROWID)OF'INVOICE_ITEMS'(Cost=2Card=1Bytes=15)

43INDEX(UNIQUESCAN)OF'INVOICE_ITEMS_PK'(UNIQUE)(Cost=1Card=2)

52TABLEACCESS(BYINDEXROWID)OF'INVOICES'(Cost=1Card=2Bytes=24)

65INDEX(UNIQUESCAN)OF'INVOICES_PK'(UNIQUE)71TABLEACCESS(BYINDEXROWID)OF'CUSTOMERS'(Cost=1Card=100Bytes=1200)

87INDEX(UNIQUESCAN)OF'CUSTOMERS_PK'(UNIQUE)



Statistics0recursivecalls0dbblockgets8consistentgets0physicalreads0redosize517bytessentviaSQL*Nettoclient424bytesreceivedviaSQL*Netfromclient2SQL*Netroundtripsto/fromclient0sorts(memory)0sorts(disk)1rowsprocessed

Althoughwehaventdiscussedhowtoreadanexecutionplanyet,youcanseethattheoutputfromSQL*Plusprovidesthesamebasicinformation,withseveraladditionaldetailsintheformofestimatesfromthequeryoptimizer.

UsingGUIToolstoViewExecutionPlans

TherearemanyGUItoolsavailablethatallowyoutoviewexecutionplansforSQLstatementsyouspecifyorforstatementsalreadysittinginthesharedpoolofthedatabaseinstance.Anycomprehensivedatabasemanagementtoolwillofferthiscapability,butthereareseveralfreetoolsavailablefordownloadontheinternetthathavethisfeatureaswell.

OnetoolinparticularthatIreallylikeisTOAD(theToolforOracleApplicationDevelopers).AlthoughTOADwasoriginallydevelopedasafreetool,QuestSoftwarenowownsTOADanditisavailableinbothafreeversion(limitedfunctionality)andanenhancedversionthatmaybepurchased(fullfeatureset).YoumaydownloadTOADfromQuestSoftwareathttp://www.toadsoft.com/downld.html.TOADhaslotsofhandyfeatures.TheonerelevanttoushereistheabilitytoclickonanySQLstatementinthesharedpoolandinstantlyviewitsexecutionplan.

AswiththeEXPLAINPLANstatementandtheautotracefacilityinSQL*Plus,youwillneedtohaveaccesstoaplantable.HereisTOADsrenditionoftheexecutionplanfortheinvoiceitemquerywevebeenusing:



YoucanseethattheinformationdisplayedisalmostidenticaltothatfromtheautotracefacilityinSQL*Plus.OnenicefeatureofTOADsexecutionplanvieweristhatyoucancollapseandexpandtheindividualoperationsthatmakeuptheexecutionplan.Also,theverticalandhorizontallinesconnectingdifferentstepshelpyoukeeptrackofthenestingandwhichchildoperationsgowithwhichparentoperationsinthehierarchy.Thebenefitsofthesefeaturesbecomemoreapparentwhenworkingwithextremelycomplicatedexecutionplans.

Unfortunately,whenlookingatexecutionplansforSQLstatementsthatinvolvedatabaselinksorparallelism,TOADleavesoutcriticalinformationthatispresentintheplantableandisreportedbytheautotracefeatureofSQL*Plus.PerhapsthisdeficiencyonlyexistsinthefreeversionofTOADIwouldliketothinkthatifyoupayforthefullversionofTOAD,youllgetcompleteexecutionplans.

GeneratingaSQLTraceFile

SQLtracemaybeenabledattheinstanceorsessionlevel.ToenableSQLtraceattheinstancelevel,addthefollowingparametersettingtotheinstanceparameterfileandrestartthedatabaseinstance:

sql_trace=true

WhenanOracleinstancestartsupwiththeaboveparametersetting,everydatabasesessionwillruninSQLtracemode,meaningthatallSQLoperationsforeverydatabasesessionwillbewrittentotracefiles.EventhedaemonprocesseslikePMONandSMONwillbetraced!Inpractice,enablingSQLtraceattheinstancelevelisusuallynotveryuseful.Itcanbeoverpowering,sortoflikeusingafirehosetopouryourselfaglassofwater.



ItismoretypicaltoenableSQLtraceinaspecificsession.YoucanturnSQLtraceonandoffasdesiredinordertotracejusttheoperationsthatyouwishtotrace.Ifyouhaveaccesstothedatabasesessionyouwishtotrace,thenusetheALTERSESSIONstatementasfollowstoenableanddisableSQLtrace:

ALTERSESSIONSETsql_trace=TRUE|FALSE;

ThistechniqueworkswellifyouhaveaccesstotheapplicationsourcecodeandcanaddinALTERSESSIONstatementsatwill.ItalsoworkswellwhentheapplicationrunsfromSQL*PlusandyoucanexecuteALTERSESSIONstatementsattheSQL*Pluspromptbeforeinvokingtheapplication.

InsituationswhereyoucannotinvokeanALTERSESSIONcommandfromthesessionyouwishtotraceaswithprepackagedapplications,forexampleyoucanconnecttothedatabaseasaDBAuserandinvokethedbms_systembuiltinpackageinordertoturnonoroffSQLtraceinanothersession.Youdothisbyqueryingv$sessiontofindtheSIDandserialnumberofthesessionyouwishtotraceandtheninvokingthedbms_systempackagewithacommandoftheform:

EXECUTESYS.dbms_system.set_sql_trace_in_session(,,TRUE|FALSE);

WhenyouenableSQLtraceinasessionforthefirsttime,theOracleserverprocesshandlingthatsessionwillcreateatracefileinthedirectoryonthedatabaseserverdesignatedbytheuser_dump_destinitializationparameter.Astheserveriscalledbytheapplicationtoperformdatabaseoperations,theserverprocesswillappendtothetracefile.

Notethattracingadatabasesessionthatisusingmultithreadedserver(MTS)isabitcomplicatedbecauseeachdatabaserequestfromtheapplicationcouldgetpickedupbyadifferentserverprocess.Inthissituation,eachserverprocesswillcreateatracefilecontainingtraceinformationabouttheoperationsperformedbythatprocessonly.Thismeansthatyouwillpotentiallyhavetocombinemultipletracefilestogethertogetthefullpictureofhowtheapplicationinteractedwiththedatabase.Furthermore,ifmultiplesessionsarebeingtracedatonce,itwillbehardtotellwhichoperationsinthetracefilebelongtowhichsession.Forthesereasons,youshouldusededicatedservermodewhentracingadatabasesessionwithSQLtrace.

SQLtracefilescontaindetailedtiminginformation.Bydefault,Oracledoesnottracktiming,soalltimingfiguresintracefileswillshowaszero.Ifyouwouldliketoseelegitimatetiminginformation,thenyouneedtoenabletimedstatistics.Youcandothisattheinstancelevelbysettingthefollowingparameterintheinstanceparameterfileandrestartingtheinstance:

timed_statistics=true

Youcanalsodynamicallyenableordisabletimedstatisticscollectionateithertheinstanceorthesessionlevelwiththefollowingcommands:

ALTERSYSTEMSETtimed_statistics=TRUE|FALSE;ALTERSESSIONSETtimed_statistics=TRUE|FALSE;



Thereisnoknownwaytoenabletimedstatisticscollectionforanindividualsessionfromanothersession(akintotheSYS.dbms_system.set_sql_trace_in_sessionbuiltin).

ThereisveryhighoverheadassociatedwithenablingSQLtrace.SomeDBAsbelievetheperformancepenaltycouldbeover25%.AnotherconcernisthatenablingSQLtracecausesthegenerationofpotentiallylargetracefiles.Forthesereasons,youshoulduseSQLtracesparingly.OnlytracewhatyouneedtotraceandthinkverycarefullybeforeenablingSQLtraceattheinstancelevel.

Ontheotherhand,thereislittle,ifany,measurableperformancepenaltyinenablingtimedstatisticscollection.ManyDBAsrunproductiondatabaseswithtimedstatisticscollectionenabledatthesystemlevelsothatvarioussystemstatistics(morethanjustSQLtracefiles)willincludedetailedtiminginformation.NotethatOracle8.1.5hadsomeseriousmemorycorruptionbugsassociatedwithenablingtimedstatisticscollectionattheinstancelevel,buttheseseemtohavebeenfixedinOracle8.1.6.

OnUnixplatforms,OraclewilltypicallysetpermissionssothatonlytheoracleuserandmembersofthedbaUnixgroupcanreadthetracefiles.IfyouwantanybodywithaUnixlogintobeabletoreadthetracefiles,thenyoushouldsetthefollowingundocumented(butsupported)initializationparameterintheparameterfile:

_trace_files_public=true

Ifyoutraceadatabasesessionthatmakesalargenumberofcallstothedatabaseserver,thetracefilecangetquitelarge.Theinitializationparametermax_dump_file_sizeallowsyoutosetamaximumtracefilesize.OnUnixplatforms,thisparameterisspecifiedinunitsof512byteblocks.Thusasettingof10240willlimittracefilesto5Mbapiece.WhenaSQLtracefilereachesthemaximumsize,thedatabaseserverprocessstopswritingtraceinformationtothetracefile.OnUnixplatformstherewillbenolimitontracefilesizeifyoudonotexplicitlysetthemax_dump_file_sizeparameter.

Ifyouaretracingasessionandrealizethatthetracefileisabouttoreachthelimitsetbymax_dump_file_size,youcaneliminatethelimitdynamicallysothatyoudontlosetraceinformation.Todothis,querythePIDcolumninv$processtofindtheOraclePIDoftheprocesswritingthetracefile.ThenexecutethefollowingstatementsinSQL*Plus:

CONNECT/ASSYSDBAORADEBUGSETORAPIDORADEBUGUNLIMIT

RunningTKPROFonaSQLTraceFile

BeforeyoucanuseTKPROF,youneedtogenerateatracefileandlocateit.Oraclewritestracefilesonthedatabaseservertothedirectoryspecifiedbytheuser_dump_destinitializationparameter.(DaemonprocessessuchasPMONwritetheirtracefilestothedirectoryspecifiedbybackground_dump_dest.)OnUnixplatforms,thetracefilewillhaveanamethatincorporatestheoperatingsystemPIDoftheserverprocesswritingthetracefile.

Iftherearealotoftracefilesintheuser_dump_destdirectory,itcouldbetrickytofindtheoneyouwant.Onetacticistoexaminethetimestampsonthefiles.AnothertechniqueistoembedacommentinaSQLstatementintheapplicationthatwillmakeitswayintothetracefile.Anexampleofthisisasfollows:

ALTERSESSION/*Moduleglpost.c*/SETsql_trace=TRUE;



BecauseTKPROFisautilityyouinvokefromtheoperatingsystemandnotfromwithinadatabasesession,therewillnaturallybesomevariationintheuserinterfacefromoneoperatingsystemplatformtoanother.OnUnixplatforms,yourunTKPROFfromtheoperatingsystempromptwithasyntaxasfollows:

tkprof[explain=][sys=n]\[insert=][record=][sort=]

IfyouinvokeTKPROFwithnoargumentsatall,youwillgetahelpscreenlistingalloftheoptions.ThisisespeciallyhelpfulbecauseTKPROFoffersmanysortcapabilities,butyouselectthedesiredsortbyspecifyingacryptickeyword.Thehelpscreenidentifiesallofthesortkeywords.

Initssimplestform,yourunTKPROFspecifyingthenameofaSQLtracefileandanoutputfilename.TKPROFwillreadthetracefileandgenerateareportfilewiththeoutputfilenameyouspecified.TKPROFwillnotconnecttothedatabase,andthereportwillnotincludeexecutionplansfortheSQLstatements.SQLstatementsthatwereexecutedbytheSYSuserrecursively(todynamicallyallocateanextentinadictionarymanagedtablespace,forexample)willbeincludedinthereport,andthestatementswillappearinthereportapproximatelyintheorderinwhichtheywereexecutedinthedatabasesessionthatwastraced.

Ifyouincludetheexplainkeyword,TKPROFwillconnecttothedatabaseandexecuteanEXPLAINPLANstatementforeachSQLstatementfoundinthetracefile.Theexecutionplanresultswillbeincludedinthereportfile.Aswewillseelater,TKPROFmergesvaluableinformationfromthetracefileintotheexecutionplandisplay,makingthisjustaboutthemostvaluablewaytodisplayanexecutionplan.NotethattheusernameyouspecifywhenrunningTKPROFshouldbethesameastheusernameconnectedinthedatabasesessionthatwastraced.YoudonotneedtohaveaplantableinordertousetheexplainkeywordTKPROFwillcreateanddropitsownplantableifneeded.

Ifyouspecifysys=n,TKPROFwillexcludefromthereportSQLstatementsinitiatedbyOracleastheSYSuser.Thiswillmakeyourreportlooktidierbecauseitwillonlycontainstatementsactuallyissuedbyyourapplication.ThetheoryisthatOracleinternalSQLhasalreadybeenfullyoptimizedbythekerneldevelopersatOracleCorporation,soyoushouldnothavetodealwithit.However,usingsys=nwillexcludepotentiallyvaluableinformationfromtheTKPROFreport.SupposetheSGAisnotproperlysizedontheinstanceandOracleisspendingalotoftimeresolvingdictionarycachemisses.ThiswouldmanifestitselfinlotsoftimespentonrecursiveSQLstatementsinitiatedbytheSYSuser.Usingsys=nwouldexcludethisinformationfromthereport.

Ifyouspecifytheinsertkeyword,TKPROFwillgenerateaSQLscriptinadditiontotheregularreport.ThisSQLscriptcreatesatablecalledtkprof_tableandinsertsonerowforeachSQLstatementdisplayedonthereport.TherowwillcontainthetextoftheSQLstatementtracedandallofthestatisticsdisplayedinthereport.YoucouldusethisfeaturetoeffectivelyloadtheTKPROFreportintothedatabaseanduseSQLtoanalyzeandmanipulatethestatistics.Iveneverneededtousethisfeature,butIsupposeitcouldbehelpfulinsomesituations.

Ifyouspecifytherecordkeyword,TKPROFwillgenerateanothertypeofSQLscriptinadditiontotheregularreport.ThisSQLscriptwillcontainacopyofeachSQLstatementissuedbytheapplicationwhiletracingwasenabled.YoucouldgetthissameinformationfromtheTKPROFreportitself,butthiswaycouldsavesomecuttingandpasting.

Thesortkeywordisextremelyuseful.Typically,aTKPROFreportmayincludehundredsofSQLstatements,butyoumayonlybeinterestedinafewresourceintensivequeries.ThesortkeywordallowsyoutoorderthelistingoftheSQLstatementssothatyoudonthavetoscantheentirefilelookingforresourcehogs.Insomeways,thesortfeatureistoopowerfulforitsowngood.Forexample,youcannotsortstatementsbyCPUtimeconsumedinsteadyousortbyCPU



timespentparsing,CPUtimespentexecuting,orCPUtimespentfetching.

AsampleTKPROFreportfortheinvoiceitemquerywevebeenusingsofarisasfollows:

TKPROF:Release8.1.6.1.0ProductiononWedAug919:06:362000

(c)Copyright1999OracleCorporation.Allrightsreserved.

Tracefile:example.trcSortoptions:default********************************************************************************count=numberoftimesOCIprocedurewasexecutedcpu=cputimeinsecondsexecutingelapsed=elapsedtimeinsecondsexecutingdisk=numberofphysicalreadsofbuffersfromdiskquery=numberofbuffersgottenforconsistentreadcurrent=numberofbuffersgottenincurrentmode(usuallyforupdate)rows=numberofrowsprocessedbythefetchorexecutecall********************************************************************************

ALTERSESSION/*TKPROFexample*/SETsql_trace=TRUE

callcountcpuelapseddiskquerycurrentrowsParse00.000.000000Execute10.000.000000Fetch00.000.000000total10.000.000000

Missesinlibrarycacheduringparse:0Missesinlibrarycacheduringexecute:1Optimizergoal:CHOOSEParsinguserid:34(RSCHRAG)********************************************************************************

ALTERSESSIONSETtimed_statistics=TRUE


Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:34(RSCHRAG)********************************************************************************

SELECTa.customer_name,a.customer_number,b.invoice_number,b.invoice_type,b.invoice_date,b.total_amount,c.line_number,c.part_number,c.quantity,c.unit_costFROMcustomersa,invoicesb,invoice_itemscWHEREc.invoice_id=:b1ANDc.line_number=:b2ANDb.invoice_id=c.invoice_idANDa.customer_id=b.customer_id

callcountcpuelapseddiskquerycurrentrowsParse10.050.020000



Execute10.000.000000Fetch20.000.008801total40.050.028801

Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:34(RSCHRAG)

RowsRowSourceOperation1NESTEDLOOPS1NESTEDLOOPS1TABLEACCESSBYINDEXROWIDINVOICE_ITEMS1INDEXUNIQUESCAN(objectid21892)1TABLEACCESSBYINDEXROWIDINVOICES1INDEXUNIQUESCAN(objectid21889)1TABLEACCESSBYINDEXROWIDCUSTOMERS1INDEXUNIQUESCAN(objectid21887)

RowsExecutionPlan0SELECTSTATEMENTGOAL:CHOOSE1NESTEDLOOPS1NESTEDLOOPS1TABLEACCESSGOAL:ANALYZED(BYINDEXROWID)OF'INVOICE_ITEMS'1INDEXGOAL:ANALYZED(UNIQUESCAN)OF'INVOICE_ITEMS_PK'(UNIQUE)1TABLEACCESSGOAL:ANALYZED(BYINDEXROWID)OF'INVOICES'1INDEXGOAL:ANALYZED(UNIQUESCAN)OF'INVOICES_PK'(UNIQUE)1TABLEACCESSGOAL:ANALYZED(BYINDEXROWID)OF'CUSTOMERS'1INDEXGOAL:ANALYZED(UNIQUESCAN)OF'CUSTOMERS_PK'(UNIQUE)

********************************************************************************

ALTERSESSIONSETsql_trace=FALSE


Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:34(RSCHRAG)

********************************************************************************

OVERALLTOTALSFORALLNONRECURSIVESTATEMENTS




Missesinlibrarycacheduringparse:3Missesinlibrarycacheduringexecute:1

OVERALLTOTALSFORALLRECURSIVESTATEMENTS


Missesinlibrarycacheduringparse:11

4userSQLstatementsinsession.24internalSQLstatementsinsession.28SQLstatementsinsession.1statementEXPLAINedinthissession.********************************************************************************Tracefile:example.trcTracefilecompatibility:8.00.04Sortoptions:default

1sessionintracefile.4userSQLstatementsintracefile.24internalSQLstatementsintracefile.28SQLstatementsintracefile.15uniqueSQLstatementsintracefile.1SQLstatementsEXPLAINedusingschema:RSCHRAG.prof$plan_tableDefaulttablewasused.Tablewascreated.Tablewasdropped.381linesintracefile.

YoucanseethatthereisalotgoingoninaTKPROFreport.Wewilltalkabouthowtoreadthereportandinterpretthedifferentstatisticsinthenextsection.

InterpretingExecutionPlansandTKPROFReportsInthissectionwewilldiscusshowtoreadandinterpretexecutionplansandTKPROFreports.WhilegeneratinganexecutionplanlistingorcreatingaTKPROFreportfileisusuallyastraightforwardprocess,analyzingthedataandreachingthecorrectconclusionscanbemoreofanart.Welllookatlotsofexamplesalongtheway.

UnderstandingExecutionPlans

Anexecutionplanisahierarchicalstructuresomewhatlikeaninvertedtree.TheSQLstatementbeingexaminedcanbethoughtofastherootofthetree.Thiswillbethefirstlineonanexecutionplanlisting,thelinethatisleastindented.Thisstatementcanbethoughtofastheresultofoneormoresubordinateoperations.Eachofthesesubordinateoperationscanpossiblybedecomposedfurther.ThisdecompositionprocesscontinuesrepeatedlyuntileventuallyeventhemostcomplexSQLstatementisbrokendownintoasetofbasicdataaccessoperations.

Considerthefollowingsimplequeryandexecutionplan:



SELECTcustomer_id,customer_number,customer_nameFROMcustomersWHEREUPPER(customer_name)LIKE'ACME%'ORDERBYcustomer_name;

IDPARENTOPERATIONOBJECT_NAME0SELECTSTATEMENT10SORTORDERBY21TABLEACCESSFULLCUSTOMERS

TherootoperationthatwhichweexplainedisaSELECTstatement.Theoutputofthestatementwillbetheresultsofasortoperation(forthepurposesofsatisfyingtheORDERBYclause).Theinputtothesortwillbetheresultsofafulltablescanofthecustomerstable.Statedmoreclearly,thedatabaseserverwillexecutethisquerybycheckingeveryrowinthecustomerstableforacriteriamatchandsortingtheresults.PerhapsthedeveloperexpectedOracletouseanindexonthecustomer_namecolumntoavoidafulltablescan,buttheuseoftheUPPERfunctiondefeatedtheindex.(Afunctionbasedindexcouldbedeployedtomakethisquerymoreefficient.)

Considerthefollowingqueryandexecutionplan:

SELECTa.customer_name,b.invoice_number,b.invoice_dateFROMcustomersa,invoicesbWHEREb.invoice_date>TRUNC(SYSDATE1)ANDa.customer_id=b.customer_id;

IDPARENTOPERATIONOBJECT_NAME0SELECTSTATEMENT10NESTEDLOOPS21TABLEACCESSBYINDEXROWIDINVOICES32INDEXRANGESCANINVOICES_DATE41TABLEACCESSBYINDEXROWIDCUSTOMERS54INDEXUNIQUESCANCUSTOMERS_PK

Again,therootoperationisaSELECTstatement.Thistime,theSELECTstatementgetsitsinputfromtheresultsofanestedloopsjoinoperation.Thenestedloopsoperationtakesasinputtheresultsofaccessestotheinvoicesandcustomerstables.(Youcantellfromtheindentingthataccessestobothtablesfeeddirectlyintothenestedloopsoperation.)Theinvoicestableisaccessedbyarangescanoftheinvoices_dateindex,whilethecustomerstableisaccessedbyauniquescanofthecustomers_pkindex.

Inplainerlanguage,hereishowOraclewillexecutethisquery:Oraclewillperformarangescanontheinvoices_dateindextofindtheROWIDsofallrowsintheinvoicestablethathaveaninvoicedatematchingthequerycriteria.ForeachROWIDfound,Oraclewillfetchthecorrespondingrowfromtheinvoicestable,lookupthecustomer_idfromtheinvoicesrecordinthecustomers_pkindex,andusetheROWIDfoundinthecustomers_pkindexentrytofetchthecorrectcustomerrecord.This,ineffect,joinstherowsfetchedfromtheinvoicestablewiththeircorrespondingmatchesinthecustomerstable.Theresultsofthenestedloopsjoinoperationarereturnedasthequeryresults.

Considerthefollowingqueryandexecutionplan:

SELECTa.customer_name,COUNT(DISTINCTb.invoice_id)"OpenInvoices",COUNT(c.invoice_id)"OpenInvoiceItems"FROMcustomersa,invoicesb,invoice_itemsc



WHEREb.invoice_status='OPEN'ANDa.customer_id=b.customer_idANDc.invoice_id(+)=b.invoice_idGROUPBYa.customer_name;

IDPARENTOPERATIONOBJECT_NAME0SELECTSTATEMENT10SORTGROUPBY21NESTEDLOOPSOUTER32HASHJOIN43TABLEACCESSBYINDEXROWIDINVOICES54INDEXRANGESCANINVOICES_STATUS63TABLEACCESSFULLCUSTOMERS72INDEXRANGESCANINVOICE_ITEMS_PK

Thisexecutionplanismorecomplexthantheprevioustwo,andhereyoucanstarttogetafeelforthewayinwhichcomplexoperationsgetbrokendownintosimplersubordinateoperations.Toexecutethisquery,thedatabaseserverwilldothefollowing:FirstOraclewillperformarangescanontheinvoices_statusindextogettheROWIDsofallrowsintheinvoicestablewiththedesiredstatus.ForeachROWIDfound,therecordfromtheinvoicestablewillbefetched.

Thissetofinvoicerecordswillbesetasideforamomentwhilethefocusturnstothecustomerstable.Here,Oraclewillfetchallcustomersrecordswithafulltablescan.Toperformahashjoinbetweentheinvoicesandcustomerstables,Oraclewillbuildahashfromthecustomerrecordsandusetheinvoicerecordstoprobethecustomerhash.

Next,anestedloopsjoinwillbeperformedbetweentheresultsofthehashjoinandtheinvoice_items_pkindex.Foreachrowresultingfromthehashjoin,Oraclewillperformauniquescanoftheinvoice_items_pkindextofindindexentriesformatchinginvoiceitems.NotethatOraclegetseverythingitneedsfromtheindexanddoesntevenneedtoaccesstheinvoice_itemstableatall.Alsonotethatthenestedloopsoperationisanouterjoin.AsortoperationforthepurposesofgroupingisperformedontheresultsofthenestedloopsoperationinordertocompletetheSELECTstatement.

ItisinterestingtonotethatOraclechosetouseahashjoinandafulltablescanonthecustomerstableinsteadofthemoretraditionalnestedloopsjoin.Inthisdatabasetherearemanyinvoicesandarelativelysmallnumberofcustomers,makingafulltablescanofthecustomerstablelessexpensivethanrepeatedindexlookupsonthecustomers_pkindex.Butsupposethecustomerstablewasenormousandtherelativenumberofinvoiceswasquitesmall.Inthatscenarioanestedloopsjoinmightbebetterthanahashjoin.ExaminingtheexecutionplanallowsyoutoseewhichjoinmethodOracleisusing.YoucouldthenapplyoptimizerhintstocoerceOracletousealternatemethodsandcomparetheperformance.

YoumaywonderhowIgotthatwholedetailedexplanationoutoftheeightlineexecutionplanlistingshownabove.DidIreadanythingintotheexecutionplan?No!Itsallthere!Understandingthestandardinputsandoutputsofeachtypeofoperationandcouplingthiswiththeindentingiskeytoreadinganexecutionplan.

Anestedloopsjoinoperationalwaystakestwoinputs:Foreveryrowcomingfromthefirstinput,thesecondinputisexecutedoncetofindmatchingrows.Ahashjoinoperationalsotakestwoinputs:Thesecondinputisreadcompletelyonceandusedtobuildahash.Foreachrowcomingfromthefirstinput,oneprobeisperformedagainstthishash.Sortingoperations,meanwhile,takeinoneinput.Whentheentireinputhasbeenread,therowsaresortedandoutputinthedesiredorder.

Nowletslookataquerywithamorecomplicatedexecutionplan:

SELECTcustomer_nameFROMcustomersa



WHEREEXISTS(SELECT1FROMinvoices_viewbWHEREb.customer_id=a.customer_idANDnumber_of_lines>100)ORDERBYcustomer_name;

IDPARENTOPERATIONOBJECT_NAME0SELECTSTATEMENT10SORTORDERBY21FILTER32TABLEACCESSFULLCUSTOMERS42VIEWINVOICES_VIEW54FILTER65SORTGROUPBY76NESTEDLOOPS87TABLEACCESSBYINDEXROWIDINVOICES98INDEXRANGESCANINVOICES_CUSTOMER_ID107INDEXRANGESCANINVOICE_ITEMS_PK

Thisexecutionplanissomewhatcomplexbecausethequeryincludesasubquerythattheoptimizercouldnotrewriteasasimplejoin,andaviewwhosedefinitioncouldnotbemergedintothequery.Thedefinitionoftheinvoices_viewviewisasfollows:

CREATEORREPLACEVIEWinvoices_viewASSELECTa.invoice_id,a.customer_id,a.invoice_date,a.invoice_status,a.invoice_number,a.invoice_type,a.total_amount,COUNT(*)number_of_linesFROMinvoicesa,invoice_itemsbWHEREb.invoice_id=a.invoice_idGROUPBYa.invoice_id,a.customer_id,a.invoice_date,a.invoice_status,a.invoice_number,a.invoice_type,a.total_amount;

Hereiswhatthisexecutionplansays:Oraclewillexecutethisquerybyreadingallrowsfromthecustomerstablewithafulltablescan.Foreachcustomerrecord,theinvoices_viewviewwillbeassembledasafilterandtherelevantcontentsoftheviewwillbeexaminedtodeterminewhetherthecustomershouldbepartoftheresultsetornot.

Oraclewillassembletheviewbyperforminganindexrangescanontheinvoices_customer_idindexandfetchingtherowsfromtheinvoicestablecontainingonespecificcustomer_id.Foreachinvoicerecordfound,theinvoice_items_pkindexwillberangescannedtogetanestedloopsjoinofinvoicestotheirinvoice_itemsrecords.Theresultsofthejoinaresortedforgrouping,andthengroupswith100orfewerinvoice_itemsrecordsarefilteredout.

WhatisleftatthestepwithID4isalistofinvoicesforonespecificcustomerthathavemorethan100invoice_itemsrecordsassociated.Ifatleastonesuchinvoiceexists,thenthecustomerpassesthefilteratthestepwithID2.Finally,allcustomerrecordspassingthisfilteraresortedforcorrectorderingandtheresultsarecomplete.

Notethatqueriesinvolvingsimpleviewswillnotresultinaviewoperationintheexecutionplan.ThisisbecauseOraclecanoftenmergeaviewdefinitionintothequeryreferencingtheviewsothatthetableaccessesrequiredtoimplementtheviewjustbecomepartoftheregularexecutionplan.Inthisexample,theGROUPBYclauseembeddedintheviewfoiledOraclesabilitytomergetheviewintothequery,makingaseparateviewoperationnecessaryinordertoexecutethe



query.

Alsonotethatthefilteroperationcantakeonafewdifferentforms.Ingeneral,afilteroperationiswhereOraclelooksatasetofcandidaterowsandeliminatessomebasedoncertaincriteria.Thiscriteriacouldinvolveasimpletestsuchasnumber_of_lines>100oritcouldbeanelaboratesubquery.

Inthisexample,thefilteratstepID5takesonlyoneinput.HereOracleevaluateseachrowfromtheinputoneatatimeandeitheraddstherowtotheoutputordiscardsitasappropriate.Meanwhile,thefilteratstepID2takestwoinputs.Whenafiltertakestwoinputs,Oraclereadstherowsfromthefirstinputoneatatimeandexecutesthesecondinputonceforeachrow.Basedontheresultsofthesecondinput,therowfromthefirstinputiseitheraddedtotheoutputordiscarded.

Oracleisabletoperformsimplefilteringoperationswhileperformingafulltablescan.Therefore,aseparatefilteroperationwillnotappearintheexecutionplanwhenOracleperformsafulltablescanandthrowsoutrowsthatdontsatisfyaWHEREclause.FilteroperationswithoneinputcommonlyappearinquerieswithviewoperationsorHAVINGclauses,whilefilteroperationswithmultipleinputswillappearinquerieswithEXISTSclauses.

Animportantnoteaboutexecutionplansandsubqueries:WhenaSQLstatementinvolvessubqueries,Oracletriestomergethesubqueryintothemainstatementbyusingajoin.Ifthisisnotfeasibleandthesubquerydoesnothaveanydependenciesorreferencestothemainquery,thenOraclewilltreatthesubqueryasacompletelyseparatestatementfromthestandpointofdevelopinganexecutionplanalmostasiftwoseparateSQLstatementsweresenttothedatabaseserver.Whenyougenerateanexecutionplanforastatementthatincludesafullyautonomoussubquery,theexecutionplanmaynotincludetheoperationsforthesubquery.Inthissituation,youneedtogenerateanexecutionplanforthesubqueryseparately.

OtherColumnsinthePlanTable

Althoughtheplantablecontains24columns,sofarwehaveonlybeenusingsixoftheminourexecutionplanlistings.Thesesixwillgetyouveryfarinthetuningprocess,butsomeoftheothercolumnscanbemildlyinterestingattimes.Stillothercolumnscanbeveryrelevantinspecificsituations.

Theoptimizercolumnintheplantableshowsthemode(suchasRULEorCHOOSE)usedbytheoptimizertogeneratetheexecutionplan.Thetimestampcolumnshowsthedateandtimethattheexecutionplanwasgenerated.Theremarkscolumnisan80bytefieldwhereyoumayputyourowncommentsabouteachstepoftheexecutionplan.YoucanpopulatetheremarkscolumnbyusinganordinaryUPDATEstatementagainsttheplantable.

Theobject_owner,object_node,andobject_instancecolumnscanhelpyoufurtherdistinguishthedatabaseobjectinvolvedintheoperation.Youmightlookattheobject_ownercolumn,forexample,ifobjectsinmultipleschemashavethesamenameandyouarenotsurewhichoneisbeingreferencedintheexecutionplan.Theobject_nodeisrelevantindistributedqueriesortransactions.Itindicatesthedatabaselinknametotheobjectiftheobjectresidesinaremotedatabase.Theobject_instancecolumnishelpfulinsituationssuchasaselfjoinwheremultipleinstancesofthesameobjectareusedinoneSQLstatement.

Thepartition_start,partition_stop,andpartition_idcolumnsofferadditionalinformationwhenapartitionedtableisinvolvedintheexecutionplan.ThedistributioncolumngivesinformationabouthowthemultipleOracleprocessesinvolvedinaparallelqueryorparallelDMLoperationinteractwitheachother.

Thecost,cardinality,andbytescolumnsshowestimatesmadebythecostbasedoptimizerastohowexpensiveanoperationwillbe.RememberthattheexecutionplanisinsertedintotheplantablewithoutactuallyexecutingtheSQLstatement.Therefore,thesecolumnsreflectOraclesestimatesandnottheactualresourcesused.Whileitcanbeamusingtolookattheoptimizerspredictions,sometimesyouneedtotakethemwithagrainofsalt.LaterwellseethatTKPROF



reportscanincludespecificinformationaboutactualresourcesusedateachstepoftheexecutionplan.

TheothercolumnintheplantableisawildcardwhereOraclecanstoreanysortoftextualinformationabouteachstepofanexecutionplan.Theother_tagcolumngivesanindicationofwhathasbeenplacedintheothercolumn.Thiscolumnwillcontainvaluableinformationduringparallelqueriesanddistributedoperations.

ConsiderthefollowingdistributedqueryandoutputfromtheSQL*Plusautotracefacility:

SELECT/*+RULE*/a.customer_number,a.customer_name,b.contact_id,b.contact_nameFROMcustomersa,[email protected](b.contact_name)=UPPER(a.customer_name)ORDERBYa.customer_number,b.contact_id;

ExecutionPlan0SELECTSTATEMENTOptimizer=HINT:RULE10SORT(ORDERBY)21MERGEJOIN32SORT(JOIN)43REMOTE*SALES.ACME.COM52SORT(JOIN)65TABLEACCESS(FULL)OF'CUSTOMERS'

4SERIAL_FROM_REMOTESELECT"CONTACT_ID","CONTACT_NAME"FROM"CONTACTS""B

Intheexecutionplanhierarchy,thestepwithID4isdisplayedasaremoteoperationthroughthesales.acme.comdatabaselink.AtthebottomoftheexecutionplanyoucanseetheactualSQLstatementthatthelocaldatabaseserversendstosales.acme.comtoperformtheremoteoperation.Thisinformationcamefromtheotherandother_tagcolumnsoftheplantable.

Hereishowtoreadthisexecutionplan:OracleobservedahintandusedtheRULEoptimizermodeinordertodeveloptheexecutionplan.First,aremotequerywillbesenttosales.acme.comtofetchthecontact_idsandnamesfromaremotetable.Thesefetchedrowswillbesortedforjoiningpurposesandtemporarilysetaside.Next,Oraclewillfetchallrecordsfromthecustomerstablewithafulltablescanandsortthemforjoiningpurposes.Next,thesetofcontactsandthesetofcustomerswillbejoinedusingthemergejoinalgorithm.Finally,theresultsofthemergejoinwillbesortedforproperorderingandtheresultswillbereturned.

Themergejoinoperationalwaystakestwoinputs,withtheprerequisitethateachinputhasalreadybeensortedonthejoincolumnorcolumns.Themergejoinoperationreadsbothinputsintheirentiretyatonetimeandoutputstheresultsofthejoin.Mergejoinsandhashjoinsareusuallymoreefficientthannestedloopsjoinswhenremotetablesareinvolved,becausethesetypesofjoinswillalmostalwaysinvolvefewernetworkroundtrips.Hashjoinsarenotsupportedwhenrulebasedoptimizationisused.BecauseoftheRULEhint,Oraclechoseamergejoin.

ReadingTKPROFReports

EveryTKPROFreportstartswithaheaderthatliststheTKPROFversion,thedateandtimethereportwasgenerated,thenameofthetracefile,thesortoptionused,andabriefdefinitionofthecolumnheadingsinthereport.Everyreportendswithaseriesofsummarystatistics.YoucanseetheheadingandsummarystatisticsonthesampleTKPROFreportshownearlierinthispaper.

ThemainbodyoftheTKPROFreportconsistsofoneentryforeachdistinctSQLstatementthatwasexecutedbythe



databaseserverwhileSQLtracewasenabled.Thereareafewsubtletiesatplayintheprevioussentence.Ifanapplicationqueriesthecustomerstable50times,eachtimespecifyingadifferentcustomer_idasaliteral,thentherewillbe50separateentriesintheTKPROFreport.Ifhowever,theapplicationspecifiesthecustomer_idasabindvariable,thentherewillbeonlyoneentryinthereportwithanindicationthatthestatementwasexecuted50times.Furthermore,thereportwillalsoincludeSQLstatementsinitiatedbythedatabaseserveritselfinordertoperformsocalledrecursiveoperationssuchasmanagethedatadictionaryanddictionarycache.

TheentriesforeachSQLstatementintheTKPROFreportareseparatedbyarowofasterisks.ThefirstpartofeachentryliststheSQLstatementandstatisticspertainingtotheparsing,execution,andfetchingoftheSQLstatement.Considerthefollowingexample:

********************************************************************************

SELECTtable_nameFROMuser_tablesORDERBYtable_name


Missesinlibrarycacheduringparse:1Optimizergoal:CHOOSEParsinguserid:RSCHRAG[recursivedepth:0]

Thismaynotseemlikeausefulexamplebecauseitissimplyaqueryagainstadictionaryviewanddoesnotinvolveapplicationtables.However,thisqueryactuallyservesthepurposewellfromthestandpointofhighlightingtheelementsofaTKPROFreport.

Readingacross,weseethatwhileSQLtracewasenabled,theapplicationcalledonthedatabaseservertoparsethisstatementonce.0.01CPUsecondsoveraperiodof0.02elapsedsecondswereusedontheparsecall,althoughnophysicaldiskI/Osorevenanybuffergetswererequired.(WecaninferthatalldictionarydatarequiredtoparsethestatementwerealreadyinthedictionarycacheintheSGA.)

ThenextlineshowsthattheapplicationcalledonOracletoexecutethequeryonce,withlessthan0.01secondsofCPUtimeandelapsedtimebeingusedontheexecutecall.Again,nophysicaldiskI/Osorbuffergetswererequired.Thefactthatalmostnoresourceswereusedontheexecutecallmightseemstrange,butitmakesperfectsensewhenyouconsiderthatOracledefersallworkonmostSELECTstatementsuntilthefirstrowisfetched.

Thenextlineindicatesthattheapplicationperformed14fetchcalls,retrievingatotalof194rows.The14callsusedatotalof0.59CPUsecondsand0.99secondsofelapsedtime.AlthoughnophysicaldiskI/Oswereperformed,33,633buffersweregotteninconsistentmode(consistentgets).Inotherwords,therewere33,633hitsinthebuffercacheandnomisses.IranthisqueryfromSQL*Plus,andwecanseeherethatSQL*Plususesanarrayinterfacetofetchmultiplerowsononefetchcall.Wecanalsoseethat,althoughnodiskI/Oswerenecessary,ittookquiteabitofprocessingtocompletethisquery.

TheremaininglinesonthefirstpartoftheentryforthisSQLstatementshowthattherewasamissinthelibrarycache(theSQLstatementwasnotalreadyinthesharedpool),theCHOOSEoptimizergoalwasusedtodeveloptheexecution



plan,andtheparsingwasperformedintheRSCHRAGschema.

Noticethetextinsquarebracketsconcerningrecursivedepth.ThisdidnotactuallyappearonthereportIaddeditforeffect.Thefactthatthereportdidnotmentionrecursivedepthforthisstatementindicatesthatitwasexecutedatthetoplevel.Inotherwords,theapplicationissuedthisstatementdirectlytothedatabaseserver.Whenrecursionisinvolved,theTKPROFreportwillindicatethedepthoftherecursionnexttotheparsinguser.

Therearetwoprimarywaysinwhichrecursionoccurs.DatadictionaryoperationscancauserecursiveSQLoperations.Whenaqueryreferencesaschemaobjectthatismissingfromthedictionarycache,arecursivequeryisexecutedinordertofetchtheobjectdefinitionintothedictionarycache.Forexample,aqueryfromaviewwhosedefinitionisnotinthedictionarycachewillcausearecursivequeryagainstview$tobeparsedintheSYSschema.Also,dynamicspaceallocationsindictionarymanagedtablespaceswillcauserecursiveupdatesagainstuet$andfet$intheSYSschema.

Useofdatabasetriggersandstoredprocedurescanalsocauserecursion.Supposeanapplicationinsertsarowintoatablethathasadatabasetrigger.Whenthetriggerfires,itsstatementsrunatarecursiondepthofone.Ifthetriggerinvokesastoredprocedure,therecursiondepthcouldincreasetotwo.Thiscouldcontinuethroughanynumberoflevels.

SofarwehavebeenlookingatthetoppartoftheSQLstatemententryintheTKPROFreport.Theremainderoftheentryconsistsofarowsourceoperationlistandoptionallyanexecutionplandisplay.(IftheexplainkeywordwasnotusedwhentheTKPROFreportwasgenerated,thentheexecutionplandisplaywillbeomitted.)Considerthefollowingexample,whichistherestoftheentryshownabove:

RowsRowSourceOperation194SORTORDERBY194NESTEDLOOPS195NESTEDLOOPSOUTER195NESTEDLOOPSOUTER195NESTEDLOOPS11146TABLEACCESSBYINDEXROWIDOBJ$11146INDEXRANGESCAN(objectid34)11339TABLEACCESSCLUSTERTAB$12665INDEXUNIQUESCAN(objectid3)33INDEXUNIQUESCAN(objectid33)193TABLEACCESSCLUSTERSEG$387INDEXUNIQUESCAN(objectid9)194TABLEACCESSCLUSTERTS$388INDEXUNIQUESCAN(objectid7)

RowsExecutionPlan0SELECTSTATEMENTGOAL:CHOOSE194SORT(ORDERBY)194NESTEDLOOPS195NESTEDLOOPS(OUTER)195NESTEDLOOPS(OUTER)195NESTEDLOOPS11146TABLEACCESS(BYINDEXROWID)OF'OBJ$'11146INDEX(RANGESCAN)OF'I_OBJ2'(UNIQUE)11339TABLEACCESS(CLUSTER)OF'TAB$'12665INDEX(UNIQUESCAN)OF'I_OBJ#'(NONUNIQUE)33INDEX(UNIQUESCAN)OF'I_OBJ1'(UNIQUE)193TABLEACCESS(CLUSTER)OF'SEG$'387INDEX(UNIQUESCAN)OF'I_FILE#_BLOCK#'(NONUNIQUE)194TABLEACCESS(CLUSTER)OF'TS$'388INDEX(UNIQUESCAN)OF'I_TS#'(NONUNIQUE)



Therowsourceoperationlistinglooksverymuchlikeanexecutionplan.ItisbasedondatacollectedfromtheSQLtracefileandcanbethoughtofasapoormansexecutionplan.Itisclose,butnotcomplete.

TheexecutionplanshowsthesamebasicinformationyoucouldgetfromtheautotracefacilityofSQL*PlusorbyqueryingtheplantableafteranEXPLAINPLANstatementwithonekeydifference.TherowscolumnalongtheleftsideoftheexecutionplancontainsacountofhowmanyrowsofdataOracleprocessedateachstepduringtheexecutionofthestatement.Thisisnotanestimatefromtheoptimizer,butratheractualcountsbasedonthecontentsoftheSQLtracefile.

Althoughthequeryinthisexamplegoesagainstadictionaryviewandisnotterriblyinteresting,youcanseethatOracledidalotofworktogetthe194rowsintheresult:11,146rangescanswereperformedagainstthei_obj2index,followedby11,146accessesontheobj$table.Thisledto12,665nonuniquelookupsonthei_obj#index,11,339accessesonthetab$table,andsoon.

InsituationswhereitisfeasibletoactuallyexecutetheSQLstatementyouwishtoexplain(asopposedtomerelyparsingitaswiththeEXPLAINPLANstatement),IbelieveTKPROFoffersthebestexecutionplandisplay.GUItoolssuchasTOADwillgiveyouresultswithmuchlesseffort,butthedisplayyougetfromTOADisnot100%completeandincertainsituationscriticalinformationismissing.(Again,myexperienceiswiththefreeversion!)Meanwhile,simpleplantablequeryscriptslikemyexplain.sqlpresentedearlierinthispaperorutlxpls.sqldisplayveryincompleteinformation.TKPROFgivesthemostrelevantdetail,andtheactualrowcountsoneachoperationcanbeveryusefulindiagnosingperformanceproblems.AutotraceinSQL*Plusgivesyoumostoftheinformationandiseasytouse,soIgiveitaclosesecondplace.

TKPROFReports:MoreThanJustExecutionPlans

TheinformationdisplayedinaTKPROFreportcanbeextremelyvaluableintheapplicationtuningprocess.OfcoursetheexecutionplanlistingwillgiveyouinsightsintohowOracleexecutestheSQLstatementsthatmakeuptheapplication,andwaystopotentiallyimproveperformance.However,theotherelementsoftheTKPROFreportcanbehelpfulaswell.

LookingattherepetitionofSQLstatementsandthelibrarycachemissstatistics,youcandetermineiftheapplicationismakingappropriateuseofOraclessharedSQLfacility.Arebindvariablesbeingused,oriseveryqueryauniquestatementthatmustbeparsedfromscratch?

Fromthecountsofparse,execute,andfetchcalls,youcanseeifapplicationsaremakingappropriateuseofOraclesAPIs.Istheapplicationfetchingrowsoneatatime?Istheapplicationreparsingthesamecursorthousandsoftimesinsteadofholdingitopenandavoidingsubsequentparses?IstheapplicationsubmittinglargenumbersofsimpleSQLstatementsinsteadofbulkingthemintoPL/SQLblocksorperhapsusingarraybinds?

LookingattheCPUandI/Ostatistics,youcanseewhichstatementsconsumethemostsystemresources.CouldsomestatementsbetunedsoastobelessCPUintensiveorlessI/Ointensive?Wouldshavingjustafewbuffergetsoffofastatementsexecutionplanhaveabigimpactbecausethestatementgetsexecutedsofrequently?

Therowcountsontheindividualoperationsinanexecutionplandisplaycanhelpidentifyinefficiencies.Aretablesbeingjoinedinthewrongorder,causinglargenumbersofrowstobejoinedandeliminatedonlyattheveryend?Arelargenumbersofduplicaterowsbeingfedintosortsforuniquenesswhenperhapstheduplicatescouldhavebeenweededoutearlieron?

TKPROFreportsmayseemlongandcomplicated,butnothinginthereportiswithoutpurpose.(Well,okay,therowsourceoperationlistingsometimesisntveryuseful!)YoucanlearnvolumesabouthowyourapplicationinteractswiththedatabaseserverbygeneratingandreadingaTKPROFreport.



ConclusionInthispaperwehavediscussedhowtogenerateexecutionplansandTKPROFreports,andhowtointerpretthem.Wevewalkedthroughseveralexamplesinordertoclarifythetechniquespresented.WhenyouhaveafirmunderstandingofhowtheOracledatabaseserverexecutesyourSQLstatementsandwhatresourcesarerequiredeachstepoftheway,youhavetheabilitytofindbottlenecksandtuneyourapplicationsforpeakperformance.EXPLAINPLANandTKPROFgiveyoutheinformationyouneedforthisprocess.

Whenisafulltablescanbetterthananindexrangescan?Whenisanestedloopsjoinbetterthanahashjoin?Inwhichordershouldtablesbejoined?Theseareallquestionswithoutuniversalanswers.Inreality,therearemanyfactorsthatcontributetodeterminingwhichjoinmethodisbetterorwhichjoinorderisoptimal.

Inthispaperwehavelookedatthetoolsthatgiveyoutheinformationyouneedtomaketuningdecisions.HowtotranslateanexecutionplanorTKPROFreportintoanactionplantoachievebetterperformanceisnotsomethingthatcanbetaughtinonepaper.Youwillneedtoreadseveralpapersorbooksinordertogiveyourselfsomebackgroundonthesubject,andthenyouwillneedtotrypotentialsolutionsinatestenvironmentandevaluatethem.Ifyoudoenoughapplicationtuning,youwilldevelopanintuitionforspottingperformanceproblemsandpotentialsolutions.Thisintuitioncomesfromlotsofexperience,andyoucantgainitsolelyfromreadingpapersorbooks.

FormoreinformationabouttheEXPLAINPLANfacility,executionplansingeneral,andTKPROF,consulttheOraclemanualentitledOracle8iDesigningandTuningforPerformance.Tolearnmoreaboutapplicationtuningtechniques,IsuggestyoupickupRichardNiemiecstomeonthesubject,OraclePerformanceTuningTips&Techniques,availablefromOraclePress.

AbouttheAuthor

RogerSchraghasbeenanOracleDBAandapplicationarchitectforoverelevenyears,startingoutatOracleCorporationontheOracleFinancialsdevelopmentteam.HeisthefounderofDatabaseSpecialists,Inc.,aconsultinggroupspecializinginbusinesssolutionsbasedonOracletechnology.YoucanvisitDatabaseSpecialistsonthewebathttp://www.dbspecialists.com,andyoucanreachRogerbycalling+1.415.344.0500orviaemailatrschrag@dbspecialists.com.

Still Looking for Help on this Subject?

Get a ConsultationWe would be happy to talk with you about our services and how our seniorlevel database team might helpyou. Call Database Specialists at 4153440500 or 8886480500 or fill out a free consultation requestform. Complimentary NewsletterIf you'd like to receive our complimentary monthly newsletter with database tips and new white paperannouncements, sign up for The Specialist.

Copyright2005DatabaseSpecialists,Inc.http://www.dbspecialists.com

Documents

Explain Plan and Tkprof