本文介绍Oracle Database 12c中关于数据生命周期管理多个新特性中相对最简单的一个，数据库内归档（In-Database Archiving）。使用的测试表是上一篇介绍数据时间有效期管理中使用的TV表（包括表结构和测试数据），如果你还没有看过上一篇文章，可以先阅读【Oracle Database 12c New Feature】ILM – Temporal Validity。

相比起数据时间有效期管理而言，数据库内归档非常简单，只有一个开关，对于一条数据，要不就是活跃的允许显示，要不就是归档掉不显示，这是由数据库管理员来人工操作的。

在设置数据库内归档之前，必须要在表级别启用该特性。如上一篇文章提到的，In-Database Archiving支持多租户架构，可以在PDB中使用。

SQL> alter table TV row archival;

Table altered.

Oracle仍然是使用隐藏列来实现这个功能的，在启用该特性以后，会自动在表上增加ORA_ARCHIVE_STATE字段，这是一个VARCHAR2(4000)的字段。

SQL> select COLUMN_NAME,DATA_TYPE,HIDDEN_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='TV';

COLUMN_NAME          DATA_TYPE            HID
-------------------- -------------------- ---
ORA_ARCHIVE_STATE    VARCHAR2             YES
SYS_NC00005$         RAW                  YES
VALID_TIME_END       DATE                 YES
VALID_TIME_START     DATE                 YES
INSERT_TIME          DATE                 NO
VALID_TIME           NUMBER               YES

6 rows selected.

先检查一下TV表中的数据分布，一共有9个不同的时间段，前面5个都只有1条记录，后面4个则有大量测试记录。

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1
20130811 09:50:44      19368
20130811 09:50:46      19368
20130811 09:50:47      19368
20130811 09:50:48      19368

9 rows selected.

尝试将所有20130811 09:50之后的记录全部设置为归档模式。直接使用UPDATE语句将ORA_ARCHIVE_STATE字段更新为任意非0的字符，0表示该记录是活跃的，任何非0字符都表示该记录被归档。

SQL> UPDATE TV SET ORA_ARCHIVE_STATE = '20' WHERE INSERT_TIME>to_date('20130811 09:50','YYYYMMDD HH24:MI');

77472 rows updated.

再次执行相同的查询语句，可以看到只存在活跃的5条记录了。

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1

5 rows selected.

可以在会话级别设置即使是记录被归档，也仍然显示出来。

SQL> ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ALL;

Session altered.

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1
20130811 09:50:44      19368
20130811 09:50:46      19368
20130811 09:50:47      19368
20130811 09:50:48      19368

9 rows selected.

检查ORA_ARCHIVE_STATE值，可以看到所有活跃数据的ORA_ARCHIVE_STATE字段值均为0，这也是在表级别启用数据库内归档以后的默认值。

SQL> select ORA_ARCHIVE_STATE,INSERT_TIME,count(*) from TV group by ORA_ARCHIVE_STATE,INSERT_TIME order by 2;

ORA_ARCHIVE_STATE    INSERT_TIME         COUNT(*)
-------------------- ----------------- ----------
0                    20130811 09:04:30          1
0                    20130811 09:08:27          1
0                    20130811 09:22:30          1
0                    20130811 09:39:40          1
0                    20130811 09:45:22          1
20                   20130811 09:50:44      19368
20                   20130811 09:50:46      19368
20                   20130811 09:50:47      19368
20                   20130811 09:50:48      19368

9 rows selected.

将其中的一些记录的ORA_ARCHIVE_STATE字段更新为另外的非0字符。

SQL> update TV set ORA_ARCHIVE_STATE='ARCHIVING' where INSERT_TIME='20130811 09:50:48';

19368 rows updated.

SQL> select ORA_ARCHIVE_STATE,INSERT_TIME,count(*) from TV group by ORA_ARCHIVE_STATE,INSERT_TIME order by 2;

ORA_ARCHIVE_STATE    INSERT_TIME         COUNT(*)
-------------------- ----------------- ----------
0                    20130811 09:04:30          1
0                    20130811 09:08:27          1
0                    20130811 09:22:30          1
0                    20130811 09:39:40          1
0                    20130811 09:45:22          1
20                   20130811 09:50:44      19368
20                   20130811 09:50:46      19368
20                   20130811 09:50:47      19368
ARCHIVING            20130811 09:50:48      19368

在会话级别重新设置不显示归档数据，可以看到只要是ORA_ARCHIVE_STATE字段不为0的记录都不会显示。

SQL> ALTER SESSION SET ROW ARCHIVAL VISIBILITY = ACTIVE;

Session altered.

SQL> select INSERT_TIME,count(*) from TV group by INSERT_TIME order by 1;

INSERT_TIME         COUNT(*)
----------------- ----------
20130811 09:04:30          1
20130811 09:08:27          1
20130811 09:22:30          1
20130811 09:39:40          1
20130811 09:45:22          1

性能考虑，这一点数据库内归档与时间有效性是相同的，都只是对隐藏字段进行了filter操作。即使是只显示活跃数据，也仍然需要扫描全表。这一点在真实应用中可以通过创建索引来避免全表扫描，可以参看MOS Note: Potential SQL Performance Degradation When In Database Row Archiving (Doc ID 1579790.1)，也就是数据库内归档只应该在一个具备良好性能的SQL基础上对返回结果进行过滤，而不要期望归档的记录不参与扫描。

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:04:30
20130811 09:08:27
20130811 09:22:30
20130811 09:39:40
20130811 09:45:22


Execution Plan
----------------------------------------------------------
Plan hash value: 1723968289

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     4 |  8044 |   102   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TV   |     4 |  8044 |   102   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("TV"."ORA_ARCHIVE_STATE"='0')

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        375  consistent gets
          0  physical reads
          0  redo size
        648  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          5  rows processed

数据库内归档可以跟时间有效性管理一起配合使用。在会话级别激活时间有效性，可以看到检索不再返回任何数据。执行计划中显示filter条件融合了数据库内归档跟时间有效性两层过滤。

SQL> exec dbms_flashback_archive.enable_at_valid_time('CURRENT');

PL/SQL procedure successfully completed.

SQL> select * from tv;

no rows selected


Execution Plan
----------------------------------------------------------
Plan hash value: 1723968289

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     3 |  6087 |   102   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TV   |     3 |  6087 |   102   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."ORA_ARCHIVE_STATE"='0' AND ("T"."VALID_TIME_START"
              IS NULL OR SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_START"))<=S
              YS_EXTRACT_UTC(SYSTIMESTAMP(6))) AND ("T"."VALID_TIME_END" IS NULL OR
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_END"))>SYS_EXTRACT_UTC
              (SYSTIMESTAMP(6))))


Statistics
----------------------------------------------------------
         34  recursive calls
          8  db block gets
        397  consistent gets
          0  physical reads
          0  redo size
        347  bytes sent via SQL*Net to client
        532  bytes received via SQL*Net from client
          1  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          0  rows processed

将时间有效期设置为20130811 09:39:50，根据上一篇文章我们设置的1分钟有效期，只有在20130811 09:39:40插入的这条活跃记录可以被显示出来。

SQL> exec dbms_flashback_archive.enable_at_valid_time('ASOF',to_date('20130811 09:39:50','YYYYMMDD HH24:MI:SS'));

PL/SQL procedure successfully completed.

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:39:40


Execution Plan
----------------------------------------------------------
Plan hash value: 1723968289

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     3 |  6087 |   102   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| TV   |     3 |  6087 |   102   (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("T"."ORA_ARCHIVE_STATE"='0' AND ("T"."VALID_TIME_START"
              IS NULL OR INTERNAL_FUNCTION("T"."VALID_TIME_START")<=TIMESTAMP'
              2013-08-11 09:39:50.000000000') AND ("T"."VALID_TIME_END" IS NULL OR
              INTERNAL_FUNCTION("T"."VALID_TIME_END")>TIMESTAMP' 2013-08-11
              09:39:50.000000000'))


Statistics
----------------------------------------------------------
         35  recursive calls
          6  db block gets
        398  consistent gets
          0  physical reads
          0  redo size
        550  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

结论：数据库内归档是一个Oracle利用隐藏字段实现的非常简单的功能，但是数据架构人员在规划的时候一定要考虑性能因素。

ILM全称是Information Lifecycle Management，意思是信息生命周期管理，听上去很高端洋气的一个词，但是实际上几乎每个稍微大些的系统都已经在做ILM了，比如说将生产表中的数据定期插入到历史表中，并把生产表中的这些数据删除，这就是数据生命周期管理；又比如使用了分区，定期将过期的数据分区删除掉，或者置为READONLY，让RMAN不再备份，这也是数据生命周期管理。

因此ILM由来已久，只要数据存在活跃-不活跃-静止这样的周期变化，那么ILM就必不可少，Oracle Database 12c中提供了很多新功能用来方便地进行数据生命周期管理，有些功能甚至是我们期盼已久的。

本文先介绍时间有效期管理（Temporal Validity），下两篇文章会介绍数据库内归档（In-Database Archiving）以及数据热度图（Heat Map）。注意：Temporal Validity和Heat Map目前还不支持多租户架构的数据库，因此想要使用，必须是一个NON-CDB，In-Database Archiving则支持多租户架构，可以在PDB中使用。

一. 时间有效期管理（Temporal Validity）
以下简称TV，TV的功能大致上可以这样描述：在表中手动或者自动建两个时间类型的字段，一个表示有效期的开始时间，一个表示有效期的结束时间，就可以通过设置让只有在有效期内的记录才会被选择出来。

以下这个场景是我构想出来的，一张表里不断地INSERT数据，但是每条数据有效期只有1分钟，过了1分钟再查就看不见了，如果加以仔细策划，应该会是很有趣的功能。直接进入测试。

设置TV，需要使用dbms_flashback_archive包，需要该包的执行权限。

SQL> grant execute on dbms_flashback_archive to kamus;

创建测试表，period for关键字是TV新功能的关键字，valid_time是TV策略的名字，可以随便写。valid_time_start和valid_time_end字段可以不手工定义，只要指定了period for关键字，Oracle会自动创建两个不可见字段。我这里之所以手工定义开始和结束时间字段，是为了能够指定DEFAULT值。有效期开始时间valid_time_start是记录插入的当前时间，有效期结束时间valid_time_end是当前时间的后一分钟。由此定义出了一个跨度1分钟的有效期。

SQL> conn kamus/oracle
SQL> create table TV (insert_time date, 
valid_time_start date invisible default sysdate, 
valid_time_end date invisible default sysdate+1/1440, 
period for valid_time(valid_time_start,valid_time_end)
);

可以看到明确定义的INSERT_TIME字段用于演示，VALID_TIME_START和VALID_TIME_END是明确定义的不可见字段。之外，Oracle还自动创建了VALID_TIME字段，也是隐藏字段。

SQL> select COLUMN_NAME,DATA_TYPE,HIDDEN_COLUMN FROM USER_TAB_COLS WHERE TABLE_NAME='TV';

COLUMN_NAME          DATA_TYPE            HID
-------------------- -------------------- ---
VALID_TIME_END       DATE                 YES
VALID_TIME_START     DATE                 YES
INSERT_TIME          DATE                 NO
VALID_TIME           NUMBER               YES

插入一行当前时间

SQL> insert into TV values (sysdate);

1 row created.

正常情况选择，这行记录总是存在的

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:04:30

为了应对这个新功能，在Flashback Query中新增了as of period for关键字。as of period for valid_time sysdate+1表示我们想查询在明天都还有效的数据，因为根据我们的设定，所有数据都只在插入以后1分钟内有效，因此自然无法找到在明天还有效的数据，返回零条记录。

SQL> select * from TV as of period for valid_time sysdate+1;

no rows selected

再插入一条测试数据。

SQL> insert into TV values (sysdate);

1 row created.

SQL> select * from TV;

INSERT_TIME
-----------------
20130811 09:04:30
20130811 09:08:27

我们想查询昨天就有效的数据，但是所有的数据有效期开始都是插入数据的那个时间点，自然无法找到昨天就有效的数据，返回零条记录。

SQL> select * from TV as of period for valid_time sysdate-1;

no rows selected

除了使用as of这种闪回查询的语法，还可以直接在会话级别设置有效时间点。CURRENT表示设置为当前时间点。

SQL> exec dbms_flashback_archive.enable_at_valid_time('CURRENT');

PL/SQL procedure successfully completed.

SQL> select * from TV;

no rows selected

在我的测试过程中，TV并不稳定，有时候即使设置了as of，也仍然会返回所有记录，但是过一会儿再次执行完全相同的语句，又能够返回符合条件的记录。没有详细跟踪不稳定的原因，但是猜测与cursor执行计划重用有关，毕竟Oracle的实现只是增加了一个filter条件，如果由于某种原因，之前cursor的执行计划被重用，那么很可能这个filter条件就没有加上，随之而来的也就会返回所有记录。

接下来，我们通过显示执行计划，看看Oracle是如何增加这个filter条件的。
首先禁用TV。执行计划是很正常的全表扫描。

SQL> exec dbms_flashback_archive.DISABLE_ASOF_VALID_TIME;

PL/SQL procedure successfully completed.

SQL> select count(*) from tv;

  COUNT(*)
----------
     77477


Execution Plan
----------------------------------------------------------
Plan hash value: 4129329588

-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   102   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TV   | 76349 |   102   (0)| 00:00:01 |
-------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
        333  consistent gets
          0  physical reads
          0  redo size
        544  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

重新在会话级别启用TV，可以看到在第二步，也就是全表扫描之后增加了一个filter，由于指定的有效期是CURRENT，因此filter条件是VALID_TIME_START 小于等于 当前时间 小于 VALID_TIME_END，也就是只要指定的有效期落在VALID_TIME_START和VALID_TIME_END之间，这条记录就可以被显示出来。同时也可以看到如果这两个限制条件为空，也都作为开放区间，也就是为空就表示不做限制。
由于测试的记录都只有1分钟有效期，因此此时已经没有一条记录可以显示了。

SQL> exec dbms_flashback_archive.enable_at_valid_time('CURRENT');

PL/SQL procedure successfully completed.

SQL> select count(*) from tv;

  COUNT(*)
----------
         0


Execution Plan
----------------------------------------------------------
Plan hash value: 4129329588

---------------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Bytes | Cost (%CPU)| Time     |
---------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |    18 |   103   (1)| 00:00:01 |
|   1 |  SORT AGGREGATE    |      |     1 |    18 |            |          |
|*  2 |   TABLE ACCESS FULL| TV   |   287 |  5166 |   103   (1)| 00:00:01 |
---------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(("T"."VALID_TIME_START" IS NULL OR
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_START"))<=SYS_EXTRACT_
              UTC(SYSTIMESTAMP(6))) AND ("T"."VALID_TIME_END" IS NULL OR
              SYS_EXTRACT_UTC(INTERNAL_FUNCTION("T"."VALID_TIME_END"))>SYS_EXTRACT_UTC
              (SYSTIMESTAMP(6))))


Statistics
----------------------------------------------------------
         33  recursive calls
          4  db block gets
        354  consistent gets
          0  physical reads
          0  redo size
        541  bytes sent via SQL*Net to client
        543  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

通过执行计划显示后台机制是一方面，另一方面我们也可以看到实际上TV是会有性能问题的，如果WHERE条件中无法使用到索引而执行了全表扫描（我这里因为没有WHERE条件所以只能是全表扫描），那么无论最终符合有效期的记录是多少，总要先进行所有记录的扫描，我们可以通过前后两次的consistent gets基本相同来获得这个结论。

更直白的说，如果作为系统设计人员不去考虑索引的构建，而仅仅是启用了TV，那么哪怕根据有效期限制，有10万记录的表只有1条会被显示出来，也仍然需要先扫描10万记录，然后再filter掉99999条，这对于程序员来说，如果不仔细阅读执行计划，就可能会造成很大的困扰，程序员会很奇怪，为什么这张表里面看上去只有1条记录，但是却要扫描那么长时间呢？

结论：数据有效期是Oracle利用隐藏字段和Flashback Query技术作的一个有趣的功能，但是数据架构人员在规划的时候一定要考虑性能因素。