Recovery and datasharing question

Hanne Lyssand

Recovery and datasharing question
I have a disaster recovery plan that needs to be updatet since we have started the road to datasharing.
We have one scenario where we have lost all disk in both our 2 locations, and have to relay on what we have one tape. (It has happened, but not here)
I do a forced log switch each hour, and have an accept of losing the rest. We have some other source for the data within that timeframe.

My problem now is that we still have some applications trouble so I have the second member down. In the v9 manuals for point in time recovery it is stated that I have to use the oldest LRSN of the 2 members. When we are up and running that’s ok, I just do a -ARCHIVE LOG SCOPE(GROUP) and will get a point who is fairly near in time. But if I have had the member down 3 days, I am a long way from just losing one hour.

Is there a work around? I can at the present bring the member up again an do whatever. But in the scenario that’s a little more tricky.
My guess is that a V8 or V9 is not a big difference. The only thing I have seen is that V9 helps you with the RECOVER INDOUBT so that you don't need them anymore, any point is made consistent.

Best regards
Hanne Lyssand

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Robert Catterall

Re: Recovery and datasharing question
(in response to Hanne Lyssand)
Hanne,

You definitely want to have all members of the DB2 data sharing group
started when you issue the ARCHIVE LOG SCOPE(GROUP) command. Why would
application trouble cause you to keep a member subsystem down for some
extended period of time? First of all, I'd think that a given application
would be able to run on all of the members of the data sharing group, versus
being confined to one member. Even if the application is confined to one
member, and an application problem causes that member to crash, I'd think
that you'd restart the member right away (to free retained locks).

Robert


On Tue, Dec 2, 2008 at 10:29 AM, Hanne Lyssand <[login to unmask email]> wrote:

> I have a disaster recovery plan that needs to be updatet since we have
> started the road to datasharing.
> We have one scenario where we have lost all disk in both our 2 locations,
> and have to relay on what we have one tape. (It has happened, but not here)
> I do a forced log switch each hour, and have an accept of losing the rest.
> We have some other source for the data within that timeframe.
>
> My problem now is that we still have some applications trouble so I have
> the second member down. In the v9 manuals for point in time recovery it is
> stated that I have to use the oldest LRSN of the 2 members. When we are up
> and running that's ok, I just do a -ARCHIVE LOG SCOPE(GROUP) and will get a
> point who is fairly near in time. But if I have had the member down 3 days,
> I am a long way from just losing one hour.
>
> Is there a work around? I can at the present bring the member up again an
> do whatever. But in the scenario that's a little more tricky.
> My guess is that a V8 or V9 is not a big difference. The only thing I have
> seen is that V9 helps you with the RECOVER INDOUBT so that you don't need
> them anymore, any point is made consistent.
>
> Best regards
> Hanne Lyssand
>
> ______________________________________________________________________
>
> * IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
> ______________________________________________________________________
>
>
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L
> list archives, FAQ, and delivery preferences are at
> http://www.idug.org/lsidug under the Listserv tab. While at the site, you
> can also access the IDUG Online Learning Center, Tech Library and Code
> Place, see the latest IDUG conference information and much more. If you
> have not yet signed up for Basic Membership in IDUG, available at no cost,
> click on Member Services at http://www.idug.org/lsms
>



--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Hanne Lyssand

Recovery and datasharing question
(in response to Robert Catterall)
The reason I have the member down, is that we have just started to do datasharing. When I started the second member last Friday morning, everything was ok until we started some batch that will match and close all the trades one the stock exchange. One of these jobs couldn't get the lock. The job will be changed, but it's no option to stop the trade until the problem is fixed. :-)

The recovery problem is not hot. I just want to understand the impact of having one member down and the question of point in time recovery.
In the recovery manual in the chapter: "Restoring data in a data sharing environment" in point 12 it states that I have to use the lowest ENDLRSN to create the restart point. Since we don't practice these recovery scenarios so often, I can't just test. Hopefully since the member went down nice and easy it's not a problem.

