fast cloning of db2 subsystems using mainstar ® : ms/vcr ™ kelly smith mainstar software...

Fast Cloning of DB2 Subsystems using Mainstar®: MS/VCR™

Kelly SmithMainstar Software Corporation

www.mainstar.com [email protected]

07-17-03

Fast Cloning of DB2 Subsystems Using Mainstar: MS/VCR 2 Mainstar Software Corporation

©2003

Disclosures

Mainstar is a registered trademark of Mainstar Software Corporation in the United States, or other countries, or both. The following terms are trademarks of Mainstar Software Corporation:

Mirroring Solutions/Volume Conflict Rename

The following terms are registered trademarks of International Business Machines Corporation in the United States, or other countries, or both:

IBM, DFSMS, DFSMSdss, OS/390, z/OS, FlashCopy, PPRC, IBM Total Storage,

Enterprise Storage Server.

SnapShot and StorageTek are trademarks of Storage Technology Corporation.

TimeFinder is a trademark of EMC Corporation.

ShadowImage is a trademark of Hitachi Data Systems.

One point Copy and Equivalent Copy are trademarks of Fujitsu. TDMF is a trademark of Softek. FDRPAS is a trademark of Innovation Data Processing.

Other company, product and service names may be trademarks or service marks of others.

07-17-03


©2003

Agenda

P.I.T. CopiesThe key to data access!

P.I.T. – What are they? Fast Data Replication Splits of Continuous Mirrors

P.I.T. – Why you want to use them P.I.T – How to use them P.I.T. – Challenges to using them Introduction to Mirroring Solutions/Volume Conflict

Rename (MS/VCR) concepts Cloning a DB2 subsystem

07-17-03


©2003

Mainstar Profile

Consulting VSAM Tuning ICF Catalog Management Storage Management MVS DR Readiness Analysis

and Implementation DR Testing Assurance HSM and SMS

Implementation and Tuning Data Cloning

Storage ManagementCatalog RecoveryPlusHSM Reporter/ManagerStorage ManagerFastAudit/390

–HSM FastAudit –Catalog & DASD Audit –Tape Audit –HSM FastAudit-

MediaControlsVSAM ManagerRealTime Defrag

Disaster RecoveryASAP (critical file selection)Backup & Recovery Manager

–ABARS Aggregate LoadBalancer – Incremental ABARS

Catalog BaseLineMirroring Solutions/

Copy Services Manager

Data AccessMirroring Solutions/Volume Conflict RenameMirroring Solutions/Copy Services Manager

Who is Mainstar?

Specialists in MVS mainframestorage management anddisaster recovery since 1978

07-17-03


©2003

Mainstar Profile

What Mainstar Does

Extensive consulting and professional services VSAM Tuning

ICF Catalog Management

Storage Management

MVS Business Continuance Readiness Analysis and Implementation

Business Continuance Testing Assurance

HSM and SMS Implementation and Tuning

Data Cloning to Extend Online Availability

07-17-03


©2003

Mainstar Profile

What Mainstar Does OS/390 Storage Management Software

Catalog RecoveryPlus HSM Reporter/Manager Storage Manager FastAudit/390

– HSM FastAudit– Catalog & DASD Audit– Tape Audit– HSM FastAudit-MediaControls

VSAM Manager RealTime Defrag

07-17-03


©2003

Mainstar Profile

What Mainstar Does

OS/390 Disaster Recovery Software ASAP (critical file selection)

Backup & Recovery Manager– ABARS Aggregate LoadBalancer – Incremental ABARS

Catalog BaseLine

Mirroring Solutions/Copy Services Manager

07-17-03


©2003

Mainstar Profile

What Mainstar Does

OS/390 Data Access Software Mirroring Solutions/Volume Conflict Rename

Mirroring Solutions/Copy Services Manager

07-17-03


©2003

Point-in-Time

What is Point-in-Time (P.I.T.) ? An instantaneous point-in-time copy of your data.

Often referred to as Time Zero (T0).

Two kinds of cloning tools: 'Fast Data Replication' 'Splits of Continuous Mirrors'

Both result in an instantaneous point-in-time copy of your data.

07-17-03


©2003

Splits of Continuous Mirrors (hardware based) PPRC (IBM) ShadowImage (HDS) TimeFinder (EMC) Equivalent Copy (Fujitsu)

Fast Data Replication (hardware based) FlashCopy (IBM) SnapShot (STK) SNAP (EMC) One Point Copy (Fujitsu)

Splits of Continuous Mirrors (software based) TDMF (Softek) FDRPAS (Innovation Data Processing)

Point-in-Time Tools

Point-in-Time Tools

07-17-03


©2003

Fast Data Replication


07-17-03


©2003


Fast Data Replication Term for IBM FlashCopy and STK SnapShot.

Appearance of an almost instantaneous volume copy.

Builds a bit map of the source volume.

Allows both source and target data to be used almost immediately even though the copy can still be in progress behind the scenes.

The apparent copy time is seconds per volume.

07-17-03


©2003



Provided with utilities such as: IBM FlashCopy

STK SnapShot

EMC SNAP

Fujitsu One Point Copy

07-17-03


©2003

Data Set vs. Volume Level


Data Set level and Volume level.

Data Set level is generally used in applications to create a fast back up of a data set.

Volume Level is used for cloning volumes to use for other processing.

** We will only focus on Volume Level.

07-17-03


©2003

FlashCopy

FlashCopy

07-17-03


©2003

Terms

Fast Data Replication – FlashCopy

Background vs. No Background COPY – Background COPY – copies the PHYSICAL data from

the source volume to the target volume.

No Background COPY – uses the pointers to the corresponding source volume.

Only copies data that is about to be updated on the source volume to maintain the point-in-time copy.

07-17-03


©2003

Background COPY


When to choose Background COPY – When you want to use the target volume data for a long

time, such as to:– clone DB2 or non-database related data– run parallel production processes– provide application testing and qualify assurance– provide data mining– create a sandbox system for testing or training

07-17-03


©2003

No Background COPY


When to choose No Background COPY – When you want to use the target volume data for a

short time such as input to backup.

When a target volume is only needed for a short time (such as for input to backup), copying tracks of unchanged data from the source volume to the target volume is a waste of resources.

It is much more efficient to just use the corresponding source volume data set.

07-17-03


©2003

Terms


Background vs. No Background COPY – Background COPY – automatically does the full

background copy, unless you use keyword (FCNOCOPY)

No Background COPY – need to use keyword (FCNOCOPY) on the COPY

07-17-03


©2003

Logical Completion


Occurs in two phases: Logical Completion – the 1st phase

– Completes in a few seconds by constructing a bitmap to describe the source volume. Apparent copy time is 3-5 seconds per volume.

– At logical completion, the data has been 'cloned' and both the source and target volumes are available for read and write access.

– The source volume and target volume contents are an exact duplicate at this point in time.

– You can back up, recover to, and resume processing from this point in time – the logical completion.

07-17-03


©2003

Physical Completion


Occurs in two phases: Physical Completion – the 2nd phase

– FlashCopy – Background COPY

• Performs a FlashCopy Background COPY.

• Copies the physical source volume data to the target volume.

• Maintains the point-in-time copy

FlashCopy – No Background COPY– No 2nd phase occurs– No Background COPY is performed– Maintains the point-in-time copy

07-17-03


©2003

Maintaining the P.I.T.


Maintaining the point-in-time copy – The point-in-time copy is maintained by the copy

process jumping out of sequence if an update request has been issued for either a source or target volume data set that has not yet been copied.

07-17-03


©2003

Write to Source


Write request to source – If the data has already been copied from the source

volume to the target volume, a write to the source volume occurs.

If the data has not yet been copied from the source volume to the target volume, the data will be copied from the source volume to the target volume before the source volume update occurs.

07-17-03


©2003

Write to Target


Write request to target – If the data has already been copied from the source

volume to the target volume, a write to the target volume occurs.

If the data has not yet been copied from the source volume to the target volume, the data will be copied to the target volume before the target volume update occurs.

07-17-03


©2003

Read to Target


Read request to target – If the data has already been copied from the source

volume to the target volume, the data is read from the target volume.

If the data has not yet been copied to the target volume, the data is read from the source volume. However, in some Fast Data Replication tools, this may result in a copy of the read data to the target.

07-17-03


©2003

Rules


FlashCopy V1 Rules – – FlashCopy – source and target in same ESS Logical

Subsystem (LSS)– Volumes must be equal or greater in size– Volumes must be same device type– If rules are not met, the long copy is done– No data set level FlashCopy– A SOURCE volume can only be in one FlashCopy

relationship at a time

07-17-03


©2003

Rules

Fast Data Replication – FlashCopy FlashCopy V2 Rules – GA end of June

