DBA

1 Paper 530

Reviewed by Oracle Certified Master Korea Community

( http://www.ocmkorea.com http://cafe.daum.net/oraclemanager )

AA RREEWWIINNDD BBUUTTTTOONN FFOORR OORRAACCLLEE 1100GG DDAATTAABBAASSEE

–– FFLLAASSHHBBAACCKK BBEESSTT PPRRAACCTTIICCEESS

Availability and protection of the mission-critical data are most important components of IT infrastructure design. The predominant causes of database failures are human errors, which can be particularly difficult to avoid and to recover. Studies show that about 40% of application outages are caused by operator’s operations, such as erroneous or malicious drop statements, data changes (insert/update/delete), and batch job or wide-spread application errors. Major database vendors continue to improve key database reliability factors such as system availability in repairing these errors by minimizing recovery time and the amount of data loss in the event of disaster. Flashback technology is one of the key features within Oracle database products in reducing the mean time to recover (MTTR) from database failures caused by logical data corruption or human errors. Oracle first introduced the concept of flashback in Oracle9i, which provides the capability to “flash back” the database to a prior data image via queries performed against specific logical entities. This is no magic. Flashback Query in Oracle 9i simply relies on Oracle’s existing read consistency model, which uses undo segments (Rollback Segment in prior Oracle version) to build a read consistent snapshot of the data to the point in time. So for a Flashback Query to succeed it is critical to have sufficient UNDO information. However, these capabilities were very limited in Oracle 9i. In Oracle 10g database, the flashback technology goes further. Its architecture leverages the unique flashback technology in providing a single “rewind button” to repair these unpredictable errors and corruptions. This article will discuss the concepts of flashback technology, architecture and configuration, and offer an in-depth insight into a set of flashback features which makes it possible to view and rewind data back and forth in time within the database. The capability of Flashback to query past version of schema objects, query historical data, perform change analysis will also be presented in this paper. Finally, we will demonstrate various real world scenarios for Flashback error correction and provide Flashback solution best practices to protect against the data disasters.

RECOVER DATA FROM HUIMAN ERRORS AND FLASHBACK TECHNOLOGY One of the most central roles of DBA/architect is to define sound and efficient strategy and plan for high availability (HA), data protection (DP) and disaster recovery (DR). To provide powerful HA/DR solutions, it is imperative to analyze the business continuity requirements, and present the most likely data loss scenarios. As mentioned above, human errors are primary causes of the majority of outages in daily IT operations, and they are hard to avoid, then it attracts much attention of database vendors to provide a technology to recover from these human errors or logical errors in a easy and fast way, such like that a user drops the wrong tables, commits data updated with an incorrect “WHERE” clause, and so forth, you can easily get the table or data back without performing any point in time data recovery. Following is an example of these scenarios: The current time is 5:30 PM on Friday. You are ready to leave office and looking forward to spending time with kids on weekend. You just stepped out the office, and your pager was ringing. A message from your human resource department told you that the employee (EMP) table in your HR database couldn’t be found. You rush back to office, and you felt the blood pressure start to rise…. The problem was caused by your training DBA, who by accident dropped the table. The table was dropped around 4:00 PM. The database activity is minimal because most the company staffs are leaving for home. Absolutely, the table has to be recovered… There are various cases caused by human errors. This example is just one of them. There are a few traditional solutions for this scenario. Firstly, the IMPORT utility can be used to bring back the dropped table, because you have full EXPORT data last Sunday. However, this is not a good choice at all for the data recovery! The table dropped is prerry voltile and pretty much change happened with the HR data last week, you will loss trsnasctions. Important consideration using import utility is that

DBA

2 Paper 530

import process is time consuming, you had better perform a import testing on separate database before applying the same onto the production, and depending on the size of the database, these procedures can consume hours or days of precious recovery time. A well known methodology for data recovery in Oracle database is recovery manager (RMAN), and possiblely, this is one of the best choice. The basic requirement for this soultion is that the database run with archive log mode, and you have full backup or incrementall backup implemented within your database system. The advantages of RMAN is that you can recover data prior to the time of failure, such as above case (dropped tables) or deleted data erronerously in important tables, when immediately notified of failure. RMAN can provide data recovery in situation where complete recovery is not possible. However, the disadvantages are obvious, (1) during recovery, the database is taken back in time, so data after this point is lost and must be reentered, (2) the total recovery time is significant, because time to recover the database is the length of time your hardware can backup the existing database, restore all data files from disk or tape, and roll the database forward to a point-in-time before the error, the whole process can take many hours, depending on the size of the database, and (3) since the database must be started in MOUNT until recovery process is completes, the period of downtime might be unacceptable in environments that require a high degree of availability. If the logical errors can be confined to certain tablespaces, then a tablespace point-in-time recovery (TSPITR) can be performed while the rest of the database remains accessible. However, in TSPITR, the appropriate datafiles are still taken offline, restored from backup, rolled forward to the required point-in-time, and finally put back online. Note that the entire tablespace is recovered; included tables that were not affected by logical errors are also recovered to the point-in-time. Leveraged several technology features, Oracle 10g flashback features can perform the query to retrieve the past data, show the detailed history of data changes in row or table level, and recover the tables or rows or database to the point in time. Due to the capability of supporting viewing and rewinding data back and forth in time, Oracle Flashback technology provides the fastest and most efficient method of data recovery from potential diasters. The following tables contains the Oracle 10g flashback new features and the capabilities they offer to query past versions of schema objects, query historical data, analyze database changes, or perform self-service repair to recover from logical corruptions while the database is online.

Flashback Features Capability

Flashback Query This feature lets you specify a target time or SCN in the past and then run queries against your database to view any data at that time using the AS OF clause of the SELECT statement. Can be used to recover from any unwanted changes like an erroneous update to a table.

Flashback Version Query Provides a mechanism to review the changed versions of all rows made to the database in a specified time interval. With this feature, You can also retrieve metadata about the differing versions of the rows, including start time, end time, operation, and transaction ID of the transaction that created the version. Therefore, you can recover lost data values and audit any changes made to the tables queried.

Flashback Transaction Query Lets you view changes made by a single transaction, or by all the transactions during a period of time.

Flashback Table This feature can return a table to its state at a previous point in time. You can easily restore table data while the database is online, undoing changes only to the specified table.

DBA

3 Paper 530

Flashback Drop Undo the effects of a DROP TABLE statement.

Flashback Database This is a new and more efficient strategy for doing point-in-time recovery. It likes a “rewind button” embedded within the database to let you rewind your database to a point in time and correct any problems caused by human errors, data corruption or any other logical data errors.

The features of Flashback Table, Flashback Query, Flashback Transaction Query and Flashback Version Query all rely on the Automatic Undo Management, which was introduced in Oracle9i. Used primarily for such purposes as providing read consistency for SQL queries and rolling back transactions, these undo segments should contain sufficient information required to reconstruct data as it stood at a past time and examine the record of changes since that past time. Flashback Drop uses a mechanism of recycle bin, which is a virtual container for dropped objects. The feature of Flashback database uses a different architecture and a mechanism for quickly rewinding the data back and forth, which will be discussed in next section.

ARCHITECTURE AND CONSIDERATION FOR ORACLE 10G FLASHBACK There are two kinds of Flashback implementations with Oracle 10g Database. Flashback Database provides a new and faster way for database recovery, which looks like a rewind button embeded in the database, it let you easily and quickly recover the database to a point in time in database level. The other features of Oracle10g flashback technology including Flashback Query, Drop Tables, Transactions, and Versions are used in a easy, fast and online way for the recovery of individual rows or individual objects, implementing appropriate Undo Management is the key for these features to succeed.

UNDO MANAGEMENT AND FLASHBACK TECHNOLOGY Oracle firstly introcue concepts of UNDO management from Oracle 9i database release. Leveraged with this, Oracle Flashback features provides a mechanism to rewind data or spcific objects to the snapshot in the past, and make it possible to query past data based on date, time, and System Change Number (SCN). You may ask, how far can you flash back into the past? of course, this depends on how much UNDO information retained in the database's UNDO segments, and is bounded by the time frame specified by the UNDO_RETENTION initialization parameter. The implementation is pretty simple. There are a few UNDO related initialization parameters needed to be assigned appropriate values so that a database is enabled to use the Flashback Query and other flashback features. These parameters are:

• UNDO_MANAGEMENT – setting to AUTO, which ensures that the database is using an undo tablespace. • UNDO_TABLESPACE – Define which undo tablespace to use. The size of UNDO tablespace is another key factor

for flashback features, that determine how much information retains within the UNDO space. For Oracle Real Application Cluster (RAC) environment, each instance has its own UNDO space.

• UNDO_RETENTION - setting this initialization parameter to a value that causes UNDO to be kept for how far you can flashback in time.

• RETENTION GUARANTEE - This is a statement clause used for UNDO tablespace to guarantee that unexpired undo will not be overwritten.

It is very important to understand the effect of UNDO_RETENTION Setting. This parameter obviously will define the time windows the row versions are available. By default, this setting is 900 seconds (15 minutes); for some scenarios, if you want to flashback longer time into the past, of course, you need to set UNDO_RETENTION to a higher value, such as 10800 (3 hours). Absolutely, some databases needs longer UNDO retention durations.

FLASHBACK DATABASE ARCHITECTURE Oracle10g Flashback Datbase feature provides another way of easier, faster, and more efficient point-in-time recovery in case of data corruption or data loss in database level. It is like a rewind button for your database. Architecturally, Oracle 10g introduces a few new concepts for Flashback Database:

DBA

4 Paper 530

(1) Flash recovery area provides a unified storage location for all recovery related files (flashback database logs, archived redo logs, and RMAN backups) within the database. It can be managed via Oracle Managed Files (OMF) or by Oracle Automated Storage Management (ASM). Also, the Flash Recovery Area can be configured to be shared by multiple database instances.

(2) Flashback Database log is another new concept. It is the old versions of changed blocks of the database, and these flashback logs are located at Flash Recovery area. You can think the flashback logs as a continuous backup or storage snapshot.

(3) Flashback buffer is a new cache within SGA. It is used for caching the snapshot of changed data blocks. (4) RVWR (Recovery Writer) is a new background process, which is started whenever Flashback Database is enabled.

Similar to the LGWR (log writer) process, RVWR periodically and sequentially writes the old images of changed data blocks within the flashback buffer as flashback logs onto the Flash Recovery Area.

Flashback database logs are used to quickly back out the data files to any time at which the log is captured just before the desired target time. Then, the redo logs are applied to fill in the gap. This is why Flashback Database reduces the time required to recover the database greatly, because it doesn’t need to restore backups from tape, and no lengthy downtime, and no complicated recovery procedures are required. Therefore, using flashback database as the point in time recovery strategy is just extremely fast and easy to use. In following diagram, Flashback Database architecture is illustrated:

Figure 1: Architecture of Flashback Database

FLASHBACK BEST PRACTICES: VARIOUS SCENARIOS As we discussed above, Oracle 10g Database indeed can undo the past in row, object and database levels. For most logical database errors, Oracle 10g flashback technology provides a simple, powerful, and completely nondisruptive mechanism of data recovery. With the feature of flashback database, you can quickly bring your database back to the point of failure by undoing all the changes that has taken place since time; flashback query, flashback versions and flashback transaction feature let you view the chages to one or more rows with all metadata of changes as well as the corresponding undo SQL statements; flashback table make it possible to recover your table to the point in time without restoring backup; flashback drops provides a way to restore dropped tables and all its dependencies.

Redo Log

Buffer Data Buffer Flashback

Buffer Not every

change Every

change

RVWR

Flashback Logs

RVWR

LGWR

Log block before images

periodically

Back out changes to database without

restore

Redo Logs

Forward media recovery

DBA

5 Paper 530

SCENARIO 1: FLASHBACK QUERY On Monday afternoon, a junior DBA helped to perform emergency maintenance for a developer against the EMPLOYEE table, inadvertently deleted the data for employee ‘PETER’ from the table. After careful researches, the senior DBA knew the approximate time at which this had occurred. This is a common error occurred in daily database activity. Traditionally, you use incomplete recovery method to recover the data to the prior point in time by restoring and recovering from the backups and using archived logs. However, this point in time recovery process may take hours, or even days, or longer because the whole database will be restored from the backup, and then recovered to the point in time just before the error was introduced into the database. Also it may cost data loss. As we discussed above, Oracle Flashback Query allows an administrator or user to query any data at some point-in-time in the past. This powerful feature can be used to view and reconstruct lost data that may have been deleted or changed by accident. To perform the data recovery in above case, firstly, you can issue following statements to display rows from the table employee before the time of logical errors is introduced:

Obviously, this feature is very efficient to empower the end-user, developer or DBA to undo and correct the errors without any delay. Following statement will be issued to recover the data to the prior point of failure:

Flashback Query is extremely simple to manage, as the database automatically keeps the necessary information to reconstruct data for a configurable time into the past. Absolutely, you need to set appropriate UNDO parameters based on the length of the long running queries and logical corruption recovery requirements for your databases.

SCENARIO 2: FLASHBACK VERSION QUERY You are the DBA for a Peoplesoft HR system. On 9:00 AM Monday morning, HR manager sent you an urgent email regarding some abnormal changes of your employee table data during weekend. Yor are asked to retrieve the information about the transactions that changed the rows of employee table. This is an common scenario for data auditing. For the perspective of data security, sometime, we need to know what changes have been made, when the changes happened, and who did the changes. Oracle 10g Flashback Version Query provides a easy way for data auditing. It can retrieve all committed versions of the rows that exist or ever existed between the time the query was issued and a point in time in the past, as long as those versions are still available within the UNDO tablespace's rollback segments. A new pseudocolumn VERSIONS_XID is introduced as a transaction identifier of the corresponding version of a row, and the transactionVERSIONS clause is used to retrieve all of the versions of the rows that exist between two points in time or two SCNs. The rows returned by Flashback Versions Query present a history of the rows across transctions. It is worth to mention that Flashback Versions Query only return comitted transactions.

SELECT * FROM hr.employee AS OF TIMESTAMP TO_TIMESTAMP('02/02/2005 11:55:00', 'MM/DD/YYYY HH24:MI:SS') name = ‘PETER’;

INSERT INTO hr.employee (SELECT * FROM hr.employee AS OF TIMESTAMP TO_TIMESTAMP ('02/02/2005 11:55:00', 'MM/DD/YYYYHH24:MI:SS') WHERE name = ‘PETER'); COMMIT;

SELECT versions_xid, versions_operation, employee_name FROM hr.employee VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('03/15/2005 15:30:00', 'MM/DD/YYYY HH24:MI:SS') AND TO_TIMESTAMP('03/15/2005 16:10:00', 'MM/DD/YYYY HH24:MI:SS') WHERE versions_operation IS NOT NULL;

DBA

6 Paper 530

/0

This example present the transaction history made on the employee table during specified time period. Obviously, this feature is powerful tool for data auditing, system analysis and answering some questions such like ‘How did this happen?’ Any user or developer can use this feature if they are grant the SELECT and FLASHBACK privileges. However, when using Flashback Version Query, there exists following limitations:

• VERSIONS BETWEEN clause cannot be used for External Tables, Temporary Tables, and Fixed Tables.

• VERSIONS BETWEEN clause cannot be used for views

• VERSIONS BETWEEN cannot produce versions of rows across DDL statements that changes the table structures

• VERSIONS BETWEEN can be used in the subqueries of DDL and DML statements

• ORA-30052 error if not appropriate UNDO_RENTION

SCENARIO 3: FLASHBACK TRANSACTION QUERY

According the Scenario 2, you have found some changes happening on you employee table. These transactions include the UPDATE, DELETE, and INSERT. However, you are required to know what operations have been made on the transaction level, how to undo the changes back to its before immages, and finally use the undo DML to recover the data. This is an urgent need for HR department. Users sometimes issue erroneous DML against the database. With Oracle 8i and 9i, LogMiner and DBMS_FLASHBACK package can be used to recover user error to some extent. But it is time sonsuming and not convenient. Oracle 10g Flashback Transaction Query is a very relible and efficient diagnostic tool to view change made to the database on transaction level, and to perform analysis and audits of transactions, and fastly to generate the undo DML for data recovery to the point of failure. FLASHBACK_TRANSACTION_QUERY is a view within Oracle 10g database to determine all the necessary SQL information that can be used to undo the chnages that were made by a specific transaction during a specific time period. The view has following columns:

This is is a great tool! You can easily find out what has been done, and produce the UNDO SQL (DML statement) to perform data recovery. Moreover, Flashback Transaction Query and Flashback Versions Query discussed above are complementary each other, and working together you can easily fix the user errors caused by erroneous DML. With Flashback Versions Query, you can easily find the transaction identifier (VERSION_XID) of changed rows of interests, and with Flashback Transaction Query, you can see exactly what operations were made by the transaction and what necessary SQL statements shoud be executed to undo the erronerous changes. Following is an SQL example example for using both feature to recover erroneous

data:

Name Null? Type ----------------------------------------- -------- -------------------- XID RAW(8) START_SCN NUMBER START_TIMESTAMP DATE COMMIT_SCN NUMBER COMMIT_TIMESTAMP DATE LOGON_USER VARCHAR2(30) UNDO_CHANGE# NUMBER OPERATION VARCHAR2(32) TABLE_NAME VARCHAR2(256) TABLE_OWNER VARCHAR2(32) ROW_ID VARCHAR2(19) UNDO_SQL VARCHAR2(4000

SELECT version xid, ename FROM emp VERSIONS BETWEEN TO_TIMESTAMP('03/15/2005 15:30:00', 'MM/DD/YYYY HH24:MI:SS') AND TO_TIMESTAMP('03/15/2005 16:10:00', 'MM/DD/YYYY HH24:MI:SS') WHERE empno = ‘7900’;

DBA

7 Paper 530

From above SQL statement, you want to find the transaction id (version_xid) for employee 7900 during the speified time window, the results show that the VERSION_ID is 0400260021450000. Then, you will the VERSION_ID in following SQL statement to produce UNDO DML to recover the errorenous data changes by this transaction:

Then, following is the result of the query on FLASHBACK_TRANSACTION_QUERY:

Use above undo SQL statement, you can rollback the erroneous changes.

SCENARIO 4: FLASHBACK TABLE The current time is 12 PM on April 2, 2005. Your HR user run an erroneous DML while trying to fix the employee tablel data, some of the employee data lost. You are required to recover the data ASAP. As the DBA, more or less you experience table data loss by user error. Absolutely, you can use RMAN for performing incomplete recovery to the point of failure. However, as mentioned above, this point in time recover process is pretty inconvenient, takes lengthy time, and causes possible downtime and data loss. With Oracle 10g Flashback table feature, you can easily recover a set of tables to a specific point in time without having to perform traditional point-in-time recovery operations, even user can perform self-service correction from data modification to table by erroneous DML without DBA’s help. Most importantly, the data recovery process with Flashback table feature is quick, easy and online in term of ease of use, availability and faster restoration with point-in-time object based recovery. Like flaskback query, to implement Flashback Table feature, you have to configure UNDO_TABLESPACE and UNDO_RETENTION to guanantee enough space to hold undo data, and time for retaining undo data. Appropriate undo information can control how far back in time a table can be repaired using this feature. Because Flashback Table feature does not preserve the original row IDs, it is necessary to enable row movement on the impacted tables first before performing the flashback table. Following is the example to use timestamp to flashback table to the point in time. You can combine Flashback Version Query and Flashback Transaction Query to determine the appropriate flashback time or SCN.

SELECT operation, undo_sql FROM FLASHBACK_TRANSACTION_QUERY WHERE xid = HEXTORAW(‘0400260021450000’);

OPERATION UNDO SQL --------- ------------------------------------------------------------- UPDATE update “SCOTT”.”EMP” SET “SAL” = ‘1000’ where ROWID = ‘AAAP93AAGAAAAVAAAA’;

ALTER TABLE emp ENABLE ROW MOVEMENT;

DBA

8 Paper 530

The benefits of using flashback table are significant. Not only can it be used as a self-service repair tool for developer, users, and DBA to recover from accidental deletion or erroneous modifications, also, it can be incorporated within an application to customize the data manipulation. Except the advantages mentioned above, flashback table process can automatically restores all attributes associated with the table, such as indexes and triggers, and maintains the dada integrity with preserving all dependent objects and referential constraints. If you have a distributed environments, all of the table modifications required by replication are flashed back. However, there exists following limitations when performing the flashback table function:

- Executed within a single transaction - Acquire exclusive DML locks - Statistics are not flashbacked - Can’t across DDL operation - Can’t Flashback system tables

SCENARIO 5: FLASHBACK DROP TABLE The current time is 12 PM on April 5, 2005. Your training DBA just told you that he dropped the HR employee table. The table was dropped around 11:45 AM. The database activity is minimal because most staff are currently in a meeting. The table must be recovered. Accidental drop of table or other objects are always a problem for database users and DBAs. In most cases, when users realize the erroneous action, then it is already too late. Unfortunaltely, there is no easy way to recover the dropped objects. Traditionally, You can either use IMPORT/EXPORT utility depending your data size and data volatility, or perform incomplete recovery to bring the data to the point in time by using RMAN. However, these methods are time consuming, and may cause dowtime or result in other kind of data loss. With Oracle 10g Flashback Drop feature, you can just undo the effects of a DROP TABLE statement without having to use point-in-time recovery. It is easy, quick and online! Oracle 10g Flashback Drop Table feature introduces the mechanism of Recycle Bin within the database, which is a virtual container where all dropped objects reside. When a table is droped, the table and its associated objects and constraints are moved to the Recycle Bin, and their names are changed by Oracle with a prefix of BIN$$, but still belong to their owner and are occupying the same storage. Of course, the dropped table can be purged permanently. Following is a example of drop/undrop table:

Also, you can recover the drop table with a different name:

Recycle Bin is a data dictionary, and you can query the content of the recycle bin by using the DBA_RECYCLEBIN or USER_RECYCLEBIN view. To view the contents of Recycle Bin at database level or user level, following query can be used:

FLASHBACK TABLE emp TO TIMESTAMP TO_TIMESTAMP('03/15/2005 15:30:00', 'MM/DD/YYYY HH24:MI:SS') ;

DROP TABLE emp;

FLASHBACK TABLE emp TO BEFORE DROP;

FLASHBACK TABLE emp TO BEFORE DROP RENME TO employee;

SELECT owner, original name, object name, type, ts_name, droptime, related, space FROM user_recyclebin WHERE can_undrop=’YES’;

DBA

9 Paper 530

As long as the space used by recycle bin objects is not reclaimed, you can recover those objects by Flashback Drop. The space used by the table and its dependent objects are not immediately reclaimable. Generally, although the dropped table is in Recycle Bin, but its associated space is reported in DBA_FREE_SPACE view because its space is automatically reclaimable. Whenever the space is under pressure, it will be reclaimed automatically, the recycle bin objects will be purged using FIFO mechanism, such as the table owner creates a new table or adds data that causes the quota to be exceeded, or DBA extends the file size within the tablespace to accommodate create/insert operations. The space can be manually cleaned up with PURGE statement. Using PURGE command can permanently remove objects from the recycle bin. Also, when an object is purged from recycle bin, it and its dependent objects are permanently removed from database. Following are a few examples of use of PURGE statements:

Dropped wrong table? Not a big deal, just undrop it using Oracle 10g Flashback drop feature. However, there are following limitations for using Flashback Drop:

- Flashback Drop only uses for non-system tables.

- Flashback Drop only uses for locally managed tablespaces.

- Flashback Drop not uses for tables associated with Fine-Grained Auditing (FGA) or Virtual Private Database (VPD).

- When table dropped, its dependent bitmap join indexes, referential integrity constraints, and materialized view logs are not protected with Recycle Bin.

SCENARIO 6: FLASHBACK DATABASE The current time is 12 PM on April 5, 2005. Your training DBA just told you that he purged the HR employee table. The table was purged around 11:45 AM. The database activity is minimal because most staff are currently in a meeting. Definitely, you can not Flashback the droped tables using Flashback Drop features. The table must be recovered. You may be tired of any human errors like this scenario, what to do for this? your answer may be RMAN or IMPORT or other incomplete recovery method. However, none of these methods is easy and can get rid of the possible down time. As mentioned above, Oracle 10g provide a fast and efficient solution to get your data back to a privous time, just like pushing a rewind button. This is a mracle, because it can be used to correct any problems caused by logical data corruptions or user errors without the need to restore a database backup from tape. It is fast, the time to restore a database is proportional to the number of block changes that need to be backed out, not the size of the database. Actually, Flashback database is similar to conventional point-in-time recovery, it is accessed by RMAN or SQL*Plus.To implement Flashback database feature, you need to configure flash recovery area to provide a unified storage location for all recovery related files (flashback database logs, archived redo logs, and RMAN backups) and activities within the database.

SELECT owner, original name, object name, type,ts_name, droptime, related, space FROM dba_recyclebin WHERE can_undrop=’YES’;

SHOW RECYCLEBIN;

PURGE TABLE emp;

PURGE TABLESPACE users;

PURGE TABLESPACE hr data USER hr;

PURGE [USER |DBA ]RECYCLEBIN;

DBA

10 Paper 530

Flashback database logs are the snapshot of changed blocks within the database written by RVWR peridocally. The storage size of flash recovery area should be managed carefully, because the size of flashback database log can vary considerablly, depending on how much data changes against the database during a given flashback-logging period. The more database changes occur, the bigger the size of Flashback Logs. Using the flashback database log plus redo logs will make the recovery process faster and more efficient. The database recovery will be in minutes instead of hours. Another significant benefit of Flashback database is its use with Data Guard both on primary and standby database. It can quickly recover the data to the point-in-time from the user errors, even these user errors were already applied to the standby database due to the enabled Real Time Apply function, you can just easily flashback the standby database to the previous time. You may ask the performance overhead cost? Statistics show that the enabling flashback database is less than 2%, which will be acceptable for trading off the data loss and downtime. Following is the implementation procesudres for Flashback Database: Step 1: Make sure the database is in archive log mode. Step 2: Define Flash Recovery Area

a. Use Database Control

b. Mannually configure Flash Recovery Area:

DB_RECOVERY_FILE_DEST – defining this parameter as a location and destination for Flash Recovery files DB_RECOVERY_FILE_DEST_SIZE – speifiy the disk limit, which is the amount of space the flash area is permitted to use. Example:

ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE 4G; ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = ‘C:\oracle\flask_area’;

DBA

11 Paper 530

DB_RECOVERY_FILE_DEST_SIZE has to be specified before the DB_RECOVERY_FILE_DEST initialization parameter. For using Oracle RAC, all instances must have the same values for these two parameters.

Step 3. Open the database in MOUNT EXCLUSIVE mode and turn on the flashback feature:

Step 4: Set the Flashback Database retention target:

DB_FLASHBACK_RETENTION_TARGET parameter defines an upper time limit in minutes on how far you want to be able to flashback the database. In this example, it is set 10080 minutes, which represents a week. However, this parameter just defines a target number, not guaranteed. The actual time period depends on the flashback log data in the flash recovery area. To determine if Flashback Database is enabled, issue the following command:

Flashback Database commands can be executed with RMAN or SQL environments. You can use Flashback Database to Time, SCN, and also, use SEQUENCE and THREAD to specify a redo log sequence number and thread as an upper limit. Like traditional incomplete recovery method, you need to open database with RESETLOGS after the flashback. Using RMAN commands:

Using SQL Commands:

Also, you can exclude tablespace from Flashback Database:

Flashback Database processes can be monitored using following views: V$FLASHBACK_DATABASE_LOG

SQL> STARTUP MOUNT EXCLUSIVE; SQL> ALTER DATABASE FLASHBACK ON;

ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET = 10080;

SQL> select flashback_on from v$database; FLASHBACK_ON ------------ YES

RMAN> FLASHBACK DATABASE TO TIME = Time Stamp Format; RMAN> FLASHBACK DATABASE TO SCN = n; RMAN> FLASHBACK DATABASE To SEQUENCE=m THREAD=n;

SQL> FLASHBACK DATABASE TO TIMESTAMP (…);SQL> FLASHBACK DATABASE TO SCN m;

ALTER TABLESPACE tbs_name FLASHBACK {ON|OFF};SELECT name, flashback_on FROM v$tablespace;

DBA

12 Paper 530

V$FLASHBACK_DATABASE_STAT To summarize, here are the benefits of flashback database feature:

- Fast recovery, no need to restore a back, and costs less down time.

- Seamlessly integrated withh Data Guard and eliminate the standby database redo apply delay

- Efficient correction for any user errors or logical data corruption. By contrast with above benefits, Flashback Database feature has following limitations:

- Can’t use Flashback Database feature if the control file was restored or recreated after Flashback dabase is enabled

- A data file cannot be flashed back to a time before the RESIZE operation. This restriction only apply the manual RESIZE operation, not for automatic space extension

- Can’t flashback the media failures such as a data file or tablespace was dropped or corrupted. In this case, whenever a data file or tablespace is dropped, it is written to control file, and will be marked offline, it can not be flashed back. Need to recover the lost data file or tablespace after flashback operation.

- The SCN you want to flashback to must EXIST in the flashback logs. Due to space pressure, the flashback log may be deleted. In this case, you canot flashback your database to the SCN prior to the earlist SCN within the flashback logs.

COLLUSION Predominant causes of system failures are human errors and logical data corruption. These errors can be particularly difficult to avoid. Historically, there are no easy ways to recover data to the point-in-time of failure quickly and efficiently. With the addition of Flashback technology, the time to recover from the errors is equal to the time for causing data errors; it is easy, fast and most importantly online. Flashback Technology with Oracle 10g has significantly improved the availability of a database while it's restored and recovered to the desired point in time.