From the manual:
Use the print log map utility (DSNJU004) to list the BSDS contents. Find the ENDLRSN of the last log record that is available for each active member of the data sharing group. Subtract 1 from the lowest ENDLRSN in the data sharing group. Use this value for the ENDLRSN in the CRESTART statement. (In the sample output that is shown in step 7.c, the value is AE3C45273A77 - 1, which is AE3C45273A76.)

Hanne

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Chris White

Re: Recovery and datasharing question
(in response to Hanne Lyssand)
I think this could be a problem for us. We retired a DS member and don't run it
anymore. So the oldest ENDLRSN in the group is a very old value, perhaps
older than our archive retention period. The retired member was quiesced
months ago and its archive logs have probably all expired. Its active logs are
still available and it can theoretically be started (I think it is tested
occasionally and then quiesced).

It seems to me the oldest ENDLRSN in this DS group should be picked from the
surviving members, not the retired member. No so?

Chris White
Caterpillar Inc.

Note - these are just my opinions, not my employer's and blah, blah, blah...

===<snip>===>


On Wed, 3 Dec 2008 11:09:16 +0100, Hanne Lyssand
<[login to unmask email]> wrote:

>The reason I have the member down, is that we have just started to do
datasharing. When I started the second member last Friday morning,
everything was ok until we started some batch that will match and close all
the trades one the stock exchange. One of these jobs couldn't get the lock.
The job will be changed, but it's no option to stop the trade until the problem
is fixed. :-)
>
>The recovery problem is not hot. I just want to understand the impact of
having one member down and the question of point in time recovery.
>In the recovery manual in the chapter: "Restoring data in a data sharing
environment" in point 12 it states that I have to use the lowest ENDLRSN to
create the restart point. Since we don't practice these recovery scenarios so
often, I can't just test. Hopefully since the member went down nice and easy
it's not a problem.
>
>From the manual:
>Use the print log map utility (DSNJU004) to list the BSDS contents. Find the
ENDLRSN of the last log record that is available for each active member of the
data sharing group. Subtract 1 from the lowest ENDLRSN in the data sharing
group. Use this value for the ENDLRSN in the CRESTART statement. (In the
sample output that is shown in step 7.c, the value is AE3C45273A77 - 1,
which is AE3C45273A76.)
>
>Hanne
>
>_________________________________________________________________
_____
>
>* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
>_________________________________________________________________
_____
>
>
>
>The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L
list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug
under the Listserv tab. While at the site, you can also access the IDUG Online
Learning Center, Tech Library and Code Place, see the latest IDUG conference
information and much more. If you have not yet signed up for Basic
Membership in IDUG, available at no cost, click on Member Services at
http://www.idug.org/lsms

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Robert Catterall

Re: Recovery and datasharing question
(in response to Chris White)
Hey, Chris. Sorry about the delayed response.

My understanding is that you could leave out the log files of the "retired"
DB2 member if you are certain that you will not ever need any of the records
in those files for a recovery operation, so you should be OK given that the
quiesced system is unlikely to be used again.

Hanne, in your case, with a DB2 subsystem down that you expect to be back up
and in use again soon, I would be very reluctant to recover the system using
log files archived via an ARCHIVE LOG SCOPE(GROUP) command issued with one
or members down. Given that the alternative (losing perhaps 24 hours or
more of data changes) is very unappealing, I would be very keen on having
all members up when I issue the ARCHIVE LOG SCOPE(GROUP) command.

Not to beat a dead horse (as we say here in the USA), but I still don't see
why you'd have an extended period during which you have one of your members
down. A batch job's inability to get a lock shouldn't necessitate a member
shutdown. If the lock couldn't be obtained because another process on a
different DB2 member held an incompatible lock on the target resource,
that's contention that would occur regardless of whether or not you were in
data sharing mode. Even if you wanted to have all work run on DB2 A and
none on DB2 B, you wouldn't have to shut DB2 B down to accomplish that.

