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

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) Chapter 18: User-Managed Backup, Restore, and Recovery 697 PART III 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. This page intentionally left blank 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 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. Chapter 19: Flashback 701 PART III 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 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. Chapter 19: Flashback 703 PART III 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. 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. Chapter 19: Flashback 705 PART III 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: SQL> select log_mode from v$database; . Use a Flashback Data Archive 699 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. procedures are for. 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. 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