***SPAM*** Re: [DB2-L] [Maybe Spam] [DB2-L] OS/390 offsite disk mirroring/re covery

Tom Moulder

***SPAM*** Re: [DB2-L] [Maybe Spam] [DB2-L] OS/390 offsite disk mirroring/re covery
<snip>

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Bell, Raymond
Sent: Friday, January 19, 2007 5:03 AM
To: [login to unmask email]
Subject: ***SPAM*** Re: [DB2-L] [Maybe Spam] [DB2-L] OS/390 offsite disk
mirroring/recovery

So the snaps aren't for us, nor are they used by us. They're hangovers from
a previous DR strategy we used to have, involving stopping the subsystems
(you can stop laughing now), and should be removed. However if you're using
the snap copies for your DR then yes, it might be a good idea to suspend the
log while you snap.

<unsnip>

I have worked with EMC Symmetrix and as long as you have all the volumes for
the system or application segregated through SMS or some other allocation
mechanism you can break the mirror between all the volumes at a consistent
point for all volumes. It appears to DB2 and IMS as though there were a
power failure and each handles restart of the system at the remote location
with little problems. Before the consistent breaking of the mirror there
were issues with DB2 having a long LPL list at restart time. The only
problem with this approach is that DB2 will only run a small number of tasks
to resolve LPL issues and as a result the more objects on the list the
longer it takes to clear the list. Once the consistent split of the mirror
was implemented these issues virtually disappeared and the time to clear the
list with it. What this means is that a user can split the mirror of a
running DB2 without any pause as far as DB2 is concerned -- Log suspend or
whatever.

I have done this procedure with both non-data-sharing and data-sharing
systems and it works.

One site has three tier applications and it takes longer to get the UNIX app
servers changed to point to the new mainframe for application access than it
does to bring up the DB2 application at the remote site. That being said,
22 minutes and the application is back fully functional. The only
noticeable change to the user is that the last transaction did not work and
has to be entered once again.

Tom Moulder
TREX Associates, Inc.
9728 Delmonico Dr.
Keller, Tx. 76248-9559
+1 817 741-5549 Office
+1 817 741-5548 Fax
+1 682 558-6527 Mobile
[login to unmask email]
www.t-rex-associates.com

---------------------------------------------------------------------------------
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

Brian Bear

Re: [Maybe Spam] [DB2-L] OS/390 offsite disk mirroring/re covery
(in response to Tom Moulder)
Ray,

Thanks. I thought I was missing something about NOT having to do the
SET LOG SUSPEND during our flash copy. Again thanks for the
clarification.

Regards.

Brian.
Charming Shoppes.

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
Sent: Friday, January 19, 2007 6:03 AM
To: [login to unmask email]
Subject: Re: [DB2-L] [Maybe Spam] [DB2-L] OS/390 offsite disk
mirroring/re covery






Brian,

Basically because the snapping isn't used for our DB2 recoveries, but
for everything (i.e. non-DB2) else.

Our normal DR recovery process is to make use of the hot DASD at the DR
site via PPRC, so all we do is start 'er up and off we go. If we have
to fall back to our 'recover everything' process, we go back to our last
archive log point. We effectively do a conditional restart to the point
of the last archive - which for us will be immediately prior to the
snap, because we've manually -ARCHIVEd the log at that point - and
recover everything 'to current'. BMC's Recovery Manager has already
built all the jobs for us so it's quite straightforward.

So the snaps aren't for us, nor are they used by us. They're hangovers
from a previous DR strategy we used to have, involving stopping the
subsystems (you can stop laughing now), and should be removed. However
if you're using the snap copies for your DR then yes, it might be a good
idea to suspend the log while you snap.

Cheers,


Raymond Bell
Database Administrator


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Bear, Brian
Sent: 18 January 2007 22:48
To: [login to unmask email]
Subject: Re: [DB2-L] [Maybe Spam] [DB2-L] OS/390 offsite disk
mirroring/recovery

Why is suspending the logs briefly while you take your snaps, not
necessary?


-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email]
Sent: Thursday, January 18, 2007 9:15 AM
To: [login to unmask email]
Subject: Re: [DB2-L] [Maybe Spam] [DB2-L] OS/390 offsite disk
mirroring/recovery






Hey Steve,

Your timing is perfect - I spent the first two days this week at one of
our regular DR tests, and mirroring is exactly what we do. The first
day was spent re-proving our backup DR method (using BMC's Recovery
Manager) still works in case PPRC goes AWOL - it does. The 2nd day was
basically an hour or so waiting for the Sysprogs to bring up the LPAR at
our snap point, DB2 subsystems included, and having a quick butchers at
our subsystems to make sure they were fine (they were), followed by
several hours of sitting around waiting for someone to notice something
that didn't work - they didn't.

DR for us now is a piece of cake. The hard work is done by our DASD and
Sysprog bods. We currently suspend the logs briefly while we take our
snaps, but it's not necessary and we'll stop doing that shortly.

Anyway, it works a treat. Mind you, our DR site is only 30 or so miles
away so we don't experience (I believe) any of the latency Eric
mentioned as a possibility. So, as always, YMMV I believe the
short-hand is.

Cheers,


Raymond Bell
Database Administrator
PS. The one hard bit we still face is synching up with all those
non-z/OS worlds - AS/400, NT. Makes me chuckle. Bless 'em; they'll
catch up one day...

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Steve Lamb
Sent: 18 January 2007 13:01
To: [login to unmask email]
Subject: [Maybe Spam] [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 (and any attachments) may contain privileged and/or
confidential information. If you are not the intended recipient please
do not disclose, copy, distribute, disseminate or take any action in
reliance on it. If you have received this message in error please reply
and tell us and then delete it. Should you wish to communicate with us
by e-mail we cannot guarantee the security of any data outside our own
computer systems.
For the protection of Legal & General's systems and staff, incoming
emails will be automatically scanned.

Any information contained in this message may be subject to applicable
terms and conditions and must not be construed as giving investment
advice within or outside the United Kingdom.

The following companies are subsidiary companies of the Legal & General
Group Plc which are authorised and regulated by the Financial Services
Authority for advising and arranging the products shown: Legal & General
Partnership Services Limited (insurance and mortgages), Legal & General
Insurance Limited (insurance), Legal & General Assurance Society Limited
(life assurance, pensions and investments), Legal & General Unit Trust
Managers Limited and Legal & General Portfolio Management Services
Limited (investments).

They are registered in England under numbers shown.
The registered office is Temple Court, 11 Queen Victoria Street, London
EC4N 4TP.

Legal & General Partnership Services Limited: 5045000 Legal & General
Assurance Society Limited: 166055 Legal & General (Unit Trust Managers)
Limited: 1009418 Legal & General (Portfolio Management Services)
Limited:
2457525 Legal & General Insurance Limited: 423930

They are registered with the Financial Services Authority under numbers
shown. You can check this at www.fsa.gov.uk/register

Legal & General Partnership Services Limited: 300792 Legal & General
Assurance Society Limited: 117659 Legal & General (Unit Trust Managers)
Limited: 119273 Legal & General (Portfolio Management Services) Limited:
146786 Legal & General Insurance Limited: 202050

------------------------------------------------------------------------
---------

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

************************************************************************
****

*
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material. Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited. If you
received this message in error, please contact the sender and delete the
material from any computer.
************************************************************************
****

*

------------------------------------------------------------------------
----

-----
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

------------------------------------------------------------------------
---------

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

---------------------------------------------------------------------------------
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