SCN
System Change Number. A database ordering primitive. The value of an SCN is the logical point in time at which changes are made to a database.
SCN的值是数据库进行更改时记录逻辑时间点。可以理解成SCN就相当于ORACLE的计时方法
详见https://docs.oracle.com/cd/E11882_01/server.112/e40540/glossary.htm#CHDBFAEG
查询当前SCN
SQL>select dbms_flashback.get_system_change_number() from dual;--不会影响原有的最新值
SQL>select current_scn from v$database;--SQL只要执行一次SCN就会在原有的最新值的基础上加1,和序列号的nextval相似
https://docs.oracle.com/database/121/REFRN/GUID-B33E13DF-0BF1-4E20-8471-CE168A8380FD.htm#REFRN-GUID-B33E13DF-0BF1-4E20-8471-CE168A8380FD
V$DATABASE displays information about the database from the control file
V$DATAFILE_HEADER displays datafile information from the datafile headers
V$DATAFILE displays datafile information from the control file
P18
undo参见官方文档https://docs.oracle.com/cd/E11882_01/server.112/e25494/undo.htm#ADMIN11460
回滚段中的数据主要分为以下三种类型：
1.Uncommitted undo information; 未提交的回滚数据，该数据所关联的事务并未提交，用于实现读一致性，所以该数据不能被其它事务的数据所覆盖(假如回滚段不够的情况下，开始执行一个事务，执行到一半就会提示ORA-30036:无法按8扩展段(在还原表空间‘XXXX’中)。就如undo只有10M的情况下，delete一张100M的表，delete执行不到一半就会开始报错了。)
2.Committed undo information; 已经提交但未过期的回滚数据，该数据关联的事务已经提交，但是仍在undo retention参数保持的时间内
3.Expired undo information; 事务已经提交，而且数据保存时间已经超过undo retention参数指定的时间，属于已经过期的数据
当回滚段不足时，会优先覆盖Expired undo information，当过期数据空间覆盖后，会再覆盖Committed undo information的区域，这时undo retention参数所规定的保持时间是不起作用的，Uncommitted undo information的数据是不允许覆盖的，如果要求提交的数据在undo retention参数规定的时间内不会被覆盖，必须在undo表空间上指定RETENTION GUARANTEE
查询UNDO表空间是否启用retention guarantee
SQL> SELECT tablespace_name, retention FROM dba_tablespaces where tablespace_name='UNDOTBS1';
SQL> alter tablespace UNDOTBS1 retention guarantee;
SQL> SELECT tablespace_name, retention FROM dba_tablespaces where tablespace_name='UNDOTBS1';
了解Oracle在什么情况下会产生ORA-01555:快照过旧错误
假设有一张1000万行数据的test表，预计test全表扫描1次需要1个小时，参考过程如下：
1、在1:00，用户A发出了select * from test;此时不管将来test怎么变化，1小时执行完后显示的正确结果应该是用户A看到在1:00这个时刻的内容。
2、在1:20，用户B执行了update命令，更新了test表中的第900万行的这条记录，这时，用户A的全表扫描还没有到达第900万条。毫无疑问，这个时候，第900万行的这条记录是被写入了回滚段，假设是回滚段UNDOTS1，如果用户A的全表扫描到达了第900万行，是应该会正确的从回滚段UNDOTS1中读取出1:00这个时刻的内容的。
3、到了1:30这时，用户B将他刚才做的update操作提交了，但是这时，系统仍然可以给用户A提供正确的数据，因为那第900万行记录的内容仍然还在回滚段UNDOTS1里。但要注意到，就是第900万行在回滚段UNDOTS1里的数据有可能随时被覆盖掉，因为这条记录已经被提交了！
4、到了1:40这时，由于用户A的查询时间漫长，而业务在一直不断的进行，UNDOTS1回滚段在被多个不同的事务使用着，回滚段出现不足的情况，由于test表第900万行的这条记录已经被标记提交了，所以在1:40它在回滚段中的空间被其他事务覆盖掉的！
5、到了1:50，用户A的查询终于到了第900万行，这时需要到回滚段UNDOTS1去找数据，而这时已经出现了第4条说的情况，该回滚段已经被覆盖掉了，这时就出现了ORA-01555错误。
ORACLE的多版本与读一致性
网络上比较好的一个例子https://blog.csdn.net/garefield/article/details/1818572
create table test1 (hid number,hname varchar2(10));
insert into test1 values (1,'1');
insert into test1 values (2,'2');
commit;
SQL> select * from test1;
HID HNAME
---------- ----------
1 1
2 2
begin
for s in (select * from test1) loop
insert into test1 values(s.hid+10,s.hname);
end loop;
commit;
end;
SQL> select * from test1;
HID HNAME
---------- ----------
1 1
2 2
11 1
12 2
闪回查询
alter session set nls_date_format='YYYY-MM-DD hh24:mi:ss';
select sysdate from dual;
SELECT dbms_flashback.get_system_change_number FROM dual;
conn hr/123456
select * from JOB_HISTORY;
delete from JOB_HISTORY where EMPLOYEE_ID>101;
commit;
select * from JOB_HISTORY;
按time：as of timestamp
select * from JOB_HISTORY as of timestamp to_timestamp('XX','YYYY-MM-DD hh24:mi:ss');
按scn：as of scn
select * from JOB_HISTORY as of scn XX;
SCN和time的关系
select time_dp,scn from sys.smon_scn_time order by 1 desc
闪回版本查询
GRANT EXECUTE ON SYS.DBMS_LOCK TO HR;
grant select on sys.smon_scn_time to hr;
alter database add supplemental log data;
create table hr.test1(id number primary key,name varchar2(10));--10秒后执行下面语句
begin
insert into test1 values(1,'A');
commit;
insert into test1 values(2,'B');
commit;
insert into test1 values(3,'C');
commit;
dbms_lock.sleep(5);
update test1 set name='C-1' where id=3;
commit;
insert into test1 values(4,'D');
commit;
end;
select id,name,versions_startscn,versions_starttime,versions_xid,versions_operation from hr.test1 versions BETWEEN SCN MINVALUE AND MAXVALUE order by 3
--查询结果发现1、2、3的versions_starttime都一样，但是versions_startscn各不一样
--versions_startscn,versions_starttime等伪列的解释见https://docs.oracle.com/cd/E11882_01/server.112/e41084/pseudocolumns003.htm#SQLRF00252
闪回事务查询
select id,name,versions_startscn,versions_starttime,versions_xid,versions_operation from hr.test1 versions BETWEEN SCN MINVALUE AND MAXVALUE order by 3
select * from flashback_transaction_query where xid='0100000012040000'
闪回事务查询需要ADD SUPPLEMENTAL LOG DATA的说明
https://docs.oracle.com/cd/E11882_01/appdev.112/e41502/adfns_flashback.htm#ADFNS610
闪回丢弃
SQL> create table test123 as select EMPLOYEE_ID from hr.employees;
SQL> drop table test123;
SQL> create table test123 as select FIRST_NAME from hr.employees;
SQL> drop table test123;
SQL> show recyclebin;
SQL> flashback table test123 to before drop;
SQL> desc test123
SQL> show recyclebin;
SQL> flashback table test123 to before drop;
ERROR at line 1:
ORA-38312: original name is used by an existing object
SQL> flashback table test123 to before drop rename to test123_EMPLOYEE_ID;
SQL> desc test123_EMPLOYEE_ID
--类似堆栈，先进后出。
oracle回收站中的被删除的表会存放多长时间
空间不够用,需要扩展新的extent之前，按时间顺序尝试逐个清空回收站中的对象（从最早删除的对象开始清除）,全清空还是不够则扩展新extent
oracle原则上不会自动删除或者覆盖你回收站，只有出现“space pressure”空间压力的情况才会清理回收站
Dropped objects are kept in the recycle bin until such time as no new extents can be allocated in the tablespace to which the objects belong without growing the tablespace.
参考https://docs.oracle.com/cd/B19306_01/backup.102/b14192/flashptr004.htm
闪回表
conn hr/123456
select * from JOB_HISTORY;
ALTER TABLE JOB_HISTORY ENABLE ROW MOVEMENT;
flashback table JOB_HISTORY to scn XX
select * from test1
需要ROW MOVEMENT的原因
每一行数据都对应一个row_id，记录了数据存放的具体位置，哪个数据文件、哪个数据块、哪行
比如1行数据被删除了，这行对应的数据块就空了，一旦有其他数据插入，可能就会写入到这些到数据块上，也就是这行数据的位置被其他数据占用了，以后如果要恢复这行，因为原先的位置被其他数据占用，就要改变这行数据的位置，这就是row movement
注意事项
基于undo 的表恢复，需要注意DDL操作的影响，就是commit后，再对表做DDL操作会使undo表空间中的撤销数据失效，对于执行过这些操作的表应用flashback query会触发错误ORA-01466:无法读取数据 - 表定义已更改。
select * from JOB_HISTORY as of scn XX;
truncate table JOB_HISTORY
select * from JOB_HISTORY as of scn XX;--报错ORA-01466:无法读取数据 - 表定义已更改。
闪回数据库
SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /u01/app/oracle/archivelog
Oldest online log sequence 65
Current log sequence 67
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database flashback on;
alter database flashback on
*ERROR at line 1:
ORA-38706: Cannot turn on FLASHBACK DATABASE logging.
ORA-38709: Recovery Area is not enabled.
SQL> show parameter recover
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
db_recovery_file_dest_size big integer 0
db_unrecoverable_scn_tracking boolean TRUE
recovery_parallelism integer 0
SQL> alter system set db_recovery_file_dest='/u01/app/oracle/flashlog';
alter system set db_recovery_file_dest='/u01/app/oracle/flashlog'
*ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-19802: cannot use DB_RECOVERY_FILE_DEST without DB_RECOVERY_FILE_DEST_SIZE
SQL> alter system set db_recovery_file_dest_size=1G;
SQL> alter system set db_recovery_file_dest='/u01/app/oracle/flashlog';
SQL> alter database flashback on;
SQL> alter database open;
SQL> create table hr.test1 as select employee_id from hr.employees;
SQL> SELECT CURRENT_SCN FROM V$DATABASE;
XX
SQL> drop table hr.test1;
SQL> select count(*) from hr.test1;
select * from test1
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> shutdown immediate;
SQL> startup mount;
SQL> Flashback database to scn XX;
SQL> alter database open resetlogs;
SQL> select count(*) from hr.test1;
闪回技术的官方文档https://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmintro.htm#BRADV89342
闪回技术分以下几类
闪回查询：Flashback Query (SELECT AS OF)
闪回版本查询：Flashback Version Query
闪回事务查询：Flashback Transaction Query
闪回表:Flashback Table
闪回删除:Flashback Drop
闪回数据归档：Flashback Data Archive