（19C专题）专题解读：Oracle Database 19c特性

Oracle 19c 相当于 12.2.0.3 版本，是 Oracle 12c 的最终版，所以这一版本中，不会有太多的新特性，更重要的是稳定性的增强，使得用户能够更多的迁移到12c这个主流版本中。虽说如此，但是Oracle数据库的进步总是会让人感到惊喜，在此遴选了 10 个 19c 的新特性，送给坚持在技术道路上的朋友们。

原文：Oracle Database 19c 的10大新特性一览

“ADG的自动DML转发”是Oracle 19c的一个重要增强。

这个新特性的功能是：将偶然发送到ADG上的DML操作，自动转发到主库执行，然后通过主库日志传递到备库实时应用，在保证了ACID的前提下，大大增强了备库的实用性，这被称为 DML Redirection 。

其实这个特性在 Oracle 18c 中就已经提供，所以我们不必等到 19c 就能够体验到这个特性。

在两个版本中，唯一的差别是：

在 18c 中，这个特性是通过隐含参数 _enable_proxy_adg_redirect 的调整来启用这个特性，这表示此特性是趋向内部的；

在 19c 中，显式参数 ADG_REDIRECT_DML 参数控制这个特性的开关，说明这个特性变成外部和成熟的；

这个新特性的便利性，参见文章：ADG的自动DML重定向增强读写分离

官方文档可以公开下载，本文整理了一些重要文档，包括概念手册、新特性手册、管理员手册等，关注本公众号（OraNews），回复关键字：19CDOC获得下载链接。

原文：Oracle 19c 新特性及官方文档下载

在Oracle 19c中，函数 ANY_VALUE 被引入进来，这个函数的作用是基于ORDER BY定义返回每个组中的任何值，通过这一个函数，可以消除将每个列都指定为GROUP BY子句的一部分的必要性。

原文：ANY_VALUE函数和LISTAGG的增强

在Oracle的发布网站，https://edelivery.oracle.com

整个数据库安装包高达 2.8 GB 的体量，大家感兴趣的抓紧时间下载吧。

此前我们发布的链接：

Oracle 官方文档下载

2019年了数据库也已经到了19C，如下是主要的安装步骤

原文：Oracle 19C单实例数据库安装步骤详解

Automatic indexing是Oracle Database 19c开始新增加的特性，从字面上很容易理解，就是依据应用负载的变化自动/动态地进行索引的管理任务，比如创建(create index)、重构(rebuild index)和删除(drop index)，从而提高数据库性能，这个特性也是Oracle自治数据库云服务自我优化的一个基础。

索引从一开始就是数据库性能的一个基本特性，尽管在并行、分区、压缩、物化视图以及内存列等其他性能特性方面有了很大的进步，但索引仍然是OLTP甚至OLAP中都离不开的关键特性。

原文：自动化索引 Automatic indexing 实践

从Oracle Database 19c开始，Oracle数据库支持Hybridpartitioned tables，也就是混合分区表，进一步扩展了Oracle分区技术。这里的混合指的是数据的分布，一些分区可以位于数据库中，另一些可以是位于数据库外部的文件（比如操作系统文件或Hadoop Distributed File System (HDFS) 文件）。这个特性的出现，其实一点也不奇怪，因为从12.2开始就支持了外部表分区、只读分区，在19c中只是将内部分区（internal partitions）与Oracle外部分区（external partitions）特性结合起来，形成一个更通用的分区，称为混合分区表。

原文：混合分区表Hybrid partitioned tables强体验

从 Database 18c 开始，可以创建 Schema Only Account（可以拥有对象、权限/角色，但不允许直接连接的 Schema），不过可以通过 single session proxy 的方式连接访问。

这种类型的 account 设计既是为了满足 Oracle-provided schemas 同时也适用于客户应用设计的需要，创建用户的时候不需要指定密码或授权方式。除非使用 ALTER USER 语句分配身份验证方法，否则无法对 Schema Only Account 进行身份验证。DBA_USERS_WITH_DEFPWD数据字典视图中不再包含Schema Only Account 信息。

原文：Oracle 19c 新特性：Schema Only Account详解

Oracle Hints 是 SQL语句中的注释机制，用来传递指令给 Oracle 数据库优化器，告诉优化器按照我们的告诉它的方式 选择执行计划，除非存在某种条件阻止优化器这样做，典型的比如设置了 OPTIMIZER_IGNORE_HINTS、OPTIMIZER_IGNORE_PARALLEL_HINTS 参数或发生了查询转换甚至 Hint 冲突，那么可能会导致 Hint 失效。

原文：Hint Usage Reports详解

众所周知，Oracle在一个机房内实现真正双活的唯一方式是RAC，而如果这个机房出现整个机房的故障（比如机房断电，油机忘了加油了，或者机房地震了，机房着火了，机房进水了等等），那么，双活也将不复存在。

为了解决这个问题，Oracle将RAC的范围进行了扩大，原意是将RAC的节点们分布在物理位置不同的机房，这样一旦某个机房整个下线，其他机房的节点可以承担起原来RAC该承担的责任。愿景很美好，原理也说得通。

但是，实现这个目的，有两个关键的点，其中最需要考量的是多个机房之间的链路质量（存储链路和大二层问题），这个超出本文讨论的范围。其次是，第三地表决。双活里面，除了两个业务机房，还需要有第三个仲裁机构不属于这两个机房，来维持在极端情况下的正确选举存活节点（站点）。

在双活项目的实施里，大体有两种方案，早前为此写过一个片子，现在找不到了。大体是，一种是存储来做，一种是主机层来做。存储层来做的话，方案有很多，如EMC的vplex metro，HDS的GAD等等。这些方案对DBA来说是非常友好的，因为双活和第三地表决不由DBA来规划和控制。第二种，主机层做的双活（基于ASM），这部分除了链路DBA不能主导之外，剩下的，如faillure group，3rd voting都是需要DBA来介入的。

本文只取其中一个部分，就是3rd voting，来阐述在19C extended rac下，第三地表决的管理。

原文：Voting Disk管理