Recyclebin with Flashback Table in Oracle 10g

Oracle 10g introduced a new feature of recycle bin. Before oracle 10g if you accidentally dropped a table, the only option to recover that table was incomplete database recovery provided that you have all the required backups. From 10g onwards a DROP TABLE statement doesn't actually drop the table but it puts the table into the database recycle bin from where the table can be recovered with one command. I will go through the recycle bin feature here and we will see how it works. $ sqlplus / as sysdba SQL> show parameter recyclebin NAME TYPE VALUE ---------------------- ----------- ----------recyclebin string ON /* Make sure the recyclebin is ON. */ SQL> 2 3 4 5 create tablespace ts_recyclebin datafile '/d01/apps/oradata/oraxpo/ts_recyclebin01.dbf' size 10m autoextend on next 1m maxsize 50m extent management local segment space management auto;

Tablespace created. SQL> create user test_recyclebin identified by test; User created. SQL> grant connect , resource to test_recyclebin; Grant succeeded. SQL> alter user test_recyclebin 2 default tablespace ts_recyclebin 3 quota unlimited on ts_recyclebin; User altered. SQL> We have setup a tablespace of size 10 mega bytes and created a user with unlimited quota on the tablespace. Now login as the new user from another console leaving the sysdba session intact, and create a table of a significant size. Here I created a table of about 40,000 rows with a size around 5Mb. /* Open another console and login as user test_recyclebin. sysdba session is opened in the other console. */ $ sqlplus test_recyclebin/test

SQL> create table test_recyclebin 2 as 3 select * from all_objects; Table created. SQL> Come back to sysdba session and see how much of the tablespace is consumed by the table we just created. /* Back to sysdba session */ SQL> select d.tablespace_name , 2 round(d.bytes/1024/1024) total_mb , 3 round(d.bytes/1024/1024)4 round(sum(f.bytes)/1024/1024) used_mb, 5 round(sum(f.bytes)/1024/1024) free_mb 6 from dba_data_files d, dba_free_space f 7 where f.file_id = d.file_id 8 and d.tablespace_name = 'TS_RECYCLEBIN' 9 group by d.tablespace_name , d.bytes; TABLESPACE_NAME TOTAL_MB USED_MB FREE_MB ------------------------------ ---------- ---------- ---------TS_RECYCLEBIN 10 5 5 SQL> Lets now drop the table and see what happens to it. /* Back to session test_recyclebin */ SQL> drop table test_recyclebin; Table dropped. SQL> select table_name 2 from user_tables 3 where table_name = 'TEST_RECYCLEBIN'; no rows selected SQL> SQL> SQL> SQL> SQL> 2 column type format a6 column original_name format a16 column ts_name format a13 set lines 10000 select object_name , ORIGINAL_NAME , TYPE , TS_NAME from user_recyclebin;

OBJECT_NAME ORIGINAL_NAME TYPE TS_NAME ------------------------------ ---------------- ------ ------------BIN$hBJrmLxc49DgQAB/AQAmMA==$0 TEST_RECYCLEBIN TABLE TS_RECYCLEBIN SQL> Please note that the table we dropped, is no more there in USER_TABLES but it can be seen in the USER_RECYCLEBIN.

/* Back to sysdba session */ SQL> select d.tablespace_name , 2 round(d.bytes/1024/1024) total_mb , 3 round(d.bytes/1024/1024)4 round(sum(f.bytes)/1024/1024) used_mb, 5 round(sum(f.bytes)/1024/1024) free_mb 6 from dba_data_files d, dba_free_space f 7 where f.file_id = d.file_id 8 and d.tablespace_name = 'TS_RECYCLEBIN' 9 group by d.tablespace_name , d.bytes; TABLESPACE_NAME TOTAL_MB USED_MB FREE_MB ------------------------------ ---------- ---------- ---------TS_RECYCLEBIN 10 0 10 SQL> Here we can see that the space that was being used by the table is released. The used space is 0. As we saw in the recyclebin the table is still there but the tablespace is being shown empty. Now whats happening here is that Oracle actually rename the dropped table instead of actually dropping it and put a record in recyclebin against that table (e.g. in our case the new name of the table is "BIN$hBJrmLxc49DgQAB/AQAmMA==$0"). The table is still there in the same tablespace but the space used by the table is considered as free space now. /* Back to session test_recyclebin */ SQL> flashback table test_recyclebin to before drop; Flashback complete. SQL> select table_name 2 from user_tables 3 where table_name = 'TEST_RECYCLEBIN'; TABLE_NAME -----------------------------TEST_RECYCLEBIN SQL> select object_name , ORIGINAL_NAME , TYPE , TS_NAME 2 from user_recyclebin; no rows selected SQL> This is how we bring a table back from the recycle bin. /* Back to sysdba session */ SQL> select d.tablespace_name , 2 round(d.bytes/1024/1024) total_mb , 3 round(d.bytes/1024/1024)4 round(sum(f.bytes)/1024/1024) used_mb, 5 round(sum(f.bytes)/1024/1024) free_mb 6 from dba_data_files d, dba_free_space f 7 where f.file_id = d.file_id 8 and d.tablespace_name = 'TS_RECYCLEBIN' 9 group by d.tablespace_name , d.bytes;

TABLESPACE_NAME TOTAL_MB USED_MB FREE_MB ------------------------------ ---------- ---------- ---------TS_RECYCLEBIN 10 5 5 SQL> Here you can see the table is back and the tablespace shows 5Mb used. The question that comes to mind next is okay? the space is considered free when the table is in recyclebin, what happens if a new object comes in and need the space? The space being free should be used for the new object, and if that occurs what happens to the table in the recyclebin? /* Back to session test_recyclebin */ SQL> drop table test_recyclebin; Table dropped. SQL> select table_name 2 from user_tables 3 where table_name = 'TEST_RECYCLEBIN'; no rows selected SQL> select object_name , ORIGINAL_NAME , TYPE , TS_NAME 2 from user_recyclebin; OBJECT_NAME ORIGINAL_NAME TYPE TS_NAME ------------------------------ ---------------- ------ ------------BIN$hBJrmLxi49DgQAB/AQAmMA==$0 TEST_RECYCLEBIN TABLE TS_RECYCLEBIN /* Drop a table and verify that it is in the recyclebin. */ SQL> 2 3 4 5 create table test2_recyclebin as select * from all_objects UNION ALL select * from all_objects;

Table created. SQL> analyze table test2_recyclebin compute statistics; Table analyzed. SQL> select table_name , round(blocks*8192/1024/1024) size_mb 2 from user_tables 3 where table_name = 'TEST2_RECYCLEBIN'; TABLE_NAME SIZE_MB ------------------------------ ---------TEST2_RECYCLEBIN 9 /* We created another table with around 80,000 rows and about 9mb in size.

So now we have a 10m auto extend on tablespace with a 5mb hidden object already lying in it. What happens when another 9 Mb object comes in. Even this tablespace is extend able, the space being used by objects in the recyclebin is considered as a free space, so if the new object can fit into the space where recyclebin objects are resting they have to go and make a room for the new objects instead of extending the tablespace. That is called automatic purging of the recyclebin. */ SQL> select object_name , ORIGINAL_NAME , TYPE , TS_NAME 2 from user_recyclebin; no rows selected /* Please note the object in the recycle bin is purged (permanently dropped). So whenever you have objects in recyclebin, then keep watching the space utilization of the new objects in the tablespace. */ SQL> drop table test2_recyclebin; Table dropped. SQL> select table_name 2 from user_tables 3 where table_name = 'TEST2_RECYCLEBIN'; no rows selected SQL> select object_name , ORIGINAL_NAME , TYPE , TS_NAME 2 from user_recyclebin; OBJECT_NAME ORIGINAL_NAME TYPE TS_NAME ------------------------------ ---------------- ------ ------------BIN$hBJrmLxj49DgQAB/AQAmMA==$0 TEST2_RECYCLEBIN TABLE TS_RECYCLEBIN /* Like I said before a dropped object is just renamed with a system generated unique name and can be seen in the recyclebin. We can no more access it with its original name but we can sure use its new name which is the OBJECT_NAME in the user_recyclebin view. */ SQL> select count(*) from test2_recyclebin; select count(*) from test2_recyclebin * ERROR at line 1: ORA-00942: table or view does not exist SQL> select count(*) from "BIN$hBJrmLxj49DgQAB/AQAmMA==$0"; COUNT(*) ---------81378

/* This is how we manually purge objects from recyclebin. */ SQL> purge table test2_recyclebin; Table purged. SQL> select object_name , ORIGINAL_NAME , TYPE , TS_NAME 2 from user_recyclebin; no rows selected SQL> select count(*) from "BIN$hBJrmLxj49DgQAB/AQAmMA==$0"; select count(*) from "BIN$hBJrmLxj49DgQAB/AQAmMA==$0" * ERROR at line 1: ORA-00942: table or view does not exist

SQL> select count(*) from test2_recyclebin; select count(*) from test2_recyclebin * ERROR at line 1: ORA-00942: table or view does not exist

SQL> A table once purged from recyclebin is deleted permanently. There is no record of that table in *_tables and *_recyclebin. Scenerios where you may have multiple objects with same name in and out of recyclebin: /* Back to session test_recyclebin */ SQL> create table samename (first_in number); Table created. SQL> drop table samename; Table dropped. SQL> create table samename (last_in number); Table created. SQL> drop table samename; Table dropped. SQL> select object_name , ORIGINAL_NAME , TYPE , TS_NAME 2 from user_recyclebin; OBJECT_NAME ORIGINAL_NAME TYPE TS_NAME ------------------------------ ---------------- ------ ------------BIN$hBJrmLxk49DgQAB/AQAmMA==$0 SAMENAME TABLE TS_RECYCLEBIN

BIN$hBJrmLxl49DgQAB/AQAmMA==$0 SAMENAME SQL> flashback table samename to before drop; Flashback complete.

TABLE

TS_RECYCLEBIN

SQL> desc samename Name Null? Type --------------------- -------- -----------------------LAST_IN NUMBER SQL> If you have tables with the same original name in the recyclebin and you issue a FLASHBACK TABLE command using the original name, which is not unique in the recyclebin. Which table will be restored? This works in a LIFO (Last In First Out) fashion, i.e. the table that came in the recyclebin last will be restored. SQL> drop table samename; Table dropped. /* This is the table that we just restored with a column LAST_IN in it. I dropped it again. */ SQL> select object_name , ORIGINAL_NAME , DROPTIME 2 from user_recyclebin; OBJECT_NAME -----------------------------BIN$hBJrmLxm49DgQAB/AQAmMA==$0 BIN$hBJrmLxk49DgQAB/AQAmMA==$0 ORIGINAL_NAME ---------------SAMENAME SAMENAME DROPTIME ------------------2010-04-13:03:43:38 2010-04-13:03:40:29

/* Now if a table that didn''t go Last in the recyclebin and is required to be restored then its unique recyclebin name BIN* can be used to restore it. */ SQL> flashback table "BIN$hBJrmLxk49DgQAB/AQAmMA==$0" 2 to before drop; Flashback complete. SQL> desc samename Name Null? Type ---------------------- -------- -----------------------FIRST_IN NUMBER /* The table having column LAST_IN the recyclebin. But the name we unique name for the table which got it back, even it was second */ was the one which came last in used in FLASHBACK command is the has Column FIRST_IN in it and we in the queue.