– FlashCopy – source and target in same ESS Logical Subsystem (LSS) (RESTRICTION LIFTED – now just same ESS)

– Volumes must be equal or greater in size– Volumes must be same device type

– If rules are not met, the long copy is done (RESTRICTION LIFTED unless volumes are in different ESSs)

– No Data Set Level FlashCopy (RESTRICTION LIFTED)

– A source volume can only be in one relationship at a time (RESTRICTION LIFTED – up to 12 relationships can exist with a volume)

07-17-03


©2003

SnapShot

SnapShot

07-17-03


©2003

Terms

Fast Data Replication – SnapShot

Background vs. No Background COPY – SnapShot – doesn’t do a background copy.

Works similar to FlashCopy FCNOCOPY.

However, if the source/target relationship exists for a long period of time, a large portion of the data will be copied if enough updates occur on the source.

07-17-03


©2003

Logical Completion


Occurs in one phase: Logical Completion

– Completes in a few seconds by constructing a bitmap to describe the source volume. Apparent copy time is 3-5 seconds per volume.

– At logical completion, the data has been 'cloned' and both the source and target volumes are available for read and write access.

– The source volume and target volume contents are an exact duplicate at this point in time.

– You can back up, recover to, and resume processing from this point in time – the logical completion.

07-17-03


©2003

Completion


Occurs in one phase: SnapShot

– No second phase occurs– No Background COPY is performed– Maintains the point-in-time copy

07-17-03


©2003

Maintaining the P.I.T


Maintaining the point-in-time copy – The point-in-time copy is maintained by the copy

process jumping out of sequence if an update request has been issued for either a source or target volume data set that has not yet been copied.

07-17-03


©2003

Write to Source


Write request to source – If the data has already been copied from the source

volume to the target volume, a write to the source volume occurs.

If the data has not yet been copied from the source volume to the target volume, the data will be copied from the source volume to the target volume before the source volume update occurs.

07-17-03


©2003

Write to Target


Write request to target – If the data has already been copied from the source

volume to the target volume, a write to the target volume occurs.

If the data has not yet been copied from the source volume to the target volume, the data will be copied to the target volume before the target volume update occurs.

07-17-03


©2003

Read to Target


Read request to target – If the data has already been copied from the source

volume to the target volume, the data is read from the target volume.

If the data has not yet been copied to the target volume, the data is read from the source volume. However, in some Fast Data Replication tools, this may result in a copy of the read data to the target.

07-17-03


©2003

Rules


SnapShot Rules – – SnapShot – source and target in same RVA Subsystem– Volumes must be equal or greater in size– Volumes must be same device type– If rules are not met, the long copy is done

07-17-03


©2003

FlashCopy & SnapShot

FlashCopy & SnapShot

07-17-03


©2003

How Is it Invoked?

Fast Data Replication – FlashCopy & SnapShot

How is it invoked? //COPYFULL JOB….

//COPY EXEC PGM=ADRDSSU

//SYSIN DD *

COPY FULL INDYNAM ((SRCVOL)) OUTDYNAM ((TGTVOL)) –

DUMPCONDITIONING

No special coding. If the rules are met, the Fast Data Replication copy occurs.

If rules are not met for FlashCopy V1 and SnapShot, the long copy is done.

07-17-03


©2003

Challenges to Access Data

Fast Data Replication – FlashCopy & SnapShot

Data Access Challenges – now that you’ve cloned volumes, how do you access the data that was just cloned?

Problems: VOLSERs may have the same volume name as the

source.

Data has the same data set names as the source.

If you don’t want to access the data from a different, non-sharing system, how do you access the data?

07-17-03


©2003

Result:1. Source PDBA01 keeps its original VOLSER on the target volume.2. VTOC, VTOCIX, and VVDS still think they’re PDBA01.3. The target volume is varied offline because it has the same VOLSER as the source.It

could be brought online on another non-sharing system to use the clone.4. Can’t use the target volume on a sharing system without re-labeling the volume,

and renaming and cataloging all data sets including the volume VTOCIX and VVDS.

SYS1.VTOCIX.PDBA01

VTOC

SYS1.VVDS.VPDBA01

SourcePDBA01

SYS1.VTOCIX.PDBA01

SYS1.VVDS.VPDBA01

VTOC

Target PDBA01


DFSMSdss FlashCopy or SnapShot with COPYVOLID specified – volume conflicts

07-17-03


©2003

Result:1. Source PDBA01 becomes new VOLSER TDBA01 on the target volume.2. VTOC, VTOCIX, and VVDS still think they’re PDBA01.3. Can’t use the target volume without renaming and cataloging all data sets

including the volume VTOCIX and VVDS.


DFSMSdss FlashCopy or SnapShot withNo COPYVOLID specified – volume conflicts

SYS1.VTOCIX. PDBA01

VTOC

SYS1.VVDS.V PDBA01

SourcePDBA01

SYS1.VTOCIX. PDBA01

SYS1.VVDS.VPDBA01

VTOC

Target TDBA01

07-17-03


©2003

Result:1. Data sets on the volume get copied, but keep their original name.2. Only the source data sets are cataloged; even if the catalog is on the cloned

volumes, it isn’t connected to the system’s master catalog.

VTOC

SourcePDBA01

Target TDBA01

VTOCIX VVDS VTOC VTOCIX VVDS

ICF User Catalog

A1.CAT

A.DSN3A.DSN2A.DSN1 A.DSN3A.DSN2A.DSN1


DFSMSdss FlashCopy or SnapShot – data set name and catalog conflicts

07-17-03


©2003

Splits of Continuous Mirrors


07-17-03


©2003



Term for onsite 'mirror' relationships that can be split at a specific point in time.

Provided with utilities such as: IBM PPRC

EMC TimeFinder

HDS ShadowImage

Fujitsu Equivalent Copy

Softek TDMF (Software)

Innovation Data Processing FDRPAS (Software)

07-17-03


©2003

Terms


Each hardware vendor has different names/terms for the following processes but they are all very similar:

Establish a source and target mirror relationship (both volumes are online).

Data is duplicated on target volume as it occurs on the source volume.

At a designated point in time, the mirror relationship is split or suspended.

07-17-03


©2003

Terms

Splits of Continuous Mirrors – cont.

The target volume automatically gets varied offline by the system because it has the same name as the source volume.

The target label needs to be re-labeled and varied online so the data can be processed.

07-17-03


©2003

SYS1.VTOCIX.PDBA01

VTOC

SYS1.VVDS.VPDBA01

SourcePDBA01

SYS1.VTOCIX.PDBA01

SYS1.VVDS.VPDBA01

VTOC

Target PDBA01SPLIT

Result:1. Source PDBA01 keeps its original VOLSER on the target volume.2. VTOC, VTOCIX, and VVDS still think they’re PDBA01.3. The target volume is varied offline because it has the same VOLSER as the source.

It could be brought online on another non-sharing system to use the clone.4. Can’t use the target volume on a sharing system without re-labeling the volume, and

renaming and cataloging all data sets including the volume VTOCIX and VVDS.


Split of Continuous Mirror – the target is offline Same internal data sets!

07-17-03


©2003



Using the target volumes again: Re-establish the mirror relationship

The target can be REFRESHED from the source without having to copy all the data again – the data plays catch-up

07-17-03


©2003

Mainstar: Mirroring Solutions/Volume Conflict Rename

Provides a way to use the cloned data

MS/VCR

07-17-03


©2003

MS/VCR Concepts

Gaining Data Access

MS/VCR provides access to data sets on target volumes: Quickly renames and catalogs the data sets

Fixes the VTOC, VTOCIX, and VVDS conflicts

Re-labels and varies volumes online (for 'Split of Continuous Mirror' tools)

Optionally, updates DB2 internal control information

07-17-03


©2003

MS/VCR Concepts

MS/VCR – Provides Data Access

Supports: Fast Data Replication – IBM FlashCopy, SnapShot,

EMC SNAP, and Fujitsu OPC

Splits of Continuous Mirrors – IBM PPRC, EMC TimeFinder, HDS ShadowImage, Fujitsu Equivalent Copy, Softek TDMF, and Innovation DP FDRPAS

07-17-03


©2003

MS/VCR Concepts

MS/VCR – Concepts

FlashCopy and SnapShot – 'cloaks' itself around DFSMSdss Initiates DFSMSdss COPY

Requires no COPYVOLID, so volume stays online

Captures catalog information to rename the data sets

Renames and catalogs target volume data sets

Updates DB2 Internals with new names

Provides simulation capabilities

07-17-03


©2003

MS/VCR Concepts

MS/VCR – Concepts

Splits of Continuous Mirrors User (at this time) is responsible for batch initiation of

mirror and split or suspend

MS/VCR re-labels and varies target volume(s) online

