本期为我们带来分享的嘉宾是 ACOUG 核心专家，Oracle ACE 总监 杨廷琨先生，本次嘉年华上，杨老师为我们带来题为：Oracle 19c 和 20c 的新特性解密主题分享。下面，让我们跟随杨老师，一同来学习关于Oracle 19c和20c新特性吧~
在这次数据技术嘉年华大会上，我和大家分享的是Oracle最新版本的一些重要的新特性。
根据我们白求恩自动巡检平台的数据分析结果，虽然Oracle对于11g的支持已经进入扩展维护期，但是目前业内使用最多的版本仍然是11.2，大概占到了6成左右。而12c的版本的使用超过10g版本，总体接近3成。这说明对于很多客户，已经逐渐把数据库升级到了12.2及以后的版本上。12c正在逐渐变为主流的版本，因此希望把新版本中一些重要的新特性分享给大家，以便于后续在数据库版本选择的时候可以对新的功能做到心中有数。
12.2推出了很长时间了，大部分DBA对于12.2的特性并不陌生，因此这次主要分享18c、19c和20c的新特性。
在Oracle中，一个频繁插入的系统在正常时刻的运行会非常稳定和高效，但是很可能突然会出现大量的竞争和等待，一般来说产生这个性能问题原因是单调递增索引在索引分裂的时候引发的竞争和等待。绝大部分主键依赖于SEQUENCE产生的NEXT_VALUE，而SEQUENCE产生的值一般都是单调递增的，因此序列产生的新值总是最大的，而索引本身又是一个排序的结构，当多个会话同时进行插入时，这些会话就会争抢索引叶子块的最右端，也就是最大值存放的地方。当索引需要进行分裂来扩展空间时，就会导致所有试图插入的会话被锁定，从而引发一系列并发等待，造成严重的性能问题。
在18c中，一个重要的特性就是引入了Scalable Sequence。Oracle改造了序列的构成，其后半部分就是一个标准的序列，而前半部分分别把数据库的实例ID和当前会话的SESSION ID加到了序列中，因此在获取序列的NEXT_VALUE时，得到的不再是递增的数值，而且变化差异非常大的不连续的数值，从根本上改变了获取序列的数据连续性问题，解决了由此引发的索引热点块争抢的问题。
18c中使用外部表不再需要通过DDL先创建后使用的方式，可以将外部表的描述性部分直接加入到访问的SQL语句中，从而简化了外部表的使用和维护。尤其是针对一次性加载的外部表，INLINE外部表功能是非常方便的。
除了增加了外部表使用的便利性，在性能方面，18c也对外部表进行了优化。可以在数据库中为外部表创建IN MEMORY缓存，从而极大的加快外部表数据的运算和分析过程，对于多次访问或进行复杂分析运算的外部表，启用IN MEMORY外部表功能，可能会得到成百倍的性能提升。
Oracle对于PDB的复制同步功能得到进一步提升，从12.2引入了PDB的热克隆，同时支持了克隆库可以阶段性的从源库进行增量的数据同步，而在18c中，可以对源库和克隆库之间进行SWITCHOVER切换，转换二者的身份，使得源库变成可同步刷新的只读克隆环境，而原本的只读克隆库变为可读写的主库。这种PDB级别的SWITCHOVER对于计划停机场景和非计划故障停机场景都是有价值的。
18c中另外一个很重要的特性就是Oracle提供了对于用户使用权限的捕获，可以通过开启一个业务周期的权限捕获，然后获取到这个用户在这个业务周期内，使用了哪些权限，访问了哪些对象，对于分析当前用户是否权限过大，非常有帮助。而在之前的版本中，这个任务非常难以实现。
上面是18c中带来的一些重要的特性，下面看看19c中Oracle又引入了哪些重大的功能和特性：
Oracle第一次提出了自制数据库的概念，而要解决数据库自治，自动优化是不可缺少的，而19c引入的一个重要的特性就是索引自动创建功能。当设置了自动索引创建功能后，Oracle后台会不断的评估数据库中运行的SQL语句，分析这个语句是否可以通过创建索引来提升性能，并尝试创建不可见索引，如果优化器评估确认新创建的索引确实可以提高查询性能，会将这个索引设置为可见，使得前台业务SQL语句可以使用这个索引。
针对物联网应用场景，面临海量数据的频繁插入，Oracle提供了专门的优化手段：MEMOPTIMIZE FOR WRITE。开启表的这个功能后，前台业务插入直接写入LARGE POOL中的内存空间，后台进程异步的将内存中的数据写入到数据库文件中，其本质是以牺牲事务性为代价来换取极速的插入性能，在2 Socket服务器上可以实现每秒插入2500万条记录。
在19c中Oracle对于在线维护操作进一步增加，进一步降低了DDL对于正在运行系统的影响。在进行游标过期时，将会采用更加智能的策略，将DML和SELECT按照不同的策略进行处理，采用滚动游标过期方式，避免DDL使得所有相关游标同时过期，从而导致解析风暴引发的并发锁定问题。
在数据库中有一类SQL比较难以处理，被称为RUNAWAY语句，这类语句有一个特点，执行次数并不频繁，但是会消耗大量的资源，一旦被执行就可能造成系统的性能问题。而且下次再运行的时候，可能在SQL文本上有少量的变化，导致难以通过SQL_ID的方式进行定位和处理。
Oracle针对这种SQL提供了执行计划隔离的能力，评估一个SQL是否会被隔离不是根据SQL文本，而是根据SQL的执行计划，一旦SQL的消耗超过了资源管理器中的阈值设置，该SQL语句对应的执行计划就被隔离起来，后续所有采用同样执行计划的SQL都不会再被执行。从而有效地避免了RUNAWAY语句对于性能的影响。
19c的ADG对DML的自动重定向功能也是比较引人关注的，在配置了该功能后，在备库上运行的DML会被Oracle通过内部DBLINK传输到主库中运行，运行成功后产生的日志发送到备库并成功应用后，备库上的DML才会成功返回，并可以查看到DML执行后的结果。
Oracle实现这个功能的同时并没有牺牲数据库的事务性，也就是说在备库的DML未提交之前，备库上的修改只有当前会话可见，其他会话看不到修改后的结果，当备库的DML修改提交之后，其他会话才可以看到修改后的结果。这个功能适用于读写分离应用中存在很少量修改的情况，这时备库不会报错，而是透明的将修改应用到主库中。
在19c中，对于Sharding的功能有了进一步的增强，其中比较重要的一点改进是目前Sharding支持多个表家族，也就是说一个Shard中可以存储超过一套的主子表，而在以前的版本中，Oracle只允许存储一套主子表。另外一个改进是在Sharding的目录库中，可以通过运行ALTER SYSTEM语句将参数设置发送到所有的Shard库中。
Oracle在19c中对于外部数据的混合存储功能进一步加强，允许分区表中部分分区为数据库内的在线数据，部分分区由存储在外部文件系统的外部数据构成。这使得数据库中全生命周期管理功能得到进一步完善。对于很少访问的历史数据，不需要通过额外的历史库或历史表去访问，而是通过原表不需要修改程序就可以直接访问到离线的只读数据。Oracle会对不同类型的分区进行分别处理，当一个SQL同时访问内部分区和外部分区时，Oracle将执行计划拆分为两个UNION ALL分支，采用不同的执行计划去获取数据。
很多时候一些SQL的执行计划性能低下，实际上是统计信息不准确导致的，Oracle的19c开始将部分关键统计信息实时化，从根本上避免了由于统计信息不准确导致执行计划低效的问题。由于统计的实时化不能以牺牲DML操作的性能为代价，因此目前实时计算的统计信息仅包括最小值，最大值和行数。因此实时统计信息并不能完全代替统计信息收集，后台的自动统计信息收集仍然需要执行。
Oracle的In-Memory功能不仅仅针对结构化数据，对于空间数据库和全文数据库，同样可以采用In-Memory来进行加速，从而获得几倍或更高的性能提升。
在12.2和18c中，Oracle实现了ADG切换之后的连接会话保持和Buffer Cache的保持功能，在20c中，Oracle可以实现ADG中Result Cache缓存的保持功能，普通用户将很难察觉到Data Guard主备切换带来的影响。