RE: RMAN backups

  • From: "Ruth Gramolini" <rgramolini@xxxxxxxxxxxxxxx>
  • To: "Allen, Brandon" <Brandon.Allen@xxxxxxxxxxx>, <jrsmiley@xxxxxxxxx>, <richard.ignizio@xxxxxxxxxx>
  • Date: Tue, 21 Jun 2005 14:24:56 -0400

When I first installed 9.2.0.4 from 8.0.6.3 my backups (of the migrated
databases) went up from 1 to 6 hours (roughly).  Oracle could not tell me
why. However, when I did a complete restore/recovery of the databasess in
question  the backup time went back to about 1 hour.   I have my own ideas
as to why but no definitive answer from Oracle.  You could try to do a
complete restore or duplicate the databases and see if that helps.  YMMV!

Regards,
Ruth

-----Original Message-----
From: Allen, Brandon [mailto:Brandon.Allen@xxxxxxxxxxx]
Sent: Tuesday, June 21, 2005 1:44 PM
To: rgramolini@xxxxxxxxxxxxxxx; jrsmiley@xxxxxxxxx;
richard.ignizio@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: RMAN backups


I think the results I have shown below, although accurate, may be
misleading.  After further analysis I noticed that when we first implemented
incrementals, the backup time was not much shorter than for the full
backups, however something changed in January that made the backup time for
the Full backups rise sharply, while incrementals remained consistent.  I'm
working with my tape library admins to see what may be the cause and will
reply later with my findings.  In the mean time, please do not expect your
backup time to be dramatically reduced by implementing incrementals like I
have shown below - I believe there is some other force at work here besides
just the incremental vs. full difference.  It may be something simple like
the tape library is busy with replication on Thursdays when we run our Full
backups or something like that.

Regards,
Brandon


-----Original Message-----
From: Allen, Brandon
Sent: Tuesday, June 21, 2005 10:17 AM
To: 'rgramolini@xxxxxxxxxxxxxxx'; jrsmiley@xxxxxxxxx;
richard.ignizio@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: RMAN backups


We do save a significant amount of time and space by using incremental
backups:

SQL>select avg(elapsed_seconds)/60/60 from rc_backup_set where db_key=2300
and backup_type='D' and completion_time >= sysdate -45;

AVG(ELAPSED_SECONDS)/60/60
--------------------------
                 3.8742284

SQL>select avg(elapsed_seconds)/60/60 from rc_backup_set where db_key=2300
and backup_type='I' and completion_time >= sysdate -45;

AVG(ELAPSED_SECONDS)/60/60
--------------------------
                1.13801519

Regards,
Brandon


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of Ruth Gramolini
Sent: Tuesday, June 21, 2005 10:05 AM
To: jrsmiley@xxxxxxxxx; richard.ignizio@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: RMAN backups


John,

Unless something has changed with 10g, and incremental backup doesn't
actually save much time.  Rman still has to read the block headers to see if
the block needs to be backed up.  It mostly saves space on disc if backing
up to disk.

Correct me if I am wrong!
Ruth
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On
Behalf Of John Smiley
Sent: Saturday, June 18, 2005 11:19 AM
To: richard.ignizio@xxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: RMAN backups


Backup times with RMAN are going to vary greatly depending upon the hardware
and how many blocks need to be backed up.  Even a very large database can be
backed up incrementally if very few blocks have changed since the last
backup with RMAN.

What might be a better yardstick is backup rate.  The fastest RMAN backup
rate I've seen was published by Amazon a few years back.  They attained 2TB
/ hour.

John Smiley
Technical Management Consultant
TUSC, Inc.

Privileged/Confidential Information may be contained in this message or
attachments hereto. Please advise immediately if you or your employer do not
consent to Internet email for messages of this kind. Opinions, conclusions
and other information in this message that do not relate to the official
business of this company shall be understood as neither given nor endorsed
by it.

--
//www.freelists.org/webpage/oracle-l

Other related posts: