RE: re BCV / SnapShot / SnapClone and the ALTER SYSTEM
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
Re: re BCV / SnapShot / SnapClone and the ALTER SYSTEM
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
RE: re BCV / SnapShot / SnapClone and the ALTER SYSTEM
Mladen, I apologize - I didn't want to imply that you were not aware of the way RMAN works. However, I am not sure I got my point across on the Hot backup issue, so here goes... You should not take a backup of a BCV mirror _without_ putting the whole database in Hot backup, even if you suspend all I/O using SUSPEND. AFAIK, the SUSPEND command was provided to enable an 'instance recoverable' database copy and NOT a day-to-day backup copy. In other words, a copy taken after a successful SUSPEND can be restored and started up, in which case an _instance_ recovery is done. The issue is that you cannot perform _media_ recovery to this copy to bring it up a particular point in time, which is the whole point of a backup... The way I see it, a DBA can use the SUSPEND command to backup a Development/Test database, which would not demand a point-in-time recovery requirement but require a end-of-day backup without having to shut it down. The other use of couse is to reduce or even eliminate IO activity to the BCV while the split occcurs. The split can take quite a while to complete if a session performs heavy writing - a Hash join writing to TEMP can very quickly overwhelme the Write cache of a SAN and delay the split. I found ML Note:91059.1 useful in understanding the SUSPEND command... John Kanagaraj DB Soft Inc Phone: 408-970-7002 (W) Grace - Getting something we do NOT deserve Mercy - NOT getting something we DO deserve Click on 'http://www.needhim.org' for Grace and Mercy that is freely available! ** The opinions and facts contained in this message are entirely mine and do not reflect those of my employer or customers ** -Original Message- From: Mladen Gogala [mailto:[EMAIL PROTECTED] Sent: Monday, January 12, 2004 11:34 AM To: Multiple recipients of list ORACLE-L Subject: Re: re BCV / SnapShot / SnapClone and the ALTER SYSTEM 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. -- 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).
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,
Re: re BCV / SnapShot / SnapClone and the ALTER SYSTEM SUSPEND --
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).
