Oracle-L11 using Oracle flashback technology-Mazenet solution

Editor's Notes

• #4: Flashback Technology You can use Flashback technology when a logical corruption occurs in the Oracle database, and you need to recover data quickly and easily. As with human errors, it is difficult to identify the objects and rows that are affected by an erroneous transaction. With Flashback technology, you can diagnose how errors are introduced into the database, and then you can repair the damage. You can view the transactions that have contributed to specific row modifications, view the entire set of versions of a given row during some time period, or just view data as it appeared at a specific time in the past. The table in the slide shows typical uses of Flashback technology. Flashback Database depends on the flashback logs to perform flashback. Flashback Drop uses the recycle bin. All other techniques use undo data. Not all flashback features modify the database. Some are simply methods to query other versions of data. Those are tools for you to use to investigate a problem and aid in recovery. The results of those flashback queries can help you do one of these two things: Determine which type of database-modifying flashback operation to perform to fix the problem. Feed the result set of these queries into an INSERT, UPDATE, or DELETE statement that enables you to easily repair the erroneous data. Flashback Data Archive enables you to use the preceding logical flashback features to access data from far back in the past. Flashback Database and Flashback Data Archive are covered in the lesson titled “Additional Flashback Operations.”
• #5: Transactions and Undo When a transaction starts, it is assigned to an undo segment. Throughout the life of the transaction, when data is changed, the original “old” values are copied into the undo segment. You can see which transactions are assigned to which undo segments by checking the V$TRANSACTION dynamic performance view. Undo segments are specialized segments that are automatically created by the instance as needed to support transactions. Like all segments, undo segments are made up of extents, which, in turn, consist of data blocks. Undo segments automatically grow and shrink as needed, acting as a circular storage buffer for their assigned transactions. Transactions fill extents in their undo segments until a transaction is completed or all space is consumed. If an extent fills up and more space is needed, the transaction acquires that space from the next extent in the segment. After all extents have been consumed, the transaction either wraps around back into the first extent or requests a new extent to be allocated to the undo segment. Note: Parallel DML operations can actually cause a transaction to use more than one undo segment. To learn more about parallel DML execution, see the Oracle Database Administrator’s Guide.
• #6: Guaranteeing Undo Retention The default undo behavior is to overwrite committed transactions that have not yet expired rather than to allow an active transaction to fail because of lack of undo space. In case of conflict, transactions have precedence over queries. This behavior can be changed by guaranteeing retention. With guaranteed retention, undo retention settings are enforced even if they cause transactions to fail. (So in case of conflict, queries have precedence over transactions.) RETENTION GUARANTEE is a tablespace attribute rather than an initialization parameter. This attribute can be changed using either SQL command-line statements or Enterprise Manager. The syntax to change an undo tablespace to guarantee retention is: SQL> ALTER TABLESPACE undotbs1 RETENTION GUARANTEE; To return a guaranteed undo tablespace to its normal setting, use the following command: SQL> ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE; You can set Undo Retention Guarantee in Enterprise Manager. Navigate to the Automatic Undo Management page. Click the current setting for Retention Guarantee (General/Undo Retention Settings) to modify it.
• #7: Preparing Your Database for Flashback To enable flashback features for an application, you must perform these tasks: Create an undo tablespace with enough space to keep the required data for flashback operations. The more often users update the data, the more space is required. The database administrator usually calculates the space requirement. If you are uncertain about your space requirements, you can start with an automatically extensible undo tablespace, observe it through one business cycle (for example, 1 or 2 days), collect undo block information with the V$UNDO_STAT view, calculate your space requirements, and use them to create an appropriately sized fixed undo tablespace. (The calculation formula is in the Oracle Database Administrator’s Guide.) By default, Automatic Undo Management is enabled. If needed, enable Automatic Undo Management, as explained in the Oracle Database Administrator’s Guide. For a fixed-size undo tablespace, the Oracle database automatically tunes the system to give the undo tablespace the best possible undo retention. For an automatically extensible undo tablespace (default), the Oracle database retains undo data to satisfy at a minimum, the retention periods needed by the longest-running query and the threshold of undo retention, specified by the UNDO_RETENTION parameter.
• #8: Flashback Drop and the Recycle Bin Using the FLASHBACK TABLE command, you can undo the effects of a DROP TABLE statement without having to use point-in-time recovery. Note: The RECYCLEBIN initialization parameter is used to control whether the Flashback Drop capability is turned ON or OFF. If the parameter is set to OFF, then dropped tables do not go into the recycle bin. If this parameter is set to ON, the dropped tables go into the recycle bin and can be recovered. By default, RECYCLEBIN is set to ON.
• #9: Recycle Bin Without the recycle bin enabled, when you drop a table, the space associated with the table and its dependent objects is immediately reclaimable (that is, it can be used for other objects). If the recycle bin is enabled, when you drop a table, then the space associated with the table and its dependent objects is not immediately reclaimable, even though it does appear in DBA_FREE_SPACE. Instead, the dropped objects are referenced in the recycle bin and still belong to their owner. The space used by recycle bin objects is never automatically reclaimed unless there is space pressure. This enables you to recover recycle bin objects for the maximum possible duration. When a dropped table is “moved” to the recycle bin, the table and its associated objects and constraints are renamed using system-generated names. The renaming convention is as follows: BIN$unique_id$version where unique_id is a 26-character globally unique identifier for this object making the recycle bin name unique across all databases and version is a version number assigned by the database.
• #10: Restoring Tables from the Recycle Bin Use the FLASHBACK TABLE ... TO BEFORE DROP command to recover a table and all of its possible 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 (LIFO: 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 that 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 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 flash back 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. In this way, you can rename the recovered indexes, triggers, and constraints to more usable names.
• #11: Recycle Bin: Automatic Space Reclamation As long as the space used by recycle bin objects is not reclaimed, you can recover those objects by using Flashback Drop. The following are the recycle bin object reclamation policies: 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: 1.Free space not corresponding to recycle bin objects 2.Free space corresponding to recycle bin objects. In this case, recycle bin objects are automatically purged from the recycle bin using a first in, first out (FIFO) algorithm. Free space automatically allocated if the tablespace is auto-extensible Suppose you create a new table inside the TBS1 tablespace. 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, free space is used that corresponds to recycle bin objects that reside inside TBS1. If the free space of some recycle bin objects is used, then these objects get purged automatically from the recycle bin. At this time, you can no longer recover those objects by using the Flashback Drop feature. As a last resort, if space requirement is not yet satisfied, the TBS1 tablespace is extended if possible.
• #12: Recycle Bin: Manual Space Reclamation Use the PURGE command to permanently remove objects from the recycle bin. When an object is purged from the recycle bin, the object and its dependent 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 are the possible uses of PURGE: 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. 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. You must have enough system privileges or the SYSDBA system privilege to issue this command. Tables can also be purged from the recycle bin using Enterprise Manager. On the Schema folder tab, click Tables, then select the schema the dropped object resided in and click the Recycle Bin button. Select the table from the results list and click the Purge button. Note: For PURGE TABLE and PURGE INDEX commands, if you specify an original name and if the recycle bin contains more than one object of that name, then the object that has been in the recycle bin the longest is purged first (FIFO).
• #13: 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 previous 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 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.
• #14: Querying the Recycle Bin You can view all the objects that you have dropped by querying user_recyclebin or RECYCLEBIN. It has a synonym RECYCLEBIN, for ease of use. The dba_recyclebin view 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 “undropped.” The examples show how to extract important information from the recycle bin: original_name is the name of the object before it is dropped. object_name is the system-generated name of the object after it is dropped. type is the object’s type. ts_name is the name of the tablespace to which the object belongs. 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. You can also see the content of the recycle bin by using Database Control. Note: For detailed information about the DBA_RECYCLEBIN view, see the Oracle Database Reference guide.
• #15: Querying Data from Dropped Tables When you drop a table, its original name is changed to a unique, system-generated name referenced in the recycle bin. Because you still own the dropped table, you can still see its characteristics from various dictionary views such as DBA_TABLES, DBA_OBJECTS, DBA_SEGMENTS, and so on. To make a distinction between tables that are in the recycle bin and tables that are not, the DBA_TABLES view has a 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 also in flashback queries. However, you cannot issue any sort of DML or DDL statements on objects that reside in the recycle bin.
• #16: Using Flashback Technology to Query Data Flashback technology provides the capability to query past versions of schema objects, query historical data, and 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 as it existed at a specific point in time. Flashback Version 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.
• #17: Flashback Query With the Flashback Query feature, you can perform queries as of a certain time. By using the AS OF clause of the SELECT statement, you can specify the time stamp for which to view the data. This is useful for analyzing a data discrepancy. Note: TIMESTAMP and SCN are valid options for the AS OF clause.
• #18: Flashback Query: Example If a raise has been erroneously given to a particular employee recently, you can update the salary again, assigning the salary provided by a subquery that returns the flashed-back value.
• #19: Flashback Version Query With Flashback Query, you can perform queries on the database as of a certain time span or range of user-specified system change numbers (SCNs). The Flashback Version Query feature enables you to use the VERSIONS clause to retrieve all the versions of the rows that exist between two points in time or two SCNs. The rows returned by Flashback Version Query represent a history of changes for the rows across transactions. Flashback Version Query retrieves only committed occurrences of the rows. Uncommitted row versions within a transaction are not shown. The rows returned also include deleted and subsequently reinserted versions of the rows. You can use Flashback Version 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 affected the rows. You can then use the returned transaction identifier to perform transaction mining by using LogMiner or to perform a Flashback Transaction Query, as described later in this lesson. Note: VERSIONS_XID is a pseudocolumn that returns the transaction identifier of the corresponding version of a row.
• #20: Flashback Version Query Using Enterprise Manager You can also perform Flashback Version Query by using Enterprise Manager (EM). On the Availability page, select Perform Recovery. On the Perform Recovery page, select Tables as Object Type and Flashback Existing Tables as Operation Type. Click Perform Object Level Recovery. On the “Perform Object Level Recovery: Point-in-Time” page, select “Evaluate row changes and transactions to decide on a point in time,” and specify the name of the target table. Select the columns that you want to view in the Available Columns box, and then enter a search clause in the Bind The Row Value box. Select “Show all row history,” and then click Next.
• #21: Flashback Version Query: Considerations The VERSIONS clause cannot be used to query the following types of 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 after it reaches a time in the past when the table structure was changed. Certain maintenance operations, such as 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.
• #22: Flashback Transaction Query Flashback Transaction Query is a diagnostic tool that you can use to view changes made to the database at the transaction level. This enables 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 the necessary SQL statements that can be used to undo the changes made either by a specific transaction or during a specific period of time.
• #23: Using Enterprise Manager to Perform Flashback Transaction Query This feature is used in conjunction with the Flashback Version Query feature with the help of the Perform Recovery Wizard. On the “Perform Object Level Recovery: Choose SCN” page, click the corresponding Transaction ID link in the Flashback Version Query Result region. In the example in the slide, a Flashback Version Query is performed on the JOBS table to retrieve the three versions of the JOBS row for JOB_ID = 'AD_PRES'. Then, one of the transaction IDs is clicked, showing all the changes that were part of that transaction. Notice that in addition to the JOBS table update, there was also an update to the EMPLOYEES table in that transaction.
• #24: Flashback Transaction Query: Considerations Within the database, DDL operations are nothing but a series of space management operations and changes to the data dictionary. Flashback Transaction Query on a transaction underlying a DDL command 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 user ID only, and not the username. 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.
• #25: Flashback Transaction With Flashback Transaction, you can reverse a transaction and dependant transactions. Oracle Database determines the dependencies between transactions and, in effect, creates a compensating transaction that reverses the unwanted changes. The database rewinds to a state as if the transaction, and any transactions that could be dependent on it, never occurred. You can use the Flashback Transaction functionality from within Enterprise Manager or with PL/SQL packages.
• #26: Prerequisites In order to use this functionality, supplemental logging must be enabled and the correct privileges established. For example, the HR user in the HR schema decides to use Flashback Transaction for the REGIONS table. The SYSDBA performs the following setup steps in SQL*Plus: alter database add supplemental log data; alter database add supplemental log data (primary key) columns; grant execute on dbms_flashback to hr; grant select any transaction to hr;
• #27: Flashing Back a Transaction Security privileges To flash back or back-out a transaction—that is, to create a compensating transaction—you must have the SELECT, FLASHBACK, and DML privileges on all affected tables. Conditions of Use Transaction back-out is not supported across conflicting DDL. Transaction back-out inherits data type support from LogMiner. See the Oracle Database 11g documentation for supported data types. Recommendation When you discover the need for transaction back-out, performance is better if you start the back-out operation sooner. Large redo logs and high transaction rates result in slower transaction back-out operations. Provide a transaction name for the back-out operation to facilitate later auditing. If you do not provide a transaction name, it will be automatically generated for you.
• #28: Possible Workflow Assume that several transactions occurred as indicated below: connect hr/hr INSERT INTO hr.regions VALUES (5,'Pole'); COMMIT; UPDATE hr.regions SET region_name='Poles' WHERE region_id = 5; UPDATE hr.regions SET region_name='North and South Poles' WHERE region_id = 5; COMMIT; INSERT INTO hr.countries VALUES ('TT','Test Country',5); COMMIT; connect sys/<password> as sysdba ALTER SYSTEM ARCHIVE LOG CURRENT;
• #29: Viewing Data To view the data in a table in Enterprise Manager, go to the Schema folder and select Tables under Database objects. While viewing the content of the HR.REGIONS table, you discover a logical problem. Region 5 is misnamed. You decide to immediately address this issue.
• #30: Flashback Transaction Wizard In Enterprise Manager, select HR.REGIONS under Table, select Flashback Transaction from the Actions drop-down list, and then click Go. This invokes the Flashback Transaction Wizard for your selected table. The Flashback Transaction: Perform Query page is displayed. Select the appropriate time range and add query parameters. (The more specific you can be, the shorter is the search of the Flashback Transaction Wizard.) Without Enterprise Manager, use the DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure, which is described in the PL/SQL Packages and Types Reference. Essentially, you take an array of transaction IDs as the starting point of your dependency search. For example: CREATE TYPE XID_ARRAY AS VARRAY(100) OF RAW(8); CREATE OR REPLACE PROCEDURE TRANSACTION_BACKOUT( numberOfXIDs NUMBER, -- number of transactions passed as input xids XID_ARRAY, -- the list of transaction ids options NUMBER default NOCASCADE, -- back out dependent txn timeHint TIMESTAMP default MINTIME -- time hint on the txn start );
• #31: Flashback Transaction Wizard (continued) The Flashback Transaction: Select Transaction page displays the transactions according to your previously entered specifications. First, display the transaction details to confirm that you are flashing back the correct transaction. Then select the offending transaction and continue with the wizard.
• #32: Flashback Transaction Wizard (continued) The Flashback Transaction Wizard now generates the undo script and flashes back the transaction, but it gives you control to COMMIT this flashback. Before you commit the transaction, you can use the Execute SQL area at the bottom of the Flashback Transaction: Review page, to view what the result of your COMMIT will be.
• #33: Finishing Up On the Flashback Transaction: Review page click the Show Undo SQL Script button to view the compensating SQL commands. Click Finish to commit your compensating transaction.
• #34: Choosing Other Back-out Options The TRANSACTION_BACKOUT procedure checks dependencies, such as: Write-after-write (WAW) Primary and unique constraints A transaction can have a WAW dependency, which means a transaction updates or deletes a row that has been inserted or updated by a dependent transaction. This can occur, for example, in a master/detail relationship of primary (or unique) and mandatory foreign key constraints. To understand the difference between the NONCONFLICT_ONLY and the NOCASCADE_FORCE options, assume that the T1 transaction changes rows R1, R2, and R3 and the T2 transaction changes rows R1, R3, and R4. In this scenario, both transactions update row R1, so it is a “conflicting” row. The T2 transaction has a WAW dependency on the T1 transaction. With the NONCONFLICT_ONLY option, R2 and R3 are backed out, because there is no conflict and it is assumed that you know best, what to do with the R1 row. With the NOCASCADE_FORCE option, all three rows (R1, R2, and R3) are backed out. Note: This screenshot is not part of the workflow example, but shows additional details of a more complex situation.
• #35: Choosing Other Back-out Options (continued) The Flashback Transaction Wizard works as follows: If the DBMS_FLASHBACK.TRANSACTION_BACKOUT procedure with the NOCASCADE option fails (because there are dependent transactions), you can change the recovery options. With the Nonconflict Only option, nonconflicting rows within a transaction are backed out, which implies that database consistency is maintained (although the transaction atomicity is broken for the sake of data repair). If you want to forcibly back out the given transactions, without paying attention to the dependent transactions, use the Nocascade Force option. The server simply executes the compensating DML commands for the given transactions in reverse order of their commit times. If no constraints break, you can proceed to commit the changes, or else roll back. To initiate the complete removal of the given transactions and all their dependents in a post-order fashion, use the Cascade option. Note: This screenshot is not part of the workflow example, but shows additional details of a more complex situation.
• #36: Final Steps Without EM The DBA_FLASHBACK_TXN_STATE view contains the current state of a transaction: whether it is alive in the system or effectively backed out. This table is atomically maintained with the compensating transaction. For each compensating transaction, there could be multiple rows, where each row provides the dependency relationship between the transactions that have been compensated by the compensating transaction. The DBA_FLASHBACK_TXN_REPORT view provides detailed information about all compensating transactions that have been committed in the database. Each row in this view is associated with one compensating transaction. For a detailed description of these tables, see the Oracle Database Reference.