How to Predict DB2 Performance Changes

1,260 views
1,143 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,260
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
60
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • The topics being covered in this presentation as outlined on the agenda will not be divided into the “hard groups” as specified. However – all the topics will be covered sooner or later. The topics are: EXPLAIN has been through a tremendous evolution over the past two decades – and “thank you for that” since it’s quite a job to keep up the Optimizers pace, so we will look into some of the changes to EXPLAIN which might have slipped your mind. The Optimizer has gotten more and more clever – but sometimes it does happen you don’t get the “correct” Access Path, so we’ll look at what resources the Optimizer has and what we can do to help her/him/it to pick “our desired AP”. When the Optimizer doesn’t pick the AP we want – we have many methods to change the Optimizers preferred Access Path. We will also look into some methods to predict the Access Path before we move our programs and SQL into production. Part of item 3 above is the ability to version Access Path information – especially for predicting but certainly also for reactive performance debugging. Finally we will look into how the costs of SQL statements/packages can be compared to the current costs prior to upgrading the SQL and/or package or doing the BIND / REBIND.
  • When dealing with performance, a number of issues (sometimes unfortunately neglected) are very important to understand. Performance is not only a matter for the Systems Programmer, the DBA or the Application Developer or Programmer analysts. Performance is ONE COMMON task – and everyone need to be involved and understand the issue if the common theme needs to be successful – the Enterprise. The biggest challenge today is to have DBA’s and Application Developers speak “the same language”. Too often “fingers are pointed” instead of creating a mutual common environment and understanding of the issues. In order to capture performance problems before they do become an issue – and potentially hurt the enterprise, it is important to explain the “why’s” to the application folks instead of simply saying “do it this way” – since the same issue will arise again very shortly. Also it is important for the Application folks to explain the business issues to the DBA’s – too often these two groups are moving in different directions – and the ultimate “end-of-the-story” is a hurting enterprise.
  • So in order to start up from the previous slide – it is important everybody is aware of the tools, the reasons and the methods – so let’s do a short introduction to EXPLAIN – the most important tool when dealing with performance. EXPLAIN is THE tool to use in order to see how the DB2 Optimizer has decided to execute a SQL-statement, a Package or a PLAN – depending on what was explained. Why is EXPLAIN such a necessity – can’t we simply look at the SQL statement and predict how the performance will be ? Many years ago we probably could do that, but with today’s sophisticated SQL possibilities and up to 2MB statements and dozens of table joined – it is impossible to predict the access path in a timely manner (unless you are Terry Purcell). Dealing with performance – we also need to look verify if it matters whether the SQL statement execution takes half a second or 5 minutes – AND – what will happen when/IF a REBIND or BIND is executed (like DB2 upgrades or program promotion). Another issue is – do we always know if a JOIN or SUBSELECT will perform the best - many issues to consider in today’s performance world.
  • Bottom line – The EXPLAIN function is invaluable in the day-to-day job in order to predict performance, or at least get a clue how the Optimizer decides to access the data. Like mentioned earlier – sometimes it’s hard to predict how the SQL statement is coded, and even though the Optimizer is getting more and more clever (and sophisticated), the performance can differ based on the SQL statement even though the result-set is the same. This slide has two different statements both producing the same result-set, but the performance and access path is completely different.
  • As mentioned on the previous slide – these two statements are very different but they both do produce the correct and desired result. Can you predict which SQL statement is the cheapest based on the current catalog statistics ? Perhaps you can, but in order to verify which one to use it might be necessary to both execute EXPLAIN as well as the actual statement and look at the execution statistics.
  • The two statements do get different access path selected by the Optimizer. The lower part of the slide is a snapshot of some of the columns from the DSN_STATEMNT_TABLE. The processing Milliseconds and Processing Service Units are indeed different for the two explained statements, so let’s have a closer look at the actual executions before we make up our mind which statement to use.
  • Both SQL statements were executed in two scenarios: In order not to get any buffer hits, the database was stopped and started ahead of each execution All pages were in a separate buffer pool in order to see the impact. Both scenarios produced similar difference in terms of execution and CPU time, so we have an easy pick in this case since the real time execution reflected what the EXPLAIN output indicated. The conclusion is – like we discussed earlier, the EXPLAIN function should be a mandatory part of the application development environment, and it is necessary for the DBA’s and Application people to get together and discuss DB2 performance issues.
  • Why do we spent so much time and resources working with and understanding Explain ? Bad performing SQL statements cost the enterprise a lot of money, and performance is today’s hottest topic – hotter than back-up and recovery planning for some sites. A study a few years ago claimed that that finding and correcting bad performing SQL in production as opposed to finding these in the early stage of development costs at least 30 times more – for a number of reasons: When performance isn’t optimal fewer transactions can be pushed through the pipe and every transaction takes longer This might also impact other SQL executions since a lot of resources are shared. Eventually it might be necessary to upgrade the HW – meaning additional costs for both HW and SW In worst case it could result in loss of businesses and even the entire business. Especially where the business is dependent on the Wild Wild Web – it is so easy for shoppers to visit another site unlike driving to another store if the line at the cash register is too long or no one is available to assist you.
  • So far we have talked about how important it is to do Explain as early as possible in the development phase. When applications are being changed – meaning we already do have the application running in production – the Explain process needs to be considered from a different angle, but more about this later. When Explain is executed in the test environment everything might look great, but a number of issues will have to be considered before signing off. The DB2 Optimizer makes decisions based on a number of things, like hardware, number of processors, buffer pool size, size of workfiles etc. Also – when statements are being explained (except for Bind / Rebind explain(yes)), the host variables have to be replaced with parameter markers. This could result in some misleading access path descriptions in the “old days” since the Optimizer can’t see the host programs definition of the host variables. This is becoming less an issue for every DB2 version, and especially DB2 V8 has removed some of these concerns. So keep in mind that it might not be sufficient to “only” explain the SQL in the test environment. The real picture might not be available until the SQL is explained in the real production environment (more about this later).
  • The previous slide listed some of the not-so-obvious parameters influencing the Optimizer decision – while this slide lists some of the more obvious pieces of information assisting the Optimizer to chose the “correct” access path. These are some of the obvious parameters being looked at and checked carefully before the Optimizer decides “how” – but not limited to: Table definition and column attributes Column distribution statistics – and DB2 has introduced a lot of great enhancements during the past couple of versions, where it is necessary to change how Runstats has been executed in the past Indexes and the columns included, Clusterratio, index levels Which columns are being ordered or grouped by – can sort be eliminated.
  • Now we all know that Explain is very important, so let’s have a deeper look into what is needed in order to execute Explain. Minimum the PLAN_TABLE is needed. This is where the Optimizer records the chosen access path when Explain is executed – either dynamically or via Bind / rebind with Explain(YES). The DSN_STAMENT_TABLE is optional, but I strongly recommend to have this created too (with the same creator as for the used PLAN_TABLE). More later why I think this table is a MUST HAVE. The DSN_FUNCTION_TABLE is only needed if UDF’s are going to be explained – and this will not be covered in this presentation. A new table was introduced in DB2 V8 – the DSN_STATEMENT_CACHE_TABLE. This table is mandatory if the DB2 Dynamic Statement cache is explained – either via using the statement token or the entire cache is explained in one go.
  • Just like DB2 has been through a huge evolution – so has the PLAN_TABLE. The very first DB2 version didn’t have an EXPLAIN feature associated, so predicting performance was “a lot of fun”. Thank God it didn’t take long before Explain became available, and it has grown since then. Every Db2 version has extended the PLAN_TABLE content, and listed on the right hand side are some of the major events which are reflected in the PLAN_TABLE content.
  • Now that EXPLAIN and the PLAN_TABLE has received a lot of credits – let’s look at some of the issues we’re facing – and why we sometimes see the execution performance being completely different what we expected based on the PLAN_TABLE content. The reality is that EXPLAIN does not tell us the whole truth / everything, so we still need to put on “the DBA Performance glasses”. What ever goes through the Optimizers mind during the cost estimation process isn’t reflected. Why one index was chosen to be preferred over another one. Why one table was selected to be the first accessed over one of the other ones involved in the join process. It also could be nice to see why a predicate was considered STAGE 1 or 2 as well as why a predicate isn’t indexable (the matrix is huge in the performance guide). Tools do exist which greatly assist in this matter. However – more important issues do exist than these ones which are not reflected on the Explain output – please see the next page.
  • Explain “only” tells you the basic content of the SELECT, DELETE, UPDATE and INSERT statements – but a lot of other “stuff” is going on behind the scenes which isn’t reflected. The following issues are very important to have in mind when performance is analyzed – no matter if this happens before or after the Explain is executed: Referential Integrity cannot be viewed and can have a major impact on the performance if nor properly indexed. An insert can turn out to be a disaster. Triggers being fired as a result of the SQL statement are not listed in the Explain output – again this can result in “less than optimal performance”, and the same goes for UDF’s which will have to be explained separately. Check constraints are not listed either. Another issue to think about is – even though the Explain output shows one access path, there is no guarantee this access path will be used. DB2 reserves the right to disable prefetch activity – and enable again. The same goes for parallelism – DB2 might turn off the parallelism at execution time, so this is just an indication – or intent. RID Pool shortage used to be a disaster and the SQL execution could fail. DB2 9 has changed this so DB2 will fall back to a tablespace scan, so make sure this event is monitored.
  • The invention of the DSN_STATEMNT_TABLE being part of the Explain process was (in my opinion) some great news. I believe it is almost as important as the PLAN_TABLE itself due to a couple of columns present in this table: Two of the columns I really like are the PROCSU and PROCMS which can be used to compare costs for a statement between program versions – or – compare the costs associated with different SQL statements like illustrated earlier where two different statements produced the same result-set, but were quite different in terms of costs. Another reason is – it’s a lot easier to compare numbers than rows in the PLAN_TABLE. The DSN_STATEMNT_TABLE got one additional column in DB2 9 which is the estimated ELAPSED TIME. According to IBM this should only be compared within the “same statement” and “same DB2 version” and not to other statements.
  • And we have another “new born” – DB2 9 has introduced about 9 new tables to be used with Optimization tools – like Explain. One of the most exiting new tables is the DSN_VIRTUAL_INDEXES table to be used when doing EXPLAIN. It is used to “define” an index in order to verify if an index which currently doesn’t exist CAN be used by the Optimizer.
  • I believe most of us have had scenarios where we think the Optimizer decided an Access Path we did not agree with. In “the old days” a few years ago, the “wrong” access path usually was due to insufficient information. Not because we didn’t supply the Optimizer with correct or enough information – but simply because the catalog and DB2 did NOT have any mechanics to capture and store the information. Runstats was very simple and the Optimizer was still at the stage where it hadn’t learn to walk – still crawling and needing a chair to get up. Where the Access Path often went South was when the table had very skewed data in one or more columns – and where there wasn’t enough information for every column in the index – or rather column combinations. Today everything has changed. Runstats has a LOT more options to collect the information needed for the Optimizer to make more mature decisions.
  • What did we do a few years back when the Optimizer picked a “wrong” access path ? We had no OPTHINT so we could describe the access path in the PLAN_TABLE and try to have DB2 pick the desired access path. Runstats had no REPORT option – meaning we had to execute Runstats and then hope for no BIND/REBIND until we fixed potential performance issues. We only had FIRSTKEYCARD and FULLKEYCARD which could be pretty bad for multi-column indexes with a few distinct values for the first key-column. I used to update NLEVELS to favor other indexes, change the CLUSTERRATIO, update FIRSTKEYCARD, . . . . . . . . No fun since how did you store this information when the information was changed in the catalog. A lot of users used to (and still do) change the SQL statements to add all kind of weird predicates – making it difficult for the next person to maintain the SQL statement.
  • Some of the bad scenarios was to force index access – DB2 V8 introduced VOLATILE for the table DDL, which is a way better method to tell that an index should be used if present. This also eliminates the documentation issue of keeping track of which tables should have forced index access (I used to use LABEL and COMMENT when I manually manipulated catalog columns). One issue to have in mind is – PREFETCH will be disabled for these tables. Another method to “HELP” the Optimizer is to use REOPT on the BIND statement. Be careful using this parameter due to the costs of evaluating Access Path at execution time, but for situations where the AP really should be different based on the host variable content (and data is very skewed) – this might be a way better solution than messing with the catalog – og having more indexes being manipulated manually. OPTIMIZE for xx ROWS is another nice method to change the Optimizers mind. Remember this doesn’t restrict you from selecting MORE rows than specified. For this case DB2 V8 introduced FETCH FIRST x ROWS ONLY. Another common method is to rearrange the tables in the FROM clause so the table providing the best filtering is listed first. Finally – adding a predicate like < 0=1 > can invalidate some index usage.
  • The previous slide mentioned the use of OPTHINT. I don’t think this ever got the usage it was intended to get – it’s not a widely spread used method. It is not a very user friendly method, but it’s still way better than manually manipulating the catalog. The outlined method requires a few steps to get a package-statement using “the desired” access path – and it only works for statements going through the BIND process. If this method appeals to you – consider using the QUERYNO in the SQL statement in the programs. This will eliminate the need to go back and redo the whole thing when the statement changes in the source code. Doing this also provide an easier method to compare PLAN_TABLE content between program versions (more about this later).
  • However – before moving into some of the manual manipulative methods – the preferred method is still to use the DB2 tools available – RUNSTATS !!! One major reason is the Optimizer changes between every version – and even within one DB2 version, and going through all the packages/statements changed in order to get better performance is a nightmare. RUNSTATS has evolved dramatically – especially in DB2 V8 and DB2 9. The COLGROUP parameter is a great method to get cardinality for combinations of columns (as opposed to FIRSTKEYCARDF and FULLKEYCARDF) – and it’s even possible to describe the number of combinations is needed depending how skewed the data is. DB2 9 introduced HISTOGRAM statistics which can be used too where ranges of variation exist. Soon – we probably won’t even have to think about RUNSTATS – I believe it will become an integral part of the “DB2 engine”.
  • So far we have been talking about how to get Access Path described and some methods to manipulate the Optimizers decision. This all leads to the main point in this presentation – Versioning Explain – why this is important. Two reasons: We need a proactive approach in order to predict the performance for both new and changes SQL statements. This is a lot easier to control for static programs than all the Wild Wild Web from the dynamic world. We also need to have a good reactive approach in place. Admitted we cannot catch everything before the SQL is in production – or when something changes upon which the SQL is dependent. So we need to have a method to find out what happened when and why. In most cases this is when users complain about performance, but it happens that someone asks us “why does transaction xyz run faster / use less CPU ?”. If we can find the cause we might be able to apply identical changes to other applications.
  • My point is – having the REACTIVE plan in place as well as the PROACTIVE plan in place is JUST AS IMPORTANT. You might ask – why is Explain so interesting ? Isn’t it enough to simply have access to the most recent Access Path in PLAN_TABLE ? In my opinion this is not sufficient – I really prefer to have access to the CURRENT access path to in order to compare all the ingredients involved in the Access Path selection from the past explain and the current explain. So many things can have changed the Access Path (my favorite scan) – so in order to save time playing “Sherlock Holmes” I need all these ingredients to be handy (we will look into the ingredients later). Having the REACTIVE plan in place is important so we can find out WHAT made the Access Path change – for the better or worse. The purpose of having a PROACTIVE plan in place, is to be able PREDICT what the performance will be before the SQL / Package is ported to production. There are many ways to accomplish this – productions catalog statistics can be imported into the “explain environment”, the program can have a BIND executed with EXPLAIN(YES) on the production system using a “QA Collection-id” – and there are probably many more methods to accomplish this. The main idea is to PREDICT what the Access path and cost will be.
  • In many cases, Explain is only used by DB2 DBA’s. In order to utilize the resources and knowledge available, the application developers should use an Explain tool too – like CA Plan Analyzer. Instead of having the DBA’s chase the developers to make them change the SQL, the developers can gain a lot of knowledge by using CA Plan Analyzer due to the Expert System Rules and recommendations. One important issue or recommendation is to create Explain Profiles up front so the users don’t have to walk through a lot of options and decisions. Instead the user can simply select the profile of choice where all the needed options and reports are defined.
  • The important parameters are marked with red. Database Options is used to specify versions of the explain will be saved. DB2 subsystem-id (or group attach name must be specified – here S81A). Use Rollback of PLAN_TABLE output since these will be saved in the Plan Analyzer repository anyway. Specify Future explain in order to see what the Access path will be as opposed to Current, which describes the current access path as recorded in the plan-table. Specify SAVE REPORTS so these can be viewed at a later time. Specify UPDATE REPORTS in order to describe which reports to generate when Explain is executed.
  • Most of the reports can be generated as long or short format. The red ones are my preference, but a good idea is to execute one explain with all the reports long and another explain with all the reports short (where this is possible) and then decide which ones provide the best information. Also – remember there can be as many profiles as needed in order to reflect the different levels og expertise and knowledge. Specify that the Compare should be generated and by also chosing the Compare Options, it is possible to describe what the compare report should include (see next slide). The STATISTICS report is also important – more about this later.
  • This is the different options available for the Compare report. Describe what the report should include when CA Plan Analyzer has found a difference in Access Path
  • We start by creating a strategy where the strategy name is identical to the program name (package). This is an easy method to automate and it’s easy to find the information when performance needs to be investigated.
  • Since this strategy will explain a DBRM, the TYPE is specified as D and the DBRM library and member is specified. Wildcarding is possible here too, so RQA* would pull in all DBRM’s with a name starting with RQA. It is also possible to select a number of DBRM’s by using RQA% instead.
  • After the strategy is created, option E(xplain) is typed for the strategy whereby this panel is displayed. Simply specify the EXPLAIN PROFILE needed and hit ENTER, and the CA Plan Analyzer explain is executed.
  • Once the explain is finished executing, the first version of explain is generated.
  • Instead of creating the strategy online, the control cards can be imbedded in a batch step and appended the program promotion procedure in the Change Management process. In fact, nothing needs to be done in CA Plan Analyzer to implement this process. The batch control cards will CREATE a strategy if it doesn’t exist already, and in both cases – an explain version is created. The versioning works like a wrap-around, so when the maximum number of versions exist, this process will delete the oldest. The parameters marked in red need to be symbolic values to be replaced by the change management process for the program promotion procedure.
  • Now the second explain for this strategy (package) has been executed and version 2 is created. Using option R will display all the reports generated for this explain version.
  • Let us have a closer look at the Explain Compare report.
  • Statement 1202 has changed from matchcols=1 to matchcols=2 and at the same time has gone from List prefetch to no prefetch. The Service Units has decreased 86% compared to the previous explain, so performance should get a lot better. Every access path change is illustrated by a hyphen.
  • The sixth statement was statement number 1322 but now is statement number 1325 (someone must have added additional application code). This statement will change from matchcols=2 to matchcols=1 which will be a 300% increase in service units.
  • Another useful report to look into when performance and access path needs to be analyzed in detail is the Catalog Statistics report. This might lead to the answer why the access path was chosen. This report is especially invaluable when comparing access path between two version is needed since the access path change might be due to changed catalog statistics, so it is possible to see the catalog statistics from the point in time the Explain was executed last time (and even earlier if needed).
  • The biggest advantage using the automated batch explain approach is, that corrective actions can be done prior to the program moving into production. Also – it provides a unique opportunity to quickly identify WHEN performance changed and WHAT the reason was when someone asks “what happened – why does this transaction use more resources ?” Having access to this kind of information, it is possible to identify reasons for performance changes and use this in other scenarios.
  • Bottom line – having a well defined PROACTIVE procedure as well as being able to react quickly when being in a REACTIVE mode is important. Both issues can be automated using CA Plan Analyzer.
  • At this point we have covered a lot of details why Explain versioning is worth to consider if not already implemented. The entire approach – both the REACTIVE as well as the PROACTIVE has been covered, but ONE issue can make the whole thing almost fall apart, but it really needs to be considered, and there are ways to deal with the following issue too. Even though we make all kind of precautions in order to be PROACTIVE and prepare for the REACTIVE approach – consider the situations where a Package is having a REBIND executed outside the normal “change management” implementation. One method to “catch” these is to have a daily job finding the Packages and pass these through the “normal Explain process” in order to save the new access path, catalog statistics etc. Talking about REBIND – this brings us to one topic popping up all the time : When to REBIND and when NOT to REBIND . . . . . . . . . . . . My believe is – if it works – don’t touch it UNLESS major changes has happened to the data AND statistics in the catalog.
  • The main issue with REBIND is – DB2 will generate a new Access Path (unless OPTHINT used and utilized), but it MIGHT be the same Access Path. Is this a great idea ? Maybe – but we really don’t know until after the fact – and this is the big issue and concern. What IF the DB2 catalog statistics isn’t “optimal” – someone by accident executed Runstats before the reorg of a very disorganized object was done !!! Another issue is – when dealing with TRIGGERS – the only way to predict the performance of a trigger is to do a REBIND using EXPLAIN(YES). Again like mentioned earlier – the REBIND’s happening outside of “our” control can mess up our very good intentions being PROACTIVE.
  • One of the reasons for using the previously mentioned methods to collect all the information is – in case the Access path suddenly went South – hopefully we can “restore” the catalog information and get back our “FAVORITE SCAN”. In other words – having the ability to FALLBACK to a previous Access Path. This has NOT been an easy task – at least until now. Once on DB2 9, a relative new APAR is available making the fallback procedure a lot easier. Depending on the ZPARM setting and BIND parameters – it is possible to save up to three copies / versions of a Package. All that is needed is to start using some one BIND parameter for the REBIND statement : PLANMGMT. This parameter basically allows you to SAVE an Access Path after the INITIAL BIND is executed.
  • The previous page illustrated how it now is possible to save an ACCESS PATH. Let’s assume you end up with a package after a REBIND with “less than optimal” Access Path – it is now possible to FALLBACK to a previously saved Access Path by using another REBIND parameter which is SWITCH.
  • These three jobs illustrates how this new – excellent - feature can be used to save a preferred Access Path using the EXTENDED keyword for PLANMGMT which allows up to three versions of the Package. If an earlier version of a package needs to be active, the Package will have to go through a REBIND using the parameter SWITCH which will indicate which version is desired to become the active. The third example illustrates you cannot SWITCH back to a previously saved Package Access path version – unless you have SAVED one using the new parameter PLANMGMT in the REBIND
  • One question comes to mind when dealing with multiple version of a Package Access Path – where is this stuff stored. I haven’t found much documentation for this very new feature, but using my favorite “secret weapon” – this is what I discovered: 1) Doing three REBIND’s of one Package resulted in 103 updates to the Skeleton Package Table. 2) When the same Package had a REBIND executed doing a FALLBACK using the SWITCH(PREVIOUS), this resulted in 309 updates to SPTR. Based on this scenario, all the versions are stored in the SPTR table – so make sure you have enough additional space allocated to this dataset before enabling this new feature.
  • How to Predict DB2 Performance Changes

    1. 1. How To Predict DB2 Performance Changes Mainframe MB103SN
    2. 2. Abstract <ul><li>The attendee will get a quick overview of Explain evolution over time and how this feature has become the mirror of the Optimizer </li></ul><ul><li>We will look at some potential methods to exploit in order to influence the Optimizers decisions and some issues to have in mind where Explain doesn’t show the “real picture”. </li></ul><ul><li>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 </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    3. 3. Agenda <ul><li>Explain Evolution over the years – are you aware of all the new stuff ? </li></ul><ul><li>Optimizer resources for choosing the” correct” Access Path and how the user can influence these decisions </li></ul><ul><li>Methods to make corrective actions to application SQL and how to predict Access Path / Performance </li></ul><ul><li>Using CA Plan Analyzer to have a Proactive and a Reactive approach in place </li></ul><ul><ul><li>How CA Plan Analyzer can automate Explain Versioning in order to find the reasons for Access Path change or performance degradation / improvement </li></ul></ul><ul><ul><li>A method to compare the costs and performance improvements/degradation prior to a potential Bind or Rebind </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    4. 4. What is EXPLAIN <ul><li>Some very important issues when dealing with DB2 Performance </li></ul><ul><ul><ul><li>Not only a Systems Programmer task </li></ul></ul></ul><ul><ul><ul><li>Not only a DBA task </li></ul></ul></ul><ul><ul><ul><li>Not only an Application Programmer / Analyst task </li></ul></ul></ul><ul><li>It’s one common task </li></ul><ul><ul><ul><li>Important to have DBA’s and Application folks speak the same language </li></ul></ul></ul><ul><ul><ul><li>Don’t “point fingers” and don’t direct without explaining WHY ! </li></ul></ul></ul><ul><ul><ul><ul><li>Let the Application Developer understand what is happening </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Let the DBA understand the business </li></ul></ul></ul></ul><ul><ul><ul><li>Too often “bad things” are found too late </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    5. 5. What is EXPLAIN <ul><li>Illustrates how DB2’s Optimizer will execute SQL, a Package or a Plan (depending on how EXPLAIN is executed) </li></ul><ul><li>Why is EXPLAIN a necessity </li></ul><ul><ul><li>Can’t we simply look at the SQL-statement and estimate if it has been coded “all right” (we used to) </li></ul></ul><ul><ul><ul><li>What if it’s a 12 table join </li></ul></ul></ul><ul><ul><ul><li>Or the statement is 2 MB (or “just” 24 KB) </li></ul></ul></ul><ul><ul><li>Does performance mean anything – if a statement executes in half a second or 5 minutes ? </li></ul></ul><ul><ul><li>Predict WHAT will happen when SQL changes or after a Package REBIND when a reorganization and Runstats executed </li></ul></ul><ul><ul><li>The latest example – how will upgrading to DB2 V8 impact Access Path (compare DB2 V7 Optimizer with DB2 V8) </li></ul></ul><ul><ul><li>Do you always know whether a JOIN or SUBSELECT/EXISTS provides the best performance ?? (let’s see an example) </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Let’s see a cool example IDUG NA2007 alt.doc
    6. 6. What is EXPLAIN <ul><li>Explain is invaluable to check how the DB2 Optimizer decides to access the data </li></ul><ul><li>The following pages illustrates that even though the RESULT-SET is good and expected – the performance might be very different and not desirable </li></ul><ul><ul><ul><li>We will get back to the EXPLAIN prerequisites in the next section </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. SELECT * FROM DSN8810.EMP outer WHERE NOT EXISTS (SELECT * FROM DSN8810.EMP inner WHERE outer.WORKDEPT IN ('D11','C11') ); SELECT * FROM DSN8810.EMP outer WHERE outer.WORKDEPT NOT IN ('D11','C11') ;
    7. 7. What is EXPLAIN <ul><li>Two different SQL statements might give the same result – but is performance identical ? </li></ul><ul><li>One example where it pays off to utilize Explain: </li></ul><ul><ul><ul><li>Explain these two statements – same result-set !!!! </li></ul></ul></ul><ul><ul><ul><li>Any differences in Access Path ? </li></ul></ul></ul><ul><ul><ul><li>What about Cost estimates ? </li></ul></ul></ul>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') ; COMMIT; SELECT * FROM PLAN_TABLE where queryno in (810,811); SELECT * FROM DSN_STATEMNT_TABLE where queryno in (810,811);
    8. 8. What is EXPLAIN <ul><li>EXPLAIN output (the essential part) for these two statements </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. QUERYNO QBLOCKNO APPL NAME PROGNAME PLANNO METHOD CREATOR 810 2 BPASQL8 1 0 DSN8810 810 1 BPASQL8 1 0 DSN8810 811 1 BPASQL8 1 0 DSN8810 TNAME TABNO ACCESSTYPE MATCHCOLS ACCESSCREATOR EMP 2 I 0 DSN8810 EMP 1 R 0 EMP 1 R 0 ACCESSNAME INDEXONLY XEMP2 Y N N ~~~~~~~~~~~~~~~ from DSN_STATEMNT_TABLE ~~~~~~~~~~~~~ QUERYNO APPLNAME PROGNAME PROCMS PROCSU 810 BPASQL8 216 6000 811 BPASQL8 98 2706
    9. 9. What is EXPLAIN <ul><li>Execution statistics for these two statements </li></ul><ul><ul><ul><li>Reflects what Explain described </li></ul></ul></ul><ul><ul><ul><li>A clear difference in performance and access path – even though the result-sets are identical </li></ul></ul></ul><ul><li>Use EXPLAIN as part of the development toolset !!!!!! </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. R11.05 > ------ DETECTOR Exception SQL Request Summary ------ 08-28-07 16:22 Command ==> Scroll ==> PAGE Line 1 of 2 OPID ==> RASST02 DB2 SSID ==> S81A Total/Avg ==> T Interval Time ==> 04:00 Interval Elapsed ==> 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 ********************************
    10. 10. What is EXPLAIN <ul><li>Why is Performance so important </li></ul><ul><ul><li>Bad performing SQL costs $$$$ </li></ul></ul><ul><ul><li>One benchmark a few years ago illustrates: </li></ul></ul><ul><ul><ul><ul><li>It costs $30 to correct “bad” SQL in test </li></ul></ul></ul></ul><ul><ul><ul><ul><li>It costs $1000 to correct in production </li></ul></ul></ul></ul><ul><ul><li>If response times are not optimal </li></ul></ul><ul><ul><ul><li>Fewer transactions will go through the pipe </li></ul></ul></ul><ul><ul><ul><li>Each end user will be less productive </li></ul></ul></ul><ul><ul><ul><li>Other SQL-statements will suffer due to sharing of resources </li></ul></ul></ul><ul><ul><ul><ul><li>Buffer Pools, I/O channels, Locking conflicts, contention in shared pools like SORT area, RID pool, . . . . </li></ul></ul></ul></ul><ul><ul><li>Hardware upgrade to conform to SLA </li></ul></ul><ul><ul><li>Potential loss of business – especially for businesses dependent on Internet applications </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    11. 11. What’s influencing the EXPLAIN output <ul><li>Some factors to consider when comparing Explain between two different environments </li></ul><ul><ul><ul><li>Optimizer looks at Hardware type </li></ul></ul></ul><ul><ul><ul><li>Optimizer looks at number of processors </li></ul></ul></ul><ul><ul><ul><li>Optimizer looks at Buffer Pools </li></ul></ul></ul><ul><ul><ul><li>Costs to allocate work-files </li></ul></ul></ul><ul><li>Host variables will be replaced by “Parameter Markers” when doing dynamic Explain (as opposed to Explain during Bind/Rebind) </li></ul><ul><ul><ul><li>This could be a major problem in earlier DB2 versions (prior to DB2 V8) </li></ul></ul></ul><ul><ul><ul><li>When host variables (or column predicate) was defined differently than the column defined in the DB2 catalog </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    12. 12. What’s influencing the EXPLAIN output <ul><li>Table size (and compression) </li></ul><ul><li>Column cardinality and Filter Factor </li></ul><ul><li>Indexes present and the index columns </li></ul><ul><ul><li>FIRSTKEYCARDF and FULLKEYCARDF and now more granular statistics when portion of index columns referenced </li></ul></ul><ul><ul><li>Different RUNSTATS parameters to collect these statistics </li></ul></ul><ul><li>Clustering (Cluster Ratio) and number of index levels </li></ul><ul><li>SQL predicates (predicate analysis) </li></ul><ul><li>ORDER BY and the ability to eliminate sorts </li></ul><ul><li>. . . . . . . . . . and many more details </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    13. 13. EXPLAIN Pre-Requisites <ul><li>EXPLAIN tables </li></ul><ul><ul><li>creator.PLAN_TABLE (minimum to do explain) </li></ul></ul><ul><ul><ul><li>Records Optimizers choice of Access Path </li></ul></ul></ul><ul><ul><ul><li>Not immediately easy to decrypt – many “codes” </li></ul></ul></ul><ul><ul><li>creator.DSN_STATEMNT_TABLE (optional) </li></ul></ul><ul><ul><ul><li>Shows COST estimates (this is HUGE in my opinion) </li></ul></ul></ul><ul><ul><li>creator.DSN_FUNCTION_TABLE (optional) </li></ul></ul><ul><ul><ul><li>Only used if UDF’s need to be explained </li></ul></ul></ul><ul><ul><li>Creator.DSN_STATEMENT_CACHE_TABLE (new in DB2 V8) </li></ul></ul><ul><ul><ul><li>Used to explain the DB2 Dynamic Statement Cache </li></ul></ul></ul><ul><ul><li>With DB2 9 there are 10 additional tables to consider </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    14. 14. PLAN_TABLE evolution June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. V1R1M0 Where is Explain ? V1R2 25 columns V2R1 28 columns V2R3 30 columns V3R1 34 columns V4 43 columns V5 46 columns V6 49 columns V7 51 columns V8 58 columns 9 59 columns Sequential Prefetch Packages Parallelism Data Sharing and more parallelism Re-optimization Optimization Hints Table types like temporary, work file Encoding scheme - Unicode Lots of new information to existing columns
    15. 15. PLAN_TABLE evolution <ul><li>Even though the PLAN_TABLE is invaluable there are a number of issues to consider </li></ul><ul><ul><ul><li>The Optimizers “thoughts” are not reflected </li></ul></ul></ul><ul><ul><ul><li>Why one index was chosen over the other </li></ul></ul></ul><ul><ul><ul><li>Why one table was picked as the first accessed instead of another in a join sequence </li></ul></ul></ul><ul><ul><ul><li>Why a predicate is considered STAGE1 or STAGE2 </li></ul></ul></ul><ul><ul><ul><li>Why a predicate isn’t indexable </li></ul></ul></ul><ul><ul><ul><li>Visual Explain does help to explain some of these issues </li></ul></ul></ul><ul><ul><li>The most important issues when analyzing the Access Path described in the PLAN_TABLE  </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    16. 16. PLAN_TABLE evolution <ul><li>Explain only shows SELECT, DELETE, UPDATE, INSERT </li></ul><ul><li>Important not to forget the issues below when doing performance / tuning </li></ul><ul><ul><ul><li>RI Definitions </li></ul></ul></ul><ul><ul><ul><li>TRIGGERs executed as part of the SQL-statement </li></ul></ul></ul><ul><ul><ul><li>UDF’s </li></ul></ul></ul><ul><ul><ul><li>Table- and Column Check Constraints </li></ul></ul></ul><ul><li>Not always a guarantee DB2 will USE the illustrated AP </li></ul><ul><ul><ul><li>Prefetch activities can be disabled depending on BP status </li></ul></ul></ul><ul><ul><ul><li>Parallelism is decided at the execution time </li></ul></ul></ul><ul><ul><ul><li>RID Pool shortage (DB2 V8 changed the behavior) </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    17. 17. PLAN_TABLE evolution <ul><li>The birth of DSN_STATEMNT_TABLE one of the greatest news </li></ul><ul><ul><ul><li>Almost as important as the PLAN_TABLE itself </li></ul></ul></ul><ul><ul><ul><li>PROCMS and PROCSU can be used to compare costs between different versions of a statement or package </li></ul></ul></ul><ul><ul><ul><li>Somehow it’s easier than comparing the PLAN_TABLE content </li></ul></ul></ul><ul><ul><ul><ul><li>Numbers are nice when somehow accurate </li></ul></ul></ul></ul><ul><ul><ul><li>Don’t base all your decisions on these numbers only – use them to compare a previous Access Path </li></ul></ul></ul><ul><ul><li>DB2 9 for z/OS introduced one additional column in DSN_STATEMNT_TABLE </li></ul></ul><ul><ul><ul><li>TOTAL_COST - The estimated cost of the statement (elapsed time) to compare with explain versions of the same statement </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    18. 18. PLAN_TABLE evolution <ul><li>WHAT-IF analysis </li></ul><ul><ul><li>DB2 9 provides another new feature – the ability to do explain with virtual indexes </li></ul></ul><ul><ul><li>One additional table needs to be created for the Explain feature. </li></ul></ul><ul><ul><li>The VIRTUAL index will show up in the PLAN_TABLE if it can be used </li></ul></ul>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 , &quot;PADDED&quot; CHAR ( 1 ) , COLNO1 SMALLINT , ORDERING1 CHAR ( 1 ) , COLNO2 SMALLINT , ORDERING2 CHAR ( 1 ) , . . . . , . . . . , COLNO64 SMALLINT , ORDERING64 CHAR ( 1 ) )
    19. 19. Help or Fool the Optimizer <ul><li>The Optimizer not always perfect - what are the options when a “ less optimal ” Access Path chosen </li></ul><ul><ul><li>Used to be because of insufficient information due to “lack of features in Runstats” - or the Optimizer being a “toddler” still learning </li></ul></ul><ul><ul><li>Nowadays - bad decisions mostly due to: </li></ul></ul><ul><ul><ul><li>Insufficient information in the catalog </li></ul></ul></ul><ul><ul><ul><li>Catalog statistics doesn’t reflect the reality </li></ul></ul></ul><ul><ul><ul><li>The table data is skewed – not evenly distributed (highly uneven frequency) </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    20. 20. Help or Fool the Optimizer <ul><li>What did we do in the “good old days” </li></ul><ul><ul><ul><li>We had no OPTHINT </li></ul></ul></ul><ul><ul><ul><li>No FETCH ONLY and no FETCH FIRST </li></ul></ul></ul><ul><ul><ul><li>No report option for Runstats (live or die) </li></ul></ul></ul><ul><ul><ul><li>Only cardinality for FIRSTKEYCARD(f) and FULLKEYCARD(f) </li></ul></ul></ul><ul><ul><ul><ul><li>A challenge when 4 columns in index and MC=2 with low cardinality for first column </li></ul></ul></ul></ul><ul><ul><li>Update catalog changing NLEVELS of indexes </li></ul></ul><ul><ul><li>Update catalog changing the Clusterratio </li></ul></ul><ul><ul><li>Add strange predicates (e.g. +0 or *1) to SQL statement making it less understandable for the next person </li></ul></ul><ul><ul><li>Adding “additional duplicate” predicates </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Just to name a few – let’s see the goodies !
    21. 21. Help or Fool the Optimizer <ul><li>VOLATILE – a better way to force index access compared to manually manipulating Catalog statistics </li></ul><ul><ul><ul><li>Update NLEVELS, CARDF etc. </li></ul></ul></ul><ul><ul><ul><li>Remember Prefetch is disabled </li></ul></ul></ul><ul><li>REOPT (xxxx) </li></ul><ul><ul><li>where cardinality is really skewed and the costs associated with re-optimization is less than the benefits from different Access Path. </li></ul></ul><ul><ul><ul><li>NONE, ONCE, ALWAYS, AUTO (DB2 9 - ZPARM parameter) </li></ul></ul></ul><ul><li>OPTIMIZE FOR xx ROWS </li></ul><ul><li>FETCH FIRST xx ROWS ONLY </li></ul><ul><li>Rearrange tables in the FROM clause still might help </li></ul><ul><ul><li>Predicates can still be “invalidated” by adding 0=1 </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    22. 22. Help or Fool the Optimizer <ul><li>OPTHINT – not the most intelligent implementation, but still better than manually updating the catalog and keep track of changes </li></ul><ul><ul><li>Identify QUERYNO from PLAN_TABLE (preferable to use QUERYNO yyy in SQL statement) </li></ul></ul><ul><ul><li>Update PLAN_TABLE for QUERYNO with “access path” and specify OPTHINT name </li></ul></ul><ul><ul><li>Either specify OPTHINT in Rebind or use SET CURRENT OPTIMIZATION HINT=‘hint name’ </li></ul></ul><ul><ul><li>Execute EXPLAIN and study HINT_USED in PLAN_TABLE </li></ul></ul><ul><ul><ul><li>SQL+394  Hint used </li></ul></ul></ul><ul><ul><ul><li>SQL+395  something is wrong </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    23. 23. <ul><li>Runstats the first choice – and easiest method </li></ul><ul><ul><li>Especially since Optimizer changes all the time </li></ul></ul><ul><li>Exploit the many great keywords and parameters in Runstats </li></ul><ul><ul><ul><li>Column combinations used in multi-column indexes </li></ul></ul></ul><ul><ul><ul><li>Are most frequent / least frequent values used </li></ul></ul></ul><ul><ul><ul><ul><li>Also needed for REOPT </li></ul></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Help or Fool the Optimizer RUNSTATS TABLESPACE db.ts TABLE(tbcr.tbnm) INDEX(all) KEYCARD COLGROUP(col1,col2,col3) COLGROUP(col3,col1) FREQVAL(30 / most / least / both)
    24. 24. Who stole my favorite scan <ul><li>All the previous mentioned issues lead to the essence of this presentation: Explain versioning </li></ul><ul><li>Finding the best proactive approach </li></ul><ul><ul><li>How much can be done ahead of time </li></ul></ul><ul><ul><li>Static SQL is a lot easier to deal with compared to dynamic SQL from the Wild Wild World of Java and other sources </li></ul></ul><ul><li>Finding the best reactive approach </li></ul><ul><ul><li>No matter how proactive we try to be, something will eventually fall between the cracks </li></ul></ul><ul><ul><ul><li>What changed and when ? </li></ul></ul></ul><ul><ul><li>Sometimes we are being pleasantly surprised by performance improvements </li></ul></ul><ul><ul><ul><li>What happened – and why ? </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    25. 25. Explain Versioning <ul><li>REACTIVE <> PROACTIVE Explain </li></ul><ul><ul><li>Reactive explain is just as important as the proactive </li></ul></ul><ul><ul><li>Why is versioning interesting – isn’t the most current PLAN_TABLE content sufficient ? </li></ul></ul><ul><ul><li>More interesting to see the current “real” Access Path </li></ul></ul><ul><ul><li>We really need a feature to show what the current Access Path is (explain what’s in SPT01) </li></ul></ul><ul><li>Proactive Explain – many ways to accomplish this </li></ul><ul><ul><li>Goal is to predict performance prior to production </li></ul></ul><ul><ul><ul><li>Import production catalog statistics into test </li></ul></ul></ul><ul><ul><ul><li>Or Bind into separate collection on Production </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    26. 26. Automate Explain Versioning using CA Plan Analyzer <ul><li>Consider to make information available for everyone </li></ul><ul><li>Consider to have Developers use the same concept </li></ul><ul><ul><ul><li>They learn what to do and not to do </li></ul></ul></ul><ul><ul><ul><li>They can see the impact </li></ul></ul></ul><ul><ul><ul><li>Less burden for the DBA’s </li></ul></ul></ul><ul><ul><ul><li>Better performance is the ultimate goal </li></ul></ul></ul><ul><li>CA Plan Analyzer can help you with all these aspects </li></ul><ul><ul><ul><li>Create Profiles reflecting the Users and Purposes </li></ul></ul></ul><ul><ul><ul><ul><li>Short or long Access Path description ? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Filter Factors and Predicate analysis ? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Object tree and object statistics ? </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Which Expert Rules and guidelines depends on knowledge ! </li></ul></ul></ul></ul><ul><ul><ul><li>Users simply PICK the profile they need based on experience, knowledge, task etc. </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    27. 27. Create Profile(s) <ul><li>Create as many Explain Profiles as needed to reflect the user profiles and skill level </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ---------------- PPA Explain Options --------------- 07-30-08 16:02 COMMAND ===> PROFILE ===> IDUGVER1 Description ===> DBA PROD EXPL+COMP Creator ===> RASST02 Share Option ===> U (U,Y, or N) ----------------------------------------------------------------- RASST02 Database Options ===> y Historical Database Options Primary AUTHID ===> Secondary AUTHID ===> Update SQL Qualifiers ===> (Override Schemas & SQL/View Qualifiers) Rule Set SSID ===> s81a (Subsystem where Rule Sets are stored) PLAN_TABLE Option ===> R (C - Commit, R - Rollback) Explain Type ===> F (C - Current, F - Future) Plan Explain Option ===> b (D - DBRM, P - Package, B - Both) Non-Catalog Isolation ===> CS Optimization Hint ===> Process Views (Y, N) ===> Y Parallelism Degree ===> Target SSID ===> s81a Target Rule Set ===> @DEFAULT Save Host Variables ===> Y Save Reports ===> y Uppercase Output ===> n Access Path Filters ===> N Reports ===> u Search Conditions ===> N Catalog Statistics ===> N Search Filters ===> N Tie PERFORMANCE Data ===> N Save Historic data as strategy
    28. 28. Create Profile(s) <ul><li>Specify which reports to generate and whether these should be Short or Long (knowledge level) </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 -------------- PPA Explain Reports --------------- 07-30-08 16:13 COMMAND ===> Summary Reports: Stmt Level Reports: Group Level Reports: Summary ===> n Access ===> s Planrule ===> N Cost ===> n Predicate ===> L RI ===> N Dependency ===> S Tree ===> N Sqlrule ===> s Statistics ===> y Physrule ===> N Compare ===> Y Predrule ===> N Performance ===> N Report Formatting Options: Compare Options ===> y Cost Filtering ===> Perf Total/Avg ===> T Suppress Reports ===> N (Ignore Stmt Level reports if rules not fired)
    29. 29. Create Profile(s) <ul><li>Specify what should be included in the compare report – SQL differences, Access Path changes, . . . . </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ------------ PPA Compare Report Options ------------ 07-30-08 16:15 Report Inclusion Options Change Level ===> A B - Changed/Unchanged S - SQL changed E - Either changed A - Access changed Paired stmts ===> B B - Paired/Unpaired P - Paired U - Unpaired Comparison Options Compare Creator ===> N Cost Margin (ms) => 08 (su) => 05 (tm) => Formatting Options SQL/Access Path ===> A B - Show SQL and Access S - Show SQL only C - Show the change only A - Show Access only SQL version ===> E E - Show once if equal O - Show OLD version Access version ===> E B - Show both versions N - Show NEW version Host Variables ===> C B - Show Changed/Unchanged C - Show Change Only N - Do not show Suppress Report ===> Y Y - No SQL and/or Access changes N - Show report Old HVersion ===> Options ===> Y Y – Save N – Use
    30. 30. Execute Explain using Profile <ul><li>Online creation of a strategy is used to explain a package / program in this case – but input can be anything </li></ul><ul><ul><ul><li>Program name used as strategy name  easy to identify and administer </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ----------------- PPA Quick Explain ---------------- 07-30-08 16:28 COMMAND ===> Strategy ===> R% Creator ===> RASST02 Type ===> E ----------------------------------------------------------------- RASST02 Location ===> LOCAL DB2 SSID ===> S81A Version ===> V8R1M0 STRATEGY T D S +----- LAST UPDATE -----+ CMD /VERSION DESCRIPTION CREATOR P B O USER DATE TIME c rqatsl _________________________ RASST02 E U <=== STRATEGY CREATION _ RMA@TCON RASST02 E U CALPE05 2005-05-15 10.05 _ V00001 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.17 _ V00002 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.20 _ V00003 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.21 _ V00004 VERSION AUTO CREATED RASST02 C M U RASST02 2005-06-13 09.09 _ RMA@TCO8 RASST02 E U RASST02 2005-04-28 18.04 _ V00001 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.03 _ V00002 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.13 ******************************** BOTTOM OF DATA ******************************* Batch automation to follow
    31. 31. Execute Explain using Profile <ul><li>Specify what the input to Explain is – in this case DBRMLIB is specified </li></ul><ul><li>Wildcarding supported too </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ------- PPA Explain Strategy - DBRMLIB Source Strategy : RQATSL Type : E Creator : RASST02 Share Option : U Version : Description : --------------------------------------------------------- Member Selection List ===> n (Y or N) Enter Specifications for your DBRMLIB Dataset. ISPF LIBRARY: PROJECT ===> RASST02 GROUP ===> R115 TYPE ===> DBRMLIB MEMBER ===> RQATSL (Blank, pattern, or member name) Specify the DBRMLIB Member(s) to include r11.5 --------- PPA Explain Strategy Data Editor --------- 07-30-08 17:17 Strategy : RQATSL Type ===> E Profile ===> IDUGVER1 Creator : RASST02 Share Option ===> U Version : Description ===> ----------------------------------------------------------------- RASST02 ----TARGET--- O C TY SSID RULE SET P LOCATION SSID PLAN/COLLID DBRM/PKG STMT c D s81a ________ _ LOCAL___________ s81a __________________ ________ ________ ******************************** BOTTOM OF DATA ******************************* CMDS : C - Create, E - Edit, D - Delete, R - Repeat, O - Options TYPES: A,AK,AO,AQ,AP - Autobuild(Plan,Package,Object,QMFQuery,PRFQuery) C,CK,CO,CQ,CP - Catalog(Plan,Package,Object,QMFQuery,PRFQuery) E,EK - EQF(Plan,Pkg), S - SQL, F - File, P - PRF, Q - QMF, D - DBRMLIB
    32. 32. Execute Explain using PPA Profile <ul><li>Once Explain command is executed for strategy – simply specify the PROFILE needed </li></ul><ul><li>The profile also holds the Expert System Rules </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 -------- PPA Explain Strategy - Version Info ------- 07-30-08 17:28 PP327I: Explain Profile options will be used for Explain. Strategy : RQATSL Type : E Profile ===> IDUGVER1 Creator : RASST02 Share Option : U Version : Description : ---------------------------------------------------------------------- RASST02 Version Information: Identifier ===> (Leave blank for system generated ID) Description ===> Options: Replace existing version ===> N (Y,N) Update Explain Options ===> N (Y,N) Easier to specify a profile than selecting the reports and options.
    33. 33. Execute Explain using Profile <ul><li>Once the explain is executed, the first Version is generated </li></ul><ul><ul><li>Lets change the DBRM and re-execute the explain - this time simply using the control cards in a batch job </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ---------- PPA Explain Strategy Services ---------- 07-31-08 11:37 LINE 1 OF 11 > Strategy ===> R% Creator ===> RASST02 Type ===> E ----------------------------------------------------------------- RASST02 Location ===> LOCAL DB2 SSID ===> S81A Version ===> V8R1M0 STRATEGY T D S +----- LAST UPDATE -----+ CMD /VERSION DESCRIPTION CREATOR P B O USER DATE TIME _ ________ _________________________ RASST02 E U <=== STRATEGY CREATION _ RMA@TCON RASST02 E U CALPE05 2005-05-15 10.05 _ V00001 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.17 _ V00002 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.20 _ V00003 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.21 _ V00004 VERSION AUTO CREATED RASST02 C M U RASST02 2005-06-13 09.09 _ RMA@TCO8 RASST02 E U RASST02 2005-04-28 18.04 _ V00001 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.03 _ V00002 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.13 _ RQATSL RASST02 E U RASST02 2008-07-30 17.28 _ V00001 VERSION AUTO CREATED RASST02 C S U RASST02 2008-07-30 17.48 ******************************** BOTTOM OF DATA *******************************
    34. 34. Execute Explain using Profile <ul><li>Batch JCL step to either create a new explain version or create a new strategy (if DBRM is new) </li></ul><ul><ul><li>Attributes marked in red should be replaced at generation time when integrated with Change Management process </li></ul></ul><ul><ul><li>Nothing needs to be done within PPA – executing this step is all that is needed. </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. //STEP1 EXEC PGM=PTLDRIVM,REGION=4M, // PARM='SUFFIX=00,EP=BPLBCTL' //STEPLIB DD DISP=SHR,DSN=SALESUP.R115SP1.LOADLIB //PTILIB DD DISP=SHR,DSN=SALESUP.R115SP1.LOADLIB //PTIPARM DD DISP=SHR,DSN=SALESUP.R115SP1.PARMLIB //SYSOUT DD SYSOUT=X //UTPRINT DD SYSOUT=X //ABNLIGNR DD DUMMY SUPPRESS ABENDAID DUMPS //BPIIPT DD * .CALL EXPLAIN .DATA .ENDDATA /* //BPIOPT DD * .CONTROL BPID( BP-RASST02-114817-20080731 ) + LOGID( S81A ) UNIT(SYSDA) .LIST SYSOUT(X,,) .OPTION NOERRORS .RESTART OVERRIDE .CONNECT S81A RULESSID = ( S81A ) ACM = (N,RASST02) STRATEGY = ( S81A , RQATSL ,RASST02,@AUTO) PLANTAB = (ROLLBACK) SQLQUAL = (RASST02) LINES = (55) PROCDDF = (N) FLOATFMT = (SCI) SAVEHOST = (Y) PROCVIEW = (Y) EXPLTYPE = (FUTURE) ISOLATE = (CS) TARGET = ( S81A (@DEFAULT)) PERFTIE = (N) DATABASE = (STRATEGY) REPORT = (ACCESS/SHORT,PREDICATE, DEPENDENCY/SHORT, STATISTICS,SQLRULE/SHORT, PREDRULE,COMPARE) STATSRPT = (TSP,TB,IX,IXP,CO) COMPOPTS = (ABNAEE CY,,N,08,05,) SRCDBRML = ( RASST02.R115.DBRMLIB(RQATSL ),)
    35. 35. Execute Explain using Profile <ul><li>Executing the JCL from the previous page will create VERSION 2 of the Explain for this DBRM / Package </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ---------- PPA Explain Strategy Services ---------- 07-31-08 12:50 LINE 1 OF 12 > Strategy ===> R% Creator ===> RASST02 Type ===> E ----------------------------------------------------------------- RASST02 Location ===> LOCAL DB2 SSID ===> S81A Version ===> V8R1M0 STRATEGY T D S +----- LAST UPDATE -----+ CMD /VERSION DESCRIPTION CREATOR P B O USER DATE TIME _ ________ _________________________ RASST02 E U <=== STRATEGY CREATION _ RMA@TCON RASST02 E U CALPE05 2005-05-15 10.05 _ V00001 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.17 _ V00002 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.20 _ V00003 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.21 _ V00004 VERSION AUTO CREATED RASST02 C M U RASST02 2005-06-13 09.09 _ RMA@TCO8 RASST02 E U RASST02 2005-04-28 18.04 _ V00001 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.03 _ V00002 VERSION AUTO CREATED RASST02 C M U RASST02 2005-04-28 18.13 _ RQATSL RASST02 E U RASST02 2008-07-30 17.28 _ V00001 VERSION AUTO CREATED RASST02 C S U RASST02 2008-07-30 17.48 R V00002 VERSION AUTO CREATED RASST02 C S U RASST02 2008-07-31 11.53 ******************************** BOTTOM OF DATA *******************************
    36. 36. View Explain Reports <ul><li>Use option “R” to view the generated reports for a specific Explain version - then Select the reports of interest </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. r11.5 ---------- PPA Explain - Output Selection ---------- 07-31-08 13:09 Strategy : RQATSL Creator : RASST02 Version : V00002 Share Opt: U Type : C Desc : VERSION AUTO CREATED ---------------------------------------------------------------------- RASST02 Available Sel ( Indicate Selections with an &quot;S&quot; ) Y _ INPUT (Explain input statements) _ SUMMARY (Explain summary report) Y _ ACCESS (Access path report) _ COST (Relative cost report) Y _ PREDICATE (Predicate analysis report) Y _ DEPENDENCY (Object dependency report) _ TREE (Object tree report) Y _ STATISTICS (Catalog statistics report) Y _ SQLRULE (SQL rules/recommendations) _ PHYSRULE (Physical rules/recommendations) _ PLANRULE (Plan rules/recommendations) _ PREDRULE (Predicate rules/recommendations) Y _ ERRORS (Error messages) Y S COMPARE (Compare Explain Versions report) _ PERFORMANCE (Performance Report) _ STATS MGR (Statistics Manager Interface)
    37. 37. View Explain Compare Report <ul><li>The compare report selected and displayed (first access path change listed) . </li></ul><ul><ul><ul><li>Changes to Access Path noted by hyphens </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Old: Source: New: Source: DBRM: RQATSL DBRM: RQATSL Statement: 1292 (3) Statement: 1292 (3) Old Access Path Analysis: Cost: (ms) 1 (su) 7 (tm) +.88415 E+02 PQbkNo: 0 QblkNo: 1 PlanNo: 1 MxOpSq: 0 TBTyp: TABLE Access: IXDATA TSLock: IS Prefet: L QblkTy: SEL TabNo: 1 Table : SYSIBM.SYSTABLESPACE CorrNm: A Index : SYSIBM.DSNDSX01 MCols : 1 New Access Path Analysis: Cost: (ms) 1 -(su) 1 (tm) +.11048 E+02 Diff: (ms) None -(su) 86% Decr PQbkNo: 0 QblkNo: 1 PlanNo: 1 MxOpSq: 0 TBTyp: TABLE Access: IXDATA TSLock: IS Prefet:-? QblkTy: SEL TabNo: 1 Table : SYSIBM.SYSTABLESPACE CorrNm: A Index : SYSIBM.DSNDSX01 MCols :-2 This statement will perform better than the previous version
    38. 38. View Explain Compare Report <ul><li>. . . and the second Access Path Change </li></ul><ul><ul><ul><li>This statement will have worse performance </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Old: Source: New: Source: DBRM: RQATSL DBRM: RQATSL Statement: 1322 (6) Statement: 1325 (6) Old Access Path Analysis: Cost: (ms) 1 (su) 1 (tm) +.11048 E+02 PQbkNo: 0 QblkNo: 1 PlanNo: 1 MxOpSq: 0 TBTyp: TABLE Access: IXDATA TSLock: IS Prefet: QblkTy: SEL TabNo: 1 Table : SYSIBM.SYSTABLESPACE CorrNm: A Index : SYSIBM.DSNDSX01 MCols : 2 New Access Path Analysis: Cost: (ms) 1 -(su) 4 (tm) +.46428 E+02 Diff: (ms) None -(su) 300% Incr PQbkNo: 0 QblkNo: 1 PlanNo: 1 MxOpSq: 0 TBTyp: TABLE Access: IXDATA TSLock: IS Prefet: QblkTy: SEL TabNo: 1 Table : SYSIBM.SYSTABLESPACE CorrNm: A Index : SYSIBM.DSNDSX01 MCols :-1 Please note the statement number change too where CA Plan Analyzer was able to map these
    39. 39. View Explain Statistics Report June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Object Statistics Report: ---------------- TABLEPART PARTNO: 0 ---------------------------- STATSTIME : 2007-02-14-15.27.27.450000 NEARINDREF : 257 FARINDREF: 273 PAGESAVE : 0 PERCACTIVE : 48 PERCDROP : 0 CARD : 76492 EXTENTS : 3 DSNUM : 1 PQTY : 4140 SECQTY : 4140 SPACE : 33120 TABLE SYSIBM.SYSTABLESPACE STATSTIME : 2007-02-14-15.27.27.450000 CARD : 1401 NPAGES : 1401 PCTROWCOMP: 0 AVGROWLEN : 190 PCTPAGES : 45 SPACE : 720 INDEX SYSIBM.DSNDSX01 STATSTIME: 2007-02-14-15.27.27.450000 CLUSTRATO: +.7480E+00 1STKEYCARD: 164 FULLKYCARD: 1401 CLUSTERNG: YES NLEAF : 15 NLVL : 2 SPACE : 240 -------------- INDEXPART PARTNO: 0 ---------------------------- STATSTIME: 2007-02-14-15.27.27.450000 FAROFFPOS: 513 NEAROFFPOS: 251 LEAFDIST : 340 LEAFFAR : 14 LEAFNEAR : 0 PQTY : 60 SECQTY : 60 SPACE : 240 CARD : 1401 EXTENTS : 1 DSNUM : 1 COLUMN NAME COLCARD : 552 COLTYPE : VARCHAR LENGTH : 24 STATSTIME: 2005-10-19-16.19.22.520206 NULLS : NO HIGH2KEY : !|.(... <HEX> 5444455 AF8D543 Another report generated is the Object Statistics Report, which does provide invaluable information when comparing Access Path changes between two Explain versions. In most cases, the cause for an Access Path change is due to changed SQL or changed information in the catalog used by the Optimizer
    40. 40. DB2 Explain Versioning <ul><li>Using the CA Plan Analyzer batch JCL step listed earlier, removes most if not all the guess work: </li></ul><ul><ul><ul><li>Old and new SQL statement listed </li></ul></ul></ul><ul><ul><ul><li>Old and new Access Path described </li></ul></ul></ul><ul><ul><ul><li>Old and new catalog information used by the Optimizer is saved for further analysis when needed </li></ul></ul></ul><ul><li>A quick and easy method to pinpoint WHEN and WHY performance changed. </li></ul><ul><ul><ul><li>Gives you invaluable information to “learn” too </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    41. 41. DB2 Explain Versioning (cont’d) <ul><li>Conclusion - CA Plan Analyzer Explain versioning provides: </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. <ul><li>A Proactive approach </li></ul><ul><ul><li>Verify SQL and performance changes ahead of program promotion </li></ul></ul><ul><ul><li>Eventually execute Explain ahead of Bind for critical applications </li></ul></ul><ul><ul><li>Perform corrective actions </li></ul></ul><ul><li>A Reactive approach </li></ul><ul><ul><li>When someone complains about performance </li></ul></ul><ul><ul><li>Quickly identify when program was bound </li></ul></ul><ul><ul><li>Analyze SQL text changes </li></ul></ul><ul><ul><li>Analyze Access Path Changes </li></ul></ul><ul><ul><li>Verify if catalog statistics have changed </li></ul></ul>
    42. 42. DB2 Explain Versioning <ul><li>However - this process might fall short, so here are some challenges to consider </li></ul><ul><li>What if Binds or Rebinds happen “outside” this process </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. To Rebind or Not To Rebind … . That is the QUESTION ! (cited from Roger Miller)
    43. 43. DB2 Explain Versioning <ul><li>BIND / REBIND with EXPLAIN(YES) </li></ul><ul><ul><li>DB2 will generate a NEW Access path !!!!! </li></ul></ul><ul><ul><li>Is this a good idea ? Maybe ! </li></ul></ul><ul><ul><li>What if the DB2 catalog statistics ISN’T optimal </li></ul></ul><ul><ul><ul><li>No RUNSTATS executed  statistics columns in the catalog have -1  Optimizer has NO clue about statistics for tables, indexes, columns </li></ul></ul></ul><ul><ul><li>Only method to evaluate Trigger Access Path </li></ul></ul><ul><li>These might happen outside the scope / process discussed on the previous slides – so unless these are caught in another job, you might be fooled !!! </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. warning
    44. 44. DB2 Explain Versioning <ul><li>Fallback to previous Access Path </li></ul><ul><ul><li>Has not been a very easy task in the past </li></ul></ul><ul><ul><li>DB2 9 APAR=PK52523 (PTF UK31993) changed the game (up to three copies of package access path) </li></ul></ul><ul><ul><li>REBIND PACKAGE(x) PLANMGMT(yyyyyyyy) </li></ul></ul><ul><ul><ul><li>OFF : The new package access path will become the active – any previous or original package access path remain untouched (basically what we have had for years) </li></ul></ul></ul><ul><ul><ul><li>BASIC : The previous copy is removed, the active copy becomes the PREVIOUS and the new becomes the ACTIVE </li></ul></ul></ul><ul><ul><ul><li>EXTENDED : The current active package becomes PREVIOUS and new package becomes ACTIVE – original stays (or previous becomes ORIGINAL if original doesn’t exist already) </li></ul></ul></ul><ul><ul><li>Also valid for REBIND TRIGGER PACKAGE </li></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    45. 45. DB2 Explain Versioning <ul><li>Fallback to previous Access Path </li></ul><ul><ul><li>REBIND PACKAGE(x) SWITCH(yyyyyyyy) </li></ul></ul><ul><ul><li>PREVIOUS : Flip-Flop ACTIVE and CURRENT access paths. The current active Package Access Path becomes the previous – and the current previous Package Access Path becomes the active </li></ul></ul><ul><ul><ul><li>A quick method to fallback to old Access Path </li></ul></ul></ul><ul><ul><li>ORIGINAL : Flip-Flop of the ORIGINAL and the current ACTIVE (newest) Package Access Path. </li></ul></ul><ul><ul><ul><li>What was the CURRENT becomes the PREVIOUS </li></ul></ul></ul><ul><ul><ul><li>The ORIGINAL is now the ACTIVE </li></ul></ul></ul><ul><ul><ul><ul><li>It still exists as ORIGINAL too </li></ul></ul></ul></ul><ul><ul><ul><li>The PREVIOUS is gone </li></ul></ul></ul><ul><ul><li>Wildcarding is supported to help rebinding multiple packages </li></ul></ul><ul><ul><ul><li>After DB2 upgrade </li></ul></ul></ul><ul><ul><ul><li>Runstats and/or REBIND “mis-executed” </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    46. 46. DB2 Access Path (SPT01) Versioning June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. REBIND PACKAGE(STEEN_COLL2.RQATL.(CAD115_2008-01-08-20.41.45)) SWITCH(PREVIOUS) ; DSNT217I !DA0G DSNTBRB2 REBIND SWITCH FOR PACKAGE =DA0GPTIB.STEEN_COLL2.RQATL.(CAD115_2008-01-08-20.41.45) FAILED BECAUSE THE PREVIOUS OR ORIGINAL COPY DOES NOT EXIST. DSNT233I !DA0G UNSUCCESSFUL REBIND FOR PACKAGE = DA0GPTIB.STEEN_COLL2.RQATL.(CAD115_2008-01-08-20.41.45) REBIND PACKAGE(STEEN_COLL.RQATL.(CAD115_2008-01-08-20.41.45)) PLANMGMT(EXTENDED) ; DSNT255I !DA0G DSNTBRB2 REBIND OPTIONS FOR PACKAGE = DA0GPTIB.STEEN_COLL.RQATL.(CAD115_2008-01-08-20.41.45) SQLERROR NOPACKAGE CURRENTDATA NO DEGREE 1 DYNAMICRULES DEFER REOPT NONE KEEPDYNAMIC NO IMMEDWRITE NO DBPROTOCOL DRDA OPTHINT ENCODING EBCDIC(05035) ROUNDING HALFEVEN PATH DSNT232I !DA0G SUCCESSFUL REBIND FOR PACKAGE = DA0GPTIB.STEEN_COLL.RQATL.(CAD115_2008-01-08-20.41.45) REBIND PACKAGE(STEEN_COLL.RQATL.(CAD115_2008-01-08-20.41.45)) SWITCH(PREVIOUS) ; DSNT232I !DA0G SUCCESSFUL REBIND FOR PACKAGE = DA0GPTIB.STEEN_COLL.RQATL.(CAD115_2008-01-08-20.41.45)
    47. 47. DB2 Explain Versioning <ul><li>Where does DB2 keep the new Access Path versions </li></ul><ul><ul><li>I found no documentation, so my “Sherlock Holmes” toolset (CA Log Analyzer) uncovered the following: </li></ul></ul><ul><ul><ul><li>Three REBINDs executed of one package using EXTENDED  resulted in 103 updates to SPTR </li></ul></ul></ul><ul><ul><ul><li>A REBIND with SWITCH(PREVIOUS)  resulted in 309 updates to SPTR </li></ul></ul></ul><ul><ul><ul><li>Seems like all this information is stored in SPTR (the table name for SPT – Skeleton Package table) </li></ul></ul></ul><ul><ul><li>Make sure your SPT01 has enough space to accommodate multiple Access Paths </li></ul></ul><ul><ul><li>FREE using PLNMGMTSCOPE(xxxxx) </li></ul></ul><ul><ul><ul><li>INACTIVE  original and previous removed </li></ul></ul></ul><ul><ul><ul><li>ALL  all packages removed (be careful since default) </li></ul></ul></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    48. 48. Summary <ul><li>Explain more important as ever </li></ul><ul><li>Influencing the Optimizer </li></ul><ul><li>Proactive performance approach </li></ul><ul><li>Reactive performance approach </li></ul><ul><li>Explain versioning </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.
    49. 49. Terms of This Presentation June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. This presentation was based on current information and resource allocations as of November 16, 2008 and is subject to change or withdrawal by CA at any time without notice. Notwithstanding anything in this presentation to the contrary, this presentation shall not serve to (i) affect the rights and/or obligations of CA or its licensees under any existing or future written license agreement or services agreement relating to any CA software product; or (ii) amend any product documentation or specifications for any CA software product. The development, release and timing of any features or functionality described in this presentation remain at CA’s sole discretion. Notwithstanding anything in this presentation to the contrary, upon the general availability of any future CA product release referenced in this presentation, CA will make such release available (i) for sale to new licensees of such product; and (ii) to existing licensees of such product on a when and if-available basis as part of CA maintenance and support, and in the form of a regularly scheduled major product release. Such releases may be made available to current licensees of such product who are current subscribers to CA maintenance and support on a when and if-available basis. In the event of a conflict between the terms of this paragraph and any other information contained in this presentation, the terms of this paragraph shall govern.
    50. 50. For Informational Purposes Only June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved. Certain information in this presentation may outline CA’s general product direction. All information in this presentation is for your informational purposes only and may not be incorporated into any contract. CA assumes no responsibility for the accuracy or completeness of the information. To the extent permitted by applicable law, CA provides this document “as is” without warranty of any kind, including without limitation, any implied warranties or merchantability, fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits, lost investment, business interruption, goodwill, or lost data, even if CA is expressly advised of the possibility of such damages.
    51. 51. Resources and Q&A <ul><li>Database Management White paper by Phillip Howard </li></ul><ul><ul><li>http://www.ca.com/us/products/collateral.aspx?cid=196889 </li></ul></ul><ul><li>Business Value of Intelligent Data Access by Susan Larsen http://www.ca.com/us/whitepapers/collateral.aspx?cid=201547 </li></ul><ul><ul><li>Access Path Flash Download </li></ul></ul><ul><ul><li>http://www.ca.com/us/demos/collateral.aspx?cid=185950 </li></ul></ul><ul><li>Questions? </li></ul>June 10th: How to predict DB2 Performance Changes Copyright © 2009 CA. All rights reserved.

    ×