Skip to main content

BLOCK TRACKING FEATURE IN RMAN




NOTE: Once enabled; this new 10g feature records the modified since last backup and stores the log of it in a block change tracking file. During backups RMAN uses the log file to identify the specific blocks that must be backed up. This improves RMAN's performance as it does not have to scan whole datafiles to detect changed blocks.

Logging of changed blocks is performed by the CTWR process which is also responsible for writing data to the block change tracking file.

When using Oracle block change tracking we see this procedure.  As data blocks change, the Change Tracking Writer (CTWR) background process tracks the changed blocks in a private area of memory.

When a commit is issued against the data block, the block change tracking information is copied to a shared area in Large Pool called the CTWR buffer. During the checkpoint, the CTWR process writes the information from the CTWR RAM buffer to the change-tracking file.

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.


By default, Oracle will not record block change information.  To enable this feature, you need to issue the following command:

Enable change tracking when the database is either open or mounted. To alter the change tracking setting, perform the following steps:


To store it in the default location:

Set the DB_CREATE_FILE_DEST parameter for the target database.

Issue the following SQL statement to enable Block Change Tracking:

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING;

To store it in a user-defined location, issue the following SQL statement:

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/<Location>/rman_change_track.dat' REUSE;

The REUSE option tells Oracle to overwrite an existing file with the specified name.

Important: In a RAC environment, the change-tracking must be located on shared storage that is accessible from all nodes in the cluster.

The following example stores the Block Change Tracking File in a file located in an ASM File System, which is used for shared storage in a RAC environment.

SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '+DATA/oradata/block_change_tracking.dat' REUSE;

Disable block change tracking:

SELECT filename, status, bytes FROM v$block_change_tracking;


SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING;

Thank You!


Comments

Popular posts from this blog

Registering The Database to RMAN catalog database:

Registering The Database to RMAN catalog database: Need to start RMAN as follows: RMAN target=sys/password@database_to_backup rcvcat=sys/password@recovery_catalog_database Another variation on the command, if the recovery catalog and the database were on the same server, might be as shown: oraenv ORACLE_SID = [KKUY] ? KKUY RMAN rcvcat=sys/password@recovery_catalog_database RMAN> connect target Recovery Manager: Release 8.0.5.1.0 - Production RMAN-06005: connected to target database: KKUY RMAN-06008: connected to recovery catalog database Use the below command to register the database. RMAN>register database; Want to verify if a database is registered in the recovery catalog. To do this, connect to RMAN and issue the command LIST INCARNATION OF DATABASE. RMAN> list incarnation of database; RMAN-03022: compiling command: list RMAN-06240: List of Database Incarnations RMAN-06241: DB Key Inc Key DB Name DB ID      CUR Reset SCN   Reset Time RMAN

ORA-39014: One or more workers have prematurely exited.ORA-00018: maximum number of sessions exceeded

ERROR: I was Performing a full database import and during the import I faced the below error. ORA-39014: One or more workers have prematurely exited. ORA-39029: worker 6 with process name "DW07" prematurely terminated ORA-31672: Worker process DW07 died unexpectedly. Job "SYSTEM"."SYS_IMPORT_FULL_04" stopped due to fatal error at 00:59:40 ORA-39014: One or more workers have prematurely exited. SOLUTION:  Run the import with fewer parallel processes, like PARALLEL=2 instead of 8. I was able to run the import successfully. NOTE 1: This errors occurs when there are less session allocation in the database. check the session,process parameters and increase them accordingly. To avoid such errors again. NOTE 2 : Note: Increasing processes parameter increases the amount of shared memory that needs to be reserved & the OS must be configured to support the larger amount of shared memory. So here we first need to increase the Memory & SG