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.

CHAPTER 3 ■ FILES 107<br />

Flashback Log Files<br />

Flashback log files (or simply flashback logs) were introduced in <strong>Oracle</strong> 10g in support of the<br />

FLASHBACK DATABASE comm<strong>and</strong>, a new feature of the Enterprise Edition of the database. Flashback<br />

logs contain “before images” of modified database blocks that can be used to return the<br />

database to the way it was at some prior point in time.<br />

Flashback <strong>Database</strong><br />

The FLASHBACK DATABASE comm<strong>and</strong> was introduced to speed up the otherwise slow process<br />

of a point in time database recovery. It can be used in place of a full database restore <strong>and</strong> a<br />

rolling forward using archive logs, <strong>and</strong> it is primarily designed to speed up the recovery from<br />

an “accident.” For example, let’s take a look at what a DBA might do to recover from an<br />

“accidentally” dropped schema, in which the right schema was dropped, just in the wrong<br />

database (it was meant to be dropped in the test environment). The DBA recognizes immediately<br />

the mistake he has made <strong>and</strong> immediately shuts down the database. Now what?<br />

Prior to the flashback database capability, what would probably happen is this:<br />

1. The DBA would shut down the database.<br />

2. The DBA would restore the last full backup of database from tape (typically). This is<br />

generally a long process.<br />

3. The DBA would restore all archive redo logs generated since the backup that were not<br />

available on the system.<br />

4. The DBA would roll the database forward <strong>and</strong> stop rolling forward at a point in time<br />

just before the erroneous DROP USER comm<strong>and</strong>.<br />

5. The database would be opened with the RESETLOGS option.<br />

This was a nontrivial process with many steps <strong>and</strong> would generally consume a large piece<br />

of time (time where no one would be accessing the database, of course). The causes of a point<br />

in time recovery like this are many: an upgrade script gone awry, an upgrade gone bad, an<br />

inadvertent comm<strong>and</strong> issued by someone with the privilege to issue it (a mistake, probably<br />

the most frequent cause), or some process introducing data integrity issues into a large database<br />

(again, an accident; maybe it was run twice instead of just once, or maybe it had a bug).<br />

Whatever the reason, the net effect was a large period of downtime.<br />

The steps to recover in <strong>Oracle</strong> 10g Enterprise Edition, assuming you configured the flashback<br />

database capability, would be as follows:<br />

1. The DBA shuts down the database.<br />

2. The DBA startup-mounts the database <strong>and</strong> issues the flashback database comm<strong>and</strong>,<br />

using either an SCN, the <strong>Oracle</strong> internal clock, or a timestamp (wall clock time), which<br />

would be accurate to within a couple of seconds.<br />

3. The DBA opens the database with resetlogs.

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

Saved successfully!

Ooh no, something went wrong!