Smoothing the DB2 version migration path!

1. Smoothing the DB2 version migration path! Presenter’s Name Presenter’s Title

2. Migrating to DB2 v10? Do you want to avoid surprises and delays during and after the upgrade process? DB2 subsystem clones offer multiple levels of testing environments These clones can be created with minimum skilled resources, minimum time and no interruption to your production systems. Creating exact copies of production quickly for high quality testing reduces the risk of impacting critical applications during the migration process.

3. Agenda What is lurking in production? (and other environments) Problems and concerns Test environments needed for success Smoothing the migration path Test environments created by VCR Database storage integration Cloning overview Cloning terminology Clone DB2 systems Step by Step test environment creation

4. What’s lurking in production? You are migrating to a new version of DB2!

5. What’s lurking in production? But, what is lurking in your production environment?

6. What’s lurking in production? What is waiting to be uncovered by the new software?

7. What’s lurking in production? Development environments may be even more complicated Your environment is unique – • How do those new features really work in YOUR production environment? • How do those WAD elements mesh with YOUR production environment? • Are there bugs that can only surface in YOUR production environment? • Are there issues that can only manifest with the combinations of data and data volumes in YOUR production environment? What are the unexpected events for which you cannot test because they cannot be ANTICIPATED with your current knowledge? • Is there legacy code using undocumented features that no longer exist? • Is there Assembler code using addresses that are now used by DB2? • Is there a clever SQL technique that no longer works? • Is there code that was never invoked because the data volumes never reached the levels and throughput possible with the new DB2? • Something else?

8. What’s lurking in development? • Development environments • Critical applications may be in test – with new features – DB2 VNEXT may impact • Performance testing can be impacted by new versions of DB2 • Optimizer changes, etc • Multiple copies of the same application objects and data – Make more complicated environment to manage • Multiple versions of the same application • New features of an application that have not quite made it into production

9. What’s lurking in production? How do you find out before it bites you? • Upgrading to a new DB2 version is a high impact effort. • Any issue could be visible system wide or company wide • Sandbox environments are used to initially test DB2 version release. However, software is rarely kept in sync with production. • This is due to resources issues of time, money, space, manpower, and availability of required skills. • Usually “bare bones” and not reflecting production • There is only one Sandbox but many production DB2 configurations. • It is difficult to measure the impact or savings of implementing new DB2 features without testing in a production-like environment.

10. What’s lurking in production? A clone of your production DB2 can uncover what’s hidden!

11. Smoothing the migration path Cloning DB2 is not a new concept • There are 2 basic traditional methods • The first method – Resource intensive: • Creates a new DB2 system (the clone) • Creates the objects from a source DB2 on the new DB2 via DDL • Unloads the tables of the source DB2 • Loads the table rows of the source DB2 onto the tables of the clone • The second method – Requires an isolated LPAR: • Dump the data sets of a source DB2 to tape or some movable media • On an isolated LPAR restore the data sets of the source DB2 • Start the clone DB2 • A third and non-traditional method uses cloning automation and makes the process - • Safer • Faster • Non resource intensive • Can clone on the same or on a shared LPAR • Uses storage technology which you already own

12. Smoothing the migration path Migration with a DB2 subsystem clone • Create the DB2 subsystem Clone. There is cloning automation which can do this in under an hour • Migrate the clone to the new version of DB2 • Execute a parallel set of production jobs on the Clone • If any issues are uncovered, correct them at leisure during business hours, with no fear of an emergency back off at some early morning hour • Apply any necessary patches and migrate the production DB2 with confidence!

13. How does it clone so fast?Database and Storage Integration Mainframe Database Systems Application and Database Management Domain • Organizational Integration • New Backup Methods • New Recovery Strategies • Business Recovery Monitoring • Cloning Automation • Disaster Restart Solutions Storage Aware Database Tools Source Database Storage Administration and Business Continuity Domain Backup, Clone, DR

14. Cloning Terminology • A clone is an exact but independent replica • Clone a DB2 system by volume • Clone a table space by data set • DB2 system cloning and table space refresh • The act of replicating the data, making the replica accessible, and then using the replica in lieu of the original data • DB2 system cloning automation • Clones a complete DB2 system including all its databases • Lowest level is by storage volume • DB2 table and index space refresh automation • Refreshes specific table and index spaces • Lowest level is by data set

15. Types of DB2 clones • Full Subsystem Clone • 2 sources: • DB2 Subsystem storage volumes • System Level Backup (SLB) • Partial subsystem Clone • Selected storage volumes (partial application data) • Skeleton Clone • DB2 directory, catalog, BSDS, and active logs storage volumes without application data • Populated by dataset • Table Space Clones • By dataset/object definition

16. Volume based fast replication options for DB2 system cloning FlashCopy (IBM,EMC,HDS) SnapShot (IBM,STK) TimeFinder/Clone Volume Snap (EMC) TimeFinder/Snap (EMC) Mirror processes PPRC (IBM,EMC,HDS) TimeFinder/Mirror, SRDF (EMC) ShadowImage HUR (HDS) Data set based fast replication options for DB2 table space refresh Data Set FlashCopy (IBM,EMC,HDS) Data set SnapShot (IBM,STK) TimeFinder/Clone Data set Snap (EMC) Fast Replication Data Copy Options Fast copy processes offloaded to the storage processor No host CPU or I/O resources Fast Replication Commands from z/OS

17. Volume copy options for DB2 system cloning TDMF (IBM) FDRPAS (Innovation Data Processing) DFSMSdss (IBM) FDR (Innovation Data Processing) Data set copy options for DB2 table space refresh Any traditional data set copy processes Host Based Data Copy Options Data copy processes use host based CPU and I/O facilities Slower than storage-based fast replication Host-based Copy Process

18. 7 8 DB2 Full Subsystem Cloning Steps Target DB2 Production DB2‘Source’ 5 Rename DB2 6 Update DB2 directory and BSDSs DB2 Clone Start DB2 in maintenance mode for metadata management DB2 volume Selection or SLB 1 Correct DB2 catalog and directory page spaces A. SET LOG LOAD(0) SET LOG SUSPEND (*not for an SLB source) B. Consistency Group 2 9 Update DB2 catalog 10 Correct application page spaces 3 Volume copy 11 Stop target in maintenance mode 4 SET LOG RESUME if 2A Clone Database Volumes Source Database Volumes 12 Start DB2 clone in normal mode

19. Partial Subsystem Clone Application Volumes Application Volumes Application Volumes Application Volumes Clone DB2 Subsystem Volumes Source DB2 Subsystem Volumes DB2 subsystem is cloned + specific applications Some application datasets are excluded from renames – and optionally deleted

20. Populated Subsystem Skeleton Clone Application Volumes Application Data Sets Application Data Sets Application Volumes Source DB2 Subsystem Volumes Clone DB2 Subsystem Volumes DB2 subsystem is cloned + selected DB2 data sets Volumes containing application data are NOT copied

21. DB2 Table Refresh Steps Target DB2 Production DB2‘Source’ Source Job DB2 Target Job DB2 Target 1 LISTDEF selection Object ID translation, data masking and log apply 7 Verify object compatibility 2 Create target DB2 DDL and table and index spaces if they don’t exist 3 8 Update identity columns Stop table space or fuzzy copy Start target table and index spaces 4 9 5 Perform copy process Start, if stopped 6

22. Benefits of cloning • All source object are known to the clone • Triggers • Constraints, Etc. • Stats are identical to the source • Packages are already bound and access paths known • Columns may be masked to protect sensitive data • If it can be done on the source it can be done on the clone • The footprint of the clone can be determined by the user and how the clone is populated

23. DB2 Support • DB2 Support • DB2 offline • DB2 online • Clone from an executing DB2 subsystem • Clone from a System Level Backup • DB2 data sharing • DB2 data sharing with many to less members • DB2 data sharing to non-DB2 data sharing • Clone from a System Level Backup

24. Smooths the migration path – and helps YOU to avoid surprises and delays during and after the upgrade process Provides for creating DB2 subsystem clones, which offer multiple levels of testing environments Clones are created with minimum skilled resources, minimum time and no interruption to your production systems. Creating clones of your production and nonproduction environments reduces the risk of impacting critical applications during the migration process. Using Volume Clone and Rename (VCR) & Fast Tablespace Refresh(FTR)

25. Q & A