1 / 30

Recovery Management Solution 50 Ways to Move Your Data (a.k.a., Make a New Plan Stan)

Recovery Management Solution 50 Ways to Move Your Data (a.k.a., Make a New Plan Stan). Phil Grainger Donna Di Carlo BMC Software Session Code: 414 Wed, May 01, 2013 01:00 PM - 02:00 PM| Platform: DB2 for z/OS. Data migration overview Capturing a consistent image

abena
Download Presentation

Recovery Management Solution 50 Ways to Move Your Data (a.k.a., Make a New Plan Stan)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Recovery Management Solution50 Ways to Move Your Data(a.k.a., Make a New Plan Stan) Phil Grainger Donna Di Carlo BMC Software Session Code: 414 Wed, May 01, 2013 01:00 PM - 02:00 PM| Platform: DB2 for z/OS

  2. Data migration overview • Capturing a consistent image • Migrating with RMD Solution V10.1.00 • New V11.1.00 Copy Migration feature • Migration scenarios • Summary • Questions Agenda

  3. Production data is our business • And it is often handy to have that data elsewhere • From production DB2 to “somewhere else” • Data analytics and decision support • Application testing • System testing • Problem diagnostics Why do we move data around?

  4. As with most things in DB2, we have choices to make • We could use Unload and Load • Costly process and time consuming • We could use DSN1COPY • Much faster • But no knowledge of DB2 internals • DSN1COPY can complete without errors, but the data may still be inaccessible • There are more and more reasons NOT to use DSN1COPY: • Schema changes that are not yet instantiated • RRF vs BRF • Object definition differences • We could use hardware snapshots • IF the object structures are IDENTICAL between subsystems • For safety we would need to revert to Unload and Load • Costly process and time consuming What are our choices?

  5. And there is • Restore the data using a consistent image • This process is very efficient • And if the data movement needs to be repeated, we could • Refresh the migrated data • Or even propagate changes via log There has to be a better way

  6. Image copy can’t have in-flight transactions • All updates must be committed Consistent image copy UR 4 UR 1 UR 3 UR 2 Consistent Point Inconsistent Point

  7. SHRLEVEL REFERENCE image copy • Requires a large outage • Instant Snapshot Copy • Uses intelligent storage to snap a SHRLEVEL REFERENCE copy • Requires a small outage • OUTCOPY ONLY • Merges existing image copy with log to produce a copy • Must specify a quiet point or use Timestamp Recovery feature • Can use Log Master to find a quiet point • QUIESCE not necessary • Online Consistent Copy (OCC) • Creates a SHRLEVEL CHANGE Snapshot • Uses log to back out in-flight transactions • No outage required Obtaining a consistent image

  8. Use when the target subsystem is remote • Specify an unregistered consistent copy in the INCOPY clause • Supply OBID translation values • Values can be defaulted for single-table table spaces and indexes Recover Plus INCOPY feature DB2A DB2B

  9. Recover Plus INCOPY feature (cont.) • Difficult to use with OBJECTSET • An OBJECTSET allows you to process a group of objects in a single statement • All OBID translation values must be defaulted • All image copy data set names must use the same data set model • Can’t use cabinet copies • A cabinet copy contains several small images in one data set • Eliminates several data set allocate/open/close commands • Needs BMCXCOPY information to read the cabinet Recover Plus INCOPY feature (cont.)

  10. Use when shared DASD is available • Specify source object name and quiet point • The appropriate image copy will be used based on the quiet point • Will merge log with image copy to create a consistent image • Can use Timestamp Recovery and specify a time instead of a quiet point • Specify VSAM data set name of target • Supply OBID translation values • Defaults source values for single-table table spaces and indexes Recover Plus INDEP OUTSPACE DB2B VSAM DS DB2A Log DB2A

  11. Can’t be used with cabinet copies or an OBJECTSET that contains multi-table table spaces Recover Plus INDEP OUTSPACE (cont.)

  12. Copy Migration feature helps automate migration • The migration file is key • Supplies image copy names and translation ID values • Used to verify compatibility between source and target attributes V11.1.00 Copy Migration feature

  13. Uses the following products • Copy Plus • EXPORT creates the migration file • Recover Plus processes the migration file • IMPORT automates INCOPY • MIGRATE automates INDEP OUTSPACE • Change Manager • EXPORT • IMPORT • Allows for multi-tasking • Allows BMCXCOPY access • Instant Snapshot • Cabinet copies • Encrypted copies • Allows LOB migration V11.1.00 Copy Migration feature (cont.)

  14. Brains of Copy Migration • Contains information from SYSCOPY, BMCXCOPY and the DB2 catalog • Image copy names • Object ID values • Schema definitions • Versioning information • Allows for a high level of error checking • Created by the Copy Plus EXPORT command • Input to the Recover Plus IMPORT and MIGRATE commands Migration file

  15. The output descriptor defines the migration file allocation • The object list names the table spaces to be exported • TABLESPACE • Can be wildcarded • OBJECTSET • APPLICATION • Table spaces will be included if a full image copy is found • Can request to include indexes with INDEXES YES • Must have an available index image copy • Image copy selection • Most recent copy is default • If INDEXES YES, index copy log point doesn’t have to match table space copy • Can request a copy at a specific point • If INDEXES YES, index copy log point must match table space copy Copy Plus EXPORT command

  16. OUTPUT EXPFILE UNIT WORK EXPOUT YES DSNAME RDADMB.PBGMIG.EXPORT EXPORT TABLESPACE DMDSRC*.* EXPORTDDN(EXPFILE) ATLOGPOINT LASTFULLCOPY INDEXES YES Copy Plus EXPORT example

  17. Automates the INCOPY technology • The EXPORT runs on the source while the IMPORT runs on the target • The object list names the table spaces to be imported • TABLESPACE • OBJECTSET • No specification means import everything • You have a choice on how to handle indexes • REBUILD • RECOVER • AUTO - let Recover Plus decide • NO - don’t process any indexes • Command available to map object names from source to target • Ability to migrate only data that has changed since last EXPORT/IMPORT Recover Plus IMPORT command

  18. IMPORT TS SOURCE SUBSYSTEM TARGET SUBSYSTEM EXPORT COPY IMPORT TS IX BMC XCOPY IX IC SYSCOPY BMC XCOPY MIG FILE DB2 CATALOG DB2 CATALOG

  19. IMPORT USING RDADMB.PBGMIG.EXPORT NOCOPYPEND INDEXES AUTO SYNC AUTO CHANGE TABLE FROM RDADMB.DMDSRC* TO RDADMB.DMDTGT* CHANGE INDEX FROM RDADMB.DMDSRC* TO RDADMB.DMDTGT* Recover Plus IMPORT example

  20. Automates the INDEP OUTSPACE technology • The EXPORT runs on the target while the MIGRATE runs on the source • The object list names the table spaces to be exported • TABLESPACE • OBJECTSET • No specification means migrate everything • Choices to handle indexes are limited • Recovering the indexes is advisable • Cannot rebuild the indexes with MIGRATE • Must supply a model of the VSAM data set name • Command available to map object names from source to target Recover Plus MIGRATE command

  21. MIGRATE TS SOURCE SUBSYSTEM TARGET SUBSYSTEM MIGRATE EXPORT IX DB2 CATALOG DB2 Catalog IC Log MIG FILE SYSCOPY BMC XCOPY

  22. MIGRATE USING RDADMB.PBGMIG.EXPORT1 CHANGE TABLE FROM RDADMB.DMDTGT* TO RDADMB.DMDSRC* CHANGE INDEX FROM RDADMB.DMDTGT* TO RDADMB.DMDSRC* INDEP OUTSPACE MODEL &VCAT.DSNDBC.&DB.&TS.I0001.&PART Recover Plus MIGRATE example

  23. BACKOUT updates Log Master ongoing process Copy Migration refresh Migration scenarios

  24. IMPORT production to test • On the source subsystem • Create an OCC for the table spaces • Execute Copy Plus EXPORT to create a migration file • On the target subsystem • Use Change Manager to • Create the target objects • Specify IMPORT to migrate the data • Rebuild the indexes • Execute Copy Plus to create copies of the new table spaces • Perform testing • BACKOUT AUTO to refresh data • Forward recovery will be performed if one of the following occurs • REORG • LOAD • REBUILD BACKOUT updates

  25. MIGRATE production to RO subsystem • On the target subsystem • Use Change Manager to create the target objects • Create an image copy for the table spaces • Execute Copy Plus EXPORT to create a migration file • Stop the table spaces • On the source subsystem • Find and generate a quiet point with Log Master • Run Recover Plus MIGRATE to move the data to the target VSAM • On the target subsystem • Start the table spaces • Rebuild the indexes Log Master ongoing process

  26. Refresh from production • On the source subsystem • Collect Logical Log (LLOG) with Log Master ongoing process • Use the quiet point from the MIGRATE as a starting point • Specify end point with a date/time, LRSN or LOGMARK • On the target • Use High Speed Apply Engine to apply LLOG • Repeat this process on a regular basis • Some customers repeat as regularly as every 15 minutes Log Master ongoing process (cont.)

  27. IMPORT production to test • On the source subsystem • Create an OCC for the table spaces and indexes • Execute Copy Plus EXPORT to create a migration file • On the target subsystem • Use Change Manager to • Create the target objects • Use Recover Plus to • IMPORT the table space and indexes Copy Migration refresh

  28. Refresh test data • On the source subsystem • Create an OCC for the table spaces and indexes • Execute Copy Plus EXPORT to create a migration file • On the target subsystem • Use Recover Plus to IMPORT with SYNC AUTO • Only refreshes data that was changed on the source and/or the target • No need to rebuild indexes Copy Migration refresh (cont.)

  29. BMC Software provides several different ways to • Create consistent image copies • Migrate data • Refresh data • Mix and match to suit your environment • All options provide • Speed • Efficiency • Ease of use • If you would like a copy of this presentation • We will be at the booth or email us Summary

  30. Evaluate my session online: www.idug.org/na2013/eval Phil GraingerDonna Di CarloBMC Softwarephil_grainger@bmc.com donna_di_carlo@bmc.com Session Code: 414 Recovery Management Solution50 Ways to Move Your Data(a.k.a., Make a New Plan Stan)

More Related