SQL> flashback table samename to before drop; flashback table samename to before drop * ERROR at line 1: ORA-38312: original name is used by an existing object /* Okay. Now that we already have restored an object with the name "samename", if we try to restore another one with the same name we will get an object already exists error. We can rename a table while flashing it back from recyclebin to overcome duplicate table names problem. Please see below. */ SQL> flashback table samename to before drop rename to samename2; Flashback complete. SQL> desc samename Name Null? Type ----------------------- -------- -----------------------FIRST_IN NUMBER SQL> desc samename2 Name Null? Type ----------------------- -------- -----------------------LAST_IN NUMBER SQL>

FLASHBACK in Oracle 10g database (FLASHBACK TABLE)

This article explain FLASHBACK TABLE capabilities of the oracle 10g database.Flashback table can be of 2 types. 1. Flashback or recover a dropped table with FLASHBACK DROP 2. Flashback a table to a time in the past. Note 1: Only FLASHBACK DATABASE requires flashback to be 'ON' since only FLASHBACK DATABASE uses flashback logs in the flash_recovery_area. All other forms of FLASHBACK use the recycle bin and undo_tablespace and time upto which flashback is possible depends on the initializtion parameter db_flashback_retention_target. Db_flashback_retention_target=1440 (24 hours).

Important info: You cannot 'flashback table to before drop' a table which has been created in the SYSTEM tablespace. The table is sent to the recyclebin only if it existed in some other tablespace other than SYSTEM tablespace and that tablespace must be locally managed. When you drop a table, the objects are temporarily placed in a 'recycle bin' and still belong to the owner. The space used by recycle bin objects is never reclaimed unless there is space pressure. The space associated with the dropped object is not immediately reclaimable although it appears in the DBA_FREE_SPACE view.Query the dba_recyclebin view as SYS or just recyclebin as the user for information about the recycle bin. Flashback drop allows you to recover a dropped table. Example. Connect arjun/arjun Create table tempp (col_1 number(10)) tablespace users; Insert into tempp values (10); 1 row created. SQL> drop table tempp; Table dropped. SQL> show recyclebin; ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------TEMPP BIN$AI2Gp/QiZsPgQAw5yUImEA==$0 TABLE 2005-09-12:10:49:16 SQL> flashback table tempp to before drop; Flashback complete. SQL> select * from tempp; COL_1 ---------10

In case the table is created in the system tablespace an error is thrown if you try to flashback drop :

SQL> show user USER is "SYS"..Default tablespace SYSTEM SQL> create table test (col_1 number(10)); Table created. SQL> drop table test; Table dropped. SQL> select * from dba_recyclebin; no rows selected SQL> flashback table test to before drop; flashback table test to before drop *ERROR at line 1: ORA-38305: object not in RECYCLE BIN QUERYING DROPPED TABLES Dropped tables can be queried from the recycle bin. No DML or DDL operations are allowed on the table. SQL> drop table tempp; Table dropped. SQL> show recyclebin; ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME ---------------- ------------------------------ ------------ ------------------TEMPP BIN$AI9AwvFRdf7gQAw5yUIsGA==$0 TABLE 2005-09-12:13:15:2 While querying the recycle bin, make sure the system generated table name is enclosed in double quotes. SQL> select * from BIN$AI9AwvFRdf7gQAw5yUIsGA==$0; select * from BIN$AI9AwvFRdf7gQAw5yUIsGA==$0 *ERROR at line 1: ORA-00933: SQL command not properly ended

SQL> select * from 'BIN$AI9AwvFRdf7gQAw5yUIsGA==$0'; select * from 'BIN$AI9AwvFRdf7gQAw5yUIsGA==$0' * ERROR at line 1: ORA-00903: invalid table name

SQL> select * from "BIN$AI9AwvFRdf7gQAw5yUIsGA==$0"; COL_1 ---------10 You cannot run any DML or DDL on dropped tables. SQL> Insert into tempp values(20); Insert into tempp values(20) *ERROR at line 1: ORA-00942: table or view does not exist FLASHBACK TABLE TO A TIME IN THE PAST. Firstly enable row movement for the table.In this example the table name is TEST. SQL> ALTER TABLE TEST ENABLE ROW MOVEMENT; TIME : 08:00:00 SQL> select * from test; SALARY ---------5000 TIME :08:00:01 SQL> update test set salary =6000;

1 row updated. SQL> select * from test; SALARY ---------6000 SQL> commit; Commit complete. Now flashback table to time 08:00:00 SQL> FLASHBACK TABLE TEST to timestamp TO_TIMESTAMP( '2005-09-13 08:00:00','YYYY-MM-DD HH24:MI:SS'); Flashback complete. SQL> SELECT * FROM TEST; SALARY ---------5000

Testing a Physical Standby database in oracle 10g If you dont want to deal with missteps, I recommend that you test your standby database to facilitate the failover or switchover process. This procedure is very useful when you have physical standby databases for testing and other purposes that require read-write access to the standby database. Also, it improves your checklist in the event of an error or disaster. By using Snapshot standby databases, redo data is not applied until you convert the snapshot standby database back into a physical standby database, and after all local updates to the snapshot standby database are discarded. Requirements: The following requirements need to be met in order to create a snapshot standby. The Data Guard environment (a primary and a physical standby) needs to be Oracle 10.2.0.1 version or higher. The Primary and Standby databases need to be in archivelog mode (this is a default requirement for Data Guard).

Force logging should be set to TRUE (to avoid no-logging operations). Flash Recovery Area (FRA) is required on the standby database to implement a Flashback database. The Primary and standby are in sync at the time of the test, or the gap between primary and physical standby is nominal. Activation of the standby On the standby database Stop dataguard brokers on standby: SQL> alter system set dg_broker_start=FALSE; Get the SCN SQL> select current_scn from v$database; Cancel the managed recovery: SQL> alter database recover managed standby database cancel; Create the restore point. A restore point can be specified such that it guarantees the database can be recovered to a particular point-intime and eliminates the need to manually record an SCN or timestamp to use with the Flashback database and Flashback table operations: SQL> create restore point TEST_NEW_FEATURE guarantee flashback database; Now confirm the scn from restore point: SQL> col name form a40; SQL> select scn, time, name from v$restore_point where name = 'TEST_NEW_FEATURE'; Prepare the primary Archive logs When using the standby redo logs, this step is essential to ensure that the database can be properly flashed back to the restore point. SQL> alter system archive log current; SQL> alter system switch logfile; SQL> alter system switch logfile; Stop shipment of logs SQL> alter system set log_archive_dest_state_2=DEFER Activate the Physical Standby Activation of the standby: SQL> alter database activate standby database; SQL> startup mount force;

SQL> alter database set standby database to maximize performance; (This is used in case you have not set it before) SQL> alter database open; disable log_archive_dest_2 (this will prevent archive logs being sent to primary): SQL> alter system set log_archive_dest_state_2=DISABLE; Time for testing Once the standby database has been activated, it is a full-blown production system. You may run reports, test new code, or create objects. Remember that any results stored in the activated database will be lost when the database is flashed back to before activation time.. If you need to save the results, they must be copied or exported out of the activated database before flashing it back. Revert the snapshot database to physical standby After testing is completed, you need to resynchronize the activated database with the primary database. Flashback to the restore point: SQL> STARTUP MOUNT FORCE; SQL> FLASHBACK DATABASE TO RESTORE POINT TEST_NEW_FEATURE; SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY; SQL> ALTER SYSTEM SET DG_BROKER_START=TRUE; SQL> STARTUP MOUNT FORCE; Re-enable log shipping on the primary Enable shipment: SQL> alter system set log_archive_dest_state_2=ENABLE To re-enable log shipping on the standby, enable this parameter: SQL> alter system set log_archive_dest_state_2=ENAB Check dgmgrl configuration DGMGRL> show configuration verbose; Current status for xxx: SUCCESS

DGMGRL> enable configuration (if not success) A status of data guard configuration successful indicates the success of the procedures. On Oracle Database 11g, you can use the Data Guard command-line interface (DGMGRL), Oracle Active Data Guard, and the OEM interface. In my next blog Ill describe the equivalent procedures on 11g.