OS/390 offsite disk mirroring/recovery

Steven Lamb

OS/390 offsite disk mirroring/recovery
We need to come up with a proposal to be able to recover a DB2 system at a
second site. The disks would be mirrored - one set in the primary data
centre and the second set in a second centre a couple of hundred miles
away. If the primary data centre goes down, then we will need to IPL a
machine at the second centre and recover the systems within a couple of
hours.

Obviously there are quite a few complications in this - the MVS catalogs,
IMS, CICS and DB2 etc. Does anybody do anything similar and what sort of
tools/products do you use to do this?

Steve

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

Eric Pearson

Re: OS/390 offsite disk mirroring/recovery
(in response to Steven Lamb)
I've been in shops that do this with integrated
hardware/software combinations from the vendor (HDS and EMC). Other
vendors
likely provide similar solutions. Works well,
but biggest concerns:

1) Which set(s) of devices must be consistent with each other?
Example: DB2 BSDS, Active Log, Catalog, and Directory
absolutely must. Preferably DB2 application objects
also should. If the underlying software (load libraries, etc.)
Do your CICS, MQ, etc. data and logs need to be exactly
in synch with the DB2 stuff? If the underlying software (
load libraries, etc.) is a little behind it is no big deal.
Ask vendor about terms like 'consistency group'.
2) Delay. If the mirroring is truly synchronous (i.e. exactly consistent
at all times), the length of time for I/O is increased by the
time to send the data and receive acknowledgement of the
receipt.
Depending upon the distance and your response requirements, this
might be a very small issue or an absolute show stopper.
3) If you mitigate (2) by accepting asynchronous mirroring, what is
your tolerance and what are your procedures for handling
the inevitable data inconsistencies (which again may be very
small or intolerably large).
4) Procedures for the remote site. This is a very large challenge.
5) Non-data concerns - how to get a network etc. in place.
6) How to return to 'home site' after crisis passes. I do not
know anybody who has tried this (or even tested!).
7) Staffing at remote site (remember the disaster killed
all your locals!).

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Steve Lamb
Sent: Thursday, January 18, 2007 8:01 AM
To: [login to unmask email]
Subject: [DB2-L] OS/390 offsite disk mirroring/recovery

We need to come up with a proposal to be able to recover a DB2 system at
a second site. The disks would be mirrored - one set in the primary data
centre and the second set in a second centre a couple of hundred miles
away. If the primary data centre goes down, then we will need to IPL a
machine at the second centre and recover the systems within a couple of
hours.

Obviously there are quite a few complications in this - the MVS
catalogs, IMS, CICS and DB2 etc. Does anybody do anything similar and
what sort of tools/products do you use to do this?

Steve

------------------------------------------------------------------------
---------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and
home page at http://www.idugdb2-l.org/archives/db2-l.html. From that
page select "Join or Leave the list". The IDUG DB2-L FAQ is at
http://www.idugdb2-l.org. The IDUG List Admins can be reached at
[login to unmask email] Find out the latest on IDUG conferences
at http://conferences.idug.org/index.cfm


This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated.

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm