We use the 'shadow mirror' process on a Hitachi SAN (with Oracle 8.1.7 on Solaris 8 and Veritas VxFS) successfully to refresh our development db without a suspend, or even hot backup mode.
After the hair that I didn't pull out turned gray (though I am not willing to detail the incompetence on a semi-public list), we got the hardware/file system set up correctly and we have done this several times with no trouble. One issue I had with Hitachi support was that they insisted I had to suspend the database at the time of the split when we were seeing data corruption that was clearly unrelated to Oracle behavior. It turned out to be low level misconfiguration, I believe at the Veritas file system level. I never got a satisfactory explanation. Here is my current (possibly inaccurate) understanding of the process. I would be more than happy to be corrected on any of the details. The shadow mirror process is 'atomic' in the sense that there is some kind of journaling so that when the mirror is split, it is done so that the shadow is a copy of the disk at a particular time, so it looks like the disk would look after a crash or a shutdown abort. Oracle crash recovery has worked as advertised, which is sufficient for our development db needs. If we do get a bad mirror, we would be able to resync and resplit quickly. But as I said, we've done this without incident at least 8 or 9 times. The only times we've had to resync and resplit were due to human error. If you are using Shadow mirror, and this is for backup purposes, you may want the extra security of hot backup. But the mirror split should not cause split blocks, so I'm not sure that it would actually do much for you. To be honest, I haven't thought through all the ramifications of using this as a backup method. If you're not using Shadow mirror, but some other mirror method, the above may not apply. Hope this helps. -Chris > -----Original Message----- > From: Hemant K Chitale [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 27, 2003 9:44 AM > To: Multiple recipients of list ORACLE-L > Subject: may not be necessary -- was RE: Oracle DB Backups on SAN with > > > > Jeremiah / Deborah, > > My understanding is/was that the Snapshot creation wasn't > atomic -- it can > take "a little bit of time" > and, therefore, it becomes necessary to suspend I/O. > Now, I haven't had a chance yet to speak to the Sun/Hitachi > engineers and I > am going > by what management has understood and conveyed to me -- that > the database must > be "quiesced". Hopefully, next week, I will be allowed to > speak to the > engineers before > they set up the SAN. > > Reading Oracle's documentation in the Backup and Recovery guide > "Using the Oracle8i SUSPEND/RESUME functionality, you can > suspend I/O to > the database, then split the mirror and make a backup of the > split mirror. > This feature, which complements the hot backup functionality, > allows you to > quiesce the database so that no new I/O can be performed. You > can then > access the suspended database to make backups without I/O > interference. > Note: Some RAID devices benefit from suspending writes while > the split > operation is occurring; your RAID vendor can advise you on > whether your > system would benefit from this feature. > " > and > "After a successful database suspension, you can back up the > database to > disk or break the mirrors. Because suspending a database does > not guarantee > immediate termination of I/O, Oracle recommends that you precede the > SUSPEND statement with a BEGIN BACKUP statement to place the > tablespaces in > hot backup mode. > > You must use conventional operating system backup methods to > back up split > mirrors. RMAN cannot make database backups or copies because these > operations require reading the datafile headers. After the > database backup > is finished or the mirrors are re-silvered, then you can > resume normal > database operations using the RESUME statement. > > Backing up a suspended database without splitting mirrors can > cause an > extended database outage because the database is inaccessible > during this > time. If backups are taken by splitting mirrors, however, > then the outage > is nominal. The outage time depends on the size of cache to > flush, the > number of datafiles, and the time required to break the mirror > " > > I did get the impression that a SUSPEND was necessary. > > However, I have read a Hitachi document at > http://www.hds.com/pdf/ods.pdf > and I think that a SUSPEND is not mandatory. > > I will come back to the list when I get more information from > the Sun/Hitachi > engineers and see the scripts/script-templates that they will > be providing. > > Hemant > > LEGAL NOTICE: Unless expressly stated otherwise, this message is confidential and may be privileged. It is intended for the addressee(s) only. Access to this e-mail by anyone else is unauthorized. If you are not an addressee, any disclosure or copying of the contents or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you are not an addressee, please inform the sender immediately. -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Sarnowski, Chris INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
