RE: Production DB Crash Recovery process - Some immediate advice ASAP pls
- From: "VIVEK_SHARMA" <VIVEK_SHARMA@xxxxxxxxxxx>
- To: "Hemant K Chitale" <hkchital@xxxxxxxxxxxxxx>, <jeremiah@xxxxxxxxxxx>
- Date: Sun, 12 Feb 2006 12:40:06 +0530
DATABASE is UP & OPEN Hemant, Jeremiah.
Thanks indeed for all the Support
It was a Case of 1 Datafile NOT being in sync with the rest of Database.
This had been added after the Last HOT backup(being used in recovery).
This File was made OFFLINE & DB was opened on completion of recovery.
Thanks again Folks for responding ever so quickly.
Good Wishes
Vivek
P.S. Hemant, if you in SG? I am in Bangalore & can meet, if you come by
sometime. Jeremiah, I assume is in Seattle but nevertheless very welcome
to come to Bangalore.
-----Original Message-----
From: Hemant K Chitale [mailto:hkchital@xxxxxxxxxxxxxx]
Sent: Sunday, February 12, 2006 12:03 PM
To: VIVEK_SHARMA; Oracle-L
Subject: RE: Production DB Crash Recovery process - Some immediate
advice ASAP pls
A) If this was an online backup and you are attempting to recover the
whole database
AND the *last* END BACKUP in that backup set was *after* 6pm of 11-Feb,
then Oracle would still want recovery.
B) If you are using the *current* controlfile or any controlfile whose
timestamp
is *after* 6pm of 11-Feb, then Oracle would still want recovery.
C) If any of the datafiles on disk that you are applying recovery to is
*after* 6pm of 11-Feb,
then Oracle would still want recovery.
If you've received ORA-1194 when attempting to OPEN, that doesn't mean
that
you cannot continue with that backup.
1. Identify the actual datafiles that you need in that backup set.
2. RECREATE the Controlfile (with a CREATE CONTROLFILE sql -- even if
generated
from the current image of the controfile, you can exclude the newer
files
(ie those *after* 6pm of 11-Feb)
from the script.
3. Use RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL
4. Issue CANCEL at the last ArchiveLog you want to apply
5. Issue an ALTER DATABASE OPEN RESETLOGS
Note : IF A) or C) above applies to your case, you should be
restoring
from an *OLDER* backup.
Hemant
At 01:34 PM Sunday, VIVEK_SHARMA wrote:
-----Original Message-----
From: Jeremiah Wilton [mailto:jeremiah@xxxxxxxxxxx]
Sent: Sunday, February 12, 2006 11:28 AM
To: VIVEK_SHARMA; 'Oracle-L'
Subject: RE: Production DB Crash Recovery process - Some immediate
advice ASAP pls
Importance: Low
If you are using a backup controlfile, then you should let create the
new
datafiles when it comes to that point in the redologs. You should not
use
the datafiles that are consistent with the CURRENT point in time, if you
are
trying to recover the whole database to a point in time in the PAST.
Do the new datafiles appear in v$datafile?
What do the recovery SCNs look like in v$recover_file? Find the high
SAN
values in this view to find which datafiles are out of sync in the
recovery.
Jeremiah Wilton
ORA-600 Consulting
Recoveries - Seminars - Hiring
http://www.ora-600.net
>Could ORA1194 be due to some Datafiles having being ADDED AFTER the
LAST
>Cold backup of 10 Feb 2006, BUT Before occurrence of the CRASH around 6
>pm on 11 Feb 2006, which continue to exist in the respective
Directories
>during the recovery process?
>
>
>Qs How can we identify these Datafiles which are NOT in sync with the
>rest of the Database files after getting ORA1194 when attempting to
open
>the Databse?
>
>Qs Should we consider removing Such Files, if there, before
>RE-initiating the CANCEL based recovery process again?
>
>Reference is to the following Article:-
>
>http://www.orafaq.com/usenet/comp.databases.oracle.server/2003/08/20/17
6
>0.htm
>
>Thanks indeed
>
Hemant K Chitale
http://web.singnet.com.sg/~hkchital
**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient, please
notify the sender by e-mail and delete the original message. Further, you are
not to copy, disclose, or distribute this e-mail or its contents to any other
person and any such actions are unlawful. This e-mail may contain viruses.
Infosys has taken every reasonable precaution to minimize this risk, but is not
liable for any damage you may sustain as a result of any virus in this e-mail.
You should carry out your own virus checks before opening the e-mail or
attachment. Infosys reserves the right to monitor and review the content of all
messages sent to or from this e-mail address. Messages sent to or from this
e-mail address may be stored on the Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
--
//www.freelists.org/webpage/oracle-l
Other related posts:
