Re: Production DB Crash Recovery process - Some immediate advice ASAP pls
- From: LiShan Cheng <exriscer@xxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Sun, 12 Feb 2006 11:51:19 +0100
I am interested how did you put file 1 offline and opened the database. File
1 should be system tablespace, I dont think that can be offlined ever?
On 2/12/06, VIVEK_SHARMA <VIVEK_SHARMA@xxxxxxxxxxx> wrote:
>
>
> 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:
