Re: Tuning RMAN backup and recovery

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_at_oneneck.com> 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_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] 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.
--
http://www.freelists.org/webpage/oracle-l