Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director

Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director carl.dudley@wlv.ac.uk

2 Introduction Working with Oracle since 1986 Oracle DBA - OCP Oracle7, 8, 9, 10 Oracle DBA of the Year – 2002 Oracle ACE Director Regular Presenter at Oracle Conferences Consultant and Trainer Technical Editor for a number of Oracle texts UK Oracle User Group Director Member of IOUC Day job – University of Wolverhampton, UK

3 Flashback Techniques for Oracle Database 11g and The Next Generation Flashback Queries Flashback Row and Transaction History Flashback Transaction Backout Flashback Table Flashback Drop Flashback Database Flashback Data Archive Valid Time Support

4 Flashback Queries - SQL Level Flashback  Principal uses of flashback query : —Repair bad data —Collect and review recent data values over time  To observe flashback using SQL —Requires FLASHBACK privilege on the table CREATE TABLE changes_today AS SELECT * FROM employees MINUS SELECT * FROM employees AS OF TIMESTAMP TRUNC(SYSDATE); – To observe new records added today SELECT * FROM department AS OF TIMESTAMP TO_TIMESTAMP('03-MAR-2013 09:30:00');

5 Flashback Queries - Session Level Flashback  To observe data from several queries at a point in time using PL/SQL —Requires execute privilege on dbms_flashback Known as session level flashback dbms_flashback.enable_at_time('22-NOV-2012 11:00:00AM'); SELECT... FROM... ; SELECT... FROM... ; -- No DML or DDL allowed SELECT... FROM... ; dbms_flashback.disable; —If only a date is specified, time element defaults to 12 midnight  Useful when using 3 rd party apps and you cannot touch the code —Simply put the session back in time

6 Flashback Query Limitations  Flashback is enabled at nearest SCN to the specified time rounded down to a 3 second interval — SCN s are mapped to times only once every 3 seconds —Need to know SCN s to flashback more accurately  Alterations to tables (and indexes) since flashback time will cause errors — Avoid flashing back to a time close to a DDL statement System could happen to choose an SCN earlier than the DDL statement  Correspondence of SCN s to timestamps are shown in rows generated at five minute intervals in smon_scn_time —But the RAW column, tim_scn_map, holds up to 100 mappings within its raw data This allows efficient fine-grained 3 second mapping

8 Flashback Row History  Shows row version data plus : —Start and end times of the version ( SCN s and timestamps) —Transaction ID for every version of the row during the specified period EMPNO SAL ST XID ----- ---- ------------------ ----------------- 7766 8000 01-MAR-13 05.32.38 06001F0014170000 7766 7120 01-MAR-13 05.28.45 04002C00151B0000 7766 6300 01-MAR-13 05.26.14 0200290017370000 — Returns the salary for each transaction affecting the row, as follows: SELECT empno,sal,versions_starttime st,versions_xid XID FROM empf VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('01-MAR-13 05.24.02') AND TO_TIMESTAMP('01-MAR-13 05.35.02'); WHERE empno = 7766; — No need for audit tables? — Does not show any inserts and deletes due to online shrink operations

9 Flashback Transaction History - Scenario  Build a table with some data CONNECT scott/tiger CREATE TABLE empf(empno NUMBER PRIMARY KEY,ename VARCHAR2(16),sal NUMBER); Sleep for a short time INSERT INTO empf VALUES(7950, 'BROWN', 3000); INSERT INTO empf VALUES(8888, 'GREEN', 4000); INSERT INTO empf VALUES(1111, 'WHITE', 1000); COMMIT; EMPNO ENAME SAL ----- --------- ----- 7950 BROWN 3000 8888 GREEN 4000 1111 WHITE 1000  Contents of table empf

10 Flashback Transaction History – Scenario (continued) DELETE FROM empf WHERE empno = 7950; UPDATE empf SET sal = sal + 3000 WHERE empno = 8888; COMMIT;  Bad transaction correctly deletes a row, incorrectly updates the other EMPNO ENAME SAL ----- -------- ----- 8888 BROWN 6000 1111 WHITE 1000 UPDATE empf SET sal = sal + 400 WHERE empno = 8888; UPDATE empf SET sal = sal + 250 WHERE empno = 8888; COMMIT;  New transaction updates a remaining row with new values EMPNO ENAME SAL ----- -------- ----- 8888 BROWN 6650 1111 WHITE 1000

11 Finding the Errant Transaction  The DBA decides that there has been an error and interrogates the versions of the rows (row history) for transaction information — Top row is the final transaction, second row is the error SELECT versions_xid XID,versions_startscn START_SCN,versions_endscn END_SCN,versions_operation OPERATION,ename,sal,empno FROM empf VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE; XID START_SCN END_SCN O ENAME SAL EMPNO ---------------- --------- --------- - ------ ----- ------ 05002500BE000000 428380 U BROWN 6650 8888 05001800BE000000 428372 428380 U BROWN 6000 8888 05001800BE000000 428372 D GREEN 4000 7950 04001600BE000000 428365 I WHITE 1000 1111 04001600BE000000 428365 428372 I BROWN 3000 8888 04001600BE000000 428365 428372 I GREEN 4000 7950

12 Auditing the Transaction  Obtain the UNDO of the original SQL for the entire bad transaction —Requires SELECT ANY TRANSACTION system privilege  Decide how to use this information to repair the data SELECT xid, undo_sql FROM flashback_transaction_query WHERE xid = '05001800BE000000'; XID UNDO_SQL ---------------- ----------------------------------------- 05001800BE000000 update "SCOTT"."EMPF" set "SAL" = '3000' where ROWID = 'AAAMUDAAEAAAAIXAAB'; 05001800BE000000 insert into "SCOTT"."EMPF"("EMPNO","ENAME","SAL") values ('7950','GREEN','4000');

13 Performance of flashback_transaction_query  Searches on flashback_transaction_query can take some time —The xid column is indexed but it is RAW(8) To use the index, specify HEXTORAW( ‘ ’ ) in the WHERE clause  Consider flashback_transaction_query with approximately 40,000 rows SELECT xid, undo_sql FROM flashback_transaction_query WHERE xid = '070017004A090000'; 15.51 secs SELECT xid, undo_sql FROM flashback_transaction_query WHERE xid = HEXTORAW('070017004A090000'); 0.04 secs

15 Flashback Transaction (Transaction Backout)  Rolls back a transaction and all or some of its dependent transactions —Gives fine control over how and which transactions are backed out  Dependent transactions are those that : a.Have written to the same data after the target transaction Called Write After Write (WAW) b.Re-insert a primary key value that was deleted by the target transaction  Uses undo, redo and supplementing logging information  Creates compensating transactions that can be executed —Controlled by user with commit, rollback statements

