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.
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. By default, the change tracking file is created as an Oracle managed file in DB_CREATE_FILE_DEST. You can also specify the name of the block change tracking file, placing it in any location you choose.
SQL> SELECT status FROM v$block_change_tracking;
STATUS
----------
DISABLED
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string
SQL> alter system set db_create_file_dest='+DATA' scope=both;
System altered.
(or) If DB on windows
SQL> alter system set db_create_file_dest='C:\ORACLE\DB1\CHANGETRACKING\BLOCKCHANGE.F' scope=both;
System altered.
(or) If DB on Non-ASM
SQL> alter system set db_create_file_dest='/u01/app/oracle/db1/oradata/changetracking/blockchange.f' scope=both;
System altered.
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string +DATA
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
Database altered.
SQL> SELECT status FROM v$block_change_tracking;
STATUS
----------
ENABLED
SQL> select * from v$block_change_tracking;
STATUS FILENAME BYTES
----------------------------------------------------------------------------------------------------
ENABLED +DATA/DB1/changetracking/ctf.427.741526883 22085632
(OR)
we can enable the BCT using USING keyword as follows:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/app/oracle/db1/oradata/changetracking/blockchange.f';
Now that we have enabled block change tracking a new background process called CTWR (change track writer) is started and it will automatically be started for every new instance.
CTWR will track addresses of blocks which have changed since the last backup in the change tracking file from now on.
RMAN can use this information for the next incremental backup. It will be able to find out which block must be written to the backupset by just reading the change tracking file.
RMAN will not have to read the entire datafiles into the SGA in order to find out which blocks must be backed up as it had to do before 10g.
This methode is much faster.
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.
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. By default, the change tracking file is created as an Oracle managed file in DB_CREATE_FILE_DEST. You can also specify the name of the block change tracking file, placing it in any location you choose.
SQL> SELECT status FROM v$block_change_tracking;
STATUS
----------
DISABLED
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string
SQL> alter system set db_create_file_dest='+DATA' scope=both;
System altered.
(or) If DB on windows
SQL> alter system set db_create_file_dest='C:\ORACLE\DB1\CHANGETRACKING\BLOCKCHANGE.F' scope=both;
System altered.
(or) If DB on Non-ASM
SQL> alter system set db_create_file_dest='/u01/app/oracle/db1/oradata/changetracking/blockchange.f' scope=both;
System altered.
SQL> show parameter db_create_file_dest
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_create_file_dest string +DATA
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;
Database altered.
SQL> SELECT status FROM v$block_change_tracking;
STATUS
----------
ENABLED
SQL> select * from v$block_change_tracking;
STATUS FILENAME BYTES
----------------------------------------------------------------------------------------------------
ENABLED +DATA/DB1/changetracking/ctf.427.741526883 22085632
(OR)
we can enable the BCT using USING keyword as follows:
SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/u01/app/oracle/db1/oradata/changetracking/blockchange.f';
Now that we have enabled block change tracking a new background process called CTWR (change track writer) is started and it will automatically be started for every new instance.
CTWR will track addresses of blocks which have changed since the last backup in the change tracking file from now on.
RMAN can use this information for the next incremental backup. It will be able to find out which block must be written to the backupset by just reading the change tracking file.
RMAN will not have to read the entire datafiles into the SGA in order to find out which blocks must be backed up as it had to do before 10g.
This methode is much faster.
No comments:
Post a Comment