ADSM-L

Re: [ADSM-L] TSM 6.2.2 unrecoverable DB backup

2011-09-23 11:23:06
Subject: Re: [ADSM-L] TSM 6.2.2 unrecoverable DB backup
From: "Cowen, Richard" <rcowen AT SBSPLANET DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 23 Sep 2011 11:21:34 -0400
Jim,

I would suggest, on the recovery dd, creating the snap and using
fastcopy, and then using the resulting "frozen" data for TSM restores.
Don't forget to expire the snap (or create it with a short life.)
Trying to use data that may be changed by ongoing replication (you
didn't break replication, did you?) is not a good idea.
Plus, as you noticed, the replication target files are not to be opened
for writing, since that could affect the replication integrity.
Are you using a VTL or devtype=file for the library volumes?

Richard

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, Jim
Sent: Thursday, September 22, 2011 4:50 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TSM 6.2.2 unrecoverable DB backup

Richard,

We use a Data Domain 880 for constant replication.
The database backup, devconfig, volhist, and prepare file time stamps
matched the source.
The DD880 file system is mounted as read-only on the server performing
recovery.
I have not used snapshots for access database and storage pool data.

NB: After a successful recovery I update TSM volume access to read-only.
If this is not done then I cannot recovery from any filling volumes.

Jim
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT vm.marist DOT edu] On Behalf Of
Cowen, Richard
Sent: Thursday, September 22, 2011 3:07 PM
To: ADSM-L AT vm.marist DOT edu
Subject: Re: [ADSM-L] TSM 6.2.2 unrecoverable DB backup

Jim,

What method/appliance for replication are you using?
Did the datetime stamp for all 3 files (dbbackup, devconfig, volhist)
match up with the source system?
Did you snap the replicated side to make it read only before attempting
the restore?

Richard Cowen


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, Jim
Sent: Thursday, September 22, 2011 3:06 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] TSM 6.2.2 unrecoverable DB backup

Hello TSMers

AIX 6.1
TSM 6.2.2.0

I have been testing DR recovery using replicated DB backups and storage
pools, recovering to a second TSM instance on a remote server.  I have
found that I cannot restore from every database backup.
 
I ran successful restores on Monday and Wednesday but today's restore
attempt failed.  db2diag messages include

2011-09-22-09.24.36.455938-300 I1562137A367       LEVEL: Warning
PID     : 17105122             TID  : 2111        PROC : db2sysc 0
INSTANCE: tsminst1             NODE : 000
EDUID   : 2111                 EDUNAME: db2logmgr (TSMDB1) 0
FUNCTION: DB2 UDB, data protection services, sqlpgRetrieveLogFile,
probe:4130
MESSAGE : Started retrieve for log file S0000223.LOG.

2011-09-22-09.24.36.456575-300 E1562505A576       LEVEL: Error
PID     : 17105122             TID  : 2111        PROC : db2sysc 0
INSTANCE: tsminst1             NODE : 000
EDUID   : 2111                 EDUNAME: db2logmgr (TSMDB1) 0
FUNCTION: DB2 UDB, data protection services, sqlpgRetrieveLogDisk,
probe:3500
MESSAGE : ZRC=0x860F000A=-2045837302=SQLO_FNEX "File not found."
          DIA8411C A file "S0000223.LOG" could not be found.
DATA #1 : String, 110 bytes
This might mean that end-of-logs has been reached.  Check for other
errors
to verify whether this is the case.

2011-09-22-09.24.36.457229-300 E1563082A434       LEVEL: Warning
PID     : 17105122             TID  : 2111        PROC : db2sysc 0
INSTANCE: tsminst1             NODE : 000
EDUID   : 2111                 EDUNAME: db2logmgr (TSMDB1) 0
FUNCTION: DB2 UDB, data protection services, sqlpgRetrieveLogFile,
probe:4165
MESSAGE : ADM1847W  Failed to retrieve log file "S0000223.LOG" on chain
"12" to 
          "/arclog/recovery/RstDbLog/".

2011-09-22-09.24.36.657930-300 I1563517A561       LEVEL: Error
PID     : 17105122             TID  : 10078       PROC : db2sysc 0
INSTANCE: tsminst1             NODE : 000         DB   : TSMDB1
APPHDL  : 0-37                 APPID: *LOCAL.tsminst1.110922142314
AUTHID  : TSMINST1
EDUID   : 10078                EDUNAME: db2redom (TSMDB1) 0
FUNCTION: DB2 UDB, recovery manager, sqlpPRecReadLog, probe:1275
RETCODE : ZRC=0x071000D7=118489303=SQLP_EXT_NOT_IN_CHAIN
          "This extent is not a successor of the previous extent.  Fwd
Recovery can not continue."

I ran another DB backup, backed up devconfig, volhist, and ran prepare.
After waiting for the data to replicate to the remote site my restore
test was successful.  The error messages I listed did not occur during
the successful restore attempt.  There were no activity log messages
indicating an error during the first (unusable) DB backup.  It appears
that I cannot recover from all of my DB backups and wonder if anybody
else has run across the same situation.

I'm trying to determine if the problem is mine or ours.

With confused and gracious desperation,
Jim Schneider
United Stationers



The information contained in this transmission may contain privileged
and confidential information. 
It is intended only for the use of the person(s) named above. If you are
not the intended  
recipient, you are hereby notified that any review, dissemination,
distribution or  
duplication of this communication is strictly prohibited. If you are not
the intended recipient, 
please contact the sender by reply email and destroy all copies of the
original message. 
To reply to our email administrator directly, please send an email to
postmaster AT sbsplanet DOT com.



The information contained in this transmission may contain privileged and 
confidential information. 
It is intended only for the use of the person(s) named above. If you are not 
the intended  
recipient, you are hereby notified that any review, dissemination, distribution 
or  
duplication of this communication is strictly prohibited. If you are not the 
intended recipient, 
please contact the sender by reply email and destroy all copies of the original 
message. 
To reply to our email administrator directly, please send an email to 
postmaster AT sbsplanet DOT com.