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:hkchital_at_singnet.com.sg]
> >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: hkchital_at_singnet.com.sg
> >> >
> >> > 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: ListGuru_at_fatcity.com (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: mgogala_at_adelphia.net
> >>
> >>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: ListGuru_at_fatcity.com (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: hkchital_at_singnet.com.sg
> >
> >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: ListGuru_at_fatcity.com (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: john.kanagaraj_at_hds.com
>
> 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: ListGuru_at_fatcity.com (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: mladen_at_wangtrading.com
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: ListGuru_at_fatcity.com (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).
Received on Mon Jan 12 2004 - 13:34:26 CST
