1. Trang chủ
  2. » Công Nghệ Thông Tin

OCA /OCP Oracle Database 11g A ll-in-One Exam Guide- P75 pps

10 283 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 10
Dung lượng 250,32 KB

Nội dung

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 1

OCA/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 2

Chapter 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 3

This page intentionally left blank

Trang 4

CHAPTER 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 5

OCA/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 6

Chapter 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 7

OCA/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 8

Chapter 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 9

OCA/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 10

Chapter 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:

Ngày đăng: 06/07/2014, 13:20

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w