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).
