Recovering from User Errors

Objectives After completing this lesson, you should be able to: Perform Flashback table operation Manage the recycle bin Recover from user errors using Flashback versions query Perform transaction level recovery using Flashback Transaction query

Flashback Time Navigation Flashback Query Query all data at a specified point in time Flashback Versions Query See all versions of a row between two times See the transactions that changed the row Flashback Transaction Query See all changes made by a transaction Tx3 Tx1 Tx2 Time Flashback Flashback Time Navigation Flashback Technology offers the capability to query past versions of schema objects, query historical data, perform change analysis. Every transaction logically generates a new version of the database. With Flashback Technology, you can navigate through these versions to find an error and its cause: Flashback Query: Query all data for a point in time Flashback Versions Query: See all versions of rows between two times and the transactions that changed the row Flashback Transaction Query: See all changes made by a transaction

Flashback Drop Overview DROP TABLE employees; FLASHBACK TABLE employees TO BEFORE DROP; Mistake was made Flashback Drop Overview In prior releases of the Oracle Database, if you mistakenly dropped a table, you had to recover the database to a prior time to recover the dropped table. This procedure was often time consuming and resulted in the loss of the work of other transactions. The flashback drop feature that allows you to undo the effects of a DROP TABLE statement without resorting to traditional point-in-time recovery.

Recycle Bin DROP TABLE employees; BIN$zbjrBdpw==$0 EMPLOYEES BIN$zbjra9wy==$0 EMPLOYEES_PK Recycle bin USER_OBJECTS 4 DBA_FREE_SPACE EMPLOYEES BIN$zbjrBdpw==$0 3 EMPLOYEES_PK BIN$zbjra9wy==$0 Recycle Bin When you dropped a table in previous releases of the Oracle database, the space associated with the table and its dependent objects was immediately reclaimable. When you drop a table with Oracle Database 10g, the space associated with the table and its dependent objects is not immediately reclaimable although it appears in DBA_FREE_SPACE. Instead, the dropped objects are temporarily placed in the recycle bin and still belong to their owner. The space used by recycle bin objects is never reclaimed unless there is space pressure. This allows you to recover recycle bin objects for the maximum possible duration. When a dropped table is moved to the recycle bin, it and its associated objects and constraints are renamed. This is necessary to avoid name conflicts that may arise if you later create a new table with the same name. The recycle bin itself is a data dictionary table that maintains the relationships between the original names of dropped objects and their system-generated names. You can query the content of the recycle bin by using the DBA_RECYCLEBIN view. 2 1 DROP TABLE employees;

Querying the Recycle Bin SELECT owner, original_name, object_name, type, ts_name, droptime, related, space FROM dba_recyclebin WHERE can_undrop = 'YES'; SELECT original_name, object_name, type, ts_name, droptime, related, space FROM user_recyclebin WHERE can_undrop = 'YES'; Querying the Recycle Bin You can view all of the objects that you have dropped by querying USER_RECYCLEBIN or RECYCLEBIN. DBA_RECYCLEBIN shows you all the objects that have been dropped by all users and that are still in the recycle bin. You can also use the SQL*Plus SHOW RECYCLEBIN command. This command shows you only those objects that can be un-dropped. The examples above show you how to extract important information from the recycle bin: ORIGINAL_NAME is the name of object before it has been dropped. OBJECT_NAME is the system-generated name of the object after it was dropped. TYPE is the object’s type. TS_NAME is the name of the tablespace to which the object belongs to. DROPTIME is the date at which the object was dropped. RELATED is the object identifier of the dropped object. SPACE is the number of blocks currently used by the object. SQL> SHOW RECYCLEBIN

Flashback Dropped Tables Using EM To flashback dropped tables with the Database Control Console, from the Maintenance page, select Perform Recovery in the Backup/Recovery region. Select Tables for the Object Type in the Type region, and choose Flashback Dropped Tables in the Operation Type section. Once done, click Continue. You should now see the Recovery: Dropped Objects Selection page from where you can select dropped tables from the recycle bin. You can also query the content of dropped tables by clicking View Content. Select the tables you want to recover and click Next. The next step is the Recovery: Rename page, where you can rename the table if one with the same name currently exists in the same schema. Click Next to continue. On the Perform Recovery: Review page, you can review the details of your operation as well as display the corresponding SQL statements. Once you are ready, click Submit. You should now see the Confirmation page. Click OK to go back to the Maintenance page. Note: You can also flashback dropped tables from the Tables link of the Schema section of the Administration page. On the Tables page, click the Recycle Bin button.

Restoring Objects from the Recycle Bin Use the FLASHBACK TABLE … command to restore dropped tables and dependent objects. If multiple recycle bin entries have the same original name: Use unique system-generated names to restore a particular version. When using original names, restored table is LIFO. Rename the original name if that name is currently used. Restoring Objects from the Recycle Bin Use the FLASHBACK TABLE … TO BEFORE DROP command to recover a table and all of its dependent objects from the recycle bin. You can specify either the original name of the table or the system-generated name assigned to the object when it was dropped. If you specify the original name, and if the recycle bin contains more than one object of that name, then the object that was moved to the recycle bin most recently is recovered first (Last In First Out). If you want to retrieve an older version of the table, you can specify the system-generated name of the table you want to retrieve, or issue additional FLASHBACK TABLE ... TO BEFORE DROP statements until you retrieve the table you want. If a new table of the original same name has been created in the same schema since the original table was dropped, then an error is returned unless you also specify the RENAME TO clause. Note: When you flashback a dropped table, the recovered indexes, triggers, and constraints keep their recycle bin names. Therefore it is advisable to query the recycle bin and DBA_CONSTRAINTS before flashing back a dropped table. That way you can rename the recovered indexes, triggers, and constraints to more usable names. FLASHBACK TABLE <table_name> TO BEFORE DROP [RENAME TO <new_name>]

Recycle Bin Automatic Space Reclamation 2 BIN$zbjrBdpw==$0 BIN$zbjra9wy==$0 BIN$zbjrBdpw==$0 BIN$zbjra9wy==$0 DBA_FREE_SPACE - RECYCLEBIN 1 Automatic Space Reclamation As long as the space used by recycle bin objects is not reclaimed, you can recover those objects by using the flashback drop feature. There are two ways in which objects from the recycle bin get reclaimed: Manual cleanup when you explicitly issue a PURGE command. Automatic cleanup under space pressure: While objects are in the recycle bin, their corresponding space is also reported in DBA_FREE_SPACE because their space is automatically reclaimable. The free space in a particular tablespace is then consumed in the following order: Free space not corresponding to recycle bin objects. Free space corresponding to recycle bin objects. In this case, recycle bin objects are automatically purged from the recycle bin using a FIFO algorithm. Free space automatically allocated if the tablespace is auto extensible. Assume that you create a new table inside tablespace TBS1. If there is free space allocated to this tablespace that does not correspond to a recycle bin object, then this free space is used as a first step. If this is not enough, then free space corresponding to recycle bin objects, that reside inside TBS1, is used. Autoextend 3

Recycle Bin Manual Space Reclamation PURGE {TABLE <table_name>|INDEX <index_name>} PURGE TABLESPACE <ts_name> [USER <user_name>] PURGE [USER_|DBA_]RECYCLEBIN Manual Space Reclamation Use the PURGE command to permanently remove objects from the recycle bin. When an object is purged from the recycle bin, it and its dependant objects are permanently removed from the database. As a consequence, objects purged from the recycle bin are no longer recoverable by using the flashback drop feature. The following PURGE operations are available: PURGE TABLE purges the specified table. PURGE INDEX purges the specified index. PURGE TABLESPACE purges all the objects residing in the specified tablespace. In addition, objects residing in other tablespaces may get purged if they are dependent. Optionally, you can also specify the USER clause to purge only those objects that belong to the specified user. This option is useful when a particular user is running low on disk quota for the specified tablespace. PURGE RECYCLEBIN purges all the objects that belong to the current user. RECYCLEBIN and USER_RECYCLEBIN are synonymous. PURGE DBA_RECYCLEBIN purges all the objects in the recycle bin. You must have enough system privileges or the SYSDBA system privilege to issue this command.

Bypassing the Recycle Bin DROP TABLE <table_name> [PURGE] ; DROP TABLESPACE <ts_name> [INCLUDING CONTENTS] ; DROP USER <user_name> [CASCADE] ; Bypassing the Recycle Bin You can use the DROP TABLE PURGE command to permanently drop a table and its dependent objects from the database. When you use this command, the corresponding objects are not moved to the recycle bin. This command provides the same functionality that the DROP TABLE command provided in prior releases. When you issue the DROP TABLESPACE … INCLUDING CONTENTS command, the objects in the tablespace are not placed in the recycle bin. Moreover, objects in the recycle bin belonging to the tablespace are purged. When you issue the same command without the INCLUDING CONTENTS clause, the tablespace must be empty for the command to succeed. However, there can be objects belonging to the tablespace in the recycle bin. In this case, these objects are purged. When you issue the DROP USER … CASCADE command, the user and all of the objects owned by the user are permanently dropped from the database. Any objects in the recycle bin belonging to the dropped user are purged.

Querying Dropped Tables USER_TABLES DROPPED TABLE_NAME NO SALES Recycle bin YES BIN$zbjrBdpw==$0 EMPLOYEES BIN$zbjra9wy==$0 EMPLOYEES_PK YES NO SALES_PK DROPPED INDEX_NAME USER_INDEXES Querying Dropped Tables When you drop a table, that table is moved to the recycle bin, and its original name is changed to a unique system-generated name. Because the dropped table still belongs to the schema of its owner, you can still see its characteristics from various dictionary views like DBA_TABLES, DBA_OBJECTS, and DBA_SEGMENTS. To make the distinction between tables that are in the recycle bin and the ones that are not, the DBA_TABLES view has a new column called DROPPED that is set to YES for tables that were dropped but are still in the recycle bin. So, as long as a system-generated table name is in the recycle bin, you can use it in a SELECT statement and flashback queries. However, you can not perform DML or DDL operations on objects that reside in the recycle bin. SELECT ... FROM BIN$zbjrBdpw==$0 [AS OF ...] WHERE ...

Flashback Drop Considerations Protected tables: Are non-SYSTEM tablespace tables Are stored in locally managed tablespaces Do not use fine-grained auditing or virtual private database The following dependencies are not protected: Bitmap-join indexes Materialized view logs Referential integrity constraints Indexes dropped before tables Purged tables cannot be flashed back Flashback Drop Considerations The recycle bin exists only for tables in non-SYSTEM locally managed tablespaces. However, dependent objects that reside in dictionary managed tablespaces are protected by the recycle bin. Tables with fine-grained auditing (FGA) or virtual private database (VPD) policies defined over them do not go into the recycle bin. When you drop a table that is protected by the recycle bin, its dependent objects are also protected by the recycle bin except for bitmap join indexes, referential integrity constraints, and materialized view logs. These objects cannot be flashed back along with the corresponding table. You cannot flashback a dropped table if it has been purged, either by a user or by an automatic space reclamation operation. Note: If you drop an index before its associated table, recovery of the index is not supported when you flashback the dropped table.

Flashback Versions Query Overview Tx0 Tx1 Tx2 Employees Employees Employees Fox t1 t2 SELECT versions_xid, salary FROM employees VERSIONS TIMESTAMP BETWEEN t1 and t2 WHERE last_name = 'Fox'; Versions Query Overview With the Flashback Query feature, you can perform queries on the database as of a certain time or user-specified system change number (SCN). The Flashback Versions Query feature allows you to use the VERSIONS clause to retrieve all of the versions of the rows that exist between two points in time, or two SCNs. The rows returned by the Flashback Versions Query represent a history of changes for the rows across transactions. The Flashback Versions Query retrieves only committed occurrences of the rows. Uncommitted row versions within a transaction are not shown. The rows returned include deleted and subsequently reinserted versions of the rows. You can use Flashback Versions Query to retrieve row history. It provides you with a way to audit the rows of a table and retrieve information about the transactions that changed the rows. You can then use the transaction identifier obtained from Flashback Versions Query to perform transaction mining using LogMiner. Note: In the example, VERSIONS_XID is a new pseudo-column that returns the transaction identifier of the corresponding version of a row. Tx0 Tx1 Tx2

Flashback Versions Query Using EM Flashback Versions Query can also be performed through EM. From the Maintenance page, select Perform Recovery. On the Perform Recovery page, select Table for the Object Type and select Flashback Existing Tables for the Operation Type. On the Perform Recovery: Point-in-Time page choose to ‘Evaluate row changes and transactions to decide on a point in time’ and specify the name of the target table. Select the columns you wish to view in the Available Columns box, then enter a search clause in the Bind The Row Value box. Select Show all row history and then click Next.

Flashback Versions Query Syntax SELECT [Pseudocolumns]… FROM … VERSIONS BETWEEN {SCN|TIMESTAMP {expr|MINVALUE} AND {expr|MAXVALUE}} [AS OF {SCN|TIMESTAMP expr}] WHERE [Pseudocolumns…]… Pseudocolumn Description VERSIONS_STARTTIME VERSIONS_STARTSCN Version validity range lower bound VERSIONS_ENDTIME VERSIONS_ENDSCN Version validity range upper bound VERSIONS_XID Transaction that created the version VERSIONS_OPERATION Operation that produced the version Flashback Versions Query Syntax When you specify the VERSIONS clause in a query, Oracle Database 10g retrieves multiple versions of the rows returned by the query. MINVALUE and MAXVALUE resolve to the SCN or timestamp of the oldest and most recent data available respectively. When both VERSIONS and AS OF clauses are used together, the VERSIONS clause determines the versions of the rows starting with the AS OF point. You can also use the following pseudocolumns in the SELECT list or the WHERE clause of the flashback versions query: VERSIONS_STARTSCN: SCN at which this version of the row was created. VERSIONS_STARTTIME: Timestamp at which this version of the row was created. VERSIONS_ENDSCN: SCN at which this version of the row expired. VERSIONS_ENDTIME: Timestamp at which this version of the row expired. VERSIONS_XID: Transaction identifier that created this version of the row. VERSIONS_OPERATION: Operation done by this transaction. VERSIONS_STARTSCN or VERSIONS_STARTTIME are NULL if the version of the corresponding row was created before the lower bound of the interval, or before the UNDO_RETENTION time. VERSIONS_ENDSCN or VERSIONS_ENDTIME are NULL in the following cases: The version of the row is still alive as of the query time. This is a deleted version of the row.

Flashback Versions Query Example SELECT versions_xid AS XID, versions_startscn AS START_SCN, versions_endscn AS END_SCN, versions_operation AS OPERATION, first_name FROM employees VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE AS OF SCN 5525300 WHERE employee_id = 111; XID START_SCN END_SCN O First_NAME ---------------- ---------- ---------- - ----------- 8C0025003A000000 5525293 I Tom 8C0024003A000000 5525291 D Mike 8C0022003A000000 5525277 5525291 I Mike Versions Query Example This example retrieves the change history for employee number 111. The period of the past is determined by the oldest SCN available, and the read SCN of the query (5525300). The rows returned include deleted and reinserted versions of the specified rows. The query results indicate the following: The third row corresponds to the time when employee 111 was inserted. So, employee 111 was inserted by transaction 8C0022003A000000 at SCN 5525277. The life time of this particular version of the row ended at SCN 5525291. The second row corresponds to a transaction that deleted employee 111. So, transaction 8C0024003A000000 deleted employee 111 at SCN 5525291. The fact that the VERSIONS_ENDSCN value for this row is NULL means that this version of the row no longer exists because it was deleted. The first row corresponds to a new version of the row that was inserted by transaction 8C0025003A000000 at SCN 5525293. The fact the VERSIONS_ENDSCN value is NULL means that this version of the row still exists at SCN 5525300. Note: If the AS OF clause is not used, the data are retrieved as of the current transaction, or specified SCNs, or specified times.

Flashback Versions Query Considerations The VERSIONS clause cannot be used to query: External tables Temporary tables Fixed tables Views The VERSIONS clause cannot span DDL commands. Segment shrink operations are filtered out. Versions Query Considerations The VERSIONS clause cannot be used to query the following special tables: External tables Temporary tables Fixed tables. You cannot use the VERSIONS clause to query a view. However, a view definition can use the VERSIONS clause. The VERSIONS clause in a SELECT statement cannot produce versions of rows across the DDL statements that change the structure of the corresponding tables. This means that the query stops producing rows once it hits a time in the past when the table was changed. Certain maintenance operations like a segment shrink may move table rows across blocks. In this case, the version query filters out such phantom versions because the row data remains the same.

Flashback Transaction Query Overview DBA Erroneous DML Undo SQL Flashback Transaction Query Overview Flashback Transaction Query is a diagnostic tool you can use to view changes made to the database at the transaction level. This allows you to diagnose problems in your database and perform analysis and audits of transactions. You can use the FLASHBACK_TRANSACTION_QUERY view to determine all of the necessary SQL statements that can be used to undo the changes made by a specific transaction, or during a specific period of time. USER

Querying FLASHBACK_TRANSACTION_QUERY SELECT operation, undo_sql, table_name FROM FLASHBACK_TRANSACTION_QUERY; SELECT operation, undo_sql, table_name FROM FLASHBACK_TRANSACTION_QUERY WHERE xid = HEXTORAW('8C0024003A000000') ORDER BY undo_change#; SELECT operation, undo_sql, table_name FROM FLASHBACK_TRANSACTION_QUERY WHERE start_time >= TO_TIMESTAMP ('2003-10-21 11:00:00','YYYY-MM-DD HH:MI:SS') AND commit_time <= TO_TIMESTAMP ('2003-10-21 11:30:00','YYYY-MM-DD HH:MI:SS'); Querying FLASHBACK_TRANSACTION_QUERY A query on the FLASHBACK_TRANSACTION_QUERY view can be issued without any filters, or can be issued with a filter incorporating a transaction identifier, or a time range. The first example returns information about all transactions, both active and committed, in all undo segments in the database. The second example returns information relevant to the transaction whose identifier is specified in the where clause. Note that a transaction may modify multiple rows within different statements. So, if you want to recover those changes you need to apply the undo SQL statements, returned by the query, in the right order. The third example returns information about all transactions that began and committed within an half hour interval. FLASHBACK_TRANSACTION_QUERY contains the following data for each row: START_SCN and corresponding START_TIMESTAMP COMMIT_SCN and COMMIT_TIMESTAMP: NULL for active transaction. LOGON_USER TABLE_OWNER ROW_ID Note: You need the SELECT ANY TRANSACTION system privilege to be able to issue a query against FLASHBACK_TRANSACTION_QUERY.

Using Flashback Versions Query and Flashback Transaction Query SELECT versions_xid , first_name FROM hr.employees VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE WHERE employee_id = 111; SELECT operation, undo_sql FROM FLASHBACK_TRANSACTION_QUERY WHERE xid = HEXTORAW('8C0024003A000000'); Using Flashback Versions and Transaction Query Flashback Versions Query and Flashback Transaction Query are two complementary features. Flashback Versions Query provides a history of changes made to a row along with the corresponding identifier of the transaction that made the change. However, as a DBA, you may need to know how a row came to have a certain set of values. By using the transaction identifier provided by the version query, for a particular row version, you can use Flashback Transaction Query to see exactly what operations were performed by the transaction and the necessary SQL statements to executed to undo those changes. The combination of the two features also provide a way to audit transactions. In the example, the result of the query on FLASHBACK_TRANSACTION_QUERY could look like: OPERATION UNDO_SQL --------- ------------------------------------------------------- DELETE insert into "HR"."EMPLOYEES_DEMO"("EMPNO","EMPNAME", "SALARY") values ('111','Mike','655'); INSERT delete from "TMP"."DEPARTMENTS_DEMO" where ROWID = 'AAAP95AAGAAAAAlAAB'; UPDATE update "HR"."EMPLOYEES_DEMO" set "SALARY" = '555' where ROWID = 'AAAP93AAGAAAAAVAAA';

Flashback Transaction Query Using EM This feature is used in conjunction with the Flashback Versions Query feature from the Perform Recovery wizard. On the Perform Recovery: Choose SCN page, click the corresponding Transaction ID link in the Flashback Versions Query Result section.

Flashback Transaction Query Considerations DDLs are seen as dictionary updates. Dropped objects appear as object numbers. Dropped users appear as user identifiers. Minimal supplemental logging may be needed: ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; Flashback Transaction Query Considerations Within the database, DDLs are nothing but a series of space management operations and changes to the data dictionary. Flashback Transaction Query on a transaction underlying a DDL displays the changes made to the data dictionary. When Flashback Transaction Query involves tables that have been dropped from the database, the table names are not reflected. Instead, object numbers are used. If the user who executed a transaction is dropped, Flashback Transaction Query of that transaction displays the corresponding userid only, and not the user name. Minimal supplemental logging ensures that Flashback Transaction Query has sufficient information to support chained rows and various storage arrangements such as cluster tables. Note: When there is not enough undo data for a specific transaction, a row with a value of UNKNOWN in the OPERATION column of FLASHBACK_TRANSACTION_QUERY is returned.

Flashback Table Overview Recover tables to a specific point in time Flashback Table is an in-place operation Database stays online Flashback Table Overview Flashback Table allows you to recover a set of tables to a specific point in time without having to perform traditional point in time recovery operations. A Flashback Table operation is done in-place while the database is online by rolling back only the changes that were made to the given tables and their dependent objects. A Flashback Table statement is executed as a single transaction. All tables must be flashed back successfully or the entire transaction is rolled back. Note: You can use Flashback Versions Query and Flashback Transaction Query to determine the appropriate flashback time. Erroneous DMLs Flashed back tables User

Using EM to Flashback Tables To flashback a table with the Database Control Console, from the Maintenance page, click Perform Recovery in the Backup/Recovery section. Select Tables for the Object Type and then select Flashback Existing Tables for the Operation Type. Once done, click Continue and the wizard guides you through the whole process. To enable row movement, go to the Administration page, and choose Table in the Schema section. From there, select your table and click Edit. Then, click the Options tab and select Yes in the Enable Row Movement field. Click Apply. Note: You can also flashback tables from the Tables link of the Schema section of the Administration page.

Flashback Table Example ALTER TABLE employees ENABLE ROW MOVEMENT; FLASHBACK TABLE employees TO TIMESTAMP (SYSDATE-1); ALTER TABLE employees ENABLE ROW MOVEMENT; ALTER TABLE departments ENABLE ROW MOVEMENT; Flashback Table Example Use the FLASHBACK TABLE command to flashback one or more tables to a specified SCN or point in time. Because Flashback Table technology uses DML operations to restore the rows in changed blocks of tables, Flashback Table does not preserve the rowids. Before issuing a FLASHBACK TABLE command, it is therefore necessary to enable row movement on the impacted tables. The first example uses a timestamp to determine the point in time to which to flashback the EMPLOYEES table. The second example uses an SCN instead of a timestamp, and because both tables EMPLOYEES and DEPARTMENTS are linked by a referential integrity constraint, the FLASHBACK TABLE statement is grouping both tables together. In the default operation mode, triggers currently enabled on the tables being flashed back are disabled for the duration of the flashback operation, and brought back to the enabled state after completion of the flashback operation. That is why you can use the ENABLE TRIGGERS clause in the FLASHBACK TABLE statement to override the default, and enable user-defined triggers that are currently enabled to stay enabled during the Flashback Table operation. The internal system triggers for materialized views stay enabled. Note: The order in which the tables are specified in the Flashback Table statement, or the order in which tables are flashed back does not matter. FLASHBACK TABLE employees, departments TO SCN 5525293 ENABLE TRIGGERS;

Rolling Back a Flashback Table Operation 10:25 10:42 11:29 11:30 11:35 HR.JOBS SCN:5525354 FLASHBACK TABLE jobs TO TIMESTAMP to_timestamp('10:42','hh24:mi'); 11:30 Rolling Back a Flashback Table Operation The FLASHBACK TABLE statement is executed as a single transaction, and cannot be part of any other transaction. This means you cannot use a ROLLBACK statement to bring back the tables to their prior states. However the effects of a FLASHBACK TABLE statement can be reverted by executing another FLASHBACK TABLE statement that specifies the SCN which corresponds to the one just before the first FLASHBACK TABLE statement. It is therefore recommended to make a copy of the current SCN before issuing FLASHBACK TABLE statements. In the example, the table JOBS is flashed back at 11:30 to its state at 10:42. Before executing the FLASHBACK TABLE command, you retrieve the current SCN of the database at 11:29. Let us suppose that its value is 5525354. After flashing back JOBS, you realize that this is not the correct state. So, at 11:35, you decide to revert the effects of your FLASHBACK TABLE statement by executing another FLASHBACK TABLE statement to retrieve the JOBS table as it was at SCN 5525354. Note: You can query the CURRENT_SCN column in V$DATABASE to obtain the current SCN. FLASHBACK TABLE jobs TO SCN 5525354; 11:35

