May 20, 2008 • 01:30 p.m. – 02:30 p.m. Platform: DB2 for z/OS Marc Costa FedEx Freight System Session: B07 Urban Legend:  ...
Urban Legend <ul><li>Is it possible to upgrade to NFM in less than 90 days? </li></ul><ul><li>Timelines and upgrade paths ...
DB2 Timeline (GA and EOS) <ul><li>DB2 for OS/390 and z/OS Version 7 </li></ul><ul><ul><li>GA – March 30, 2001 EOS June 30,...
Training Timeline <ul><li>September 20 – 24 2004 – IBM DB2 Technical Conference Las Vegas, NV </li></ul><ul><li>May 22 – 2...
Upgrade Timeline <ul><li>August 12 th  2005 – Ordered V8 </li></ul><ul><li>August 29 th  2005 – SMP/E work completed </li>...
Horizontal Upgrade <ul><li>IBM recommended upgrade path </li></ul>Test QA Prod Prod QA Test CM NFM <ul><li>How long do you...
<ul><li>Maybe for those that think they are smarter than IBM </li></ul>Vertical Upgrade Test QA Prod Prod QA Test CM NFM <...
CCSID Conversion <ul><li>How do you know one is needed? </li></ul><ul><li>Get the 27 step conversion plan </li></ul><ul><l...
CCSID cont’d <ul><li>7 characters between 37 and 500 don’t match </li></ul><ul><li>CCSID 37 CCSID 500 </li></ul><ul><ul><l...
Short Overview of Upgrade Steps <ul><li>If CCSID conversion needed, complete before CM </li></ul><ul><li>CM – Compatibilit...
Reorg of Catalog and Directory <ul><li>Before starting the upgrade </li></ul><ul><ul><li>Going to happen in ENFM </li></ul...
Getting to CM <ul><li>DSN7100I  %DBS1 DSN7GCMD  </li></ul><ul><li>*** BEGIN DISPLAY OF GROUP(DSNSDBG0) GROUP LEVEL(810) MO...
ENFM – Convert to Unicode <ul><li>DSN7100I  %DBS1 DSN7GCMD  </li></ul><ul><li>*** BEGIN DISPLAY OF GROUP(DSNSDBG0) GROUP L...
NFM – Flip the switch <ul><li>DSN7100I  %DBS1 DSN7GCMD  </li></ul><ul><li>*** BEGIN DISPLAY OF GROUP(DSNSDBG0) GROUP LEVEL...
Project Plan <ul><li>Project template available from IBM </li></ul><ul><ul><li>Use as a starting point, but need to custom...
Other things to upgrade <ul><li>Hardware </li></ul><ul><ul><li>z9 Architecture </li></ul></ul><ul><li>Software </li></ul><...
To rebind or not to rebind? <ul><li>That isn’t even an option </li></ul><ul><ul><li>Real question is what % to rebind </li...
Fun times in V8 NFM <ul><li>No more reading Database Request Modules (DBRM’s) </li></ul><ul><li>Getting off of Opthints </...
DBRM (V7 and before) <ul><li>“ Readable” </li></ul>
DBRM V8 NFM <ul><li>Not so readable </li></ul>
Death of Opthints <ul><li>Prior to V8, many access paths using opthint </li></ul><ul><li>In V8, wanted to use optimizer/ut...
OLSE at the wrong time  <ul><li>Request to do OLSE during the week </li></ul><ul><ul><li>Down time for object was determin...
DISTSERV and 2 gig limit <ul><li>Distributed application </li></ul><ul><li>Bulk harvesting of data </li></ul><ul><li>Upwar...
Should I upgrade in less than 90 days?
Marc Costa <ul><li>FedEx Freight System </li></ul><ul><li>[email_address] </li></ul>Session B07 Session Title -  Urban Leg...
Upcoming SlideShare
Loading in …5
×

Upgrade from DB2 for z/OS V7 to DB2 for z/OS V8 (NFM) In Less ...

