Flashback Techniques for Oracle11g and Oracle12c

Flashback Techniques for Oracle11g and Oracle12c
Carl Dudley Tradba Ltd Oracle ACE Director

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 Official Member of IOUC Day job – University of Wolverhampton, UK

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

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 <ipf>L</ipf> This is obviously not the complete detail necessary to use Flashback. Objective is to make the students aware of the availability of the tool. Time must be specified using AM and PM and not the 24-hour clock. SELECT * FROM department AS OF TIMESTAMP TO_TIMESTAMP('03-MAR :30:00'); CREATE TABLE changes_today AS SELECT * FROM employees MINUS SELECT * FROM employees AS OF TIMESTAMP TRUNC(SYSDATE); To observe new records added today

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 :00:00AM'); SELECT ... FROM ... ; SELECT ... FROM ... ; -- No DML or DDL allowed dbms_flashback.disable; <ipf>L</ipf> This is obviously not the complete detail necessary to use Flashback. Objective is to make the students aware of the availability of the tool. Time must be specified using AM and PM and not the 24-hour clock. If only a date is specified, time element defaults to 12 midnight Useful when using 3rd party apps and you cannot touch the code Simply put the session back in time

Flashback Query Limitations
Flashback is enabled at nearest SCN to the specified time rounded down to a 3 second interval SCNs are mapped to times only once every 3 seconds Need to know SCNs 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 SCNs 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 <ipf>L</ipf> This is obviously not the complete detail necessary to use Flashback. Objective is to make the students aware of the availability of the tool. Time must be specified using AM and PM and not the 24-hour clock.

Flashback Row History Shows row version data plus :
Start and end times of the version (SCNs and timestamps) Transaction ID for every version of the row during the specified period SELECT empno,sal,versions_starttime st,versions_xid XID FROM empf VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP('01-MAR ') AND TO_TIMESTAMP('01-MAR ') WHERE empno = 7766; <ipf>R</ipf> 1st bullet, 3rd dash – goes to nearest SCN within 5 minutes. Can be difficult to get to the right point in time. Can cause problems if tale is created or altered close to flashback time. LogMiner may still be preferable. Oracle maintains timing information for up to five days. This allows it to translate times to SCNs for up to five days previous. If you need to go further back, you must supply an actual SCN. Could retrieve value from DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER before a heavy delete operation in order to flashback accurately to that point Dictionary views except the v$ views can be flashed back - but only in SQL-driven flashbacks because sys can not use the dbms_flashback package. Try the following - it will show roughly five minute intervals for the time mapping to SCNs SELECT TO_CHAR(time_dp,’dd-mon-yyyy hh24:mi:ss’) FROM smon_scn_time WHERE ROWNUM < 21; Maximum 1440 rows in this view (one for each five minutes gives 5 days of tracking) Returns the salary for each transaction affecting the row, as follows: EMPNO SAL ST XID MAR F MAR C00151B0000 MAR No need for audit tables? Does not show any inserts and deletes due to online shrink operations

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; <ipf>R</ipf> 1st bullet, 3rd dash – goes to nearest SCN within 5 minutes. Can be difficult to get to the right point in time. Can cause problems if tale is created or altered close to flashback time. LogMiner may still be preferable. Oracle maintains timing information for up to five days. This allows it to translate times to SCNs for up to five days previous. If you need to go further back, you must supply an actual SCN. Could retrieve value from DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER before a heavy delete operation in order to flashback accurately to that point Dictionary views except the v$ views can be flashed back - but only in SQL-driven flashbacks because sys can not use the dbms_flashback package. Try the following - it will show roughly five minute intervals for the time mapping to SCNs SELECT TO_CHAR(time_dp,’dd-mon-yyyy hh24:mi:ss’) FROM smon_scn_time WHERE ROWNUM < 21; Maximum 1440 rows in this view (one for each five minutes gives 5 days of tracking) Contents of table empf EMPNO ENAME SAL 7950 BROWN 8888 GREEN 1111 WHITE

Flashback Transaction History – Scenario (continued)
DELETE FROM empf WHERE empno = 7950; UPDATE empf SET sal = sal WHERE empno = 8888; COMMIT; Bad transaction correctly deletes a row, incorrectly updates the other EMPNO ENAME SAL 8888 BROWN 1111 WHITE <ipf>R</ipf> 1st bullet, 3rd dash – goes to nearest SCN within 5 minutes. Can be difficult to get to the right point in time. Can cause problems if tale is created or altered close to flashback time. LogMiner may still be preferable. Oracle maintains timing information for up to five days. This allows it to translate times to SCNs for up to five days previous. If you need to go further back, you must supply an actual SCN. Could retrieve value from DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER before a heavy delete operation in order to flashback accurately to that point Dictionary views except the v$ views can be flashed back - but only in SQL-driven flashbacks because sys can not use the dbms_flashback package. Try the following - it will show roughly five minute intervals for the time mapping to SCNs SELECT TO_CHAR(time_dp,’dd-mon-yyyy hh24:mi:ss’) FROM smon_scn_time WHERE ROWNUM < 21; Maximum 1440 rows in this view (one for each five minutes gives 5 days of tracking) UPDATE empf SET sal = sal WHERE empno = 8888; UPDATE empf SET sal = sal WHERE empno = 8888; COMMIT; New transaction updates a remaining row with new values EMPNO ENAME SAL 8888 BROWN 1111 WHITE

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 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 BE U BROWN BE U BROWN BE D GREEN BE I WHITE BE I BROWN BE I GREEN Top row is the final transaction, second row is the error

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

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(‘<your_transaction_id>’) in the WHERE clause Consider flashback_transaction_query with approximately 40,000 rows SELECT xid, undo_sql FROM flashback_transaction_query WHERE xid = ' A090000'; 15.51 secs SELECT xid, undo_sql FROM flashback_transaction_query WHERE xid = HEXTORAW(' A090000'); 0.04 secs

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) 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

Flashback Transaction Requirements
Database must be in ARCHIVELOG mode and COMPATIBLE >= Requires additional redo logging Minimal supplemental logging 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;

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 ( numberofxids NUMBER xids XID_ARRAY options NUMBER DEFAULT NOCASCADE timehint TIMESTAMP DEFAULT MINTIME) options can take values 1,2,3,4

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 value Result 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

Collecting Information
Situation after committing the results of the CASCADE option SELECT * FROM dba_flashback_txn_report; COMPENSATING_XID : 0E000700F COMPENSATING_TXN_NAME : _SYS_COMP_TXN_ _TIM_ COMMIT_TIME : 01-MAR-13 XID_REPORT : <?xml version="1.0" encoding="ISO "?> <COMP_XID_REPORT XID="0E000700F20200 USERNAME : SYS SELECT * FROM dba_flashback_txn_state; COMPENSATING_XID XID DEPENDENT_XID BACKOUT_MODE USERNAME 0E000700F D CASCADE SYS 0E000700F D001A D CASCADE SYS

Backing out Transactions Example
DECLARE v_xids sys.XID_ARRAY := sys.xid_array(); BEGIN v_xids.extend; v_xids(1) := HEXTORAW(' BE000000'); sys.DBMS_FLASHBACK.TRANSACTION_BACKOUT(numtxns => 1, xids => v_xids, options => 4,scnhint => 0); END; / The bad transaction id 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

v$flashback_txn_mods
EXEC scott.pt('SELECT * FROM v$flashback_txn_mods') COMPENSATING_XID : A210000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_ _TIM_ XID : F210000 TXN_NAME : PARENT_XID : F210000 INTERESTING : 1 ORIGINAL : 1 BACKOUT_SEQ : 2 UNDO_SQL : update "FRED"."STOCK" set "NAME" = 'IBM', "CTIME" = TO_TIMESTAMP('10-AUG ') where "ST_ID" = '2' and "NAME" = 'HP' and "PRICE" = '11' and "CTIME" = TO_TIMESTAMP('10-AUG ') 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 : :

v$flashback_txn_graph
EXEC scott.pt('SELECT * FROM v$flashback_txn_graph') COMPENSATING_XID : A210000 COMPENSATING_TXN_NAME : _SYS_COMP_TXN_ _TIM_ XID : F210000 TXN_NAME : PARENT_XID : F210000 INTERESTING : 1 ORIGINAL : 1 BACKOUT_SEQ : 2 NUM_PREDS : 0 NUM_SUCCS : 1 DEP_XID : 08001E DEP_TXN_NAME : TXN_CONF_SQL_ID : 1 DEP_TXN_CONF_SQL_ID : 3 CONFLICT_TYPE : WRITE AFTER WRITE XID : 08001E PARENT_XID : 08001E ORIGINAL : 0 BACKOUT_SEQ : 1 NUM_PREDS : 1 NUM_SUCCS : 0 DEP_XID : TXN_CONF_SQL_ID : 0 DEP_TXN_CONF_SQL_ID : 0 CONFLICT_TYPE :

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 (ROWIDs 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

Using Flashback Table 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 Perform the flashback table operation FLASHBACK TABLE t1 TO SCN 12345; FLASHBACK TABLE t1 TO TIMESTAMP TO_TIMESTAMP(' :05:00') ENABLE TRIGGERS; Triggers are not enabled by default during a flashback operation

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 ROWIDs of affected rows Name Type SCHEMA VARCHAR2(32) OBJECT_NAME VARCHAR2(32) OBJECT# NUMBER RID ROWID ACTION CHAR(1)

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 Create a table (ef) containing rows (143 rows per block) Enable row movement ALTER TABLE ef ENABLE ROW MOVEMENT; Find current timestamp SELECT systimestamp FROM DUAL; Update a single row UPDATE ef SET deptno = 99 WHERE ROWNUM = 1; 5 Perform a flashback FLASHBACK TABLE ef TO TIMESTAMP TO_TIMESTAMP('<time_stamp>');

Use of Temporary Table – Scenario (continued)
Update of one row causes 286 entries (2*143) in the temp 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 ROWIDs 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 ROWNUM < 145; Generates 572 (2*286) rows in the temporary table UPDATE ef SET deptno = 99 WHERE empno = 7369; (7369 is present every 14 rows) Generates rows in the temporary table

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

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

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

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

Restoring Objects in the Recycle Bin
Flashback drop will restore the most recent version of a table from the recycle bin FLASHBACK TABLE emp TO BEFORE DROP; A specific version can also be restored If same table is dropped more than once Each dropped version is given a different ‘bin’ name FLASHBACK TABLE “BIN$xyWe0+q+SniItJ0pn/u54A==$ TO BEFORE DROP; 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 emp TO BEFORE DROP RENAME TO employees;

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 [DEFERRED] | 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;

Flashback Database 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 FLASHBACK DATABASE TO TIMESTAMP ... FLASHBACK DATABASE TO BEFORE TIMESTAMP ... FLASHBACK DATABASE TO BEFORE SCN ... FLASHBACK DATABASE TO SCN ... Needs SYSDBA privilege

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

Before images (blocks)
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

Setting up Flashback Database
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 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;

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 Flashback log 20 Flashback log 21 Flashback log 22 Flashback log 23 50614 55617 62983 67234 Database SCN 69633 Archive stream 50617 53297

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 ONLINELOG ARCHIVELOG BACKUPPIECE IMAGECOPY FLASHBACKLOG

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 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)

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

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

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