Captures catalog information to rename the data sets

Renames and catalogs target volume data sets

Updates DB2 Internals with new names

Provides simulation capabilities

07-17-03


©2003

MS/VCR – Timings

Cataloging and volume processing execute in parallel Timing 1: 19 volumes (mod 3), 32,000 data sets

– 1 minute to copy

– 3 minutes to rename and catalog!

Timing 2: 134 volumes, 300 gigabytes of data, 700+ data sets– 3.5 minutes to copy

– 3.5 minutes to rename and catalog!

Timings

07-17-03


©2003

Timings

MS/VCR – Timings – cont.

Cataloging and volume processing execute in parallel Timing 3: 64 volumes (mod 3), 20,000 data sets

– 3 minutes to copy– 3 minutes to rename and catalog!

07-17-03


©2003

Timings

Timings

FlashCopy note: FlashCopy V2 documentation states a tenfold

reduction in initialization time. This is the logical completion described earlier and is also the COPY time.

IBM White Paper: IBM TotalStorage Enterprise Storage Server Advanced Copy Services

07-17-03


©2003

Steps to Clone a DB2 Subsystem

Steps to Clone a DB2 Subsystem

07-17-03


©2003

Steps to clone a DB2 Subsystem using … FlashCopy/SnapShot

1. Stop the source DB2 subsystem

2. Run MS/VCR COPY

3. Start the source DB2 subsystem

4. Run MS/VCR RENAME

5. Run MS/VCR DB2UPDATE against the cloned DB2 subsystem – this will update the cloned BSDSs and the cloned DB2 directory (DBD01)

6. Start the cloned DB2 subsystem in maintenance mode with a special zparm

7. Issue SQL commands to update the cloned DB2 subsystem VCAT names

8. Stop the cloned DB2 subsystem from running in maintenance mode

9. Start the cloned DB2 subsystem with normal zparm

Steps –FlashCopy/SnapShot

07-17-03


©2003


2. Run MS/VCR COPY



5. Run MS/VCR DB2UPDATE

6. Start the cloned DB2 subsystem in maint. mode

7. Issue SQL commands

8. Stop the cloned DB2 subsystem in maint. mode

9. Start the cloned DB2 with normal zparm

Production Copy of Production –

Production Databases

Source

Copy for Inquiry

Target-

Steps –FlashCopy/SnapShot

Steps to use … FlashCopy/SnapShot

07-17-03


©2003

Steps to clone a DB2 Subsystem using … Splits of Continuous Mirrors

1a. Establish the Mirror

1b. Stop the source DB2 subsystem

1c. Split or Suspend the Mirror

2. Run MS/VCR COPY



5. Run MS/VCR DB2UPDATE against the cloned DB2 subsystem – this will update the cloned BSDSs and the cloned DB2 directory (DBD01)

6. Start the cloned DB2 subsystem in maintenance mode with a special zparm

7. Issue SQL commands to update the cloned DB2 subsystem VCAT names


9. Start the cloned DB2 subsystem with normal zparm

Steps – Splits of Continuous Mirrors

07-17-03


©2003

1a. Establish Mirror

1b. Stop the source DB2 subsystem

1c. Split Mirror

2. Run MS/VCR COPY



5. Run MS/VCR DB2UPDATE

6. Start the cloned DB2 subsystem in maint. mode

7. Issue SQL commands

8. Stop the cloned DB2 subsystem in maint. mode

9. Start the cloned DB2 with normal zparm

Production

Production Databases

Copy for Inquiry

Copy of Production –

Source Target-

Steps – Splits of Continuous Mirrors

Steps to use … Splits of Continuous Mirrors

07-17-03


©2003

Stop Source DB2

Step 1 – Stop the Source DB2 Subsystem (FlashCopy/SnapShot)

Stop the source DB2 subsystem

Gives you a static copy of: Your data

The catalog entries

07-17-03


©2003

Stop Source DB2

Step 1 – Stop the DB2 Subsystem (Splits of Continuous Mirrors)

Start the mirror in advance

Stop the source DB2 subsystem

Split the mirror at your point-in-time

Gives you a static copy of: Your data

The catalog entries

07-17-03


©2003

MS/VCR COPY

Step 2 – MS/VCR COPY Command

Fast Data Replication – Initiates copies using DFSMSdss

Captures catalog information

Splits of Continuous Mirrors – Re-labels target volumes

Varies online

Captures catalog information

07-17-03


©2003

MS/VCR COPY

Step 2 – MS/VCR COPY Command(FlashCopy/SnapShot)

//VCRCOPY JOB ,'VCR COPY',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID

//S0 EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

DEL hlq.JRNL

DEL hlq.WRK.UCATBKUP.*

//S1 EXEC PGM=VCR00010,REGION=8M

//STEPLIB DD DISP=SHR,DSN=hlq.LOAD

//VCRINI DD DISP=SHR,DSN=hlq.PARMLIB(VCRINI)

//VCRPRINT DD SYSOUT=*

//SYSUDUMP DD SYSOUT=*

//JOURNAL DD DSN=PRD.DB2A.JRNL,RECORG=KS,KEYLEN=64,KEYOFF=0,DISP=(,CATLG),

// UNIT=SYSALLDA,LRECL=600,SPACE=(CYL,(10,10))

//SYSIN DD *

COPY DATA-MOVER(PGM(ADRDSSU)) -

FROM-STORAGEGROUP(DB2A) TO-STORAGEGROUP(DB2B) -

USERCATALOGS(SRC.USERCAT1 TGT.USERCAT1) -

CATWORK-DSN(PRD.DB2A.WRK.*) -

JOURNAL-DDN(JOURNAL)

07-17-03


©2003

Step 2 – MS/VCR COPY Command(Splits of Continuous Mirrors)

//VCRCOPY JOB ,'VCR COPY',CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID

//S0 EXEC PGM=IDCAMS

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

DEL hlq.JRNL

DEL hlq.WRK.UCATBKUP.*


//STEPLIB DD DISP=SHR,DSN=hlq.LOAD

//VCRINI DD DISP=SHR,DSN=hlq.PARMLIB(VCRINI)



//JOURNAL DD DSN=PRD.DB2A.JRNL,RECORG=KS,KEYLEN=64,KEYOFF=0,DISP=(,CATLG),

// UNIT=SYSALLDA,LRECL=600,SPACE=(CYL,(10,10))

//SYSIN DD *

COPY DATA-MOVER(PGM(NONE)) - VOLPAIRSDEVN(DB2A01 DB2B01 devn) -




MS/VCR will re-label the specifieddevice (devn)to the targetVOLSER

MS/VCR COPY

07-17-03


©2003

COPY SIMULATE

MS/VCR COPY SIMULATE – for setup verification (FlashCopy/SnapShot)

Checks pairing requirements (if using FlashCopy V1 or SnapShot) so the copy isn’t done the long way when run for real

Checks syntax

Backs up catalogs for MS/VCR RENAME SIMULATE

Does not initiate the copy

07-17-03


©2003

Helpful for new MS/VCR setups or when modifications have been made

Verify syntax and pair volumes

MS/VCR COPY SIMULATE – for setup verification (FlashCopy/SnapShot)

COPY FROM-STORAGEGROUP(DB2A) -

TO-STORAGEGROUP(DB2B) -

USERCATALOGS(DB2A.UCAT1 -

DB2B.UCAT1) -

JOURNAL-DDN(JOURNAL) -

SIMULATE

COPY SIMULATE

07-17-03


©2003

MS/VCR COPY SIMULATE

MS/VCR COPY SIMULATE – for setup verification (Splits of Continuous Mirrors)

Checks Syntax

Backs up catalogs for MS/VCR RENAME SIMULATE

07-17-03


©2003

Helpful for new MS/VCR setups or when modifications have been made

Verify syntax and pair volumes

MS/VCR COPY SIMULATE – for setup verification (Splits of Continuous Mirrors)

COPY DATA-MOVER(PGM(NONE) ) -

VOLPAIRSDEVN(DB2A01 DB2B01 devn) -




SIMULATE

MS/VCR COPY SIMULATE

07-17-03


©2003

SMS Storage Groups

MS/VCR COPY – by SMS Storage Group (FlashCopy/SnapShot)

Source and/or Target volume specification by: VOLSERS

VOLSER masks

Storage Groups

To help prevent pieces of data from being orphaned by not being copied.

Now you can specify volumes by storage group to minimize setup errors – DFSMSdss, by itself, does not support this very important capability!

07-17-03


©2003

Shark (ESS)LSS 1

LSS 2

LSS 3

LSS n

SRC SRC

SRC

SRC

SRC SRC

SRCSRC

TGT TGT

TGT

TGT

TGT

SourceStorage group – DB2A

TargetStorage group – DB2B

SRC

TGT

