V7 on z/OS - XRC, BSDS and Logs

Adam Baldwin

V7 on z/OS - XRC, BSDS and Logs
Hi. The other day we ran a DR test in which we tried to bring up one of
our DB2s on another box. We use XRC to manage the remote copying. When we
tried to bring up DB2 on the remote site it failed to start - abending
with a forward read error against the active log. The checkpoint RBA was
definitely within the active log range.

From the XRC documentation and the DB2 DR documentation I can't fully
understand how XRC copes with any inflight work on the live DB2. At the
time of a system crash, XRC will have copies of the BSDS and logs but
these may not be in sync as far as DB2 is concerned.

Can anyone explain, or point me to an explanation of, how XRC controls
inflight DB2 tasks and URs?

Is a conditional restart or cold start always required at the remote site?

Many thanks.

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

Tom Moulder

Re: V7 on z/OS - XRC, BSDS and Logs
(in response to Adam Baldwin)
Adam

I'm going to start and the end and work back. Perhaps it will make more
sense to you.

XRC does not control DB2 tasks or URs. XRC is a storage solution that is
implemented with very little or no knowledge of the database. In the cases
I have seen, XRC is used to Asynchronously copy data from one site to
another and typically over longer distances than can be accomplished with
normal channel hardware. The key word in the previous sentence is
"Asynchronously". With XRC configuration, storage will group DASD volume
serial numbers into consistency groups. Then each of these consistency
groups will accumulate I/Os to the primary volumes into a cache. These I/Os
are timestamped so that all I/O can be performed at the secondary site in
the exact time sequence of the primary site. The key to your issue is
determining how long these I/Os will be cached before SDM (a part of SMS
called System Data Mover) send the I/Os to the secondary site.
Additionally, it will be important to know what volumes are in each
consistency group. I would think that you should have all volumes for a DB2
subsystem in one group. Otherwise, you could have BSDS and log volumes at
one point in time and application data at another point in time. That could
lead to mismatches between LRSN or RBA values through DB2 data sets.

You should be able to get the secondary DB2 system up and running, but
depending upon your configuration you might have to do a conditional
restart. On second thought, you probably would have to do a conditional
restart. It would seem to me that if your BSDS and logs are not at the same
point in time that would be a major challenge to overcome. If your
application data is at a later time than your BSDS and logs that would be
another major challenge.

Again let me say that I am not an expert and have not been involved in
setting up your system, so I could be way off. If it is set up like I have
seen elsewhere, then these are some things to discover that will probably
lead you to understanding what is happening when you try to bring up DB2.

XRC AFAIK lacks the ability to suspend I/O from z/OS for a short period of
time across multiple volumes. This facility is provided by EMC and does
provide some additional capabilities when dealing with storage managed
copies over long distances. Also, this type of environment is more easily
managed if you have all your DB2 data sets on an exclusive set of volumes
where no other data is allowed and where each DB2 subsystem is segregated
from each other.

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

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Adam Baldwin
Sent: Thursday, December 21, 2006 1:10 AM
To: [login to unmask email]
Subject: [DB2-L] V7 on z/OS - XRC, BSDS and Logs

Hi. The other day we ran a DR test in which we tried to bring up one of
our DB2s on another box. We use XRC to manage the remote copying. When we
tried to bring up DB2 on the remote site it failed to start - abending
with a forward read error against the active log. The checkpoint RBA was
definitely within the active log range.

From the XRC documentation and the DB2 DR documentation I can't fully
understand how XRC copes with any inflight work on the live DB2. At the
time of a system crash, XRC will have copies of the BSDS and logs but
these may not be in sync as far as DB2 is concerned.

Can anyone explain, or point me to an explanation of, how XRC controls
inflight DB2 tasks and URs?

Is a conditional restart or cold start always required at the remote site?

Many thanks.

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


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.25/593 - Release Date: 12/19/2006

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

Amit Agarwal

Re: V7 on z/OS - XRC, BSDS and Logs
(in response to Tom Moulder)
Adam,

I have a similar setup here, with EMC ASRDF on DB2 v7. From what Tom has
described, its seems that XRC and EMC's ASRDF are similar in concept.

Not sure if this is going to be useful to you, but here is our
situation.
We have all disks related to a subsystem in one consistency group. In my
tests, I did not have to do a conditional restart even when I yanked off
the link between the source and target while Db2 was running. The target
is an hour away.

In one of my calls with a EMC, I was told that to bring up DB2 on the
target, we should be prepared to use everything that are required for
DB2 recovery - includes image copies, BSDS, archives etc. However, in my
tests, Db2 came up without any intervention at all except for some in
inflight recovery that DB2 took care on its own. Basically from my
perspective, my DR is automated and I don't expect to have to do
anything on DB2. We will have to update licenses etc for third party
tools like BMC.

Hope this helps,

Amit Agarwal





-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Tom Moulder
Sent: Thursday, December 21, 2006 10:16 AM
To: [login to unmask email]
Subject: Re: [DB2-L] V7 on z/OS - XRC, BSDS and Logs

Adam

I'm going to start and the end and work back. Perhaps it will make more
sense to you.

XRC does not control DB2 tasks or URs. XRC is a storage solution that
is implemented with very little or no knowledge of the database. In the
cases I have seen, XRC is used to Asynchronously copy data from one site
to another and typically over longer distances than can be accomplished
with normal channel hardware. The key word in the previous sentence is
"Asynchronously". With XRC configuration, storage will group DASD
volume serial numbers into consistency groups. Then each of these
consistency groups will accumulate I/Os to the primary volumes into a
cache. These I/Os are timestamped so that all I/O can be performed at
the secondary site in the exact time sequence of the primary site. The
key to your issue is determining how long these I/Os will be cached
before SDM (a part of SMS called System Data Mover) send the I/Os to the
secondary site.
Additionally, it will be important to know what volumes are in each
consistency group. I would think that you should have all volumes for a
DB2 subsystem in one group. Otherwise, you could have BSDS and log
volumes at one point in time and application data at another point in
time. That could lead to mismatches between LRSN or RBA values through
DB2 data sets.

