[SNAPSHOT - recovery options]

Jo K.Nash

[SNAPSHOT - recovery options]
Adrian,

I also asked some snapshot questions a while back, because it does appear to
be a good fast solution. But as you have uncovered there limitations. BMC so
far is the only vendor I have found that is taking advantage of the hardware
snapshot technology in more than just their copy utility.

Jo



Adrian Savory <[login to unmask email]> wrote:
Hi folks,

Can any IBMer (or anyone else) tell me if (when?) the DB2 Recover utility
will
support SNAPSHOT in future i.e. snap back virtual concurrent copy backups,
rather than recover them at the usual speed?

What I'm looking for is a fast AND flexible method of recovering a large
number
of DB2 objects, some of which will be big. SNAPSHOT looks to be the way
forward,
but I need fast recovery. The only way I think I can get that at the moment
is
by taking offline DFDSS dumps (via SNAPSHOT) and restoring them (snapping
them
back), but this isn't flexible enough as I only have the one recovery point
that
I can recover to quickly. (Incidentally has anyone played about with using
SNAPSHOT to recover snapped backups, followed by a LOGONLY recovery to a
point-in-time? Does this work? Any gotchas?)

Also, are there any plans for SNAPSHOT to be embedded in any other utilities
in
future? e.g. UNLOAD, REORG, etc.

Thanks.

Adrian Savory
ACSIS Ltd


the




____________________________________________________________________
Get free email and a permanent address at http://www.amexmail.com/?A=1



Roger Miller

Re: SnapShot - recovery options
(in response to Jo K.Nash)
The question is not clear to me. It would be more helpful if you
describe your objective than an implementation. I included a
number of possibilities I've heard before in the discussion below.

Even when we understand what you want, we do not provide
much information about dates. There is too much uncertainty in
timing, and too many people take a general statement as a
firm commitment. As usual, here are a couple of my opinions and
some of the background.

Also, there is a much better way to provide
your requirements, so they are in our requirements database and
accessible for developers. Ask your favorite IBMer to submit them,
since there is no direct customer input. The current application is
called NEWREQ in their Lotus Notes. This also provides a structure
for feedback to you, through the IBMer.

DB2 has had several varieties of SnapShot support for years, and several
improvements have been made. I think the red books are probably the
clearest explanations, except for the newest changes that are not reflected
there yet. As you might expect, the majority of our current work is on the
Enterprise Storage Server or ESS a.k.a. Shark, which calls this function
FlashCopy. For performance information check the white paper on the
main DB2 for OS/390 home page www.ibm.com/software/db2os390

1. DB2 can use Virtual Concurrent Copy to invoke the SnapShot or FlashCopy,
and you use the CONCURRENT keyword to invoke it. Since most backups
are to tape, SnapShot does only part of the job. We've had several
customers
ask for use of the function to keep the data on disk, taking advantage of
the
"virtual" disk. Another request I've seen is to have DFSMS implement retry
logic to avoid problems getting the data from the SnapShot to tape.

2. Using SnapShot for copying data sets is often an option for backup or
for copying some of the data to reduce the window. I've seen several
people
ask about other ways to copy or unload information, and there have been
quite a few changes in unload options, ranging from unload external on
the REORG and improved WHEN clauses to a new product offering that
has better flexibility and the ability to unload from an image copy.

3. For large numbers of data sets, copying volumes is much faster. There
are several notes about how to do this and a recent V6 APAR PQ31492 to
improve the technique. We worked with SAP and published a flash on the
topic.

Based upon a series of tests conducted by the SAP Advanced Technology Team
at IBM's Santa Teresa Labs and the SAP Competency Center, SAP has validated
the Enterprise Storage Server's (ESS) ability to meet SAP R/3's
requirements for Advanced Infrastructure Solutions in DB2 and OS/390
environments. For more, see
http://www.storage.ibm.com/hardsoft/diskdrls/technology.htm

There are a number of items customers have asked to to improve in this
area too, such as putting this under DB2 control for a dump and restore.
If you take a dump of the entire DB2 subsystem, logs, data, ... at a
consistency point, then you have the same options. Most of this is
discussed in disaster recovery topics and books.

The red books that have the best picture are:
Implementing SnapShot, SG24-2241-01
Storage Management with DB2 for OS/390, SG24-5462-00
RAMAC Virtual Array: Implementing Peer-to-Peer Remote Copy , SG24-5338-00
Using RVA and SnapShot for BI with OS/390 and DB2 , SG24-5333-00
Implementing DFSMSdss SnapShot and Virtual Concurrent Copy , SG24-5268-00
High Availability Considerations: SAP R/3 on DB2 for OS/390 , SG24-2003-00

Roger Miller


Adrian Savory <[login to unmask email]>@RYCI.COM> on 12/30/99 03:51:53 AM

Please respond to DB2 Data Base Discussion List <[login to unmask email]>

Sent by: DB2 Data Base Discussion List <[login to unmask email]>


To: [login to unmask email]
cc:
Subject: SNAPSHOT - recovery options



Hi folks,

Can any IBMer (or anyone else) tell me if (when?) the DB2 Recover utility
will
support SNAPSHOT in future i.e. snap back virtual concurrent copy backups,
rather than recover them at the usual speed?

What I'm looking for is a fast AND flexible method of recovering a large
number
of DB2 objects, some of which will be big. SNAPSHOT looks to be the way
forward,
but I need fast recovery. The only way I think I can get that at the moment
is
by taking offline DFDSS dumps (via SNAPSHOT) and restoring them (snapping
them
back), but this isn't flexible enough as I only have the one recovery point
that
I can recover to quickly. (Incidentally has anyone played about with using
SNAPSHOT to recover snapped backups, followed by a LOGONLY recovery to a
point-in-time? Does this work? Any gotchas?)

Also, are there any plans for SNAPSHOT to be embedded in any other
utilities in
future? e.g. UNLOAD, REORG, etc.

Thanks.

Adrian Savory
ACSIS Ltd