I think your reasoning is sound and will work.
Not sure why you would need to kill housekeeping on the prod server; why
not let it continue to run? You'll still want your copypool tapes
created for those 4 days of the audit.
Depending on your total daily volume, and if you have GIGE network
throughput, you might make less work for yourself with:
Restore the DB to the test server
Run the audit on the test server
Take a DB backup on the test server
On the prod server:
Do a server-to-server export FILEDATA=ALL FROMDATE=DB backup date
FROMTIME=DB backup time
Next day
Server-to-server export FILEDATA=ALL FROMDATE=today-1 TODATE=now
Repeat daily until you can get downtime to swap the DB's back
Only reason I can see that wouldn't be easier, is if you have too much
incoming data on the prod side to do the server-to-server export in a
timely manner.
But sometimes server-to-server exports can be faster than exports to
tape. Just depends...
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Loon, EJ van - SPLXM
Sent: Thursday, May 20, 2010 7:08 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Database corruption
Hi TSM-ers!
One of our servers have database corruptions. An audit of a copy of the
production database restored on our test environment revealed them.
Since we do not know the impact of these errors (can all client data be
restored, can I restore all primary volumes in case of a restore
stgpool?) I definitely like to fix these errors.
I ran a AUDITDB ARCHSTORAGE on this server, but that does not fix them,
only a full audit does (I have proven this on the test server).
The problem is that a full audit runs for 60 hours and I cannot afford a
60 hours downtime. Most of our Oracle and SAP clients haven't got enough
achivelog space to survive.
I tried several things to trick TSM like create a snapshot on
production, immediately followed by a full backup, then restore the
snapshot on the test server, perform the full audit on this copy and
than create a full backup on the fixed database. This way both fulls
have the same sequence number, so I was hoping I could then restore the
fixed copy on the production server and apply all incrementals made on
the production server. Bad luck, TSM apparently stores timestamp
information about previous full backups as part of the incremental
backups:
ANR4651E Restore of backup series 1733 operation restore is not in
sequence; backup is part of another log epoch.
Explanation:
During a DSMSERV RESTORE DB, a backup volume was mounted that is not in
the correct sequence. The current backup operation cannot be restored in
this series because it belongs to the same backup series from another
point in time.
Bummer... The only thing I can think of now is making a snapshot copy
and restore it on the test server, perform a full audit here and freeze
ALL housekeeping processes on the production server.
On the production server perform an EXPORT SERVER FILEDATA=ALL
FROMDATE=TODAY-1 FROMTIME=NOW every day at the same time.
As soon as the audit finishes on the test server, create a snapshot and
restore it on the production server and import all export volumes
created.
Am I missing anything or should this work?
Import as well as export are single processes, so performance can be an
issue here...
Thank you very much for your replies in advance!
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
</pre>********************************************************<br>For
information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message.<br><br>Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect
or incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.<br>Koninklijke Luchtvaart
Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered
in Amstelveen, The Netherlands, with registered number 3014286
<br>********************************************************<pre>
|
