Oracle 12c新特性整理

在线重命名或移动数据文件

不同于以往的版本，在Oracle数据库12c R1版本中对数据文件的迁移或重命名不再需要太多繁琐的步骤。在12c R1中，可以使用ALTER DATABASE MOVE DATAFILE这样的SQL语句对数据文件进行在线重命名和移动。而当此数据文件正在传输时，终端用户可以执行查询，DML以及DDL方面的任务。另外，数据文件可以在存储设备间迁移，如从非ASM迁移至ASM，反之亦然。
　　重命名数据文件：

　　从非ASM迁移数据文件至ASM：

　　将数据文件从一个ASM磁盘群组迁移至另一个ASM磁盘群组：

　　在数据文件已存在于新路径的情况下，以相同的命名将其覆盖：

　　复制文件到一个新路径，同时在原路径下保留其拷贝：

　　当通过查询v$session_longops动态视图来移动文件时，你可以监控这一过程。另外，你也可以引用alert.log，Oracle会在其中记录具体的行为。

需要注意的是，在12c中，移动数据文件必须进入到相关的容器中才可以，否则会报错“ORA-01516: nonexistent log file, data file, or temporary file "12" in the current container”

表分区或子分区的在线迁移

　　在Oracle 12c R1中迁移表分区或子分区到不同的表空间不再需要复杂的过程。与之前版本中未分区表进行在线迁移类似，表分区或子分区可以在线或是离线迁移至一个不同的表空间。当指定了ONLINE语句，所有的DML操作可以在没有任何中断的情况下，在参与这一过程的分区或子分区上执行。与此相反，分区或子分区迁移如果是在离线情况下进行的，DML操作是不被允许的。
　　示例：

　　第一个示例是用来在离线状况下将一个表分区或子分区迁移至一个新的表空间。第二个示例是在线迁移表分区或子分区并维护表上任何本地或全局的索引。此外，当使用ONLINE语句时，DML操作是不会中断的。
　　重要提示：

• UPDATE INDEXES语句可以避免出现表中任何本地或全局索引无法使用的情况。
• 表的在线迁移限制也适用于此。
• 引入加锁机制来完成这一过程，当然它也会导致性能下降并会产生大量的redo，这取决于分区和子分区的大小。
  

  不可见字段

  　　在Oracle 11g R1中，Oracle以不可见索引和虚拟字段的形式引入了一些不错的增强特性。继承前者并发扬光大，Oracle 12c R1中引入了不可见字段思想。在之前的版本中，为了隐藏重要的数据字段以避免在通用查询中显示，我们往往会创建一个视图来隐藏所需信息或应用某些安全条件。
  　　在12c R1中，你可以在表中创建不可见字段。当一个字段定义为不可见时，这一字段就不会出现在通用查询中，除非在SQL语句或条件中有显式的提及这一字段，或是在表定义中有DESCRIBED。要添加或是修改一个不可见字段是非常容易的，反之亦然。

　　你必须在INSERT语句中显式提及不可见字段名以将不可见字段插入到数据库中。虚拟字段和分区字段同样也可以定义为不可见类型。但临时表，外部表和集群表并不支持不可见字段。

相同字段上的多重索引

　　在Oracle 12c R1之前，一个字段是无法以任何形式拥有多个索引的。或许有人会想知道为什么通常一个字段需要有多重索引，事实上需要多重索引的字段或字段集合是很多的。在12c R1中，只要索引类型的形式不同，一个字段就可以包含在一个B-tree索引中，同样也可以包含在Bitmap索引中。注意，只有一种类型的索引是在给定时间可用的。

DDL日志

　　在之前的版本中没有可选方法来对DDL操作进行日志记录。而在12c R1中，你现在可以将DDL操作写入xml和日志文件中。这对于了解谁在什么时间执行了create或drop命令是十分有用的。要开启这一功能必须对ENABLE_DDL_LOGGING 初始参数加以配置。这一参数可以在数据库或会话级加以设置。当此参数为启用状态，所有的DDL命令会记录在$ORACLE_BASE/diag/rdbms/DBNAME/log|ddl 路径下的xml和日志文件中。一个xml中包含DDL命令，IP地址，时间戳等信息。这可以帮助确定在什么时候对用户或表进行了删除亦或是一条DDL语句在何时触发。
　　开启DDL日志功能

　　以下的DDL语句可能会记录在xml或日志文件中：

• CREATE|ALTER|DROP|TRUNCATE TABLE

• DROP USER

• CREATE|ALTER|DROP PACKAGE|FUNCTION|VIEW|SYNONYM|SEQUENCE

  临时undo

  　　每个Oracle数据库包含一组与系统相关的表空间，例如SYSTEM，SYSAUX，UNDO & TEMP，并且它们在Oracle数据库中每个都用于不同的目的。在Oracle 12c R1之前，临时表生成的undo记录是存储在undo表空间里的，通用表和持久表的undo记录也是类似的。而在12c R12的临时undo功能中，临时undo记录可以存储在一个临时表中，而无需再存储在undo表空间内。这样做的主要好处在于：减少undo表空间，由于信息不会被记录在redo日志中，所以减少了redo数据的生成。你可以在会话级别或者数据库级别来启用临时undo选项。
  　　启用临时undo功能
  　　要使用这一新功能，需要做以下设置：

• 兼容性参数必须设置为12.0.0或更高

• 启用 TEMP_UNDO_ENABLED 初始化参数

• 由于临时undo记录现在是存储在一个临时表空间中的，你需要有足够的空间来创建这一临时表空间

• 对于会话级，你可以使用：ALTER SYSTEM SET TEMP_UNDO_ENABLE=TRUE;
  　　查询临时undo信息

　　
　　
　　以下所列的字典视图是用来查看或查询临时undo数据相关统计信息的：
　　

• V$TEMPUNDOSTAT

• DBA_HIST_UNDOSTAT

• V$UNDOSTAT
  　　要禁用此功能，你只需做以下设置：
  　　SQL> ALTER SYSTEM|SESSION SET TEMP_UNDO_ENABLED=FALSE;

  备份特定用户特权

  　　在11g R2中，引入了SYSASM特权来执行ASM的特定操作。同样地，在12c中引入了SYSBACKUP特权用来在 RMAN中执行备份和恢复命令。因此，你可以在数据库中创建一个本地用户并在不授予其SYSDBA权限的情况下，通过授予SYSBACKUP权限让其能够在RMAN中执行备份和恢复相关的任务。

  $ ./rman target "username/password as SYSBACKUP"

  1	$ ./rman target "username/password as SYSBACKUP"

如何在RMAN中执行SQL语句

　　在12c中，你可以在不需要SQL前缀的情况下在RMAN中执行任何SQL和PL/SQL命令，即你可以从RMAN直接执行任何SQL和PL/SQL命令。如下便是在RMAN中执行SQL语句的示例：

RMAN中的表恢复和分区恢复

　　Oracle数据库备份主要分为两类：逻辑和物理备份。每种备份类型都有其自身的优缺点。在之前的版本中，利用现有物理备份来恢复表或分区是不可行的。为了恢复特定对象，逻辑备份是必需的。对于12c R1，你可以在发生drop或truncate的情况下从RMAN备份将一个特定的表或分区恢复到某个时间点或SCN。
　　当通过RMAN发起一个表或分区恢复时，大概流程是这样的：

• 确定要恢复表或分区所需的备份集
• 在恢复表或分区的过程中，一个辅助数据库会临时设置为某个时间点
• 利用数据泵将所需表或分区导出到一个dumpfile
• 你可以从源数据库导入表或分区(可选)
• 在恢复过程中进行重命名操作
  　　以下是一个通过RMAN对表进行时间点恢复的示例(确保你已经对稍早的数据库进行了完整备份)：

　　sql 　　RMAN> connect target "username/password as SYSBACKUP"; 　　 　　RMAN> RECOVER TABLE username.tablename UNTIL TIME 'TIMESTAMP…' 　　AUXILIARY DESTINATION '/u01/tablerecovery' 　　DATAPUMP DESTINATION '/u01/dpump' 　　DUMP FILE 'tablename.dmp' 　　NOTABLEIMPORT -- this option avoids importing the table automatically.(此选项避免自动导入表) 　　REMAP TABLE 'username.tablename': 'username.new_table_name'; 　　-- can rename table with this option.(此选项可以对表重命名) 　　 　　
　　
　　重要提示：

• 确保对于辅助数据库在/u01文件系统下有足够的可用空间，同时对数据泵文件也有同样保证
• 必须要存在一份完整的数据库备份，或者至少是要有SYSTEM相关的表空间备份
  　　以下是在RMAN中应用表或分区恢复的限制和约束：
• SYS用户表或分区无法恢复
• 存储于SYSAUX和SYSTEM表空间下的表和分区无法恢复
• 当REMAP选项用来恢复的表包含NOT NULL约束时，恢复此表是不可行的
  

  限制PGA的大小

  　　在Oracle 12c R1之前，没有选项可以用来限制和控制PGA的大小。虽然你设置某个大小为PGA_AGGREGATE_TARGET 的初始参数，Oracle会根据工作负载和需求来动态地增大或减小PGA的大小。而在12c中，你可以通过开启自动PGA管理来对PGA设定硬性限制，这需要对PGA_AGGREGATE_LIMIT 参数进行设置。因此，你现在可以通过设置新的参数来对PGA设定硬性限制以避免过度使用PGA。

  SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=2G; 　　 SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0; --disables the hard limit

  1 2	SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=2G; 　　 SQL> ALTER SYSTEM SET PGA_AGGREGATE_LIMIT=0; --disables the hard limit

　　重要提示：
　　当超过了当前PGA的限制，Oracle会自动终止/中止会话或进程以保持最合适的PGA内存。
　　

对表分区维护的增强

添加多个新分区

　　在Oracle 12c R1之前，一次只可能添加一个新分区到一个已存在的分区表。要添加一个以上的新分区，需要对每个新分区都单独执行一次ALTER TABLE ADD PARTITION语句。而Oracle 12c只需要使用一条单独的ALTER TABLE ADD PARTITION 命令就可以添加多个新分区，这增加了数据库灵活性。以下示例说明了如何添加多个新分区到已存在的分区表：

　　添加两个新分区：

　　同样，只要MAXVALUE分区不存在，你就可以添加多个新分区到一个列表和系统分区表。

如何删除和截断多个分区/子分区

　　作为数据维护的一部分，DBA通常会在一个分区表上进行删除或截断分区的维护任务。在12c R1之前，对于一个已存在的分区表一次只可能删除或截断一个分区。而对于Oracle 12c， 可以用单条ALTER TABLE table_name {DROP|TRUNCATE} PARTITIONS 命令来撤销或合并多个分区和子分区。
　　下例说明了如何在一个已存在分区表上删除或截断多个分区：

　　要保持索引更新，使用UPDATE INDEXES或UPDATE GLOBAL INDEXES语句，如下所示：

　　如果你在不使用UPDATE GLOBAL INDEXES 语句的情况下删除或截断一个分区，你可以在USER_INDEXES或USER_IND_PARTITIONS 字典视图下查询ORPHANED_ENTRIES 字段以找出是否有索引包含任何的过期条目。

将单个分区分割为多个新分区

　　在12c中新增强的SPLIT PARTITION 语句可以让你只使用一个单独命令将一个特定分区或子分区分割为多个新分区。下例说明了如何将一个分区分割为多个新分区：

将多个分区合并为一个分区

　　你可以使用单条ALTER TBALE MERGE PARTITIONS 语句将多个分区合并为一个单独分区：

　　如果分区范围形成序列，你可以使用如下示例：

数据库升级改进

　　每当一个新的Oracle版本发布，DBA所要面临的挑战就是升级过程。该部分我将介绍12c中引入的针对升级的两个改进。

预升级脚本

　　在12c R1中，原有的utlu[121]s.sql 脚本由一个大为改善的预升级信息脚本preupgrd.sql所取代。除了预升级检查验证，此脚本还能以修复脚本的形式解决在升级过程前后出现的各种问题。
　　可以对产生的修复脚本加以执行来解决不同级别的问题，例如，预升级和升级后的问题。当手动升级数据库时，脚本必须在实际升级过程初始化之前加以手动执行。然而，当使用DBUA工具来进行数据库升级时，它会将预升级脚本作为升级过程的一部分加以自动执行，而且会提示你去执行修复脚本以防止报错。
　　如何执行脚本：

　　以上脚本会产生一份日志文件以及一个[pre/post]upgrade_fixup.sql 脚本。所有这些文件都位于$ORACLE_BASE/cfgtoollogs 目录下。在你继续真正的升级过程之前，你应该浏览日志文件中所提到的建议并执行脚本以修复问题。
　　注意：你要确保将preupgrd.sql和utluppkg.sql 脚本从12c Oracle的目录home/rdbms/admin directory拷贝至当前的Oracle的database/rdbms/admin路径。

并行升级功能

　　数据库升级时间的长短取决于数据库上所配置的组件数量，而不是数据库的大小。在之前的版本中，我们是无法并行运行升级程序，从而快速完成整个升级过程的。
　　在12c R1中，原有的catupgrd.sql 脚本由catctl.pl 脚本(并行升级功能)替代，现在我们可以采用并行模式运行升级程序了。
　　以下流程说明了如何初始化并行升级功能(3个过程);你需要在升级模式下在启动数据库后运行这一脚本：

　　以上两个步骤需要在手动升级数据库时运行。而DBUA也继承了这两个新变化。

通过网络恢复数据文件

　　在12c R1中另一个重要的增强是，你现在可以在主数据库和备用数据库之间用一个服务名重新获得或恢复数据文件、控制文件、参数文件、表空间或整个数据库。这对于同步主数据库和备用数据库极为有用。
　　当主数据库和备用数据库之间存在相当大的差异时，你不再需要复杂的前滚流程来填补它们之间的差异。RMAN能够通过网络执行备用恢复以进行增量备份，并且可以将它们应用到物理备用数据库。你可以用服务名直接将所需数据文件从备用点拷贝至主站，这是为了防止主数据库上数据文件、表空间的丢失，或是没有真正从备份集恢复数据文件。
　　以下流程演示了如何用此新功能执行一个前滚来对备用数据库和主数据库进行同步：
　　在物理备用数据库上：

　　以上示例使用备用数据库上定义的primary_db_tns 连接字符串连接到主数据库，然后执行了一个增量备份，再将这些增量备份传输至备用目的地，接着将应用这些文件到备用数据库来进行同步。然而，需要确保已经对primary_db_tns 进行了配置，即在备份数据库端将其指向主数据库。
　　在以下示例中，我将演示一个场景通过从备用数据库获取数据文件来恢复主数据库上丢失的数据文件：
　　在主数据库上：

对Data Pump的增强

　　Data Pump版本有了不少有用的改进，例如在导出时将视图转换为表，以及在导入时关闭日志记录等。

关闭redo日志的生成

　　Data Pump中引入了新的TRANSFORM选项，这对于对象在导入期间提供了关闭重做生成的灵活性。当为TRANSFORM选项指定了DISABLE_ARCHIVE_LOGGING 值，那么在整个导入期间，重做生成就会处于关闭状态。这一功能在导入大型表时缓解了压力，并且减少了过度的redo产生，从而加快了导入。这一属性还可应用到表以及索引。以下示例演示了这一功能：

将视图转换为表

　　这是Data Pump中另外一个改进。有了VIEWS_AS_TABLES 选项，你就可以将视图数据载入表中。以下示例演示了如何在导出过程中将视图数据载入到表中：

实时自动数据诊断监视器 (ADDM) 分析

　　通过使用诸如AWR、ASH以及ADDM之类的自动诊断工具来分析数据库的健康状况，是每个DBA日程工作的一部分。尽管每种工具都可以在多个层面衡量数据库的整体健康状况和性能，但没有哪个工具可以在数据库反应迟钝或是完全挂起的时候使用。
　　当数据库反应迟钝或是挂起状态时，而且你已经配置了Oracle 企业管理器 12c的云控制，你就可以对严重的性能问题进行诊断。这对于你了解当前数据库发生了什么状况有很大帮助，而且还能够对此问题给出解决方案。
　　以下步骤演示了如何在Oracle 企业管理器 12c上分析数据库状态：