16 Flashback Transaction Requirements  Database must be in ARCHIVELOG mode and COMPATIBLE >= 11.1.0.0  Requires additional redo logging 1.Minimal supplemental logging 2.Logging of primary key values for any row that is changed Must start work using archived logs – hence at least one log has to be archived since start of operation —Force an archive : Flashback makes use of LogMiner  User requires privileges — SELECT ANY TRANSACTION — EXECUTE on dbms_flashback ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER SYSTEM ARCHIVE LOG CURRENT;

17 dbms_flashback.transaction_backout  Can back out a set of transactions —Analyzes dependencies —Performs the DML to backout the transactions —Produces dictionary information dba_flashback_txn_state –Shows whether a transaction is active or backed out dba_flashback_txn_report –Detailed report of backed out transactions  Example syntax : dbms_flashback.transaction_backout ( numberofxidsNUMBER xidsXID_ARRAY optionsNUMBER DEFAULT NOCASCADE timehintTIMESTAMP DEFAULT MINTIME) — options can take values 1, 2, 3, 4

18 Flashback Transaction Controls  Can dictate cascading effects on dependent transactions via the enumerated type options  The routine performs the necessary DML and holds locks on the data items —Does not commit – left as a decision for the user  Can be traced using EVENTS = "55500 TRACE NAME CONTEXT FOREVER, LEVEL 2" Backout mode ( options ) Number valueResult NOCASCADE 1 Error generated if dependencies exist NOCASCADE_FORCE 2 The specified transactions are entirely backed out without handling any dependencies NOCONFLICT_ONLY 3 Only changes having no dependencies are backed out CASCADE 4 All changes made by the transaction(s) and all its dependents are completely backed out

19 Collecting Information  Situation after committing the results of the CASCADE option SELECT * FROM dba_flashback_txn_state; COMPENSATING_XID XID DEPENDENT_XID BACKOUT_MODE USERNAME ---------------- ---------------- ---------------- ------------ -------- 0E000700F2020000 140011008D010000 CASCADE SYS 0E000700F2020000 0D001A0089020000 140011008D010000 CASCADE SYS SELECT * FROM dba_flashback_txn_report; COMPENSATING_XID : 0E000700F2020000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_8388645_TIM_1235938019 COMMIT_TIME : 01-MAR-13 XID_REPORT : <COMP_XID_REPORT XID="0E000700F20200 USERNAME : SYS

20 Backing out Transactions Example DECLARE v_xids sys.XID_ARRAY := sys.xid_array(); BEGIN v_xids.extend; v_xids(1) := HEXTORAW('05001800BE000000'); sys.DBMS_FLASHBACK.TRANSACTION_BACKOUT(numtxns => 1, xids => v_xids, options => 4,scnhint => 0); END; /  Populates the transaction array ( v_xids ) with just one transaction id —Array is passed to the transaction_backout procedure  options parameter set to 4 ( CASCADE ), causes backout of any dependent transactions (WAW)  The scnhint is an alternative to timehint —Default is related to retention period in undo tablespace The bad transaction id

21 v$flashback_txn_mods EXEC scott.pt('SELECT * FROM v$flashback_txn_mods') COMPENSATING_XID : 080008009A210000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_1576008_TIM_1312991793 XID : 060010002F210000 TXN_NAME : PARENT_XID : 060010002F210000 INTERESTING : 1 ORIGINAL : 1 BACKOUT_SEQ : 2 UNDO_SQL : update "FRED"."STOCK" set "NAME" = 'IBM', "CTIME" = TO_TIMESTAMP('10-AUG-11 16.48.40.781000') where "ST_ID" = '2' and "NAME" = 'HP' and "PRICE" = '11' and "CTIME" = TO_TIMESTAMP('10-AUG-1116.49.10.859000') and ROWID = 'AAAUe2AAEAAAbVEAAB' UNDO_SQL_SQN : 1 UNDO_SQL_SUB_SQN : 1 BACKOUT_SQL_ID : 2 OPERATION : UPDATE BACKEDOUT : 1 CONFLICT_MOD : 0 MODS_PER_LCR : 1 ----------------- COMPENSATING_XID : 080008009A210000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_1576008_TIM_1312991793 XID : 060010002F210000 TXN_NAME : PARENT_XID : 060010002F210000 INTERESTING : 1 : :

22 v$flashback_txn_graph EXEC scott.pt('SELECT * FROM v$flashback_txn_graph') COMPENSATING_XID : 080008009A210000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_1576008_TIM_1312991793 XID : 060010002F210000 TXN_NAME : PARENT_XID : 060010002F210000 INTERESTING : 1 ORIGINAL : 1 BACKOUT_SEQ : 2 NUM_PREDS : 0 NUM_SUCCS : 1 DEP_XID : 08001E0099210000 DEP_TXN_NAME : TXN_CONF_SQL_ID : 1 DEP_TXN_CONF_SQL_ID : 3 CONFLICT_TYPE : WRITE AFTER WRITE ----------------- COMPENSATING_XID : 080008009A210000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_1576008_TIM_1312991793 XID : 08001E0099210000 TXN_NAME : PARENT_XID : 08001E0099210000 INTERESTING : 1 ORIGINAL : 0 BACKOUT_SEQ : 1 NUM_PREDS : 1 NUM_SUCCS : 0 DEP_XID : 0000000000000000 DEP_TXN_NAME : TXN_CONF_SQL_ID : 0 DEP_TXN_CONF_SQL_ID : 0 CONFLICT_TYPE :

24 Flashback Table Functionality  Enables fast recovery of a table to a previous point in time (SCN or timestamp) —Table has an exclusive DML lock while it is being restored  Requirements for use — FLASHBACK ANY TABLE system privilege or FLASHBACK object privilege on table — SELECT, INSERT, UPDATE, DELETE privileges on the table —Table must have row movement enabled ( ROWID s are not preserved)  Automatically restores all dependent objects — Indexes dropped since flashback point will be synchronized with flashback table — Indexes created after the flashback point will be dropped — Statistics are not flashed back  Works only if constraints are not violated —Referential integrity constraints are maintained across all tables A violation causes a rollback of the flashback statement  Data in the original table is not lost after a flashback —You can later revert to the original state

25 Using Flashback Table 1.Use flashback row and transaction history to find position for flashback —Record current SCN at time of flashback if a reversal of the operation is required Found in v$database.current_scn or via dbms_flashback.get_system_change_number 2.Perform the flashback table operation FLASHBACK TABLE t1 TO TIMESTAMP TO_TIMESTAMP('2013-03-01 12:05:00') ENABLE TRIGGERS; FLASHBACK TABLE t1 TO SCN 12345; —Triggers are not enabled by default during a flashback operation

26 Global Temporary Table  On executing FLASHBACK TABLE, a global temporary table called sys_temp_fbt is created in the user schema —Rows are inserted using INSERT APPEND Rows are removed when session is terminated but the table is not dropped —The sys_temp_fbt tracks ROWID s of affected rows Name Type -------------- ------------ SCHEMA VARCHAR2(32) OBJECT_NAME VARCHAR2(32) OBJECT# NUMBER RID ROWID ACTION CHAR(1)

27 Use of Temporary Table - Scenario  Update of one row generates 2 entries for each row in same block  Deletes and inserts generate one entry for each row that is changed —2 entries for other rows in the same blocks  Scenario 1Create a table ( ef ) containing 14336 rows (143 rows per block) 2Enable row movement FLASHBACK TABLE ef TO TIMESTAMP TO_TIMESTAMP(' '); 5 Perform a flashback UPDATE ef SET deptno = 99 WHERE ROWNUM = 1; 4 Update a single row SELECT systimestamp FROM DUAL; 3 Find current timestamp ALTER TABLE ef ENABLE ROW MOVEMENT;

28 Use of Temporary Table – Scenario (continued)  Update of one row causes 286 entries (2*143) in the temp table UPDATE ef SET deptno = 99 WHERE ROWNUM < 145; Generates 572 (2*286) rows in the temporary table SELECT rid,action FROM sys_temp_fbt; RID ACTION ------------------ ------ AAANAIAAEAAAAJMAAA D AAANAIAAEAAAAJMAAB D AAANAIAAEAAAAJMAAC D AAANAIAAEAAAAJMAAA I AAANAIAAEAAAAJMAAB I AAANAIAAEAAAAJMAAC I SELECT ROWID,deptno FROM ef; ROWID EMPNO ------------------ ----- AAANAIAAEAAAAJMAAE 7369 AAANAIAAEAAAAJMAAF 7900 AAANAIAAEAAAAJMAAG 7654 —Changes ROWID s of all rows in the updated blocks in the ef table Example scenario shows only a subset of rows in affected block UPDATE ef SET deptno = 99 WHERE empno = 7369; (7369 is present every 14 rows) Generates 28672 rows in the temporary table

29 Flashback Table Restrictions  Cannot flashback a table : —Past a DDL operation —Owned by sys —When in the middle of a transaction —If undo information is not available  Flashback operation cannot be rolled back —But another flashback command can be issued to move forward in time

31 Flashback Drop and the Recycle Bin  Dropping a table places the table in the recycle bin —Makes it possible to recover a table at a later time using  Does not protect against an erroneous TRUNCATE  Different to flashback table as it does not use rollback data  Dropped objects continue to count against user quotas until purged  Oracle will purge dropped tables in preference to extending autoextensible files —Dependent objects (indexes) are purged before tables —Purging is performed on a first-in, first-out basis  Dropping a tablespace, or a user does not place any objects in the bin —Purges the bin of any objects belonging to that tablespace or user

32 Renaming Tables in the Recycle Bin  The renaming avoids name clashes across different users —Prevents clashes if tables are dropped, rebuilt with same name and dropped again —Example name - BIN$xyWe0+q+SniItJ0pn/u54A==$0  Indexes, constraints and triggers of dropped tables are also held in recycle bin  Some classes of dependent objects are not protected —Bitmap join indexes —Materialized view logs —Referential integrity constraints  Data can be queried in 'binned' tables as follows SELECT * FROM “BIN$xyWe0+q+SniItJ0pn/u54A==$0” [AS OF...]; — Cannot perform DML/DDL on recycle bin objects

33 Purging Objects in the Recycle Bin  Object(s) can be purged from the recycle bin PURGE DBA_RECYCLEBIN;  Users with SYSDBA privilege, can purge the entire recycle bin PURGE RECYCLEBIN; PURGE TABLESPACE user1; PURGE INDEX "BIN$FTX34MN88J7==$0”; PURGE TABLESPACE user1 USER fred; PURGE TABLE emp; purges earliest dropped version of emp PURGE TABLE “BIN$xyWe0+q+SniItJ0pn/u54A==$0”; purges specified version of a dropped table

34 Restoring Objects in the Recycle Bin  Table reverts to its original name in both cases — Dependent objects are recovered (except referential constraints) — Indexes and constraints keep their 'binned' name  Use RENAME to avoid name clashes with new objects of the same name FLASHBACK TABLE “BIN$xyWe0+q+SniItJ0pn/u54A==$ TO BEFORE DROP; FLASHBACK TABLE emp TO BEFORE DROP;  Flashback drop will restore the most recent version of a table from the recycle bin FLASHBACK TABLE emp TO BEFORE DROP RENAME TO employees;  A specific version can also be restored — If same table is dropped more than once Each dropped version is given a different ‘bin’ name

35 Managing the Recycle Bin  Dropped objects in the recyclebin continue to count against user quota  Objects in the recycle bin can prevent the shrinking of datafiles  Recyclebin feature can be turned off —Any object present in the recyclebin will remain when the parameter is set to OFF —Can be ON | OFF DEFERRED Affects all new sessions and is effectively dynamic —Parameter can be set at session level  After performing flashback to before drop : —Rebuild foreign key constraints —Rename or drop the indexes —Rename or drop the triggers —Recompile triggers ALTER SESSION SET recyclebin = OFF SCOPE = SPFILE;

37 Flashback Database FLASHBACK DATABASE TO BEFORE SCN... FLASHBACK DATABASE TO SCN... FLASHBACK DATABASE TO BEFORE TIMESTAMP... FLASHBACK DATABASE TO TIMESTAMP...  Fast (point in time) recovery from ‘recent’ logical errors —Effectively a rollback of the database —An alternative to normal recovery mechanisms  Database must be in ARCHIVELOG mode —Needs SYSDBA privilege

38 Flashback Logging  Recommended to store both flashback and archived logs in a common recovery area — NOLOGGING operations are recorded in the flashback logs Database Flashback logsArchived logs LGWR RVWR RVWR = Recovery Writer

39 Flashback Structures SGA Buffer cache Flashback Buffer (default size ~ 16M) Redo log buffer All changes Selective block logging Flashback logs Redo logs LGWR RVWR Before images (blocks) logged periodically  Flashback buffer size appears to be based on 2 *LOG_BUFFER

40 Setting up Flashback Database 1.Configure the recovery area DB_RECOVERY_FILE_DEST_SIZE —Default size is 2GB DB_FLASHBACK_RETENTION_TARGET (default 1440 minutes) —Oracle will try to keep enough flashback information to rollback through 1440 minutes 2. Find the current SCN of the database in case you need to perform a subsequent ‘flashback’ to the current state 3. ALTER DATABASE FLASHBACK ON; SELECT current_scn FROM v$database;

41 Flashback Mechanism  Flashback information ‘jumps’ the database back in time  Archive log data is then applied to perform a point in time recovery  Example : FLASHBACK DATABASE TO SCN 53297 Database SCN 69633 Flashback log 23 Flashback log 22 Flashback log 21 Flashback log 20 67234 62983 55617 50614 Archive stream 5329750617

