You are commenting using your Twitter account. You are commenting using your Facebook account. Notify me of new comments via email. Notify me of new posts via email. This site uses Akismet to reduce spam. Learn how your comment data is processed. During backups Rman uses the log file to identify the specific blocks that must be backed up. It improves the Rman performance as it is not scan whole datafiles instead of read the changed blocks and take backups. Enable Block Change Tracking.
Leave a Reply Cancel reply Your email address will not be published. This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish.
So as RMAN checks all data blocks and writes down only changed ones during incremental backup, it takes more time for the checking procedure. This tracks the changes made to the data blocks as redo is generated and stores their addresses to the special tracking file. When incremental backups are done, RMAN uses the tracking file and backs up only those data blocks that are written in this file, thus making incremental backups much faster, and it does not scan the unchanged data blocks.
This feature is disabled by default. Only one tracking file is used for one database. In practice, you would schedule the example script to run once each day, possibly at midnight.
On a typical night that is, after the first two nights , when the script completed the following files would be available for a point-in-time recovery:. An image copy of the database, as of the checkpoint SCN of the preceding run of the script, 24 hours earlier. Archived redo logs including all changes between the checkpoint SCN of the image copy and the current time. If, at some point during the following 24 hours, you need to restore and recover your database from this backup, for either complete or point-in-time recovery, you can restore the datafiles from the incrementally updated datafile copies, and apply changes from the most recent incremental level 1 and the redo logs to reach the desired SCN.
At most, you will have 24 hours of redo to apply, which limits how long point-in-time recovery will take. The basic example can be extended to provide fast recoverability to a window greater than 24 hours. WITH TAG to perform incomplete recovery of the datafile copies to the point in time in the past where you want your window of recoverability to begin.
This example shows how to maintain a seven day window:. As with the basic example, you have fast recoverability to any point in time between the SCN of the datafile copies and the present, using block changes from the incremental backups and individual changes from the redo logs. Because you have the daily level 1 incrementals, you still never need to apply more than one day of redo. RMAN's change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a change tracking file.
If change tracking is enabled, RMAN uses the change tracking file to identify changed blocks for incremental backup, thus avoiding the need to scan every block in the datafile. After enabling change tracking, the first level 0 incremental backup still has to scan the entire datafile, as the change tracking file does not yet reflect the status of the blocks.
Subsequent incremental backup that use this level 0 as parent will take advantage of the change tracking file. Using change tracking in no way changes the commands used to perform incremental backups, and the change tracking files themselves generally require little maintenance after initial configuration. Change tracking is disabled by default, because it does introduce some minimal performance overhead on your database during normal operations. However, the benefits of avoiding full datafile scans during backup are considerable, especially if only a small percentage of data blocks are changed between backups.
If your backup strategy involves incremental backups, then you should enable change tracking. One change tracking file is created for the whole database.
You can also specify the name of the block change tracking file, placing it in any location you choose. Oracle saves enough change-tracking information to enable incremental backups to be taken using any of the 8 most recent incremental backups as its parent.
Although RMAN does not support backup and recovery of the change-tracking file itself, if the whole database or a subset needs to be restored and recovered, then recovery has no user-visible effect on change tracking. After the restore and recovery, the change tracking file is cleared, and starts recording block changes again. The next incremental backup after any recovery is able to use change-tracking data.
You can enable or disable change tracking when the database is either open or mounted. Then issue the following SQL statement to enable change tracking:.
You can also create the change tracking file in a location you choose yourself, using the following SQL statement:.
0コメント