Robert


On Wed, Dec 3, 2008 at 9:31 AM, Chris White <[login to unmask email]> wrote:

> I think this could be a problem for us. We retired a DS member and don't
> run it
> anymore. So the oldest ENDLRSN in the group is a very old value, perhaps
> older than our archive retention period. The retired member was quiesced
> months ago and its archive logs have probably all expired. Its active logs
> are
> still available and it can theoretically be started (I think it is tested
> occasionally and then quiesced).
>
> It seems to me the oldest ENDLRSN in this DS group should be picked from
> the
> surviving members, not the retired member. No so?
>
> Chris White
> Caterpillar Inc.
>
> Note - these are just my opinions, not my employer's and blah, blah,
> blah...
>
> ===<snip>===>
>
>
> On Wed, 3 Dec 2008 11:09:16 +0100, Hanne Lyssand
> <[login to unmask email]> wrote:
>
> >The reason I have the member down, is that we have just started to do
> datasharing. When I started the second member last Friday morning,
> everything was ok until we started some batch that will match and close all
> the trades one the stock exchange. One of these jobs couldn't get the lock.
> The job will be changed, but it's no option to stop the trade until the
> problem
> is fixed. :-)
> >
> >The recovery problem is not hot. I just want to understand the impact of
> having one member down and the question of point in time recovery.
> >In the recovery manual in the chapter: "Restoring data in a data sharing
> environment" in point 12 it states that I have to use the lowest ENDLRSN to
> create the restart point. Since we don't practice these recovery scenarios
> so
> often, I can't just test. Hopefully since the member went down nice and
> easy
> it's not a problem.
> >
> >From the manual:
> >Use the print log map utility (DSNJU004) to list the BSDS contents. Find
> the
> ENDLRSN of the last log record that is available for each active member of
> the
> data sharing group. Subtract 1 from the lowest ENDLRSN in the data sharing
> group. Use this value for the ENDLRSN in the CRESTART statement. (In the
> sample output that is shown in step 7.c, the value is AE3C45273A77 - 1,
> which is AE3C45273A76.)
> >
> >Hanne
> >
> >_________________________________________________________________
> _____
> >
> >* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
> >_________________________________________________________________
> _____
> >
> >
> >
> >The IDUG DB2-L Listserv is only part of your membership in IDUG. The
> DB2-L
> list archives, FAQ, and delivery preferences are at
> http://www.idug.org/lsidug
> under the Listserv tab. While at the site, you can also access the IDUG
> Online
> Learning Center, Tech Library and Code Place, see the latest IDUG
> conference
> information and much more. If you have not yet signed up for Basic
> Membership in IDUG, available at no cost, click on Member Services at
> http://www.idug.org/lsms
>
> ______________________________________________________________________
>
> * IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
> ______________________________________________________________________
>
>
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L
> list archives, FAQ, and delivery preferences are at
> http://www.idug.org/lsidug under the Listserv tab. While at the site, you
> can also access the IDUG Online Learning Center, Tech Library and Code
> Place, see the latest IDUG conference information and much more. If you
> have not yet signed up for Basic Membership in IDUG, available at no cost,
> click on Member Services at http://www.idug.org/lsms
>



--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

[login to unmask email]

