ASE15 Optimizer Best Practices v1 051209 WP

TECHNICALWHITEPAPER
SybaseASE15BestPractices: QueryProcessing&Optimization
www.sybase.com
Contents
ExecutiveSummary...................................................................................................................................3
HistoricalOverview ............................................................................................................................................... . 3 What'sNewwiththeASE15OptimizerandQueryProcessingEngine................................................................. 4
UnderstandingASE15'sQueryProcessing...............................................................................................5
Whatisanoptimizationgoal?............................................................................................................................... 5 Optimizationcriteria.............................................................................................................................................. 6 Choosingthebestoptimizationgoalforyourapplication.................................................................................... 6 Experimentingwithoptimizationgoals................................................................................................................. 7 Howtosetsessionleveloptimizationgoals ......................................................................................................... . 8 ParallelqueryprocessinginASE15....................................................................................................................... 8 Performancemonitoringtips................................................................................................................................ 9 Troubleshootingtips.............................................................................................................................................. 9 Using'CompatibilityMode'inASE15.0.3ESD#1................................................................................................ 2 1 Ifallelsefails..................................................................................................................................................... 2 1 ObsoleteoptimizationcommandsinASE15....................................................................................................... 3 1
ResourceRecommendationsforASE15.................................................................................................14
Procedurecache.................................................................................................................................................. 4 1 Procedurecacheusagelimitationin15.0.2ESD#2............................................................................................. 4 1 OtherresourceusageaspectsofASE15............................................................................................................. 5 1
StatisticsInASE15..................................................................................................................................16
WhystatisticsmatterespeciallyinASE15........................................................................................................ 6 1 Recommendation:runupdateindexstatistics.................................................................................................... 6 1 Using'sampling'withupdateindexstatistics...................................................................................................... 6 1 Speedingupupdatestatisticswithparallelism................................................................................................... 7 1 Whentorunupdatestatistics?........................................................................................................................... 7 1 Howmanyhistogramsteps?............................................................................................................................... 8 1 Identifyingmissingstatistics................................................................................................................................ 0 2 OldstatisticsandupgradingtoASE15................................................................................................................ 0 2 Summaryofrecommendationsforstatistics....................................................................................................... 1 2
RecommendedTestingBeforeUpgradingToASE15.............................................................................22
Whyshouldyoutest?.......................................................................................................................................... 2 2 Pleasenote....................................................................................................................................................... 3 2 UsingCompatibilityMode................................................................................................................................... 3 2 Identifyingqueriesthatrunslower..................................................................................................................... 3 2 AnalyzingperformancedifferencesbetweenASE12.xandASE15.................................................................... 3 2 Analyzingshortdurationqueries........................................................................................................................ 6 2 Serverlevelperformanceaspects....................................................................................................................... 6 2
ExampleOfASE15QueryPlanAndLavaTree........................................................................................27
ASE15QueryPlans.............................................................................................................................................. 7 2 Example:setshowplan........................................................................................................................................ 7 2 Example:plancostandLavaTree........................................................................................................................ 0 3
CapturingApplicationSQL ......................................................................................................................32 .
SybaseASE15BestPractices:QueryProcessing&Optimization Version1.1May2009
Auditing............................................................................................................................................................... 2 3 MDAtables(12.5.0.3).......................................................................................................................................... 2 3 ApplicationTracing(15.0.2)................................................................................................................................. 3 3 AbstractPlanCapture/QueryMetricsCapture................................................................................................... 4 3
InformationToCaptureBeforeContactingSybaseTechSupport...........................................................35
701Errors............................................................................................................................................................ 5 3 PerformanceProblemwithaLimitedNumberofQueries.................................................................................. 6 3 SystemWidePerformanceProblemsorHighCPUUsage:step1....................................................................... 7 3 SystemWidePerformanceProblemsorHighCPUUsage:step2....................................................................... 8 3 UploadingdiagnosticstoSybaseTechSupportthroughFTP............................................................................... 9 3
ConclusionsAndRecommendations.......................................................................................................40 ReferenceDocuments.............................................................................................................................41

Principalauthor
RobVerschoor
Contributingauthors
SudiptoChowdhuri BillCox MarkKusma NitinSadalgekar PeterThawley RaymundoTorres NingzhenZhu
RevisionHistory
Version1.0 Version1.1 February2008 May2009 Firstversion CoverCompatibilityModein15.0.3ESD#1;also,minorediting.
2
ExecutiveSummary
HistoricalOverview
WhenSybasefirstbegantodesignitsrelationaldatabasemanagementsystemin1984,theworldofInformation Technology(IT)wasradicallydifferentapplicationsweremonolithicwithdataaccesscodeandbusinesslogic tightlybound;transactionprocessing(OLTP)waspredominatelyabatchprocess;anddecisionsupport(DSS) reportingnever,ever,ranatthesametimeastransactionprocessing.Sybase'spioneeringconceptofclient/server computingwasbasedontwosimpleideas.First,manybusinessescouldofferbetterserviceandvaluetotheir customersiftransactionprocessingweredone"online".Second,businessescouldservicetheircustomersbetter, andthereforegrowfaster,bydecentralizingapplicationdevelopmentandnotusingthemainframe.Toenablethis radicalapproach,Sybasehadtodesignandbuildasubstantiallydifferenttypeofdatabasekerneltosupportthis new"onlineenterprise". SybaseAdaptiveServerEnterprise(i.e.,theproductformerlyknownastheSybaseSQLServer)becametheleading RDBMSproductforhighperformancetransactionprocessingsupportinglargenumbersofclientapplication connectionsonrelativelysmall,inexpensivehardware.Tobesuccessfulinthisdemandingarea,Sybasefocused heavilytooptimizeandstreamlineallthelayersofourdatabaseenginefortransactionprocessingworkloads. WhilethisfocusturnedouttobetheassetthatcatapultedSybasetoadominantpositioninhighendOLTP applicationsduringthe1990's,itincreasinglybecamealiabilityinsomeenvironmentsasapplicationworkloads havechangedandhardwareperformancehasincreased. Withmoreandmoreenterprisesrequiringamixtureofbothtransactionprocessingandoperationaldecision supportreportingonthesamedataatthesametime,itbecameclearthatSybaseneededtorearchitectitsquery processinglayerforthefuture.Sybasebegantheprocessinthe11.9.2releasewhenwerearchitectedthe "bottomhalf"ofthequeryoptimizerthatdealtwiththestatisticsandalgorithmsthatdrivequerycosting.We thenembarkeduponasignificantefforttoreplacethetophalfoftheoptimizerandthequeryexecutionlayerwith onethatcouldmeetthenextgenerationofapplicationrequirements.Equallyimportant,weneededittobemore extensiblesothatinthefuture,wecouldaddsupportfornewindextypesornewjoinstrategiestomorequickly respondtotheneedsofourcustomers.WithASE15,Sybasehasdeliveredthis. Withthishistoricalcontextinmind,itisimportantforcustomersandpartnerswhoarelookingtoleveragethe manybenefitsofASE15.0.xunderstandthesignificanceofthesechanges.Agoodanalogyforhowtoapproach thiseffortisjustlikebreakingintheengineonyournewcar.Shouldyouwinduptheengine'sRPMstothatred lineandcruiseyourfavoritewindingbackroadat100mph?Asmuchassomeofuswouldliketosayyes,Isuspect mostofusknowtherightanswer.Well,usingthenewASE15queryoptimizerandqueryexecutionissimilargo slowerthanyou(oryourboss)wants,learntheimportantcharacteristicsofthesystem,andknowwhattodoin casetheredlightcomeson.Thisdocumentismeanttohelpyouwiththeselasttwo!
What'sNewwiththeASE15OptimizerandQueryProcessingEngine
ThefirstandmostimportantthingtoknowaboutASE15'squeryoptimizerandqueryexecutionengineisthatit's basicallytotallynew.Theshiftinrequirementsovertheyearstowardsmixedworkloads(i.e.,concurrentOLTPand DSSapplicationprofiles)stretchedourtraditionalrelationalprocessingmethodsof"nestedloop"joinstotheir breakingpoint.Ifyouconsiderthefactthatitisnowcommontoseequeriesjoiningten'softableswithmany complexsearchargumentsand/oraggregation,itwasclearthatboththequeryoptimizerandthequeryexecution engineneededamajoroverhaul.Moreimportantly,weneededtodesignasolutiontoensureboththeoptimizer andexecutionenginewouldbeextensible.Thisallowsustoaddnewandinnovativealgorithms(forjoining, grouping,union,etc)andstoragestructures(e.g.indextypes)moreeasilywithoutkludgingexistingcodeand makingitunmanageableorerrorprone.Tofacilitatethemodularityandextensibilityofthequeryexecution engine,wehaverebuilttheexecutionengineusingamoremodern,consumerdriven,iteratorbasedexecution model.Thismodelimplementsrelationaloperatorsasprimitivebuildingblocksandprovidesboththeabilityto easilysolvenagginglimitationsaswellasaddimportantnewjoinstrategiesandoptimizations.Beforewegetinto thedetailsofhowtouseandtroubleshootthenewoptimizerandqueryprocessingengine,let'sfirstgainan understandingofthemajorchangeswhichaffectbothapplicationsandoperations. LongtimeASEcustomerswillappreciatetheeliminationoflimitationswhichallofushavesufferedthrough.Over theyears,Sybasehassteadilybeenreducingtheoccurrenceswhendatatypemismatcheswouldpreventa predicatefrombeingconsideredduringoptimization.Unfortunately,oureffortswere"hardwired"sowehadto addspecialcasecodeforeachandeverycase.Althoughnot"rocketscience",itwasaresourceintensive approachthatdidnotscaleasweaddednewdatatypes.Moreinterestingly,howmanytimeshaveyouwished theoptimizerandQPenginecouldusemultipleindexesonatablethroughindex"union"or"intersection" operations?Well,wishnomore!Now,querieswithANDand/orORpredicatescanpotentiallyusemultiple differentindexesbasedondatadistributionstatistics'estimatedselectivityforeachpredicate. Howaboutthedilemmawefacedinthepastwithoptimizationofqueriesthatjoinedlargenumbersoftables resultedina"lessthanstellar"queryplanduetojoincostingthatdidnotuserealdatadistributionstatistics (histograms)butrather"magicnumbers"fromourengineer'sheads?Now,statisticsforjoins,bothtoderivejoin orderaswellastofeedmoreaccuraterowestimatesintocostingofinnertablesofthejoinorder,shouldbemore accuratebecausewedynamicallycreatejoinhistogramsatoptimizationtime. Whyisallthisimportant?Well,franklyspeaking,it'stoensurethatyoudon'ttreatASE15as"justanother release".Asmuchaswewouldliketosaythatyoucouldsimplyupgradeandpointyourapplicationsatthe upgradedservers,thedepthandbreadthofchangeinoneofthemostfundamentalareasofadatabase,query execution,necessitatesamorefocusedtestingregimen.Thispaperismeanttoprovideyouwiththeclearfacts andbestpracticestoreducethiseffortasmuchaspracticallypossible.
4
UnderstandingASE15'sQueryProcessing
Whatisanoptimizationgoal?
AcentralconceptofASE15'snewqueryprocessingengineisthe'optimizationgoal'.Inessence,thiscanbeseen asahinttotheASEqueryoptimizer,providinganindicationofthenatureofthequerybeingoptimized.To illustratetheunderlyingidea,atypicalOLTPqueryandatypicalDSSquerywillnormallyendupwithverydifferent queryplansduetothedifferentdataaccesspatternsusedbythesequeries.OLTPqueriestendtohitoneorjust veryfewrows,andjoinonlyafewwellindexedtables;DSStypicallyhitsmanyrowsbutreturnsjustafew,andcan joinalargenumberoftables. Becauseoftheirdifferentaccesspatterns,OLTPquerieswilloftenperformbestwhentheyuseaclassicnested loopjoinwhereasaDSSqueryismorelikelytorunfasterwithahashjoin.ByindicatingthataqueryisforOLTPor DSSpurposes,theoptimizermaysaveitselfalotofwork(time,memory,CPU)whengeneratingaqueryplan. ASE15providesthreeoptimizationgoals(orderedfrom'narrow'to'wide',correspondingtothenumberofoptions andstrategiestheyallowtheoptimizertoconsider): allrows_oltp allrows_mix allrows_dss (bestforOLTPqueries) (defaultafterupgradingtoASE15) (bestforDSSqueries)
ThedifferentoptimizationgoalshavethefollowingeffectontheASEqueryoptimizer: allrows_oltpoffersthenarrowestselectionofjoinmethods:thequeryoptimizerisallowedtoconsider nestedloopjoinsonly allrows_mixallowsalsomergejoinstobeconsideredbytheoptimizer,aswellasparallelplans(iftheASE serverisconfiguredforparallelism). allrows_dssoffersthewidestselectionofjoinmethods:alsohashjoinsmaybeconsideredbythe optimizer
Forallrows_mixandallrows_dss,additionallowlevelprocessingalgorithmsareenabledwhicharedisabledfor allrows_oltp. Itshouldbenotedthatwhentheoptimizationgoaliswidened,thequeryoptimizermightusesignificantlymore resources(timeandprocedurecache)togenerateaqueryplan.Iftheoptimizergeneratesthesamequeryplan, withonlynestedloopjoins,underallrows_dssandallrows_oltp,youshouldexpecttheoptimizationunder allrows_dsstotakemoretimeandprocedurecachethanunderallrows_oltp. TheoptimizationgoalcanbedefinedontheleveloftheASEserver,sessionorindividualquery: -- server-wide default: sp_configure 'optimization goal', 0, 'allrows_dss' -- session-level setting (overrides server-wide setting): set plan optgoal allrows_dss -- query-level setting (overrides server-wide and -- session-level settings): select * from T1, T2 where T1.a = T2.b
plan '(use optgoal allrows_dss)' Thesessionleveloptimizationgoalcanalsobesetinalogintrigger;seepage8formoreinformation.
Optimizationcriteria
Anoptimizationgoalisactuallyshorthandforacollectionofon/offsettingsforaseriesofpropertiesknownas 'optimizationcriteria'.Individually,anoptimizationcriterionallows(whenitisenabled)ordisallows(when disabled)theoptimizertoconsideraparticularalgorithm(asforaccessmethods,forjoins,forgrouping,sorting, etc.).Someexamplesofoptimizationcriteriaare: set hash_join on set store_index off -- enables hash joins -- disables reformatting
NotethatSybasedoesnotrecommendusingexplicitsettingsforoptimizationcriteriaunlessadvisedbySybase TechnicalSupport,oraspartofatroubleshootingprocess.Inproductioncode,Sybaserecommendsusing optimizationgoalsinsteadunlessadviseddifferentlybyTechnicalSupport.
Choosingthebestoptimizationgoalforyourapplication
Thechoiceofoptimizationgoalcanhaveabigimpactontheperformanceofyourqueries.Therefore,two importantquestionsmustbeansweredwhenupgradingtoASE15: 1. 2. Whichoptimizationgoalshouldbesetserverwide? Isitnecessarytospecifysessionorqueryleveloptimizationgoalsthataredifferentfromtheserverwide setting?
Sinceitshouldbeconsideredunfeasibletoanalyzeallqueriesinyoursystem,apragmaticapproachshouldbe takentowardstheseissues.Pleasenotethatblindlysettingtheserverwideoptimizationgoaltoallrows_dss (sinceitisthewidestoptimizationgoal)isnotrecommendsincethismayconsumemoreresources,including compilationtime,thanneeded.Itisworthtryingtodetermineifanarroweroptimizationgoalwilldo. Asforthechoiceoftheserverwideoptimizationgoal,twoapproachescanbedistinguished: A. Picktheoptimizationgoalthatprovidesthebestoverallperformanceforyoursystem. Thisshouldbesetsothatitmatchesthetypeofworkloadofthemajorityofyourqueries.Ifyouhavea pureOLTPorpureDSSsystem,thenitisobviouswhichoptimizationgoaltopick. Ideally,youshouldexperimentwiththedifferentoptimizationgoalstoseewhichoneprovidesbest resultsforyourmixofapplicationsandqueries.Seethesection"Experimentingwithoptimizationgoals" forsomesuggestions. B. Justsettheserverwideoptimizationgoaltoallrows_oltpforthesimplereasonthatthis optimizationgoalresemblesthebehaviourofASE12.xmostclosely.Thiswillreducethepossibilityof runningintounexpectedqueryplanissuesafterupgradingtoASE15,butmayalsonotletyoubenefit fromthefullpotentialofASE15'scapabilities. Thesecondissue(theneedforsessionorqueryspecificoptimizationgoalsettings)mayrequiremorework. Whenyouknowthatcertainapplicationshavedifferentworkloadcharacteristicsthantherestofyoursystem,for example,someOLTPworkloadinamostlyDSSsystem,thenitmaybeagoodideatosettheappropriatesession leveloptimizationgoalforthatapplication.Inthisexample,thatwouldmeantheserverwideoptimizationgoal wouldbesettoallrows_dsswhilethesessionleveloptimizationgoalwouldbesettoallrows_oltp. 6
Notethatthiscanquicklybecomeanopenendedundertaking:thereisalmostnolimitontheamountofeffort youcanspendonanalyzingyourqueriesandderivingthebestoptimizationgoalsettingforasessionoran individualquery.Asalways,youhavetostrikeabalancebetweenperformancegainsandeffortspentwhen engaginginperformancetuning.
Experimentingwithoptimizationgoals
Asexplainedabove,youneedtopickanoptimizationgoaltosetasyourserverwidedefault.Theeasiestapproach isjusttopickone,seehowthingsbehaveoverall,andtryanotheronetoseeifthat'sanybetter.Whenusing storedprocedures,makesuretorunsp_recompileonalltables,orrebootASE,afterchangingtheserverwide optimizationgoalinordertomakeittakeeffectbyrecompilingexistingplans.Also,makesurethestatement cacheisdisabledtogetagoodcomparison. Whilethisapproachmaywork,itisperhapsagoodideatomakeamoreinformeddecisionabouttheoptimization goaltouse.Fortunately,thisisnottoodifficult.First,youneedtocollectorcapturearepresentativesetofreal lifeSQLqueries,forexample,throughtheMDAtables,orwithauditingorMonitorServer(forsomesuggestions, seepage32).Putallthesequeriesinafileasseparatebatches,with'go'toterminateeverybatch,justasyou'ddo whenusingisql.Then,putthefollowingatthestartofthefile: set plan optgoal allrows_oltp go set showplan on set statistics time, io on go rest of file Nowrunthisfilethroughisqlandcapturetheoutputinanotherfile: isql -U username -P passwd -S YOUR_15_SERVER -e -i your_file > output_file Timehowlongittakesbeforetherunhascompleted. Repeatthiswiththeoptimizationgoalabovechangedtoallrows_mixandallrows_dss,sothatyouhave threeoutputfilesofqueryplanoutput. Fromthecompletiontimesofthedifferentruns,itmaybeimmediatelyapparentwhichoptimizationgoalprovides thebestresultoverall,andthatmightbeacandidatefortheserverwideoptimizationgoalsetting. However,itwillbeinterestingtocounthowmanytimeseachjointypehasbeenchosen.Thiscanbedonequickly withgrepforeachoftheoutputfiles: grep -c "NESTED LOOP JOIN" <filename> grep -c "MERGE JOIN" <filename> grep -c "HASH JOIN" <filename> Supposethereappeartobejustafewhashjoinsusedwhentheoptimizationgoalwassettoallrows_dss.For thequeriesusingahashjoin,itwouldbeworthcheckingiftheyranmuchslowerwiththeotheroptimization goals.Withtheapproachabove,thiswillberelativelyeasytocomparesinceset statistics timewas enabled,theelapsedtimeforeachquerywillbeintheoutputfile.Ifitturnsoutthat,forthosespecificqueries,
hashjoinsmakeabigdifferenceindeed,youcouldconsidersettingthesessionspecific,orevenqueryspecific, optimizationgoalforthosequeriestoallrows_dss.If,ontheotherhand,thereappeartobemanyqueries usingahashjoin,andallrows_dssturnsouttoprovideverygoodperformanceoverall,perhapsitisbettertoset theserverwidegoaltoallrows_dssinstead. Withthisapproach,itisrelativelyeasytogetanideaoftheimpactofusingdifferentoptimizationgoals.Ofcourse, thequalityoftheresultsdependsonhowrepresentativethesampledqueriesare. Whenrunningtestslikethese,makesurethestatementcacheisdisabled(eitherbysettingtheconfiguration parameter"statement cache size" to0,orbyrunningset statement_cache offatthestartof yoursession).Also,whenusingstoredproceduresbeforererunningwithadifferentoptimizationgoal,run sp_recompileonalltables,orrebootASE,afterchangingtheserverwideoptimizationgoalsoastomakesure thenewgoaltakeseffect. Whencomparingperformanceofqueriesunderdifferentoptimizationgoals,especiallywhenarebootisinvolved, makesuretotestundercomparablesituationswithrespecttodatacacheusage.Itdoesnotmakesenseto compareaquerywheremostdataneedstobereadfromdisk,withaquerywheremostdataisalreadyinthedata cache.Ingeneral,itisbesttocomparequerieswitha'warmcache',wherebythequeryisrunonceortwice withoutmeasuringitsperformance,followedbythefinalmeasurementrun.
Howtosetsessionleveloptimizationgoals
Let'sassumeyouhavedeterminedthataparticularapplicationwouldbenefitfromusingallrows_mixwhile theserverwidegoalissettoallrows_oltp.Howdoyouimplementthis?Initssimplestform,youmodifythe applicationtomakeitexecutethestatementset plan optgoal allrows_mixbeforesubmittingany otherstatements.However,itmaynotbepossible,orimpractical,tomodifytheSQLcodesubmittedbyan existingapplication. Fortunately,thereisaneasysolution:youcansetthesessionleveloptimizationgoalinalogintriggerwithset plan optgoal.Thisway,theoptimizationgoalforasessioncanbesetasdesired,withoutchangingany existingapplicationcode.PleaserefertotheASESystemAdministrationGuideformoreinformationaboutlogin triggers:chapter"ManagingUserPermissions",section"Rowlevelaccesscontrol",subsection"Usinglogin triggers"(thoughpleasenotethatlogintriggerscanbeandusuallyareusedindependentlyofrowlevelaccess control,asisindeedthecaseforsettingsessionleveloptimizationgoalasdescribedabove).
ParallelqueryprocessinginASE15
Sinceversion11.5,ASEhassupportedintraqueryparallelism,wherebyasinglequeryisprocessedbymultiple workerprocesses.ManySybasecustomershaveusedparallelism,usuallytoimproveresponsetimesforDSStype queries.Forthistypeofquery,wherealargenumberofrowsareaccessedbutonlyasmallresultsetisreturned, parallelismtendstobemostefficientinpre15.0.Parallelqueryprocessingtendstorequiresignificantlymore resources(CPU,memory,diskI/O)thanserialprocessing,butwhensuchresourcesareavailableparallelismmay deliverbetterperformanceforspecificqueries. ASE15alsosupportsparallelism,butinadifferentwaythanpre15versions.Withoutgoingintotoomanydetails thatwouldexceedthescopeofthisdocument,insummarywecansaythatparallelisminASE15canoccurat morelevelsinsideaquerythaninpre15.Inaddition,parallelisminASE15isdesignedforuseinconjunctionwith semanticallypartitionedtables,whichpre15didnotsupport. SincethenewqueryprocessingfeaturesofASE15offerpotentialperformancebenefitsforDSStypequeriesin particular,SybaserecommendstoinitiallynotuseparallelprocessingwhenupgradingtoASE15,evenwhen parallelismwasusedinASE12.x.Sinceserialprocessingismoreresourceefficientthanparallelprocessing, avoidingparallelismmayallowyoutodeliverbetteroverallperformancewiththesamehardware.Itmaywellbe, andhasindeedbeenobservedbycustomers,thatASE15inserialmoderunsqueriesfasterthanASE12.xwith 8
parallelism.Forthesereasons,bestexploreASE15'scapabilitiesinserialmodefirstbeforelookinginto parallelism.ForDSStypequeries,whereparallelismwasoftendeployedinASE12.x,itisspecificallysuggestedto lookintotheeffectsoftheoptimizationgoalallrows_dss. Parallelismmaydeliverbetterresponsetimesthanserialprocessingforqueriesusingsemantictablepartitioningin ASE15,orforDDLcommands(likecreate index).Forsuchcases,itmaybeworthwhiletoexploretheimpact ofparallelisminASE15.
Performancemonitoringtips
Thissectioncontainssomesuggestionsformonitoringperformanceaspectsofyourqueries.Theserequirethe MDAtablestobeinstalledandenabled.
TodetermineifanysessionsarecurrentlyexecutingqueriesthatconsumealotofdiskI/O,use sp_monitor: sp_monitor "connection", "diskio"
Tofindsessionswithlongrunningqueries,replace"diskio" by"elapsed time".TofindCPU intensivequeries,replace"diskio"by"cpu".Notethatsp_monitorhasmanyotherhandy options;usesp_monitor "help",andseetheASEdocumentationfordetails. Toidentifythetop20ofrecentlyexecutedstatementswithrespecttoLogicalI/O,usethisquery: select top 20 SPID, CpuTime, LogicalReads, PhysicalReads, ProcName=object_name(ProcedureID,DBID), MemUsageKB, StartTime, EndTime, DurationSecs = datediff(ss, StartTime, EndTime), KPID, BatchID from master..monSysStatement order by LogicalReads desc Tofindthetop20queriesforCPUconsumption,changetheorderbyclausetosortonCpuTimeinstead. Tofindthetop20longrunningqueries,sortontheduration("order by 9 desc"). TofindtheSQLtextcorrespondingtothesestatements,usetheKPIDandBatchIDcolumnstoquery themonSysSQLTexttable.NotethatmonSysSQLText,likemonSysStatement,isasocalled "historical"MDAtable,meaningthatitcontainsonlyalimitedamountofhistory.Tocaptureinformation fromthesetablesoverlongerperiodsoftime,youshouldfrequentlyselectfromtheseMDAtablesand storetheresultsetinapermanenttable.
Troubleshootingtips
ASE15wasdesignedtoofferagreatlyimprovedqueryprocessingenvironment.Intherareeventthatqueryplans orqueryperformancearenotwhatyouexpect,herearesomethingstotrytoisolatetheproblem. Whenexperimentingwithdifferentoptimizationgoals,makesurenocachedplansareused:changingthe sessionlevelorserverwideoptimizationgoalwillnotcausecachedplanstoberecompiled. Forstoredprocedures,eitherexecutethemwith recompile,orrunsp_recompileononeofthe
tablesbeingaccessed.Forbatches,makesurethestatementcacheisdisabledbyrunningset statement_cache offfirst. Whenusingdifferentsessionleveloptimizationgoalsinasinglebatchorstoredprocedure(i.e.set plan optgoalstatements),ensuretoberunning15.0.2ESD#2orlater.Thisisrecommendedbecause someaspectsofsessionleveloptimizationgoalswerechangedinthatrelease,makingthefeaturemore intuitiveandeasiertouse. Fulldetailsonthescopeandsemanticsofsessionleveloptimizationsettings,willbedescribedinanother whitepaper,titles"ChangestoscopeandsemanticsofsessionleveloptimizationsettingsinASE15.0.2" (seeURLonpage41). Whenyouwanttoguaranteethatastoredprocedureisalwaysoptimizedwithaparticularoptimization goal,irrespectiveofanyserverwideorsessionlevelsettings,putset plan optgoal allrows_xxxasthefirststatementinthebodyofthestoredprocedure.ThisrequiresASEversion 15.0.2ESD#2orlater. Ifitissuspectedthatmergejoinsarecausingsuboptimalperformanceinyoursystem,andaserverwide optimizationgoalisallrows_dss,youcouldchangethissettingtoallrows_oltp.However,this alsoimpliesthathashjoinscannolongerbeused. In15.0.2orlater,ifyoudon'twanttolosethepossibilitytousehashjoins,youcanalsokeep allrows_dssastheserverwidegoal,andsettheconfigurationparameter'enable merge join' to0;thiswilldisablemergejoinsserverwideforalloptimizationgoals. IfyourSQLcodefromASE12.xcontainsexplicitlyforcedjoinorders(withset forceplan),these forcingsshouldideallybereevaluatedwhenupgradingtoASE15(asSybasehasalwaysrecommended whentalkingaboutsuchforcings).Ofcourse,ifyoursystemrunstofullsatisfactioninASE15,theremay benoneedtochangeexistingforcings.However,theymayalsostopyoufromtakingfullbenefitofthe capabilitiesofASE15.Itisthereforerecommendedtoevaluatetheimpactofremovingtheseforcings.If thisisimpractical,in15.0.1ESD#2orlater,traceflag15307canbeenabledtonullifytheeffectofanyset forceplanstatementswhenqueryplansarecompiled. Likewise,anyexplicitforcingsforindexesorforprefetch/parallelism/bufferreplacementstrategycanbe nullifiedbyenablingtraceflag15308. Traceflags15307and15308canbesetatboottime.Theycanalsobeenabledwithdbcc traceon,but notethattheireffectisserverwide,soallsessionsareaffected. Notethatbothtraceflagsdonotaffectanyqueryplanpropertiesdefinedbyabstractqueryplans. Ifyoursystemseemstobeconsuminganunreasonableamountofspaceintempdb,youcanusethe MDAtablestoseeifoneparticularsessionconsumesalotofspaceinaworktable. AssumingtheMDAtablesareenabled,runthefollowingquery: select SPID, DBName, ObjectName, PartitionSize from master..monProcessObject where DBID = tempdb_id(SPID) order by SPID LookforsessionsthathavealargevalueforPartitionSize.WorktableshaveanObjectNameof 'temp worktable'.Byqueryingmaster..monProcessSQLTextand/or master..monProcessStatementyoucanfindthecorrespondingSQLstatementforthe correspondingsessions.Tostopsessionsfromfillinguptempdb,andthusaffectingothersessionsalso requiringtempdbspace,youcancreatearesourcelimitoftype'tempdb_space'.Anotherpossible
10
remedyiscreatingmultipletemporarydatabasesandassigningthesetospecificusers.SeetheASE documentationforfurtherdetailsonthesefeatures. Ifyouencounteraslowqueryandyoususpectthatreformattingiscausingthesuboptimalperformance, firstfollowtherecommendationswithrespecttostatistics(seepage21).Ifthereformattingpersistsand performanceremainsunsatisfactory,youcanverifywhetherdisablingreformattingimprovesthingsas follows: set store_index off go select go Or: select -- your query plan '(use store_index off)' Beforeusingindividualoptimizationcriteriasettingsinproductioncode,Sybaserecommendsverifying thissolutionwithTechnicalSupport. Underallrows_dss,ifyouencounteranunreasonablyslowquery,orifthequeryrunsintoa701error duringoptimization,firstfollowtherecommendationswithrespecttostatistics(seepage21).Iftheissues persist,tryifthefollowingsolvestheproblem: set bushy_space_search off -- relevant only under allrows_dss! go select -- your query go Or: select -- your query plan '(use bushy_space_search off)' Beforeusingindividualoptimizationcriteriasettingsinproductioncode,Sybaserecommendsverifying thissolutionwithTechnicalSupport. WhenrunninglargenumbersofidenticalorverysimilarclientgeneratedSQLqueries(i.e.notstored procedures,andalsonotinexecuteimmediate)wherethedifferenceliesinthesearchargument(i.e.a differentprimarykeyvalue),andyou'rerunning15.0.1orlater,considerenablingthestatementcacheas wellasliteralautoparameterization.Thesemaysignificantlyreducethetimeandresourcesspenton queryoptimizationandthereforeimproveoverallperformance. LiteralautoparameterizationisanenhancementtothestatementcacheinASE15.0.1orlater.Whenthe statementcacheisenabled,aquery'splanwillbecachedsothatanexactlyidenticalquerydoesnotneed tobecompiledagain,butthecachedplancanbeusedinstead,savingtimeandresources.Withliteral autoparameterizationenabled,thiscachingisextendedtoalmostidenticalqueriesthatdifferonlyina constantvalue.Forexample,takethesetwoqueries:
-- disables reformatting -- your query
11
select CustName from Customers where CustID = 123 select CustName from Customers where CustID = 456 Thesequeriesarenotidentical,buttheyarelikelytoendupwiththesamequeryplan.Enablingliteral autoparameterizationhastheeffectthatthestatementcachefactorsouttheconstantvalueinthe whereclauseandcachesaplanforallquerieslookinglikethis: select CustName from Customers where CustID= <integer-constant> Thismeansbothqueriesabovewouldusethesamecachedqueryplan. Literalautoparameterizationcan greatlyimprovetheeffectivenessofthestatementcache,andthereforeitisrecommendedtoexperiment withthisfeatureifyourapplicationsusemanyalmostidenticalSQLqueriesthatarenotpartofstored proceduresandarenotruninexecuteimmediate. Thestatementcacheisenabledseverwidewiththeconfigurationparameter'statement cache size'.Onsessionlevel,thestatementcachecanbedisabledwithset statement_cache off. Literalautoparameterizationisenabledserverwidewiththeconfigurationparameter'enable literal autoparam',andonsessionlevelwithset literal_autoparam on(oroff).It appliesonlywhenthestatementcacheisenabledtoo.
Using'CompatibilityMode'inASE15.0.3ESD#1
ForcustomerswhoprefertolimittherequiredtestingeffortforupgradingtoASE15,Sybasehasintroducedanew featurenamed'CompatibilityMode'inASE15.0.3ESD#1. CompatibilitymodeisaqueryprocessingenhancementallowingqualifyingTSQLqueriestobeprocessedwitha methodofqueryoptimizationandqueryexecutionverysimilartothatusedinASE12.5,insteadofusingtheASE 15queryprocessingalgorithms. Compatibilitymodeisnotanoptimizationgoal,butaqueryprocessingoptiononahigherlevelwhichdetermines whether12.5likeoptimizerandqueryexecutionlogicwillbeused(whichexcludeallASE15features),orwhether theASE15featuresareused;inthelattercase,theconsiderationsintherestofthisdocumentapply. Compatibilitymodehasbeenmadeavailabletocustomerstoprovidemorecontrolovertheprecisemomentwhen ASE15specificqueryprocessingfeaturesbecomeactiveintheirqueriesandapplications,thusallowinggradual introductionofASE15queryprocessingaspectsaftermigratingtoASE15.Consequently,therequiredtesting effortcanbebetterfocusedandplannedthanwhenmigratingtoASE15withoutusingcompatibilitymode. Itshouldhoweverbenotedthat,asaconsequenceofusingcompatibilitymode,applicationsmaynotbeableto fullybenefitfromthequeryprocessingenhancementsofASE15.Thisisaconsciouschoicethatcustomerswill needtomakewhenusingcompatibilitymode. Itisexpectedthatcustomers,afterhavingmigratedtoASE15,willeventuallydisablecompatibilitymodesoasto takefulladvantageoftheperformanceimprovementsinASE15. Forfulldetailsoncompatibilitymode,pleaserefertothewhitepaper"Using'CompatibilityMode'InASE15.0.3 ESD#1ForASE15Migration"(seeURLonpage41).
Ifallelsefails
IncasenoneofthesuggestionsinthecurrentdocumenthelpyoutoresolvequeryperformanceissuesinASE15, SybaserecommendsthatyouupgradeyourASEinstallationtothelatestESDavailableforyourplatform.As always,Sybaseismakingcontinuousproductimprovementsandyourissuemayalreadyhavebeenfixedinalater ESDthanyouarecurrentlyrunning.Ifyourproblemstillpersists,youshouldopenacasewithSybaseTechnical 12
Support.Pleaserefertopage35forguidanceabouttheinformationtocollectbeforecontactingTechnical Support.
ObsoleteoptimizationcommandsinASE15
Variousoptimizationrelatedsettingsfrom12.xarenolongerwhenusingtheASE15queryprocessingfeatures. AlthoughthefollowingcommandsstillexistinASE15,theydonotperformanyfunctionanymore,andsimply returnasuccessstatus: set sort_merge:inASE15,replacedbyset merge_join,optimizationgoalsandthe configurationparameter'enable merge join'(in15.0.2) set jtc:JoinTransitiveClosureisalwaysenabledinASE15 set table count:nolongerappliesinASE15
Inaddition,thefollowingfeaturesnolongerapplyinASE15: configurationparameter'enable sort-merge join and JTC':replacedbyoptimizationgoals andbytheconfigurationparameter'enable merge join'(in15.0.2). boottimetraceflags334and384,whichenabledmergejoinsandJTCindividually,nolongerhaveany functioninASE15.
However,notethatwhenusingcompatibilitymode(seepage12),thenthesecommandsandfeatureswillstill functionasinpre15.0forthosestatementsthatareprocessedinfullcompatibilitymodeorrestricted compatibilitymode.ForstatementsthatareprocessedusingASE15mode,thesecommandsarenoopsas describedabove.
13
ResourceRecommendationsforASE15
Procedurecache
OneoftheconsequencesoftheredesignedqueryprocessingengineinASE15isthatASErequiresmoreprocedure cache.Thisincreasedmemoryrequirementappliestooptimizationandexecutionofqueries. OnereasonforthisincreasedrequirementisthatASEhasmanymorejoinmethodsanddataaccessalgorithmsto considerthanpriortoversion15.Thisisespeciallytrueforallrows_dss,whichwillgenerallytendtowards consumingmoreprocedurecacheforqueryoptimizationthanallrows_mix,whichinturnusuallyneedsmore procedurecachethanallrows_oltp. ItisdifficulttopredictexactlyhowmuchmorememoryASE15willneedcomparedwith12.5.Asaruleofthumb, SybaserecommendstoplanforsizingoftheprocedurecacheinASE15between2to6timeslargerthaninASE 12.5.Whenallrows_dssisused,itislikelythatmoreprocedurecachemaybeneededthanwhen allrows_oltpisused.Usethe'procedurecache'sectionofsp_sysmontomonitorprocedurecacheusage.
Procedurecacheusagelimitationin15.0.2ESD#2
InASE15.0.2ESD#2,alimitationwasimplementedontheamountofprocedurecachethatcanbeusedbytheASE queryoptimizer.Thisisbasedonthesettingofconfigurationparameter'max resource granularity' (settableonsessionlevelwithset resource_granularity).Thissettingisanintegerbetween1100, reflectingapercentage.Thedefaultsettingis10. Thisfeatureworksintwoways.First,whentheoptimizerhasconsumedmoreprocedurecachethan: <max_resource_granularity> 100 <configured procedure cache size> andwhenatleastonefullplanhasalreadybeengenerated,theoptimizerwilltimeoutandusethecurrentbest planasthefinalplan. Second,whentheoptimizerhasnotbeenabletogenerateafullplanyet,buthasalreadyconsumedanamountof procedurecacheof: max(50, <max_resource_granularity>) 100 <configured procedure cache size> thentheoptimizerabortsthequeryplangenerationtoavoidconsumingalloftheprocedurecache.Sincethe queryhasstillnoplan,itsexecutionwillthenfail. Thisnewbehaviourwasintroducedin15.0.2ESD#2.Itcanbedisabledwithtraceflag15380. 14
OtherresourceusageaspectsofASE15
OneofthenewaspectsofASE15isthefeatureoftablepartitions.Althoughsemanticdatapartitioningisan optionallicensefeature,itmattersevenwhenyoudonotusesemanticdatapartitioning:inASE15,eachtableand indexalwaysconsistsofatleastonepartition.Consequently,theconfigurationparameter'number of open partitions'mustbesethighenoughtoavoidunnecessaryperformancepenalties. Sybaserecommendsusingsp_countmetadatatoestimatetherequiredsettingforthisparameter,anduse sp_monitorconfigtomonitoritsusage(seepage26).
15
StatisticsInASE15
WhystatisticsmatterespeciallyinASE15
ASEusesacostbasedqueryoptimizertochoosethebestplanforaparticularquery.Toachievethatgoal,the optimizerreliesonstatisticsaboutthetables,indexes,partitions,andcolumnsreferencedinaqueryforestimating thecostintermsofI/OandCPUtimeofdifferentpossiblequeryplans.Theoptimizerthenchoosesthequery planmethodthathasthelowestcost.However,thiscostestimatecannotbeaccurateifthestatisticsthemselves arenotaccurate.Asaresult,inaccuratestatisticscouldleadtoasuboptimalchoiceofplansandresultinslower performancethannecessary. Somestatistics,suchasthenumberofpagesorrowsinatable,areupdatedautomaticallyduringqueryprocessing (thesearestoredinsystabstats).Otherstatistics,notablythehistogramsoncolumns,aswellasdensity information,(bothstoredinsysstatistics),areupdatedonlywhenupdate statisticsruns,orwhen indexesarecreated.Inpractice,itiscriticalthatthehistogramsbeuptodate.ItisaDBAresponsibilityto scheduleandrunupdate statistics. InASE15,havinguptodatestatisticshasbecomeevenmoreimportantthanitalreadywas. ASE15ismoresusceptibletostatisticsissuesthanpreviousASEreleasesduetonowhavingmultiplealgorithmsfor sorting,grouping,unions,joiningandotheroperations,thusofferingtheoptimizermanymorepossiblechoices.In addition,ASE15usesstatisticsinmorewaysthaninASE12.x,forexamplefordeterminingthejoinorderinmulti tablequeries.Goodstatisticsarethereforeimportanttohelpavoidgeneratingasuboptimalqueryplan.
Recommendation:runupdateindexstatistics
ItisrecommendedtomaintainuptodatehistogramsforallcolumnsreferencedinWHEREclauses,eitherasjoin predicatesorassearcharguments.Sincethesecolumnsaretypicallypartofanindex,inpracticethismeansthat runningupdate index statisticsforallusertablesislikelytodothejob.Ifsuchcolumnsarenotpartof anindex,youshouldatleastgeneratehistogramsforthesenonindexedcolumns,orconsiderindexingthem. Comparedwithupdate statistics,runningupdate index statisticsalsogenerateshistogramsfor thenonleadingindexcolumns,whichprovidestheoptimizerwithmoreinformationtogenerateoptimalquery plans.However,update index statisticshassomepotentialdisadvantagescomparedwithupdate statistics.Sinceitneedstoperformasortoperationforeverynonleadingindexcolumn(theleadingindex columnisalreadysortedintheindextreebydefinition),update index statisticswilltakemoretimeand resourcestorunthanupdate statistics.
Using'sampling'withupdateindexstatistics
Onepossibleconsequenceisthatupdate index statisticsmayrunintoa701errorwhenthetableistoo largetoperformthesortforacolumnwiththeavailableamountofprocedurecache. Whenthishappens,theremedyapartfrompossiblyincreasingthesizeoftheprocedurecacheistorun update index statistics withthe"sampling"option.Insteadofreadingthecolumnvaluesfortheentire table,onlyapercentageofthetablewillberead.Thismakessensesincethefinalhistogramforalargetableis basedonjustafractionofthecolumnvaluesread.Apositivesideeffectisalsothatupdate index statisticswithsamplingrunsfasterthanwithoutsampling,soitmayalsobeusedforlargetableswhen update index statisticstakestoolongtorun.Notethatwhenusingsampling,thereisalwaysa
16
possibilitythatthehistogramcontainslessaccurateinformationthanwhenthefulltablewasread.However,this potentialdownsideisdifficulttoquantify. Inthefollowingexample,onlyabout5%ofthetableisreadforcreatingthehistogramsfornonleadingindex columns: update index statistics big_table with sampling=5 Thelowestpossiblevalueforsamplingis1%.Settingthepercentageto0isequivalentto100%. Intheoptdiagoutput,thesamplingpercentageusedisdisplayedas"SamplingPercent:"(0means:nosampling used). Insteadofspecifyingthesamplingpercentageexplicitly,adefaultsamplingpercentagecanalsobeconfigured serverwide,bymeansoftheconfigurationparameter"sampling percent".However,thissettingwillapply toallusertablesandthatmaynotalwaysbedesirable.
Speedingupupdatestatisticswithparallelism
Itmaybepossibletospeedupupdate statisticsfornonleadingindexcolumnsornonindexedcolumnsby usingparallelism.Forsuchcolumns,histogramcreationrequiresthatallcolumnvaluesbesortedfirst.By performingthissortoperationwithparallelworkerthreads,theruntimeofupdate statisticscanoftenbe improved(assumingyoursystemhasenoughresourcestouseparallelism). Touseparallelsorting,specifythewith consumersclause: update index statistics big_table with consumers=20 -- use 20 worker processes for the sort Exactlyhowmuchimprovementcanbeachievedwithparallelism,andwhatlevelofparallelismwouldbeoptimal, highlydependsonthespecificsystemhardware,ASEconfigurationandworkload.Youshouldexperimentto determinewhatworksbestforyoursituation. Notethatparallelismforupdate statisticsdoesnotapplytothetablescanorindexscanwithwhichthe columnvaluesareretrieved.
Whentorunupdatestatistics?
Statisticsshouldbeanaccuratereflectionofthedatainatable.Thisimpliesthatstatisticsmayneedtobeupdated whendataischangedmorefrequently.Oneexampleisadatetimecolumn,holdingthedatethatarowwas inserted.Anotherisanidentitycolumn,whichwillcontinuouslyinserthighervalues.Forthesetypesofcolumns, histogramswillquicklybecomeoutofdate,sinceallnewrowsbeinginsertedwillhavevalueshigherthanthe previousmaximumvalueinthehistogram.Thismaycontributetotheoptimizergeneratingsuboptimalquery plans. ASE15offersanewfeaturetoassistindecidingwhetherupdate [index] statisticsmaybenecessary foratable.Thenewbuiltinfunctiondatachange(table_name, partition_name, column_name) functionmeasurestheamountofchangeinthetable(orpartition)sincethelasttimeupdate [index] statisticswasrun.Dependingonthispercentage,youmaydecidetorun update [index] statisticsmore,orless,frequently. Specifically, datachange()measuresthenumberofinserts,updates,anddeletesthathaveoccurred onthegiventable,partition,orcolumn.Thisinformationhelpsyoudetermineifrunningupdate [index] statisticsmaybeneeded.
17
Anexampleofthedatachange()functionis: 1> select datachange('my_table', null, null) 2> go --------------------------243.340418 Inthisoutput,thepercentageofchangestothetablemy_tableis243%,meaningthatthenumberofchangesis higherthenthenumberofrowsinthetable.Thisindicatesthatitisagoodcandidatetorunupdate [index] statisticsnow. Thedatachange()builtinfunctioncanalsoberunonindividualcolumns: 1> select datachange('my_table', null, 'id_number') 2> go --------------------------0.017761 Theresultof0.017%indicatesthattheid_numbercolumnhashadarelativelylowamountofchange,and thereforethestatisticsforthatcolumnarestilllikelytobeaccurate.Itisgoodpracticetorundatachangeona regularbasisagainstcommonlyusedtablesandcolumns.Thisgivesabasisfordeterminingwhenitisusefultorun update [index] statistics.Lastly,byspecifyingthesecondparameterofdatachange(),whichisa partitionname,onlythechangesforthatpartitionarereported.Youmayneedtousesp_helptodeterminea table'spartitionnames. ASEhasthefunctionalitytoautomaticallycheckobjectsusingdatachange(),andscheduleupdate [index] statisticsaccordinglyusingASE'sbuiltinjobschedulerfeature.Formoredetailsonsettingup andusingthisfunctionality,pleaserefertothe15.xmanualtitled"PerformanceandTuningSeries:Query ProcessingandAbstractPlans".Inchapter6,"UsingStatisticstoImprovePerformance",refertothesectiontitled "Automaticallyupdatingstatistics". NB.Forpartitionedtables,itispossibletorunupdate [index] statisticsonanindividualpartition. Whilethatmayallowyoudividealongrunningupdate statisticsrunforalarge,partitionedtableinto multipleshorterruns,keepinmindthatupdatingstatisticsonapartitiononlyupdateshistogramsonlocalindexes forthatpartition:histogramsforglobalindexesonthetablewillnotbeupdated.
Howmanyhistogramsteps?
Anotherissueishowmanystepsahistogramshouldhaveinordertoprovidetheoptimizerwithanaccurate reflectionofthedatadistributioninacolumn.Thedefaultof20histogramstepsmaybeadequateforcolumns withasmallnumberofdistinctvalues("lowcardinality"),orfortableswithasmallnumberofrows.However,for tableswithalargenumberofrows,havingcolumnswithmanydistinctvalues20stepsmaybeinsufficient.Thisis especiallytruewhenacolumnhasahighdegreeofdataskew(thatis,thevaluesforthecolumnarenotevenly distributedovertherows). Obviously,ifyoursystemrunstofullsatisfactionwith20histogramsteps,donotchangeanything.However,ifyou suspectsuboptimalqueryplansarebeinggenerated,youmaywanttoconsiderincreasingthegranularityof histogramsbyincreasingtheirnumberofstepsanddeterminewhetherthathasapositiveeffect.Asalways,there canbetoomuchofagoodthing.Increasingthenumberofhistogramstepscanleadtohigherresource consumption,especiallyprocedurecacheusage,andlongeroptimizationtimesbeforeaqueryplanisgenerated. 18
DuetotheoptimizationtimeoutlimitfeatureinASE15,thiscaninturnalsoresultinsuboptimalplansbeing generated. Exactlyhowmanystepsahistogramshouldhaveishardtopredict.Inpractice,youneedtoseeifahighernumber ofhistogramstepsresultsinbetterqueryplansandbetteroverallperformance. Nevertheless,asapracticalguidelineitmaybeusefultostartbyincreasethestepcountto200.Ifthatdoesnot havethedesiredpositiveeffect,tryahighernumber,like500.Analternativeguidelineistouseonehistogram stepforevery10,000datapages.However,morethan10002000histogramstepsisgenerallyconsideredtoohigh anumber:ifnopositiveeffecthasbeenachieved,thehistogramstepsmaynotcontainthesolutiontoyour problem. Thenumberofhistogramstepsisdeterminedwhenupdate [index] statisticsisexecuted.Thisisdone asfollows: Theconfigurationparameter'number of histogram steps'definesthedefaultforallcreate indexandupdate [index] statisticscommandsfornewhistograms.Theoutofthebox defaultis20. Forupdate [index] statistics,thenumberofstepscanalsobesetexplicitlywiththeclause using nnn values: update index statistics big_table using 300 values Forexistinghistograms,update [index] statisticsusesthecurrentnumberofstepsinthe existinghistogramwhengeneratinganewhistogram.Theconfigurationparameter'number of histogram steps'doesnotapplytoexistinghistograms.Onlywhenupdate [index] statistics explicitlyspecifiesusing nnn values,willthestepcountintheexistinghistogram beoverridden,andnnnbeusedasthenumberofstepsforthenewhistogram. Thenumberofhistogramstepsestablishedatthispointisthetargetnumberofstepsforthehistogram. Intheoptdiagoutput,thisisdisplayedas"Requestedstepcount:". Next,the'histogram tuning factor'comesintoplay.Thisconfigurationparametermultiplies thenumberofstepsdeterminedaboveforthepurposeofgeneratinganinternal,intermediatehistogram first.If100histogramstepsarechosen,and"histogramtuningfactor"issetto20,thentheintermediate histogrammayhaveasmanyas2000steps.Thisisdonetoincreasethechanceofidentifyingsocalled "frequencycells",whichreflectduplicatedatavalues.Ifnofrequencycellsarefound,thehistogramis compressedbacktotheoriginalnumberofsteps;iffrequencycellsarefound,thesearekept.Theactual numberofresultinghistogramstepsisdisplayedintheoptdiagoutputas"Actualstepcount:". Priorto15.0.1ESD#1,the"histogram tuning factor"wassetto1bydefault.Asof15.0.1 ESD#1,theoutoftheboxdefaulthasbeenincreasedto20duetopositiveexperienceswiththisfeature. Thehistogramtuningfactorcanrangefrom1to100;however,itisrecommendedtosetit(orleaveitset at)20unlessadviseddifferentlybySybaseTechnicalSupport.Toavoidunexpectedexcessivelylargestep counts,andcorrespondingprocedurecacheusage,whencustomersupgradefrom12.5to15,asof15.0.2 ESD#2,thefollowingformulaisusedwhenhistogramtuningfactorisstillsettothedefaultof20: min( max (400, requested_steps), histogram_tuning_factor * requested_steps)
19
Thisformulahastheeffectofassumingthat'histogram tuning factor'issetto1(aswaslikely thecaseforthosecustomersbeforetheyupgradedto15).
Identifyingmissingstatistics
ASE15hasanewfeaturetoflagcaseswherenostatisticsexistforcolumnswheretheoptimizerwouldhave expectedthem.Whenrunningthecommandset option show_missing_stats on,theoptimizerwill printamessagewhenitencounterssuchacase. Bydefault,theoutputiswrittentotheASEconsole(that'snotthesameastheASEerrorlog!);enabletraceflag 3604togettheoutputsenttotheclient. Twoexamplesofthesemessagesare: NO STATS on column t.col1 NO STATS on density set for t={col2, col3, col4} Whenseeingsuchmessages,itisrecommendedthattheDBArunupdatestatisticsforthecolumnsinvolved.The correspondingcommandswouldbe: update statistics t (col1) update statistics t (col2, col3, col4) Dependingonwhichindexesexistonthistable,thesameeffectmightbeachievedbyrunningupdate index statistics t.Notethatcreatingthesestatisticsforthereportedcolumnsdoesnotguaranteethatadifferent queryplanwillbegeneratedbytheoptimizer.However,sincetheoptimizersignalsitwouldhavelikedtoconsider additionaloptions,itisbesttoensuretherequiredstatisticsareavailable. Itisrecommendedtoenableset option show_missing_stats onatleastforsometimeintheASE15 testenvironment.Thisoptioncanbesetinalogintrigger,soapplicationcodechangescanbeavoided.Please refertotheASEdocumentationformoreinformationaboutlogintriggers.
OldstatisticsandupgradingtoASE15
BeforeorafterupgradingtoASE15,itisrecommendedtodeterminewhetherveryoldstatisticsexist.Suchold statisticsmayexistforvariousreasons: SinceASE11.9,whenanindexisdropped,histogramsfortheindexcolumnsarenolongerdropped automaticallyatthesametime.Therefore,ifthesehistogramsareneverexplicitlyupdatedandthat mayneverhappenwhenthosecolumnsarenotpartofanotherindextheoldhistogramsremain. Ifahistogramwasevercreatedforanonindexedcolumn,itwillstillbearoundifitwasneverupdatedor deleted.
Irrespectiveofthereasonwhytheycametoexist,oldstatisticsmaynotprovideanaccuratereflectionofthe currentdatadistributioninthecolumn.Inrarecases,thismayresultinneedlesslyinefficientqueryplansafter upgrading. Todetermineifoldstatisticsexist,querythecolumnsysstatistics.moddate(thisisthedate/timewhen theexistinghistogramsanddensitieswerelastupdated).Ifthisindicatesthatveryoldstatisticsindeedexist,use theoptdiagutilitytodeterminewhichstatisticsareinvolved.If,atalaterpoint,youareseeingsuboptimal 20

performanceforquerieswheretablesareinvolvedthatyouknowhaveveryoldstatistics,considerupdating(the preferredmethod)ordeleting(thefastermethod)thoseoldstatistics. However,beforedeletinganystatistics,pleasemakeabackupcopywiththeoptdiagutility.Thisallowsyouto restoretheoriginalstatistics(again,withoptdiag)inthecasethatthefreshlyupdatedstatisticsshouldresultin unexpectedperformanceeffects. Infact,itmaybeagoodideatomakeabackupcopyofthestatisticsforallyourtablesafterupgradingtoASE15, butbeforerunningupdate [index] statisticstorefreshthestatistics. Todeletestatistics,useoneofthesecommands: delete statistics t -- delete all histograms and densities on table t delete statistics t(a) -- delete the histogram on column t.a delete statistics t(a,b) -- delete the densities for columns (t.a, t.b)
Summaryofrecommendationsforstatistics
Pleaserefertotheprecedingpagesfordetailsoneachoftheserecommendations. Keepstatisticsonusertablesuptodatebyrunningupdate [index] statistics regularly Usethedatachange()functiontodeterminewhetherupdate [index] statisticsshouldberun moreoften Preferablyrunupdate index statisticsinsteadofupdate statistics.Forlargetables,use samplingifnecessary. Ifyoususpectsuboptimalqueryplansaregenerated,considerincreasingthenumberofhistogramstepsfor thetablesinvolved. Usethecommandset option show_missing_stats ontodeterminecaseswherestatisticsmaybe missing;andthencreatethosestatistics. ConsiderdeletingorupdatingoldstatisticsafterupgradingtoASE15whentheseareassociatedwithsub optimalqueryplans;however,alwaysmakeabackupcopyfirstwithoptdiag.
21
RecommendedTestingBeforeUpgradingToASE15
Whyshouldyoutest?
BeforeupgradingyourproductionsystemstoASE15,itisimportanttogatherdetailsabouttheperformance characteristicsofyourapplicationsonthecurrent,pre15versionofASE,preferablyinaproductionenvironment. Gatheringsuchdataisimportant,sinceanydiscussionsaboutperformancedifferencesafterupgradingtoASE15 willnotbeveryusefulifthesediscussionsarenotbasedonhardnumbers.Forthe12.xvs15performance comparisontobevaluable,itisstronglyrecommendedthatthesetestsbeperformedasrealisticallyaspossible. Thismeans: Runtestsforasmanyapplicationfunctionsaspossible,oratleastthemostcriticalfunctions.Foreach function,measuretheresponsetimeorthroughput;preferablyalsoperformthesemeasurementsfor eachqueryexecutedbytheapplication(seepage32forsuggestions) RuntheperformancemeasurementsinyourcurrentASE12.xproductionsystem runthesametestsbeforeupgradingyourproductionsystemtoASE15,inafullyconfiguredASE15test systemwithacopyofthefullASE12.xproductiondatabase,aswellasrealisticworkload(i.e.thesame queriesasin12.x,andwiththesamelevelofconcurrentuseractivity)
Also,preferablyrunthesetestsbeforeupgradingyourproductionsystemtoASE15,sothatyoucanidentifyany issuesbeforegoingliveonASE15.Capturingthe"performancefootprint"ofyourcurrentASE12.xproduction environmentwillprovideagoodbaselineforanycomparisonswithASE15.Themeasurementsshouldprovide specificnumberssuchasnumberoflogicalI/Os,elapsedtime,compilationtime,CPUutilizationetc.forapplesto applescomparison.Differencesinthemeasuredvalueswillhelpidentifyindividualqueriesperformingpoorlyas wellasanyserverlevelconfigurationissues. Therearesomedifferentanglestolookingatperformance.ToenableasensiblecomparisonofperformanceinASE 12.xandASE15,performancedataneedstobegatheredontwolevels: forindividualqueries,runinisolation forindividualqueries,runwithfullworkloadbyotherusers forASEasawhole,fromaserverwideresourceusageperspective
PleaseensurethattheconfigurationsoftheASE12.xandASE15serverareasidenticalaspossible.Havingsaid that,theASE15servermayhavemoreresourcesallocatedtoitthan12.x,andinsomecases(seepage14)thatis infactrequired.Also,makesurethetestsareexecutedinsimilarcircumstances. Thesearesomeaspectsthatarecriticaltodoingafaircomparisonbetween12.xand15: Ensurethecacheis'warmedup'thesamewayin12.xandin15duringthetests Useidenticalcache/bufferpoolconfigurations MakesuretheamountofprocedurecacheinASE15isamultipleofwhatisusedin12.x(seepage14) Usesimilardatadevicelayout/placement,especiallyforlogdevicesandfortempdb? Ifyourunteststhatmodifydata,considersettinguptestsystemswherebytheoriginaldatabasecanbe restoredaftereachtestrun.
Theseconsiderationsarecriticalastheywillaffecttheperformancebeingmeasured.Differencesintheseareas canthereforeleadtofalsealarmsandwastedtimefollowinguponnonexistentissues. 22
Pleasenote
ItisimportanttoobservethattheapproachtowardstestingasadvocatedaboveisnotspecificforASE15,butisa bestpracticethatappliestoanymajorupgradeofanysoftwareproduct.Thebestchanceofavoidingpotential risksaroundupgradesistorunasrealisticanenvironmentaspossiblebeforeputtingyouractualproduction systemsthroughtheupgrade.Shouldyoubeunabletofollowthisapproach,thenaturalimplicationisthatyou simplywillnotdiscoveranyissuesuntilyourproductionsystemdoes. Fromariskmanagementperspective,youshouldaskyourselfhowimportantitistoidentifyanyperformance issuespriortotheupgrade,andhowmuchopportunityyouwillhavetoidentifyandfixsuchissuesafteryour productionsystemhasbeenupgraded.Although,again,thisisnotspecificforASE,Sybaserecommends performingthoroughtestingasoutlinedinthisdocumenttominimizetheriskofdisruptionsduetoanupgrade.
UsingCompatibilityMode
Asdescribedonpage12,ASE15.0.3ESD#1providesafeaturenamed'CompatibilityMode'tooffercustomersa migrationpathtoASE15thatrequireslesstestingeffortatthemomentofmigration. Nevertheless,SybasestillrecommendstoperformsufficienttestingonapplicationsthataremigratedtoASE15, evenwhenusingcompatibilitymode.
Identifyingqueriesthatrunslower
Assumingyouareabletorunrealistic,representativetestsonbothASE12.xandASE15,yournextstepsdepend onwhatyoufindinASE15.Alongthelinesofthesuggestionsonpage7,itisrecommendedtorunyourtestsin ASE15atleastthreetimes,eachtimewithadifferentserverwideoptimizationgoal. Intheidealsituation,youcanestablishaserverwideoptimizationgoalunderwhicheverythingrunsthesameor fasterinASE15,inwhichcasethereisprobablynotmuchelselefttodo.Intheeventthatsomeapplications wouldappeartorunslowerinASE15thaninASE12.x,youwillfirstneedtoidentifythequeriesinvolved,then determinewhytheyrunslower,andfinallyfigureouthowtoresolvethis.Themainchallengeliesinidentifying thosequeriesthatrunslower. IfmaybeimmediatelyapparentwhichqueriesrunslowerinASE15,forexamplewhenaclearlydefined applicationfunctionappearstoperformlessthanin12.x.Insuchacase,thecorrespondingSQLqueriescan hopefullybeidentifiedrelativelyeasilybyusingtheMDAtablesorbyapplicationtracing(seepage32).Ifthe slowerqueriescannotbeidentifiedeasily,thebestapproachistocaptureallSQLqueriessubmittedbythe applicationinASE15(again,seepage32),andanalyzethesefurther(seebelow). Ingeneral,itisparticularlyimportanttoensurethefollowingtypesofqueriesareincludedinyourtests,evenif theyarenotexecutedfrequently(forexample,forperiodicreporting).Applicationdevelopersmaybeableto providesomeofthesequeries.Thisconcernsqueriesinvolving: multitablejoins, multipleviews/unions, starschemajoins severalsubqueries derivedtables outerjoins
AnalyzingperformancedifferencesbetweenASE12.xandASE15
OnceyouhavecapturedtheSQLtextofactualproductionqueries,youwillneedtoanalyzethesetodetermine whichqueriesperformworseinASE15thanin12.x.Thisprocesscanbeperformedwithsimplecommandline
23
tools,forexampleasdescribedbelow.Notethatthisapproachiswellsuitedforidentifyingqueryplanproblem withlongerexecutiontimes(i.e.multipleseconds),butlesssuitableforquerieswithveryshortexecutiontimes (e.g.100milliseconds). First,createafile,named,say,sql.in,withthefollowinglayout,containingtheSQLtextofyourcaptured queries(inbatches,sincethisishowapplicationssubmitqueriestotheASEserver): set plan optgoal allrows_xxx 12.x go set statistics plancost on 12.x go use your_db go set statistics io on set statistics time on set showplan on go <batch 1> go <batch 2> go [...] <batch n> go -- only for 15; this raises an error in
-- only for 15; this raises an error in
-- your default database
-- captured SQL query batches go here
NowrunthisfilebothinASE12.xandin15andcapturetheoutput: isql -U username -P passwd -S YOUR_12X_SERVER -e -i sql.in > sql.12x.out isql -U username -P passwd -S YOUR_15_SERVER -e -i sql.in > sql.15.out Nowyouneedtoanalyzethedifferencesinperformancebetweenexecutionin12.xandin15. Thiscanbedonebysearchingforthestring"Serverelapsedtime:"inbothfiles(forexample,withgrep),and comparingtheresults(forexample,byimportingthelistofexecutiontimesforbothcasesintoaspreadsheetand lookingforthosecasesthataremorethan,say,50%slowerinASE15). Hereisanexampleofsuchaline,indicatingthatthequeryraninlittlelessthan16minutesinASE15: Adaptive Server cpu time: 27300 ms. Adaptive Server elapsed time: 945953 ms. AnothercriteriontoidentifyqueriesistocomparetheamountofI/Othequeriesspentin12.xand15.0.Thiscan bedonebyexaminingoutputlineslikethefollowing(notethateachquerymayproduceanumberofsuchlines, oneforeachtablereferencedbythequery).Thenumbertolookforisthenumberofregularlogicalreads(shown inboldbelow): Table: Accounts scan count 365, logical reads: (regular=833370 apf=16 total=833386), physical reads: (regular=1927 apf=101769 total=103696), apf IOs used=99762
24
Onceyouhaveidentifiedspecificqueriesthisway,youcanstudythoseparticularcasesinmoredetailbylookingat theirqueryplan,andtheLavaTreeoutputresultingfromtheplancostoption(seepage30).
25
Analyzingshortdurationqueries
Tocomparetheperformancedifferenceofveryshortqueries,youmaywanttorunsuchaqueryapredefined numberoftimes,e.g. declare @i int, @d datetime select @i = 1000 -- run the query 1000 times declare select @d = getdate() while @i > 0 begin select @i = @i -1 ...your query... end select DurationInMilliSec=datediff(ms, @d, getdate()) go Withthisapproach,youshouldcomparethenumberofmillisecondsfor1000executionsin12.xand15.Repeating aquery1000timeswilleliminatejitterduetoexternalcircumstances,whichcouldaffecttheresponsetimeofone suchindividual,shortexecutionquitedrastically.
Serverlevelperformanceaspects
Serverlevelconfigurationsettingscanhaveabigimpactonqueryperformance,thoughitmaynotbepossibleto predictwhichquerieswillbeaffectedmost. AspartofyourtestingaroundtheASE15migration,capturethefollowingserverleveldata: Runsp_sysmon regularlyandcaptureitsoutput;recommendisrunningitevery1015minuteswitha sampleintervaltimeof1minute. Itiscriticalthatdataiscapturedduringallthesignificantperiodsoftheapplicationprocessing.For example:dailypeakperiods,nightly/weekly/monthlybatchcycles,MondaymorningMarketOpensetc. Whenanalyzingthe sp_sysmon output,alsopayattentiontothefollowing: o DataCacheusage:Reviewthecachehits,spinlockcontentionandthebufferpoolusage. Highcountsforcachehitsand/orhighspinlockcontentionmaybeanindicationofpoorlyperforming queries. o CPUutilization:ReviewtheCPUcharacteristicsoftheloadi.e.howbusyarethevariousengines,how muchtimeisspentinI/OBusy,Idlev/sCPUBusyetc. o DeviceIOcharacteristics:ReviewtheI/Osoutstanding,I/Oscompleted/sectogetaroughideaofthe levelofI/Osgeneratedbytheapplication/module.ItwouldalsobeinterestingtonotehowtheI/Os aredistributedacrossthevariousdatabasedevices.IfthelayoutinthetargetASE15.0isexpectedto change,thisinformationmaycomeinhandy. Runsp_monitorconfig 'all'regularly(every1015minutes),andlookforconfiguration parametersshowinganonzero'reuse',inparticularprocedurecache.Youmayalsorun sp_monitorconfigwithatablenameasanadditionalparameter:thiswillcausetheresultvalues fromsp_monitorconfigtobestoredinatable(whichyouhavetocreatefirst;seetheASEReference manualfordetails).
26
ExampleOfASE15QueryPlanAndLavaTree
ASE15QueryPlans
EachSQLstatementiscompiledintoaqueryplan.InASE15,aqueryplanisbuiltasanupsidedowntreeof operators:theoperatoratthetophasoneormorechildoperators.Eachofthese,inturn,canhaveoneormore childoperatorsthemselves,andsoon,thusbuildingatreeofoperators.Theexactshapeofthetreeandthe operatorsinitarechosenbytheASEqueryoptimizer. Thequeryplancanberepresentedindifferentways: set showplan onshowsthequeryplaninthewellknownformat,showingthejoinorder,indexes usedandI/Ostrategy. set statistics plancost on(anewcommandinASE15)showsthequeryplaninaformatmore closelyresemblingtheinternal"LavaTree". Lastly,theGUItoolDBISQLcandisplaythequeryplaninagraphicaltreeformat.Thisisnotdiscussed furtherinthisdocument.
Example:setshowplan
TodisplaythequeryplanintheclassicASEformat,useset showplan on: set showplan on go select A.au_fname, A.au_lname from authors A, titleauthor TA where A.au_id = TA.au_id go Thefollowingshowssomehighlightsfromtheresultingqueryplanoutput:
The type of query is SELECT. 3 operator(s) under root |ROOT:EMIT Operator (VA = 3) | | |NESTED LOOP JOIN Operator (VA = 2) (Join Type: Inner Join) | | | | |SCAN Operator (VA = 0) | | | FROM TABLE | | | authors | | | A | | | Table Scan. [...] | | |SCAN Operator (VA = 1)
27
| | | | | | | | | | | | | | read. | | | | [...]
| | | | | | | | |
FROM TABLE titleauthor TA Index : auidind Forward Scan. Positioning by key. Index contains all needed columns. Base table will not be Keys are: au_id ASC
Thequeryplanoutputasdisplayedbyset showplan onconsistsoftwomaincomponents: Thenamesofthequeryplanoperators,alongwithsomeadditionalinformation,toshowwhich operationsarebeingexecutedinthequeryplan.NotethatthisoutputisverysimilartothatinASE12.x, thoughASE15hasvariousnewoperators. Verticalbars(the"|"symbol)withindentationarenewinASE15.Theseareaddedtovisuallyclarifythe structureofthequeryplanoperatortree. ThequeryplanfromtheexampleaboveindicatesthattheASEqueryoptimizerhaschosenaplanconsistingof3 operatorsundertherootoperatorEMIT.InASE15,theEMIToperatorisalwaysthetopoperator(calledthe'root' operator)thatisresponsibleforroutingtheresultofthequerytotheclient. TheplancontainsaNESTEDLOOPJOINoperator,withtheauthorstablesastheoutertable(sinceitcomesfirstin thejoinorder)andthetitleauthortableasaninnertable(secondinthejoinorder).Thefirstindentedoperator appearingbelowtheNESTEDLOOPJOINoperatoralwaysrepresentstheoutersideofthejoinandthesecond operatoratthesamelevelofindentationistheinnersideofthejoin. Thescanstrategyfortheauthorstableusesatablescan,whiletheinnertabletitleauthorwillbescannedbyindex auidind.BoththeseoperatorsareshownintheshowplanoutputasaSCANoperator.Graphically,thisqueryplan canberepresentedbythefollowingoperatortree:
EMIT
NESTED LOOP JOIN
TABLE SCAN (authors)
INDEX SCAN (titleauthors using auidind)
Aqueryplancanhaveanarbitrarilydeeptreeofqueryplanoperators.Eachoperatorreceivesrequestsforthe nextrowfromitsparent(topdowncontrolflow),processestherequestandreturnstherequestedrowtoits parent(bottomupdataflow).Theorderofexecutionofanoperatordependsthusonitsparent'salgorithmand, recursively,ontheorderofexecutionofitsparent. Forinstance,a"leftdeep"treeofnestedloopjoinoperatorswillstartbyscanningtheoutermosttable,whenthe "nextrow"request,whichispasseddownontheoutersideofeachnestedloopjoin,reachestheoutermostscan. Then,asanestedloopjoinreceivesarowfromitsouterchild,itwilldoacorrespondingscanofitsinnerside basedonthatrow.Thenestedloopjoinwillreturn,eachtimeitsparentasksfor,itsownrowbasedonitscurrent 28

outerandinnerchildrows. Thefollowingexampleshowsamorecomplexqueryplan: select A.au_fname, A.au_lname, T.title from authors A, titleauthor TA, titles T where A.au_id = TA.au_id and T.title_id = TA.title_id
EMIT
MERGE JOIN
SORT
MERGE JOIN
INDEX SCAN (titles)
INDEX SCAN (titleauthor)
INDEX SCAN (authors)
Inthiscase,EMITasksitsMERGEJOINchildforarow,whichinturnasksits2childrenforrowsattemptingto satisfythemergeclause. TheupperMERGEJOIN'souterchild,SORT,isablockingoperator.Thismeansitneedstoconsumeitsentireinput beforereturningitsfirstrow(sincethefirstrowinthesortedresultcouldbelastrowreturnedbyitschild).SORT willthusaskitschild,thelowerMERGEJOIN,onebyoneforallofitsrowsandwillsortthem(ifpossiblein memory,overflowingifneededtoaworktable)andonlythenwillitreturnitsfirstrowtotheuppermostMERGE JOIN. ToproducetheserowsateachrequestofitsSORTparent,thelowerMERGEJOINwillaskfornewrowsfromits outerand/orinnerchildren,dependingonthecurrentvaluesinthemergecolumns,untiltheequijoinclauseis satisfiedandaMERGEJOINrowisreturned. AsthesechildrenareINDEXSCANsusingindexesontheequijoincolumns,therowsarereturnedordered,as requiredbytheMERGEJOINalgorithm,andnosortisdeeded. TheupperMERGEJOINwillhavethesamebehavior,askingSORTandINDEXSCAN(titles)forrowsandreturnat eachEMITrequestarowwheretheequijoinclauseissatisfied. Finally,therootoperatorEMITsendseachfinalresultsetrowbacktotheclientapplicationthatinvokedthequery. Notethatitisnotguaranteedthateachoperatorinthetreeisexecuted.Forexample,afilterconditionmay evaluateinsuchawaythatnorowscaneverresultfromasubtree,whoseoperatorsmaythereforenotbe executedatall.Formoreinformationabouttheoperatorsandtreestructure,seetheASEPerformanceand TuningGuide,volume"QueryProcessingandAbstractPlans".
29
Example:plancostandLavaTree
AusefulnewfeatureinASE15istheplancostoption,whichdisplaysthequeryplaninasemigraphicaltree formatmorecloselyresemblingtheinternalrepresentation,knownasthesocalled"LavaTree"(whichgotits namesincedatarowsflowupwardthroughthetreeoperatorstoasinglepoint,similartolavainavolcano). Theplancostoptioncanbeturnedonusingthefollowingcommand: set statistics plancost on go --- Run your query here Oneapplicationofthiscommandistocomparetheestimatedandactualcostsinaqueryplan.Itcanbeauseful toolfordiagnosingqueryperformanceproblems.Foreachoperator,theLavaTreeoptionshowstheestimated (el:)andactual(l:)numbersoflogicalI/O,estimated(ep:)andactual(p:)physicalI/O,estimated(er:)and actual(r:)rowcountsandactualCPUticks(cpu:).Inaddition,executionoperatorsthatdoasortorahashbased operationwillalsoreportthenumberofprivatebuffersusedforthatoperation(bufct:,notshowninthe examplebelow).Sincenotallofthesequantitiesapplytoeachtypeofoperator,asubsetmaybeshown.Forsub optimalqueryplans,thisinformationcanbeusedtoverifythattheoptimizer'sestimatesaresound. Ifthejoinqueryfromthepreviousexampleisrun,yougetoutputthatlooksliketheoperatortreeshowninthe previousdiagramwithadditionalannotationsshowingtheactualversusestimatednumbers.Theestimated numbersarethosecomputedbythequeryoptimizerandtheactualnumbersaretheresultoftheactualquery execution.Thisisagoodwaytovalidatehowclosetheoptimizer'scostmodeliswithrespecttotheactual numbers.
==================== Lava Operator Tree ==================== Emit (VA = 6) r:25 er:342 cpu: 0 / MergeJoin Inner Join (VA = 5) r:25 er:342 / Sort (VA = 3) r:25 er:25 l:6 el:6 p:0 ep:0 cpu: 0 bufct: 24 / MergeJoin Inner Join (VA = 2) r:25 er:25 / 30
\ IndexScan titles_672002394 (T) (VA = 4) r:18 er:18 l:2 el:3 p:0 ep:3
IndexScan auidind (TA) (VA = 0) r:25 er:25 l:1 el:2 p:0 ep:2
IndexScan authors_57600205 (A) (VA = 1) r:23 er:23 l:1 el:2 p:0 ep:2
Fromtheaboveoutput,someinterestingobservationscanbemade.ThebottomleftIndexScanoperator(on thetitleauthorstable)hasanestimatedrowcount(er:)of25andtheactualrowcount(r:)is25aswell;thismeans thattheoptimizer'sestimatewascorrect. However,therowcountestimatesforthetopMergeJoin(VA=5)arecompletelyoff,astheoptimizer's estimateis342buttheactualrowcountis25.Itmaybepossibletorectifysomeoftheinaccuraciesinthe optimizer'sestimatesbymakingsurethatthestatisticsareuptodate,orbyincreasingthenumberofstepsinthe histogram.Ifnohistogramsexistonthejoincolumns,asindicatedbyset option show_missing_stats on,creatingthosehistogramsmayimprovetheoptimizer'sestimates. Notethatcomparingtheoptimizerestimatesandactualsisnotanexactscience:whentheestimatedrowcountis 25andtheactualrowcountis30,thatshouldnotnecessarilybetakenasanindicationthattheoptimizer's estimatesareincorrect.Orderofmagnitudedifferences,suchas25vs.342intheexampleabove,arewhatyou shouldlookfor. Also,notethatthetablenameisnotdisplayedforIndexScanoperatornodes,butonlythenameoftheindex.If itisunclearwhichtableisassociatedwithanoperatornode,therearevariouswaystofindthisout: Thenameoftheindexmayuniquelyidentifythetable Ifacorrelationnamewasusedinthequery,thisisshownintheoperatornode.Forthebottomleft IndexScanoperator,"(TA)"refersto"titleauthor TA"fromtheoriginalSQLquery.
Theindication"(VA=n)",wheren=0,1,2,,isshownbothintheLavaTreeandintheshowplanoutput,and uniquelyidentifieseachoperatornode.
31
CapturingApplicationSQL
Inthecontextofmonitoringortroubleshootingperformanceissues,itisoftenusefultodeterminetheexactSQL queriesanapplicationissubmittingtotheASEserver,alongwithsomeperformancemetricssuchaselapsedtime orI/Oconsumption.ThisinformationcanbeusefulbothbeforeandaftermigratingtoASE15,forexampleinthe contextofperformancetestingaroundtheASE15upgrade(seepage22). FromthesideoftheASEserver,thiscanbedoneinanumberofways,dependingonyourASEversion: Auditing MDAtables(12.5.0.3orlater) Applicationtracing(15.0.2orlater) Abstractplancapture(12.0orlater)orquerymetricscapture(15.0orlater) MonitorServer SQLinterceptiontools,likeRibo(see$SYBASE/jutils-x_y)or3rdpartyproducts
Wewilllookatthefirstfourinalittlemoredetailbelow.
Auditing
Withauditing,youcanenablethe'cmdtext'auditingoption(withsp_audit).Thiswillcapturetheclient submittedSQLtextinthesybsecuritydatabase.Youwillneedtoextractthecapturedtextfromthisdatabase. NoperformancemetricsrelatedtotheSQLarecaptured. SeetheASESystemAdministrationGuidefordetailsonsetupandconfigurationofauditing,andforinformation aboutaccessingthecaptureddata.
MDAtables(12.5.0.3)
InASE12.5.0.3orlater,theMDAtables(alsoknownas'monitoringtables')canbeusedtocapture,amongother things,theSQLtextsubmittedbyclientapplications.Forthis,usetheMDAtablemaster..monSysSQLText. Associatedexecutionmetrics(executiontime,I/Ocounts,andmore)canbefoundin master..monSysStatement. Whenlookingforslowrunningorresourceintensivequeries,youcanfilterthecontentsofmonSysStatement by,forexample,lookingfor: queriesrunninglongerthan,say,10seconds(i.e.10000milliseconds): filterondatediff(ms, StartTime, EndTime) > 10000 queriesusingmorethanacertainnumberoflogicalI/Os,say,20000: filteronLogicalReads > 20000
NotethatmonSysSQLTextandmonSysStatementhaveaconfigurablebutlimitedsize,sotheyshouldbe queriedregularlytoextractthecapturedinformationandstorethisinapermanent,regulartable.Ifthisisnot donefrequentlyenough,orifthenumberofsubmittedqueriesisveryhigh,someofthesubmittedSQLmaynotbe capturedthroughtheseMDAtables. ForhelpwithinstallingandusingtheMDAtablespleaserefertoeitherofthefollowing: 32

theASEPerformanceandTuningGuide,volume"MonitoringandAnalyzing",chapter"MonitoringTables" membersofISUGcanusethisinformationavailableattheISUGwebsite:
http://my.isug.com/p/do/sd/sid=13&fid=9&req=direct
ApplicationTracing(15.0.2)
InASE15.0.2,youcanintercepttheSQLqueriessenttotheASEserverbytheclientapplicationbymeansofanew featurenamedapplicationtracing.ThiscanbeusedtoidentifyquerieswithlongrunningtimesorhighI/O consumption. SupposeanapplicationhasconnectedtoASEassession#24,andyouwanttoseethequeriessubmittedthrough thisconnection.Thiscanbedoneasfollows(assumingASErunsonUnix/Linux): set go set set set go tracefile '/tmp/my_dir/apptrace.24.out' for 24 show_sqltext on statistics io, time, plancost on showplan on
Asofthismoment,allSQLsubmittedbysession24willbewrittentothefile '/tmp/my_dir/apptrace.24.out',accompaniedbytheoutputfromset showplan andset statistics.Notethatthesetcommandsaboveapplytosession24,andnottothesessionexecutingthese statements,aswouldbethenormalsemantics. Whileyoursessionhasinitiatedapplicationtracingonanothersession,itisimportanttoobservethefollowing: Donotrunanyothercommandsinthissessionuntilyouhavedisabledthetracingagain(seebelow). Onceapplicationtracingisenabled,donotrunothersetcommandsthanthoseshownabove. Donotdisconnectyoursessionuntilyouhavedisabledthetracingagain;thismaycause showplanoutput tobesenttosession24,eventhoughthatsessiondidnotrunset showplan onitself. Donotleavetracingenabledforlongperiods,toavoiddisconnectslikementionedinthepreviousbullet.
Todisableapplicationtracing,firstswitchallsetcommandsoffagainandthenstopthetracing: set set set go set go Youcannowaccessthefile'/tmp/my_dir/apptrace.24.out' andanalyzeitscontents. Inpractice,itmaybemostpracticaltouseapplicationtracingforshortintervalsratherthanprolongedperiodsof time,sincetheamountofdatawrittentothetracefilecanbesignificant.Formoreinformationaboutapplication tracing,pleaseseeaseparatewhitepaperavailableontheSybasewebsiteat http://www.sybase.com/detail?id=1052835. show_sqltext off statistics io, time, plancost off showplan off tracefile off
33
AbstractPlanCapture/QueryMetricsCapture
SinceASE12.0,abstractplancapturecanbeusedtointerceptclientsubmittedSQLtext.Thistextisstoredinthe sysqueryplanstablealongwithitsabstractqueryplan.Thecapturedquerytextcanberetrieveddirectlyfrom thistable.InASE15,thenewfeatureofquerymetricscaptureusesthesameunderlyingmechanismtocapture executionmetricssuchasI/Ocountsandexecutiontimes,alongwiththeSQLtext.Thesemetricsarealsostoredin sysqueryplans,butshouldbeaccessedthroughaviewnamedsysquerymetrics. Apotentialdisadvantageofthesefeaturesisthatthecaptureddataisstoredinthesysqueryplanstableinthe session'scurrentdatabaseatthemomentthequerywasexecuted.Thismeansthatthecapturedquerytextcould endupin,forexample,tempdb,ifthatwasthesession'scurrentdatabase,eventhoughallqueriedtablesmay resideinotherdatabases. Formoreinformationaboutquerymetricscapture,seetheASEPerformanceandTuningGuide,volume"Query ProcessingandAbstractPlans".
34
InformationToCaptureBeforeContactingSybase TechSupport
BeforecontactingTechSupport,itisoftenusefultogatheradditionaldiagnostics.Thisisespeciallytruewhenthe problemisreproducible.Thissectionwilldiscusssomepotentialproblemareasanddocumentthecollection procedures.
701Errors
Whenaregularquery(i.e.notupdate index statistics)runsintoa701error,thisindicatesthatASE exhaustedtheprocedurecachespace.Ifyouarerunningwiththedefaultprocedurecachesize,youshould increasethisandtryagain.Thegeneralguidelineistoinitiallytake23timesthesizeofyour12.5.xprocedure cache,thoughinsomecases,especiallywhenusingtheoptimizationgoalallrows_dss,yourprocedurecache mayneedtobelarger. Ifincreasingtheprocedurecachehasnotresolvedthe701errorandyoucannotisolatetheproblem,thenyou shouldsetupaConfigurableSharedMemoryDump(CSMD).Thefollowinginstructionsareused. sp_configure 'dump on conditions', 1 go sp_shmdumpconfig 'add', 'error', 701, 1, '/opt/my_dir' go sp_shmdumpconfig 'add', 'error', 701, 1, 'D:\my_dir' go
--Unix -- Windows
Thesecondinstructionaddstheerror701conditiontoinitiateamemorydump.Thefourthparameterindicates thenumberofmemorydumpstocapture,inthiscase1.ASEwillnotcaptureadditionalmemorydumpsonthis conditionuntilASEisrecycledorthecounterismanuallyreset.Thelastparametershownisthenameofa directorytoholdthememorydump.Notethatthefilesystemonwhichthedirectoryresidesshouldhaveenough freespacetoholdthememorydumpfile,whichcanbelarge. Youcanverifythedumpconditionscurrentlydefinedbyrunningsp_shmdumpconfigwithoutanyparameters. Thiswillalsoshowanestimatedsizeofthememorydumptobecaptured.Youshouldverifythatthediskspace availableinthedirectoryislargerthantheestimatedmemorydumpfilesize. Afilenamewillautomaticallybegeneratedthatincludesthedateandtimeofthememorydump.Oncethe memorydumphasbeencaptured,youcanremovethisconditionusing sp_shmdumpconfig 'drop', 'error', 701 go IfyouwishtostopallCSMDs,configure'dump on conditions'to0. Oncethememorydumphasbeencaptured,youshouldopenacasewithTechSupportanduploadthememory dumptotheftpsite(forinstructions,seepage39). YoushouldalsoincludetheoutputfromthefollowingSQLstatements.TheseusetheMDAtableswithinASE, whichisautomaticallysetupwhenrunningtheinstallmasterscriptinASE15.0.2orlater.EarlierASEversions needtoruntheinstallmontablesscript.SeeexistingdocumentationforconfiguringtheMDAtables. select * from master..monProcedureCacheMemoryUsage
35
select * from master..monProcedureCacheModuleUsage go Note:thecontentsoftheMDAtablesshownabovedonotcontainanyusefulinformationforcustomers. Bydefault,ASEwillsendthe701errormessagetotheclient.Youshouldconsidergettingthismessagealso reportedintheerrorlog,sothatyoucantrackhowoftenitishappening. Thiscanbedoneasfollows: sp_altermessage 701,'with_log',true
PerformanceProblemwithaLimitedNumberofQueries
Ifalimitednumberofqueriesarenotperformingwellduetosuboptimalqueryplansorsuboptimalresource consumption,youmaywanttoconsiderinstallingthelatestASE15.0.xreleaseonyourdevelopmentservertosee iftheproblemstillexists.Iftheproblemstillexists,orifyoucannottestthelatestASErelease,thenareproduction shouldbecollectedandsubmittedtoSybaseTechSupport.IfyoucannotsendareproductiontoTechSupport,you shouldusethefollowingstepstogatherdiagnostics: 1. Createascriptfile(here,namedsql.txt)containingthesecommands: select @@version go select @@optgoal go sp_cacheconfig go sp_configure 'nondefault' -- only if you're running 15.0.2 or later! go dbcc traceon(3604) set showplan on set statistics time, io, plancost on set option show long go <your query text> go
2.
Runsql.outusingisqlandcapturetheoutputinafile(WARNING:theoutputfilecanpotentiallybe verylargepotentiallyGigabytesforcomplexquerieswithmanytables,underallrows_dss):
isql Usa P yourpassword -S YOUR_SERVER_NAME i sql.txt o sql.out
ThefollowinginformationshouldalsobeincludedsothatTechSupportcanattemptareproduction: Thefilessql.txtandsql.out.Ifapplicable,includeacasewiththe'fast'queryplan (sql.fast.txt)andonewiththe'slow'queryplan(sql.slow.txt)andcorrespondingfiles
36
sql.fast.out,sql.slow.out DDLforthebasetable(s)andindex(es);thiscanbegeneratedwiththeddlgenutility Simulatestatisticsoutputforthebasetable(s)viaoptdiag: optdiag statistics simulate <fully-qualified-table-name> -Usa -P yourpassword -S YOUR_SERVER_NAME -o <output-file>
AcopyoftheASEconfigurationfile,or,in15.0.2,theoutputofsp_configure 'nondefault' Ifthequeryisusingview(s)orstoredprocedure(s),thenalsoincludetheirSQLsourcecodeasobtainedby defncopyorddlgen. Theoutputofsp_monitorconfig 'all'.
SystemWidePerformanceProblemsorHighCPUUsage:step1
IftheperformanceofASE,ataserverwidelevel,isnotacceptable,andyouarerunning15.0.2ESD#3orlater, pleasefollowthestepsbelow.ThisisalsorequiredwhenASEisexperiencingunusuallyhighlevelsofCPUusage withoutaclearcause. ThisremedyisrelevantmostlywhenrunningamultiengineASEserver;forasingleengineASEserverthis proceduremaynotyieldasmucheffect.Pleaseenablethistraceflagonlyasdescribedbelow: dbcc traceon(757) go dbcc proc_cache(free_unused) go Broadlyspeaking,theeffectofthistraceflagisthatallocation/deallocationalgorithmsintheprocedurecache behavedifferentlyonsomepoints. PleasereporttoTechSupport(byopeningacase)whetherthesestepsmakeadifferencetothesituationinyour ASEserver.Whenreportingthisinformation,pleaserefertothiswhitepaperandrequestyourcasetobelinkedto CR484362;pleasealsoindicatewhetheryourebootedASEornot. NotethatthistraceflagshouldnotbeusedinanyASEversionsearlierthan15.0.2ESD#3. ShutdownASEandrestartitwithtraceflag757intheRUN_serverfile(i.e.addT757) IfASEcannotberebooted,youcantryrunningthefollowingdbcccommandsinstead.Itshouldhowever benotedthatthismayhavelesseffectthananASEreboot:
37
SystemWidePerformanceProblemsorHighCPUUsage:step2
IftheperformanceofASE,atasystemwidelevel,isstillnotacceptableafterthestepabove,SybaseTechSupport needsmoreinformationabouthowASEisspendingitsprocessingtime. Since,incaseslikethese,thereisnoerrorconditiontoconfigureamemorydumpfor,youwillneedtocapturea ManualSharedMemoryDump.Todothis,youneedtouseSybMon,whichisanundocumenteddiagnostictool. NOTE:THEINFORMATIONOBTAINEDBYTHEFOLLOWINGPROCEDUREISUSEFULFORSYBASETECHSUPPORT ONLYANDDOESNOTCONTAINANYINFORMATIONTHATCANBEUSEDBYCUSTOMERS.STRICTLYNOOTHER COMMANDSSHOULDBEUSEDBYCUSTOMERSOTHERTHANASINSTRUCTEDBYSYBASETECHSUPPORTAND THISDOCUMENT.PUBLICDISCUSSIONSABOUTSYBMON,SUCHASINNEWSGROUPS,SHOULDBEAVOIDED SINCEINCORRECTINFORMATIONMAYBECOMMUNICATEDTHATMAYBEHARMFULTOYOURASESERVER! USINGSYBMONOTHERTHANASINSTRUCTEDBYSYBASETECHSUPPORTANDTHISDOCUMENT,ORFOR DIFFERENTPURPOSES,ISENTIRELYATYOUROWNRISK. SybMonisstartedasshownbelow.YoumustusethesameOSloginthatwasusedtostartASEinordertoavoid permissionproblems.Notethatthepasswordisnotthe'sa'loginpassword,butaspecialpasswordthatcanonly beobtainedfromSybaseTechSupport.PleasecontactTechSupportifyouneedtorunthisstep. Pleasenote:itisessentialthatthefollowingprocedurebeperformedwhenperformanceproblemsareactually occurring,sinceonlyatthatmomentcantherightinformationbegatheredthatisneededtodiagnosetheissue. OnUnix: dataserver X P password D<path to directory with .krg file> OnWindows: sqlsrvr.exe X P password -D<path to directory with .krg file> Ifyouhaveonly1krgfileinthedirectory,ASEwillautomaticallyattachtothesharedmemoryregionand,ifthe serverisnamed"PROD1",youwillseeapromptlikethis: PROD1:active> Ifyouhavemultiple.krgfiles,youwillneedtoattachtothecorrectserver'ssharedmemoryusingthecommand: attach <servername>
Onceyouhaveattachedtothesharedmemoryregion,runthefollowingcommands: log on <not-yet-existing file> set display off sample count=150 interval=200 set display on log close quit
38
Theoutputwillbeinthefilespecifiedinthe"logon"command. Inaddition,youshouldrunsp_sysmon(fora1or2minuteinterval).SubmittheoutputfrombothSybMonand sp_sysmontoTechSupport.
UploadingdiagnosticstoSybaseTechSupportthroughFTP
Oncetherequireddiagnosticshavebeencaptured,firstopenacasewithSybaseTechSupport.Then,usethe followinginstructionstouploaddiagnosticstotheSybaseftpsite: ftp ftp.sybase.com user: anonymous pwd: <your email address> cd /pub/incoming/wcss mkdir <your case number> cd <your case number> bin put <memory dump filename> quit
39
ConclusionsAndRecommendations
Themainconclusionsandrecommendationsfromthisdocumentarethefollowing.Pleaserefertothementioned pagesfordetails: ThequeryoptimizerinASE15issignificantlydifferentfromtheoptimizerinpriorASEreleases,offering greatperformancebenefits,butalsointroducingnewtuningaspects(seepages321). ForcustomerswhoprefertolimittherequiredtestingeffortforupgradingtoASE15,'Compatibility Mode'maybeusedinASE15.0.3ESD#1.However,thismayresultinnotbeingabletobenefitfromthe queryprocessingenhancementsinASE15(seepage12). DonotinitiallyuseparallelprocessingwhenupgradingtoASE15,evenwhenparallelismwasusedinASE 12.x.ASE15maywelldeliverbetteroverallperformanceinserialmodethanpre15inparallelmode, especiallyforDSStypequerieswithoptimizationgoalallrows_dss(seepage8). MoreprocedurecachewillbeneededinASE15thanin12.5;expecttorequire2to3timesasmuch procedurecacheasinpre15(seepage14). UptodatestatisticsaremorecriticalforgoodperformanceinASE15thaneverbefore.Preferably,run updateindexstatistics,andifneeded,configureadditionalhistogramsteps(seepage21). Sybaserecommendstestingyourapplicationsandqueriesextensivelybeforeupgradingyourproduction systemtoASE15.Forbestresults,testonarealisticproductiondatabasewithactualproductionqueries, usingrealisticworkloadlevelsandreallifeconcurrency(seepage22). Whenencounteringunexpectedqueryprocessingissues,upgradetothelatestESDavailable;Sybaseis makingcontinuousimprovementsandyourissuemayalreadyhavebeenfixed(seepage12).
EnjoySybaseASE15!

40
ReferenceDocuments
Technicalwhitepaper"ChangestoscopeandsemanticsofsessionleveloptimizationsettingsinASE15.0.2": http://www.sybase.com/detail?id=1056206 Technicalwhitepaper"Using'CompatibilityMode'InASE15.0.3ESD#1ForASE15Migration": http://www.sybase.com/detail?id=1063556 Technicalwhitepaper"RequiredSQLcodechangeswhenmigratingtoASE15": http://www.sybase.com/detail?id=1063534
41
CONTACTINFORMATION ForEurope,MiddleEast, orAfricainquiries: +(31)346582999 ForAsiaPacificinquiries: +85225068900(HongKong) ForLatinAmericainquiries: +7707773131(Atlanta,GA)
SYBASE,INC. WORLDWIDEHEADQUARTERS ONESYBASEDRIVE DUBLIN,CA945687902USA Tel:18008SYBASE www.sybase.com Copyright2009Sybase,Inc.Allrightsreserved.UnpublishedrightsreservedunderU.S. copyrightlaws.Sybase,andtheSybaselogoaretrademarksofSybase,Inc.oritssubsidiaries. Allothertrademarksarethepropertyoftheirrespectiveowners.indicatesregistrationinthe UnitedStates.Specificationsaresubjecttochangewithoutnotice.2/09.

ASE15 Optimizer Best Practices v1 051209 WP

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

ASE15 Optimizer Best Practices v1 051209 WP

Загружено:

Авторское право:

Доступные форматы

TECHNICALWHITEPAPER

plan '(use optgoal allrows_dss)' Thesessionleveloptimizationgoalcanalsobesetinalogintrigger;seepage8formoreinformation.

NotethatSybasedoesnotrecommendusingexplicitsettingsforoptimizationcriteriaunlessadvisedbySybase TechnicalSupport,oraspartofatroubleshootingprocess.Inproductioncode,Sybaserecommendsusing optimizationgoalsinsteadunlessadviseddifferentlybyTechnicalSupport.

Notethatthiscanquicklybecomeanopenendedundertaking:thereisalmostnolimitontheamountofeffort youcanspendonanalyzingyourqueriesandderivingthebestoptimizationgoalsettingforasessionoran individualquery.Asalways,youhavetostrikeabalancebetweenperformancegainsandeffortspentwhen engaginginperformancetuning.

TodetermineifanysessionsarecurrentlyexecutingqueriesthatconsumealotofdiskI/O,use sp_monitor: sp_monitor "connection", "diskio"

-- disables reformatting -- your query

However,notethatwhenusingcompatibilitymode(seepage12),thenthesecommandsandfeatureswillstill functionasinpre15.0forthosestatementsthatareprocessedinfullcompatibilitymodeorrestricted compatibilitymode.ForstatementsthatareprocessedusingASE15mode,thesecommandsarenoopsas describedabove.

Thisformulahastheeffectofassumingthat'histogram tuning factor'issetto1(aswaslikely thecaseforthosecustomersbeforetheyupgradedto15).

-- only for 15; this raises an error in

-- your default database

-- captured SQL query batches go here

NESTED LOOP JOIN

TABLE SCAN (authors)

INDEX SCAN (titleauthors using auidind)

INDEX SCAN (titles)

INDEX SCAN (titleauthor)

INDEX SCAN (authors)

isql Usa P yourpassword -S YOUR_SERVER_NAME i sql.txt o sql.out

ThefollowinginformationshouldalsobeincludedsothatTechSupportcanattemptareproduction: Thefilessql.txtandsql.out.Ifapplicable,includeacasewiththe'fast'queryplan (sql.fast.txt)andonewiththe'slow'queryplan(sql.slow.txt)andcorrespondingfiles

AcopyoftheASEconfigurationfile,or,in15.0.2,theoutputofsp_configure 'nondefault' Ifthequeryisusingview(s)orstoredprocedure(s),thenalsoincludetheirSQLsourcecodeasobtainedby defncopyorddlgen. Theoutputofsp_monitorconfig 'all'.

Theoutputwillbeinthefilespecifiedinthe"logon"command. Inaddition,youshouldrunsp_sysmon(fora1or2minuteinterval).SubmittheoutputfrombothSybMonand sp_sysmontoTechSupport.

CONTACTINFORMATION ForEurope,MiddleEast, orAfricainquiries: +(31)346582999 ForAsiaPacificinquiries: +85225068900(HongKong) ForLatinAmericainquiries: +7707773131(Atlanta,GA)

Вам также может понравиться