SYSLGRNX, RO tablespaces, and recovery

Donna Domovic

SYSLGRNX, RO tablespaces, and recovery
Hello,

We have several databases which are in a RO status but which the
application owner wants to recover during our disaster recovery exercises.
In order to accomplish this, we've come up with the following 2 options:

1. Image copy the databases one time and run RECOVER TOCOPY during the DR
exercise.
2. Image the database on a weekly basis and run a regular RECOVER (ie to
current).

The question that has come up is how the first option will affect
SYSLGRNX. If the record for the image copy remains in SYSLGRNX (we're
talking about doing this for 4 years), will SYSLGRNX track records for the
entire subsystem which we know can affect recovery or will it just have a
entry for those particular spaces?

Thanks for your assistance with this.

Donna Domovic

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

Mike Bell

Re: SYSLGRNX, RO tablespaces, and recovery
(in response to Donna Domovic)
Either approach will work and you don't have to recover to copy - If the
database is really RO, a normal recover will work just fine - however unless
the databases are big enough to justify special processing, most people just
image copy them just like everything else.

SYSLGRNX is dynamic - the first row is added when some process (person,
program, etc) generates an update to the table. The row is closed (marked
with an end-rba) after a certain period of time passes without updates, (the
period of time depends on checkpoint frequency which is either determined by
number of log records or physical time) I think it is 5 checkpoints without
updates that forces the close but couldn't find it in the manual.

So if the database is really RO, it will have a syscopy entry for image copy
and nothing in SYSLGRNX. Run REPORT RECOVERY to verify this - sometimes RO
means a user logs on and does an update when it is neccessary. A recovery
that asks for a 2 month old archive log at DR doesn't make anyone happy.

Mike
HLS Technologies



-----Original Message-----
From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf
Of Donna Domovic
Sent: Tuesday, January 23, 2007 2:18 PM
To: [login to unmask email]
Subject: [DB2-L] SYSLGRNX, RO tablespaces, and recovery

Hello,

We have several databases which are in a RO status but which the
application owner wants to recover during our disaster recovery exercises.
In order to accomplish this, we've come up with the following 2 options:

1. Image copy the databases one time and run RECOVER TOCOPY during the DR
exercise.
2. Image the database on a weekly basis and run a regular RECOVER (ie to
current).

The question that has come up is how the first option will affect
SYSLGRNX. If the record for the image copy remains in SYSLGRNX (we're
talking about doing this for 4 years), will SYSLGRNX track records for the
entire subsystem which we know can affect recovery or will it just have a
entry for those particular spaces?

Thanks for your assistance with this.

Donna Domovic

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.510 / Virus Database: 307 - Release Date: 8/14/2003


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

Donna Domovic

Re: SYSLGRNX, RO tablespaces, and recovery
(in response to Mike Bell)
Mike,

Thanks for the information.

Donna

---------------------------------------------------------------------------------
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: SYSLGRNX, RO tablespaces, and recovery
(in response to Donna Domovic)
Hi Donna,

It may not be safe to rely on being able to find and/or read the one and
only Image Copy when you need it. My experience has been that tapes aren't
happy to sit around without being accessed for years on end. Also if the
data does not, in fact, remain totally unchanged for 4 years at a time
then your procedures will have to allow for an ad-hoc new DR backup.

I'd agree with Mike Bell that unless the cost is prohibitive I would treat
these tablespaces the same as the rest of the data. In our case that would
be weekly dual offsite copies on a 2-generation cycle, in addition to
onsite backups.

Regards

Neil Price
TNT Express, UK





Donna Domovic <[login to unmask email]>
Sent by: DB2 Data Base Discussion List <[login to unmask email]>
23/01/2007 20:17
Please respond to DB2 Database Discussion list at IDUG

To: [login to unmask email]
cc:
Subject: [DB2-L] SYSLGRNX, RO tablespaces, and recovery


Hello,

We have several databases which are in a RO status but which the
application owner wants to recover during our disaster recovery exercises.
In order to accomplish this, we've come up with the following 2 options:

1. Image copy the databases one time and run RECOVER TOCOPY during the DR
exercise.
2. Image the database on a weekly basis and run a regular RECOVER (ie to
current).

The question that has come up is how the first option will affect
SYSLGRNX. If the record for the image copy remains in SYSLGRNX (we're
talking about doing this for 4 years), will SYSLGRNX track records for the
entire subsystem which we know can affect recovery or will it just have a
entry for those particular spaces?

Thanks for your assistance with this.

Donna Domovic

---------------------------------------------------------------------------------
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.
Please consider the environmental impact before printing this document and its attachment(s). Print black and white and double-sided where possible.
------------------------------------------------------------------------------

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