Useful Views (continued)
v$flashback_database_stat Shows write activity at hourly intervals 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: 15th 14:59 15th 15: 15th 13:59 15th 14: 15th 12:59 15th 13: 15th 11:52 15th 12: estimated_flashback_size is the value found in v$flashback_database_log at the end of the time interval

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 ~

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 Open the database in READ ONLY mode to observe the data 2. Shutdown Mount the database Flashback 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;

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? <ipf>R,67: Restore Points</ipf> CREATE RESTORE POINT before_upgrade [GUARANTEE FLASHBACK DATABASE];

Using Restore Points FLASHBACK DATABASE TO RESTORE POINT before_major_change; FLASHBACK TABLE TO RESTORE POINT before_major_change; RECOVER DATABASE TO RESTORE POINT before_major_change; <ipf>L,68: Using Restore Points</ipf> 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’ DROP RESTORE POINT before_major_change;

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 <ipf>R,69: Using Restore Points (Continued)</ipf> SELECT name, scn, time, database_incarnation#, guarantee_flashback_database, storage_size FROM v$restore_point;

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) Guaranteed restore point (Only this version will be logged when not in flashback mode) <ipf>L,70: Restore Points Options</ipf> block 34 ~ ~ ~ block 34 ~ ~ ~ block 34 ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Current version ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ Restore point 1 Restore point 2 flashback log1 flashback log2 flashback log3

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)

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

