Re: Tuning RMAN backup and recovery
- From: "Limin Guo" <lguo.oracle@xxxxxxxxx>
- To: "Oracle-L Freelists" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 16 Nov 2007 17:43:15 -0500
Brandon and Robert:
Very interesting to know that it actually save time for you to use
RMAN compression than not use it.
Do you use different CONFIGURE when using compression? like channels ,
parallelization, etc.
I have just run another test in a Solaris test box (Solaris 8 with 4
processors, Oracle 10.2.0.3). The results are consistent with my last
post. The database is 15g, the regular backupsets are 14g and
compressed backupsets are 2.4g. The backup time with compression on
takes over twice as long.
The backupsets are written to a RAID5 volume with ADA disks in
Clariion storage. All Oracle datafiles sit on RAID5 volume with
fiber-channel disks in the same storage, but different tray. So there
should be no competing I/O between them, I hope.
The backup script performs a level 0 backup and then restore the
backupsets for validating purpose. Here are the time results:
without compression with compression
backup 13 min 33min
restore validate 13 min 26min
During both tests, I monitored machine with sar (interval of 5
seconds), there are no noticeable differences between compressed one
and non-compressed one. On average:
user 25 - 40%
sys single digit
wio 10 - 25%
If I am CPU bounced, I should see high user% during compressed rman
backup, shouldn't I? but I did not. however I do see little high user%
in restore validate process in non-compressed mode. If I am I/O
bounced, I should see the backup without compression takes longer
time, am I right?
The rman commands used for the testing:
set $ENABLE_ENCRYPTION;
crosscheck archivelog all;
delete noprompt obsolete;
backup $AS_COMPRESSED $BKUP_LEVEL database;
delete noprompt obsolete;
set $ENABLE_DECRYPTION;
restore validate database;
restore validate spfile to 'restore_spfile.ora';
restore validate controlfile to 'restore_control01.ctl';
report unrecoverable;
All variables are substituted during run time. BKUP_LEVEL is 0.
The CONFIGURE in the database.
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION ON;
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1;
CONFIGURE MAXSETSIZE TO UNLIMITED;
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/vw01/app/oracle/product/10.2.0/Db_1/dbs/snapcf_NSTPS.f'; # default
The hardware information:
System Configuration: Sun Microsystems sun4u Sun Fire V440
System clock frequency: 183 MHZ
Memory size: 20GB
==================================== CPUs ====================================
E$ CPU CPU Temperature Fan
CPU Freq Size Impl. Mask Die Ambient Speed Unit
--- -------- ---------- ------ ---- -------- -------- ----- ----
0 1281 MHz 1MB US-IIIi 2.4 - -
1 1281 MHz 1MB US-IIIi 2.4 - -
2 1281 MHz 1MB US-IIIi 2.4 - -
3 1281 MHz 1MB US-IIIi 2.4 - -
================================= IO Devices =================================
I am going to dig into it more and see why I don't see what you guys have seen.
Thank you for sharing your information.
Limin.
On Nov 16, 2007 10:36 AM, Allen, Brandon <Brandon.Allen@xxxxxxxxxxx> wrote:
> That has not been my finding with 10.2.0.2 on AIX 5.3.
>
> My backups to Netbackup (disk staging pool, not straight to tape) are
> actually *faster* with compression on. I'm backing up about 250GB worth
> of datafiles and without compression, the backup is only slightly
> smaller than the database itself and runs in about 4.5 hours, but with
> compression the backup only 36GB and completes in only 2.5 hours. I've
> seen this result consistently for a few months now after switching back
> and forth between compressed and non-compressed. I still have to do
> more testing to do on the restore side, but so far it looks like
> restores of the compressed backupsets may take signifcantly longer than
> restores of the non-compressed backupsets - maybe twice as long.
>
>
> -----Original Message-----
> From: oracle-l-bounce@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Limin Guo
>
>
> I guess that it is a known issue of compression performance with RMAN in
> 10.1 and 10.2.
>
> When compression is enabled (no parallelism), RMAN backup takes about 5
> times longer
>
> 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.
>
>
--
Regards,
Limin Guo.
--
//www.freelists.org/webpage/oracle-l
Other related posts:
