Oracle 18c 已至, 目前已经可以从 Oracle Edelivery 网站下载 该网站的网址是: https://edelivery.oracle.com
搜索 Oracle Database 可以看到 18 版的软件介质, 目前的介质声明是 Exadata Only, 但是应可以在非 Exadata Linux 系统平台安装, OEL 是 Oracle 推荐的最佳支持平台 :
目前介质包含主要包含三个文件, 客户端软件 和 Grid 安装包, 首发 Linux 系统支持版本 (百度云分享了一份软件, 关注公众号回复: 18cNF 可以在目录中找到):
关于 Oracle 18c 的新特性, 我整理一个之前发布过的文章列表, 供大家参考:
Oracle Database 18c 的 10 大新特性一览
技术前沿: Oracle 18c 最新特性概览
开工大吉: Oracle 18c 已经发布及新特性介绍
此前我们就曾经注意到一个有意思的特性: 可扩展序列 - Scalable Sequence
通过在 CREATE SEQUENCE 或 ALTER SEQUENCE 语句中指定 SCALE 子句, 可以使序列获得健壮的扩展性
那么这个特性是如何实现的? 究竟又是为了解决什么问题呢?
我们回顾一下, Oracle RWP 团队的领袖 Andrew Holdsworth 的一个精彩分享: Real World Performance 经典性能优化案例 - 索引竞争
在这个主题中, Andrew 提到了在优化时候遇到的种种索引竞争情况:
我们一直在寻找一种方法, 希望能够从应用层就把竞争的可能性消除既能解决单节点的竞争问题, 又能在扩展中不带来新的问题, 这就需要保证缓存的相关性, 让数据所在的实例恰好是会被访问的实例
那么最佳的解决方案会是怎样的呢?
跟所有 RWP 的解决方案一样, 我们并不推荐通过各种配置或者参数的调整来解决问题, 我们会扩展问题的领域, 希望把问题上升到应用层去解决, 对于案例中的索引竞争的问题, 如果我们能控制如何生成代理主键, 我们就能把这些特征放入到生成的主键中
这样不仅能够保证得到较好的缓存相关度, 从而使 RAC 可扩展, 而且可以把主键分散开, 这样在单实例上也不会出现竞争
所以关于索引竞争, 我们面临两个挑战,
一是实例间的竞争或者说扩展性问题
二是单节点间的竞争
因此我们考虑生成一个智能主键, 智能主键常常需要找到应用代码中的某一行, 弄清楚我们要如何生成这一串字节才能确保不会出现竞争
首先要考虑的是可以使用实例号作为主键号的开头, 这样插入数据的时候就会保存在树节点的一边, 也正是这些数据应该被保存到的实例上, 这样就可以建立与插入操作相关的缓存相关性
当我们在访问的时候能够准确定位数据所在的实例之后, 第二个要考虑的问题就是, 访问同一个实例上数据的时候不会竞争同一块内存,
我们考虑, 如果说智能主键的中间部分如果是对进程号某种方式取余, 这样就把对索引的维护分散到同一实例的多个内存块上去, 而智能主键的最后一部分是 sequence 的本身, 这样可以保证引用和完整性, 确保每一行都是唯一的
因此最终智能主键的组成是: 实例 ID - 进程号取余 - 序列号
接下来我们通过实验来看一下, 在使用智能主键的情况下, 发现系统的响应时间减少, 其他等待事件消失, CPU 利用率提高, 并且只有 CPU 在占用时间跟最初系统没有产生竞争的情况下的性能一样
通过自定义智能主键, 很好地避免了传统的索引方案的不足, 在不影响性能的情况下有效实现了业务的需求
我们来看一下 18c 中的可扩展序列的定义:
通过以下语法定义 scalable sequence:
- CREATE | ALTER SEQUENCE sequence_name
- ...
- SCALE [EXTEND | NOEXTEND] | NOSCALE
- ...
当 SCALE 语句被指定时, 一个 6 位数的数字被指定作为序列的前缀, 末尾是正常的序列数字, 两者联合成为新的序列:
- scalable sequence number =
- 6 digit scalable sequence offset number
- ||
- normal sequence number
在这里, 6 位数字前缀是如何生成的呢? 正是由 实例号 和 会话号 生成的:
- 6 digit scalable sequence offset number = 3 digit instance offset number || 3 digit session offset number.
- The 3 digit instance offset number is generated as [
- (instance id % 100) + 100
- ]. The 3 digit session offset number is generated as [session id % 1000].
所以可以看到, 这个设计和 之前 Andrew 的描述完全相同, 这正是来自实践的指导最终推动了 Oracle 数据库产品的进步
测试验证一下吧:
- drop sequence enmo_seq;
- CREATE SEQUENCE enmo_seq INCREMENT BY 1 MAXVALUE 1000000 SCALE;
- SELECT enmo_seq.nextval FROM dual;
由于有 6 位前缀, 也就是说序列最小要具备 7 位的长度, 否则将不能使用:
而即使是 7 位, 对于单一进程连接, 也将仅有 9 个可用值:
ORA-64603: NEXTVAL cannot be instantiated for ENMO_SEQ. Widen the sequence by 1 digits or alter sequence with SCALE EXTEND.
现在通过这种序列方式, 能够真正将来自不同实例的数据分散开来, 索引竞争大大降低, 从而提升了性能, 使得序列变得可扩展
来源: https://yq.aliyun.com/articles/487609