You should be able to get the secondary DB2 system up and running, but
depending upon your configuration you might have to do a conditional
restart. On second thought, you probably would have to do a conditional
restart. It would seem to me that if your BSDS and logs are not at the
same point in time that would be a major challenge to overcome. If your
application data is at a later time than your BSDS and logs that would
be another major challenge.

Again let me say that I am not an expert and have not been involved in
setting up your system, so I could be way off. If it is set up like I
have seen elsewhere, then these are some things to discover that will
probably lead you to understanding what is happening when you try to
bring up DB2.

XRC AFAIK lacks the ability to suspend I/O from z/OS for a short period
of time across multiple volumes. This facility is provided by EMC and
does provide some additional capabilities when dealing with storage
managed copies over long distances. Also, this type of environment is
more easily managed if you have all your DB2 data sets on an exclusive
set of volumes where no other data is allowed and where each DB2
subsystem is segregated from each other.

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

-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On
Behalf Of Adam Baldwin
Sent: Thursday, December 21, 2006 1:10 AM
To: [login to unmask email]
Subject: [DB2-L] V7 on z/OS - XRC, BSDS and Logs

Hi. The other day we ran a DR test in which we tried to bring up one of
our DB2s on another box. We use XRC to manage the remote copying. When
we tried to bring up DB2 on the remote site it failed to start -
abending with a forward read error against the active log. The
checkpoint RBA was definitely within the active log range.

From the XRC documentation and the DB2 DR documentation I can't fully
understand how XRC copes with any inflight work on the live DB2. At the
time of a system crash, XRC will have copies of the BSDS and logs but
these may not be in sync as far as DB2 is concerned.

Can anyone explain, or point me to an explanation of, how XRC controls
inflight DB2 tasks and URs?

Is a conditional restart or cold start always required at the remote
site?

Many thanks.

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


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.25/593 - Release Date:
12/19/2006

------------------------------------------------------------------------
---------
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 contained in this message is intended only for the recipient, and may be a confidential attorney-client communication or may otherwise be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, please be aware that any dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify us by replying to the message and deleting it from your computer. The McGraw-Hill Companies, Inc. reserves the right, subject to applicable local law, to monitor and review the content of any electronic message or information sent to or from McGraw-Hill employee e-mail addresses without informing the sender or recipient of the message.
--------------------------------------------------------

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

Adam Baldwin

Re: V7 on z/OS - XRC, BSDS and Logs
(in response to Amit Agarwal)
Thanks Tom and Amit. We have tested our system various times and have only
hada problem once. What worries me is that, as Tom says, XRC works at the
physical volume level. Even with BSDS and LOGS and all other subsystem
files grouped into one consitstency group it seems to me that once could
still encounter problems. My understanding of logging - please feel free
to correct me feloow listers - is that physical writes to logs and BSDS do
not always happen at the same time. Therefore a DR solution based on
physical timestamps has a basic flaw. It seems to me that if the primary
DB2 typically has a lot of long running URs one could very easily have
problems with bringing up DB2 on the secondary (DR) site.

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

Mark McCormack

V7 on z/OS - XRC, BSDS and Logs
(in response to Adam Baldwin)
Adam,

We also use EMC's ASRDF. We perform normal DB2 restart at the DR site,
and DB2 performs normal rollback on inflight URs. We have never needed
to perform conditional restart or cold start in a DR drill. It is
essential that the dasd for the whole DB2 subsystem (DB2 catalog and
directory, BSDS, logs, appl data and indices, ICF catalogs, etc.) be in
the same consistency group.

Mark

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

Sysdba AHE

Re: V7 on z/OS - XRC, BSDS and Logs
(in response to Mark McCormack)
Adam,

Our DR is also based on XRC, with everything in a single consistency
group, and it works just as if there had been a power failure at the
primary site.

If there was any inherent issue around pending writes to the log, BSDS or
pagesets then you would have problems bringing DB2 up after a power
failure.

Hope this helps, and Merry Christmas.

Neil Price
TNT Express, UK





Adam Baldwin <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
22/12/2006 07:03
Please respond to DB2 Database Discussion list at IDUG

To: [login to unmask email]
cc:
Subject: Re: [DB2-L] V7 on z/OS - XRC, BSDS and Logs


Thanks Tom and Amit. We have tested our system various times and have only
hada problem once. What worries me is that, as Tom says, XRC works at the
physical volume level. Even with BSDS and LOGS and all other subsystem
files grouped into one consitstency group it seems to me that once could
still encounter problems. My understanding of logging - please feel free
to correct me feloow listers - is that physical writes to logs and BSDS do
not always happen at the same time. Therefore a DR solution based on
physical timestamps has a basic flaw. It seems to me that if the primary
DB2 typically has a lot of long running URs one could very easily have
problems with bringing up DB2 on the secondary (DR) site.

---------------------------------------------------------------------------------
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 message and any attachment are confidential and may be privileged or otherwise protected from disclosure.
If you are not the intended recipient, please telephone or email the sender and delete this message and any attachment from your system.
If you are not the intended recipient you must not copy this message or attachment or disclose the contents to any other person.
---------------------------------------------------------------------------------------------------------------

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