John, I know that fro RMAN tablespaces need not be in hot backup mode. The trick with susspend is quick & dirty way of achieving the same effect as with the cold backup, without bringing the database down. No RMAN involved.
On 01/12/2004 12:44:36 PM, John Kanagaraj wrote: > Mladen/Hemant, > > >>I should have expressed myself more clearly. Suspend is not necessary, > >>it's only fast. Basically, with suspend, you don't put tablespaces into > backup mode. You > >suspend, resync, split and start aonther instance as if it crashed. As no > I/O is > >going to disk, datafiles aren't fuzzy, so no recovery is needed. Problem > with this approach > >is that the original instance is not usable during this time. All sessions > are hanging. > >Benefit is that no recovery is needed and if everything goes OK, you're > done very, very > >quickly. It's either-or approach, not a combination. > > I think there is some confusion here... AFAIU (As Far As I Understand!), > > (a) A tablespace, and thus related datafiles, need to be in "Hot backup" > mode during an *OS* based backup to cater for split-block inconsistency > (i.e. to cater for the possibility of a generally shorter OS block read NOT > getting the generally larger whole block in a single read just when the DB > block was being updated). The Logwriter then writes *whole* blocks to redo > to avoid this split-block (aka fractured block) problem. This increased redo > logging becomes an issue when backing up a large database (such as an ERP > database). EMC's BCVs, Hitachi's ShadowImage (and other frozen disk copy > technologies) mitigate this problem by providing a snapshot copy of *almost > point in time* sets of disks that contain a hot backup copy of the database. > Both rely on the fact that the subsequent backup is an *OS* based copy (i.e. > outside of Oracle) and that the *whole* database was placed in Hot backup. > The split actually takes a few minutes (or seconds, depending on how it was > done and the amount of activity), and the whole database is in Hot backup > mode *only* at that time. A SUSPEND may possiblly only _reduce_ this split > time. Once the split completes, the Database is taken out of Hot backup mode > and the BCVs/Images are then presented back tp the OS via normal mount so > that a subsequent OS based backup utility (such as Legato or Netbackup) can > back it up to tape. Subsequent 'snapshots' will also require the DB to be > placed in Hot backup mode.. > In essence, this technology provides for a slow backup of a large database > that is apparently in hot backup mode without having excessive redo being > generated during the physical backup. A positive side effect is that the > Backup I/O goes against currently non-production disks. As well, these > copies can also be mounted on a backup server connected to the same SAN to > even avoid using production CPU cycles... This concept has remained the same > since V7, going into V8/8.1. and 9i as well, and I daresay it is the same in > 10g. The key point is that placing the complete DB in Hot backup mode is a > *requirement* before a BCV/Image split, regardless of the usage of SUSPEND > (and the assumption that I/O is not going to disk at this time). > > (b) OTOH, RMAN reads a database file and the blocks therein directly, and > does not need the tablespace to be in backup mode since the DB block is > being read by an *Oracle* process. And since there is no need to place a > database in backup mode, one can use RMAN to backup a large database without > worrying about the excessive redo issue. *However*, since the Oracle process > can read only from a 'live' datafile, RMAN _cannot_ be used with > BCV/ShadowImage. And placing an RMAN backed-up DB in SUSPEND mode will only > aggravate users :) > > John Kanagaraj > DB Soft Inc > Phone: 408-970-7002 (W) > > Listen to great, commercial-free christian music 24x7x365 at > http://www.klove.com > > ** The opinions and facts contained in this message are entirely mine and do > not reflect those of my employer or customers ** > > >-----Original Message----- > >From: Hemant K Chitale [mailto:[EMAIL PROTECTED] > >Sent: Saturday, January 10, 2004 6:34 AM > >To: Multiple recipients of list ORACLE-L > >Subject: Re: re BCV / SnapShot / SnapClone and the ALTER SYSTEM > > > > > > > >Yes, I hadn't read the line > >"so the tablespaces had to be put into backup mode or (8i and > >after) the > >database had to be suspended" > >you _do_ have an OR between the backup mode and the database > >.. suspended. > > > >We hadn't heard of anyone using the SUSPEND and didn't want to > >take the chance > >of a database "seeming to be frozen" for a few seconds or upto > >a minute > >{weren't sure > >how long the split would actually take to run before we > >implemented it}. > >We'll stick to putting the tablespaces in BACKUP mode. > > > >Hemant > > > >At 09:34 PM 09-01-04 -0800, you wrote: > >>I should have expressed myself more clearly. Suspend is not > >necessary, > >>it's only fast. Basically, > >>with suspend, you don't put tablespaces into backup mode. You > >suspend, > >>resync, split > >>and start aonther instance as if it crashed. As no I/O is > >going to disk, > >>datafiles aren't > >>fuzzy, so no recovery is needed. Problem with this approach > >is that the > >>original instance > >>is not usable during this time. All sessions are hanging. > >Benefit is that > >>no recovery is > >>needed and if everything goes OK, you're done very, very > >quickly. It's > >>either-or approach, > >>not a combination. > >> > >> > >>On 2004.01.10 00:09, Hemant K Chitale wrote: > >> > > >> > Mladen, > >> > Is the "ALTER SYSTEM SUSPEND" really necessary. > >> > > >> > We've just implemented SnapClone mechanims for three Oracle DBs on > >> > Hitachi and EMC SANs, We've been told that only ALTER > >TABLESPACE ... > >> BEGIN > >> > BACKUP > >> > is necessary. > >> > What we do is > >> > 1. Issue an ALTER TABLESPACE ... BEGIN BACKUP for all the > >tablespaces > >> > 2. "split" the image for the /oradata? filesystems > >> > 3. Issue an ALTER SYSTEM ARCHIVELOG CURRENT {and also > >ALTER DATABASE > >> > BACKUP CONTROLFILE TO ..} > >> > 4. "split" the image for the /archlogs filesystem {for > >the archivelogs > >> and > >> > the controlfile backup} > >> > 5. Backup the split /oradata? and /archlogs filesystems > >> > 6. ReSynch > >> > > >> > > >> > At 07:24 PM 09-01-04 -0800, you wrote: > >> > >Let me explain, because I have a little bit of experience with it. > >> > >a) BCV's are replicated disks which are synchronized > >using TimeFinder. > >> > > and then separated from the source. The phrase > >"splitting BCV's" > >> means > >> > > producing an exact disk copy of the original disks, > >similarly to > >> what > >> > > dd can > >> > > do. It's an ideal way to make a copy of an instance. > > Last time I > >> > > checked, > >> > > BCV's weren't supported by RMAN (it may have changed > >now), so the > >> > > tablespaces had to be put into backup mode or (8i > >and after) the > >> database > >> > > had to be suspended (very litle known trick is "ALTER SYSTEM > >> SUSPEND", > >> > > which abruptly ceases all the I/O in the database, > >without shutting > >> > > it down). > >> > >b) RMAN is an oracle tool which works in conjunction with > >Legato (EMC), > >> > >NetBackup(Veritas), > >> > > Tivoli, Alexandria or SyncSort backups. RMAN doesn't > >know how to > >> > > write to tape and needs > >> > > a 3rd party backup to do so. The part that > >Veritas, Legato or IBM > >> > > will charge you for is > >> > > called libobk.so and is an interface which enables > >RMAN to work > >> with > >> > > their particular tool. > >> > > RMAN is a very good tool which can do many things > >in a very easy > >> way > >> > > and without > >> > > generating a TB of redo archives for the duration of > >hot backup > >> mode. > >> > > Robert Freeman's > >> > > book is definitely the best source for anything RMAN around. > >> > > > >> > > >> > Hemant K Chitale > >> > Oracle 9i Database Administrator Certified Professional > >> > http://hkchital.tripod.com {last updated 05-Jan-04} > >> > > >> > > >> > -- > >> > Please see the official ORACLE-L FAQ: http://www.orafaq.net > >> > -- > >> > Author: Hemant K Chitale > >> > 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). > >> > > >> > >>-- > >>Mladen Gogala > >>Oracle DBA > >>-- > >>Please see the official ORACLE-L FAQ: http://www.orafaq.net > >>-- > >>Author: Mladen Gogala > >> 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). > > > >Hemant K Chitale > >Oracle 9i Database Administrator Certified Professional > >http://hkchital.tripod.com {last updated 05-Jan-04} > > > > > >-- > >Please see the official ORACLE-L FAQ: http://www.orafaq.net > >-- > >Author: Hemant K Chitale > > 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). > > > -- > Please see the official ORACLE-L FAQ: http://www.orafaq.net > -- > Author: John Kanagaraj > 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). > -- Mladen Gogala Oracle DBA -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Mladen Gogala 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).