• 在访问数据库访问主页面从Performance菜单选择Emergency Monitoring 选项。这会显示挂起分析表中排名靠前的阻止会话。
• 在Performance菜单选择Real-Time ADDM 选项来执行实时ADDM分析。
• 在收集了性能数据后，点击Findings标签以获得所有结果的交互总结。
  　　6. 同时在多个表上收集统计数据
  　　　　　　　　　　在之前的Oracle数据库版本中，当你执行一个DBMS_STATS 程序来收集表、索引、模式或者数据库级别的统计数据时，Oracle习惯于一次一个表的收集统计数据。如果表很大，那么推荐你采用并行方式。在12c R1中，你现在可以同时在多个表、分区以及子分区上收集统计数据。在你开始使用它之前，你必须对数据库进行以下设置以开启此功能：

　　sql 　　SQL> ALTER SYSTEM SET RESOURCE_MANAGER_PLAN='DEFAULT_MAIN'; 　　 　　SQL> ALTER SYSTEM SET JOB_QUEUE_PROCESSES=4; 　 　　SQL> EXEC DBMS_STATS.SET_GLOBAL_PREFS('CONCURRENT', 'ALL'); 　　 　　SQL> EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SCOTT'); 　　
　　
　　

自动存储管理(ASM)中的增强

Flex ASM

在一个典型的网格基础架构安装环境中，每个节点都运行自身的ASM实例，并将其作为运行于此节点上数据库的存储容器。但这种设置会存在相应的单点故障危险。例如，如果此节点上的ASM实例发生故障，则运行于此节点上的所有数据库和实例都会受到影响。为了避免ASM实例的单点故障，Oracle 12c提供了一个名为Flex ASM的功能。Flex ASM是一个不同的概念和架构，只有很少数量的ASM实例需要运行在集群中的一些服务器上。当某节点上的一个ASM实例发生故障，Oracle集群就会在另一个不同的节点上自动启动替代ASM实例以加强可用性。另外，这一设置还为运行在此节点上的实例提供了ASM实例负载均衡能力。Flex ASM的另一个优势就是可以在单独节点上加以配置。
当选择Flex Cluster选项作为集群安装环境的第一部分时，鉴于Flex Cluster的要求，Flex ASM配置就会被自动选择。传统集群同样也适用于Flex ASM。当你决定使用Flex ASM时，你必须保证所需的网络是可用的。你可以选择Flex ASM存储选项作为集群安装环境的一部分，或是使用ASMCA在一个标准集群环境下启用Flex ASM。
以下命令显示了当前的ASM模式：

或是连接到ASM实例并查询INSTANCE_TYPE参数。如果输出值为ASMPROX，那么，就说明Flex ASM已经配置好了。

ASM存储限制放宽

ASM存储硬性限额在最大ASM 磁盘群组和磁盘大小上已经大幅提升。在 12c R1中，ASM支持511个ASM磁盘群组，而在11g R2中只支持63个。同样，相比起在11g R2中20 PB的磁盘大小，现在已经将这一数字提高到32 PB。

对ASM均衡操作的优化

12c 中新的EXPLAIN WORK FOR 语句用于衡量一个给定ASM均衡操作所需的工作量，并在V$ASM_ESTIMATE动态视图中输入结果。使用此动态视图，你可以调整POWER LIMIT 语句对重新平衡操作工作进行改善。例如，如果你想衡量添加一个新ASM磁盘所需的工作量，在实际执行手动均衡操作之前，你可以使用以下命令：

你可以根据从动态视图中获取的输出来调整POWER的限制以改善均衡操作。

ASM 磁盘清理

在一个ASM磁盘群组中，新的ASM磁盘清理操作分为正常或高冗余两个级别，它可以检验ASM磁盘群组中所有磁盘的逻辑数据破坏，并且可以自动对逻辑破坏进行修复，如果检测到有逻辑数据破坏，就会使用ASM镜像磁盘。磁盘清理可以在磁盘群组，特定磁盘或是某个文件上执行，这样其影响可降到最小程度。以下演示了磁盘清理场景：

