Link to home
Start Free TrialLog in
Avatar of ballioballi
ballioballi

asked on

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?
ASKER CERTIFIED SOLUTION
Avatar of mrjoltcola
mrjoltcola
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of ballioballi
ballioballi

ASKER

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.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial

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??
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.

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.


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.

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.

thanks
mjc