Flashback Table Considerations The FLASHBACK TABLE command executes as a single transaction, acquiring exclusive DML locks. Statistics are not flashed back. Current indexes and dependent objects are maintained. Flashback Table operations: Cannot be performed on system tables Cannot span DDL operations Are written to the alert log file Flashback Table Considerations The entire FLASHBACK TABLE statement is executed within a single transaction. All the specified tables are updated or none are. It acquires exclusive DML locks on all the tables specified in the statement over the period of time the operation is in progress. Statistics of impacted objects are not be flashed back. All existing indexes are maintained. Dropped indexes are not recreated. Dependent on-commit materialized views are also maintained automatically. A Flashback Table statement is written to the alert log file. Tables specified in the FLASHBACK TABLE statement are flashed back provided none of the table constraints are violated. If any constraints are violated during flashback execution, the operation is aborted and the tables are left in the same state as they were just prior to the FLASHBACK TABLE statement invocation. Flashback Table to a particular time which is older than a DDL operation that has altered the structure of, or shrunk a table involved in the operation, cannot be performed. This restriction does not apply to DDL statements that only change storage attributes of the tables. Flashback Table cannot be performed on system tables, remote tables, and fixed tables.

Guaranteed Undo Retention SQL> CREATE UNDO TABLESPACE undotbs1 2 DATAFILE 'undotbs01.dbf' 3 SIZE 100M AUTOEXTEND ON 4 RETENTION GUARANTEE ; SQL> SELECT tablespace_name, RETENTION 2 FROM dba_tablespaces; TABLESPACE_NAME RETENTION --------------- --------- UNDOTBS1 GUARANTEE ... ... Guaranteed Undo Retention Most Flashback features rely on undo information to reconstruct a situation in the past. For an undo tablespace, you can now use the tablespace retention clause to control preservation of unexpired undo data. RETENTION GUARANTEE specifies that unexpired undo data should be retained in all undo segments in the tablespace even if operations that need to generate undo in those segments fail. The default value for RETENTION is NO GUARANTEE. This clause can also be specified in the CREATE DATABASE command for the undo tablespace. You can use the DBA_TABLESPACES view to determine the retention value for the tablespace. The RETENTION column has a value of GUARANTEE when the tablespace is configured with RETENTION GUARANTEE. The column has a value of NOGUARANTEE when the tablespace is configured with RETENTION GUARANTEE . If the tablespace is not configured for retention, the RETENTION column value defaults to NOT APPLY. Note: Because many of the Flashback features depend on the UNDO_RETENTION initialization parameter, you should change its default value of 900 seconds to a bigger value, if you want to flashback to a later point in time. SQL> ALTER TABLESPACE undotbs1 2> RETENTION NOGUARANTEE;

SCN and Time Mapping Enhancements The mapping granularity is three seconds. The mapping is retained for Max(five days, UNDO_RETENTION) Access the mapping by using the following SQL functions: SCN_TO_TIMESTAMP TIMESTAMP_TO_SCN SELECT current_scn, SCN_TO_TIMESTAMP(current_scn) FROM v$database; CURRENT_SCN SCN_TO_TIMESTAMP(CURRENT_SCN) ----------- ------------------------------- 3274940 23-SEP-03 02.56.03.000000000 AM SCN and Time Mapping Enhancements With most flashback features, you have the possibility to enable the flashback operation at a certain time, or SCN. Because the database time is represented by SCNs, this implies that there is a mapping between SCN numbers and corresponding times. In previous releases, when you triggered a flashback operation using a time, the database chose an SCN that was generated within five minutes of the time specified. Also, this mapping was retained for a maximum of five days of server uptime. With Oracle Database 10g, this mapping granularity is now down to three seconds instead of five minutes. That gives you much more precision when using times. In addition, the mapping can be retained for more than five days of server uptime by setting the UNDO_RETENTION initialization parameter to a bigger value. Whenever you want to access the maintained mapping, you have to use the new built-in functions: SCN_TO_TIMESTAMP converts an SCN to a corresponding TIMESTAMP value. TIMESTAMP_TO_SCN converts a TIMESTAMP value to a corresponding SCN. Note: TIMESTAMP_TO_SCN is the inverse function of SCN_TO_TIMESTAMP but not vice versa. This means that given any SCN SCNx, the following will always be true: SCNx = TIMESTAMP_TO_SCN(SCN_TO_TIMESTAMP(SCNx))

Summary In this lesson, you should have learned how to: Perform Flashback table operation Manage the recycle bin Recover from user errors using Flashback versions query Perform transaction level recovery using FB Transaction query

Practice 11 Overview: Recovering from User Errors This practice covers the following topics: Flashback Table Recycle bin space management Flashback Version Query