Block change Tracking in RMAN

This is a general question as we are going to enable block change tracking.
Is there any performance degradation on enabling it. Is someone faced some issues?

Is it a wise idea to enable it or we should not do it in Production?
Who is Participating?
mrjoltcolaConnect With a Mentor Commented:
Very minor overhead, Oracle recommends enabling it for large backups. The overhead will be worth if when your incrementals work much faster.

Do it in development first to get comfortable. I have not had any problems with it.

The good part is it only requires about 10mb of tablespace unless you are in the terabyte range, plus it does not grow based on transaction volume necessarily, it grows based on breadth of changes to your data.

Also it is an Enterprise feature, only.
ballioballiAuthor Commented:
its use is only for Incremental backups??

what if we do the level 0 backup daily and the backup size is 250 GB
Please advice me.
mrjoltcolaConnect With a Mentor Commented:
Since level 0 is full backup, RMAN will backup all used blocks, so there is no "change tracking".

BCT wont save you any time on level 0, but it allows your LEVEL 1 INCREMENTAL to be very fast.

For a 250GB database, it will likely be only < 10mb file.

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

mrjoltcolaConnect With a Mentor Commented:
Also be aware, BCT has a sliding window of 7 versions of history for tracking changes for a block, so your backup policy must employ LEVEL 0 every 8th _backup_ for BCT to be useful for incrementals against the last LEVEL 0.

ballioballiAuthor Commented:

I created a file for incremental backup and NOT started the incremental backup yet.

We are only doing the daily full backup level 0 and we are facing some IO problem  in our dev environment.

It takes longer time for RMAN backup and the simple queries takes longer time when Backup runs.

How can we take over this IO issues??
ballioballiAuthor Commented:
Just to mention that I user the following systax for creating file:-

alter database enable block change tracking using file '/oracle/app/oradata/devon/block.dbf';

It creates the file at the location but the IO is significant when RMAN full backup runs on a daily basis.
What does your RMAN backup script look like? Are you using high levels of parallelism / multiple channels? Are your files properly balanced across mount points or a RAID volume?

RMAN will do full scan of all of your datafiles when doing a LEVEL 0 or FULL, so there will be more IO, however, I need to see how your files are organized and how the RMAN script is written. It is possible to use too much parallelism for RMAN and degrade performance.

ballioballiAuthor Commented:
Files are organised in 10 different mount points.
RAID 5 SAN storage.

RMAN script uses 4 channel.  There is no parallism word in the script.

Please let me know if I answered your questions.

Thanks for taking time for understaning the issues on my subject.I appreciate your attentio and help.

Since you are using 4 channels, RMAN is using 4 server processes to backup, which can cause a lot of IO and affect users while the backup is running. You should experiment by trying 1 channel, then 2 channels, as this is probably one reason why RMAN is taking so much of the server resources.

ballioballiAuthor Commented:
Great help and I will try to implement this solution and let you know the results.

One thing we changed is that we requested the Storage team to add space and they added and now they reported that they added 500GB of SAN space which is on RAID 10. Earlier we had RAID 5. so now we have mix and match of RAID's ........10 and 5. Is it make some Performance diff.  but they are telling it has nothing to do with Performance and IO degradation.

Please comment on this also.
This is hard to say, since I cannot see your layout, how many hbas, volumes, luns you have.

Your storage team is probably right. Did they give you new volumes that are on RAID10? If so, that should improve your IO, not hurt it. RAID10 will perform better for writes than RAID5, but that is not really the issue.

It sounds like your database performs ok except during RMAN backup, correct? How long is the window of degradation?

The number of channels you allocate with RMAN must factor in how many CPUs you have, how many devices you have to read from in parallel, how much WRITE bandwidth you have to the backup destination, and how much user degradation you can afford. In this case, it sounds like you have allocated too much to RMAN, but it could also be that the disk/volume that RMAN is writing the backupsets TO is IO bound. It may not be IO at all, it could be CPUs. How many cpus do you have? What does cpu utilization look like during the RMAN backup?

You may need to look at your flash recovery area location (db_recovery_file_dest) and see if that is the bottleneck. It does not matter how many readers you have, if all of them are bottlenecking into a single, slow flash recovery area, then you need to tune that by moving it to a volume spread across more devices/luns. The flash recovery area should be on different IO channels / luns than your data.

ballioballiAuthor Commented:
1. Not using flash back
2. 16 CPU
3. 32 GB of RAM
4. Looks like we have much IO problems when the backup runs and some less issues when backup stops. (we started monitoring after enabling Block change as it increased the backup timing and also the normal database behaves slow)
5. I am not sure about the hba and luns.
6. The storage team does not mentioned the separate mount points on RAID 10 as looks like they increased the space overall on all the mount points(including existing and they made only 1 new mount point which is on RAID 10..they now disclosed it that it is on RAID10))

I am thinking that it is due to the RMAN block change and we are NOT doing the incremental backup and doing the same old daily level 0 backup.
shall we disable the block change tracking and watch the improvement?(for our satisfaction that it is not due to Block change)??

>>1. Not using flash back

I did not say flash back, I said flash recovery area. Where are your RMAN backups going? Perhaps it is best just to paste your RMAN script here?

>>2. 16 CPU
>>3. 32 GB of RAM

Not a CPU problem then.

>>4. Looks like we have much IO problems when the backup runs and some less issues when >>backup stops. (we started monitoring after enabling Block change as it increased the backup >>timing and also the normal database behaves slow)

As I said before, block change tracking is used for incrementals, so in order to see the benefit, you need to do LEVEL 1 incrementals on your daily backup, not LEVEL 0. BCT is used to track changes since the last LEVEL 0. If you do daily LEVEL 0, then BCT is not helping you.

Please post your RMAN script.
a3, I recommend my 1st 3 comments as solution. The rest of the discussion is relevant but tangential, and the original question was adequately answered.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.