42 Fast Recovery Area Storage  FRA can hold flashback logs, archive logs, backupsets and datafile copies —Alert is raised when Recovery Area is 85% full —Obsolete backups or flashback logs are deleted when 100% full  Recovery Manager (RMAN) automatically deletes flashback logs in preference to other files needed for backup purposes —Invades DB_FLASHBACK_RETENTION_TARGET —Automatically removes ‘corresponding’ flashback logs when archivelogs are purged —Recommended not to use FRA in a non-RMAN environment  Inspect v$recovery_area_usage FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------- ------------------ ------------------------- --------------- CONTROLFILE 0 0 0 ONLINELOG 2 0 22 ARCHIVELOG 4.05 2.01 31 BACKUPPIECE 3.94 3.86 8 IMAGECOPY 15.64 10.43 66 FLASHBACKLOG.08 0 1

43 Flashback Generation  Oracle places flashback markers in the flashback stream  An individual block is logged only once in between the markers —Independent of how many changes or transactions affect the block —Logged once every 30 minutes?  Scenario — emp table of following structure containing 330688 rows Table stored in 8K blocks each containing around 152 rows Rows stored in ascending seqid order SEQID NUMBER(6) PRIMARY KEY EMPNO NUMBER(4) ENAME VARCHAR2(10) JOB VARCHAR2(9) MGR NUMBER(4) HIREDATE DATE SAL NUMBER(7,2) COMM NUMBER(7,2) DEPTNO NUMBER(2)

44 Flashback Generation (continued)  Change the same row/block 2175 times —All updates localised on one block BEGIN FOR i IN 1..2175 LOOP UPDATE emp SET sal = sal+1 WHERE seqid = 40000; COMMIT; END LOOP; END; / No flashback logs generated Elapsed: 00.98 secs Without flashback  00.35 secs

45 Flashback Generation (continued) 2 flashback logs generated, each of 8mb (approx) Elapsed: 9.95 secs BEGIN FOR i IN 1..2175 LOOP UPDATE emp SET sal = sal+1 WHERE seqid = i*152; COMMIT; END LOOP; END; /  Same number of transactions (updates), but approximately one row in each block updated —2175 different blocks affected Without flashback  5.01 secs Repeat runs do not generate flashback logs  5.93 secs

46 Useful Views  Use v$flashback_database_log to show —Available recovery window —Actual size of flashback data —An estimate of amount of flashback needed to support retention target  v$recovery_file_dest —Shows total space usage in recovery area SELECT name,space_limit,space_used,reclaimable_space reclaim,number_of_files files FROM v$recovery_file_dest; NAME SPACE_LIMIT SPACE_USED RECLAIM FILES ----------------------------- ----------- ---------- ------- ----- D:\oracle\flash_recovery_area 2147483648 364353536 0 86

47 Useful Views (continued) SELECT TO_CHAR(begin_time,'ddth hh24:mi') start_time,TO_CHAR(end_time,'ddth hh24:mi') end_time,db_data,redo_data,flashback_data fl_data,estimated_flashback_size est_fl_size FROM v$flashback_database_stat; START_TIME END_TIME DB_DATA REDO_DATA FL_DATA EST_FL_SIZE ---------- ---------- ---------- ---------- ---------- ----------- 15th 15:59 15th 16:48 20234240 9678336 12361728 0 15th 14:59 15th 15:59 19652608 7720960 10272768 398499840 15th 13:59 15th 14:59 21643264 8264704 12541952 447406080 15th 12:59 15th 13:59 20897792 7571968 12435456 516833280 15th 11:52 15th 12:59 46702592 32384000 33333248 712679424  v$ flashback_database_stat —Shows write activity at hourly intervals — estimated_flashback_size is the value found in v$flashback_database_log at the end of the time interval

48 Flashback Database Features  Cannot recover from media failure such as loss of a datafile  Cannot flashback past a shrink datafile —But can handle datafile automatic expansion  Can also be used in a Data Guard environment —Used with snapshot standby databases  Flashback data requires a lot of space —On Windows, logs are ~ 8MB on a ‘quiet’ system with names like O1_MF_0B87CPH6_.FLB —Any change within a block means the whole block is logged  Volume of flashback log generation is volume of redo log generation —If DB_FLASHBACK_RETENTION_TARGET is 24 hours, and 20 GB of redo is generated in a day, then allow 20 GB to 30 GB disk space for the flashback logs ~ ~

49 Repeating Flashbacks  Flashback must be performed in a mount state and requires an : —Deletes flashback logs  What if you are unsure that your flashback is to the correct point in time 1Open the database in READ ONLY mode to observe the data 2. Shutdown 3Mount the database 4Flashback to a different point The new point in time can be in advance or behind the first flashback To move forward a conventional recovery must now be performed –This allows flashing back to the original ‘current’ state ALTER DATABASE OPEN RESETLOGS; ALTER DATABASE OPEN READ ONLY;

50 Restore Points  Named markers for FLASHBACK DATABASE —Avoids need for SCNs or timestamps  Position before potentially risky operations that could compromise the database  Can be normal or guaranteed  Normal restores require FLASHBACK mode  Guaranteed restores can be used when database not in FLASHBACK mode —Could lead to less logging—changed blocks logged once only BUT flashback logs are still produced and forcibly retained Database hangs if FRA not big enough to support guaranteed restore point —Less performance impact and strain on recovery area? CREATE RESTORE POINT before_upgrade [GUARANTEE FLASHBACK DATABASE];

51 Using Restore Points  Removing restore points —Normal restore points age out of control file Control file keeps maximum of 2048 Guaranteed restore points are never removed  Cannot take database out of archivelog mode if a guaranteed restore point is present —Database will not start if guaranteed restore point is active and no space in FRA Check flashback_on in v$database for a value of ‘ RESTORE POINT ONLY’ FLASHBACK DATABASE TO RESTORE POINT before_major_change; FLASHBACK TABLE TO RESTORE POINT before_major_change; RECOVER DATABASE TO RESTORE POINT before_major_change; DROP RESTORE POINT before_major_change;

52 Using Restore Points (continued)  FRA must be configured  Restore points can be created in an open state (11gR2) —Require archivelog mode  If guaranteed restore points defined, instance crashes when RVWR gets I/O errors  Observe in v$restore_point  For normal restore points, storage_size is zero  For guaranteed restore points, storage_size is the space for logs required to guarantee FLASHBACK DATABASE to the restore point SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size FROM v$restore_point;

53 Restore Point Options  With flashback database disabled, can restore only to a guaranteed restore point —If enabled, can restore to any point in time ( RESTORE or otherwise) flashback log2 ~ ~ ~ block 34 ~ ~ ~ Restore point 1 flashback log3 Restore point 2 ~ ~ ~ block 34 ~ ~ ~ flashback log1 ~ ~ ~ block 34 ~ ~ ~ Current version Guaranteed restore point (Only this version will be logged when not in flashback mode)

55 Flashback Data Archive  Transparently tracks historical changes to data in selected tables —Secure - no possibility to modify historical data  Retained according to a time specification —Automatically purged based on retention policy Independent of system level undo  Minimize performance impact of capturing historical data —Faster than routines based on triggers?  Different mechanism and characteristics to Warehouse Builder facility  Now part of Enterprise and Standard Edition —No licence needed except when compression is used (EE only)

56 Setting up Flashback Archives  FlashBack Data Archive (FBDA) process takes read consistent data from buffer cache and/or undo tablespace into the archive  Archives are designed to hold data for a long time (e.g. 1,3,5 years)  One archive can have many tablespaces —Can be seen as sum of quotas on the allocated tablespaces —Tablespaces can be added and removed  Archives managed by account with FLASHBACK ARCHIVE ADMINISTER privilege  Archive users need FLASHBACK ARCHIVE object privilege on the flashback archive object to allow history tracking for specific tables —Documented in sys_fba_users

57 Flashback Data Archive Mechanism UNDO tablespace DML operations Flashback data archives stored in tablespaces FBDA Active data head tail EMPNOENAMESAL 7369ADAMS2000 7788COX2500 7900MILLS800 7902WALL1500 9999 7934GOLD3500 Original (undo) data in buffer cache 1500 Inactive data 1 yr retention 2 yr retention 5 yr retention

58 Creating a Flashback Data Archive CREATE FLASHBACK ARCHIVE fba1 TABLESPACE tbs_fba1 QUOTA 5G RETENTION 1 MONTH; GRANT FLASHBACK ARCHIVE ON fba1 TO fred; CREATE TABLESPACE tbs_fba1 DATAFILE 'c:\oracle\oradata\orcl\tbs_fba1_f1.dbf' SIZE 10G SEGMENT SPACE MANAGEMENT AUTO;  Create the flashback data archive in ASSM (mandatory) tablespace(s)  Allow a user to track changes to his tables in the fba1 archive

59 Creating a Flashback Data Archive CONN fred/fred CREATE TABLE emparch (empno NUMBER(4),ename VARCHAR2(12),salNUMBER(7,2),comm NUMBER(7,2)) FLASHBACK ARCHIVE fba1; or ALTER TABLE emp FLASHBACK ARCHIVE fba1;  Enable history tracking for a table in the fba1 archive  View the historical data SELECT empno, ename, sal FROM emp AS OF TIMESTAMP TO_TIMESTAMP ('2013-03-01 00:00:00', 'YYYY-MM-DD HH24:MI:SS'); SELECT empno, ename, sal FROM emp AS OF TIMESTAMP (SYSTIMESTAMP – INTERVAL '20' DAY);

60 FDA Dictionary Information SELECT * FROM dba_flashback_archive_tables; TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NAME ARCHIVE_TABLE_NAME ---------- ---------- ---------------------- ------------------ EMPARCH SYS FBA1 SYS_FBA_HIST_69882 SELECT * FROM dba_flashback_archive; FLASHBACK_ FLASHBACK_ RETENTION_ CREATE_TIME LAST_PURGE_TIME STATUS ARCHIVE_NAME ARCHIVE# IN_DAYS ------------ ---------- ---------- ---------------------------- ---------------------------- ------- FBA1 1 30 13-MAR-13 14.24.28.000000000 12-APR-13 14.24.28.000000000 SELECT * FROM dba_flashback_archive_ts; FLASHBACK_ARCHIVE_NAME FLASHBACK_ TABLESPACE_NAME QUOTA_IN_MB ARCHIVE# ---------------------- ---------- --------------- ----------- FBA1 1 TBS_FBA1 5000 Does not show in dba_tables until actually used by fbda

61 Population of Flashback Archive Table SELECT * FROM sys_fba_hist_69882; RID STARTSCN ENDSCN XID O EMPNO ENAME SAL COMM ------------------ -------- ------- ---------------- - ----- ------ ---- ---- AAAR0nAABAAAVxiAAA 5432321 5432342 02001D00C3110000 I 7369 SMITH 800 AAAR0nAABAAAVxiAAB 5432321 5432342 02001D00C3110000 I 7499 ALLEN 1600 300 AAAR0nAABAAAVxiAAC 5432321 5432342 02001D00C3110000 I 7521 WARD 1250 500 AAAR0nAABAAAVxiAAD 5432321 5432342 02001D00C3110000 I 7566 JONES 2975 AAAR0nAABAAAVxiAAE 5432321 5432342 02001D00C3110000 I 7654 MARTIN 1250 1400 AAAR0nAABAAAVxiAAF 5432321 5432342 02001D00C3110000 I 7698 BLAKE 2850 AAAR0nAABAAAVxiAAG 5432321 5432342 02001D00C3110000 I 7782 CLARK 2450 AAAR0nAABAAAVxiAAH 5432321 5432342 02001D00C3110000 I 7788 SCOTT 3000 AAAR0nAABAAAVxiAAI 5432321 5432342 02001D00C3110000 I 7839 KING 5000 AAAR0nAABAAAVxiAAJ 5432321 5432342 02001D00C3110000 I 7844 TURNER 1500 0 AAAR0nAABAAAVxiAAK 5432321 5432342 02001D00C3110000 I 7876 ADAMS 1100 AAAR0nAABAAAVxiAAL 5432321 5432342 02001D00C3110000 I 7900 JAMES 950 AAAR0nAABAAAVxiAAM 5432321 5432342 02001D00C3110000 I 7902 FORD 3000 AAAR0nAABAAAVxiAAN 5432321 5432342 02001D00C3110000 I 7934 MILLER 1300 ROWID s of rows in base table NULL if operation is direct path (e.g CTAS)  No evidence of FDA data after inserting fourteen rows and committing —Inserts are not captured  After updating all 14 rows, committing and waiting for 5 minutes —The history table is built, and rows appear in the history table

62 Dictionary Details  Some of the flashback objects are temporary tables SELECT owner, tablespace_name, table_name, temporary FROM dba_tables WHERE table_name LIKE '%FBA%'; OWNER TABLESPACE_NAME TABLE_NAME TEMPORARY ----- --------------- ------------------------ --------- FRED TBS_FBA2 SYS_FBA_DDL_COLMAP_69878 N FRED TBS_FBA2 SYS_FBA_TCRV_69878 N FRED TBS_FBA2 SYS_FBA_DDL_COLMAP_69882 N FRED TBS_FBA2 SYS_FBA_TCRV_69882 N FRED SYS_FBA_HIST_69882 N FRED SYS_FBA_HIST_69878 N SYS SYSTEM SYS_FBA_TSFA N SYS SYSTEM SYS_FBA_FA N SYS SYSTEM SYS_FBA_BARRIERSCN N SYS SYSTEM SYS_FBA_TRACKEDTABLES N SYS SYSTEM SYS_FBA_PARTITIONS N SYS SYSTEM SYS_FBA_USERS N SYS SYSTEM SYS_FBA_DL N SYS SYSTEM SYS_FBA_COLS N SYS SYSTEM SYS_FBA_CONTEXT N SYS SYSTEM SYS_FBA_CONTEXT_AUD N SYS SYSTEM SYS_FBA_CONTEXT_LIST N SYS SYSTEM SYS_FBA_APP N SYS SYSTEM SYS_FBA_APP_TABLES N SYS SYS_MFBA_NHIST_69882 Y SYS SYS_MFBA_NCHANGE Y SYS SYS_MFBA_NROW Y SYS SYS_MFBA_TRACKED_TXN Y SYS SYS_MFBA_STAGE_RID Y SYS SYS_MFBA_NTCRV Y SYS SYS_MFBA_NHIST_69878 Y No value for tablespace_name because they are partitioned

