05.11.2015 Views

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

106<br />

CHAPTER 3 ■ FILES<br />

Change Tracking File<br />

The change tracking file is a new, optional file for use with <strong>Oracle</strong> 10g Enterprise Edition. The<br />

sole purpose of this file is to track what blocks have modified since the last incremental<br />

backup. In this fashion, the Recovery Manager (RMAN) tool can back up only the database<br />

blocks that have actually been modified without having to read the entire database.<br />

In releases prior to <strong>Oracle</strong> 10g, an incremental backup would have had to read the entire<br />

set of database files to find blocks that had been modified since the last incremental backup.<br />

So, if you had a 1TB database to which you simply added 500MB of new data (e.g., a data warehouse<br />

load), the incremental backup would have read 1TB of data to find that 500MB of new<br />

information to backup. So, the incremental backup would have stored significantly less data in<br />

the backup, <strong>and</strong> it would have still read the entire database.<br />

In <strong>Oracle</strong> 10g Enterprise Edition, that is no longer the case. As <strong>Oracle</strong> is running, <strong>and</strong> as<br />

blocks are modified, <strong>Oracle</strong> will optionally maintain a file that tells RMAN what blocks have<br />

been changed. The process of creating this change tracking file is rather simple <strong>and</strong> is accomplished<br />

via the ALTER DATABASE comm<strong>and</strong>:<br />

ops$tkyte@ORA10GR1> alter database enable block change tracking<br />

2 using file<br />

3 '/home/ora10gr1/product/10.1.0/oradata/ora10gr1/ORA10GR1/changed_blocks.bct';<br />

<strong>Database</strong> altered.<br />

■Caution I’ll say this from time to time throughout the book: please bear in mind that comm<strong>and</strong>s that set<br />

parameters, change the database, <strong>and</strong> make fundamental changes should not be done lightly, <strong>and</strong> definitely<br />

should be tested prior to performing them on your “real” system. The preceding comm<strong>and</strong> will, in fact, cause<br />

the database to do more work. It will consume resources.<br />

To turn off <strong>and</strong> remove the block change tracking file, you would use the ALTER DATABASE<br />

comm<strong>and</strong> once again:<br />

ops$tkyte@ORA10GR1> alter database disable block change tracking;<br />

<strong>Database</strong> altered.<br />

ops$tkyte@ORA10GR1> !ls -l /home/ora10gr1/.../changed_blocks.bct<br />

ls: /home/ora10gr1/.../changed_blocks.bct: No such file or directory<br />

Note that that comm<strong>and</strong> will in fact erase the block change tracking file. It does not just<br />

disable the feature—it removes the file as well. You can enable this new block change tracking<br />

feature in either ARCHIVELOG or NOARCHIVELOG mode. But remember, a database in NOARCHIVELOG<br />

mode, where the redo log generated daily is not retained, cannot recover all changes in the<br />

event of a media (disk/device) failure! A NOARCHIVELOG mode database will lose data some day.<br />

We will cover these two database modes in more detail in Chapter 9.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!