TGT

TGT

SRCTGT

SRCSRC

SRCSRC

TGT

TGT

TGTTGT

TGTTGT

TGT

SRC

SRC

Copy by SMS Storage GroupsFlashCopy

07-17-03


©2003

Storage Tek

SRC SRC

SRC

SRC

SRC SRC

SRCSRC

TGT TGT

TGT

TGT

TGT

SourceStorage group – DB2A

TargetStorage group – DB2B

SRC

TGT

TGT

TGT

SRCTGT

SRCSRC

SRCSRC

TGT

TGT

TGTTGT

TGTTGT

TGT

SRC

SRC

Copy by SMS Storage Groups SnapShot

SubSys2

SubSys1

07-17-03


©2003

Start Source DB2

Step 3 – Start Source DB2 Subsystem

FlashCopy and SnapShot – FlashCopy or SnapShot is logically complete, and for

FlashCopy, the Background COPY is initiated

Catalog information has been captured in synchronization with the FlashCopy or SnapShot

Splits of Continuous Mirrors – Volumes re-labeled and varied online

Catalog information has been captured in synchronization with the split

07-17-03


©2003

MS/VCR RENAME

Step 4 – MS/VCR RENAME Command Renames and catalogs target volume data sets//S1 EXEC PGM=VCR00010,REGION=8M

//STEPLIB DD DSN=hlq.LOAD,DISP=SHR

//VCRINI DD DSN=hlq.PARMLIB(VCRINI),DISP=SHR



//JOURNAL DD DSN=PRD.DB2A.JRNL,DISP=SHR

//SYSIN DD *

RENAME -

VOLBKUP-DDN(VOLBKUP) -


DATACLAS(SOURCE) -

MGMTCLAS(SOURCE) -

STORCLAS(SOURCE) -

RENAME-MASKS(DB2A.** DB2B.**)

07-17-03


©2003

MS/VCR RENAME SIMULATE


Helps ensure all data sets in the COPY are included in a RENAME mask.

Makes sure all related data is included by comparing both catalog and volume records. All multi-volume data sets are included

All VSAM spheres, etc.

Makes sure you didn’t leave out a source catalog

07-17-03


©2003


MS/VCR RENAME SIMULATE //S1 EXEC PGM=VCR00010,REGION=8M





//JOURNAL DD DSN=PRD.DB2A.JRNL,DISP=SHR

//SYSIN DD *

RENAME SAFE SIMULATE -



DATACLAS(SOURCE) -

MGMTCLAS(SOURCE) -

STORCLAS(SOURCE) -

RENAME-MASKS(DB2A.** DB2B.**)

07-17-03


©2003

MS/VCR RENAME SAFE

MS/VCR RENAME

SAFE option allows the RENAME step to be RERUN to correct problems caused by mistakes, such as incorrectly specified rename masks

RENAME SAFE -


…

07-17-03


©2003

Target DB2 Subsystem Setup

Step 5 – Target DB2 Subsystem Setup

The target DB2 subsystem definition needs to be defined in advance of cloning a subsystem: Define the new DB2 subsystem in SYS1.PARMLIB

Set up the procs in SYS1.PROCLIB

Set up the target system ZPARMS

If data-sharing is involved, define the target system to the coupling facility

DB2 UDB for OS/390 and z/OS V7 Administration Guide SC26-9931-01

For DB2 data-sharing: DB2 UDB for OS/390 and z/OS V7 Data Sharing: Planning and Administration SC26-9935-01

07-17-03


©2003

DB2UPDATE

Step 5 – MS/VCR DB2UPDATE command

Wrap-around support to update 'cloned' DB2 internals

Combination of: Direct MS/VCR DB2UPDATE modifications to the DB2

directory and BSDSs to reflect renamed/recataloged data sets from RENAME step

Remaining DB2 catalog changes via DB2 SQL statements to update the cloned DB2 VCATnames

07-17-03


©2003

DB2UPDATE

Step 5 – MS/VCR DB2UPDATE

Run MS/VCR DB2UPDATE to update the DB2 directory and the DB2 boot strap data sets (BSDSs). DB2 directory updates

– The VCATNAME– Optionally, the DB2 storage group names

BSDSs updates– The DB2 catalog name – The 'active' log data set names– Optionally, the ARCHIVE data set names and volume

serial numbers

07-17-03


©2003

DB2UPDT2

Step 5A – MS/VCR DB2UPDT2 Command

