The Best Way to Tune Your Parallel Statements: Real-Time ...€¦ · Real-Time SQL Monitoring • Introduced in Oracle Database 11g to make SQL tuning easier • Shows detailed informaon

Copyright©2016,Oracleand/oritsaffiliates.Allrightsreserved.|

TheBestWaytoTuneYourParallelStatements:Real-TimeSQLMonitoring

YasinBaskanProductManager,ParallelExecuPonDataWarehouseDevelopmentSep20,[email protected]@yasinbaskan


SafeHarborStatementThefollowingisintendedtooutlineourgeneralproductdirecPon.ItisintendedforinformaPonpurposesonly,andmaynotbeincorporatedintoanycontract.Itisnotacommitmenttodeliveranymaterial,code,orfuncPonality,andshouldnotberelieduponinmakingpurchasingdecisions.Thedevelopment,release,andPmingofanyfeaturesorfuncPonalitydescribedforOracle’sproductsremainsatthesolediscrePonofOracle.


• Availablenow– ExadataExpressCloudService

• Comingsoon– DatabaseCloudServices– ExadataCloudMachine

3

AnnouncingOracleDatabase12cRelease2onOracleCloud

OracleispresenPngfeaturesforOracleDatabase12cRelease2onOracleCloud.WewillannounceavailabilityoftheOn-PremreleasesomePmeaZerOpenWorld.


Agenda

IntroducPontoReal-TimeSQLMonitoring

StepstoanalyzeaSQLMonitorreport

CommoncausesofsubopPmalperformanceinparallelstatements

1

2

3

4


IntroducPontoReal-TimeSQLMonitoring

5


Real-TimeSQLMonitoring•  IntroducedinOracleDatabase11gtomakeSQLtuningeasier•  ShowsdetailedinformaPonabouttheexecuPonofasingleSQLstatement– BothatrunPmeandaZerthestatementends

• MakesitveryeasytoidenPfycausesofperformanceproblemsbyshowingwherePmeisbeingspentintheexecuPonplan– NoneedtoqueryV$viewsorenableanytracing

•  EspeciallyusefulforparallelstatementswheretheexecuPonplanmaybemuchlonger•  ForguidanceonhowtogetSQLMonitorreportssee:–  hcp://www.oracle.com/technetwork/database/manageability/sqlmonitor-084401.html

6

Copyright©2016,Oracleand/oritsaffiliates.Allrightsreserved.| 7

Real-TimeSQLMonitoring


StepstoAnalyzeaSQLMonitorReport

8


HowtoanalyzeaSQLMonitorreport•  LookatwherethePmeisbeingspent– Time&waitstaPsPcs– FindtheplanstepdoingmostoftheacPvity•  “AcPvity%”column

– CheckiftheesPmatedcardinalitymatchestheactualcardinality•  “EsPmatedrows”and“actualrows”columns

• GatheringappropriateopPmizerstatsfixesmostoftheproblems– Extendedstats,histograms,etc…

9


CommonCausesofSubopPmalPerformanceinParallelStatements

10


Top3thingstobeawareofinparallelstatements• WorkdistribuPonacrossparallelprocesses• DatadistribuPonbetweenparallelprocesses• Degreeofparallelism(DOP)

11


WorkDistribuPonAcrossParallelProcesses

12


WhyisworkdistribuPonimportant?• MulPpleprocessesworkingforasingleparallelSQLstatement• UnevenworkdistribuPoncausessubopPmalperformanceandlowscalability– e.g.IncreasingtheDOPdoesnotmakethequeryrunfaster

13


WorkdistribuPonacrossprocesses•  LookattheParalleltabtoseetheworkdistribuPonacrossprocesses

14

UnevenworkdistribuPon


WorkdistribuPonacrossprocesses•  Lookatwhataspecificprocessisdoing•  TrytounderstandwhatcausesunevenworkdistribuPon

15


CommoncausesofunevenworkdistribuPon•  SubopPmaldatadistribuPonmethodchosenbytheopPmizer• Dataskewinthejoincolumns

16


CommonDataDistribuPonProblems

17


Producer/consumermodelanddatadistribuPon

PX1

PX2

A-L

K-Z

ProducerConsumerDistribute

ProducerConsumerDistribute

QueryCoordinator

SCANJOIN

SELECT*FROMCUSTOMERSORDERBYcust_last_name;


CommondistribuPonmethods• HASH– AppliesahashfuncPononthejoinkeysandsendstherowtoasingleconsumer

• BROADCAST– Sendsallrowstoeveryconsumer– Suitableforsmallerdatasets


HashdistribuPon

PX2

PX1cust_id

3000

1000

2000

4000

c.cust_id

1000

4000

c.cust_id

3000

2000

cust_id

3000

1000

cust_id

2000

4000

PX3

PX4

PX1andPX2scantheleZsidetable

PX1andPX2applyahashfuncPononthekeycolumnsanddistributetherowsbasedontheresulttoPX3andPX4

TableC

selectcount(*)fromc,swherec.cust_id=s.cust_id;


HashdistribuPon

PX2

PX1cust_id

4000

1000

2000

3000

c.cust_id s.cust_id

1000 1000

4000 4000

c.cust_id s.cust_id

3000 3000

2000 2000

cust_id

4000

1000

cust_id

2000

3000

PX3

PX4

PX1andPX2scantherightsidetable

PX1andPX2applyahashfuncPononthekeycolumnsanddistributetherowsbasedontheresulttoPX3andPX4

TableS



BroadcastdistribuPon

PX2

PX1cust_id

3000

1000

2000

4000

cust_id

3000

1000

cust_id

2000

4000

PX1andPX2scantheleZsidetable c.cust_id

3000

1000

2000

4000

PX3

PX4c.cust_id

3000

1000

2000

4000

PX1andPX2broadcastallrowstoPX3andPX4

TableC




cust_id

3000

1000

2000

4000

PX3andPX4scantherightsidetablecust_id s.cust_id

3000 3000

1000 1000

2000

4000

PX3

PX4cust_id s.cust_id

3000

1000

2000 2000

4000 4000

TableS


NodistribuPonfortherightside


CommondistribuPonproblems• OpPmizermaypickasubopPmaldistribuPonmethodbecauseofstale/missingstats– HashdistribuPonwithlowcardinality•  Causessomeprocessesdomorework

– BroadcastdistribuPonwithhighcardinality•  CauseshighnumberofrowstobesentacrossRACnodesandprocesses• MaycausehighPGAandtemporarytablespaceusage


HashdistribuPonwithlowcardinalityWorkdistribu2on



HashdistribuPonwithlowcardinalityWaitac2vityfordistribu2on

EsPmatedrowsvs.ActualRows HighwaitPmefordistribuPonHashdistribuPonasaresultofwrongcardinalityesPmates


HashdistribuPonwithlowcardinality• OpPmizermaypickhashdistribuPonforsmalltablesbecauseofstalestats• Causessomeprocessestodomoreworkthanothersdegradingscalability• MakesureopPmizerstatsareup-to-datetogettheopPmaldistribuPonmethod• OracleDatabase12cprovidesadapPvedistribuPonmethodstopicktheopPmaldistribuPonmethodatrunPme

27


HashdistribuPonwithlowcardinalityA9ergatheringop2mizerstatsinOracleDatabase11g



HashdistribuPonwithlowcardinality

29

Adap2vedistribu2onwithstalestatsinOracleDatabase12c

AdapPvedistribuPon


AdapPvedistribuPoninOracleDatabase12c

•  DistribuPonmethoddecisionbasedonactualnumberofrowsratherthanopPmizerstats

•  NewadapPvedistribuPonmethodhybridhash–  StaPsPccollectorsusedontheleZsideofthejointocounttheactualrowsatrunPme–  IfnumberofrowsislessthantheopPmizerthresholdusebroadcast,elseusehash

Hybridhashdistribu2on


AdapPvedistribuPoninOracleDatabase12c

31

Howtofindtherun2medistribu2onmethod

6=>Broadcast16=>Hash


CommondistribuPonproblems• OpPmizermaypickasubopPmaldistribuPonmethodbecauseofstale/missingstats– BroadcastdistribuPonwithhighcardinality•  CauseshighnumberofrowstobesentacrossRACnodesandprocesses• Maycausehightemporarytablespaceusage


BroadcastdistribuPonwithhighcardinality

EsPmatedrowsvs.actualrows Hightempusage HighacPvityfortempIO


BroadcastdistribuPonwithhighcardinality• OpPmizerpicksbroadcastdistribuPonbecauseofstalestats• Causesalotofrowstobebroadcastedtoallconsumerprocesses• MaycausehighPGAandtempusageinhashjoinsaseachconsumerprocessbuildsahashtableforallrows• MakesureopPmizerstatsareup-to-datetogettheopPmaldistribuPonmethod

34


BroadcastdistribuPonwithhighcardinality

35

A9ergatheringop2mizerstats

HashdistribuPonatrunPme Notempusage


EffectofDataSkewonWorkDistribuPon

36


WorkdistribuPonwithdataskew• HashdistribuPonisthemostcommondistribuPonmethodforlargetables– DoesnottakedataskewintoaccountunPlOracleDatabase12c

• Dataskewcancausesomeconsumerprocessestogetmorerows

37

PX2

PX1cust_id

3000

3000

3000

4000

c.cust_id

3000

3000

3000

c.cust_id

4000

cust_id

3000

3000

cust_id

3000

4000

PX3

PX4

TableSPX3getsmorerowsthanPX4


WorkdistribuPonwithdataskew

38




39

AdapPvedistribuPon(HashdistribuPonatrunPmeinthiscase)



40

A9ergatheringhistogramsonthejoincolumn

HashskewdistribuPon


Skewhandlingforjoins

• Value-baseddistribuPonofskeweddataforhashdistribuPon– BroadcastrowscontainingpopularvaluesontheleZsideofthejoin– Randomizerowscontainingpopularvaluesontherightsideofthejoin

• Popularvaluesareobtainedusingsampling• DecisionbasedonskewinformaPonfromhistograms• Considersskewontherightsideofthejoin(largertable)

IntroducedinOracleDatabase12cRelease1


Skewhandlingforjoins

• Histogramneededonthejoincolumn• Popularvalues– Valuesthatareatleast10xtheaveragefrequency– Valuesthathavemorethan30%frequency

•  Ifnumberofskewedvalues>DOP,noskewhandling

IntroducedinOracleDatabase12cRelease1


DegreeofParallelismandDowngrades


• Checkifyouarege}ngtheDOPyourequested– Ifnot,findoutwhy

• DOPisthefactorimpacPngperformanceforwelltunedSQLstatements– TunetheSQLbeforeplayingwiththeDOP

Degreeofparallelism(DOP)


DOPdowngrades• OthercolumnforPXcoordinatorshowsthedowngradereason

45


DOPdowngradereasonsselectqksxareasons,indx

fromx$qksxa_reason

whereqksxareasonslike'%DOPdowngrade%’;

QKSXAREASONSINDX

----------------------------------------------------------------------

DOPdowngradeduetoadaptiveDOP351

DOPdowngradeduetoresourcemanagermaxDOP352

DOPdowngradeduetoinsufficientnumberofprocesses353

DOPdowngradebecauseslavesfailedtojoin354

46


DOPdowngradereasons

• AdapPveparallelism– DowngradestheDOPbasedonsystemload

•  Enabledbyinit.oraparameterPARALLEL_ADAPTIVE_MULTI_USER• DisableadapPveparallelismbyse}ngtheparametertoFALSE.– DisabledanddeprecatedinOracleDatabase12cRelease2

• UseParallelStatementQueuingtopreventsystemsaturaPon

47

DOPdowngradeduetoadap2veDOP


DOPdowngradereasons• DOPdowngradeduetoresourcemanagermaxDOP– DatabaseResourceManager(DBRM)plancappedtheDOP•  PlandirecPvePARALLEL_DEGREE_LIMIT_P1•  IfyouneedhigherDOPsincreasethelimitifthereisampleunusedprocessingbandwidth•  OrdecreaseconcurrencyandallowhigherDOPs

• DOPdowngradeduetoinsufficientnumberofprocesses– #ofin-usePXserversreachedPARALLEL_MAX_SERVERS•  IncreasePARALLEL_MAX_SERVERSifthereisampleunusedprocessingbandwidth•  UseParallelStatementQueuingtolimitthenumberofin-useprocesses

48


DOPdowngradereasons• DOPdowngradebecauseslavesfailedtojoin– SomeprocessescouldnotjointheexecuPonofthestatement– UsuallyaresultofplanmismatchbetweenPXserversondifferentinstances– RaiseanSR

49


Summary

50


LeverageSQLMonitorforSQLtuning•  EasilyidenPfycausesofsubopPmalperformance– CheckwherethePmeisbeingspent– MakesureesPmatedcardinalitymatchesactualcardinality– GatherappropriateopPmizerstatstofixcardinalitymismatch

•  Forparallelstatements– CheckifworkanddatadistribuPonisevenforopPmalperformanceandscalability– FixunintendedDOPdowngradesdegradingperformance

51


ForfurtherinformaPon•  MonitoringParallelExecuPonusingReal-TimeSQLMonitoringinOracleDatabase12c–  hcps://blogs.oracle.com/datawarehousing/entry/monitoring_parallel_execuPon_using_real

•  CommonDistribuPonMethodsinParallelExecuPon–  hcps://blogs.oracle.com/datawarehousing/entry/common_distribuPon_methods_in_parallel

•  AdapPveDistribuPonMethodsinOracleDatabase12c–  hcps://blogs.oracle.com/datawarehousing/entry/adapPve_distribuPon_methods

•  FindingtheDistribuPonMethodinAdapPveParallelJoins–  hcps://blogs.oracle.com/datawarehousing/entry/finding_the_distribuPon_method_in

•  FindingtheReasonforDOPDowngrades–  hcps://blogs.oracle.com/datawarehousing/entry/finding_the_reason_for_dop

52


SafeHarborStatementTheprecedingisintendedtooutlineourgeneralproductdirecPon.ItisintendedforinformaPonpurposesonly,andmaynotbeincorporatedintoanycontract.Itisnotacommitmenttodeliveranymaterial,code,orfuncPonality,andshouldnotberelieduponinmakingpurchasingdecisions.Thedevelopment,release,andPmingofanyfeaturesorfuncPonalitydescribedforOracle’sproductsremainsatthesolediscrePonofOracle.

53

54

Documents

The Best Way to Tune Your Parallel Statements: Real-Time ...€¦ · Real-Time SQL Monitoring • Introduced in Oracle Database 11g to make SQL tuning easier • Shows detailed informaon