Flashback Data Archive Mechanism
<*s*o*u*r*c*e*>*9*2*8*a*1*b*-*2*-*3*9*<*/*s*o*u*r*c*e*> UNDO tablespace Original (undo) data in buffer cache EMPNO ENAME SAL 7369 ADAMS 2000 7788 COX 2500 7900 MILLS 800 7902 WALL 7934 GOLD 3500 tail 1500 Active data head <ipf>L,59: Flashback Data Archive Overview (continued)</ipf> The Flashback Data Archive background process, FBDA, starts with the database. 1. FBDA operates first on the undo in the buffer cache. Capture interval defaults to 5 minutes and is self-tuned. 2. In case the undo has already left the buffer cache, FBDA could also read the required values from the undo segments. 3. FBDA collects the modified rows of flashback archive–enabled tables and writes them into the appropriate history tables, which make up the flashback data archive. You can find the internally assigned names of the history tables by querying the *_FLASHBACK_ARCHIVE_TABLES view. History tables are compressed and internally partitioned. The database automatically purges all historical information on the day after the retention period expires. (It deletes the data, but does not destroy the flashback data archive.) For example, if the retention period is 10 days, then every day after the tenth day, the oldest information is deleted; thus leaving only 10 days of information in the archive. This is a way to implement digital shredding. Inactive data DML operations FBDA 1 yr retention Flashback data archives stored in tablespaces 2 yr retention 5 yr retention

Creating a Flashback Data Archive
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) CREATE FLASHBACK ARCHIVE fba1 TABLESPACE tbs_fba1 QUOTA 5G RETENTION 1 MONTH; Allow a user to track changes to his tables in the fba1 archive GRANT FLASHBACK ARCHIVE ON fba1 TO fred;

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

FDA Dictionary Information
SELECT * FROM dba_flashback_archive; FLASHBACK_ FLASHBACK_ RETENTION_ CREATE_TIME LAST_PURGE_TIME STATUS ARCHIVE_NAME ARCHIVE# IN_DAYS FBA OCT NOV SELECT * FROM dba_flashback_archive_ts; FLASHBACK_ARCHIVE_NAME FLASHBACK_ TABLESPACE_NAME QUOTA_IN_MB ARCHIVE# FBA TBS_FBA SELECT * FROM dba_flashback_archive_tables; TABLE_NAME OWNER_NAME FLASHBACK_ARCHIVE_NAME ARCHIVE_TABLE_NAME EMPARCH SYS FBA SYS_FBA_HIST_69882 Does not show in dba_tables until actually used by FBDA

Population of Flashback Archive Table
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 SELECT * FROM sys_fba_hist_69882; RID STARTSCN ENDSCN XID O EMPNO ENAME SAL COMM AAAR0nAABAAAVxiAAA D00C I SMITH 800 AAAR0nAABAAAVxiAAB D00C I ALLEN AAAR0nAABAAAVxiAAC D00C I WARD AAAR0nAABAAAVxiAAD D00C I JONES 2975 AAAR0nAABAAAVxiAAE D00C I MARTIN AAAR0nAABAAAVxiAAF D00C I BLAKE 2850 AAAR0nAABAAAVxiAAG D00C I CLARK 2450 AAAR0nAABAAAVxiAAH D00C I SCOTT 3000 AAAR0nAABAAAVxiAAI D00C I KING AAAR0nAABAAAVxiAAJ D00C I TURNER AAAR0nAABAAAVxiAAK D00C I ADAMS 1100 AAAR0nAABAAAVxiAAL D00C I JAMES 950 AAAR0nAABAAAVxiAAM D00C I FORD AAAR0nAABAAAVxiAAN D00C I MILLER 1300 ROWIDs of rows in base table NULL if operation is direct path (e.g CTAS)

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_FBA SYS_FBA_DDL_COLMAP_69878 N FRED TBS_FBA SYS_FBA_TCRV_ N FRED TBS_FBA SYS_FBA_DDL_COLMAP_69882 N FRED TBS_FBA SYS_FBA_TCRV_ N FRED SYS_FBA_HIST_ N FRED SYS_FBA_HIST_ 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_ 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_ Y No value for tablespace_name because they are partitioned

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 Size could well be governed by _flashback_archiver_partition_size Partitions may be compressed – only for OLTP

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_ HIGH_VALUE : HIGH_VALUE_LENGTH : 7 INITIAL_EXTENT : COMPRESSION : ENABLED COMPRESS_FOR : ADVANCED PARTITION_NAME : HIGH_PART HIGH_VALUE : MAXVALUE HIGH_VALUE_LENGTH : 8 SCN value used as partition key Note first extent is 8M and is not deferred

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 | SORT AGGREGATE | | | | 2 | VIEW | | | | 3 | UNION-ALL | | | |* 4 | FILTER | | | | 5 | PARTITION RANGE SINGLE| | | |* 6 | TABLE ACCESS FULL | SYS_FBA_HIST_69882 | | |* 7 | FILTER | | | |* 8 | HASH JOIN OUTER | | | |* 9 | TABLE ACCESS FULL | EMP_FLASH | | | 10 | VIEW | | 204K| |* 11 | TABLE ACCESS FULL | SYS_FBA_TCRV_69882 | 204K| could index columns in this table This table is automatically indexed

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

Column Mapping and DDL Restrictions
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 DROP COLUMN job; ALTER TABLE emparch RENAME COLUMN salary TO sal; SELECT * FROM sys_fba_ddl_colmap_69882; STARTSCN ENDSCN XID OPERATION COLUMN_NAME TYPE HISTORICAL_ COLUMN_NAME EMPNO NUMBER(4) EMPNO NAME VARCHAR2(12) ENAME SAL NUMBER(7,2) SALARY COMM NUMBER(7,2) COMM D_ _JOB VARCHAR2(15) JOB

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 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

Stopping Archiving 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 Archiving can be temporarily disabled using dbms_flashback_archive Keeps the history table Allows schema modifications EXEC dbms_flashback_archive.dissociate_fba(’scott’,’emp’) Make structural changes to table being archived Make corresponding structural changes to the history table 4. EXEC dbms_flashback_archive.reassociate_fba(’scott’,’emp’) ALTER TABLE scott.emp NO FLASHBACK ARCHIVE;

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 BUT Unified Auditing on 12c uses a buffering mechanism 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);

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;

FDA versus Database Triggers Results
Three tables with same data ( rows) emp_none – no auditing emp_fda - FDA emp_trig – Trigger EMPNO ENAME SAL COMM 7654 aaaa 7698 aaaa 2850 : : : : Update all records and then commit on all three tables UPDATE <<table_name>> SET ename = 'bbbb'; COMMIT; Table emp_none emp_fda emp_trig Update 2.45s 3.81s 9.70s Commit 0.00s 0.18s

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

New View – sys_fba_context_aud
EXEC PT ('SELECT * FROM sys.sys_fba_context_aud') XID : 1E 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 : TERMINAL : LT1 SPARE : : : It appears that both ALL and TYPICAL generate this information

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

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’ See dbms_flashback_archive documentation 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;

Importing User-Generated Archive Data
Extend mappings to the past (01-JAN-1988) to enable import of history EXEC DBMS_FLASHBACK_ARCHIVE.extend_mappings(); Create an empty temp_history table for previously user managed archive table dbms_flashback_archive.create_temp_history_table('fred','emp') Populate temp table from audit table (must commit) INSERT INTO temp_history SELECT * FROM emp_aud; COMMIT; 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) Import temp table data into FDA History table dbms_flashback_archive.import_history('fred','emp') 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

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; /

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 : 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)

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 YES NO EMP_VT_TIME_END TIMESTAMP(6) WITH TIME ZONE YES NO EMP_VT_TIME NUMBER YES YES EMPNO NUMBER NO NO ENAME VARCHAR NO NO user_tab_columns does not show hidden columns

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 PM GMT' ,'05-APR PM GMT'); INSERT INTO emp_vt(empno,ename,emp_vt_time_start,emp_vt_time_end) VALUES (1024 ,'ADAMS' ,'06-APR PM GMT' ,'05-APR PM GMT'); Valid from 1st to 5th April SELECT * FROM emp_vt; EMPNO ENAME 1023 COX 1024 ADAMS SELECT * FROM emp_vt AS OF PERIOD FOR emp_vt_time '03-APR PM'; EMPNO ENAME 1023 COX SELECT * FROM emp_vt WHERE emp_vt_time_start > '03-APR PM'; EMPNO ENAME 1024 ADAMS

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 PM GMT 05-APR PM GMT 1024 ADAMS 06-APR PM GMT 05-APR PM GMT Additional periods each require three extra columns No real support for primary keys What if employees have numerous valid periods Cannot have more than one row for each employee

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

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 :18:34 INDEX_OWNER : INDEX_NAME : INVALID : VIEW_RELATED : ORIGIN_CON_ID : 0 A null value appears to get past the constraint

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' :00: ')) AND ("T"."VT_A_END" IS NULL OR SYS_EXTRACT_UTC("T"."VT_A_END")>SYS_EXTRACT_UTC(TIMESTAMP' 00:00: ')) AND ("T"."VT_B_START" IS NULL OR SYS_EXTRACT_UTC("T"."VT_B_START")<=SYS_EXTRACT_UTC(TIMESTAMP' :00: ')) AND ("T"."VT_B_END" IS NULL OR SYS_EXTRACT_UTC("T"."VT_B_END")>SYS_EXTRACT_UTC(TIMESTAMP' 00:00: ')))

Table With User-generated Start and End Columns
CREATE TABLE emp_mine (empno NUMBER ,ename VARCHAR2(12) ,stime DATE ,etime DATE); SELECT * FROM emp_mine; EMPNO ENAME STIME ETIME 11 COX 20-JAN FEB-13 12 ALLEN 20-JAN FEB-13 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 YES YES ETIME DATE NO NO STIME DATE NO NO ENAME VARCHAR NO NO EMPNO NUMBER NO NO

Flashback Techniques for Oracle Database 11g and Oracle Database 12c

Flashback Techniques for Oracle11g and Oracle12c
Carl Dudley Tradba Ltd Oracle ACE Director

Flashback Techniques for Oracle11g and Oracle12c

Similar presentations

Presentation on theme: "Flashback Techniques for Oracle11g and Oracle12c"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Flashback Techniques for Oracle11g and Oracle12c

Similar presentations

Presentation on theme: "Flashback Techniques for Oracle11g and Oracle12c"— Presentation transcript:

Similar presentations

About project

Feedback