CHAPTER 19Flashback Exam Objectives In this chapter you will learn to • 053.11.1 Restore Dropped Tables from the Recycle Bin • 053.11.2 Perform Flashback Query • 053.11.3 Use Flashback T
Trang 1OCA/OCP Oracle Database 11g All-in-One Exam Guide
696
3 During a recovery, it becomes apparent that an archive log is missing What will be the result?
A The recovery will succeed, but some data will be missing
B The recovery will fail
C The recovery will continue, if the damaged file was not from the SYSTEM tablespace or the active undo tablespace
D You must issue an ALTER DATABASE CLEAR ARCHIVE LOG FILE command to regenerate the missing archive
4 If you lose all of the tempfiles from your temporary tablespace, what is the most likely result noticed by your users?
A The database becomes unavailable and users cannot connect
B The users can’t perform SELECT statements
C The users cannot add or delete rows in any table
D The users can’t use ORDER BY or GROUP BY in their queries
5 Which is the best method for recovering a tempfile? (Choose the best answer.)
A Drop the TEMP tablespace and re-create it with a datafile in a new location
B Add another tempfile to the TEMP tablespace and drop the corrupted or missing tempfile while the database is running
C Shut down the database, restore the tempfile from a backup, and recover it using archived and online redo log files
D Add another tempfile to the TEMP tablespace and drop the corrupted or missing tempfile after the database has been shut down and restarted in MOUNT mode
6 To restore and recover a datafile that is part of the active undo tablespace, arrange these steps in the correct order:
1 Bring the file online.
2 Open the database.
3 Recover the damaged file.
4 Restore the damaged file.
5 Start the database in mount mode.
6 Start the database in nomount mode.
7 Take the damaged file offline.
A 6,7,4,5,3,1,7
B 5,7,2,4,3,1 (6 not needed)
C 5,7,4,3,1,2 (6 not needed)
D 5,4,3,2 (1,6,7 not needed)
Trang 2Chapter 18: User-Managed Backup, Restore, and Recovery
697
Self Test Answers
1 þ B The V$LOGFILE view shows information about each log file group
member
ý A, C, and D V$LOG show information for groups, not group members
There is no V$LOGFILE_MEMBER view, and damage to a multiplexed log file
member will not cause the instance to crash
2 þ C This is the error generated if you attempt to clear a log file group before
it has become inactive
ý A, B, and D A would give a different error, stating that you cannot clear
an unarchived log B is not possible because it is archive logs that are used for
recovery, and D is not relevant to clearing.
3 þ B This should never happen, though, if you have multiplexed archive log
destinations, as you should
ý A, C, and D A and C are wrong because it is not possible to skip over a
missing archive log file during a recovery D is wrong because CLEAR applies
only to online log files, not archive log files
4 þ D Temporary tablespaces provide sort space for queries that use ORDER
BY and GROUP BY when the sort operation will not fit in memory
ý A, B, and C A is wrong because the database remains available for some
queries and most DML activity even if the TEMP tablespace is unavailable
B is wrong because users can still perform SELECT statements that don’t
need sorting or the sort operation will fit into memory C is a wrong answer
because most DML activity does not require the TEMP tablespace
5 þ B Once the missing tempfile is dropped and a new one added, the TEMP
tablespace is automatically available to users
ý A, C, and D A is wrong because dropping the tablespace is not necessary,
and you cannot drop the default temporary tablespace C is wrong because
you cannot recover a temporary tablespace; there are no permanent objects in
a temporary tablespace D is wrong because the database does not need to be
shut down to recover a temporary tablespace
6 þ D This is the best (that is to say, the fastest) sequence for recovering a
critical datafile
ý A, B, C A is wrong because no datafile operations can be accomplished in
nomount mode B is the sequence for open recovery of a noncritical datafile
C would work but includes unnecessary steps.
Trang 3This page intentionally left blank
Trang 4CHAPTER 19
Flashback
Exam Objectives
In this chapter you will learn to
• 053.11.1 Restore Dropped Tables from the Recycle Bin
• 053.11.2 Perform Flashback Query
• 053.11.3 Use Flashback Transaction
• 053.12.1 Perform Flashback Table Operations
•053.12.2 Configure and Monitor Flashback Database and Perform Flashback
Database Operations
• 053.12.3 Set Up and Use a Flashback Data Archive
699
Trang 5OCA/OCP Oracle Database 11g All-in-One Exam Guide
700
A long time ago (in a galaxy far away also known as Oracle 5) every version of every data block could be logged to a Before Image file This provided the rollback function, which was handled at the block level rather than the transaction level It did provide the capability to “roll back” the entire database but the performance overhead was generally unacceptable, so Oracle 6 introduced row level before image logging in rollback (nowadays, “undo”) segments The option of block-level logging was reintroduced
in release 10g as Flashback Database, but in a fashion that has minimal performance
overhead The Flashback Database capability lets you “rewind” the database to some point in the past, by backing out (in reverse chronological order) all the changes made
to the datafiles
This chapter also covers the other flashback technologies available in an Oracle 11g
database These are not as extreme as Flashback Database in that they do not entail either downtime or loss of data They are still, however, very powerful techniques for recovering from errors by backing out changes that you would prefer not to have been committed These technologies are Flashback Drop, various forms of Flashback Query,
and (an 11g new feature) the Flashback Data Archive.
The Different Flashback Technologies
There are four distinct flashback technologies available, each implemented with
a different underlying architecture Each technology has different capabilities and limitations, but there is overlapping functionality between them The typical reason for using any type of flashback technology is to correct mistakes—it is vital to understand what type of flashback technology is appropriate for correcting different types of errors
Flashback Database
Flashback Database is, by analogy, like pressing a rewind button on the database The current database is taken as the starting point, and it is taken back in time, change by change, reversing all work done sequentially The end result is as if you had done an incomplete recovery: all work subsequent to the flashback point is lost, and indeed the database must be opened with RESETLOGS Clearly, this is a very drastic thing to do It allows you to back out changes that resulted in logical corruptions (in a business sense): inappropriate transactions, such as running your year-end archive-and-purge routines before running your end-of-year reports
If you have experienced physical corruption within the database or loss of media, Flashback Database will not help—for that, you must use traditional, complete, recovery methods Flashback Database is an alternative to incomplete recovery
following user error—perhaps a more flexible and much faster alternative
EXAM TIP Flashback Database will not back out physical corruption, only
logical corruption caused by user error
Trang 6Chapter 19: Flashback
701
Flashback Query, Transaction, and Table
Three flashback techniques are based on the use of undo segments The first flashback
capability was initially introduced with release 9i of the database and has been
substantially enhanced subsequently
Flashback Query (the release 9i feature) lets you query the database as it was at some
time in the past, either for one select statement or by taking your session temporarily
back in time so that all its queries will be against a previous version of the database This
can be used to see the state of the data before a set of transactions was committed What
did the tables look like half an hour ago? This can be invaluable in tracking down the
cause of business data corruptions, and can also be used to correct some mistakes: by
comparing the current and previous versions of a table, you can identify what was done
that was wrong It is even possible to select all versions of a row over a period of time, to
show a history of what has happened to the row, when it happened, who did it, and the
identifiers of the transactions that made each change
Flashback Transaction automates the repair process Once you have used Flashback
Query to identify which transaction it was that caused the problem, Oracle can construct
SQL statements that will reverse the changes This is not the same as rolling back a
committed transaction! It is impossible to roll back a committed change, because the
rules of a relational database do not permit this But it is possible to construct another
transaction that will reverse the effect of the first, erroneous transaction Unlike
Flashback Database, Flashback Transaction does not imply data loss: all other work
done remains in effect, and the database stays current
The third flashback technique based on undo data is Flashback Table Having
determined that inappropriate work has been committed against one table, you can
instruct Oracle to reverse all changes made to that table since a particular point in
time, while leaving all other tables current
Throughout any Flashback Query, Transaction, or Table operation, the database
remains open and all objects (including those involved in the flashback) are available
for use Transactional integrity and constraints are always enforced, which means that
the flashback operation might fail For example, if a flashback of a transaction requires
an insert into a primary key column, that value must not be in use Flashing back one
table may not be possible if it has foreign key constraints—you will have to flash back
all the related tables in one operation
EXAM TIP Flashback query, in its three variations, relies on the use of UNDO
segments
Flashback Drop
It is now possible to “un-drop” a table This is implemented by mapping the DROP
command onto a RENAME command Rather than dropping the table, it is renamed
to a system-generated name, and only actually dropped later, when its storage space
is needed for a live object If necessary, and if its storage space has not been reused,
the object can be renamed back to its original name and thus restored Without this
Trang 7OCA/OCP Oracle Database 11g All-in-One Exam Guide
702
capability, the only way to get a table back after a drop would be to do an incomplete recovery to the point in time just before the table was dropped This was usually time-consuming, and it meant the loss of all work done subsequently The new Flashback Database capability achieves the same result as incomplete recovery and should be much faster, but work done on other tables following the drop is lost and the database will be unavailable until the operation is completed
Flashback Drop lets you reinstate the table as it was at the time that it was dropped, with no loss of data whatsoever; the database remains current This does not require any use of backups, and neither is there any downtime for users Note that Flashback Drop is specifically for the DROP command; you cannot flash back a TRUNCATE command Along with the table itself, any associated indexes and permissions will also be restored
EXAM TIP You cannot flash back a table truncation, only a table drop.
Flashback Data Archive
Release 11g of the Oracle Database includes a feature sometimes referred to as Total
Recall, which is implemented with a Flashback Data Archive This is the ability to view tables as they were at any time in the past The forms of flashback described so far all have time limits: Flashback Database is restricted by the size of the flashback logs, flashback query by the undo retention, and flashback drop by the available space
in tablespaces A Flashback Data Archive can be configured to store before-images of rows indefinitely
Enabling a table for Flashback Data Archive creates another table (and a few other objects) that will store all previous versions of rows: storing them forever if desired When DML is committed against the table, a background process called the Flashback Data Archive process (the FBDA) will capture the necessary data and save it to the archive From there, it can be queried with the same syntax used for a regular flashback query—but the flashback can go back years
When a Flashback Data Archive is created, you specify a time limit (which may be years) and the FBDA will make sure that all data is saved until that time has passed, and will then remove it The FBDA is responsible for creating the objects in the archive, populating them with rows as necessary, and purging data that has passed the expiry date
When to Use Flashback Technology
Human error has always been the most difficult type of error from which to recover This is because as far as the database is concerned, human error is not an error at all The “error” is just another committed transaction, and the rules of a relational database (the “D” for “Durable” of the ACID test) do not allow Oracle to back out committed transactions Depending on the nature of the error, the different Flashback technologies may help you to recover, while minimizing downtime and loss of data
Trang 8Chapter 19: Flashback
703
The most drastic flashback technique is Flashback Database Consider using this only
when you would also consider using incomplete recovery—the effect is the same,
though the downtime will typically be much less Examples would include dropping a
user or a tablespace on the production system when you thought you were connected
to the test system A critical table truncation (though not a table drop) would also be
a time to use Flashback Database
Flashback Drop will restore a table (together with its indexes and grants) to the
state it was in at the time of the drop Note that this will not restore a truncated
table—only one that has been completely dropped There is no downtime involved,
other than the obvious fact that until the table is undropped, no one can get to it, and
no work will be lost Unlike Flashback Database, Flashback Drop does not require any
configuration—it is always available, unless you specifically disable it
For finer granularity of recovery, consider Flashback Table and Flashback
Transaction These should not affect the users at all, other than that the work reversed
is gone—which is presumably the desired outcome Like Flashback Drop, the Flashback
Query, Transaction, and Table facilities are always available without any configuration
other than granting appropriate privileges They may, however, require some tuning of
undo management
The Flashback Data Archive is for long-term storage Typically, this will be for legal
reasons: in many jurisdictions there are requirements for keeping data for years, and
then for destroying it (sometimes known as “digital shredding”) A Flashback Data
Archive can enable this transparently The DBA can thus guarantee legal compliance
without the need for any programming effort
In some cases, you will have a choice of Flashback technologies Consider an
example where a batch job is run twice Perhaps you import a few hundred thousand
invoices into your accounting system from your billing system every day, and through
some mistake and lack of validation the same billing run is imported twice If the import
is done as one huge transaction, then Flashback Transaction will reverse it But if it is
done as many small transactions, rather than reversing them all it may be easier to do a
table-level flashback of all the tables affected It may be that some of the billing system
interface tables are dropped after the run—Flashback Drop will recover them But if the
run involves a truncation, the only option is Flashback Database Also, it may be that the
error was not discovered for some time and a significant amount of work has been done
based on the erroneously imported data; then Flashback Database may be the only way
to ensure that you end up with a database that is consistent in business terms
When choosing a Flashback technique, always remember that Oracle will guarantee
transactional integrity, but that the results in business terms may not be what you
want Flashback Database, or indeed incomplete recovery, is the only way to guarantee
absolutely the integrity of the database and conformity with your business rules—but
the price in lost time and data may be very high
EXAM TIP In the case of media damage, such as losing a datafile, no Flashback
technology can help That is what the standard backup, restore, and recovery
procedures are for
Trang 9OCA/OCP Oracle Database 11g All-in-One Exam Guide
704
Flashback Database
To flash back an entire database is functionally equivalent to an incomplete recovery, but the method and the enabling technology are completely different
Flashback Database Architecture
Once Flashback Database is enabled, images of altered blocks are copied from time to time from the database buffer cache to a new memory area within the SGA, the flashback buffer This flashback buffer is flushed to disk, to the flashback logs, by a new background process: the Recovery Writer, or RVWR There is no change to the usual routine of writing changes to the log buffer, which the LGWR then flushes to disk; flashback logging is additional to this Unlike the redo log, flashback logging is not a log of changes—it is a log of complete block images
EXAM TIP Unlike redo logs, the flashback logs cannot be multiplexed and are
not archived They are created and managed automatically
Critical to performance is that not every change is copied to the flashback buffer— only a subset of changes If all changes to all blocks were copied to the buffer, then the overhead in terms of memory usage and the amount of extra disk I/O required to flush the buffer to disk would be crippling for performance Internal algorithms limit which versions of which blocks are placed in the flashback buffer, in order to restrict its size and the frequency with which it will fill and be written to disk These algorithms are intended to ensure that there will be no negative performance hit when enabling Flashback Database: they guarantee that even very busy blocks are logged only infrequently
When conducting a database flashback, Oracle will read the flashback logs to extract the versions of each changed database block, and copy these versions back into the datafiles As these changes are applied to the current database in reverse chronological order, this has the effect of taking the database back in time, by reversing the writes that the DBWn process has done
Since not every version of every changed block is copied into the flashback buffer and hence to the flashback logs, it is not possible to flash back to an exact point in time It may be that a block was changed many times, but that the flashback log has only a subset of these changes Consider the case where block A was changed at 10:00 and again at 10:05, but that only the 10:00 version is in the flashback log Block B was changed at 10:05 and at 10:20, and both versions are in the flashback log All the changes have been committed It is now 11:00, and you want to flash back to 10:15 The flashback operation will restore the 10:00 version of block A and the 10:05 version of block B: it will take each changed block back as close as it can to, but no later than, the desired time Thus Flashback Database constructs a version of the datafiles that is just before the time you want This version of the datafiles may well
be totally inconsistent: as in this example, different blocks will be at different system change numbers, depending on what happened to be available in the flashback log
Trang 10Chapter 19: Flashback
705
To complete the flashback process, Oracle then uses the redo log It will recover all the
blocks to the exact time requested (in the example, only block A needs recovery), thus
synchronizing all the datafiles to the same SCN The final stage is to roll back any
transactions that were uncommitted at the point, exactly as occurs at the last stage
of an incomplete recovery
So Flashback Database is in fact a combination of several processes and data
structures First, you must allocate some memory in the SGA (which will be automatic—
you cannot control how large the buffer is) and some space on disk to store the flashback
data, and start the RVWR process to enable flashback logging When doing a flashback,
Oracle will use the flashback logs to take the database back in time to before the time
you want, and then apply redo logs (using whatever archive redo log files and online
redo log files are necessary) in the usual fashion for incomplete recovery to bring the
datafiles forward to the exact time you want Then the database can be opened with a
new incarnation, in the same manner as following a normal incomplete recovery
EXAM TIP Flashback Database requires archivelog mode and the use of
ALTER DATABASE OPEN RESETLOGS to create a new incarnation of the
database
Flashback Database requires archivelog mode, because without the availability
of the archive log stream it would not be possible to convert the inconsistent version of
the database produced by the application of flashback logs to a consistent version that
can be opened So what is the benefit of Flashback Database over incomplete recovery,
which also requires archive log mode? It is in the speed and convenience with which
you can take the database back in time
An incomplete recovery is always time-consuming, because part of the process is a
full restore The time for an incomplete recovery is to a large extent proportional to the
size of the database By contrast, the time needed for a database flashback is largely
proportional to the number of changes that need to be backed out In any normal
environment, the volume of changed data will be tiny when compared to the total
volume of data, so a flashback should be many times faster Furthermore, Flashback
Database is very easy to use Once configured, flashback logging will proceed completely
unattended and a database can be flashed back very easily with one command There are
none of the possibilities for error inherent in a traditional restore and recover operation
Configuring Flashback Database
Configuring a database to enable Flashback Database does require downtime: there is
a command that can only be issued while the database is in mount mode To configure
Flashback Database, follow these steps:
1 Ensure that the database is in archivelog mode
Archive log mode is a prerequisite for enabling Flashback Database Confirm
this by querying the V$DATABASE view: