Hi Steve,
We are successfully applying EMC tecnhology (TimeFinder) for offline
backups. The approximate time to do a full estabilish of a 130Gb Oracle =
DB
is around 40 minutes. Incremental synchronization takes much less time, =
and
split (mirroring break) takes less than one minute.
We are also implementing online backup strategies for a 24x7 DB, and
TimeFinder will play a very important role in it. We will be able to =
put
every tablespace in backup mode for less than one minute, reducing redo
logging and archiving needs.=20
It is completely certified by Oracle. For those interested I can send =
some
copies of papers (pdf) on EMC Business Continuance Volumes (BCV) and =
Oracle
online backups.
Regards,
> Clebert Duarte Mattos
> AMERICEL
> I.T. - Administrador de Banco de Dados
> email: cmattos_at_americel.com.br
> Fone: (61) 329 6836
> Cel: (61) 929 0638
> http://www.americel.com.br
>=20
>=20
>=20
> ----- Mensagem original -----
> De: Steve Orr [SMTP:sorr_at_arzoo.com]
> Enviada em: Ter=E7a-feira, 20 de Junho de 2000 14:50
> Para: Multiple recipients of list ORACLE-L
> Assunto: RE: I/O activity during HOT backups
>=20
> > That's why it is recommended to keep the file in the hotbackup mode =
for
> the > shortest possible time.That is one tablespace at a time.
>=20
> Or you can avoid split blocks altogether by using RMAN. It's an =
on-line
> backup vs. the hot backup.
>=20
> Regarding reducing the window for tablespaces in backup mode, has =
anyone
> used EMC's TimeFinder? It's a triple mirror where you toggle all the
> tablespaces into backup mode, break the mirror, and retoggle the
> tablespaces
> out of backup mode. Supposedly this only takes a few seconds. Then =
you
> backup the broken mirror and resilver it. Any ideas as to how long =
the
> resilvering takes? I'm thinking about using this stuff.
>=20
>=20
> Steve Orr
>=20
>=20
>=20
> -----Original Message-----
> Sanjeev
> Sent: Tuesday, June 20, 2000 9:36 AM
> To: Multiple recipients of list ORACLE-L
>=20
>=20
> I fully agree with this explanation expect that the redo increases by
> 100%.
> Redo increase depend on the changes made to the block.When a block is
> copied to the backup and somebody else make a change to a part of =
that
> block
> oracle has to write the complete block again because the block is
> fractured
> and
> oracle cannot construct the entire block in the advent of failure, so
> whenever a
> block gets changed during the hot backup oracle has to write the =
entire
> block to
> keep the consistency of the block. So the redo can be increased by =
100% or
> can be
> by 1000% depending on the type of activity goinig on. That's why it =
is
> recommended
> to keep the file in the hotbackup mode for the shortest possible =
time.That
> is one
> tablespace at a time.
>=20
> Cheers
>=20
> -----Original Message-----
> Sent: Tuesday, June 20, 2000 11:25 AM
> To: Multiple recipients of list ORACLE-L
>=20
>=20
> Well, I will disagree with all of you to a point.
>=20
> When a tablespace is put into hot backup mode with the "begin backup"
> command
> the file headers of all datafiles comprising the tablespace have =
their
> SCN's
> locked (if you want to confirm that, take a very quite DB, alter one
> tablespace
> and take a look at the datafile date/time stamps. They will be =
different
> from
> all other datafiles in the database, very current, and equal to that =
of
> the
> control file.). If you remember the SCN is Oracle's internal clock =
used
> for
> insuring a consistent state within the database. This SCN lock gets
> released &
> the SCN updated to the current one by the "end backup" command. Now
> during
> the
> intervening time period, dbwr continues to write to the file as =
normal,
> but
> the
> use of redo does increase by 100% since both before and after images =
of
> the
> data
> blocks are being saved. Now, depending on what redo files your =
saving it
> may
> well be a good idea to switch logfiles before starting a backup. In =
my
> case
> we
> save all of them for one week longer than we save the datafile =
backups as
> a
> safety net.
>=20
> Now, if you need to restore from this hot backup the locked SCN's =
will
> guarantee
> you an inconsistent database, especially if you follow the Oracle =
book and
> backup the control file LAST (it's SCN never gets locked). This is =
why
> you
> always have to roll a hot backup forward, at least until the datafile
> SCN's
> match that of the control file.
>=20
> Does the IO load on the computer increase, you bet. But if you've =
wisely
> chosen
> the time of your backup or the size of your backplane/io ports it =
should
> not
> be
> noticeable. Anyway, what's the bother. IO loading is a SA problem =
(or so
> my SA
> tells me).
>=20
> Dick Goulet
>=20
> ____________________Reply Separator____________________
> Author: "William Beilstein" <BeilstWH_at_obg.com>
> Date: 6/20/00 5:57 AM
>=20
> The following is a quote from my favorite Oracle reference boot =
titled
> "Oracle
> Unleashed, Edition 2" by SAMS Publishing.
>=20
> When you place a tablespace in backup mode, the Oracle instance notes =
that
> a
> backup is being performed and internally compensates for it. As you =
know,
> it
> is
> impossible to make an authentic copy of a database file that is being
> written
> to. Upon receipt of the command to begin the backup, however, Oracle
> ceases
> to
> make direct changes to the database file. It uses a complex =
combination of
> rollback segments, buffers, redo logs, and archive logs to store the =
data
> until
> the end backup command is received and the database files are brought =
back
> to
> sync. .... What you should understand is that the trade-off for =
taking a
> hot
> backup is increased use of rollback segments, redo logs, archive =
logs, and
> internal buffers within the SGA.
>=20
> You must be running the database in Archive mode to perform a hot =
backup.
> Archive logs assure data consistency when backing up only pieces of a
> database
> at a time.
>=20
> >>> "Eric Lansu" <eric.lansu_at_quicknet.nl> 06/20/00 09:11AM >>>
> Am I wrong, or am I wrong?
>=20
> But as far as I know you have to do a log-switch BEFORE starting the
> HOT-backup, and one AFTER the HOT-backup. The tape containing the
> database-files should also contain the archive-log-files created =
between
> the
> log-switches. This way you can roll-forward (recover) the database to =
the
> point-in-time after completion of the backup, and thus bringing it =
all in
> a
> consistent state. ( yes, yes, not from a book.... )
>=20
> Still the question remains; how can the OS make a copy of a datafile =
if
> Oracle is still writing in it? Better, how does Oracle know what to =
update
> after recovery?
>=20
> Eric Lansu
>=20
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Tuesday, 20 June 2000 11:03
>=20
>=20
> > Wow! your explanation is wonderful.
> >
> > Thanks Rachel.
> >
> >
> > Bhat
> >
> > -----Original Message-----
> > Sent: Tuesday, June 20, 2000 4:19 AM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Lisa,
> >
> > I'm sorry but you are wrong. Writes to the datafiles continue =
during hot
> > backup.....
> >
> > take a hypothetical situation:
> >
> > you have 3 redo logs
> > you have put every tablespace in your database into hot backup mode
> > you do a LARGE dataload (enough to cycle through all your redo logs
> several
> > times)
> >
> >
> > so... if Oracle does NOT write to the datafiles, then the changes =
you
> have
> > been making to the blocks get overwritten in the redo logs after =
the
> logs
> > are archived. Once you take the tablespaces out of backup mode, =
given
> your
> > thinking, Oracle would have to then write all the blocks to the =
database
> > files at once. But where would it get them from? The archived redo =
logs
> are
> > NOT re-read, nor are the redo logs.
> >
> > So...... writing continues to the database files.
> >
> > Rachel
> >
> > >From: Lisa_Koivu_at_gelco.com
> > >Reply-To: ORACLE-L_at_fatcity.com
> > >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > >Subject: Re: I/O activity during HOT backups
> > >Date: Mon, 19 Jun 2000 11:50:37 -0800
> > >
> > >No! The command below stops all writes to the datafiles in the
> tablespace
> > >for
> > >the duration of the backup, to ensure consistency.
> > >
> > >The i/o overload I see during backups is the data being copied out =
to
> our
> > >backup
> > >server. And it is usually very high: like 80% of all current
> activity.
> > >
> > >Lisa
> > >
> > >
> > >
> > >
> > >
> > >Dan.Hubler_at_midata.com on 06/19/2000 01:18:14 PM
> > >
> > >Please respond to ORACLE-L_at_fatcity.com
> > >
> > >To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
> > >cc: (bcc: Lisa Koivu/GELCO)
> > >
> > >
> > >
> > >
> > >
> > >Please settle a discussion amongst our DBA team:
> > >
> > >Is there ANY I/O that takes place to the database files (*.DBF)
> > >during a HOT backup? (That is, ALTER TABLESPACE BEGIN BACKUP).
> > >
> > >If not, how does the process work?
> > >
> > >Thanks.
> > >
> > >
> > >
> > >
> > >???
> > >
> > >also send the HELP command for other information (like =
subscribing).
>=20
> --=20
> Author: Steve Orr
> INET: sorr_at_arzoo.com
>=20
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing =
Lists
> --------------------------------------------------------------------
Received on Tue Jun 20 2000 - 14:38:42 CDT
