cancel
Showing results for 
Search instead for 
Did you mean: 

Rman / image cleanup

Doctorski
Level 5

Hi,

      NBU 8.1 RHEL7

Is there a way to get RMAN to use the -notimmediate switch on bpexpdate when cleaning up images ?

We have migrated all our tape based backups to disk and now when RMAN does a tidy up, we get an image cleanup for each image that is expired.

This can take some minutes to do for each image and has drastically increased the run times of the RMAN backups.

When the images were on tape, there was no -notimmediate needed.

Thanks - Darren

6 REPLIES 6

Nicolai
Moderator
Moderator
Partner    VIP   

Workaround more than answer to question:

Do you follow the recommendation about RMAN pice names ?

https://www.veritas.com/support/en_US/article.100028185.html

Not following the rman piece names recommendation will increase the image search time a lot and that will hit you extra hard when doing image clean. Also ensure the rman recover catalog has good respond times.

Hi Nicolai,

                 Yes we are following that recommendation.

All our formats end in _%t.

Thanks.

 

Also catalog is responsive after recent migration to new hardware / storage.

Nicolai
Moderator
Moderator
Partner    VIP   

Seeing a image clean per RMAN image, is the result of RMAN filesperset is configured to 1. It is considered best pratice to use filesperset=1 when using disk because it provide the best dedupe degree. 

Typical when using tape for RMAN backup, RMAN filesperset is either default or set very high, becuase you want to avoid tape unmounts. This also mean Netbackup can clean large amount of data in on image clean.

It could be what you are seeing is a "work as expected" behaviour.

Another hint - the recovery catalog need to be in good shape with good respond times. If the recovercatalog somehow is misbehaving, you will see a mountain of status code 54 - especially when running archives.

Hi Nicolai,

                 Really not a big fan of FILESPERSET=1 here, as we would get hundreds of images per database backup, and this leads to greater catalog growth. We prefer to have a few larger streams depending on database size.

Our dedupe rates are still in the mid-high 90% bracket for the databases themselves. Archive logs dont dedupe well so they go to advanced disk, meaning we dont chew up lots of valuable dedupe space.

Currently looking at revamping how the archive log backups are triggered, as we have too many small backups, and want fewer larger backups.

Working with DBA's to start to use thresholds on the archive log file systems, including logic for ASM file systems

Thanks for your comments tho :)

Nicolai
Moderator
Moderator
Partner    VIP   

Archive batch size is for sure something you want to care about, worst case if archiving for every 2GB and want to restore 300GB, will result in 150 restore jobs, where each job need to be job processed in Netbackup.

The counter argument from the DBA, will be protecting the archive log as quickly as possible, but Netbackup is not the tool for that. Mirror volumes or file replication is the right tool. Also - you want to have a good amount of archive on the system so media recovery can be performed without restoring archive files.