If DB2 data sharing is involved, run MS/VCR DB2UPDT2 member for each additional DB2 member.

If required by your environment, run DSNJU003 toupdate the target DB2 BSDS's DDF parameters.

07-17-03


©2003

DB2 Steps

Step 6 – Start Target DB2 System in MaintenanceMode

Start the target DB2 system in maintenance mode using a special zparm.

This special zparm allows the DB2 catalog to be updated, and is set up in advance of the subsystem clone.

07-17-03


©2003

Step 7 – MS/VCR VCRSQL Command

Run MS/VCR VCRSQL to issue the SQL statements that will update the DB2 VCATnames (this is set up in advance).

For each old/new VCATNAME:UPDATE SYSIBM.SYSSTOGROUP

SET VCATNAME = 'newvcat'

WHERE VCATNAME = 'oldvcat' ;

UPDATE SYSIBM.SYSTABLEPART


WHERE VCATNAME = 'oldvcat' ;

UPDATE SYSIBM.SYSINDEXPART


WHERE VCATNAME = 'oldvcat';

DB2 Steps

07-17-03


©2003

DB2 Steps

Step 8 – Shut the target DB2 system down.

Step 9 – Start the target DB2 system again with itsnormal zparms DSNZPARx.

07-17-03


©2003

MS/VCR DB2UPDATE

MS/VCR DB2UPDATE Timings 29 mod 2 volumes:


2. 2 minutes – Run MS/VCR COPY


4. 2 minutes – Run MS/VCR RENAME

5. 5 seconds – Run MS/VCR DB2UPDATE against the cloned DB2 subsystem – this will update the cloned BSDSs and the cloned DB2 directory (DBD01)

6. 16 seconds – Start the cloned DB2 subsystem in maintenance mode with a special zparm

7. 5 seconds – Issue SQL commands to update the cloned DB2 subsystem VCAT names


9. 70 seconds – Start the cloned DB2 subsystem with normal zparm

07-17-03


©2003

MS/VCR DB2UPDATE SIMULATE

MS/VCR – DB2UPDATE SIMULATE

Find out exactly what DB2UPDATE would modify in the BSDSs and DB2 directory if you were running the update for real.

07-17-03


©2003

MS/VCR Optional Commands

MS/VCR Additional Optional Features

MS/VCR FINDUCATS Command Locates user catalogs for source volumes

MS/VCR BCSCLEAN Command Deletes catalog entries from previous executions

07-17-03


©2003

MS/VCR FINDUCATS

MS/VCR – FINDUCAT (optional step)

Run MS/VCR – FINDUCATS Identifies user catalogs for all data sets on source

volumes

Run FINDUCATS before COPY – if catalogs are relatively static, only run it once

Why not do this as part of the COPY step? Time may be of the essence

Likely to find the same catalogs every cycle

Performance implications for lookup

07-17-03


©2003

MS/VCR FINDUCATS

MS/VCR – FINDUCAT (optional step) //??????? JOB ,'VCR FINDUCATS',CLASS=?,MSGCLASS=?






//SYSIN DD *

FINDUCATS -

FROM-STORAGEGROUP(DB2A) orFROM-VOLSER(DB2A*)

07-17-03


©2003

Optional BCSCLEAN

MS/VCR BCSCLEAN (optional step)

Empty catalogs – BCSCLEAN can be used – or a DELETE/DEFINE of catalog(s) in front of each cloning execution.

Populated catalogs – BCSCLEAN is needed – don't have a dedicated target catalog.

Remove orphaned catalog entries from previous executions.

BCSCLEAN JOURNAL-DDN(JOURNAL)

07-17-03


©2003

Resources

Resources

IBM Redbook – Mainstar MS/VCR The Tool for Efficient Cloning

White Paper: Copying a PeopleSoft 8.1 DB2 Subsystem with Mainstar's MS/VCR Using the FlashCopy Function of IBM ESS DASD This White Paper is available on Mainstar's web site,

www.mainstar.com, andIBM's web site

07-17-03


©2003

Fast Cloning of DB2 Subsystems using Mainstar®: MS/VCR™

Kelly SmithMainstar Software Corporation

www.mainstar.com [email protected]

fast cloning of db2 subsystems using mainstar ® : ms/vcr ™ kelly smith mainstar software...

Documents

tuningdata cloning

time copy

kinds of cloning tools

point copy

trademark of emc corporation

time toolspoint

msvcrmainstar profilewho

trademarks of fujitsu