482 views
411 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
482
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • The current EOS (End of Support) date for DB2 V7 is June 30th, 2008. If you have not upgraded to V8, you have very little time left before V7 is no longer supported. Do you like running on unsupported code? While FedEx Freight didn’t wait until the last minute, we did upgrade from V7 to V8 in less than 90 days. This presentation will go over the time line for the upgrade, issues during the upgrade (including CCSID conversion) and some interesting things we encountered after the upgrade. Biography: Marc Costa BSBA Degree, Colorado State University, Fort Collins, CO December 1993. Accepted a Programmer position with Mutual of Omaha in 1994. Programmed against DB2 using Cobol and Visual Basic. Accepted a position as an application DBA, September 1998. Joined FedEx Freight System as a Sr. DBA in January 2003. Working on a DBA team supporting all aspects of DB2, including upgrades (V7, V8), application design, SQL tuning and system tuning. IBM Certified DBA V8.1 DB2 UDB for z/OS.
  • Is it possible to upgrade to NFM in less than 90 days? What is possible and what is recommended may not always be the same. There were some strong reasons (and timelines) pushing the upgrade plan. Columns on 250+ tables needed to be expanded tied to a corporate directive. The online schema change in V8 allowed for this with a much smaller outage window. Had we stayed on V7 and done the changes via unload, drop table, reload and rebind, the outage(s) would have been much longer.
  • The System z product lifecycle dates can be found at http://www-306.ibm.com/software/support/systemsz/lifecycle/ DB2 V7 was the version to cross the OS/390 to z/OS operating system. OS/390 2.10 (last release of OS/390) went out of service on Sep 30, 2004. Anyone still on OS/390? It is a requirement to be on DB2 V7 to migrate to DB2 V8.
  • IBM DB2 Tech Conference in 2004 was the first real look at V8. We had completed the migration to V7 in December 2003. In 2004, we had not identified any business reasons for migrating to V8. In early 2005 a business reason arose that could be handled with V8. V8 was still very new and the adoption rate and stories from the users made us leery. By 2 nd quarter 2005 the business need was gaining momentum and our confidence in V8 was increasing. 3 rd quarter of 2005 a decision was made to go forward with the upgrade to V8.
  • At the same time that DB2 was being upgrade, z/OS was also being upgraded from 1.4 to 1.6. We couldn’t start some of the upgrade activities when we wanted (on a sandbox system) because none of the lpar’s had been upgraded to 1.6. If we had started the upgrade when we wanted, we would have upgraded the first DB2 subsystem on z/OS 1.4 and the remaining DB2 subsystems on z/OS 1.6. We wanted to be consistent in the process, so we had to wait to start the upgrade process until the first lpar was at 1.6.
  • How long do you want to stay in CM mode for each environment? Do you want to go over “critical” business events – end of month, end of quarter maybe even end of year in CM mode? Depending on how long you plan to stay in each mode, this might be the desired upgrade path. What is the length of time that it takes to roll maintenance to the current version of DB2 across the environment? If this is a long duration (months or quarters) then the same philosophy should be applied for the migration. If it takes a quarter to roll maintenance in V7, why would you upgrade to V8 in less than that time? One drawback is the length of time that it could take to complete the upgrade. From the time of ordering version 8, most shops have 1 year to complete the upgrade before being charged for 2 versions of DB2 (V7 and V8). Depending on how long you want to spend in each environment, and the number of environments to upgrade, the 1 year restriction can be a hindrance.
  • One serious drawback to this method is that if you hit an issue in an environment, you don’t have another environment to go to for testing fixes. All of the environments are at different levels so testing fixes (in-house or vendor) is not an apple to apple comparison. How do you know if you have it fixed for the environment that has the problem? Another drawback is if you have frequent code releases to production and production is not at the same level as QA (or test if code can be moved from test to production). A benefit to this upgrade path is the duration in each phase is kept to a minimum. If planned correctly, critical business functions (month end/quarter end/year end) can be run while in CM mode. If the business functions while in CM during these events, then hopefully no issues in NFM will be found.
  • This 60 minute presentation contains 2 slides on this topic. Christopher Crone from IBM spent 2 - 75 minute sessions at the 2005 Tech conference on this topic. Other than the upgrade of DB2, the CCSID conversion was the second highest consumer of time for the project. We didn’t have a large conversion either (48 tables in test, 9 in QA and 141 in production) with the largest table being 55 million rows. There are multiple queries to run to determine if a CCSID conversion is necessary (these are in member DSNTIJPM in SDSNSAMP dataset). When we first ran these queries, the results pointed to a much larger conversion. We used the locate function against all the tables that the queries initially flagged as needing conversion. Only tables that had any of the 7 characters needed the full conversion plan (which includes an unload and load to do a data conversion). The other tables that did not have that data type in the data went through a modified conversion plan (just the CCSID was changed, but not the data).
  • Most of these characters are not common. If you have a CCSID mismatch you are going to have to do a CCSID conversion. You can run a query against the tables that have the “losing” CCSID using the LOCATE function to see if you have any of these characters. SELECT columns FROM table1 WHERE LOCATE(X&apos;BA&apos;,column1) &lt;&gt; 0 OR LOCATE(X&apos;BB&apos;, column1) &lt;&gt; 0 OR LOCATE(X&apos;B0&apos;, column1) &lt;&gt; 0 OR LOCATE(X&apos;4A&apos;, column1) &lt;&gt; 0 OR LOCATE(X&apos;4F&apos;, column1) &lt;&gt; 0 OR LOCATE(X&apos;5A&apos;, column1) &lt;&gt; 0 OR LOCATE(X&apos;5F&apos;, column1) &lt;&gt; 0 WITH UR ;
  • If you need to do a CCSID conversion, it has to be completed before going to CM. You could do the CCSID conversion months/years before doing the upgrade to V8. Do you reorg the catalog and directory on a regular basis now? Doing this before ENFM will speed up the ENFM job. Also, doing clean up of obsolete packages and plans so that the catalog and directory tables tied to these objects is “smaller” will improve performance of ENFM. As long as NEWFUN=NO in DSNHDECM, compiled code dependant on DSNHDECP will not be able to use new functions, even if the system is in new function mode. This is one way to migrate to NFM but not allow code to start using new functions until you are ready. Dynamic SQL will be able to use new functions once the DSNTIJNF has been run.
  • Do you reorg your catalog and directory on a regular basis? For some shops, going to V8 might be the first time the catalog and directory have been reorganized. What is the rate of change in your shop? If it is very small, maybe reorganizing the catalog and directory is not needed. If the rate of change is average or high, it is a good idea to reorganize the catalog and directory. The catalog and directory was reorganized while still on V7 hoping that this would reduce the time required for ENFM job. There is no easy way to tell if this did or did not help, but it was determined that it couldn’t hurt. In both CM and NFM, all plans and packages were rebound. Prior to the reorg of the catalog and directory, the rebind took 2 and a half hours. In both CM and NFM, the rebinds took less than one hour 45 minutes. Some IBM’ers believe it was the reorg of the catalog and directory that contributed to the reduced time to do rebinds.
  • Now is the time to test the fall back procedures as this is the only V8 mode that you can fall back to V7 easily. Falling back to V7 after starting ENFM, completing ENFM or NFM is a major undertaking.
  • There is one job that is run for ENFM. It can be restarted in the event of a failure. My advice would be to run this during a quiet time (particularly avoid a time when running user data reorgs). After the job completes successfully, all the table spaces will have the YES next to them in the Enabled New Function column. Do not submit this job unless you are sure you do not want to go back to V7. It may be possible to get back to V7, but at what cost to the business (and you)?
  • After running the last job, the Mode will change to N. Also, after doing a group wide shut down, those in data sharing will be converted to locking protocol 2. At IDUG 2007 locking protocol 2 was being discussed in some presentations. Later on I did a display group on all of the DB2 subsystems. All of the systems except production were at locking protocol 2. Production was still at locking protocol 1. We had done multiple IPL’s since going to NFM. We scheduled another group wide shut down. Much to our surprise, after this shutdown we were still on locking protocol 1. Some analysis was then done and a thread was found that had connected from one DB2 system to another. This thread had been in this status for months (maybe even years) and was indoubt. This thread was preventing a clean shut down and therefore preventing the switch to locking protocol 2. A –reset indoubt command was issued before the next planned group wide shut down. When DB2 started back up, it was at locking protocol 2.
  • Where to get project plan template? Contact your local DB2 specialist (this person works for IBM and if you don’t know who this person is, find out from your sales rep or other IBM contact).
  • z/OS 1.4 went out of support on 3/31/2007. This was the minimum version needed for V8. Hopefully you are on z/OS 1.6 or later as some of the features required 1.6. z/OS 1.6 goes out of support on 9/30/2008. Prior to V8 there were 3 explain tables visible – PLAN_TABLE DSN_FUNCTION_TABLE DSN_STATEMNT_TABLE After going to V8, 10 more are visible – DSN_STRUCT_TABLE DSN_PREDICAT_TABLE DSN_FILTER_TABLE DSN_DETCOST_TABLE DSN_PGROUP_TABLE DSN_PTASK_TABLE DSN_PGRANGE_TABLE DSN_SORTKEY_TABLE DSN_SORT_TABLE DSN_VIEWREF_TABLE Also, DSN_FUNCTION_TABLE no longer fits on a 4K page. The plan table and DSN tables support aliases in version 8, allowing collapsing and easier administration of these tables. One resource was dedicated to upgrading DB2 Connect, QMF for Windows and Visual Explain as these are all tied to the PC and required resources from other teams to get deployed. Another was doing QMF (host version).
  • In each release of DB2, there are changes to the optimizer. Most are very good, but occasionally there will be one or two things that get regressed. I don’t know why everyone is always so hung up on those that get regressed. Look at the total number of statements that are in your shop. What percentage actually have negative impact? Understand that some statements in each shop are “critical” and can not be regressed. These should be documented and verified after doing rebinds. If these critical statements are regressed and tuning options have been exhausted, then use a hint to get back to the previous access path (you do have the previous access path, right?). This is a good time to use optimizer hints. In each mode (V7, V8 CM and V8 NFM) plan tables (and DSN* tables) were created for that stage and the data was dumped into these tables. Then as we moved to the next phase, we could compare the access path between the current phase and the previous. If your shop is package based, you can side bind all packages to a different collection ID. You could rebind the plans, putting the side collection first in the PKLIST, followed by the existing collection ids. If a particular package is causing access path grief, it can be freed from the side collection, and it will go back to the access path before the rebind. This would then allow time to research the issue and when resolved, bind the package into the side collection again. Once all packages in a side collection have acceptable performance, rebind the packages in the normal collection and drop the side collection packages.
  • Once on V8 NFM, there were a couple of interesting challenges that were encountered. One of them was tied to us getting off of opthints (prior to V8 we had thousands of plans and packages using opthints – now it is 9 plans and 7 packages). Another fun evening was tied to doing an online schema change in the middle of the week. Yet another was tied to a new distributed application that was missing one important statement.
  • The DBRM’s in version 7 and prior were created using encoding scheme defined in DSNHDECP. In most cases this was tied to the same encoding scheme of the host and was in a language readable to the people that worked on that system. For those of us in the US, that most likely meant a CCSID that represents the English language. While reading DBRM’s is not something most IT people do on a daily basis, it is something that can be done prior to V8.
  • In NFM, DBRM’s are now stored in Unicode. This makes them a little less readable (if not completely). Turning hex on doesn’t help much either. The data in the catalog tables is also stored in Unicode (that is what the ENFM job did – convert the catalog and directory to Unicode). Queries that pulled the statements out of SYSSTMT and SYSPACKSTMT will not have the same results before. The data will need to be casted back to a CCSID that is “readable” to you. There are multiple examples in both the SQL Reference and the DB2-L listserv. Visual Explain will translate the statement back to a readable format. ISV tools will also do the same thing. Here is a query that will translate the Unicode rows in SYSPACKSTMT (or SYSSTMT) to CCSID 37 (one of the US English values) – SELECT NAME, STMTNOI, SECTNOI, QUERYNO, SEQNO, CAST(CAST(STMT AS VARCHAR(3500) CCSID 1208) AS VARCHAR(3500) CCSID EBCDIC) FROM SYSIBM.SYSPACKSTMT WHERE COLLID=&apos;DSNUTILS&apos; AND NOT (STMTNO=0 AND SEQNO=0 AND SECTNO=0) WITH UR SELECT NAME, PLNAME, STMTNOI, SECTNOI, QUERYNO, SEQNO, CAST(CAST(TEXT AS VARCHAR(3500) CCSID 1208) AS VARCHAR(3500) CCSID EBCDIC) FROM SYSIBM.SYSSTMT WHERE PLNAME = ‘plan name&apos; WITH UR
  • Just after going to V7, someone thought it would be a good idea to OPTHINT all of the plans and packages. When work was done that would cause massive rebinds, all plans and packages were rebound using hinted access path. The downside to this is that all maintenance on V7 that modified the optimizer would not be used at bind/rebind time. All of the access paths were determined from the opthint and not via the optimizer. With all the changes in V8, including data type mismatch, all plans and packages were rebound with OPTHINT(‘ ‘) to get off of the opthint. In NFM, one program had an issue tied to the rebind using OPTHINT(‘ ‘). In this case, it was tied to reading an index backwards to fulfill the order by clause. During execution, it did not read the index backwards (read it forward) and gave incorrect results. ETR with IBM was opened and an opportunity was discovered and fixed. Prior to version 8, a stand alone program called DSTATS could be downloaded from IBM and run to gather distribution statistics on any column or group of columns. This functionality is now in the RUNSTATS utility in V8. Here is an example of column group statistics generated from the stats advisor in Visual Explain – RUNSTATS TABLESPACE AFWFMSYS.AFTSSHHI TABLE(AFW.SHIPMENT_HIST) SAMPLE 5 COLUMN(VOID_FLG,ORIGIN_TERMINAL_ID,SUFFIX_NUMBER) COLGROUP(VOID_FLG) FREQVAL COUNT 1 COLGROUP(ORIGIN_TERMINAL_ID,VOID_FLG) COLGROUP(PRO_NUMBER,SUFFIX_NUMBER) SORTDEVT SYSDA SORTNUM 4 INDEX(AFW.AFIXSHHI, AFW.AFX5SHHI, AFW.AFX3SHHI KEYCARD, AFW.AFX2SHHI KEYCARD, AFW.AFX6SHHI KEYCARD, AFW.AFX4SHHI KEYCARD) SHRLEVEL CHANGE REPORT YES
  • Structure changes are usually done once a week during down time. A change was not requested timely and needed to happen before the next down window to meet an install date. It was determined that the object that needed to be changed was not in use at a certain time of the evening. The normal process for OLSE was executed. Change and reorg were successful. When the rebinds were started, it happened to be at the same time that a large package install was occurring on the second member of data sharing group. DBA saw the deadlocks and cancelled the rebind thread tied to OLSE change. The thread did not cancel nicely. Batch jobs started to fail, but the threads did not detach from DB2 (we would see in the MSTR the abnormal termination, but a display thread would show the thread tied to the abnormal termination still in DB2). From the time of the cancel of the rebind to when we cancelled IRLM was about 3 hours. When we started DB2 back up, the threads that had abnormally terminated had to be backed out, so the start up of DB2 took much longer than a normal start up. The standard practice that we use for online scheme changes – 1. If the table has Change Data Capture turned on, put the table in read only and alter CDC off. 2. Do OLSE alter 3. Online reorg of the tablespace (so that there aren’t multiple page versions) 4. Rebind all dependant packages and plans 5. Turn CDC back on and put table in read write If a table has an olse executed against it and is no longer at version 0, alters from previous versions (like adding columns) will put the tablespace into AREO* status.
  • A new application was coded in Java using SQLJ. At the time, SQLJ was not used much at this shop. The lead developer created a process that had a “queen/worker bee” scenario where the queen could start up to 20 worker bees to do work. The process was also set up so that 10 queens could work in parallel, so up to 200 worker bees could be working at one time. None of the worker bees committed the work (even though the worker bees were only reading). After about an hour and a half, process started slowing down dramatically. It was determined that the memory usage in DIST was creeping up the entire time the process was running. When it reached about 1.6 gig used, DIST crashed, taking all of DB2 down with it. The developer added commits to the worker bees, and the application ran smooth after that.
  • So, if you are still wondering if you should attempt an upgrade in less than 90 days, maybe this flowchart will help you decide. While this flowchart was meant to be entertaining, there are a couple of serious underlying themes. The upgrade will not only impact you and the team doing the upgrade. It will extend outside of work. The shorter the timeframe for the upgrade the greater the impact on the people outside of work.
  • Upgrade from DB2 for z/OS V7 to DB2 for z/OS V8 (NFM) In Less ...

    1. 1. May 20, 2008 • 01:30 p.m. – 02:30 p.m. Platform: DB2 for z/OS Marc Costa FedEx Freight System Session: B07 Urban Legend: Upgrade from DB2 for z/OS V7 to DB2 for z/OS V8 (NFM) In Less Than 90 days
    2. 2. Urban Legend <ul><li>Is it possible to upgrade to NFM in less than 90 days? </li></ul><ul><li>Timelines and upgrade paths </li></ul><ul><li>Upgrades to other components (not just DB2) </li></ul><ul><li>To rebind or not to rebind? </li></ul><ul><li>Fun days (and nights) after getting to NFM </li></ul>
    3. 3. DB2 Timeline (GA and EOS) <ul><li>DB2 for OS/390 and z/OS Version 7 </li></ul><ul><ul><li>GA – March 30, 2001 EOS June 30, 2008 </li></ul></ul><ul><li>DB2 for z/OS Version 8 </li></ul><ul><ul><li>GA – March 26, 2004 EOS Not established </li></ul></ul><ul><li>DB2 for z/OS Version 9 </li></ul><ul><ul><li>GA – March 16, 2007 EOS Not established </li></ul></ul><ul><li>All versions prior to V7 are out of support </li></ul><ul><ul><li>Do you like running on unsupported code? </li></ul></ul><ul><ul><li>What about your business partners? </li></ul></ul><ul><li>http://www-306.ibm.com/software/data/support/lifecycle/ </li></ul>
    4. 4. Training Timeline <ul><li>September 20 – 24 2004 – IBM DB2 Technical Conference Las Vegas, NV </li></ul><ul><li>May 22 – 26 2005 – IDUG Denver, CO </li></ul><ul><li>June 15 th 2005 – CDUG V8 upgrade workshop training </li></ul><ul><li>September 12 – 16 2005 – IBM DB2 Technical Conference Orlando, FL </li></ul>
    5. 5. Upgrade Timeline <ul><li>August 12 th 2005 – Ordered V8 </li></ul><ul><li>August 29 th 2005 – SMP/E work completed </li></ul><ul><li>September 2005 – Additional RSU’s applied </li></ul><ul><li>October 5 th 2005 – Sandbox DB2 upgraded to Compatibility Mode (CM) </li></ul><ul><li>November 24 th 2005 – Production to CM </li></ul><ul><li>December 17 th 2005 – Production to New Function Mode (NFM) </li></ul>Total Time from Order to NFM – 127 Days Total Time from first member CM to last member NFM – 72 days
    6. 6. Horizontal Upgrade <ul><li>IBM recommended upgrade path </li></ul>Test QA Prod Prod QA Test CM NFM <ul><li>How long do you spend in each mode in each environment? </li></ul><ul><li>Benefits/Drawbacks </li></ul>
    7. 7. <ul><li>Maybe for those that think they are smarter than IBM </li></ul>Vertical Upgrade Test QA Prod Prod QA Test CM NFM <ul><li>Complete (through NFM) one environment before moving to next </li></ul><ul><li>Benefits/Drawbacks </li></ul>
    8. 8. CCSID Conversion <ul><li>How do you know one is needed? </li></ul><ul><li>Get the 27 step conversion plan </li></ul><ul><li>Build into project plan the time to do conversion </li></ul><ul><ul><li>All environments </li></ul></ul><ul><li>Why do we need to do a conversion? </li></ul><ul><li>CCSID and Codepage – Do your homework </li></ul>
    9. 9. CCSID cont’d <ul><li>7 characters between 37 and 500 don’t match </li></ul><ul><li>CCSID 37 CCSID 500 </li></ul><ul><ul><li>x’BA’ = [ x’5B’ = ¬ </li></ul></ul><ul><ul><li>x’BB’ = ] x’BB’ = | </li></ul></ul><ul><ul><li>x’B0’ = ^ x’B0’ = ¢ </li></ul></ul><ul><ul><li>x’4A’ = ¢ x’4A’ = [ </li></ul></ul><ul><ul><li>x’4F’ = | x’4F’ = ! </li></ul></ul><ul><ul><li>x’5A’ = ! x’5A’ = ] </li></ul></ul><ul><ul><li>x’5F’ = ¬ x’5F’ = ^ </li></ul></ul>
    10. 10. Short Overview of Upgrade Steps <ul><li>If CCSID conversion needed, complete before CM </li></ul><ul><li>CM – Compatibility Mode </li></ul><ul><ul><li>Can your shop run V8 Code? </li></ul></ul><ul><ul><li>Fallback to V7 if needed </li></ul></ul><ul><li>ENFM (Enable New Function Mode) </li></ul><ul><ul><li>Catalog and Directory Reorg and conversion to Unicode </li></ul></ul><ul><li>NFM (New Function Mode) </li></ul><ul><ul><li>Flip the switch (no easy way back to CM or V7) </li></ul></ul><ul><ul><li>Compiler option after last system upgraded? </li></ul></ul>
    11. 11. Reorg of Catalog and Directory <ul><li>Before starting the upgrade </li></ul><ul><ul><li>Going to happen in ENFM </li></ul></ul><ul><ul><li>When was the last time it was done? </li></ul></ul><ul><ul><li>Are you rebinding all plans/packages? </li></ul></ul><ul><ul><ul><li>Help in rebind time </li></ul></ul></ul><ul><li>After upgrade, continue doing? </li></ul><ul><ul><li>Regular basis </li></ul></ul><ul><ul><li>Need based on rate of change </li></ul></ul>
    12. 12. Getting to CM <ul><li>DSN7100I %DBS1 DSN7GCMD </li></ul><ul><li>*** BEGIN DISPLAY OF GROUP(DSNSDBG0) GROUP LEVEL(810) MODE(C) </li></ul><ul><li>PROTOCOL LEVEL(1) GROUP ATTACH NAME(DSNS) </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>DB2 DB2 SYSTEM IRLM </li></ul><ul><li>MEMBER ID SUBSYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC </li></ul><ul><li>-------- --- ---- -------- -------- --- -------- ---- -------- </li></ul><ul><li>DBS1 1 DBS1 %DBS1 ACTIVE 810 AFW4 DIS1 DBS1IRLM </li></ul><ul><li>DBS2 2 DBS2 %DBS2 QUIESCED 710 AFW4 DIS2 DBS2IRLM </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>DB2 PARALLEL PARALLEL </li></ul><ul><li>MEMBER COORDINATOR ASSISTANT </li></ul><ul><li>-------- ----------- --------- </li></ul><ul><li>DBS1 YES YES </li></ul><ul><li>DBS2 **** **** </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>SCA STRUCTURE SIZE: 16640 KB, STATUS= AC, SCA IN USE: < 1 % </li></ul><ul><li>LOCK1 STRUCTURE SIZE: 8192 KB </li></ul><ul><li>NUMBER LOCK ENTRIES: 2097152 </li></ul><ul><li>NUMBER LIST ENTRIES: 16717, LIST ENTRIES IN USE: 0 </li></ul><ul><li>*** END DISPLAY OF GROUP(DSNSDBG0) </li></ul><ul><li>DSN9022I %DBS1 DSN7GCMD 'DISPLAY GROUP ' NORMAL COMPLETION </li></ul><ul><li>*** </li></ul>
    13. 13. ENFM – Convert to Unicode <ul><li>DSN7100I %DBS1 DSN7GCMD </li></ul><ul><li>*** BEGIN DISPLAY OF GROUP(DSNSDBG0) GROUP LEVEL(810) MODE(E) </li></ul><ul><li>PROTOCOL LEVEL(1) GROUP ATTACH NAME(DSNS) </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>DB2 DB2 SYSTEM IRLM </li></ul><ul><li>MEMBER ID SUBSYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC </li></ul><ul><li>-------- --- ---- -------- -------- --- -------- ---- -------- </li></ul><ul><li>DBS1 1 DBS1 %DBS1 ACTIVE 810 AFW3 DIS1 DBS1IRLM </li></ul><ul><li>DBS2 2 DBS2 %DBS2 ACTIVE 810 AFW3 DIS2 DBS2IRLM </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>DB2 PARALLEL PARALLEL </li></ul><ul><li>MEMBER COORDINATOR ASSISTANT </li></ul><ul><li>-------- ----------- --------- </li></ul><ul><li>DBS1 YES YES </li></ul><ul><li>DBS2 NO YES </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>TABLE ENABLED </li></ul><ul><li>SPACE NEW FUNCTION </li></ul><ul><li>-------- ------------ </li></ul><ul><li>SYSVIEWS YES </li></ul><ul><li>SYSDBASE YES </li></ul><ul><li>SYSDBAUT YES </li></ul><ul><li>SYSDDF YES </li></ul><ul><li>SYSGPAUT YES </li></ul><ul><li>SYSGROUP YES </li></ul><ul><li>SYSGRTNS YES </li></ul><ul><li>SYSHIST YES </li></ul><ul><li>SYSJAVA NO </li></ul><ul><li>--------- </li></ul>
    14. 14. NFM – Flip the switch <ul><li>DSN7100I %DBS1 DSN7GCMD </li></ul><ul><li>*** BEGIN DISPLAY OF GROUP(DSNSDBG0) GROUP LEVEL(810) MODE(N) </li></ul><ul><li>PROTOCOL LEVEL(2) GROUP ATTACH NAME(DSNS) </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>DB2 DB2 SYSTEM IRLM </li></ul><ul><li>MEMBER ID SUBSYS CMDPREF STATUS LVL NAME SUBSYS IRLMPROC </li></ul><ul><li>-------- --- ---- -------- -------- --- -------- ---- -------- </li></ul><ul><li>DBS1 1 DBS1 %DBS1 ACTIVE 810 AFW3 DIS1 DBS1IRLM </li></ul><ul><li>DBS2 2 DBS2 %DBS2 ACTIVE 810 AFW3 DIS2 DBS2IRLM </li></ul><ul><li>-------------------------------------------------------------------- </li></ul><ul><li>SCA STRUCTURE SIZE: 16384 KB, STATUS= AC, SCA IN USE: 1 % </li></ul><ul><li>LOCK1 STRUCTURE SIZE: 8192 KB </li></ul><ul><li>NUMBER LOCK ENTRIES: 2097152 </li></ul><ul><li>NUMBER LIST ENTRIES: 14938, LIST ENTRIES IN USE: 3426 </li></ul><ul><li>*** END DISPLAY OF GROUP(DSNSDBG0) </li></ul>
    15. 15. Project Plan <ul><li>Project template available from IBM </li></ul><ul><ul><li>Use as a starting point, but need to customize </li></ul></ul><ul><li>Factor in burn time for each mode by environment </li></ul><ul><li>Build “fluff” time to resolve issues that might arise </li></ul><ul><ul><li>Catch in test/QA and not production </li></ul></ul><ul><li>Open ETR’s with IBM in advance (recommended) </li></ul><ul><ul><li>CCSID </li></ul></ul><ul><ul><li>General Upgrade </li></ul></ul><ul><ul><li>Site specific “issues” </li></ul></ul>
    16. 16. Other things to upgrade <ul><li>Hardware </li></ul><ul><ul><li>z9 Architecture </li></ul></ul><ul><li>Software </li></ul><ul><ul><li>z/OS – minimum of 1.4 </li></ul></ul><ul><ul><li>QMF </li></ul></ul><ul><ul><ul><li>Also have CM and NFM phases </li></ul></ul></ul><ul><ul><li>ISV’s </li></ul></ul><ul><ul><ul><li>Probably not as much of an issue now, but toleration/exploitation of new features </li></ul></ul></ul><ul><ul><li>DB2 Connect or equivalent </li></ul></ul><ul><ul><li>Visual Explain (plan/DSN tables) </li></ul></ul>Alias support
    17. 17. To rebind or not to rebind? <ul><li>That isn’t even an option </li></ul><ul><ul><li>Real question is what % to rebind </li></ul></ul><ul><ul><ul><li>In CM – top 10% to 20% - maybe all </li></ul></ul></ul><ul><ul><ul><ul><li>~95% of optimizer changes in CM </li></ul></ul></ul></ul><ul><ul><ul><li>In NFM – all or what was not done in CM </li></ul></ul></ul><ul><ul><li>Tuning after rebind </li></ul></ul><ul><ul><ul><li>Tuning options </li></ul></ul></ul><ul><ul><ul><ul><li>Stats Advisor in Visual Explain </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Reorg </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Alter clustering index/add columns to index (On-Line Schema Evolution - OLSE) </li></ul></ul></ul></ul><ul><ul><ul><li>Use opthints only when all other tuning options exhausted – then open ETR </li></ul></ul></ul>Colgroup Stats in V8
    18. 18. Fun times in V8 NFM <ul><li>No more reading Database Request Modules (DBRM’s) </li></ul><ul><li>Getting off of Opthints </li></ul><ul><li>Online Schema Evolution </li></ul><ul><ul><li>Main driver to go to V8 </li></ul></ul><ul><ul><li>Define process, including Data Capture Changes </li></ul></ul><ul><ul><li>Rebind </li></ul></ul><ul><ul><li>Ideally do in “quieter” time or down window </li></ul></ul><ul><li>DISTSERV and 2 gig limit </li></ul><ul><ul><li>Commit is not over-rated </li></ul></ul>
    19. 19. DBRM (V7 and before) <ul><li>“ Readable” </li></ul>
    20. 20. DBRM V8 NFM <ul><li>Not so readable </li></ul>
    21. 21. Death of Opthints <ul><li>Prior to V8, many access paths using opthint </li></ul><ul><li>In V8, wanted to use optimizer/utility enhancements </li></ul><ul><ul><li>Data type mismatch </li></ul></ul><ul><ul><li>DSTATS in V7 and before now built in </li></ul></ul><ul><li>Rebound plans and packages with OPTHINT(‘ ‘) </li></ul><ul><li>One program started giving incorrect output </li></ul><ul><ul><li>Tied to backwards index scan and opthint </li></ul></ul><ul><li>Get over fear of rebind </li></ul>
    22. 22. OLSE at the wrong time <ul><li>Request to do OLSE during the week </li></ul><ul><ul><li>Down time for object was determined </li></ul></ul><ul><ul><li>Process executed </li></ul></ul><ul><ul><li>Rebinds for OLSE object collided with Bind tied to a scheduled move </li></ul></ul><ul><ul><ul><li>Rebind job tied to OLSE was cancelled (hard) </li></ul></ul></ul><ul><ul><ul><li>Entire system “slowly” started to lock up </li></ul></ul></ul><ul><ul><ul><li>Sev 1 ETR opened with IBM </li></ul></ul></ul><ul><ul><ul><li>Cancelled IRLM (per IBM recommendation) </li></ul></ul></ul><ul><ul><li>Restart “longer” than normal </li></ul></ul>
    23. 23. DISTSERV and 2 gig limit <ul><li>Distributed application </li></ul><ul><li>Bulk harvesting of data </li></ul><ul><li>Upwards of 200 connections managed by application </li></ul><ul><li>0 commits </li></ul><ul><li>DIST address space memory increased to 1.6 gig </li></ul><ul><li>DIST address space crashed taking DB2 with it </li></ul><ul><li>Commits added (even read only need commit) </li></ul><ul><li>No issues </li></ul>
    24. 24. Should I upgrade in less than 90 days?
    25. 25. Marc Costa <ul><li>FedEx Freight System </li></ul><ul><li>[email_address] </li></ul>Session B07 Session Title - Urban Legend: Upgrade from DB2 for z/OS V7 to DB2 for z/OS V8 (NFM) In Less Than 90 days

    ×