0072254289 Errata:

Chapter 8:

page 286: We discuss how large to make your Flash Recovery Area, and tell you to make it twice as large as your total database size, plus 20 percent. 

As we talked with more and more users of the FRA, we felt this may represent the true power of the disk-based backup solution that Oracle is positioning. If  you use disk-based datafile copies, and then take incremental backups, and use incrementally-updated backups, you need only have enough space for one good copy of your database, plus room for the nightly incremental and the day's archivelogs.

page 301: "Retention Policies and the Flashback Recovery Area"

We erroneously tell you that the FRA will age files out based on your RMAN retention policy. This is not the case. A good way to think about the FRA and the retention  policy is like this: "The Flash Recovery Area will neither enforce nor violate your retention policy." What this means is that the only way to enforce your retention policy is by passing the command 'delete obsolete.' So, even if you have a policy set to redundancy of 2, and you have 4 full backups in the FRA, if you run out of space the next backup will fail. On the same note, however, if you have a policy of redundancy 2, and you run out of space with only one full backup, the next backup will fail. 

So why is the FRA touted as 'self cleaning?' Good question. The automatic aging out of files refers to those files that RMAN has staged out to tape via the 'backup recovery area' command, and thus there are two copies of the same backupset-- one on disk, one on tape. Once this backup to tape happens, RMAN can delete the backupset on disk if space pressure occurs. 

We apologize for the confusion.

Chapter 9:

Page 330: "Setting Undo Parameters for Flashback Query and Flashback Table"

We fail to properly explain that the UNDO_RETENTION value you set does not effect any functionality within the UNDO tablespace. Instead, it provides a target for providing internal data on how close or how far the existing amount of UNDO is from your desired flashback time. 

If you want to guarantee that you will always be able to flashback as far back as your UNDO_RETENTION value, you have set a GUARANTEE on the UNDO tablespace:

sql> create tablespace undotbs1 
datafile 'u01/oracle/oradata/ora10g/undo01.dbf' size 500m
autoextend on
retention guarantee;

Once this is set, if the undo tablespace runs out of extents, and is at risk of overwriting undo data required to meet your UNDO_RETENTION target, then the undo datafile will autoextend rather than round-robin over the top of existing undo extents. Once extended, the file will not 'shrink' back down, which is smart: this is how much UNDO you need, under heavy load, to meet your retention target.