Re: San & single point of failure

  • From: Tim Gorman <tim@xxxxxxxxx>
  • To: mfontana@xxxxxxxxxxx
  • Date: Mon, 17 Nov 2008 16:50:39 -0700

Good point made here by Michael!  If you've got at least one controlfile, you can bring up RMAN and restore/recover everything else, provided you didn't lose it because CONTROLFILE_RECORD_KEEP_TIME was too narrow... ;-)  For this reason, I tend to scatter backup controlfiles all over the place:  on local file-systems, on NFS-mounted file-systems, "scp"d to other servers, etc.

Because, if you don't have any controlfiles at all, you're in for a painful SR with Oracle Support so that they can walk you through the method of restoring backed-up controlfiles using SQL*Plus and PL/SQL to call the DBMS_BACKUP_RESTORE package procedures;  essentially reverse-engineering RMAN.  There used to be notes describing how to do this available on MetaLink, but they removed them; presumably due to the "reverse-engineering RMAN" aspect of things...

The following articles are no longer retrievable by the general public from MetaLink, but (presumably) they are still used internally by Oracle Support (and available if you smile and say "pretty please"):
  • How to extract controlfiles, datafiles, and archived logs from SMR backups without using RMAN (MetaLink note #60545.1)
  • How to Extract the Control file from an RMAN backupset using PL/SQL (MetaLink note #388052.1)
  • How to Extract Datafile(s) from an RMAN backupset Level-0(Full) using PL/SQL (MetaLink note #388053.1)
  • How to Extract Incremental Backups of Datafile(s) from an RMAN Incremental backupset Level-1 or higher using PL/SQL (MetaLink note #388054.1)
  • How to Extract Archivelogs from an RMAN using PL/SQL (MetaLink note #388055.1)
  • How to Restore an RMAN backed up database using PL/SQL (MetaLink note #388057.1)
Some of the longest days (40+ hours) I've ever experienced dealt with recovery problems like these.  I recall a lot of terror intermixed with elation, much of which could have been avoided with just one viable controlfile at hand...

Hope this helps...
Tim Gorman
consultant - Evergreen Database Technologies, Inc.
P.O. Box 630791, Highlands Ranch CO  80163-0791
website   = http://www.EvDBT.com/
email     = Tim@xxxxxxxxx
mobile    = +1-303-885-4526
fax       = +1-303-484-3608
Yahoo IM  = tim_evdbt


Michael Fontana wrote:
I've lost a san and had local controlfiles.

From them I was able to ascertain where the files were so that when the SAN was rebuilt (which in this case it had to be), we knew exactly what directories needed to be restored (which our san admins had no idea - shame on them).  

You could also ascertain, from the controlfiles, what your recovery options are BEFORE restoring from backup, which could save some time.  RMAN should still come up!




-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Allen, Brandon
Sent: Monday, November 17, 2008 3:23 PM
To: rjoralist@xxxxxxxxxxxxxxxxxxxxx; oracle_l
Subject: RE: San & single point of failure

I don't understand what good it does to have the control file alone on your local disk in that situation?  If your SAN with the rest of your database files is toast, then your control file alone isn't going to do you much good.  You're going to have to restore from a backup and do an incomplete recovery anyway, so what's the difference if you do it with your current controlfile still on your local disk, or if you restore a control file from backup along with the rest of the database files you'll be restoring?


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Rich Jesse


Good luck convincing anyone that you NEED two mirrored fast local
drives,
but maybe this will help:

//www.freelists.org/post/oracle-l/Write-cache-for-a-SAN,7


Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do
not consent to Internet email for messages of this kind. Opinions,
conclusions and other information in this message that do not relate to
the official business of this company shall be understood as neither given
nor endorsed by it.
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l




  
-- //www.freelists.org/webpage/oracle-l

Other related posts: