How To Predict DB2 Performance Changes Mainframe MB103SN

Download How To Predict DB2 Performance Changes Mainframe MB103SN

Post on 28-Dec-2015

225 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

<ul><li><p>How To Predict DB2 Performance ChangesMainframeMB103SN</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>AbstractThe attendee will get a quick overview of Explain evolution over time and how this feature has become the mirror of the OptimizerWe will look at some potential methods to exploit in order to influence the Optimizers decisions and some issues to have in mind where Explain doesnt show the real picture. The attendee will also get some ideas how Explain information can be versioned in order to quickly find the reason for a performance change and finally how to predict performance before a program or SQL statement is going through a Rebind/Bind using CA Plan Analyzer which also is a major concern during DB2 upgrades *June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>AgendaExplain Evolution over the years are you aware of all the new stuff ?Optimizer resources for choosing the correct Access Path and how the user can influence these decisionsMethods to make corrective actions to application SQL and how to predict Access Path / PerformanceUsing CA Plan Analyzer to have a Proactive and a Reactive approach in placeHow CA Plan Analyzer can automate Explain Versioning in order to find the reasons for Access Path change or performance degradation / improvementA method to compare the costs and performance improvements/degradation prior to a potential Bind or Rebind*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAIN Some very important issues when dealing with DB2 Performance</p><p>Not only a Systems Programmer taskNot only a DBA taskNot only an Application Programmer / Analyst task</p><p>Its one common taskImportant to have DBAs and Application folks speak the same language Dont point fingers and dont direct without explaining WHY !Let the Application Developer understand what is happeningLet the DBA understand the businessToo often bad things are found too late*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAIN Illustrates how DB2s Optimizer will execute SQL, a Package or a Plan (depending on how EXPLAIN is executed) Why is EXPLAIN a necessityCant we simply look at the SQL-statement and estimate if it has been coded all right (we used to)What if its a 12 table join Or the statement is 2 MB (or just 24 KB)Does performance mean anything if a statement executes in half a second or 5 minutes ?Predict WHAT will happen when SQL changes or after a Package REBIND when a reorganization and Runstats executedThe latest example how will upgrading to DB2 V8 impact Access Path (compare DB2 V7 Optimizer with DB2 V8)Do you always know whether a JOIN or SUBSELECT/EXISTS provides the best performance ?? (lets see an example)*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.Lets see a cool example IDUG NA2007 alt.doc</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAINExplain is invaluable to check how the DB2 Optimizer decides to access the dataThe following pages illustrates that even though the RESULT-SET is good and expected the performance might be very different and not desirable</p><p>We will get back to the EXPLAIN prerequisites in the next section*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>SELECT * FROM DSN8810.EMP outer WHERE NOT EXISTS (SELECT * FROM DSN8810.EMP inner WHERE outer.WORKDEPT IN ('D11','C11') ); </p><p>SELECT * FROM DSN8810.EMP outer WHERE outer.WORKDEPT NOT IN ('D11','C11') ; </p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAINTwo different SQL statements might give the same result but is performance identical ?One example where it pays off to utilize Explain:Explain these two statements same result-set !!!!Any differences in Access Path ?What about Cost estimates ?</p><p>*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.EXPLAIN PLAN SET QUERYNO = 810 FOR SELECT * FROM DSN8810.EMP outer WHERE NOT EXISTS (SELECT * FROM DSN8810.EMP inner WHERE outer.WORKDEPT IN ('D11','C11') ); EXPLAIN PLAN SET QUERYNO = 811 FOR SELECT * FROM DSN8810.EMP outer WHERE outer.WORKDEPT NOT IN ('D11','C11') ; </p><p>COMMIT; SELECT * FROM PLAN_TABLE where queryno in (810,811); SELECT * FROM DSN_STATEMNT_TABLE where queryno in (810,811); </p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAINEXPLAIN output (the essential part) for these two statements*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.QUERYNO QBLOCKNO APPLNAME PROGNAME PLANNO METHOD CREATOR 810 2 BPASQL8 1 0 DSN8810 810 1 BPASQL8 1 0 DSN8810 811 1 BPASQL8 1 0 DSN8810</p><p>TNAME TABNO ACCESSTYPE MATCHCOLS ACCESSCREATOREMP 2 I 0 DSN8810 EMP 1 R 0 EMP 1 R 0 </p><p>ACCESSNAME INDEXONLYXEMP2 Y N N </p><p>~~~~~~~~~~~~~~~ from DSN_STATEMNT_TABLE ~~~~~~~~~~~~~</p><p>QUERYNO APPLNAME PROGNAME PROCMS PROCSU 810 BPASQL8 216 6000 811 BPASQL8 98 2706</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAINExecution statistics for these two statements</p><p>Reflects what Explain describedA clear difference in performance and access path even though the result-sets are identical Use EXPLAIN as part of the development toolset !!!!!!*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.R11.05 &gt; ------ DETECTOR Exception SQL Request Summary ------ 08-28-07 16:22Command ==&gt; Scroll ==&gt; PAGE Line 1 of 2OPID ==&gt; RASST02 DB2 SSID ==&gt; S81ATotal/Avg ==&gt; T Interval Time ==&gt; 04:00 Interval Elapsed ==&gt; 22:28.08------------------------------------------------------------------------------- S -View SQL stats, Q -View SQL text, E -Explain, D -View Detail START_TIME PLANNAME SQL INDB2_TIME INDB2_CPU GETPAGE ------------ -------- ---------- ------------ ------------ ---------- _ 16:19:57.066 RBPA1150 35 00:05.940991 00:00.009281 33 _ 16:21:00.559 RBPA1150 35 00:02.791862 00:00.004852 27 ******************************* BOTTOM OF DATA ********************************</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>What is EXPLAIN Why is Performance so importantBad performing SQL costs $$$$One benchmark a few years ago illustrates:It costs $30 to correct bad SQL in testIt costs $1000 to correct in productionIf response times are not optimalFewer transactions will go through the pipeEach end user will be less productiveOther SQL-statements will suffer due to sharing of resourcesBuffer Pools, I/O channels, Locking conflicts, contention in shared pools like SORT area, RID pool, . . . . Hardware upgrade to conform to SLA Potential loss of business especially for businesses dependent on Internet applications*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>Whats influencing the EXPLAIN output Some factors to consider when comparing Explain between two different environmentsOptimizer looks at Hardware typeOptimizer looks at number of processorsOptimizer looks at Buffer PoolsCosts to allocate work-filesHost variables will be replaced by Parameter Markers when doing dynamic Explain (as opposed to Explain during Bind/Rebind)This could be a major problem in earlier DB2 versions (prior to DB2 V8) When host variables (or column predicate) was defined differently than the column defined in the DB2 catalog*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>Whats influencing the EXPLAIN outputTable size (and compression)Column cardinality and Filter FactorIndexes present and the index columnsFIRSTKEYCARDF and FULLKEYCARDF and now more granular statistics when portion of index columns referencedDifferent RUNSTATS parameters to collect these statisticsClustering (Cluster Ratio) and number of index levelsSQL predicates (predicate analysis)ORDER BY and the ability to eliminate sorts. . . . . . . . . . and many more details*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>EXPLAIN Pre-RequisitesEXPLAIN tablescreator.PLAN_TABLE (minimum to do explain)Records Optimizers choice of Access PathNot immediately easy to decrypt many codes creator.DSN_STATEMNT_TABLE (optional)Shows COST estimates (this is HUGE in my opinion)creator.DSN_FUNCTION_TABLE (optional)Only used if UDFs need to be explainedCreator.DSN_STATEMENT_CACHE_TABLE (new in DB2 V8)Used to explain the DB2 Dynamic Statement Cache With DB2 9 there are 10 additional tables to consider *June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>PLAN_TABLE evolution*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.V1R1M0Where is Explain ?V1R225 columnsV2R128 columnsV2R330 columnsV3R134 columnsV443 columnsV546 columnsV649 columnsV751 columnsV858 columns959 columnsSequential PrefetchPackagesParallelismData Sharing and more parallelismRe-optimizationOptimization HintsTable types like temporary, work file Encoding scheme - Unicode Lots of new information to existing columns</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>PLAN_TABLE evolutionEven though the PLAN_TABLE is invaluable there are a number of issues to consider The Optimizers thoughts are not reflectedWhy one index was chosen over the otherWhy one table was picked as the first accessed instead of another in a join sequenceWhy a predicate is considered STAGE1 or STAGE2Why a predicate isnt indexableVisual Explain does help to explain some of these issuesThe most important issues when analyzing the Access Path described in the PLAN_TABLE *June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>PLAN_TABLE evolutionExplain only shows SELECT, DELETE, UPDATE, INSERTImportant not to forget the issues below when doing performance / tuning RI DefinitionsTRIGGERs executed as part of the SQL-statementUDFsTable- and Column Check ConstraintsNot always a guarantee DB2 will USE the illustrated APPrefetch activities can be disabled depending on BP statusParallelism is decided at the execution timeRID Pool shortage (DB2 V8 changed the behavior) *June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>PLAN_TABLE evolutionThe birth of DSN_STATEMNT_TABLE one of the greatest newsAlmost as important as the PLAN_TABLE itselfPROCMS and PROCSU can be used to compare costs between different versions of a statement or packageSomehow its easier than comparing the PLAN_TABLE content Numbers are nice when somehow accurate Dont base all your decisions on these numbers only use them to compare a previous Access Path DB2 9 for z/OS introduced one additional column in DSN_STATEMNT_TABLETOTAL_COST - The estimated cost of the statement (elapsed time) to compare with explain versions of the same statement *June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p><p>June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.</p></li><li><p>PLAN_TABLE evolutionWHAT-IF analysisDB2 9 provides another new feature the ability to do explain with virtual indexesOne additional table needs to be created for the Explain feature.The VIRTUAL index will show up in the PLAN_TABLE if it can be used*June 10th: How to predict DB2 Performance Changes Copyright 2009 CA. All rights reserved.CREATE TABLE RASST02.DSN_VIRTUAL_INDEXES ( TBCREATOR VARCHAR ( 128 ) , TBNAME VARCHAR ( 128 ) , IXCREATOR VARCHAR ( 128 ) , IXNAME VARCHAR ( 128 ) , ENABLE CHAR ( 1 ) , MODE CHAR ( 1 ) , UNIQUERULE CHAR ( 1 ) , COLCOUNT SMALLINT , CLUSTERING CHAR ( 1 ) , NLEAF INTEGER , NLEVELS SMALLINT , INDEXTYPE CHAR ( 1 ) , PGSIZE SMALLINT , FIRSTKEYCARDF FLOAT , FULLKEYCARDF FLOAT , CLUSTERRATIOF FLOAT , "PADDED" CHAR ( 1 ) , COL...</p></li></ul>

Recommended

View more >