ASM的活动会话历史(ASH)

V$ACTIVE_SESSION_HISOTRY 动态视图现在还可以提供ASM实例的活动会话抽样。然而，诊断包的使用是受到许可限制的。

网格(Grid)基础架构的增强

Flex 集群

Oracle 12c 在集群安装时支持两类配置：传统标准集群和Flex集群。在一个传统标准集群中，所有集群中的节点都彼此紧密地整合在一起，并通过私有网络进行互动，而且可以直接访问存储。另一方面，Flex集群在Hub和Leaf节点结构间引入了两类节点。分配在Hub中的节点类似于传统标准集群，它们通过私有网络彼此互连在一起并对存储可以进行直接读写访问。而Leaf节点不同于Hub节点，它们不需要直接访问底层存储;相反的是，它们通过Hub节点对存储和数据进行访问。
你可以配置多达64个Hub节点，而Leaf节点则可以更多。在Oracle Flex集群中，无需配置Leaf节点就可以拥有Hub节点，而如果没有Hub节点的话，Leaf节点是不会存在的。对于一个单独Hub节点，你可以配置多个Leaf节点。在Oracle Flex集群中，只有Hub节点会直接访问OCR和Voting磁盘。当你规划大规模的集群环境时，这将是一个非常不错的功能。这一系列设置会大大降低互连拥堵，并为传统标准集群提供空间以扩大集群。
部署Flex 集群的两种途径：
\1. 在配置一个全新集群的时候部署
\2. 升级一个标准集群模式到Flex集群
如果你正在配置一个全新的集群，你需要在步骤3中选择集群配置的类型，选择配置一个Flex集群选项，然后你需要在步骤6中对Hub和Leaf节点进行分类。对于每个节点，选择相应角色是Hub或是Leaf，而虚拟主机名也是可选的。
将一个标准集群模式转换为Flex 集群模式需要以下步骤：
\1. 用以下命令获取集群的当前状态：
$ ./crsctl get cluster mode status
\2. 以root用户执行以下命令：
$ ./crsctl set cluster mode flex $ ./crsctl stop crs $ ./crsctl start crs –wait
\3. 根据设计改变节点角色：
$ ./crsctl get node role config $ ./crsctl set node role hub|leaf $ ./crsctl stop crs $ ./crsctl start crs -wait
注意：

• 你无法从Flex恢复回标准集群模式
• 改变集群节点模式需要集群栈停止
• 确保以一个固定的VIP配置GNS
  

  ASM磁盘群组中的OCR备份

  对于12c，OCR现在可以在ASM磁盘群组中得以备份。这简化了通过所有节点对OCR备份文件的访问。为了防止OCR的恢复，你不必担心OCR最新的备份是在哪个节点上。可以从任何节点轻易识别存储在ASM中的最新备份并能很容易地执行恢复。
  以下演示了如何将ASM磁盘群组设置为OCR备份位置：

支持IPv6协议

对于12c，Oracle是支持IPv6网络协议配置的。你现在可以在IPv4或IPv6上配置共有或私有网络接口，尽管如此，你需要确保在所有集群中的节点上使用相同的IP协议。

3. RAC数据库的增强

What-if命令评估
通过srvctl使用新的What-if命令评估选项，现在可以确定运行此命令所造成的影响。这一新添加到srvctl的命令，可以在没有实际执行或是不对当前系统做任何改变的情况下模拟此命令。这在想要对一个已存在的系统进行更改却对结果不确定的时候特别有用。这样，此命令就会提供进行变更的效果。而–eval 选项也可以通过crsctl 命令来使用。
例如，如果你想要知道停止一个特定数据库会发生什么，那么你就可以使用以下示例：

srvctl的改进

对于srvctl命令还有一些新增功能。以下演示了如何用这些新增功能停止或启动集群上的数据库或实例资源。

截断表CASCADE