Re: Recovery and datasharing question
(in response to Robert Catterall)
Hanne,
You may wish to visit _www.recoveryknowledge.com_
(http://www.recoveryknowledge.com) and review the GENDB2 software product. The complete recovery
process is automated for datasharing and non-datasharing for onsite and offsite
Disaster Recovery (DR.

Ed.
**************Make your life easier with all your friends, email, and
favorite sites in one place. Try it now.
(http://www.aol.com/?optin=new-dp&icid=aolcom40vanity&ncid=emlcntaolcom00000010)

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms

Robert Catterall

Re: Recovery and datasharing question
(in response to DB2information@AOL.COM)
Hanne (and Chris),

I got some additional information on this topic that may be useful to you.

The directive to code the conditional restart control record so as to
truncate all DB2 members back to the same ENDLRSN point is based on an
assumption that you won't be recovering at the DR site using the current (at
the time of the disaster event) active log data from the primary site (you
WOULD be recovering using this data if you were mirroring the active log
data sets at the DR site, but you've mentioned that you're exploring a
scenario in which disk storage has been lost at both the primary and DR
sites). Without knowing what was on the current active log data set at the
time of the disaster, the only safe option would be to truncate all members
back to that earliest-in-time ENDLRSN value from a previous -ARCHIVE LOG
operation.

Now, in your case (member B has to be stopped for some extended period of
time) you could see to it that you would indeed know what is on member B's
current active log data set at the time of the disaster, and furthermore you
could know that this data is not needed for consistent recovery of the
database at the DR site, the payoff being that you would not need to
conditionally restart member B at the DR site, and you could use the
more-current log data from member A generated via -ARCHIVE LOG operations
since the shutdown of member B. Here's how you would do that: when you
determine that you need to shut member B down, first quiesce that subsystem
so that there are no in-flight, in-doubt, in-abort, or postponed-abort units
of recovery. Then, just before shutting the system down, do an -ARCHIVE
LOG. What you will end up with on the new current active log data set for
member B is just a shutdown checkpoint record, and that's not needed for
recovery at the DR site (you could run DSN1LOGP off the end of that last
member B archive log, generated via the just-before-shutdown -ARCHIVE LOG
operation, to verify that there were no incomplete URs on member B at the
time of the shutdown).

Robert


On Wed, Dec 3, 2008 at 5:09 AM, Hanne Lyssand <[login to unmask email]> wrote:

> The reason I have the member down, is that we have just started to do
> datasharing. When I started the second member last Friday morning,
> everything was ok until we started some batch that will match and close all
> the trades one the stock exchange. One of these jobs couldn't get the lock.
> The job will be changed, but it's no option to stop the trade until the
> problem is fixed. :-)
>
> The recovery problem is not hot. I just want to understand the impact of
> having one member down and the question of point in time recovery.
> In the recovery manual in the chapter: "Restoring data in a data sharing
> environment" in point 12 it states that I have to use the lowest ENDLRSN to
> create the restart point. Since we don't practice these recovery scenarios
> so often, I can't just test. Hopefully since the member went down nice and
> easy it's not a problem.
>
> From the manual:
> Use the print log map utility (DSNJU004) to list the BSDS contents. Find
> the ENDLRSN of the last log record that is available for each active member
> of the data sharing group. Subtract 1 from the lowest ENDLRSN in the data
> sharing group. Use this value for the ENDLRSN in the CRESTART statement. (In
> the sample output that is shown in step 7.c, the value is AE3C45273A77 - 1,
> which is AE3C45273A76.)
>
> Hanne
>
> ______________________________________________________________________
>
> * IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
> ______________________________________________________________________
>
>
>
> The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L
> list archives, FAQ, and delivery preferences are at
> http://www.idug.org/lsidug under the Listserv tab. While at the site, you
> can also access the IDUG Online Learning Center, Tech Library and Code
> Place, see the latest IDUG conference information and much more. If you
> have not yet signed up for Basic Membership in IDUG, available at no cost,
> click on Member Services at http://www.idug.org/lsms
>



--
Robert Catterall
Catterall Consulting
www.catterallconsulting.com

______________________________________________________________________

* IDUG 2009 Denver, CO, USA * May 11-15, 2009 * http://IDUG.ORG/lsNA *
______________________________________________________________________



The IDUG DB2-L Listserv is only part of your membership in IDUG. The DB2-L list archives, FAQ, and delivery preferences are at http://www.idug.org/lsidug under the Listserv tab. While at the site, you can also access the IDUG Online Learning Center, Tech Library and Code Place, see the latest IDUG conference information and much more. If you have not yet signed up for Basic Membership in IDUG, available at no cost, click on Member Services at http://www.idug.org/lsms