本文描述的是12.1.0.2上的特性，包含索引，PDB的特性及增强等。
Advanced Index Compression
高级索引压缩在所有Oracle支持的索引类型上都能够很好的工作，包括索引的前导列中没有、或几个重复值的索引Creating an Index Using Prefix Compression(之前的索引压缩方式)
CREATE INDEX hr.emp_ename ON emp(ename) TABLESPACE users COMPRESS 1;
Creating an Index Using Advanced Index Compression(新的压缩方式)CREATE INDEX hr.emp_mndp_ix ON hr.employees(manager_id, department_id) COMPRESS ADVANCED LOW;
Approximate Count Distinct
引入了函数APPROX_COUNT_DISTINCT()，这个在海量数据中，对数据要求不是那么精确时，这个函数能快速的给出结果
Automatic Big Table Caching
在以前的版本中，当多个扫描争用缓存内存时，内存中的并行查询并没有很好的工作。这个特性实施了一个称作大表缓存的功能。引入了参数db_big_table_cache_percent_target，这个参数可将buffer cache分成两部分，一部分用作大表扫描使用，另外一部分用作OLTP中insert，update，delete操作。这个特性，对全表扫描的性能有明显的提升。在单实例环境中，并行和串行查询都可以，在RAC环境中，只对并行查询有用。在RAC中，需要设置下面这两个参数
db_big_table_cache_percent_target = 80 这个80的意思是，80%为扫描用，剩下的20%用作OLTP parallel_degree_policy =auto/adaptive
FDA Support for CDBs
在12.1.0.1中，CDB不支持FDA(Flashback Data Archive)，在12.1.0.2中，这个限制被移除。CDB不支持Flashback Transaction Query和Flashback Transaction Backout
Full Database Caching
从12.1.0.2开始，数据库cache有2种模式，第一种是默认的数据库Cache模式和之前的版本一样;第二种是强制全库缓存模式，这个是新的特性。当整个库的大小小于database buffer cache大小时，我们就可以把整个库的cache模式转化为强制全库缓存模式。这时，所有的数据文件，包括NOCACHE LOBs and LOBS这些使用SecureFiles都被装载到buffer cache中。
查看是否启用FULL DATABASE CACHING
select force_full_db_caching from v$database;启用FULL DATABASE CACHING
alter database force full database caching;
In-Memory Aggregation
和之前的执行计划相比，这个特性会使用新的执行计划，尤其在星型查询(通过维度表连接事实表，聚合条件使用维度表中的条件)中效果非常不错，能减少CPU的使用。想使用这个特性，的满足下面的条件，compatible必须为12.1以上，inmemory_size必须大于0。
SQL> show parameters compatible NAME TYPE VALUE ------------------------------------ ----------- compatible string 12.1.0.0 SQL> show parameter inmemory_size NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ inmemory_size big integer <Value greater then 0>查看是否启用
select name,currently_used from dba_feature_usage_statistics where name like '%In-Memory%' ;
如果启用的话，在执行计划下方，能看到下面的信息
Note
-----
- vector transformation used for this statement
相关的隐含参数 _optimizer_vector_min_fact_rows _optimizer_vector_transformation _always_vector_transformation _optimizer_vector_cost_adj相关的hint
VECTOR_TRANSFORM
VECTOR_TRANSFORM_FACT
VECTOR_TRANSFORM_DIMS
SELECT t.calendar_year, p.prod_category, SUM(quantity_sold) FROM times t, products p, sales s
WHERE t.time_id = s.time_id
AND p.prod_id = s.prod_id
GROUP BY t.calendar_year, p.prod_category;
-------------------------------------------------------------------------------------------------------------
|Id | Operation | Name |Rows|Bytes|Cost(%CPU)|Time|Pstart|Pstop|
-------------------------------------------------------------------------------------------------------------
| 0| SELECT STATEMENT | | | |285 (100)| | | |
| 1| TEMP TABLE TRANSFORMATION | | | | | | | |
| 2| LOAD AS SELECT | SYS_TEMP_0FD9D6644_11CBE8 | | | | | | |
| 3| VECTOR GROUP BY | | 5| 80 | 3 (100)|00:00:01| | |
| 4| KEY VECTOR CREATE BUFFERED | :KV0000 |1826|29216| 3 (100)|00:00:01| | |
| 5| TABLE ACCESS INMEMORY FULL | TIMES |1826|21912| 1 (100)|00:00:01| | |
| 6| LOAD AS SELECT | SYS_TEMP_0FD9D6645_11CBE8 | | | | | | |
| 7| VECTOR GROUP BY | | 5| 125 | 1 (100)|00:00:01| | |
| 8| KEY VECTOR CREATE BUFFERED | :KV0001 | 72| 1800| 1 (100)|00:00:01| | |
| 9| TABLE ACCESS INMEMORY FULL | PRODUCTS | 72| 1512| 0 (0)| | | |
| 10| HASH GROUP BY | | 18| 1440|282 (99)|00:00:01| | |
|*11| HASH JOIN | | 18| 1440|281 (99)|00:00:01| | |
|*12| HASH JOIN | | 18| 990 |278 (100)|00:00:01| | |
| 13| TABLE ACCESS FULL | SYS_TEMP_0FD9D6644_11CBE8 | 5| 80 | 2 (0)|00:00:01| | |
| 14| VIEW | VW_VT_AF278325 | 18| 702 |276 (100)|00:00:01| | |
| 15| VECTOR GROUP BY | | 18| 414 |276 (100)|00:00:01| | |
| 16| HASH GROUP BY | | 18| 414 |276 (100)|00:00:01| | |
| 17| KEY VECTOR USE | :KV0000 |918K| 20M|276 (100)|00:00:01| | |
| 18| KEY VECTOR USE | :KV0001 |918K| 16M|272 (100)|00:00:01| | |
| 19| PARTITION RANGE ALL | |918K| 13M|257 (100)|00:00:01| 1| 28|
| 20| TABLE ACCESS INMEMORY FULL| SALES |918K| 13M|257 (100)|00:00:01| 1| 28|
| 21| TABLE ACCESS FULL | SYS_TEMP_0FD9D6645_11CBE8 | 5 | 125| 2 (0)|00:00:01| | |
-------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
11 - access("ITEM_10"=INTERNAL_FUNCTION("C0") AND "ITEM_11"="C2")
12 - access("ITEM_8"=INTERNAL_FUNCTION("C0") AND "ITEM_9"="C2")
Note
-----
- vector transformation used for this statement
45 rows selected.
In-Memory Column Store
内存列存储使表或分区表在内存中以列的方式存储。扫描，连接，聚合等操作和传统格式相比性能有明显改善。内存中列的格式，不会取代硬盘上火缓存中的数据。对应用来说是透明的，无需对程序做任何修改，只需DBA简单地内存列分配内存即可，优化器会自动识别。
SELECT OWNER, SEGMENT_NAME, INMEMORY_PRIORITY, INMEMORY_COMPRESSION FROM V$IM_SEGMENTS;
JSON Support
JSON是JavaScript Object Notation的缩写。是一种轻量级的数据交换格式。易于人阅读和编写。也易于机器解析和生成，类似于XML语言。 12.1.0.2开始，Oracle支持存储和查询JSON格式的数据，
New FIPS 140 Parameter for Encryption
在安全方面，引入了新的数据库参数DBFIPS_140，提供了在Oracle数据库中打开和关闭的联邦信息处理标准（FIPS）140密码处理方式的功能，以满足安全方面的需要。
PDB CONTAINERS Clause
假如在CDB和PDB中有同样的表和视图，可以通过containers字句把CDB和PDB中的查询一并输出。CDB的视图，在12.1.0.1中，是通过CDB$VIEW的方式在实现，在12.1.0.2中是通过CONTAINERS来实现的。
下面的语句是查询在cond_id为45和49的库中表scott.emp中的employe name
SELECT ename FROM CONTAINERS(scott.emp) WHERE CON_ID IN (45, 49);其实CDB_开头的参数，也是通过containers实现的。
12.1.0.1
SQL> select TEXT_VC from cdb_views where view_name='CDB_DATA_FILES';
TEXT_VC
--------------------------------------------------------------------------------
SELECT "FILE_NAME","FILE_ID","TABLESPACE_NAME","BYTES","BLOCKS","STATUS","RELATI
VE_FNO","AUTOEXTENSIBLE","MAXBYTES","MAXBLOCKS","INCREMENT_BY","USER_BYTES","USE
R_BLOCKS","ONLINE_STATUS","CON_ID" FROM CDB$VIEW("SYS"."DBA_DATA_FILES")
12.1.0.2
SQL> select TEXT_VC from cdb_views where view_name='CDB_DATA_FILES';
TEXT_VC
--------------------------------------------------------------------------------
SELECT "FILE_NAME","FILE_ID","TABLESPACE_NAME","BYTES","BLOCKS","STATUS","RELATI
VE_FNO","AUTOEXTENSIBLE","MAXBYTES","MAXBLOCKS","INCREMENT_BY","USER_BYTES","USE
R_BLOCKS","ONLINE_STATUS","CON_ID" FROM CONTAINERS("SYS"."DBA_DATA_FILES")
PDB File Placement in OMF
一个新的初始化参数create_file_dest，她允许管理员为PDB OMF(Oracle Managed Files)设置一个默认的位置
PDB Logging Clause
在创建或修改PLUGGABLE DATABASE时，可以指定logging或nologging来设置PDB中表空间的属性。如果logging属性未指定，默认是logging模式
PDB Metadata Clone
创建PDB时，可以只克隆数据库的数据定义模型而不要数据(用户创建的表或索引的数据被舍弃)，创建时指定NO DATA就可以了
create pluggable database pdb2 from pdb1 no data;
PDB Remote Clone
通过DBLINK可以克隆一个PDB或non-CDB，这个功能不错。比如，你可以把一个12c的non-cdb克隆为一个pdb，这样就可以clone或插拔这个数据库
如果是从non-cdb克隆为pdb，在打开之前必须要执行脚本@$ORACLE_HOME/rdbms/admin/noncdb_to_pdb.sql
PDB Snapshot Cloning Additional Platform Support
如果初始化参数CLONEDB设置为true，那么在启用dNFS的任何本地文件系统，NFS文件系统或集群文件系统支持snapshot copy方式克隆数据库，源端PDB必须为只读模式。如果CLONEDB设置为false，那么存储必须支持快照。
PDB STANDBYS Clause
在Ddata Guard环境中，通过standbys字句可以指定是否克隆这个PDB。有2个值ALL和NONE，如果是ALL，则会在所有的备库中创建，如果为NONE，则在所有的备库中不创建，这时备库上的这个pdb数据文件会被offline，状态为UNNAMED。当然之后还可以启用。
STANDBYS=ALL
STANDBYS=NONE
PDB State Management Across CDB Restart
可以保存PDB的状态，在CDB重启后，数据库会自动打开。PDB默认会到mount状态，也可以使用trigger等方法，让PDB在CDB打开时自动打开。
alter pluggable database salespdb save state;
alter pluggable database salespdb discard state;
alter pluggable database all save state;
alter pluggable database all except salespdb, hrpdb save state;
PDB Subset Cloning
假如一个pdb有ts1,ts2,ts3,ts4,ts5,ts6,ts7等表空间，可以根据需要只clone其中部分表空间到一个新的pdb
USER_TABLESPACES=('tbs2');
USER_TABLESPACES=('tbs1','tbs4','tbs5');
USER_TABLESPACES=ALL EXCEPT('tbs1','tbs4','tbs5');
Rapid Home Provisioning
简单的说就是可以把oracle home做成image，然后在RHP客户端可以快速的部署，RHP是集群资源的一部分