在之前的版本中，在子表引用一个主表以及子表存在记录的情况下，是不提供截断此主表操作的。而在12c中的带有CASCADE操作的TRUNCATE TABLE可以截断主表中的记录，并自动对子表进行递归截断，并作为DELETE ON CASCADE服从外键引用。由于这是应用到所有子表的，所以对递归层级的数量是没有CAP的，可以是孙子表或是重孙子表等等。
这一增强摈弃了要在截断一个主表之前先截断所有子表记录的前提。新的CASCADE语句同样也可以应用到表分区和子表分区等。
SQL> TRUNCATE TABLE CASCADE; SQL> TRUNCATE TABLE PARTITION CASCADE;
如果对于子表的外键没有定义ON DELETE CASCADE 选项，便会抛出一个ORA-14705错误。
对Top-N查询结果限制记录
在之前的版本中有多种间接手段来对顶部或底部记录获取Top-N查询结果。而在12c中，通过新的FETCH FIRST|NEXT|PERCENT语句简化了这一过程并使其变得更为直接。为了从EMP表检索排名前10的工资记录，可以用以下新的SQL语句：

以下示例获取排名前N的所有相似的记录。例如，如果第十行的工资值是5000，并且还有其他员工的工资符合排名前N的标准，那么它们也同样会由WITH TIES语句获取。

以下示例限制从EMP表中获取排名前10%的记录：

以下示例忽略前5条记录并会显示表的下5条记录：

所有这些限制同样可以很好的应用于PL/SQL块。

对SQLPlus的各种增强

SQL*Plus的隐式结果

12c中，在没有实际绑定某个RefCursor的情况下，SQL*Plus从一个PL/SQL块的一个隐式游标返回结果。这一新的dbms_sql.return_result过程将会对PL/SQL 块中由SELECT 语句查询所指定的结果加以返回并进行格式化。以下代码对此用法进行了描述：

当此过程得以执行，会在SQL*Plus上返回格式化的记录。

显示不可见字段

当字段定义为不可见时，在描述表结构时它们将不会显示。然而，你可以通过在SQL*Plus提示符下进行以下设置来显示不可见字段的相关信息：

以上设置仅对DESCRIBE 命令有效。目前它还无法对不可见字段上的SELECT 语句结果产生效果。

会话级序列

在12c中现在可以创建新的会话级数据库序列来支持会话级序列值。这些序列的类型在有会话级的全局临时表上最为适用。
会话级序列会产生一个独特范围的值，这些值是限制在此会话内的，而非超越此会话。一旦会话终止，会话序列的状态也会消失。以下示例解释了创建一个会话级序列：

对于会话级序列，CACHE, NOCACHE, ORDER 或 NOORDER 语句会予以忽略。

WITH语句的改善

在12c中，你可以用SQL更快的运行PL/SQL函数或过程，这些是由SQL语句的WITH语句加以定义和声明的。以下示例演示了如何在WITH语句中定义和声明一个过程或函数：
WITH PROCEDURE|FUNCTION test1 (…) BEGIN END; SELECT FROM table_name;
尽管你不能在PL/SQL单元直接使用WITH语句，但其可以在PL/SQL单元中通过一个动态SQL加以引用。

扩展数据类型

在12c中，与早期版本相比，诸如VARCHAR2, NAVARCHAR2以及 RAW这些数据类型的大小会从4K以及2K字节扩展至32K字节。只要可能，扩展字符的大小会降低对LOB数据类型的使用。为了启用扩展字符大小，你必须将MAX_STRING_SIZE的初始数据库参数设置为EXTENDED。
要使用扩展字符类型需要执行以下过程：
\1. 关闭数据库
\2. 以升级模式重启数据库
\3. 更改参数: ALTER SYSTEM SET MAX_STRING_SIZE=EXTENDED;
\4. 执行 utl32k.sql as sysdba : SQL> @?/rdbms/admin/utl32k.sql
\5. 关闭数据库
\6. 以读写模式重启数据库
对比LOB数据类型，在ASSM表空间管理中，扩展数据类型的字段以SecureFiles LOB加以存储，而在非ASSM表空间管理中，它们则是以BasciFiles LOB进行存储的。
注意：一旦更改，你就不能再将设置改回STANDARD。

12.2 新特性：RMAN 自动恢复到 REDO 终点的步骤简化

在 Oracle 12.2 之前，当我们需要恢复数据库到某个时间点的时候，需要确定 SCN，或者日志序列号，或者一个时间点，以便尽可能多的应用归档日志，进而尽可能多的恢复数据。

从12.2开始，RMAN 新增参数：

RECOVER DATABASE UNTIL AVALIABLE REDO

RMAN 将会根据控制文件信息和归档日志/在线日志/归档日志备份集的物理可用性，将数据库恢复到最后一个可用的归档日志。所以在进行恢复的时候，可以不需要指定 SCN，或者时间,或者日志序列号。需要注意的是，数据文件仍然需要在一致的情况下，数据库才能打开。

语法如下:

RMAN> RECOVER DATABASE UNTIL AVALIABLE REDO;

限制：

1. 不能针对恢复数据文件或者表空间使用这个命令。
2. 不能针对恢复 PDB 使用这个命令。
3. 只能针对全库恢复使用这个命令。

下面进行试验来测试该命令。

备份

也就是说基于该备份进行恢复，至少需要恢复到序号为5的归档，数据库才能处于一致性的状态，才能进行 OPEN 操作。

模拟归档丢失

由于只是在操作系统层面删除了归档日志，没有进行 crosscheck 操作，控制文件里仍然记录有这些归档日志还没有被删除。

RESTORE 数据库

RECOVER 数据库

通过日志输出可以看到，rman 自动读取了所有可用于前滚数据库的归档，对于删除的归档，如果在线日志还没有被覆盖，也会通过读取在线日志来替换删除的归档，这里序号为8的归档日志已经被操作系统删除了，并且在线日志也已经被覆盖了，所以 rman 自动前滚到该位置之后，停止继续前滚。

注明：实验环境为 rhce 7.4 12.2.0.1

参考：12.2 NEW FEATURE : -RECOVER DATABASE UNTIL AVAILABLE REDO (文档 ID 2300465.1)

Oracle 12.2 新特性：在线的修改数据表为分区表

众所周知，分区技术是Oracle应用最为广泛的一个选件，并且历史悠久，然而在过去的版本中，如果我们要将一个现有的数据表转换为分区表，则是相当复杂的一个过程，而在 12.2 版本中，这个过程被简化为一个在线的操作。

请看以下Demo SQL语句：

CREATE TABLE sales

( order_num NUMBER,

order_name VARCHAR2(128),

region VARCHAR2(10));

insert into sales (1,'YHEM','BEIJING');

insert into sales (2,'ENMOTECH','SHENZHEN');

insert into sales (3,'YHEM','SHANGHAI');

ALTER TABLE sales MODIFY

PARTITION BY LIST (region)

(partition p1 values ('BEIJING'),

partition p2 values ('SHENZHEN'),

partition p3 values ('SHANGHAI'),

partition p4 values (DEFAULT)) ONLINE;

在Modify修改表结构时，增加了ONLINE语句，可以直接将原有的数据表修改为分区结构。不会影响现有业务的运行。

在Live SQL站点运行一下测试语句（ https://livesql.oracle.com ），可以看到顺利的完成了分区定义。事实上这个功能已经非常健壮：

那么Oracle在后台是如何完成这个DDL的重定义过程呢？

如果通过10046进行跟踪，可以发现这是一个非常复杂的内部递归过程，Oracle会建立一个日志表记录变更，然后通过Bulk Move批量迁移原有数据，最后增量应用变化数据，所以当然，你会发现这期间需要两倍的存储空间：

10046 的跟踪日志，揭示了这一过程，以下是跟踪日志中一个映射表的建立（感兴趣的同学可以从10046中找到很多原理性知识）：

一个简单的操作，后台的递归执行高达2500次，大家可以想象Oracle这艘航空母舰有多么的庞大：

参考

http://www.searchdatabase.com.cn/showcontent_74721.htm
http://www.searchdatabase.com.cn/showcontent_74959.htm
http://www.searchdatabase.com.cn/showcontent_75748.htm
http://www.searchdatabase.com.cn/showcontent_75994.htm