63 Partitioning of Flashback Data Archive Tables SELECT * FROM dba_part_tables WHERE table_name = 'SYS_FBA_HIST_69882' OWNER : SYS TABLE_NAME : SYS_FBA_HIST_69882 PARTITIONING_TYPE : RANGE SUBPARTITIONING_TYPE : NONE PARTITION_COUNT : 1 DEF_SUBPARTITION_COUNT : 0 PARTITIONING_KEY_COUNT : 1 SUBPARTITIONING_KEY_COUNT : 0 STATUS : VALID DEF_TABLESPACE_NAME : TBS_FBA1 DEF_PCT_FREE : 10 DEF_PCT_USED : DEF_INI_TRANS : 1 DEF_MAX_TRANS : 255 DEF_INITIAL_EXTENT : DEFAULT DEF_NEXT_EXTENT : DEFAULT DEF_MIN_EXTENTS : DEFAULT DEF_MAX_EXTENTS : DEFAULT DEF_MAX_SIZE : DEFAULT DEF_PCT_INCREASE : DEFAULT DEF_FREELISTS : DEF_FREELIST_GROUPS : DEF_LOGGING : NONE DEF_COMPRESSION : ENABLED DEF_COMPRESS_FOR : ADVANCED DEF_BUFFER_POOL : DEFAULT DEF_FLASH_CACHE : DEFAULT DEF_CELL_FLASH_CACHE : DEFAULT REF_PTN_CONSTRAINT_NAME : INTERVAL : IS_NESTED : NO DEF_SEGMENT_CREATION : NONE DEF_INDEXING : ON Partitions may be compressed – only for OLTP Size could well be governed by _flashback_archiver_partition_size

64 The First Two Partitions of the Flashback Archive Table SELECT table_name, partition_name, high_value, high_value_length,initial_extent, compression, compress_for FROM dba_tab_partitions WHERE table_name = 'SYS_FBA_HIST_69882' TABLE_NAME : SYS_FBA_HIST_69882 PARTITION_NAME : PART_8290898 HIGH_VALUE : 8290898 HIGH_VALUE_LENGTH : 7 INITIAL_EXTENT : 8388608 COMPRESSION : ENABLED COMPRESS_FOR : ADVANCED TABLE_NAME : SYS_FBA_HIST_69882 PARTITION_NAME : HIGH_PART HIGH_VALUE : MAXVALUE HIGH_VALUE_LENGTH : 8 INITIAL_EXTENT : 8388608 COMPRESSION : ENABLED COMPRESS_FOR : ADVANCED SCN value used as partition key Note first extent is 8M and is not deferred

65 Flashback Archive Query Trace SELECT COUNT(*) FROM emparch AS OF TIMESTAMP(systimestamp – INTERVAL '2' DAY); COUNT(*) -------- 100000 ----------------------------------------------------------------- | Id | Operation | Name | Rows | ----------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | | 1 | SORT AGGREGATE | | 1 | | 2 | VIEW | | 998 | | 3 | UNION-ALL | | | |* 4 | FILTER | | | | 5 | PARTITION RANGE SINGLE| | 1 | |* 6 | TABLE ACCESS FULL | SYS_FBA_HIST_69882 | 1 | |* 7 | FILTER | | | |* 8 | HASH JOIN OUTER | | 997 | |* 9 | TABLE ACCESS FULL | EMP_FLASH | 1511 | | 10 | VIEW | | 204K| |* 11 | TABLE ACCESS FULL | SYS_FBA_TCRV_69882 | 204K| ----------------------------------------------------------------- This table is automatically indexed could index columns in this table

66 Flashback Archive Query Performance  emparch has 1,000,000 rows  sys_fba_hist_69882 has 329,387 rows  empno has high selectivity (10 rows with empno value of 50000) SELECT COUNT(*) FROM emparch AS OF TIMESTAMP(SYSTIMESTAMP – INTERVAL '60' DAY) WHERE empno = 50000; Elapsed time : 7.06secs CREATE INDEX emparch$empno ON sys_fba_hist_69882(empno); Elapsed time : 4.89secs

67 Column Mapping and DDL Restrictions SELECT * FROM sys_fba_ddl_colmap_69882; STARTSCN ENDSCN XID OPERATION COLUMN_NAME TYPE HISTORICAL_ COLUMN_NAME -------- -------- --------- --------- -------------- ------------ ---------- 5424699 EMPNO NUMBER(4) EMPNO 5424699 NAME VARCHAR2(12) ENAME 5424699 22415904 SAL NUMBER(7,2) SALARY 5424699 COMM NUMBER(7,2) COMM 5474905 20775346 D_20775346_JOB VARCHAR2(15) JOB ALTER TABLE emparch DROP COLUMN job;  From 11g Release 2 you can perform DDL on the source table —Add, drop, rename, modify a column —Drop or truncate a partition —Rename, truncate table (but not drop) —Add, drop, rename, modify a constraint ALTER TABLE emparch RENAME COLUMN salary TO sal;

68 Tips for Using Flashback Data Archive  COMMIT or ROLLBACK before querying past data  Use System Change Number (SCN) where precision is needed —Timestamps have a three-second granularity —Obtain SCN with DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER  Disabling archiving for a specific table requires the FLASHBACK ARCHIVE ADMINISTER privilege – ‘normal’ users are not allowed to disable the archiving —Drops the history table  Tables that are being archived cannot be dropped —Archiving must first be disabled  Tablespaces that contain archive-enabled tables cannot be dropped  Total recall data is not exported —Lost when flashback data archiving is turned off Save into another table ALTER TABLE scott.emp NO FLASHBACK ARCHIVE;

69 Flashback Data Archiving versus Oracle11g Auditing  Auditing needs the audit_trail parameter to be set to DB or DB,EXTENDED  Auditing uses autonomous transactions, which has some performance overhead —FDA written in background by FBDA process – gives less impact on performance  Audit trails are handled manually —Flashback Data Archives can be automatically purged —Or handled manually ALTER FLASHBACK ARCHIVE fba1 MODIFY RETENTION 6 MONTH; ALTER FLASHBACK ARCHIVE fba1 PURGE BEFORE TIMESTAMP(SYSTIMESTAMP – INTERVAL '1' DAY);

70 Flashback Data Archiving versus Database Triggers  Database triggers can populate an audit table —Implies a performance overhead —The audit table must be managed CREATE TABLE emp_trig_aud (empno NUMBER(8), ename VARCHAR2(12), sal NUMBER(7,2), comm NUMBER(7,2), rid VARCHAR2(20), curdate DATE, username VARCHAR2(20)); CREATE OR REPLACE TRIGGER e_f_trig AFTER UPDATE ON emp_trig FOR EACH ROW BEGIN INSERT INTO emp_trig_aud VALUES(:OLD.empno,:OLD.ename,:OLD.sal,:OLD.comm,:OLD.rowid,sysdate,user); END;

71 FDA versus Database Triggers Results  Three tables with same data (114688 rows) 1.emp_none – no auditing 2.emp_fda - FDA 3.emp_trig – Trigger EMPNO ENAME SAL COMM ----- ----- ---- ---- 7654 aaaa 1250 1400 7698 aaaa 2850 : : : : UPDATE > SET ename = 'bbbb'; COMMIT; Table emp_noneemp_fdaemp_trig Update2.45s3.81s9.70s Commit0.00s0.18s0.00s  Update all records and then commit on all three tables

72 12c New features : User-context tracking  User context and other metadata can now be tracked - easier to identify a user —Better alternative to trigger-based auditing EXEC dbms_flashback_archive.set_context_level(level=> 'ALL'); — level can be ALL, TYPICAL, NONE Value can be seen in sys_fba_context_list SELECT * FROM SYS.SYS_FBA_CONTEXT_LIST; NAMESPACE PARAMETER ------------------------------ ------------------------ USERENV ACTION USERENV AUTHENTICATED_IDENTITY : : USERENV SESSIONID USERENV TERMINAL FBA_CONTEXT ALL

73 New View – sys_fba_context_aud EXEC PT ('SELECT * FROM sys.sys_fba_context_aud') XID : 1E00120059030000 ACTION : AUTHENTICATED_IDENTITY : fred CLIENT_IDENTIFIER : CLIENT_INFO : CURRENT_EDITION_NAME : ORA$BASE CURRENT_SCHEMA : SYS CURRENT_USER : SYS DATABASE_ROLE : PRIMARY DB_NAME : orcl GLOBAL_UID : HOST : WORKGROUP\LT1 IDENTIFICATION_TYPE : LOCAL INSTANCE_NAME : orcl IP_ADDRESS : MODULE : SQL*Plus OS_USER : LT1\Administrator SERVER_HOST : ltree1 SERVICE_NAME : SYS$USERS SESSION_EDITION_NAME : ORA$BASE SESSION_USER : FRED SESSION_USERID : 120 SESSIONID : 1509620 TERMINAL : LT1 SPARE : ----------------------------------------------------- : : It appears that both ALL and TYPICAL generate this information

74 Correlating Context Information with History  Context for a given transaction can also be obtained from : SELECT sfba.authenticated_identity,sfba.host,sfba.module,hist.empno,hist.ename FROM sys.sys_fba_context_aud sfba,fred.sys_fba_hist_175827 hist WHERE hist.xid = sfba.xid; SESSION_USER HOST MODULE EMPNO ENAME ------------ ------------- -------- ----- ------ FRED WORKGROUP\LT1 SQL*Plus 7934 MILLER FRED WORKGROUP\LT1 SQL*Plus 7902 FORD FRED WORKGROUP\LT1 SQL*Plus 7900 JAMES dbms_flashback_archive.get_sys_context(v_xid,'USERENV','SESSION_USER');

75 More New Features  Archive tables can now be selectively compressed —Requires a licence for the Advanced Compression Option —The compression is COMPRESS FOR OLTP ( FOR ALL OPERATIONS ) —Default is not to compress ( NO OPTIMIZE ) allowing FDA for SE  Application support —Sets of tables can be registered for archiving in an ‘Application’ CREATE FLASHBACK ARCHIVE FBA_OPT TABLESPACE FBA_OPT RETENTION 12 MONTH OPTIMIZE DATA; CREATE TABLE EMP_OPT AS SELECT * FROM EMP; ALTER TABLE EMP_OPT FLASHBACK ARCHIVE FBA_OPT;

76 Importing User-Generated Archive Data  Extend mappings to the past ( 01-JAN-1988 ) to enable import of history dbms_flashback_archive.create_temp_history_table('fred','emp') dbms_flashback_archive.import_history('fred','emp') INSERT INTO temp_history SELECT * FROM emp_aud; COMMIT;  Create an empty temp_history table for previously user managed archive table Name Type ----------- ------------ RID VARCHAR2(4000) STARTSCN NUMBER ENDSCN NUMBER XID RAW(8) OPERATION VARCHAR2(1) EMPNO NUMBER(4) ENAME VARCHAR2(12) SAL NUMBER(7,2) COMM NUMBER(7,2)  Populate temp table from audit table (must commit)  Import temp table data into FDA History table SELECT tname FROM tab; TNAME ------------------------- EMP SYS_FBA_DDL_COLMAP_406248 SYS_FBA_HIST_406248 SYS_FBA_TCRV_406248 TEMP_HISTORY SELECT tname FROM tab; TNAME ------------------------- EMP SYS_FBA_DDL_COLMAP_406248 SYS_FBA_HIST_406248 SYS_FBA_TCRV_406248 EXEC DBMS_FLASHBACK_ARCHIVE.extend_mappings();

77 Importing User-Generated Archive Data  emp table audit data had been generated into emp_aud by this trigger — emp_aud has same structure as history table CREATE OR REPLACE TRIGGER emparch_trg AFTER UPDATE OR DELETE ON fred.emparch FOR EACH ROW DECLARE opn VARCHAR2(1); BEGIN IF UPDATING THEN opn := 'U'; ELSE opn := 'D'; END IF; INSERT INTO fred.emparch_aud (rid, startscn, endscn, xid, operation, empno, ename, sal, comm ) VALUES (:OLD.ROWID, NULL, NULL, NULL, opn, :OLD.empno, :OLD.ename, :OLD.sal, :OLD.comm); END; /

79 Valid Time Support – Temporal Validity  Allows tables to have one or more valid time dimensions —Data is visible (‘valid’) depending on its time-based validity —Determined by start and end dates or time stamps of a valid time period  Examples include : —Hiring and finishing dates of an employee —Valid period for an insurance policy —Date of change of address for a customer or client  Temporal Validity is typically actioned with : 1. AS OF and VERSIONS BETWEEN 2. DBMS_FLASHBACK_ARCHIVE.enable_at_valid_time  Can be set to show all table data (the default) or valid data as of a specified time —Flash forward to see future database state??  Useful with Information Lifecycle Management (ILM)

80 Valid Time Dimensions  Two date-time columns result from CREATE TABLE or ALTER TABLE —Can be added explicitly or created automatically from PERIOD specification  One NUMBER column is also created with same name as specified PERIOD CREATE TABLE emp_vt ( empno NUMBER(6) NOT NULL,ename VARCHAR2(20), PERIOD FOR emp_vt_time); SELECT column_name,data_type,column_id AS col_id,segment_column_id AS seg_col_id,internal_column_id AS int_col_id,hidden_column,virtual_column FROM user_tab_cols WHERE table_name = 'EMP_VT'; COLUMN_NAME DATA_TYPE COL_ID SEG_COL_ID INT_COL_ID HID VIR ----------------- --------------------------- ------ ---------- ---------- --- --- EMP_VT_TIME_START TIMESTAMP(6) WITH TIME ZONE 1 1 YES NO EMP_VT_TIME_END TIMESTAMP(6) WITH TIME ZONE 2 2 YES NO EMP_VT_TIME NUMBER 3 YES YES EMPNO NUMBER 1 3 4 NO NO ENAME VARCHAR2 2 4 5 NO NO user_tab_columns does not show hidden columns

81 Using Valid Times – SQL level control INSERT INTO emp_vt(empno,ename,emp_vt_time_start,emp_vt_time_end) VALUES (1023,'COX','01-APR-2013 12.00.01 PM GMT','05-APR-2013 12.00.01 PM GMT'); INSERT INTO emp_vt(empno,ename,emp_vt_time_start,emp_vt_time_end) VALUES (1024,'ADAMS','06-APR-2013 12.00.01 PM GMT','05-APR-2014 12.00.01 PM GMT'); SELECT * FROM emp_vt AS OF PERIOD FOR emp_vt_time '03-APR-2013 12.00.00 PM'; EMPNO ENAME ----- -------------------- 1023 COX Valid from 1 st to 5 th April SELECT * FROM emp_vt; EMPNO ENAME ----- --------------- 1023 COX 1024 ADAMS SELECT * FROM emp_vt WHERE emp_vt_time_start > '03-APR-2013 12.00.00 PM'; EMPNO ENAME ----- --------------------- 1024 ADAMS

82 Displaying Valid Times  Must explicitly select hidden columns —Cannot be combined with ‘ * ’ SELECT empno,ename,emp_vt_time_start,emp_vt_time_end,emp_vt_time FROM emp_vt; EMPNO ENAME EMP_VT_TIME_START EMP_VT_TIME_END EMP_VT_TIME ----- ----- -------------------------------- -------------------------------- ----------- 1023 COX 01-APR-13 12.00.01.000000 PM GMT 05-APR-13 12.00.01.000000 PM GMT 7339307 1024 ADAMS 06-APR-13 12.00.01.000000 PM GMT 05-APR-14 12.00.01.000000 PM GMT 7339307 —Additional periods each require three extra columns  Visibility of rows can also be controlled with ARCHIVAL VISIBILITY —Uses another hidden column ORA_ARCHIVE_STATE

83 Session Level Control of Visibility  Visibility only of data valid at a point in time —Row must be valid for all PERIOD s in use  Full data visibility (default ) EXEC dbms_flashback_archive.enable_at_valid_time('ALL') EXEC dbms_flashback_archive.enable_at_valid_time('CURRENT')  Visibility only of currently valid data EXEC dbms_flashback_archive.enable_at_valid_time ('ASOF', '01-APR-13 12.00.01 PM') Must be UPPERCASE EXEC DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME('ASOF','01-JAN-02 01.01.01.000000') UPDATE emp_vt2 SET vt_a_start = '01-JAN-02 01.01.01.000000 AM' WHERE empno = 1; ORA-00904: "VT_A_START": invalid identifier EXEC DBMS_FLASHBACK_ARCHIVE.ENABLE_AT_VALID_TIME('ALL') UPDATE emp_vt2 SET vt_a_start = '01-JAN-02 01.01.01.000000 AM' WHERE empno = 1; 1 row updated.

84 Constraints for Valid Tiimes OWNER : FRED CONSTRAINT_NAME : EMP_VT_TIMEA67E83 CONSTRAINT_TYPE : C TABLE_NAME : EMP_VT SEARCH_CONDITION : EMP_VT_TIME_START < EMP_VT_TIME_END SEARCH_CONDITION_VC : EMP_VT_TIME_START < EMP_VT_TIME_END R_OWNER : R_CONSTRAINT_NAME : DELETE_RULE : STATUS : ENABLED DEFERRABLE : NOT DEFERRABLE DEFERRED : IMMEDIATE VALIDATED : VALIDATED GENERATED : USER NAME BAD : RELY : LAST_CHANGE : 16-sep-2013 23:18:34 INDEX_OWNER : INDEX_NAME : INVALID : VIEW_RELATED : ORIGIN_CON_ID : 0 A null value appears to get past the constraint

85 Filters based on Valid Times  Two valid time periods placed on table data —Plan shows combined constraint filter(("T"."VT_A_START" IS NULL OR SYS_EXTRACT_UTC("T"."VT_A_START")<=SYS_EXTRACT_UTC(TIMESTAMP' 2010-01-01 00:00:00.000000000')) AND ("T"."VT_A_END" IS NULL OR SYS_EXTRACT_UTC("T"."VT_A_END")>SYS_EXTRACT_UTC(TIMESTAMP' 2010-01-01 00:00:00.000000000')) AND ("T"."VT_B_START" IS NULL OR SYS_EXTRACT_UTC("T"."VT_B_START")<=SYS_EXTRACT_UTC(TIMESTAMP' 2010-01-01 00:00:00.000000000')) AND ("T"."VT_B_END" IS NULL OR SYS_EXTRACT_UTC("T"."VT_B_END")>SYS_EXTRACT_UTC(TIMESTAMP' 2010-01-01 00:00:00.000000000')))

86 Table With User-generated Start and End Columns CREATE TABLE emp_mine (empno NUMBER,ename VARCHAR2(12),stime DATE,etime DATE); ALTER TABLE emp_mine ADD(PERIOD FOR pd(stime,etime)); SELECT column_name,data_type,column_id AS col_id,segment_column_id AS seg_col_id,internal_column_id AS int_col_id,hidden_column,virtual_column FROM user_tab_cols WHERE table_name = 'EMP_MINE'; COLUMN_NAME DATA_TYPE COL_ID SEG_COL_ID INT_COL_ID HID VIR --------------- -------------------- ---------- ---------- ---------- --- --- PD NUMBER 5 YES YES ETIME DATE 4 4 4 NO NO STIME DATE 3 3 3 NO NO ENAME VARCHAR2 2 2 2 NO NO EMPNO NUMBER 1 1 1 NO NO SELECT * FROM EMP_MINE; EMPNO ENAME STIME ETIME ----- ----- --------- --------- 11 COX 20-JAN-13 21-FEB-13 12 ALLEN 20-JAN-13 21-FEB-13

Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director carl.dudley@wlv.ac.uk

Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director

Similar presentations

Presentation on theme: "Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director

Similar presentations

Presentation on theme: "Flashback Techniques for Oracle Database 11g and The Next Generation Carl Dudley University of Wolverhampton, UK UKOUG Oracle ACE Director"— Presentation transcript:

Similar presentations

About project

Feedback