作者：enmotech 发布在 eygle.com

在2017年的DB-Engine的年度数据库榜单上，PostgreSQL以其超过其他341个受监控数据库管理系统的受欢迎程度居于榜首，被评为年度DBMS。其总体排名也超过MongoDB，在其流行程度上排名第四。

PostgreSQL是DB领域的一匹黑马，之前一直默默活在MySQL的阴影之下，今年随着 10.0版本的发布，Declarative Partitioning的引入，改进的查询并行性，逻辑复制和同步复制的Quorum Commit ，PostgreSQL 10 的影响力在不断的增强。

今天我们有幸邀请到了PostgreSQL的专家朱贤文老师，为我们分享PostgreSQL的核心技术、发展现状及未来方向。

遇见未来

DB舞台谁是王者之PostgreSQL专访

我们有一套自研的专门用于数据库的高性能私有云系统，支持PostgreSQL和Oracle数据库高效可靠地运行。

PostgreSQL 10版本中，新的特性比较多，下面只列出部分，详细的部分可以参考官方Wiki：https://wiki.postgresql.org/wiki/New_in_postgres_10

• 大数据处理：原生分区，并行执行，FDW下发/push-down，更快的查询支持；

• 复制和很横向扩张：逻辑复制，同步复制实现Quorum Commit-类Raft的部分功能,临时复制slots支持，连接层的failover和routing，加强的物理复制；

• 系统管理：pg_receivewal支持压缩，pg_stat_activity有了专门的后台处理进程等；

• SQL功能：Identity Columns，Crash Safe,Replicable HashIndexes,Transition Tables for Triggers；

• XML和JSON：支持XMLTable,JSON和JSONB的全文搜索

根据我知道的信息，市场对PostgreSQL数据库的需求一直都是高速增长的，增长的量主要集中在两个方面：

• 一方面是新建的对可靠性、业务连续性要求高的OLTP系统，越来越多的用户将PostgreSQL作为优先选择的数据库；

• 另一方面是数据量小于50T的小型OLAP业务系统，很多用于会优先选择PostgreSQL作为分析引擎。

这种需求最近一两年表现尤为明显。

• 第一种跟其它数据库的高可用架构基本上一样，就是采用共享存储模式，数据库存放在共享存储上；一台主机，一台备机；正常情况下，主机连接存储启动数据库对外提供服务；当主机故障，备机接管存储，并且启动数据库，继续对外提供服务；这种架构的好处就是数据是专门的存储提供保护，不用担心丢失，切换服务的时间需要集群管理软件决定，一般来说基本中就可以完成切换；

• 第二种是基于流复制的高可用架构，这里面有几个发展的阶段，

• 第三种是逻辑复制。逻辑复制的好处比较多，比如可以跨平台跨操作系统，可以控制需要复制的表而不是整个库进行部分数据的复制，比如用于OLAP分析系统的数据同步；也可以用于做不停机的业务系统升级。

另外说一点就是PostgreSQL可用的高可用方案比较丰富，有开源的方案比如pgpool，也有一些商业的解决方案，比如我们公司的ECOX系统。客户在设计和选用高可用方案的时候，严谨的生产系统最好要购买专业的服务。我们是国内比较好的服务团队并且能提供完整的解决方案跟相关技术。

PostgreSQL不像MySQL数据库那样有很多存储引擎。PostgreSQL只有一种存储引擎，对事务处理非常严谨严肃，主要用于高性能的OLTP业务场景。同时也可以用于小型的OLAP分析型业务场景。

PostgreSQL数据库，不像我们常用的Oracle数据库，如果参数设置得当，应用设计也比较好，这种情况下其实不需要太多的维护；

对于PostgreSQL来说，反而是需要将精力放在存储子系统的可靠性，备份等方面。

存储子系统的可靠性需要仔细地设计，因为它不仅关乎系统性能，也关乎数据本身存放的可靠性。如果是严谨的商业应用，建议优先选用可靠的存储系统和文件系统；我们作为有丰富实施经验的专业厂商，我们会推荐用户优先选用ZFS，特别是原生的ZFS，这个领域我们有完整的方案。

相对于其它数据库而言，PostgreSQL的优势是非常明显的，比如：

• 有庞大的潜在的开发群体、运维群体和完整的生态；因为Oracle的生态系统非常完善和成熟，熟悉Oracle技能的人迁移到PostgreSQL数据库上的学习曲线非常平滑，成本非常低。根据我自己的经验，基本上2周时间可成。

• 有大量的银行、电信、保险、政府等行业的关键业务应用案例和知名客户。

• 有丰富的开发接口和开发语言支持，丰富的数据类型，支持传统的关系型数据和非关系型数据。对GIS非常好，对JSON,JSONB,XMLTable支持非常好。

• 非常丰富的fdw扩展，几乎可以支持所有的外部数据源和数据库。

• 非常先进的企业级特性，比如复制，分区，在线热备份，非常丰富的索引、函数等。

• 非常优秀的跨平台、跨操作系统支持。支持几乎所有的硬件平台和操作系统。大到mainframe，小到嵌入式系统。

• 高品质的代码，优雅的设计，非常长时间的、持续活跃的开发历史。

• 每个发行版本都能获得为期5年的产品支持。

当然也有需要完善的地方，比如：

• 宣传不到位，现在还有很多用户不清楚、甚至不知道PostgreSQL是一个生么样的数据库。（这一点会导致用户选用技术线路失误，从而导致后面的应用系统开发和维护成本很高。）所以应该加强PostgreSQL数据库的培训和宣传。

• 国内从事PostgreSQL的服务商比较少，高质量的专业服务商更少。

• 技术上目前还不支持块级别的增量备份和恢复（这个功能已经在线路图上，很快会有）

OceanBase是一个非常有特点的数据库，全新的设计，也在高性能，高可靠性方面有比较好的表现，17年双11表现的每秒处理26万多笔交易的威力（性能）大家也见识过了。

OceanBase的主从数据库

在传统的数据库主从架构中，比如（Active）DataGuard，主库对外提供全功能的读写服务，从库对外提供只读服务，主库到从库通过流复制技术使数据保持同步；

在OceanBase中，也有主和从的概念，复制也是主到从，与传统数据库不一样的是这个数据库的主、从概念是建立在分区表的分区上，每个表有多个分区，所有节点都可以有全部或者部分分区，分区有多个副本，分布在集群内的其它节点上，副本可以看作是是从，只接收主上面的日志，并且回放到内存里，一个可以读写的分区就是一个主；一个主可以有多从，确保数据有多份拷贝，主到从的日志传输通过Paxos协议完成，确保数据可以正确传输到其它节点；

整个集群对外来看，所有节点都是读写的、全功能的，比传统数据库优势明显，因为多活，负载均衡可以实现比较好，可以用低廉的硬件实现高性能、高可靠的系统；

仔细观察集群内部，由很多表的不同分区及它们的副本构成非常多的主从复制，所有的日志数据复制基于Paxso协议，能够保证任何节点损坏都不会有数据丢失的危险（当然节点坏掉的个数不能大于节点总数的一半）。

OceanBase另外一个比较有意思的设计就是类似于传统数据库中的check_point的处理，传统数据库的check_point时间根据负载和SLA的一些要求，一般保持在几分钟到半个小时之间，数据库要做一次check_point，以确保数据库的数据一致性；而OceanBase数据库把传统数据库类似check_point功能的操作周期做得非常长，比如一天做一次数据整合（类似于传统数据库的check_point操作）；这样做有好处，就是对SSD这种新型电子磁盘的寿命有帮助，因为对SSD的操作都是大片大片的、整块地删除、写入，尽量避免SSD内部的写放大，这个设计的前提是基于服务器有非常大的内存配置，比如256G、甚至1T，现在的机器内存配置都比较大，很容易配置大内存的集群，那么把数据库的data buffer做到足够大，数据库所有的操作都在内存里，相当于一个准内存数据库，比操作磁盘的IO要快很多；通过这些设计，非常合理地避免了全分布式、高可靠、高性能并发和mvcc之间的矛盾。

OceanBase的设计非常聪明，它的出现的确给了我耳目一新的感觉，不管是技术上的创新，架构上的创新，技术来源，都是值得大大地给一个赞，说到技术创新、架构创新，我们的鸿鹄彩云系统就是为高性能数据库业务设计的，里面也有很多可以让人感觉耳目一新的技术创新的点，希望更多的人可以尝试试用；

当然一个新事物的出现需要一个时间完善和成长／成熟的过程，对于OceanBase来说目前也需要有完善的地方，比如技术上与现有的用的广泛的Oracle的兼容性，跨库交易等，关键行业的成功的应用案例等，让我们多给它一些时间，多给一些耐心；（当然我对OceanBase的了解也比较有限，可能有很多技术特点没有讲到，请包涵）

从数据本身来说，真实世界里生产的95%以上的数据都是关系型的，只有很少的数据是非关系型的。

所谓的NoSQL是Google在很多年提出来的处理大数据的一个技术方案，主要使用的思想就是Map/Reduce，学过数据库的人都应该了解，这项技术实际上在上个世纪60年代，在大型机上处理大量计算常用的技术思想。

Google最终推出了自己的Spanner数据库，结果是非常明显的，Google自己都不用NoSQL，而回到传统的SQL这个线路上面来，所以未来还会向SQL这个方向走。

PostgreSQL未来还是会持续、活跃地开发高品质的软件，并且根据市场需要提供满足市场的技术特性；国内的市场也会普及和成熟，用户也会接纳并且广泛地使用PostgreSQL数据库、并且从中受益。

应对海量数据的实施处理，可以选用高性能硬件，MPP架构的技术；以后也会有基于内存的MPP，甚至用GPU加速运算的数据库；但是最终还是需要看用户本身的需求和业务特点，根据这些进行有针对性的设计和实施，以满足这类需求。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业，以及每一个向未来而努力的人，听见时代最前沿的声音，见证成长！

相关文章|Related Articles

作者：enmotech 发布在 eygle.com

互联网及其延伸，正在导向我们走向一个新的时代，软件技术在新一轮革命技术中毫无疑问是核心竞争力之一。C++语言发明人Biarne Stroustrup说，人类文明运行在软件之上，也突出了软件技术的重要地位。

什么是软件定义？软件定义在企业的数据中心中的表现是什么？如何发展这项技术？今天我们有幸邀请到了VMware存储架构师Peter Ye（叶毓睿），分享他关于软件定义存储的深刻见解。

遇见未来

未来数据中心建设战略之软件定义专访

PeterYe（叶毓睿），现任VMware存储架构师,《软件定义存储:原理,实践与生态》作者，《VMware软件定义存储：原理剖析和设计指南》译者。曾任职于EMC、Compellent、DELL，对存储行业的历史发展和未来趋势有着深入的了解。Peter同时也是"乐生活与爱IT" 微信公众号的作者。

软件定义存储（SoftwareDefined Storage，简称SDS）的首次提出是在2012年8月VMworld大会上，此次大会同时提出了软件定义的数据中心（Software Defined Data Center，简称SDDC），SDS是SDDC的五大组成部分之一。

我在《软件定义存储:原理,实践与生态》一书中，曾指出：软件定义的存储（SDS）是一个不断进化的概念，在现阶段看来，是指存储资源由软件自动控制，通过抽象、池化和自动化，将标准服务器内置存储、直连存储，外置存储，或云存储等存储资源整合起来，实现应用感知，或者基于策略驱动的部署、变更和管理，最终达到存储即服务的目标。

用户在传统数据中心建设中，大多是烟囱或竖井架构，也就是每上一套业务应用，需要申请和采购包括服务器、网络和存储在内的IT基础架构硬件，这使得用户在数字化转型的时代，IT基础架构的资源无法共享，存储资源无法动态扩展，即刻交付。SDS是在虚拟化已经渗透到各行各业，云计算逐渐普及的大环境下，孕育而生的。

软件定义为云而生，通过抽象、池化、自动化等步骤，实现IAAS（基础架构即服务），帮助用户共享计算网络和存储资源池，并能实现动态扩展，即刻交付和方便地变更资源，以动态地适应某一业务在不同时间段对于资源的SLA（服务等级协议）的要求。

目前SDS包括分布式存储，分布式存储有两种部署形态，一种是计算和存储相分离的，另一种是计算和存储融合在同一个物理服务器节点上，也即超融合基础架构。分离部署的方式，在大规模存储资源池化，存放非结构化数据（如文档，图片，音视频等）的场景中，应用较为广泛。而超融合架构中，较多使用的场景包含VDI、集群管理、ROBO（远程分支办公室）、开发测试、备份与灾难恢复。除此之外，由于VMware vSAN依托于vSphere ESXi这一稳定可靠的Hypervisor，并且自身拥有故障域、双活（延伸集群）、而且支持vMotion/HA/FT等功能，使得越来越多的用户将关键应用（如Oracle RAC、SAP、SQL Server等）放在了VMware vSAN上，根据2016年的数据统计，有64%的vSAN用户，将其关键应用放在vSAN上。

在数据平面层涌现出可以采用基于标准商用硬件（如X86服务器）的分布式存储或者HCI，降低了成本；控制平面层向上提供了存储自动化（如存储策略驱动）的资源部署和变更方式，使得云计算所需的存储资源即刻交付成为可能。软件定义存储中的大类：HCI使得数据靠近计算，能让SSD的性能发挥得淋漓尽致，性能更高，延时更低。

• 第一步是抽象，也即解耦，因为如果硬件被锁定，存储资源无法被灵活调用；

• 第二步是池化，也即虚拟化，这样才能随需分配，动态扩展；

• 第三步是自动化，存储资源由软件(Hypervisor或云管理软件)来自动分配和管理。

经由抽象、池化和自动化，打破了信息孤岛，也不再被供应商绑定，并支持动态扩展的。

在数据平面层的分布式存储或者HCI，大多是通过类似互联网分布式计算，也即多副本的方式来提供数据冗余，另外也有通过双活（如vSAN 延伸集群）来提高可用性。为了解决存储利用率，也有采用EC（纠删码）和去重压缩的技术。

软件定义存储包含了存储虚拟化，简单理解，可以认为软件定义存储=存储虚拟化+自动化，其实就是SDS的三步曲：抽象、池化和自动化。详见《什么是存储虚拟化？它与软件定义存储有何区别？》

都包含了控制平面和数据平面。软件定义这个词汇最早就是来源于软件定义网络（SDN），核心是控制平面和数据平面解耦，SDS在这一部分上收到了SDN的影响。

软件定义的出现，是虚拟化已经渗透，云计算逐渐普及的大环境下，对于基础架构层的迫切需求，打破了以往烟囱或竖井架构，使得资源能够池化并自动化地被部署。迄今为止，云计算，尤其是私有云的最佳实践方式就是软件定义的数据中心，而且这个过程会持续很长时间，直至用户迈向混合云。因此，毫无疑问，SDDC是数据中心的未来。

人类的文明运行在软件和硬件结合的环境之上。实际上，正是因为硬件技术的突飞猛进地发展，才使得软件定义有了腾挪的空间。早期，为了大规模生产，降低制造的复杂度和成本，许多功能都固化在硬件里，我们可以称之为硬件定义。随着日益增长的灵活性、自动化、多样化、个性化定制的需求，由软件来操控硬件资源的情况将越来越多、越来越广。然而，软件操控硬件的前提是，硬件的能力（例如性能、容量等）需要有富余。所以，硬件发展越快，软件定义的发展才会更有潜力。另外，软件的发展反过来也会影响硬件的发展，例如虚拟化软件对芯片指令集的影响，分布式存储软件对网络的影响。

前面提到，软件定义为云而生。所有企业，在云战略上，如果考虑混合云或者私有云，都必须认真思考如何利用现有的最佳实践，也即软件定义的数据中心来使云战略落地。

VMware的软件定义存储主要分为两大部分，如下图所示。

1）控制平面，即Storage Policy Based Management（基于存储策略的管理），简称SPBM。

数据平面，即Virtual DataServices。分别有三个子类构成：Virtual SAN，VirtualVolumes和Cloud/Object Storage。

降低成本、提升性能、管理简单灵活、扩展方便、即刻交付符合一定SLA标准的存储资源。

未来可能出现的软件定义存储，可大致分为如下六类：

1）与Hypervisor融为一体的SDS厂商，也即前述的VMware、Microsoft等。

2）与应用融为一体的超融合架构设备，通常俗称一体机。

由于针对某一类特定业务，其工作负载相对固定，也比较容易在存储曾针对这一特点进行优化，例如针对数据库的有：云和恩墨、天玑数据、沃趣（已被华胜收购）、成都文武信息等；针对VDI的一体机；针对SAP的一体机；并行数据库一体机 （如MonDb）, 数据分析一体机 （Greeplum），也许未来还会有针对Exchange的、针对SQL Server的一体机；从业务应用来看，也许还会有针对视频监控，针对媒资管理等，针对某一行业的某一类应用。

3）拥有某一项或几项出色功能的新SDS厂商。虽然没有与Hypervisor或者应用融合。但靠着它的独特或先进的功能，依然赢得用户的青睐；

4）针对云平台或者Hypervisor生态链，专注某垂直领域的SDS厂商，例如针对AWS的SoftNAS，针对vSphere的Tintri；现阶段针对Hypervisor进行拓展和优化的，应该有不少生存空间；针对公有云的，可能在晚些年陆续出现更多的初创厂商。

5）传统外置磁盘阵列的转型尝试，如HP StorVirtual、EMC vVNX、NetApp OnTap Edge等。

6）云计算公司的的转型尝试，如公有云提供商青云推出超融合一体机等。

7）包括冷存储在内的对象存储。

初期，必须围绕着数据平面下功夫，提供稳定性和可靠性，甚至可能针对业务应用进行优化；将来，数据平面同质化后，应该开始向控制平面层对接，以更好的为存储自动化服务。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业，以及每一个向未来而努力的人，听见时代最前沿的声音，见证成长！

相关文章|Related Articles

作者：enmotech 发布在 eygle.com

超融合的概念自2012年被提出到现在，经历了6年的时间。其技术已经从最初的以存储的融合为重点，经历过计算、存储、网络的全面融合，到现在，重心落在云计算平台的交付，整个技术趋于成熟。

今天我们有幸邀请到青云QingCloud青立方产品总监廖洋（Lester）老师，请他分享青云在超融合的技术和产品上所做的一些尝试，我们一起来学习超融合的发展现状和未来方向，以及超融合是如何兼顾企业的"敏态"和"稳态"的业务需求的。

廖洋（Lester Liao），青云QingCloud青立方产品总监。15年IT行业从业经验，专注于存储及云计算产品，对超融合系统、SAN存储、分布式存储系统、虚拟化、云计算等领域有较深入的研究。

目前团队的工作重心主要在青云QingCloud的硬件产品线--"青立方"，包括青立方超融合一体机、青立方对象存储一体机和青立方NeonSAN一体机等。团队涵盖以上产品线的硬件设计、云平台及存储集成、测试与服务等产品技术人员。

超融合（HCI ：HyperConverge Infrastructure）最初是借鉴了Google、Facebook等互联网公司的技术，通过产品化的包装，导入到企业级IT市场。2012年美国Nutanix公司提出超融合的概念至今已有6年的时间。

市场上的超融合产品至今也经历了三个阶段的发展。

• 第一个阶段，融合1.0。重点在存储：以Nutanix为例，其产品刚推向市场的时候主要强调其分布式存储技术。从技术本身来看并没有什么创新，而主要的创新其实是在其部署架构上，即将VMware的虚拟机与分布式存储部署在相同的服务器上。这一阶段的主要价值是帮助用户从传统的集中存储架构切换到以软件定义存储为核心的分布式存储架构，简化了存储管理的复杂性，提高了存储的可扩展及利用率，从而降低了存储成本，并且在某些特定的场景中提供比集中存储更高的性能和可用性。

• 第二个阶段，融合2.0，重点在于计算、存储、网络的融合，即将数据中心基础架构的三大件----计算、存储、网络实现软件定义，通过软件+通用服务器的方式，在同一个架构里进行交付。这一阶段的主要价值是：简化了用户对IT的管理，从计算、存储、网络三个层面实现横向扩展。

• 第三个阶段，融合3.0，重点在于云计算平台的交付，实现应用（PaaS、SaaS等企业级应用）的横向扩展。青云QingCloud在2015年发布超融合产品时，就强调超融合不仅是计算、存储、网络等资源层面的问题，还要交付完整的云计算。

在第三个阶段以前，业界普遍认为超融合仅适用于面向互联网、横向扩展的分布式业务，而一些传统应用很难构建在超融合架构上。但是青云QingCloud提供的超融合一体机积累了大量公有云的实践经验，融合了多种创新技术来解决扩展性问题。

• 在存储层面，青云不仅提供分布式存储（SDS 2.0），也提供NeonSAN共享块存储；

• 在计算层面，青云不仅提供虚拟主机和容器主机，还提供物理主机，在统一架构上满足应用对基础架构的所有需求；

• 在应用层面，QingCloud AppCenter能够实现应用的横向扩展。

这也是全模云的概念，即面向企业兼顾"敏态"和"稳态"的需求，为分布式和集中式业务架构进行云端部署提供一体化解决方案。企业用户可以根据自身业务特点灵活选择不同类型的云端资源，构建灵活、敏捷、高效的全模式业务系统，并实现统一管理。

• 降低基础架构复杂度，易于管理；

• 采用横向扩展方式，易于扩展；

• 采用通用硬件，可降低成本；

• 更加适合承载云计算业务，提高了性能；

• 支持全模云，兼顾企业"敏态"和"稳态"的业务需求。（青云QingCloud独有的价值）

• 第一类是传统IT厂商，他们的产品更关注硬件层面的融合，软件层面一般采用开源技术，缺乏自己的核心技术；

• 第二类是专注软件定义存储的IT厂商，他们将以往的软件存储方案加上计算，以超融合一体机的形式交付。但是产品成熟度较差，在功能、可扩展性和稳定性上还有待提升；

• 第三类是云计算厂商，把云计算技术，通过超融合一体机的形式，形成私有云的交付。以青云QingCloud为例，从软件层面来看，不管是公有云、私有云还是混合云，青云QingCloud采用统一的代码、自研的技术，核心代码自主可控。因此无论从需求自定义还是产品更新迭代的能力上，都优于开源软件。从硬件层面，青云QingCloud对底层硬件持开放态度，兼容各种主流硬件，不存在硬件绑定。成熟度、稳定性，自研、定制化，兼容性，技术演进路线清晰。

上面融合3.0里有提到应用层面的扩展，不仅是PaaS，也有SaaS，主要通过QingCloudAppCenter实现。

首先从管理架构上看，青云QingCloud支持计算、存储与管理节点分离的部署模式，从而在高可用和安全性上达到高可靠性。其次是P2P运维机器人系统，能够自动处理各类硬件故障、数据中心级的灾难等。此外，青云的高可用和数据保护可以细致到"卷"的级别，这是很多超融合厂商无法做到的。同时，青云QingCloud支持各种容灾级别，如同步复制、异步复制、同中心三副本、异地副本等，都可以自定义。

接下来，青立方超融合一体机将做到更精简的交付。我们现在最小可以做到两台服务器交付，未来从交付规模上会做到更小的集群交付。随着业务规模的不断扩展，能够从1-2台的小规模扩展到上百万台的大集群，或者从易捷版（Express）扩展到高级版、企业版，都是完全平滑的过渡方式。为企业提供从基础的计算虚拟化到企业级的私有云，一条完整通畅的数字化转型路径。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业，以及每一个向未来而努力的人，听见时代最前沿的声音，见证成长！

相关文章|Related Articles

作者：enmotech 发布在 eygle.com

互联网和Web的蓬勃发展正在改变着我们的世界，随着互联网的不断发展和壮大，企业数据规模越来越大，并发量越来越高，关系数据库无法应对新的负载压力，随着Hadoop，Cassandra，MongoDB，Redis等NoSQL数据库的兴起，因其良好的可扩展性，弱化数据库的设计范式，弱化一致性要求，在解决海量数据和高并发的问题上明显优于关系型数据库。因而很快广泛应用于互联网业务中。

Redis作为基于K-V的NoSQL数据库，具有高性能、丰富的数据结构、持久化、高可用、分布式、支持复制等特性。从09年至今，经历8年多的锤炼，已经非常稳定，并且得到业界的广泛认可和使用，同时社区非常活跃。

今天我们有幸邀请到了Redis中国用户组主席张冬洪老师，请他分享Redis的核心技术，应用现状及发展方向等。

我是来自新浪微博研发中心的高级DBA 张冬洪，目前在微博带一个小组，主要负责微博平台、手机微博、话题、红包飞、开放平台、私信、以及内容管控项目的数据库产品运维和服务保障工作。工作中涉及的数据库产品主要包括MySQL、Redis、Memcached、MCQ、Kafka、Pika、Postgresql等。

微博研发中心数据库部门主要负责全微博平台的后端资源的托管和运维，涉及的资源种类比较多，数据量比较大，业务线和资源实例数目也是非常之多，并发量巨大。而这些正是微博这种体量的公司应该具有的，微博作为当今中文社交媒体的第一品牌，拥有超过3.76亿的月活用户，也是当前社会热点事件传播的最主要平台，其中包括但不限制于大型活动（如：里约奥运会、朱日和沙场大点兵等），春晚，明星动态（如：王宝强离婚事件、女排夺冠、乔任梁去世、白百合出轨、TFBOYS生日、鹿晗关晓彤CP等）。

而热点事件往往具有不可预见性和突发性，并且伴随着极短时间内流量的数倍增长，甚至更多，有时持续时间较长。如何快速应对突发流量的冲击，确保线上服务的稳定性，是一个非常巨大的挑战和有意义的事情。为了达到这一目标，需要有一个完善的，稳定可靠的，健壮的数据库运维体系来提供支撑和管理，所以我们团队也是在领导的指导下，有目标、有计划的开展一些数据库自动化运维平台的建设工作。

在业余的时间我和其他几大互联网公司的朋友一起发起了Redis中国用户组（简称CRUG），也欢迎大家加入我们。

我最早接触应该是在12年的时候，当时最新的版本应该是2.6.x。那个时候也没有在线上用，只是学习Linux的时候了解过。所以知道Redis的版本号命名规则借鉴了Linux的方式，版本号第二位如果是奇数，则为非稳定版本，如果为偶数，则为稳定版本。

这里我说下稳定版本的一些主要改进吧：

•Redis2.6

1）键的过期时间支持毫秒

2）从节点提供只读功能

3）服务端支持Lua脚本

4）放开客户端连接数的硬编码限制

5）去掉虚拟内存相关功能等

• Redis2.8

1）完善主从复制功能，实现增量复制

2）Redis设置明显的进程名，在系统中ps命令即可查看

3）发布/订阅添加pub/sub命令

4）Redis Sentinel第二版发布，较Redis 2.6更加完善，可以线上使用

5）可以通过config set命令设置maxclients等

• Redis3.0

1）推出Redis的分布式集群 Redis Cluster

2）全新的embedded string对象编码结果，优化小对象的内存访问，在特定的工作负载下能大幅度提升性能

3）LRU算法提升

4）config set 设置maxmemory的时候可以设置不用的单位

5）新的Client pause命令，在指定时间内停止处理客户端请求等

• Redis3.2

1）添加GEO功能

2）新的List编码类型quicklist

3）SDS在速度和节省空间上都做了优化

4）Lua脚本功能增强

5）新的RDB格式，仍兼容旧版RDB，同时加载速度上也有提升

6）Cluster nodes命令加速等

在Redis4.0版本上，我认为最核心的功能应该是支持了module，这极大的丰富的Redis的功能，使得许多Redis本身不具有的，第三方开发者拓展的功能也能加载到Redis中当一个功能进行使用，比如RediSearch、ReJSON、Redis-ML等。除此之外，还看到有很多新特性：

1）psync2.0，优化了之前版本主从节点切换必然引起全量复制的问题

2）提供全新的缓存剔除算法LFU，并对已有算法进行了优化

3）提供了非阻塞del和flushall和flushdb功能，有效解决了删除bigkey可能造成的Redis阻塞

4）提供了RDB-AOF混合持久化格式

5）提供memory命令，实现对内存的更为全面的监控统计

6）Redis Cluster 兼容NAT和Docker

7）引入Jemalloc库，优化内存访问等等

Redis之所以能够被广泛的应用于企业的架构中，而且是不可或缺的重要组成部分，也可以说是标配吧，其中很重要的一点就是得益于它具有丰富的数据结构，这也是它逐渐替代Memcached，备受青睐的重要原因。那么Redis都提供哪些数据类型呢？

相信对Redis有了解过的同学都知道，它的数据类型有：String、Hash、List、Set、Zset、Bitmaps、HyperLogLog、GEO等。

随着互联网的兴起和Redis技术的不断完善和发展，它已经被广泛应用于各行各业中，应用场景也是百花齐放。比如：会话缓存（Session cache）、全页缓存（FPC）、手机验证码、访问频率限制/黑白名单、消息队列、发布与订阅、消息通知、排名/排行榜/最新列表、计数器（比如微博的转评赞计数、阅读数（浏览数，视频播放计数）、博文数（发帖数）、粉丝数、关注数（喜欢商品数）、未读数（动态数））、共同好友/喜好/标签、推送、下拉刷新、私信、商品库存管理（限时的优惠活动信息）、证券指标实时计算，发号器/UUID、以及随着LBS（基于位置服务）的发展，加入的GEO（地理信息定位）的功能和基于Lua自定义命令或功能等等。大家在使用过程中，需要结合自己的业务场景，选择正确的数据类型。

Redis作为基于K-V的NoSQL数据库，具有高性能、丰富的数据结构、持久化、高可用、分布式、支持复制等特性。从09年至今，经历8年多的锤炼，已经非常稳定，并且得到业界的广泛认可和使用，同时社区非常活跃，开发者又很严谨，这使得Redis版本非常精简，bug fix非常高效。根据similarweb.com的统计，中国Redis用户占全球Redis用户的40.96%，所以我们在使用的过程中遇到的问题，大部分可能都有解决方案。

需要关注的点比较多，之前在CRUG深圳站活动的分享中也提到过一些，下面举一些例子吧：

1)安全问题：Redis用非root用户启动，并且运行在内网，尽可能不要暴露在外网，配置认证requirepass xxx，减少被攻击的风险；开启危险命令认证（keys-need-auth yes rename-command KEYS MY_KEYS）

2)容量问题：合理评估；合理使用内存分配策略（no-enviction、allkeys-random、allkeys-lru、volatile-random、volatile-ttl、volatile-lru）；检查是否有内存碎片；选择合适的服务类型（Redis cluster或者pika）；水平拆分；性能满足的条件下选择诸如ziplist类的内部编码

3)big-key问题：可能会引起慢查或者带宽瓶颈，按照业务逻辑拆成小key或者业务解耦剥离big-key或直接改用其他存储方式

4)hot-key问题：Redis是单进程，节点实例很容易成为系统的短板，垂直扩容；增加local cache；如果只是简单的k-v结构，可以考虑使用Memcached

5)使用姿势问题：避免使用阻塞操作（如：flushall、flushdb、keys *等）；尽量使用Pipeline，减少syscall带来的网络IO，但要注意限制数据量大小；对多个元素操作时，像使用SORT、LREM、SUNION，计算复杂度为O(N), 避免线上乱用；尽可能使用最新的版本

6)Key过期问题：合理设置过期时间；如果存在许多该过期的key而没被及时删除，可以通过命令scan、hscan、sscan、zscan、keys *遍历一遍key的方式实现

7)配置上：建议开启tcp-keepalive，tcp-backlog，从库设置readonly yes

8)系统设置：关闭NUMA；关闭transparent _hugepage; 关闭swap

等等，大家有问题的时候可以相互交流。

Redis做消息队列，有两种实现方式：

第一种：通过数据结构List来实现

优点：能够实现持久化；支持集群；接口使用简单

缺点：

• 如上图所示，一条消息只会被一个消费者消费，所以不存在有多个消费者消费一条消息

• 生产者和消费者的高可用或崩溃后的处理机制需要自己实现

• 当生产者消息写入太快，消费者消费太慢，则有可能会导致内存溢出问题，导致进程crash

第二种：通过pub/sub来实现

优点：

一个生产者可以对应多个消费者，但是必须保证消息发布者和消息的订阅者同时在线，否则，否则一旦消息订阅者由于各种异常情况而被迫断开连接，在其重新连接后，其离线期间的消息是无法被重新通知的（即发即弃）。当然，生产者不需要关心有多少的订阅者，也不用关心订阅者的具体信息，而订阅者可以根据需要自由选择订阅哪些频道：支持集群；接口使用简单等。

缺点：

• 没有持久化机制，属于即发即弃模式，因此也不需要制定消息的备份和恢复机制

• Redis没有提供保证pub/sub消息性能的方案

• 当大量的消息到达Redis服务时，如果订阅者不能及时完成消费，则就会导致消息堆积，引发上面一样的内存问题

要了解Redis的集群功能，可以从数据分片、数据迁移、集群通讯、故障检测以及故障转移等方面进行了解，Cluster相关的代码也不是很多，注释也很详细，可自行查看，地址是：https://github.com/antirez/redis/blob/unstable/src/cluster.c。

这里由于篇幅的原因，主要从数据分片和数据迁移两方面进行详细介绍：

• 数据分片

Redis cluster在设计中没有使用一致性哈希（consistency hashing），而是使用数据分片（sharding），引入哈希槽（hash slot）来实现；一个 redis cluster包含16384（0~16383）个哈希槽，存储在redis cluster中的所有的键都会被映射到这些slot中，集群中的每个键都属于这16384个哈希槽的其中一个，集群使用公式slot=CRC16（key）/16384来计算key属于哪个槽，其中CRC16(key)语句用于计算key的CRC16 校验和。

集群中的每个主节点（Master）都负责处理16384个哈希槽中的一部分，当集群处于稳定状态时，每个哈希槽都只由一个主节点进行处理，每个主节点可以有一个到N个从节点（Slave），当主节点出现宕机或网络断线等不可用时，从节点能自动提升为主节点进行处理。

如上，clusterNode数据结构中的slots和numslots属性记录了节点负责处理哪些槽。其中，slot属性是一个二进制位数组(bitarray),其长度为16384/8=2048 Byte，共包含16384个二进制位。集群中的master节点用bit（0和1）来标识对于某个槽是否拥有。比如，对于编号为1的槽，master只要判断序列的第二位（索引从0开始）的值是不是1即可，时间复杂度为O(1)。

集群中所有槽的分配信息都保存在clusterState数据结构的slots数组中，程序要检查槽i是否已经被分配或者找出处理槽i的节点，只需要访问clusterState.slots[i]的值即可，复杂度也为O(1)。clusterState数据结构如下所示：

查找关系如下图：

• 数据迁移

数据迁移可以理解为slot和key的迁移，这个功能很重要，极大的方便了集群做线性扩展，实现平滑的扩容或缩容。

那么它是一个怎样的实现过程呢？

下面举个例子：现在要将Master A节点中的编号为1、2、3的slot迁移到Master B节点中，在slot迁移的中间状态下，slot 1、2、3在Master A节点的状态表现为MIGRATING,在Master B节点的状态表现为IMPORTING。

MIGRATING状态

这个状态如上图所示是被迁移slot在当前所在Master A节点中出现的一种状态，预备迁移slot从Mater A到Master B的时候，被迁移slot的状态首先变为MIGRATING状态，当客户端请求的某个key所属的slot的状态处于MIGRATING状态的时候，可能会出现以下几种情况：

1）如果key存在则成功处理

2）如果key不存在，则返回客户端ASK，客户端根据ASK首先发送ASKING命令到目标节点，然后发送请求的命令到目标节点

3）当key包含多个命令时：

• 如果都存在则成功处理

• 如果都不存在，则返回客户端ASK

• 如果一部分存在，则返回客户端TRYAGAIN，通知客户端稍后重试，这样当所有的key都 迁移完毕的时候客户端重试请求的时候回得到ASK，然后经过一次重定向就可以获取这批键

此时并不刷新客户端中node的映射关系

IMPORTING状态

这个状态如上图所示是被迁移slot在目标Master B节点中出现的一种状态，预备迁移slot从Mater A到Master B的时候，被迁移slot的状态首先变为IMPORTING状态。在这种状态下的slot对客户端的请求可能会有下面几种影响：

1）如果key不存在则新建

2）如果key不在该节点上，命令会被MOVED重定向，刷新客户端中node的映射关系

如果是ASKING命令则命令会被执行，从而key没在被迁移的节点，已经被迁移到目标节点的情况命令可以被顺利执行。

键空间迁移

这是完成数据迁移重要的一步，键空间迁移是指当满足了slot迁移前提的情况下，通过相关命令将slot 1、2、3中的键空间从Master A节点转移到Master B节点，这个过程由MIGRATE命令经过3步真正完成数据转移。步骤示意如下：

经过上面三步可以完成键空间数据迁移，然后再将处于MIGRATING和IMPORTING状态的槽变为常态即可，从而完成整个重新分片的过程。

根据业务的规模以及Redis使用环境的不同，Redis的高可用方案也比较多。这里举一些例子说明一下业界比较常用的一些方案吧。需要说明一下的是下面的这些方案不涉及到同城多活或异地多活的场景，但是部分方案能够做到跨数据中心的灾备。

•Keepalive + Redis

•Redis Sentinel

•Twemproxy + Redis Sentinel + Redis

•Redis Cluster

•Redis Sentinel + Proxy + Zookeeper + Redis

•Zookeeper + MySQL + Redis + DNS

如果不强调"最大的"话，我知道有不少的挑战，哈哈。

我想最大的挑战应该是"智能化"吧。现在业界都在追捧DevOps、AIOps，那么在Redis的自动化运维过程中，也需要学习行业的先进思想，结合部门自身的实际稳扎稳打，逐一突破。

首先在智能化实现之前，我们要尽力实现下面的一些需求：

1）数据库运维自动化平台的建设，为RD和DBA提供较全面的自助服务和数据库管理功能

2）工单事件关联任务系统，一键完成自动安装部署，添加产品线和报警

3）海量报警智能分类（比如按产品线或按DBA分类），实现部分报警故障自愈 （比如：从库readonly设置、内存使用率超过95%自动扩容）

4）基于队列分布式批量部署，可横向扩展，任务异步调度，满足大规模部署、扩容的需求

5）日志实时展示，监控数据实时采集，图形化多维度展示，满足可视化的需求

6）RedisHA支持秒级响应，实现故障无缝切换，满足高可用的需求

7）缓存弹性扩缩容（利用私有云和公有云，结合Docker容器化技术实现），满足对热点的快速应对

8）内部开发了各种通用的管理和运维脚本，化繁为简，提高工作效率

9）根据历史/晚高峰资源的性能指标设置水位线，和报警阈值，提供决策支持

10）在Redis集群、容灾、异地多活（跨数据中心数据同步）、微服务等等方面还需要花很大的力气去建设，目前依旧比较欠缺

智能化的实现还需要持续的投入和迭代。

是的，这几年从运维的角度看，明显能感觉到数据体量上的膨胀，一个实例动不动就几十G，一个集群动不动几百G、几T，甚至更多。以Redis为代表的NoSQL数据库在处理这方面的表现还是令人非常满意的。它的高性能表现得淋漓尽致，从微博的业务来看，Redis实例每天承载着千亿级的写QPS、万亿级的读QPS，数据量TB级，确实没有Redis，且不说能不能用关系型数据库存储，单是硬件成本就几何倍增长了吧。

未来，随着硬件成本的降低，硬件性能优化的极致，比如PCIE、25GE网络的升级，一定是软硬结合，会出现更多的Redis的相关产品和服务。包括收费的Redis Enterprise，Cloud Redis等，也包括开源的Pika、TiDB等NewSQL。正如阿里云的同学所说，"数据库终极是九九归一 -- 量子数据库"，一起期待吧。

首先当然还是需要多看官方文档，多看看业界大牛的技术博客。其次可以买几本书对比着学习下，目前市面上的相关书籍也就4，5本的样子。然后主要的还是要多动手，实践出真知，在使用的过程中，还是要结合具体的业务场景，灵活使用。有能力的时候，看看源码，了解底层的实现原理。最后，多思考多总结，好记性不如烂笔头，每一次踩坑都是一次成长，遇到解决不了的问题的时候多向业界大牛们请教学习，平时多关注一些业界相关技术的最新动态。

纵观Redis的发展，无独有偶的与互联网的发展浪潮紧紧相随，从web1.0到web2.0的转变，从博客、贴吧、论坛到社交媒体，从文本到图文再到短视频的兴起，从互联网到移动互联网，从3G到4G到即将普及的5G，从异军突起的新兴产业，如：团购、电商、外卖、旅游、游戏、互联网金融和证券、出行和直播等等，商业模式在不断的改变，不断的在刷新人们的生活方式。

但是在这些变化的背后，不变的是Redis作为基础服务为企业的高可用架构保驾护航，变化的是Redis的使用案例越来越丰富、服务体验越来越好。在Redis的发展过程中，由于企业需求的多样化，对Redis的要求越来越高，许多场景Redis的功能显得相形见绌，因此出现了诸如Codis、Pika、CounterService、ApsaraCache、CacheCloud、smartClient（Redisson）等产品，它们是对Redis的有益补充。

随着4.0版本module功能的推出，使得Redis拥有更多的想象和发展空间，在全文索引（RediSearch），AI（Redis-ML）、云计算、大数据、物联网、人工智能、BlockChain等领域，模块化的融合能力将极大的丰富Redis的功能，从而为企业构建更为多元化、立体化的数据库使用方式。

在使用Redis的过程中，还需要保持关注官方的动态，多看看github上的changelog和issue，因为随着Redis的用户群体的增多，使用场景的复杂化，Redis自身隐藏的问题或瓶颈也会暴露出来，这样有助于我们避免踩一些不必要的坑，及早规避一些风险。

不仅仅是Redis，学习其他的数据库也是一样的。另外，我们在关注Redis本身以外，还需要关注一些其他的Redis的替代产品（比如：SSDB、Pika、Codis、ApsaraCache、TiDB等），Redis的周边工具（如：redis-migrate-tool、redis-faina、redis-audit、redis-rdb-tools、RedisMyAdmin等）、中间件(如：twemproxy、corvus、redis-cerberus)等。如果你想要从事Redis的开发，那么你可能需要关注的更多，比如各种锁的实现。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业，以及每一个向未来而努力的人，听见时代最前沿的声音，见证成长！

相关文章|Related Articles

作者：enmotech 发布在 eygle.com

在互联网和大数据的压力下，很多企业面临着经济增长下滑、跨行业竞争激烈，用户需求越来越个性化。于是如何实现转型、业务创新和盈利增长成为企业的共同诉求。

而依靠硬件的提升获取系统性能大幅度提升的日子已经一去不复返。软件定义这么技术从提出到被广泛接受和利用，只用了短短几年的时间。其盛行的原因主要有以下几个方面：

作为软件定义的核心，软件定义存储则为存储行业带来了更多的可能。x86架构成为主流，不仅提供了相对廉价的计算资源，还带来了无与伦比的软件生态环境。

在本次遇见未来的专访栏目中，我们邀请了来自戴尔EMC的高级市场经理周俊杰先生，请他分享软件定义这门技术的发展现状及背景，以及戴尔EMC在软件定义存储方面所做的尝试和成果。通过基于软件定义技术的数据加速解决方案，让你的系统加速跑！

周俊杰先生, 现任戴尔EMC大中华区企业级产品市场总监，负责服务器及相关解决方案的产品市场工作。出生于计算机家庭，从小受到计算机知识熏陶，加上在IT行业超过23年的经验中，曾经服务于奇虎360、浪潮集团、惠普等各大企业，在大客户销售，业务拓展，渠道管理，产品管理，市场营销，都有着丰富的经验。

传统的存储设备已经在行业里叱咤风云了近20年，回想起来，特别有意思的事实是：存储一开始也不是我们现在看到的传统存储设备的形态，从一开始居然也是"软件定义"的。一台服务器带着比较大的硬盘容量，通过一些标准的操作系统及功能软件的管理，就是存储设备了。通过提升客户的数据处理和保存能力，支撑着客户的数据库，邮件，文件，客户文档等业务的快速发展。随着网络技术的发展，专有形态的存储不断涌现。

而过去的10年的数据增长主要在于结构化的数据。 从2000年互联网泡沫破裂，到随着web2.0的出现再现辉煌，数据的增长也呈指数级的增长，各大公司分别作出至2020年的全球ZB级数据总和的预测，而增长的主要动力来源于非结构化化或者半结构化数据。

大部分传统存储主要为关键业务数据而设计，它的扩展性有局限，协议支持固有，数据存储类型单一，不够灵活，新技术的适配性较差，追随也较慢。面对新兴的应用场景，特别是当云，大数据等技术被用户广泛使用，传统的存储技术已经不太适合新兴的应用场景，这些场景典型的需求（相反就是痛点）包括：灵活扩展，跟新兴应用结合紧密，较低的成本，部署和管理简便，学习成本低，支持应用和存储融合，不受限于专有硬件，从闭源到开源软件的选择相对灵活，多协议支持适用多用途等特征。从2010年在行业内启动，经过6-7年的验证期，在2017年，软件定义存储的引爆点到来。

软件定义的技术正被各行各业所看好，我们看到从传统行业中的金融，证券，电信，政府，医疗，教育，制造，物流等领域，原来越多的软件定义招标正在发生中。蓬勃发展的互联网行业早几年前，就已经开始了基于自行研发的软件定义技术的实践应用。我们认为从宏观上来看，云原生的应用，大数据的应用是软件定义存储的主战场。从具体应用角度，超融合，非结构化数据的存放及归档，多数据存储类型应用将是软件定义存储的典型应用场景。

目前在中国，客户的广泛认可度依然是一个主要挑战，特别是传统行业。软件定义存储还需要再经历几年的磨炼，形成各行各业的最佳实践，用事实说话，让用户信服。

部署和管理成本低，学习成本也低；多协议，多数据存储类型，支持超融合等多用途；扩展灵活，不受限于专有硬件设备；软件选择宽泛；基于对象的存储方面技术领先；技术迭代快，能第一时间利用到如非易失性内存，NVMe, RDMA等最新硬件技术。

很多软件定义存储技术使用多副本，纠删码等技术来满足应用对数据高可用需求。

方式不同，目的也不同。

SDS理论上可以运行在任何开放的工业标准服务器上，来提供一致性数据服务。即便是借助虚拟化软件，也是行业通用的Hypervisor。目的是把存储软件和硬件解耦合。具体好处如上所述。

而存储虚拟化技术一般来讲，是指通过定制的软件，运行在经过适配的专用存储硬件之上，通过网络，将原来多个不同的存储设备进行统一的一致性数据访问的池化技术。

软件定义的归根诉求我认为来自企业自身的业务发展。有的企业为了业务效益最大化，有的为了生存，有的为了业务转型，他们加速数字化转型需求日益明显，而传统存储，传统网络等技术迭代较慢，基本以年为周期单位，甚至更长。这个大大落后于企业由于新业务的爆发或者老业务的技术改造而产生的对新技术能力的渴求。而软件定义的技术，将成倍缩短技术迭代周期。

打个比方，这个跟智能手机的迅速成为主流，而传统功能固化的手机迅速被淘汰的过程是相同的。因为智能手机硬件本身只是载体，而运行在上面的以月，以周为周期，不断迭代的APP所产生的能力才是用户所真正享受到的利益。同时软件定义技术能帮助企业在特定的业务上摆脱对专有设备的依赖和束缚。我们相信未来的数据中心将会越来越多的使用软件定义的技术，来成就企业的生存，发展和转型。

DELL和EMC合并之后，整体软件定义存储产品形成了全面体系化的产品组合。

包括先前有的vSAN, XC系列，又增加了专门针对对象存储的Elastic Cloud System，专门针对块存储的Scale IO，专门针对数据保护的Data Domain Virtual Edition等。这些软件都可以运行在戴尔EMC的x86服务器之上，组成软件定义的存储，针对特定的客户应用场景，提供给客户多一种选择。

戴尔EMC一如既往地积极推动软件定义存储的发展，我们认为在将来的数据中心里，服务器将成为基石。在服务器的设计上，第一时间引入业内标准的，先进的，可靠的，高性价比的组件，赋能软件定义存储技术。

增加业务的弹性，灵活性，提升业务效率；降低管理成本；降低企业业务数据风险；减轻IT选择风险。全面支持企业数字化转型。

未来统一的IT基础架构均是由软件定义的网络、存储、计算三大IT基础资源所构成的，并辅以自动化的运维。而在IT系统建设中，所有的核心都将围绕数据库展开。

zData light storage是云和恩墨开发的一种针对数据库领域的软件定义存储软件。最初只针对Oracle数据库，也即将支持MySQL等开源数据库。

其基本架构如下：

zData存储平台软件整合PC服务器，InfiniBand网络，传统的机械硬盘/SSD和闪存卡等开放平台硬件。为数据库提供分布的存储池。以满足高性能、高可用、易扩展等需求。

其分布式存储架构如下：

具有以下的特点和功能：

高性能：超百万IOPS，能很好地应对数据库场景下极端的性能需求；

安全性：2-3副本存储，应对去也最核心业务数据完整性和一致性的要求

扩展性：在线增加存储能力和计算能力，以满足业务交易量越来越大的需求。

推荐阅读（或了解产品详情，请加产品小助手微信：sunx5126）：

加速Oracle RAC性能 软件定义存储的数据库云化实践

分布式存储解决方案zData

zData方案在多个企业和单位有过最佳实践,以其高计算能力、高 I/O 能力、高可用能力、高可伸缩能力且极具稳健性的分布式存储架构，是具有高并发高IO需求的系统的最佳选择。在过去的实践中也得到证实和认可。

贵州交警

贵州交警某业务系统随着系统应用的深入和广泛，原有基础架构、数据架构规划和设计上的问题逐渐凸现出来，主要表现为业务数据爆炸增长、业务应用增多、系统响应缓慢、物理扩容达到瓶颈、设备达到服务年限。在经过zData一体机整合之后，整体用户体验得到了大幅改善，业务受理和办理效率均得到了用户赞誉。

性能提升效果：

1、整体性能提升18倍：重构前核心指标DBTIME每日最高单小时为3563.15，重构后每日最高单个小时指标为199.68，性能效果提升17.8倍。

2、I/O响应提升1000倍：重构前平均单次I/O请求时间为10.07毫秒，重构后平均I/O的请求时间缩短为0.01毫秒，I/O效率提升1007倍。

3、SQL性能提升117倍：考察违法审批报表SQL执行效率，重构前SQL执行需10206.1秒，重构后SQL执行完成只需87.07秒，执行效率提升117倍。

跨界与融合、机遇与挑战、个人与企业、现在与未来。让各行业、企业，以及每一个向未来而努力的人，听见时代最前沿的声音，见证成长！

相关文章|Related Articles

作者：eygle 发布在 eygle.com

在2018的新年（据2月16日文章），Oracle宣布Database 18c已经发布，但是仍然是首先在Oracle Cloud上一体机环境发布出来。所以要等到常规版本的公开提供，还有一段时间要等。

期待尝鲜的朋友，可以通过 livesql.oracle.com 来体验一下新特性，该平台的数据库版本已经升级到 18.1.0.0 版本：

Live SQL 18.1.2, running Oracle Database 18c Enterprise Edition - 18.1.0.0.0

那么在 18c 中有哪些新特性值得瞩目呢？新文档已经发布，在 docs.oracle.com 上你可以找到关于数据库 18c 的新特性文档。

我下载整理了相关文档，关注公众号回复关键字：18cNF ，可以获得这些文档。

此前已经写过一些文章讨论 18c 的新特性，现在大致浏览文档，还可以看到以下一些小的改变：

1. New Default Location of Oracle Database Password File，在18c中，口令文件的缺省位置迁移到 $ORACLE_BASE 目录下，以便去除对于 $ORACLE_HOME的更改。

2. Read-Only Oracle Home，设置 $ORACLE_HOME 为只读，则变化文件将创建于 $ORACLE_BASE， 这是为了标准化、分发共享、滚动升级等提供便利；

3. RPM-based Database Installation，终于Oracle 提供了 RPM 方式的安装方式。

4. Online Merging of Partitions and Subpartitions，可以在线合并分区和自分区，加强了在线维护性；

5. Scalable Sequences，自适应的序列，是为了减少高并发DML下的竞争，通过构建不连续的序列，打散和减轻类似索引之上的分裂竞争等，这是来自Oracle优化最佳实践的增强；

6. ASM Database Cloning，ASM数据库克隆支持多租户数据，这个特点通过ASM冗余提供了一种基于数据的原生克隆方式，可以替代基于存储级别的克隆或复制同步；

7. Concurrent SQL Execution with SPA，通过并行执行加快SPA的测试过程，这个特性在升级时很有用，云和恩墨有一个自己内部的并行版本，现在Oracle也推出了这个特性；

8. Modifying the Partitioning Strategy，可以将堆表在线或者离线的修改分区策略，比如将HASH分区改为范围分区；

9. 自动纠正Non-logged Blocks at a Data Guard Standby Database，自动纠正备库因Nologging而导致的坏块问题；

10. Shadow Lost Write Protection，写丢失的影子保护，可以在表空间、数据库、数据文件级别开启，用于主动提前检查和防止写丢失；

参考新特性手册，可以了解这些内容。

如果你错过了我们年前准备的新春大礼包，不妨再来一次也好：

1、《恩墨年货-企业系统运维及案例实践》下载地址：https://pan.baidu.com/s/1mkpD2fY

2、《恩墨年货-MySQL与开源技术》下载地址：https://pan.baidu.com/s/1rahxN3Y

3、《恩墨年货-SQL与性能优化》下载地址：https://pan.baidu.com/s/1smLbfEP

4、《恩墨年货-前沿技术与时代走向》下载地址：https://pan.baidu.com/s/1jJa8mqy

10课时经典视频，帮助你更好地学习新特性与RAC核心技术。

课程资料下载链接：

链接: https://pan.baidu.com/s/1kWoduCn 密码: 4e3d

相关文章|Related Articles

• Oracle 18c 安装ORA-12754 Runtime Environment的两种解决方案
  
• 极速体验:Oracle 18c 下载和Scalable Sequence新特性
  

作者：eygle 发布在 eygle.com

Oracle 18c 已至，目前已经可以从Oracle Edelivery 网站下载。 该网站的网址是：https://edelivery.oracle.com 。

搜索 Oracle Database 可以看到 18 版的软件介质，目前的介质声明是 Exadata Only，但是应可以在非Exadata Linux 系统平台安装，OEL 是Oracle 推荐的最佳支持平台 ：

目前介质包含主要包含三个文件，客户端、软件 和 Grid 安装包，首发 Linux 系统支持版本（百度云分享了一份软件，关注公众号 oranews 回复：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-进程号取余-序列号

通过自定义智能主键，很好地避免了传统的索引方案的不足，在不影响性能的情况下有效实现了业务的需求。

我们来看一下 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.

现在通过这种序列方式，能够真正将来自不同实例的数据分散开来，索引竞争大大降低，从而提升了性能，使得序列变得可扩展。

更多新特性，欢迎大家测试体验，并和我们分享。

如果你错过了我们年前准备的新春大礼包，不妨再来一次也好：

1、《恩墨年货-企业系统运维及案例》下载：https://pan.baidu.com/s/1mkpD2fY

2、《恩墨年货-MySQL与开源技术》下载：https://pan.baidu.com/s/1rahxN3Y

3、《恩墨年货-SQL与性能优化》下载：https://pan.baidu.com/s/1smLbfEP

4、《恩墨年货-前沿技术与时代走向》下载：https://pan.baidu.com/s/1jJa8mqy

10课时经典视频，帮助你更好地学习新特性与RAC核心技术。

课程下载：https://pan.baidu.com/s/1kWoduCn 密码: 4e3d

相关文章|Related Articles

• Oracle 18c 安装ORA-12754 Runtime Environment的两种解决方案
  
• Oracle Database 18c已经发布及新特性介绍
  

作者：eygle 发布在 eygle.com

Oracle 率先在 Oracle Cloud 上发布了 18c 的数据库版本，也对外发布了针对 Exadata 的下载包。这些软件首先在 Edelivery 网站上提供了下载。

也可以参考公众号之前文章：极速体验:Oracle 18c 下载和Scalable Sequence新特性 关注本公众号（需要在微信关注 OraNews 公众号回复）：18cNF 找到下载软件。

目前发布的版本，已经声明限制在 Exadata 上安装，安装软件之后会遇到 ORA-12754 错误，无法启动实例：

SQL> startup

ORA-12754: Feature 'startup' is disabled due to missing capability 'Runtime Environment'.

目前这个问题有两种解决方案：方案一 是通过Oracle Cloud找到非限制版本的libserver18.a资源，重新编译；方案二 是通过添加参数 _exadata_feature_on 来解决。以下的这些方法，仅供测试参考，请勿侵犯Oracle的软件版权。相信通用版本很快就会发布。

目前Oracle公有云上已经发布了18c的安装版本，申请免费账号就可以登录使用18c的云版本。

在安装之后，可以在 $ORACLE_HOME/lib 下找到 libserver18.a 库文件，这个文件：

[oracle@O18c lib]$ ls -l libserver18.a

-rw-r--r-- 1 462876440 Mar 1 04:13 libserver18.a

这个文件其实有 450MB，但是真正的启动限制来自其中的 ksct.o 文件，其中增加了一个函数 kscxnfy 功能检测环境，下载这个文件仅有 160 KB 大小，将这个文件复制到 $ORACLE_HOME/lib 目录，更新替换原来的文件：

[oracle@sdb0 lib]$ ls -l libserver18.a

-rw-r--r-- 1 oracle oinstall 462826398 Mar 1 11:13 libserver18.a

[oracle@sdb0 lib]$ ar -r libserver18.a ksct.o

[oracle@sdb0 lib]$ pwd

/u01/app/oracle/product/18.1.0/lib

然后重新make oracle执行文件即可：

[oracle@sdb0 lib]$ pwd

/u01/app/oracle/product/18.1.0/rdbms/lib

[oracle@sdb0 lib]$ make -f ins_rdbms.mk ioracle

chmod 755 /u01/app/oracle/product/18.1.0/bin

- Linking Oracle

rm -f /u01/app/oracle/product/18.1.0/rdbms/lib/oracle

/u01/app/oracle/product/18.1.0/bin/orald 。。。。

rm -f /u01/app/oracle/product/18.1.0/bin/oracle

mv /u01/app/oracle/product/18.1.0/rdbms/lib/oracle /u01/app/oracle/product/18.1.0/bin/oracle

chmod 6751 /u01/app/oracle/product/18.1.0/bin/oracle

数据库此后就可以正确使用，DBCA 等可以正常使用进行建库等操作：

[oracle@sdb0 lib]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 Production on Mon Mar 1 12:27:42 2018

Version 18.1.0.0.0

SQL> startup

ORACLE instance started.

Database mounted.

Database opened.

方案二，是通过手工建库在参数文件中增加（需要修改在 init.ora 参数文件中，以下是一个对比验证的输出效果）：

SQL> alter system set "_exadata_feature_on"=true scope=spfile;

[oracle@sdb0 dbs]$ sqlplus / as sysdba

SQL*Plus: Release 18.0.0.0.0 Production on Mon Mar 1 11:18:25 2018

Version 18.1.0.0.0

SQL> startup

ORACLE instance started.

Total System Global Area 1459617328 bytes

Database mounted.

Database opened.

SQL> alter system set "_exadata_feature_on"=false scope=spfile;

System altered.

SQL> shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup

ORA-12754: Feature 'startup' is disabled due to missing capability 'Runtime Environment'.

Oracle 18c 自治数据库的时代已经来临，欢迎大家测试和分享关于 18c 有意思的新特性。

相关文章|Related Articles

• 极速体验:Oracle 18c 下载和Scalable Sequence新特性
  
• Oracle Database 18c已经发布及新特性介绍
  

作者：eygle 发布在 eygle.com

在 Oracle 11.2.0.2 之后，随着一系列 SCN 耗尽问题的出现，很多补丁涌现出来，一个新的 Package 增加进来。
这个 Package 就是 DBMS_SCN 。

如果你的数据库中存在这个Package，也就意味着你已经安装具备了关于DB Link的修正补丁。

以下是这个包的主要函数过程以及说明，这个内容来自Oracle 11.2.0.4版本平台：

Rem
Rem $Header: rdbms/admin/dbmsscnc.sql /st_rdbms_11.2.0/1 2013/04/18 23:05:40 vgokhale Exp $
Rem
Rem dbmsscn.sql
Rem
Rem Copyright (c) 2012, 2013, Oracle and/or its affiliates. 
Rem All rights reserved. 
Rem
Rem    NAME
Rem      dbmsscnc.sql - dbms_scn package definition
Rem
Rem    DESCRIPTION
Rem      
Rem
Rem    NOTES
Rem      
Rem
Rem    MODIFIED   (MM/DD/YY)
Rem    mtiwary     05/26/12 - Declarations and definitions related to DBMS_SCN
Rem                           package.
Rem    mtiwary     05/26/12 - Created
Rem

Rem
Rem    BEGIN SQL_FILE_METADATA 
Rem    SQL_SOURCE_FILE: rdbms/admin/dbmsscn.sql 
Rem    SQL_SHIPPED_FILE: 
Rem    SQL_PHASE: 
Rem    SQL_STARTUP_MODE: NORMAL 
Rem    SQL_IGNORABLE_ERRORS: NONE 
Rem    SQL_CALLING_FILE: 
Rem    END SQL_FILE_METADATA

SET ECHO ON
SET FEEDBACK 1
SET NUMWIDTH 10
SET LINESIZE 80
SET TRIMSPOOL ON
SET TAB OFF
SET PAGESIZE 100

CREATE OR REPLACE LIBRARY DBMS_SCN_LIB TRUSTED AS STATIC;
/

CREATE OR REPLACE PACKAGE DBMS_SCN AUTHID CURRENT_USER IS

DBMS_SCN_API_MAJOR_VERSION  CONSTANT NUMBER := 1; 
DBMS_SCN_API_MINOR_VERSION  CONSTANT NUMBER := 0;

PROCEDURE GetCurrentSCNParams(
                rsl      OUT number,
                headroom_in_scn OUT number,
                headroom_in_sec OUT number,
                cur_scn_compat OUT number,
                max_scn_compat OUT number);

--      Currently no exceptions are thrown.
--      rsl             - Reasonable SCN Limit as of 'now'
--      headroom_in_scn - Difference between current SCN and RSL
--      headroom_in_sec - number of seconds it would take to reach RSL
--                        assuming a constant SCN consumption rate associated
--                        with current SCN compatibility level
--      cur_scn_compat  - current value of SCN compatibility
--      max_scn_compat  - max value of SCN compatibility this database
--                        understands

FUNCTION GetSCNParamsByCompat(
                compat IN number,
                rsl           OUT number,
                headroom_in_scn OUT number,
                headroom_in_sec OUT number
         ) RETURN boolean;

--     compat           -- SCN compatibility value
--     rsl              -- Reasonable SCN Limit
--     headroom_in_scn  -- Difference between current SCN and RSL
--     headroom_in_sec  -- number of seconds it would take to reach RSL
--                         assuming a constant SCN consumption rate associated
--                         with specified database SCN compatibility
--
--     Returns False if 'compat' parameter value is invalid, and OUT parameters
--     are not updated.

PROCEDURE GetSCNAutoRolloverParams(
                effective_auto_rollover_ts OUT DATE,
                target_compat OUT number,
                is_enabled OUT boolean);

--      effective_auto_rollover_ts  - timestamp at which rollover becomes
--                                    effective
--      target_compat               - SCN compatibility value this database
--                                    will move to, as a result of
--                                    auto-rollover
--      is_enabled                  - TRUE if auto-rollover feature is
--                                    currently enabled

PROCEDURE EnableAutoRollover;

PROCEDURE DisableAutoRollover;

END DBMS_SCN;
/

这里就可以看到 auto-rollover 的自动 SCN 兼容性终止时间，
也就是说，在不同的兼容性设置中，SCN的算法不同，但是内置了天然的算法过期时间。

在此之后，可以通过命令修改数据库的SCN兼容性算法：


SQL> ALTER DATABASE SET SCN COMPATIBILITY 2;
Database altered.

从高级别向低级别修改，需要数据库在Mount状态：


SQL> ALTER DATABASE SET SCN COMPATIBILITY 2;
ALTER DATABASE SET SCN COMPATIBILITY 2
*
ERROR at line 1:
ORA-01126: database must be mounted in this instance and not open in any instance


SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area 4609830912 bytes
Fixed Size   2260888 bytes
Variable Size   989855848 bytes
Database Buffers  3607101440 bytes
Redo Buffers    10612736 bytes
Database mounted.
SQL> ALTER DATABASE SET SCN COMPATIBILITY 2;
Database altered.
SQL> alter database open;
Database altered.

这是一个非常重要的变化。

相关文章|Related Articles

• Oracle全面修正了关于DB Link和SCN补丁的公告
  
• SCN 新算法：DBMS_SCN的用法及范例
  
• Oracle 11g在补丁修正中引入DBMS_SCN包及新特性
  
• 解决方案：Oracle的DB Link问题及2019年4月升级路线详述
  
• 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级
  

作者：eygle 发布在 eygle.com

在 Oracle 官方支持站点 MOS 上，最近发布了两篇告警文章，引发了用户的广泛关注，这两篇文章分别是：

• Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)
• Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)

简单翻译一下就是：

2361478.1：在 2019年 4月前，Oracle 数据库需要更新到的最小 Patchset/PSU/RU 补丁；

2335265.1：使用 DB Link 的数据库，11.2.0.3 及之前版本必须应用的补丁

这两篇文章引发了用户的广泛关注，尤其是针对标题中使用的"Mandatory - 必须的"和"Before April 2019 - 在2019年4月之前"。

我注意到很多用户在问：Oracle 是如何让这样的问题在2019年4月后触发的？难道是 Oracle 在数据库中埋下了一个时间触发器？

经过我们的分析，这个时间约束的确存在，但是触发时间是：2019年6月23日。

接下来让我们一步一步来解析一下，在 2361478.1 文档的发布时间里可以看到，这个文档是 2018年2月15日创建发布的,而在 2018年2月16日，Oracle 发布了 Oracle Database 18c 数据库，具体可以参考：Oracle 18c 数据库已经发布和新特性介绍。

所以，这篇文档是随着新版本而发布出来的，这也意味着新版本新特性导致 Oracle 的内部工作原理发生了重要的变化。

我们再来看看这篇文章宣布的内容，以下是关键内容：

What we are announcing（我们宣布的是）：

All supported releases of Oracle Databases need to be patched to a minimum patchset/PSU level before April 2019 to ensure proper functioning of database links.

为确保数据库链正常工作，所有受支持的 Oracle 数据库需要在2019年4月之前修补到的最低 补丁集/ PSU。

影响范围：12.2.0.1及更高版本不受影响，11.2.0.4和12.1.0.2补丁集已经包含了必要的修复，已发布补丁程序可用于11.1.0.7和11.2.0.3版本。 其他版本无补丁，需要升级，否则低版本和新版本的其他库通过 DB Link 连接时可能遇到问题。

那么到底是什么变化引起了这个影响？关键的部分仅有以下一句话的描述：

What is the change introduced by the patches listed above?

The patches listed above make the older databases capable of supporting increased SCN soft limit (i.e. support transactions with higher SCN rate) though the increased SCN soft limit only becomes effective at a later time (after April 2019).

为了允许更高的 SCN 增长率，Oracle 采用了新的 SCN soft limit 机制，补丁修正是使得之前版本能够支持这个新特性。该特性将在2019年4月之后生效，因此建议在11.2.0.4以下版本需要按照官方文档进行补丁升级。

简单来说，也就是 SCN 的算法要改变，最常见的是增长率，低版本和高版本必须保持同样的算法才能确保 DB Link 访问正常。

描述中所说的 Soft Limit 在文档中的描述如下，在 Oracle 11.2.0.2 之前这个限制是 16K：

"At any point in time, the Oracle Database calculates a "not to exceed" limit for the SCN a database can have used, based on the number of seconds elapsed since 1988, multiplied by 16,384. This is known as the 'Soft Limit'. If the soft limit is likely to be exceeded in the next SCN increment then Oracle will issue an ORA-0600 error and the process will be cancelled."

在SCN耗尽的问题出现之后，这个限制提升到32K：

在我的网站上，记录了一篇我在2006年写的文章，通过 DB Link 的查询会同步数据库的 SCN，也就是这个原理导致了后来很多 SCN 耗尽的 Headroom 问题：

[oracle@jumper oracle]$ sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.4.0 - Production on Tue Nov 7 21:07:56 2006
SQL> select dbms_flashback.GET_SYSTEM_CHANGE_NUMBER scn from dual;
       SCN
---------------
   5287824

那么会发生什么样的改变？

在 18c 中已经可以看到一些端倪，这样的新特性被引入：

Consistency Levels for Multi-Shard Queries

You can specify different consistency levels for queries across multiple shards in a sharded database. For example, you might want some queries to avoid the cost of SCN synchronization across shards, and these shards could be globally distributed. Another use case is when you use standbys for replication and slightly stale data is acceptable for cross-shard queries, as the results could be fetched from the primary and its standbys. You can use the initialization parameter MULTISHARD_QUERY_DATA_CONSISTENCY to set different consistency levels when executing multi-shard queries across shards.

This feature enables you to avoid the cost of SCN synchronization while executing multi-shard queries across shards and these shards potentially could be distributed globally.

For multi-shard queries, this feature allows slightly stale data from the standby databases.

翻译过来就是：

多分片查询的一致性级别

您可以为分片数据库中多个分片的查询指定不同的一致性级别。 例如，您可能希望一些查询避免跨分片的 SCN 同步的成本，要知道这些分片可能是全局分布式的。 另一个用例是当您使用备用数据库时，对于跨分片查询可以接受稍陈旧的数据。 在分片上执行多分片查询时，可以使用初始化参数 MULTISHARD_QUERY_DATA_CONSISTENCY 设置不同的一致性级别。

• 通过此功能，您可以在跨分片执行多分片查询时避免 SCN 同步的成本，并且这些分片可能可以全球分发。

• 对于多分片查询，此功能允许从备用数据库稍微陈旧的数据。

这个功能目前是针对 Oracle Sharding 数据库的，也就是说，在跨 Shard 的查询中，可以避免 SCN 同步的成本。

这意味着什么？

• 通过进一步提升 SCN 增长率（超过32K）的上限约束或者避免同步，这可能意味着以前通过 DB Link 的 SCN 传播问题可以被更好的避免。

• 我们预计在 2019年4月，当 Oracle Database 19 版发布时，这些特性会获得全面支持，SCN 将全面摒弃16K 的增长率。

很多客户一直在提问，到底要修正什么 BUG？Oracle 在文档中没有说明，但是提出了最小补丁要求，不同版本的补丁应用矩阵：

那么这个列表中的最小补丁级修正的到底是什么？

经过分析，我们最终确认修复内容就是 BUG 14121009 中的内容，请注意上面列表中 Oracle 要求2019年4月前应用的最小补丁要求，和下图修正 BUG 14121009 的版本是完全相符的。如 11.2.0.3.9 、11.1.0.7.20 、以及 Windows 11.2.0.3 Patch 28、11.1.0.7 Patch 57。

那么这个补丁中到底引入了什么核心特性，改变了 Oracle SCN 的算法？

从说明中我们可以看到 Oracle 引入了一个重要的特性，这个特性就是：

SCN 兼容性特性 SCN Compatibility，而且在这个特性中设置了时间限制。这个特性要求这个补丁应用。

修改数据库 SCN 算法的命令是：

ALTER DATABASE SET SCN COMPATIBILITY.

严正警告：请不要在你的任何重要环境中进行测试，后果自负。

兼容性特性有4个选项，可以修改为：1、2、3 。

SQL> ALTER DATABASE SET SCN COMPATIBILITY 2;

Database altered.

SQL> ALTER DATABASE SET SCN COMPATIBILITY 3;

Database altered.

SCN 算法向小值修改时，数据库需要重新启动：

那么最后的关键是，这一切到底和时间有什么关系？

经过我们的分析，得出的结论是：Oracle 为每个 SCN 的兼容性设置了时间点，也就是说，低级别的兼容性将在一定的时间后自动过期，所有的修正数据库都将在2019年6月23日直接跳级到兼容性 3 。3 级允许更高的 SCN 增长率，16K 将过时，32K 将可以被超越。所以可以预期，如果你的旧数据库不升级，连接 3 级兼容性的数据库，可能立刻就超出 SCN 的限制，访问被拒绝出错。

这一切就是因为在内核中，Oracle 引入了一个：Auto-RollOver 的特性，也就是说Oracle 为不同 SCN 的增长率设定了时间，自动过期，随着时间推移，用户会不知不觉的过度到新的 SCN 算法上来。

你可以通过 DBMS_SCN 包获得这些内部信息，我感觉数据库中被埋了一个定时炸弹，滴答滴答。。。

-- effective_auto_rollover_ts - timestamp at which rollover becomes effective

-- target_compat - SCN compatibility value this database

-- will move to, as a result of auto-rollover

-- is_enabled - TRUE if auto-rollover feature is currently enabled

Oracle 在警告中之所以提示提示 2019年4月，我想是给用户留出了84天的余量。

基于以上分析，一些常见问题的答案是显然的：

1. 如果我是低版本之间的访问，一定会出问题吗？

   不会，如果都是未应用补丁的低版本数据库互访，不会出现问题；但是如果是未应用补丁的低版本和应用了补丁的高版本之间互访，就可能出问题。

2. 如果低版本和高版本互访，在2019年4月之后一定会出问题吗？

   不一定，跨 DB Link 的访问不一定会出现问题，尤其是 SCN 的增长率维持低位的数据库；但是由于算法的改变，很可能会出现问题，而且概率很高；

3. 为什么引入这样的修改和补丁？

   因为 SCN 是 Oracle 的核心机制，过去遇到的 Headroom问题必须获得彻底消除，所以算法需要调整，这是非常核心的改变。

4. 我们是否需要打补丁？

如果数据库全部维持在低版本，或者不通过 DB Link 互访，则无所谓; Oracle 也提供禁用该特性的功能，但是不保证之后不改变；鉴于11.2.0.4以下版本都属于不支持版本，强烈建议用户升级。

那么如果出现问题，会是什么样子的？在 MOS 上文档 1393360.1中，就有各种已知的描述，如果低版本的数据库 SCN 不能抬升，那么就可能遭遇：ORA-19706: invalid SCN 的错误。

Rejected the attempt to advance SCN over limit by 9374 hours worth to 0x0c00.00000f66, by distributed transaction remote logon, remote DB: REMDB.XX.ORACLE.COM.

Client info : DB logon user ME, machine yy, program sqlplus@yy (TNS V1-V3), and OS user uuu

事实上，在这个文档的最后部分已经揭示了关于 SCN 新特性的变化，在新版本中，SCN 的增长率完全可以变成动态调节：

Warning: The SCN intrinsic growth rate has been consistently

higher than system default 16384 per sec. for last 60 mins.

Current SCN intrinsic growth rate is 24416 per sec., zas 7fffff!

The Current SCN value is 3354492471, SCN Compat value is 1

如果在此问题上需要进一步的协助，请联系云和恩墨的技术团队，更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。

相关阅读：

安全警报：Oracle 2018一月号安全补丁修复由来已久安全漏洞

安全警告：未修复WebLogic WSAT组件RCE漏洞挖矿程序攻击

相关文章|Related Articles

• Oracle全面修正了关于DB Link和SCN补丁的公告
  
• SCN 新算法：DBMS_SCN的用法及范例
  
• Oracle 11g在补丁修正中引入DBMS_SCN包及新特性
  
• 解决方案：Oracle的DB Link问题及2019年4月升级路线详述
  
• Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性
  

作者：eygle 发布在 eygle.com

在之前的文章中，我们详细描述了：揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级 。

在以下我简要引用一下Oracle官方的声明，提醒大家务必认真分析，制定必要的应对策略。

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)

适用版本:

Oracle Database - Personal Edition - Version 9.2.0.1 and later
Oracle Database - Standard Edition - Version 9.2.0.1 and later
Oracle Database - Enterprise Edition - Version 9.2.0.1 and later
Information in this document applies to any platform.

描述

What we are announcing

All supported releases of Oracle Databases need to be patched to a minimum patchset/PSU level before April 2019 to ensure proper functioning of database links.

This note only applies to Database Server installations and the interoperability of database clients with database servers is not impacted by this patch.

What action you need to take

For all database releases prior to 12.2.0.1, ensure that all interconnected databases are in the below mentioned patchset/ PSU/BP levels or above:

In summary, 12.2.0.1 and higher releases, 11.2.0.4 and 12.1.0.2 patchsets have this fix included, while patches are available for 11.1.0.7 and 11.2.0.3 releases. If you have any other database server installations (e.g. 10.2.0.5, 11.2.0.2), you should upgrade such databases if you would like the older databases to continue using database links with newer versions of databases.

What is the change introduced by the patches listed above?

The patches listed above make the older databases capable of supporting increased SCN soft limit (i.e. support transactions with higher SCN rate) though the increased SCN soft limit only becomes effective at a later time (after April 2019).

Timelines

All databases should be at the above mentioned release/patchset/ PSU/BP levels (or above) before April 2019.

Support and Questions

If you have any queries please post them in the Database community page: https://community.oracle.com/message/14710245#14710245

OCCURRENCE

Applicable to all Oracle database releases prior to 12.2.0.1

症状

Database Links might fail or encounter errors

WORKAROUND

None

PATCHES

Please refer the table Minimum Required PSU/RU above.

发布历史

Added details regarding the change: 9-Mar-2018

Corrected the hyperlinks and information related to 11.2.0.3.29 (windows) : 7-Mar-2018

Created: 15-Feb-2018

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)

适用版本:

Oracle Database - Enterprise Edition - Version 11.1.0.7 to 12.2.0.1 [Release 11.1 to 12.2]
Oracle Database - Standard Edition - Version 11.1.0.7 to 12.2.0.1 [Release 11.1 to 12.2]
Information in this document applies to any platform.

目标

This support note provides additional info related to mandatory patching/upgrade of all supported releases of Oracle Databases to a minimum patchset/PSU level before April 2019.

SCOPE

The document is intended for all DBAs.

DETAILS

All supported releases of Oracle Databases need to be patched to a minimum patchset/PSU level before April 2019 to ensure proper functioning of database links. This note only applies to Database Server installations and the interoperability of database clients with database servers is not impacted by this patch.

1. What are the minimum recommended patchset/PSU/BP/RU levels?

For all database releases prior to 12.2.0.1, ensure that all interconnected databases are in the below mentioned patchset/ PSU/BP levels or above:

In summary, 12.2.0.1 and higher releases, 11.2.0.4 and 12.1.0.2 patchsets have this fix included, while patches are available for 11.1.0.7 and 11.2.0.3 releases. If you have any other database server installations (e.g. 10.2.0.5, 11.2.0.2), you should upgrade such databases if you would like the older databases to continue using database links with newer versions of databases.

Patching the older versions is mandatory *only* if you want to have a db link connection to a latest release or patched database.

2. What is the timeline for moving to the minimum recommended patchset/PSU/BP mentioned?

All databases should be at the above mentioned release/patchset/ PSU/BP levels (or above) before April 2019.

3. What is the change introduced by the patches listed above?

The patches listed above make the older databases capable of supporting increased SCN soft limit (i.e. support transactions with higher SCN rate) though the increased SCN soft limit only becomes effective at a later time (after April 2019).

4. What happens if the mandatory PSU / patchset is not applied?

If either the source or target database using database links is not patched/upgraded to the right patchset/PSU level, you may get run-time errors during database link operations after April 2019. In order to resolve the errors, you would immediately need to patch/upgrade the databases.

5. What about databases that are 10.2 or older, which are not listed in the table?

Please ensure that you don't have any database link (incoming or outgoing) between earlier versions of databases (e.g. 10.2) and the database releases/patches mentioned in this document (Under Sec 1. What are the minimum recommended patchset/PSU/BP/RU levels? ) as we don't plan to release patches for those unsupported versions of databases. If you continue to have such database links after April 2019, you may get run-time errors during database link operations and you would need to disconnect those database links at that time.

6. How can I check the details regarding the dblinks to and from a database?

In order to identify database links, please review "Viewing Information About database Links" in Database Administrator's guide.

Please note that outgoing db links from a database can be identified via DBA_DB_LINKS view for all database releases.

For 12.1 and later releases, you can also find out about incoming database links via DBA_DB_LINK_SOURCES view.

7. Will there be any issues with the db links connecting two unpatched databases ? Or databases of older versions?

The dblink connections involving two unpatched databases or two older releases are not directly affected by this change. Having said that, we do recommend to apply the patches or upgrade the database as per the table above. The patches listed above are recommended inline with the features available in the future releases.

8. Will the dblinks involving a patched and an unpatched database, stop working immediately after April 2019?

DB Links won't become unusable immediately after April 2019. But might encounter errors (for some cases) at any point of time, after April 2019.

9. What should I do, if the dblink connection from an older version database to a latest (or patched) version database fails, after April 2019?

Upgrade the older version database to any patch level mentioned in the table - Mandatory patch levels.

10. What do we need to do for 11.2.0.4, 12.1.0.2 and 12.2.0.1 database releases?

No action is necessary. All the fixes needed are already included in these releases.

相关文章|Related Articles

作者：eygle 发布在 eygle.com

在之前的文章中，我们阐述了"预警揭秘：倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相"，很多读者提出了很多问题，我们在此进一步的补充和介绍一点基础知识，并给出解决方案。

我们整理了检查SCN的脚本 scnhealthcheck.sql 和文中用到的脚本，以及几篇文章的PDF版本，关注本公众号（ OraNews）回复：SCNCOMP ，你可以找到下载链接。

这个问题严重吗？

我想首先回答一下这个问题，可能很多人心存疑惑，这个问题严重吗？有多严重？会影响到我吗？

首先，我们分析这个问题的起因就是因为Oracle用了空前严重的措辞，11.2.0.3 及以前版本，使用DB Link的，在2019年4月前必须应用到推荐的补丁。

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)

这个警告是非常严重的。

如果经历过 2011 - 2013 年左右，通宵达旦升级 SCN 补丁的DBA都会心有余悸、印象深刻，如果数据库的 SCN 接近极限，则数据库就可能频繁出错，最坏的情况是事务都执行不了，数据库停顿。由于SCN不可以重置，严重情况甚至要重建数据库。

所以和 SCN 相关的问题，都是很严重的问题。遇到这类问题的症状参考：SCN、ORA-19706错误和内部参数。

但是注意，严重的问题不一定会影响所有客户，最容易遭遇问题的是，事务频繁、交易频繁、压力大的数据库，这类系统SCN增长快，Headroom紧张，对于空闲度高、事务率低的系统基本上没有什么事（除非杯具的遇到BUG），这一类的系统无需过度忧虑。

还要一个大前提，如果你不用 DB Link，这个事情就和你一点关系都没有，可以安全的忽略之！

但是不要误会：低版本、不用DB Link并不意味着你不会遇到SCN的 ORA-19706错误，你的数据库如果有SCN增长过快的问题，同样会中止服务（用 scnhealthcheck 脚本可以进行检查）。只是没有办法使用新特性的增强解决方案，Oracle 致力于解决的就是跨DB Link的SCN拉平导致的各种异常。

简单来说，影响的是 SCN算法，SCN 是数据库内部的时钟。

Oracle设置了倒计时，在 2019年6月23日，自动启用 3 级兼容性，提升SCN的可用量。

也彻底废弃 16K/s 的增长率，提升到 96K/s 的增长率，目标是让数据库支持的变化更多，承载能力更强，这是进步。但是注意：即便都升级到高版本并且到2019年自动过度到 3 级兼容性，SCN 越界的ORA-19706问题仍然可能会遇到。

SCN新算法兼容性有四个级别，是为了让SCN的可用量更多而已，级别可设置的是 1，2，3，将要自动进化到的就是 3 级。下表我们绘制了兼容性曲线，可以看到 RSL 3 的SCN可用空间获得了大幅度提升。

当然你可以通过禁用这个自动过度，让数据库SCN维持在以前的增长率上。

在 DBMS_SCN 的工具包里提供了 DISABLEAUTOROLLOVER 和

ENABLEAUTOROLLOVER 的过程。

并且 Oracle 修改了 SCN 起点的算法从 1998 年 推进到 2008 年。时代已然改变。具体请各位向下看详细描述的技术内容。

如果您还觉得有点复杂，在我们免费的SaaS产品 Bethune 中，已经全面提供了关于 SCN 和 DB Link 的检测和可视化输出，够体贴吗？

网址是： https://bethune.enmotech.com

以下是关于 SCN 和 Headroom 的检查：

下图是DB Link的安全检查和图谱：

不要犹豫，云和恩墨 免费、优雅又好用的产品工具等着你。

首先，关于补丁，比如很多朋友问 10.2.0.5 有没有补丁，请看下图，目前Oracle在支持的最低版本是11g。而且 11.2.0.4 将在 2019年1月1日进入扩展支持期（Extended Support），也就是必须要有支持合同才为用户提供补丁，不对外公开发布补丁了。所以，所有 10g 的版本，已经没有补丁了。例外的是 11.1.0.7 和 11.2.0.3 有补丁。所以这个问题应该清楚了。

版本升级路线如下：

豁免版本：11.2.0.4 和 12.1.0.2 及以上版本，已然自带加持；

10g 版本：你可以选择升级到 11g 或者 12c；

11.1版本：你可以选择升级到11.1.0.7 版本，应用补丁；

11.2版本：你可以选择升级到11.2.0.3 版本，应用补丁；

12.1版本：你至少升级到 12.1.0.2.0 版本；

关于这个DB Link 问题的影响，简要再总结一下：

1. 首先定义一下高版本：就是 11.2.0.4 和 12.1.0.2 及其以上版本，和打过补丁的 11.1.0.7 和 11.2.0.3 版本；
   

2. 再定义一下低版本：不再上述版本中的；

以下几点一目了然：

1. 低版本之间通过DB Link互联，不受影响；

2. 低版本和高版本之间通过DB Link互联，可能受到影响，主要取决于高 SCN 系统的高度；

3. 受影响是因为新版本的 SCN 增长算法改变，可能瞬间抬升低版本的 SCN 至越界；

4. 越界只影响跨 DB Link 的访问，不影响本数据库运行；

5. 如果你的系统SCN都很低，增长也很慢，就基本不用担心，不升级也没有问题；

再明确一下，哪些版本有补丁：

1. 11.2.0.4 和 12.1.0.2 及其以上版本，天然自带加持；

2. 11.1.0.7 和 11.2.0.3 版本有补丁，具体见下图，Windows版本和其他平台不同；

3. 其余版本无补丁；

很多朋友提出了很多问题，在此一一解答如下：

1. SCN的问题和版本有关吗？

   任何版本都可能因为SCN增长过快而遭受SCN拒绝，数据库停顿的问题。高版本在尝试解决（这个修正就是），低版本不予修补。

2. 10g受影响吗？

   受影响没补丁，但是大前提是有DB Link，如果仅仅是低版本之间访问，没有问题（不受SCN算法变动影响，但是自身SCN过高仍然会有问题），低版本和高版本通过DB Link互访，可能有问题。

3. 高版本和其它低版本通过dblink互联就算中标了，还是其它11g版本打了这次的补丁的才算？

   是的，但是仅仅是跨DB Link的SQL失败，高版本数据库本身不受影响。

4. 10.2.0.4和10.2.0.5的RAC受到影响么？

   如第一个问题，这两个版本互访都没有问题，和高版本跨DB Link访问才有风险。

5. 这问题会扩展传播吗，如10.2.0.5连接11.2.0.4，10g被传染，又有个新的10g连接了被传染的10g.会扩散吗？

   会的，SCN问题天然会通过DB Link扩展传播。

6. 我这里用11204连了10g，报scn错了。只能升级吗？很多10g。

   不一定非要升级，只要能够有效控制SCN，不要增长过快，就没有问题。一般来说跳变SCN的源数据库是能够排查和解决的。

下图是昨天网友提出的一个问题，10.2.0.5 的SCN已经接近限制的极限，数据库出现问题，这类数据库根本上要去解决SCN异常增长的问题。这个过程较复杂，云和恩墨技术支持提供协助诊断排查服务。

如何判断我的数据库是否已经应用了这个补丁？

只需要看看是否存在 DBMS_SCN 这个包，如果存在，就意味着已经应用了这个补丁.

通过如下一段代码，就可以查出数据库当前的SCN兼容性和启用时间：

SQL> @scncomp

date:20190623000000, compatiable:3

Auto-rollover is disabled

SQL> exec dbms_scn.ENABLEAUTOROLLOVER;

SQL> @scncomp

date:20190623000000, compatiable:3

Auto-rollover is enabled

SQL> set echo on

SQL> @scncomp

SQL> declare

2 v_date date;

3 v_compat number;

4 v_enable boolean;

5 begin

6 dbms_scn.getscnautorolloverparams(v_date, v_compat, v_enable);

7 dbms_output.put_line('date:' || to_char(v_date, 'yyyymmddhh24miss') || ', compatiable:' || v_compat );

8 if v_enable then

9 dbms_output.put_line('Auto-rollover is enabled');

10 else

11 dbms_output.put_line('Auto-rollover is disabled');

12 end if;

13 end;

14 /

date:20190623000000, compatiable:3

Auto-rollover is enabled

我们再来阐述一下技术问题，有以下几个小知识需要明确：

• SCN 是Oracle数据库的内部时钟，单调递增，不可逆转；

• SCN 在很多情况下会增长，比如Commit，Oracle对这个增长进行控制，最初是允许每秒 16K ；

• 如果通过 DB Link 进行跨数据库访问，基于分布式一致性原理，Oracle会将两个数据库的SCN时钟同步；

• 通过DB Link，SCN低的被拉高，一旦超过数据库的允许限制，就会出错；

了解了这几点，我们可以向下进行了，详细一点说：

SCN(System Change Number) ，也就是通常我们所说的系统改变号，是数据库中非常重要的一个数据结构。

它定义数据库在某个确切时刻提交的版本。在事物提交时，它被赋予一个唯一的标示事物的 SCN 。 SCN 提供 Oracle 的内部时钟机制，可被看作逻辑时钟，这对于恢复操作是至关重要的 （ Oracle 仅根据 SCN 执行恢复）。

Oracle 通过 SCN 来维护数据库的一致性，并通过SCN 实施 Oracle 至关重要的恢复机制。

为什么SCN的增长要进行控制？

这是因为 Oracle 使用了 6 Bytes 记录SCN，也就是48位，不能无限增长用超了就麻烦了。6 Bytes 的最大值是：

SQL> select power(2,48) scn from dual;

SCN

----------------------------

281,474,976,710,656

如果Oracle在内部控制每秒增加的SCN不超过 16K，按照这样计算，这个数值可以使用大约544年：

SQL> select power(2,48) / 16 / 1024 / 3600 / 24 / 365

2 from dual;

POWER(2,48)/16/1024/3600/24/365

-------------------------------

544.770078

SCN算法是以1988年1月1日 00点00时00分开始，每秒计算1个点数，有了16K的限制，一个数据库当前最大的可能SCN被称为"最大合理SCN"，该值可以通过如下方式计算：

col scn for 999,999,999,999,999,999

select

(

(

(

(

(

(

to_char(sysdate,'YYYY')-1988

)*12+

to_char(sysdate,'mm')-1

)*31+to_char(sysdate,'dd')-1

)*24+to_char(sysdate,'hh24')

)*60+to_char(sysdate,'mi')

)*60+to_char(sysdate,'ss')

) * to_number('ffff','XXXXXXXX')/4 scn

from dual

/

后来由于 SCN 因为种种原因增长越来越快，Oracle 不得不放宽约束，也就有了参数 _max_reasonable_scn_rate ，增长率从 16k 放宽到 32k，现在看起来，在即将启用的特性中，将进一步放宽到 96K。

那么在 96K 的约束之下，SCN 的存储空间，可以使用 90 年。所以有朋友问，是否SCN加位扩展了，事实上并没有：

SQL> select power(2,48) / 96 / 1024 / 3600 / 24 / 365

from dual;

POWER(2,48)/96/1024/3600/24/365

-------------------------------

90.795013

但是注意，还有一个好问题，为什么要选择 1988年 作为起点呢？这个起点可以修改吗？

当然，在新的算法中，Oracle改变了 SCN 算法的起点值，在32K和96K的增长率下，起点分别近似调整为：

2：~ 1998/07/01
3： ~ 2008/03/30

这也可算作起征点调整吧，所以经过调整最大支持到大约 2097年（极限不稳定值 Oracle 最高可以用到 2105 年），你可能会问，那到了2097年怎么办？这个，呵呵。。。

我们再来阐述一下技术问题，有以下几个小知识需要明确：

此外，昨天的文章我们提到，如果出现问题，你可能看到的提示或者错误。这一部分必须要补充完整。

新的提示大约类似如下这些，我就不一一翻译了，大家可以看到主要是提示用户SCN的兼容性版本发生改变，基于自动的Rollover特性，这些关键字在未来不要奇怪：

• Database SCN compatibility changed from %d to %d due to auto-rollover

• Warning - High Database SCN: Current SCN value is %s, threshold SCN value is %s

• If you have not previously reported this warning on this database, please notify Oracle Support so that additional diagnosis can be performed.

• Database SCN compatibility auto-rollover - control file update

• ALTER DATABASE SET SCN COMPATIBILITY : setting compatibility to %d does not allow sufficient headroom

• Parameter value %s is invalid for _external_scn_rejection_delta_threshold_minutes

• Database SCN compatibility auto-rollover enabled

• Database SCN compatibility auto-rollover disabled

• Initializing SCN for created control file

• Database SCN compatibility initialized to %d

• Warning: The SCN headroom for this database is only %d hours!

• Warning: The SCN headroom for this database is only %d days!

• SCN compatibility auto-rollover is disabled

• SCN compatibility changed from %d to %d (auto-rollover)

关于 SCN 有很多有意思的变化，大家一起来探索吧！

相关阅读：

SCN、ORA-19706错误和内部参数

深入剖析：Oracle SCN 机制详解

预警揭秘：11.2.0.4前版必须在2019年4月升级

安全警报：2018一月号安全补丁修复安全漏洞

安全警告：WebLogic WSAT组件漏洞挖矿程序攻击

如果在此问题上需要进一步的协助，请联系云和恩墨的技术团队，更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。

相关文章|Related Articles

• Oracle全面修正了关于DB Link和SCN补丁的公告
  
• SCN 新算法：DBMS_SCN的用法及范例
  
• Oracle 11g在补丁修正中引入DBMS_SCN包及新特性
  
• 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级
  
• Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性
  

作者：eygle 发布在 eygle.com

DBMS_SCN 的Package是在 11.2.0.3.9 中引入，在Opatch应用补丁的过程中，可以观察到这个执行过程。

整个Package 由两个源码文件组成，分别是：dbmsscnc.sql 和 prvtscnc.plb 。后者是加密Wrap过的代码。

以下引用了补丁修正安装后的代码执行过程，作为参考：

$ opatch napply -oh $ORACLE_HOME -local /u01/app/oracle/patch/17540582
Oracle 中间补丁程序安装程序版本 11.2.0.3.5
版权所有 (c) 2013, Oracle Corporation。保留所有权利。
Oracle Home       : /u01/app/oracle/product/11.2.0.3/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/11.2.0.3/db_1/oraInst.loc
OPatch version    : 11.2.0.3.5
OUI version       : 11.2.0.3.0
Log file location : /u01/app/oracle/product/11.2.0.3/db_1/cfgtoollogs/opatch/opatch2015-01-10_11-12-31上午_1.log

Verifying environment and performing prerequisite checks...
OPatch continues with these patches:   17540582  

是否继续? [y|n]
y
User Responded with: Y
All checks passed.
请关闭本地系统上在此 ORACLE_HOME 之外运行的 Oracle 实例。
(Oracle 主目录 = '/u01/app/oracle/product/11.2.0.3/db_1')

本地系统是否已准备打补丁? [y|n]
y
User Responded with: Y
Backing up files...
Applying sub-patch '17540582' to OH '/u01/app/oracle/product/11.2.0.3/db_1'
ApplySession: Oracle 主目录中不存在可选组件 [ oracle.precomp.lang, 11.2.0.3.0 ] , 或找到更高版本。


正在为组件 oracle.rdbms, 11.2.0.3.0 打补丁...
正在为组件 oracle.rdbms.rsf, 11.2.0.3.0 打补丁...
正在为组件 oracle.sdo, 11.2.0.3.0 打补丁...
正在为组件 oracle.ldap.rsf, 11.2.0.3.0 打补丁...
正在为组件 oracle.precomp.common, 11.2.0.3.0 打补丁...
正在为组件 oracle.ordim.client, 11.2.0.3.0 打补丁...
正在为组件 oracle.rdbms.util, 11.2.0.3.0 打补丁...
正在为组件 oracle.rdbms.dbscripts, 11.2.0.3.0 打补丁...
正在为组件 oracle.sdo.locator, 11.2.0.3.0 打补丁...
正在为组件 oracle.rdbms.rman, 11.2.0.3.0 打补丁...
正在为组件 oracle.ordim.jai, 11.2.0.3.0 打补丁...
Verifying the update...
Composite patch 17540582 successfully applie
查看更新的结果
$ opatch lspatches
17540582;Database Patch Set Update : 11.2.0.3.9 (17540582)
查看更新补丁的内容
$ opatch lsinventory
Oracle 中间补丁程序安装程序版本 11.2.0.3.5
版权所有 (c) 2013, Oracle Corporation。保留所有权利。
Oracle Home       : /u01/app/oracle/product/11.2.0.3/db_1
Central Inventory : /u01/app/oraInventory
   from           : /u01/app/oracle/product/11.2.0.3/db_1/oraInst.loc
OPatch version    : 11.2.0.3.5
OUI version       : 11.2.0.3.0
Log file location : /u01/app/oracle/product/11.2.0.3/db_1/cfgtoollogs/opatch/opatch2015-01-10_11-12-31上午_1.log
Lsinventory Output file location : /u01/app/oracle/product/11.2.0.3/db_1/cfgtoollogs/opatch/lsinv/lsinventory2015-01-10_11-12-31上午_1.txt

--------------------------------------------------------------------------------
已安装的顶级产品 (1):
Oracle Database 11g                                                  11.2.0.3.0
此 Oracle 主目录中已安装 1 个产品。

中间补丁程序 (1) :

Patch  17540582     : applied on Thu Feb 20 11:33:06 CST 2014
Unique Patch ID:  16985511
Patch description:  "Database Patch Set Update : 11.2.0.3.9 (17540582)"
   Created on 7 Jan 2014, 03:01:22 hrs PST8PDT
Sub-patch  16902043; "Database Patch Set Update : 11.2.0.3.8 (16902043)"
Sub-patch  16619892; "Database Patch Set Update : 11.2.0.3.7 (16619892)"
Sub-patch  16056266; "Database Patch Set Update : 11.2.0.3.6 (16056266)"
Sub-patch  14727310; "Database Patch Set Update : 11.2.0.3.5 (14727310)"
Sub-patch  14275605; "Database Patch Set Update : 11.2.0.3.4 (14275605)"
Sub-patch  13923374; "Database Patch Set Update : 11.2.0.3.3 (13923374)"
Sub-patch  13696216; "Database Patch Set Update : 11.2.0.3.2 (13696216)"
Sub-patch  13343438; "Database Patch Set Update : 11.2.0.3.1 (13343438)"
   Bugs fixed:
     13593999, 10350832, 14138130, 12919564, 13561951, 14198511, 13588248
     13080778, 13804294, 16710324, 12873183, 14472647, 12880299, 13369579
     14409183, 13492735, 12857027, 13496884, 14263036, 14263073, 13015379
     16038929, 17748833, 16563678, 13732226, 13866822, 13742434, 13944971
     12950644, 17748831, 12899768, 13063120, 13958038, 14613900, 13972394
     11877623, 17088068, 13072654, 12395918, 13814739, 17343514, 13649031
     13981051, 12797765, 17333200, 12923168, 16761566, 16279401, 13384182
     13466801, 15996344, 14207163, 13724193, 13642044, 11063191, 13945708
     12797420, 12865902, 15869211, 13041324, 14003090, 16314468, 16019955
     11708510, 14637368, 13026410, 13737746, 13742438, 15841373, 16347904
     15910002, 16362358, 14398795, 13579992, 16344871, 10400244, 14275605
     13742436, 9858539, 14841812, 16338983, 9703627, 13483354, 14207317
     14393728, 12764337, 16902043, 14459552, 14191508, 12964067, 12780983
     12583611, 14383007, 14546575, 15862016, 13476583, 13489024, 17748830
     14088346, 13448206, 16314466, 13419660, 14110275, 13430938, 13467683
     14548763, 12834027, 13632809, 13377816, 13036331, 14727310, 16175381
     13584130, 12829021, 15862019, 12794305, 14546673, 12791981, 13787482
     13503598, 10133521, 12744759, 13399435, 13553883, 14023636, 14762511
     9095696, 14343501, 13860201, 13257247, 14176879, 16014985, 12312133
     14480675, 16306019, 13559697, 9706792, 12974860, 12940620, 13098318
     13773133, 15883525, 16794244, 13340388, 13366202, 13528551, 12894807
     12747437, 13454210, 12748240, 13385346, 15987992, 13923995, 13582702
     14571027, 12784406, 13907462, 13493847, 13857111, 13035804, 16710363
     13544396, 14128555, 8547978, 14226599, 17478415, 17333197, 9397635
     14007968, 12925089, 12693626, 14189694, 12815057, 17761775, 16721594
     13332439, 14038787, 11071989, 14207902, 14062796, 12913474, 14390252
     16314470, 13370330, 14062794, 13358781, 17333202, 12960925, 9659614
     14546638, 13699124, 13936424, 9797851, 14301592, 16794240, 13338048
     12938841, 12620823, 12656535, 12678920, 14488943, 16850197, 14791477
     14062792, 13807411, 16794238, 15862022, 12594032, 13250244, 9761357
     12612118, 14053457, 13527323, 10625145, 15862020, 13910420, 12780098
     13696216, 10263668, 14841558, 16794242, 16944698, 15862023, 16056266
     13834065, 14351566, 13723052, 13011409, 14063280, 13566938, 13737888
     13624984, 16024441, 17333199, 13914613, 17540582, 14258925, 14222403
     14755945, 13645875, 12571991, 14664355, 12998795, 13719081, 14469008
     14188650, 17019974, 13742433, 16368108, 16314469, 12905058, 6690853
     16212405, 12849688, 13742435, 13464002, 13534412, 12879027, 12585543
     13790109, 12535346, 16382448, 12588744, 13916549, 13786142, 12847466
     13855490, 13551402, 12582664, 14262913, 17332800, 14695377, 12912137
     13612575, 13484963, 14163397, 17437634, 13772618, 16694777, 13070939
     14369664, 12391034, 13605839, 16314467, 16279211, 12976376, 12755231
     13680405, 14589750, 13742437, 14318397, 11868640, 14644185, 13326736
     13596521, 13001379, 12898558, 17752121, 13099577, 9873405, 16372203
     16344758, 11715084, 16231699, 9547706, 14040433, 12662040, 12617123
     17748832, 16530565, 12845115, 16844086, 17748834, 13354082, 13397104
     13913630, 16462834, 12983611, 13550185, 13810393, 14121009, 13065099
     11840910, 13903046, 15862017, 13572659, 16294378, 13718279, 13657605
     14480676, 13632717, 14668670, 14063281, 13420224, 13812031, 16299830
     12646784, 14512189, 12755116, 13616375, 17230530, 14035825, 13427062
     12861463, 13092220, 15862021, 13043012, 16619892, 13685544, 15862018
     13499128, 13561750, 12718090, 13848402, 13725395, 12401111, 12796518
     13362079, 12917230, 13042639, 13923374, 14220725, 12621588, 13524899
     14751895, 14480674, 13916709, 14076523, 15905421, 12731940, 13343438
     14205448, 17748835, 14127231, 17082364, 15853081, 14273397, 16844448
     14467061, 12971775, 16864562, 14497307, 12748538, 10242202, 14230270
     16382353, 13686047, 14095982, 17333203, 13591624, 14523004, 13440516
     16794241, 14062795, 13035360, 13040943, 13843646, 16794243, 14841409
     13059165, 14062797, 12959852, 12345082, 16703112, 13890080, 17333198
     16450169, 12658411, 13780035, 14062793, 13038684, 16742095, 13742464
     14052474, 13060271, 13911821, 13457582, 7509451, 13791364, 12821418
     13502183, 13705338, 16794239, 15862024, 13554409, 13645917, 13103913, 12772404
--------------------------------------------------------------------------------
OPatch succeeded.
数据库启动，并加载修改SQL Files到数据库
enmo@oracle> @?/rdbms/admin/catbundle.sql psu apply

PL/SQL procedure successfully completed.

Function created.

PL/SQL procedure successfully completed.


PL/SQL procedure successfully completed.


Generating apply and rollback scripts...
Check the following file for errors:
/u01/app/oracle/cfgtoollogs/catbundle/catbundle_PSU_ENMO_GENERATE_2014Feb20_11_42_25.log
Apply script: /u01/app/oracle/product/11.2.0.3/db_1/rdbms/admin/catbundle_PSU_APPLY.sql
Rollback script: /u01/app/oracle/product/11.2.0.3/db_1/rdbms/admin/catbundle_PSU_ROLLBACK.sql


PL/SQL procedure successfully completed.


Executing script file...


enmo@oracle> COLUMN spool_file NEW_VALUE spool_file NOPRINT
enmo@oracle> SELECT '/u01/app/oracle/cfgtoollogs/catbundle/' || 'catbundle_PSU_' || name 
|| '_APPLY_' || TO_CHAR(SYSDATE, 'YYYYMonDD_hh24_mi_ss', 'NLS_DATE_LANGUAGE=''AMERICAN''')
|| '.log' AS spool_file FROM v$database;


enmo@oracle> SPOOL &spool_file
enmo@oracle> exec sys.dbms_registry.set_session_namespace('SERVER')


PL/SQL procedure successfully completed.


enmo@oracle> PROMPT Skipping EM Repository because it is not installed or versions mismatch...
Skipping EM Repository because it is not installed or versions mismatch...
enmo@oracle> PROMPT Processing Oracle Database Packages and Types...
Processing Oracle Database Packages and Types...
enmo@oracle> ALTER SESSION SET current_schema = sys;


Session altered.


enmo@oracle> @?/rdbms/admin/dbmsscnc.sql
enmo@oracle> Rem
enmo@oracle> Rem $Header: rdbms/admin/dbmsscnc.sql /st_rdbms_11.2.0.3.0dbpsu/1 2013/11/06 04:17:31 mtiwary Exp $
enmo@oracle> Rem
enmo@oracle> Rem dbmsscn.sql
enmo@oracle> Rem
enmo@oracle> Rem Copyright (c) 2012, 2013, Oracle and/or its affiliates.
enmo@oracle> Rem All rights reserved.
enmo@oracle> Rem
enmo@oracle> Rem    NAME
enmo@oracle> Rem      dbmsscnc.sql - dbms_scn package definition
enmo@oracle> Rem
enmo@oracle> Rem    DESCRIPTION
enmo@oracle> Rem      
enmo@oracle> Rem
enmo@oracle> Rem    NOTES
enmo@oracle> Rem      
enmo@oracle> Rem
enmo@oracle> Rem    MODIFIED   (MM/DD/YY)
enmo@oracle> Rem    mtiwary     05/26/12 - Declarations and definitions related to DBMS_SCN
enmo@oracle> Rem                           package.
enmo@oracle> Rem    mtiwary     05/26/12 - Created
enmo@oracle> Rem
enmo@oracle> 
enmo@oracle> Rem
enmo@oracle> Rem    BEGIN SQL_FILE_METADATA
enmo@oracle> Rem    SQL_SOURCE_FILE: rdbms/admin/dbmsscn.sql
enmo@oracle> Rem    SQL_SHIPPED_FILE:
enmo@oracle> Rem    SQL_PHASE:
enmo@oracle> Rem    SQL_STARTUP_MODE: NORMAL
enmo@oracle> Rem    SQL_IGNORABLE_ERRORS: NONE
enmo@oracle> Rem    SQL_CALLING_FILE:
enmo@oracle> Rem    END SQL_FILE_METADATA
enmo@oracle> 
enmo@oracle> SET ECHO ON
enmo@oracle> SET FEEDBACK 1
enmo@oracle> SET NUMWIDTH 10
enmo@oracle> SET LINESIZE 80
enmo@oracle> SET TRIMSPOOL ON
enmo@oracle> SET TAB OFF
enmo@oracle> SET PAGESIZE 100
enmo@oracle> 
enmo@oracle> CREATE OR REPLACE LIBRARY DBMS_SCN_LIB TRUSTED AS STATIC;
  2  /


Library created.


enmo@oracle> 
enmo@oracle> CREATE OR REPLACE PACKAGE DBMS_SCN AUTHID CURRENT_USER IS
  2  
  3  DBMS_SCN_API_MAJOR_VERSION  CONSTANT NUMBER := 1;
  4  DBMS_SCN_API_MINOR_VERSION  CONSTANT NUMBER := 0;
  5  
  6  PROCEDURE GetCurrentSCNParams(
  7                  rsl      OUT number,
  8                  headroom_in_scn OUT number,
  9                  headroom_in_sec OUT number,
 10                  cur_scn_compat OUT number,
 11                  max_scn_compat OUT number);
 12  
 13  --      Currently no exceptions are thrown.
 14  --      rsl             - Reasonable SCN Limit as of 'now'
 15  --      headroom_in_scn - Difference between current SCN and RSL
 16  --      headroom_in_sec - number of seconds it would take to reach RSL
 17  --                        assuming a constant SCN consumption rate associated
 18  --                        with current SCN compatibility level
 19  --      cur_scn_compat  - current value of SCN compatibility
 20  --      max_scn_compat  - max value of SCN compatibility this database
 21  --                        understands
 22  
 23  FUNCTION GetSCNParamsByCompat(
 24                  compat IN number,
 25                  rsl           OUT number,
 26                  headroom_in_scn OUT number,
 27                  headroom_in_sec OUT number
 28           ) RETURN boolean;
 29  
 30  --     compat           -- SCN compatibility value
 31  --     rsl              -- Reasonable SCN Limit
 32  --     headroom_in_scn  -- Difference between current SCN and RSL
 33  --     headroom_in_sec  -- number of seconds it would take to reach RSL
 34  --                         assuming a constant SCN consumption rate associated
 35  --                         with specified database SCN compatibility
 36  --
 37  --     Returns False if 'compat' parameter value is invalid, and OUT parameters
 38  --     are not updated.
 39  
 40  PROCEDURE GetSCNAutoRolloverParams(
 41                  effective_auto_rollover_ts OUT DATE,
 42                  target_compat OUT number,
 43                  is_enabled OUT boolean);
 44  
 45  --      effective_auto_rollover_ts  - timestamp at which rollover becomes
 46  --                                    effective
 47  --      target_compat               - SCN compatibility value this database
 48  --                                    will move to, as a result of
 49  --                                    auto-rollover
 50  --      is_enabled                  - TRUE if auto-rollover feature is
 51  --                                    currently enabled
 52  
 53  PROCEDURE EnableAutoRollover;
 54  
 55  PROCEDURE DisableAutoRollover;
 56  
 57  END DBMS_SCN;
 58  /


Package created.


enmo@oracle> 
enmo@oracle> @?/rdbms/admin/prvtscnc.plb
enmo@oracle> SET ECHO ON
enmo@oracle> SET FEEDBACK 1
enmo@oracle> SET NUMWIDTH 10
enmo@oracle> SET LINESIZE 80
enmo@oracle> SET TRIMSPOOL ON
enmo@oracle> SET TAB OFF
enmo@oracle> SET PAGESIZE 100
enmo@oracle> CREATE OR REPLACE PACKAGE BODY DBMS_SCN wrapped
  2  a000000
  3  1
  4  abcd
  5  abcd
  6  abcd
  7  abcd
  8  abcd
  9  abcd
 10  abcd
 11  abcd
 12  abcd
 13  abcd
 14  abcd
 15  abcd
 16  abcd
 17  abcd
 18  abcd
 19  b
 20  6c0 243
 21  QlmAiY1dAl0ShRRHlX+HGNAfF7Mwgw23ACAVfC9A2k7VVhtmMilHXbSA4+y0szHoAcIlGGvF
 22  LFznjZK7HsiO4405ad7otP6DvBJPmF/CgKv7vWxPthzol8UbWtg5Rsh0bB1IL1o27IiiL4Pp
 23  ghghXIzy7qpN8ZKAqy5GoYTd+NFVjhaAPl79bXMSsYU3kLeYwwq6YrfeYIGtMvJPmD01eYTm
 24  6ZHFbXW65+zhiLyd4n6gFjHiFm8ewsIUlps9n1Qmhi8+HDugSGp5JJUj8nWOq0ENurliNrJN
 25  hU0xgcfHK5K6QfbtOHA/U80YLHmYL19b0SJ/rClUGJ61NxJXZGyQ5KEL4FaSdiRh+mztwHkD
 26  0vUMuhwvNnlpUxmcvWlSy/43x86V3wrQNDQ+u0hWeLus6JG2IndfBYS5uYxgDImhZhepALfL
 27  t71Ti3U3O8u0T7YrCu/D3Cr1ZiWOVQsf/xfYVuerG93+lzkruPtiRdV4U5PReE9tBiwb0r+Z
 28  zwEKhyQwCZo3l/PypHsCJbpX2E6cQwagpSSNihdqCzJce+R5Ek7PZ6VqrwhVeOL4icI=
 29  
 30  /


Package body created.


enmo@oracle> CREATE OR REPLACE PUBLIC SYNONYM dbms_scn FOR sys.dbms_scn;


Synonym created.


enmo@oracle> /


Synonym created.


enmo@oracle> GRANT EXECUTE ON dbms_scn TO PUBLIC;


Grant succeeded.


enmo@oracle> /


Grant succeeded.


enmo@oracle> PROMPT Skipping Oracle Workspace Manager because it is not installed or versions mismatch...
Skipping Oracle Workspace Manager because it is not installed or versions mismatch...
enmo@oracle> PROMPT Skipping Oracle interMedia because it is not installed or versions mismatch...
Skipping Oracle interMedia because it is not installed or versions mismatch...
enmo@oracle> PROMPT Skipping Spatial because it is not installed or versions mismatch...
Skipping Spatial because it is not installed or versions mismatch...
enmo@oracle> ALTER SESSION SET current_schema = SYS;


Session altered.


enmo@oracle> PROMPT Updating registry...
Updating registry...
enmo@oracle> INSERT INTO registry$history
  2    (action_time, action,
  3     namespace, version, id,
  4     bundle_series, comments)
  5  VALUES
  6    (SYSTIMESTAMP, 'APPLY',
  7     SYS_CONTEXT('REGISTRY$CTX','NAMESPACE'),
  8     '11.2.0.3',
  9     9,
 10     'PSU',
 11     'PSU 11.2.0.3.9');


1 row created.


enmo@oracle> COMMIT;


Commit complete.

相关文章|Related Articles

• Oracle全面修正了关于DB Link和SCN补丁的公告
  
• SCN 新算法：DBMS_SCN的用法及范例
  
• 解决方案：Oracle的DB Link问题及2019年4月升级路线详述
  
• 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级
  
• Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性
  

作者：eygle 发布在 eygle.com

前情回顾，请参考之前的文章：

预警揭秘：倒计时炸弹11.2.0.4前版本DB Link必须在2019年4月升级真相

解决方案：Oracle的 DB Link 问题及2019年4月前升级路线详述

Oracle 的 DBMS_SCN 修正以及 SCN 的 auto-rollover 新特性

在 Oracle 官方支持站点 MOS 上，此前关于 DB Link 和 SCN 问题的两篇文章已经更新，发布了更详细的信息，现在这两篇文章的标题已经修改为：

Recommended patches and actions for Oracle databases versions 12.1.0.1, 11.2.0.3 and earlier - before June 2019 (Doc ID 2361478.1)

Recommended patching and actions for Oracle database versions 12.1.0.1, 11.2.0.3 and earlier - before June 2019 (Doc ID 2335265.1)

主要更新反应了2点：

1. 更新时间建议从原来的 2019 年4月，修改为 2019年6月；

2. 必须更新，修改为 推荐补丁应用；

3. 在文章中明确提出了 2019年6月23日这个时间点。

原来这两篇文章的标题是这样子的：

Oracle Databases Need to be Patched to a Minimum Patchset/PSU/RU level before April 2019 (Doc ID 2361478.1)

Mandatory Patching Requirement for Database Versions 11.2.0.3 or Earlier, Using DB Links (Doc ID 2335265.1)

现在大家终于可以松下一口气了，Oracle 开始较为详细的说明这件事，并且将时间延迟到6月份，我以为原来的文章是内部留了一个余量，现在看来是修正了。我们此前也在文章中详述了可选的解决方案，如果不启用新的SCN兼容性3，补丁应用就不是必须的。

在文章中，首次澄清了补丁修正的内容，补充了以下详细的描述，由于我们之前文章已经详细解释了这些内容，在此我只简要的翻译一下好了：

3. What is the change introduced by the patches listed above?

These patches increase the database's current maximum SCN (system change number) limit.

At any point in time, the Oracle Database calculates a "not to exceed" limit for the number of SCNs a database can have used, based on the number of seconds elapsed since 1988. This is known as the database's current maximum SCN limit. Doing this ensures that Oracle Databases will ration SCNs over time, allowing over 500 years of data processing for any Oracle Database.

These recommended patches enable the databases to allow for a higher current maximum SCN limit. The rate at which this limit is calculated can be referred to as the "SCN rate" and these patches help allow higher SCN rates to enable databases to support many times higher transaction rates than earlier releases.

Please note that the patches only increase the max limit but the current SCN is not impacted. So, if all your databases don't have any major change in transaction rate, the current SCN would still remain below the current maximum SCN limit and database links between newer (or patched) and unpatched databases would continue to work. The patches provide the safety measure to ensure that you don't have any issue with dblinks independent of any possible future change in your transaction rate.

请注意，这个补丁仅仅是增加了最大的SCN限制，所以如果你的数据库在事务率方面没有改变，或者事务率不高，当前的SCN将维持在最大SCN限制以下，在旧版本和新版本之间的DB link也可能毫无问题。

With the patches applied, this change in current maximum SCN limit will happen automatically starting 23rd June 2019.

如果应用了补丁，SCN 新算法的自动生效期是：2019年6月23日。

4. What happens if the recommended PSU / patchset is not applied?

If this patch is not applied, the unpatched database will have a lower SCN rate or lower current max SCN limit.

The newer or patched databases will have higher SCN rate or higher current max SCN limit.

如果不应用补丁，低版本的数据库使用低SCN增长率，高版本数据库使用高SCN增长率。这两类数据库互联，就可能出现SCN的问题。

Therefore, there can be situations when the patched database is at a higher SCN level (due to the higher SCN rate allowance) and the unpatched database is at a much lower SCN level (due to lower SCN rate allowance).

When you open a dblink between these two databases, it has to sync the SCN levels of both the databases and if the SCN increase needed in the unpatched database for this sync is beyond it's allowed SCN rate or current max SCN limit, then the dblink connection cannot be established.

This situation will not rise immediately after the change, but can potentially arise any time after 23rd June 2019.

相关阅读：

SCN、ORA-19706错误和内部参数

深入剖析：Oracle SCN 机制详解

预警揭秘：11.2.0.4前版必须在2019年4月升级

安全警报：2018一月号安全补丁修复安全漏洞

安全警告：WebLogic WSAT组件漏洞挖矿程序攻击

如果在此问题上需要进一步的协助，请联系云和恩墨的技术团队，更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。

相关文章|Related Articles

• SCN 新算法：DBMS_SCN的用法及范例
  
• Oracle 11g在补丁修正中引入DBMS_SCN包及新特性
  
• 解决方案：Oracle的DB Link问题及2019年4月升级路线详述
  
• 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级
  
• Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性
  

作者：eygle 发布在 eygle.com

我们在之前的文章中介绍，Oracle修改了SCN算法，使得SCN的增长率最高可以达到96K/s。
并且设置了3个兼容性级别，对应不同的增长率，1，2，3 是三个可设置级别，3 是终极目标的 96K/s 增长率。

为了推进数据库自动演进到3级的SCN算法，引入了 Auto-Rollover 特性，
根据缺省设置，在 2019年6月23日，数据库将自动启用这个级别。

为了更好的监控和管理SCN，引入了DBMS_SCN包。我们来看一下这个包的使用。

以下是创建脚本：
CREATE OR REPLACE LIBRARY DBMS_SCN_LIB TRUSTED AS STATIC;
/

CREATE OR REPLACE PACKAGE DBMS_SCN AUTHID CURRENT_USER IS

DBMS_SCN_API_MAJOR_VERSION  CONSTANT NUMBER := 1; 
DBMS_SCN_API_MINOR_VERSION  CONSTANT NUMBER := 0;

以下存储过程用于获得当前的SCN参数，包括当前的SCN兼容性，Headroom：
PROCEDURE GetCurrentSCNParams(
                rsl      OUT number,
                headroom_in_scn OUT number,
                headroom_in_sec OUT number,
                cur_scn_compat OUT number,
                max_scn_compat OUT number);

--      Currently no exceptions are thrown.
--      rsl             - Reasonable SCN Limit as of 'now'
--      headroom_in_scn - Difference between current SCN and RSL
--      headroom_in_sec - number of seconds it would take to reach RSL
--                        assuming a constant SCN consumption rate associated
--                        with current SCN compatibility level
--      cur_scn_compat  - current value of SCN compatibility
--      max_scn_compat  - max value of SCN compatibility this database
--                        understands

采用这个过程可以获得如下信息：
DECLARE
 crsl  NUMBER;
 hscn NUMBER;
 hsec NUMBER;
 csc  NUMBER;
 msc  NUMBER;
BEGIN
  dbms_scn.getCurrentSCNParams(crsl, hscn, hsec, csc, msc);
  dbms_output.put_line('Current  RSL:'||TO_CHAR(crsl));
  dbms_output.put_line('Headroom SCN:'||TO_CHAR(hscn));
  dbms_output.put_line('Headroom Sec:'||TO_CHAR(hsec));
  dbms_output.put_line('Currnt SCOMP:'||TO_CHAR(csc));
  dbms_output.put_line('Max_SCN_COMP:'||TO_CHAR(msc));
END;
/
Current  RSL:20764257779712
Headroom SCN:20764254578401
Headroom Sec:633674761
Currnt SCOMP:2
Max_SCN_COMP:3

以下函数用于获得兼容性的信息：
FUNCTION GetSCNParamsByCompat(
                compat IN number,
                rsl           OUT number,
                headroom_in_scn OUT number,
                headroom_in_sec OUT number
         ) RETURN boolean;

--     compat           -- SCN compatibility value
--     rsl              -- Reasonable SCN Limit
--     headroom_in_scn  -- Difference between current SCN and RSL
--     headroom_in_sec  -- number of seconds it would take to reach RSL
--                         assuming a constant SCN consumption rate associated
--                         with specified database SCN compatibility
--
--     Returns False if 'compat' parameter value is invalid, and OUT parameters
--     are not updated.
DECLARE
 boo  BOOLEAN;
 rsl  NUMBER;
 hscn NUMBER;
 hsec NUMBER;
BEGIN
  boo := dbms_scn.getSCNParamsByCompat(1, rsl, hscn, hsec);
  IF boo THEN
    dbms_output.put_line('T');
  ELSE
    dbms_output.put_line('F');
  END IF;
  dbms_output.put_line(TO_CHAR(rsl));
  dbms_output.put_line(TO_CHAR(hscn));
  dbms_output.put_line(TO_CHAR(hsec));
END;
/
T
15910860898304
15910857696641
971121685

以下存储过程获得自动Rollover的时间和目标兼容性，启用与否的信息：
PROCEDURE GetSCNAutoRolloverParams(
                effective_auto_rollover_ts OUT DATE,
                target_compat OUT number,
                is_enabled OUT boolean);

--      effective_auto_rollover_ts  - timestamp at which rollover becomes
--                                    effective
--      target_compat               - SCN compatibility value this database
--                                    will move to, as a result of
--                                    auto-rollover
--      is_enabled                  - TRUE if auto-rollover feature is
--                                    currently enabled

执行如下代码的输出：
DECLARE
 boo     BOOLEAN;
 efrt    DATE;
 tcompat NUMBER;
BEGIN
  dbms_scn.GetSCNAutoRolloverParams(efrt, tcompat, boo);
  dbms_output.put_line('Eff time:'||TO_CHAR(efrt));
  dbms_output.put_line('Tar compt:'||TO_CHAR(tcompat));
  IF boo THEN
    dbms_output.put_line('Enabled');
  ELSE
    dbms_output.put_line('Not Enabled');
  END IF;
END;
/

Eff time:23-JUN-19 -- 可以看到启用时间是2019年6月23日。
Tar compt:3
Enabled



PROCEDURE EnableAutoRollover;

PROCEDURE DisableAutoRollover;

END DBMS_SCN;
/

相关文章|Related Articles

• Oracle全面修正了关于DB Link和SCN补丁的公告
  
• Oracle 11g在补丁修正中引入DBMS_SCN包及新特性
  
• 解决方案：Oracle的DB Link问题及2019年4月升级路线详述
  
• 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级
  
• Oracle 的 DBMS_SCN 修正以及SCN的auto-rollover新特性
  

作者：eygle 发布在 eygle.com

vi ~/.ssh/config
// 加入：
ServerAliveInterval 30

SecCRT 有个 30 秒自动发送字符的做法，Mac 的这个参数设置方便了很多。记录备忘。

相关文章|Related Articles

• Mac上安装Oracle 10g的几点注意事项
  

作者：eygle 发布在 eygle.com

前情回顾：

更新通报：Oracle修正了关于DB Link补丁的公告

解决方案：Oracle的DB Link问题及升级路线详述

预警揭秘：11.2.0.4前版必须在2019年4月升级

Oracle Database 12.2 中，为了更彻底的解决SCN问题，Oracle 通过引入 BigSCN 的新特性，最终改变了 SCN 的算法。

BigSCN 新特性最根本的改变是：将原来 SCN 的存储位数从 6 字节扩展为 8 字节。对比起来，我们将原来的SCN算法称为 SmallSCN，现在的就是 BigSCN。

在 Oracle 12.2 的执行文件中，可以看到其中的一点提示：

[oracle12c@enmotech bin]$ strings oracle | grep big_scn

_big_scn_test_mode

Raising initial SCN from 0x%016llx to 0x0002000000000000 due to _big_scn_test_mode = 4

Raising initial SCN from 0x%016llx to 0x0000ffffffff1fff due to _big_scn_test_mode = %d

通过隐含参数列表，可以获得 big scn 的一个隐含参数，从这个注释中可以看出新特性被命名为 BigSCN, 缺省值是 2 ，在产品环境中这个参数不可以修改，是以测试目的设置的 ：

NAME: _big_scn_test_mode

VALUE: 2

DESCRIB: testing mode for BigSCN

通过以上两类输出，可以看到，当 _big_scn_test_mode 被设置为 4 的时候，SCN 会增进为 0x0002000000000000 ,由这些我们可以看出 SCN 终于突破了 6 Bytes 的设置，进入到了 8 Bytes 时代。

插播活动信息：

2018 ACOUG中国行之·上海站 4月13日上海相见，从Oracle 18c到MySQL 8.0 ，5 大技术主题，欢迎来约，报名详情参考：

ACOUG China Tour 2018 - 4月13日启航上海站

当SCN mode 设置为 4 的时候，SCN 会直接跃迁到 7 Bytes，超越了 6 Bytes 的界限。

那么这个SCN 是多少？

SQL> select to_number('2000000000000','xxxxxxxxxxxxx') scn

from dual;

SCN

------------------------

562,949,953,421,312

而 6 Bytes 的 SCN极限值是281 trillion ：

SQL> select power(2,48) scn from dual;

SCN

------------------------

281,474,976,710,656

将这两组数据放到一个表格会显得一目了然：

_big_scn_test_mode=4 的起点是 49 位，比较 原来的 48 位增进一位，这个起点就直接超越了过去的最大限制：

SQL> select power(2,49) scn from dual;

SCN

------------------------

562,949,953,421,312

BigSCN 最大可用值上升到一个天量数字，可以看到关于SCN问题，我们越来越不需要去担心了：

SQL> select power(2,63) scn from dual;

SCN

--------------------------------

9,223,372,036,854,775,808

虽然理论值做出了改变，SCN的地址空间也获得了增加，但是在实践中，这些新特性的获得是渐进式，在 12.2 之后，这些特性才会逐渐的释放出来。

在以下我的测试环境中，尝试将SCN推进到了极高的位置：

SQL> select current_scn scn from v$database;

SCN

--------------------------------

4,519,057,215,000,399

SQL> oradebug setmypid

Statement processed.

SQL> oradebug dumpvar sga kcsgscn_

kcslf kcsgscn_ [0600113B8, 0600113E8) = 00050F5D 00100E0F

将这个数字放到前面的表格中，大家可以看到SCN在实践中可以获得的海量值空间：

为了防止SCN的过度增加，Oracle 增加了内部函数去分析headroom，并通过 600 号错误的 kcm_low_scn_headroom_alert_1 抛出异常：

2018-03-23T18:12:01.849206+08:00

Errors in file /enmo12c/enmo12c/trace/enmo12c_ora_5259.trc (incident=174424) (PDBNAME=CDB$ROOT):

ORA-00600: internal error code, arguments: [2252], [4520092301887888], [4519517455400960], [], [], [], [], [], [], [], [], []

Incident details in: /enmo12c/enmo12c/incident/incdir_174424/enmo12c_ora_5259_i174424.trc

2018-03-23T18:12:01.858629+08:00

Errors in file /enmo12c/enmo12c/trace/enmo12c_ckpt_5220.trc (incident=174304) (PDBNAME=CDB$ROOT):

ORA-00600: internal error code, arguments: [kcm_low_scn_headroom_alert_1], [], [], [], [], [], [], [], [], [], [], []

Incident details in: /enmo12c/enmo12c/incident/incdir_174304/enmo12c_ckpt_5220_i174304.trc

这个启用了 BigSCN 的 12.2 数据库，当通过DB Link连接 11.2.0.4 的数据库时：

SQL> create database link enmo

connect to eygle identified by eygle using 'enmo';

Database link created.

SQL> select * from dual@enmo;

select * from dual@enmo

*

ERROR at line 1:

ORA-24442: SCN exceeds the capability of the target OCI database or client

这是一个新的错误号：

ORA-24442: SCN exceeds the capability of the target OCI database or client

Cause: An attempt was made to transfer a system change number (SCN) to an Oracle database or client that is older than Release 12.2 and the SCN exceeds the maximum value that such a system can handle.

Action: If needed, update the target database or client to Release 12.2 or higher.

有了BigSCN的新特性，在12.2版本之后，Oracle 关于SCN的种种问题，可能再也不容易被遇到了。

在官方文档上有一些描述与 8 Bytes的 BigSCN相关：

Data Pump Export and Data Pump Import support the new big SCN size of 8 bytes. See the Export FLASHBACK_SCN and the Import FLASHBACK_SCN parameters.

As of Oracle Database 12c release 2 (12.2), the SCN value can be a big SCN (8 bytes). You can also specify a big SCN when you create a dump file for an earlier version that does not support big SCNs because actual SCN values are not moved. See the following restrictions for more information about using big SCNs.

附录：

在kcm内核文件中，可以看到和BigSCN相关的一些函数调用：

bigscn: %c

-?comment:PROF: NO_PROFILE krsu_fal_rcv_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_fal_send_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfs_rcv_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfs_send_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfx_rcv_hndl_bigscn()

-?comment:PROF: NO_PROFILE krsu_rfx_send_hndl_bigscn()

krsu_fal_rcv_hndl_bigscn

krsu_fal_send_hndl_bigscn

krsu_rfs_rcv_hndl_bigscn

krsu_rfs_send_hndl_bigscn

krsu_rfx_rcv_hndl_bigscn

krsu_rfx_send_hndl_bigscn

-?comment:PROF: USED kcm_low_scn_headroom_alert()

kcm_low_scn_headroom_alert

kcm_low_scn_headroom_alert_1

相关阅读：

更新通报：Oracle修正了关于DB Link补丁的公告

解决方案：Oracle的DB Link问题及升级路线详述

预警揭秘：11.2.0.4前版必须在2019年4月升级

SCN、ORA-19706错误和内部参数

深入剖析：Oracle SCN 机制详解

安全警报：2018一月号安全补丁修复安全漏洞

安全警告：WebLogic WSAT组件漏洞挖矿程序攻击

如果在此问题上需要进一步的协助，请联系云和恩墨的技术团队，更详细的解决方案将提供给我们的服务客户。也欢迎加入我们的微信群进一步的讨论该问题。

相关文章|Related Articles

• Oracle全面修正了关于DB Link和SCN补丁的公告
  
• SCN 新算法：DBMS_SCN的用法及范例
  
• Oracle 11g在补丁修正中引入DBMS_SCN包及新特性
  
• 解决方案：Oracle的DB Link问题及2019年4月升级路线详述
  
• 揭秘Oracle 11.2.0.4前版本DB Link必须在2019年4月前升级
  

作者：eygle 发布在 eygle.com

2018 Oracle APAC 用户组大会于2018年4月12日在上海举行，我和杨廷琨作为ACOUG的代表，参加了此次用户组大会。

除了中国本土的用户组，还有来自韩国、澳洲、印度等地的用户组。

在会议开始，Tony Chen展示了Oracle 全球用户组，在 FY18 财年的活动统计，其中包括 675 个 Events，5216 个Sessions，其中和Cloud相关的Session达到1707个。

云技术推广是Oracle战略的主线和导引方向。

Oracle 全球社区的负责人 Jeremy Whyte 为我们介绍了Oracle云业务的增长，从数据上看，FY18财年，Oracle的新的软件收入中，

云上的SaaS和IaaS、PaaS部分已经超过 50%，Oracle的云战略已经成效初显：

ACOUG 联席主席杨廷琨发表演讲，介绍 ACOUG 在过去一年的成绩，ACOUG FY18 举行了超过20场活动，线下影响了5000+，线上的传播则影响了超过100w读者。

在2018年，ACOUG将继续展开基于Cloud技术的全国行，将18c以及Oracle Cloud新技术带给广大的Oracle用户。

不忘初心，继续前行，ACOUG 2018 将加速前行，感谢大家一贯的支持和帮助！

相关文章|Related Articles

• Oracle优化，云上启航 - 2017 RWP中国之旅圆满结束
  
• 2016 ACOUG Asia Tour 西安站 - 西北长安 软件园区
  
• 2016 ACOUG Asia Tour 兰州站 - 黄河之滨 数据为王
  
• 2016 ACOUG Asia Tour 济南站 - 花好月圆 饮水泉城
  
• 2016 ACOUG Asia Tour 南京站 - 六朝古都 金陵王气
  

作者：eygle 发布在 eygle.com

在 Oracle Database 18.3 版本发布之后，一系列新的参数被加入到数据库中，这些新的参数就代表了数据库中新增的特性。

很多特性Oracle并未明确解释何说明，但是我们可以通过参数揣摩端倪。
以下列表是对比 Oracle Database 12.2 版本，18.3 中新增的参数。通过 x$ksppi 可以看到 12.2 版本有 4846 个参数，而 18.3 有 5159 个参数.
从参数数量上来说，增加了 313 个，这是一个不小的数字，无论是跟踪诊断，性能优化，还是 异常恢复，这些参数都是核心所在。

KSPPINM 					   KSPPSTVL		     KSPPDESC
-------------------------------------------------- ------------------------- --------------------------------------------------------------------------------
_EnableDDLTtriggerTracing			   FALSE		     enable ddl trigger tracing
_EnableShadowTypes				   FALSE		     enable shadow types
_REMOVE_INACTIVE_STANDBY_TDE_MASTER_KEY 	   FALSE		     Remove Inactive Standby TDE Master Key
_REMOVE_STDBY_OLD_KEY_AFTER_CHECKPOINT_SCN	   TRUE 		     Remove standby old key after checkpoint SCN
_STFTranslateDynamicSQL 			   FALSE		     if TRUE translation profile will translate dynamic SQL statements
__memoptimize_xmem_pool_size_metadata		   0			     Size of extended cache metadata of MEMOPTIMIZE buffer pool for standard block si
									     ze buffers

__sga_current_size				   0			     Current size for PDB SGA
_adg_auto_close_pdb				   TRUE 		     ADG recovery auto close PDB upon PDB drop/unplug/rename marker
_adg_objectlock_attempts			   2			     Maximum attemps for objectlock get on ADG
_adg_objectlock_maxnum				   1000 		     The maximum limit of the objectlock number on ADG
_adg_objectlock_timeout 			   0			     timeout for objectlock get on ADG in centiseconds
_adg_redirect_flags				   0			     Flags for controlling ADG's Statement Redirection behavior
_allocate_flashback_buffer			   FALSE		     Allocate flashback buffer at mount time even if flashback is off
_allow_cross_endian_dictionary			   FALSE		     Allow cross-endian data dictionary
_app_container_debug				   0			     Enable Debug tracing in Application container
_apppdb_multi_slave_sync			   TRUE 		     Multiple slaves used during Application sync
_aq_dqblocks_in_cache				   0			     deq blocks in cache
_aq_free_list_pools				   10			     state object and transaction memory pools
_aq_lb_garbage_col_interval			   600			     AQ LB garbage collect interval
_aq_lb_subht_bkt_ltch				   32			     AQ LB subscriber ht bucket latches
_aq_lb_subht_elm_ltch				   128			     AQ LB subscriber ht element latches
_aq_max_pdb_close_msg				   1			     Max Number of AQ Recovery Messages when pdb is closed
_aq_scrambled_deqlog				   1			     scrambled deqlog
_asm_allow_dgname_special_chars 		   FALSE		     Enable the use of special characters in diskgroup names
_asm_async_scrub_reap_wait			   100000		     Async scrubbing reaping IO wait in microseconds
_asm_cancel_delta				   75000		     Delta timeout for blocking big writes in milliseconds
_asm_enable_batch_scrub 			   FALSE		     Allow scrubbing verification to run in batch mode
_asm_enable_kfios				   FALSE		     Enable KFIOS module
_asm_oda_type								     ODA Type
_asm_proxy_online_restart			   0			     Allow patching while ADVM volumes are online
_asm_pstonpartners				   TRUE 		     Select ideal PST disks following partnership
_asm_reloc_cic					   FALSE		     Allow relocation during rolling migration
_asm_relocation_scheme				   alloc_p2 alloc_s3 reb_p2  ASM allocation / relocation scheme
						   reb_s1 bal_p2 bal_s3 prep
						   _p2 prep_s3

_asm_write_badfdata_in_contentcheck		   TRUE 		     Write BADFDA7A in content check
_asm_zero_power_limit							     allow setting zero power limit
_async_scn_sync 				   OFF			     Asynchronous SCN Sync Setting
_auto_dismount_on_pdb_close			   FALSE		     Enable implicit PDB dismount on PDB close
_auto_rcv_pdb_open				   1			     enable automatic recovery during pdb open
_awr_incremental_flush_enabled			   TRUE 		     Enable/Disable AWR automatic incremental flushing
_backup_block0					   default		     backup block0
_bequeath_via_broker				   FALSE		     Bequeath connections via broker
_bloom_extent_size				   0			     bloom filter extent size in bytes
_bloom_filter_setops_enabled			   TRUE 		     Allow bloom filter to be pushed through set operations
_bloom_max_wait_time				   50			     bloom filter wait time upper bound (in ms)
_bloom_pruning_setops_enabled			   TRUE 		     Allow bloom pruning to be pushed through set operations
_bloom_use_shared_pool				   FALSE		     use shared pool for bloom filter
_bloom_wait_on_rac				   FALSE		     enables bloom filter (with hash hash distribution) wait on RAC
_capability_simulate							     Simulate the capabilities for testing
_cdb_fleet_sync_timeout 			   10			     Time in minutes to wait for sync of stub entry in CDB Fleet
_cdb_port					   0			     Port number for CDB
_cdb_view_no_skip_restricted			   FALSE		     do not skip RESTRICTED mode PDBs from results of CONTAINERS()
_cell_offload_hybrid_processing 		   TRUE 		     enable hybrid SQL processing offload to cells
_cell_offload_vector_groupby_force		   FALSE		     force offload of vector group by
_cgs_publish_netinfo_collect_event_chm		   TRUE 		     enable cgs publish collect_netinfo event to event stream for CHM
_cgs_publish_netinfo_collect_event_haip 	   FALSE		     enable cgs publish collect_netinfo event to event stream for HAIP
_clear_preserved_buffers			   TRUE 		     Clear preserved buffers before DB reopen after switchover
_client_result_cache_ramthreshold					     client_result_cache_ramthreshold
_cloud_service_sim				   0			     simulate cloud services in Database
_cloud_service_type							     cloud service type
_con_map_sql_enforcement			   TRUE 		     disable container map SQL enforcement
_connection_broker_handout_accept		   FALSE		     connection broker accepts prior to handout
_cross_con_collection				   FALSE		     enable cross container collection
_datapump_gather_stats_on_load			   FALSE		     Gather table statistics during Data Pump load rather thanimporting statistics fr
									     om the dump file. This should be set to TRUE in the lockdown profile in a DWCS e
									     nvironment.

_datapump_inherit_svcname			   FALSE		     Inherit and propagate service name throughout job
_db_flash_cache_slow_io_adjustment_interval	   3600 		     Decrement interval
_db_imoltp_hashidx_force_nonctg 		   0			     kcbw imoltp hash index force non contig granules
_db_shadow_lost_write_protect			   NOT_SET		     alter shadow lost write detection for PDB
_disable_actualization_for_grant		   FALSE		     disable actualization of editioned objects on grant
_disable_asm_audit_feat 			   0			     disable ASM audit features
_disable_dblink_optim				   TRUE 		     disable intra CDB dblink optimizations
_disable_system_tablespaces_enc_enforcement	   FALSE		     if TRUE, disable system tablespaces encryption enforcement
_dmm_pga_load_threshold 			   3			     Model size less than threshold are loaded into PGA
_drain_on_ping_database 			   TRUE 		     Should session drain be performed when user issues OPING
_dskm_single_instance				   FALSE		     DSKM and Diskmon operating in Single Instance mode
_dss_cache_flush_threshold			   1			     threshold when thread ckpt considered over obj ckpt
_duplicated_table_complete_refresh_percent	   50			     percent threshold for duplicated table to do complete refresh
_dupt_noupdate					   0			     disable duplicated table updates
_ena_storage_lmt				   DEFAULT		     Enable storage clause for LMT
_enable_auto_upgrade				   FALSE		     Enable automatic PDB upgrade
_enable_dbwr_auto_tracing			   0			     enable dbwriter auto-tracing
_enable_imc_mira				   FALSE		     enable IMC with  multi instance redo apply
_enable_ios_spm 				   FALSE		     Allow Split Mirror operations via IOServer
_enable_multiple_fgprepares			   FALSE		     Allow concurrent PREPAREs on the same database
_enable_parallel_dml				   FALSE		     enables or disables parallel dml
_enable_pmo_outside_begin_end			   TRUE 		     Enable PMO outside begin-end block
_enable_proxy_adg_redirect			   FALSE		     Enable Statement Redirection Support for ADG using Proxy PDB
_enable_single_dgprepare			   FALSE		     Disable concurrent PREPAREs in same disk group
_error_row_predicate_evaluation 		   AUTO 		     skip predicate evaluation for error rows
_exadata_feature_on				   FALSE		     Exadata Feature On
_fg_fast_sync_sleep_usecs			   50			     DAX log file sync sleep time
_fg_fast_sync_spin_usecs			   300			     DAX log file sync spins time
_force_active_temp_detection			   FALSE		     Force active temp detection during PDB close
_freeze_kgh_timestamp				   FALSE		     prevent heap manager timestamp from advancing
_gc_lease_time					   500			     lease time for rdma reads
_gc_max_reg_sz					   68719476736		     maximum length for memory registration
_gc_partial_cleanout				   FALSE		     if TRUE, partial cleanout is enabled
_gc_undo_rdma_read				   FALSE		     if TRUE, rdma read of undo blocks is enabled
_gcs_disable_imc_preallocation			   FALSE		     disable preallocation for imc memory requirement in RAC
_gcs_enable_private_iterator			   TRUE 		     Enable private iterator for GCS locks
_gcs_recoverable_asserts			   1			     if non-zero, enable recoverable assert resolution
_gdr_control_flags				   0			     gdr control flags
_gds_allow_nullkey				   0			     allow the use of nullable shard key columns
_gds_max_chunk_num				   0			     max chunk_num used in sharding environment
_ges_mseq_demo					   0			     demo mseq wrap scenarios (dflt is 0)
_globaldict_analyzer_pct			   100			     Maximum percentage of unique values in analyzer phase for GD
_globaldict_chain_limit 			   32			     Chain limit for global dictionary
_globaldict_check				   0			     Dictionary checking
_globaldict_chunk_minalloc			   FALSE		     Force minimum chunk allocation size
_globaldict_dbg 				   0			     Global dictionary debug modes
_globaldict_enable				   2			     Enable segment dictionary
_globaldict_max_gdsize				   1073741824		     Maximum number of entries in a Global dictionary
_globaldict_reprobe_limit			   1			     Reprobe limit for global dictionary
_globaldict_use_ndv				   TRUE 		     Use NDV for sizing global dictionary, if available
_gwm_db_unique_name							     gsm db_unique_name name
_hang_appl_issue_session_threshold		   0			     Hang Management application issue session threshold
_hang_asm_hang_resolution_enabled		   FALSE		     Hang Management ASM hang resolution enabled
_hang_deadlock_resolution_enabled		   TRUE 		     Hang Management deadlock resolution enabled
_hang_hang_blocked_session_delta_percent_threshold 20			     Hang Manager hang's blocked session delta percent threshold
_hang_ignore_hngmtrc_interval			   150			     Hang Management ignore hang metric dependent hang interval
_hang_intersecting_chains_scanning_enabled	   TRUE 		     Hang Management intersecting chains scanning is allowed
_hang_log_important_hangs_to_alert		   TRUE 		     Hang Management log important hangs to alert log
_hang_promote_process_termination_interval	   70			     Hang Management promote process termination interval in seconds
_hang_root_ha_phase_trigger_time		   300			     Hang Management root HA phase trigger time
_hcs_expose_with_expr				   FALSE		     expose internal with_expression
_hcs_gen_aggr_opt_estimate			   FALSE		     apply OPT_ESTIMATE hint to aggregation queries
_hcs_ignore_latest_compat_check 		   FALSE		     skip compatibility check for latest compatible version
_hcs_in_mem_cdt_hint				   FALSE		     add hint opt_param('_in_memory_cdt', 'off')
_hcs_mdx_cache_name_col 			   FALSE		     add column for mdx cache name
_hcs_mdx_cache_name_no_sid			   FALSE		     don't use session id in mdx cache hint names
_hcs_mdx_sleep_after_pin			   FALSE		     sleep after pinning MDX caches
_hcs_no_calc_dtm_to_out_opt			   FALSE		     apply move calc determined hier to output hier optimization
_hcs_no_cell_qry_atr_prune_opt			   FALSE		     apply attribute prune optimization to cell query
_hcs_no_cell_qry_lvl_prune_opt			   FALSE		     apply level prune optimization to cell query
_hcs_no_cell_qry_meas_prune_opt 		   FALSE		     apply measure prune optimization to cell query
_hcs_no_cell_qry_mv_cache_opt			   FALSE		     apply mv cache optimization to cell query
_hcs_no_cell_qry_no_calc_nav_opt		   FALSE		     apply no calc navigation optimization to cell query
_hcs_no_cell_qry_no_out_data_opt		   FALSE		     apply no output data optimization to cell query
_hcs_no_cell_qry_tmpls				   FALSE		     no cell query templates for optimization
_hcs_no_col_prune_optz				   FALSE		     skip column pruning optimization on generated SQL
_hcs_no_fltr_fact_opt				   FALSE		     apply filtered fact optimization
_hcs_no_fltr_hier_star_opt			   FALSE		     apply filtered hierarchy star optimization
_hcs_no_inline_tmpl_opt 			   FALSE		     apply inline single ref top blocks optimization to cell query
_hcs_no_jback_opt_for_hord_in_oby		   FALSE		     optimize analytic view joinback for HIER_ORDER
_hcs_no_mdx_cache_hint				   FALSE		     generate hcs query mdx cache hints
_hcs_no_mv_rewrite_check			   FALSE		     skip MV rewrite check when generating for ANALYTIC VIEW cache
_hcs_no_opt_cell_qry				   FALSE		     optimize cell query
_hcs_no_rm_like_withs_optz			   FALSE		     skip like WITH element removal optimization on generated SQL
_hcs_no_rm_unused_withs_optz			   FALSE		     skip unused WITH element removal optimization on generated SQL
_hcs_no_rmv_unref_top_opt			   FALSE		     apply remove unref top blocks optimization to cell query
_hcs_no_tgt_depths_opt				   FALSE		     apply target depths optimization
_hcs_opt_av_pred_push				   TRUE 		     enable optimizer AV predicate pushing via reparse
_hcs_parse_dynamic_all_cache			   FALSE		     allow parsing of dynamic across all levels cache
_hcs_stats_max_card				   2000000		     maximum value for stats cardinality
_hcs_use_dynamic_all_cache			   FALSE		     use dynamic across all levels cache
_hcs_use_multi_parent_gen			   FALSE		     generate hcs query using multi-parent aggregation
_hugetlbfs_mount_point_for_sga						     HugeTLBFS mount point to be used
_imado_diagtasks_log_period			   5			     IM-ADO diagnostic tasks logging period (in seconds)
_imado_diagtasks_purge_period			   30			     IM diagnostic tasks purge older than X days
_imado_evict_sf 				   2			     AIM evict safety factor
_imado_sysaux_usage_limit			   90			     SYSAUX usage percent limit for storing AIM diagnostics
_imtxnrma_table_enable				   FALSE		     is In-Memory RMA Txn Table cache enabled
_index_load_analysis_frequency			   4			     index load compression analysis frequency
_inmemory_adg_batched_flush			   TRUE 		     If true, batched flush is performed
_inmemory_adg_journal_quota			   FALSE		     If true, throttled mining is performed under space pressure
_inmemory_adg_parallel_flush			   TRUE 		     If true, parallel flush is performed
_inmemory_adg_periodic_sort			   FALSE		     If true, periodic sort is performed
_inmemory_delta_population			   0			     Control Delta IMCU population
_inmemory_dynamic_scans_analyze_batch_size	   5			     Inmemory dynamic scan analyze batch size
_inmemory_external_table			   TRUE 		     Enable inmemory extern table
_inmemory_grpcolinv_buffer_size 		   131072		     In-memory grpcolinv buffer size
_inmemory_grpcolinv_granularity 		   1			     In-memory grpcolinv blks per colmap
_inmemory_hwm_expand_percent			   20			     max blks percent can exceed in hwmimcu
_inmemory_hwm_expansion 			   0			     If 0, the highwatermark CU is dropped when expanded
_inmemory_max_delta				   5			     Inmemory max number of deltas per CU
_inmemory_min_delta_blocks			   50			     Inmemory minimum blocks per delta
_inmemory_min_delta_rows			   255			     Inmemory minimum rows per delta
_inmemory_patch_background_blocks		   200			     In-memory SMU patch threshold blocks to start background tasks
_inmemory_patch_commit_path			   FALSE		     If true, enable the SMU patching from DML path
_inmemory_patch_threshold_blocks		   25			     In-memory SMU patch threshold blocks
_inmemory_prefix_encode_dsbs			   FALSE		     Prefix-encode the DSB-dictionary
_inmemory_scan_invalid_percent			   30			     Inmemory scan invalid percentage
_inmemory_smu_patch_options			   7			     Inmemory SMU patching options
_inmemory_vector_encode_override		   FALSE		     Populate and use DSBs for Vector Encode columns
_instance_recovery_bloom_filter_fprate		   0			     Allowable false positive percentage [0-100]
_instance_recovery_bloom_filter_size		   83886080		     Bloom filter size (in num of bits) used during claim phase
_intra_cdb_dblink				   FALSE		     enable intra CDB implicit dblink
_kcfis_pmem_enabled				   FALSE		     RDMA Persistent Memory support enabled
_kdfip_buf_nclatch				   64			     memopt w buffer child latches
_kdfip_bufl_nbkt				   64			     memopt w buffers list buckets
_kdfip_cmap_nbkt				   16			     memopt w chunk map buckets
_kdfip_debug					   0			     memopt w debug
_kdfip_drain_sleeps				   60			     memopt w drain coord sleep count
_kdfip_elem_nclatch				   64			     memopt w chunkmap elem child latches
_kdfip_flush_nrows				   10			     memopt w flush num rows
_kdfip_flush_rowsz				   1024 		     memopt w flush row size
_kdfip_flush_rowtm				   60			     memopt w flush time
_kdfip_iga_bufsz				   65536		     memopt w write buffer size
_kdfip_iga_maxsz				   52428800		     memopt w max global area size
_kdfip_par_flush				   TRUE 		     memopt w parallel flush
_kdfip_trace					   FALSE		     memopt w tracing on-off
_kdkv_fg_drop_memopt				   TRUE 		     hashindex foreground drop
_kdkv_fg_no_memopt				   FALSE		     hashindex foreground cleanup
_kdkv_fg_populate				   FALSE		     hashindex foreground populate
_kdkv_fg_repopulate				   FALSE		     hashindex foreground repopulate
_kdkv_force_fastpath				   FALSE		     kdkv fast path on-off
_kdkv_index_lossy				   TRUE 		     hashindex lossiness on-off
_kdkv_index_relocate				   FALSE		     hashindex relocation on-off
_kdkv_indexinvalid				   FALSE		     objd and rdba based index invalidation
_kdkv_trace					   FALSE		     kdkv tracing on-off
_kdlxp_no_dedup_on_insert			   FALSE		     disable deduplication for new inserts of deduplicated lobs
_key_vector_double_enabled			   TRUE 		     enables or disables key vector support for binary_double
_key_vector_shared_dgk_ht			   TRUE 		     allows shared DGK hash table
_key_vector_timestamp_enabled			   TRUE 		     enables or disables key vector support for timestamp
_kra_cfile_compaction				   TRUE 		     controlfile record compation
_kse_alt_stack_sig_syms 			   10			     The number of top symbols used for the alternate stack signature
_ksipc_trace_bucket				   PRIVATE		     memory tracing: use ksipc-private or rdbms-shared bucket
_ksipc_trace_bucket_size			   IPC0:1048576-REST:8192    KSIPC trace bucket size in bytes (format: "IPC0:-REST:")
_ksipc_window_size							     Configure IPC Windowing Value for clients on a per transport basis
_ksipcsnsrv								     Configure Shared Nothing Server Name
_ksm_sp_rcr_hits				   10			     hits to make object recurrent
_ksmd_trace					   0			     ksmd tracing
_ksmsq_hintmaxinst				   1024 		     KSMSQ Hint Max Instances
_ksmsq_hintmaxproc				   300			     KSMSQ Hint Max Processes
_ksws_java_patching				   0			     java patching mode
_kswsas_drain_kill_batch_size			   5			     Batch size for killing non-drained sessions
_kswsas_num_jp_slaves							     Number of slaves for java patching
_ksxp_validate_cnh_life_cycle			   0			     enable validation of ksxp connection life cycle
_ktst_tscleanup_timeout 			   1800 		     Time in seconds to wait for active temp clients
_ldap_config_force_sync_up			   FALSE		     LDAP configure force sync up
_ldap_config_ssl_for_sasl_md5			   TRUE 		     LDAP configure SSL for SASL-DIGEST-MD5
_ldap_reset_user_account_flc			   TRUE 		     LDAP reset user account lockout counter
_lm_chk_inv_domenq_ops				   TRUE 		     enable checks for invalid enqueue operations on domains
_lm_comm_slow_op_loop_threshold 		   15			     GES communication slow operation loop threshold in ms
_lm_enq_iso_enabled				   TRUE 		     if TRUE enables enqueue isolation
_lm_idle_connection_action			   kill 		     GES idle connection action
_lm_idle_connection_load_check			   TRUE 		     GES idle connection load check
_lm_nonisolated_restype 			   TOTTUL		     string of resource types banned from enqueue isolation
_lm_pdb_wait_all_gone				   FALSE		     pdb domain attach wait until all locks are gone
_lm_recovery_set				   1			     enable recovery set checking for accessing invalid domains
_lm_share_lock_pdbisolation			   TRUE 		     if TRUE enables share lock optimization with pdb isolation
_lm_use_us_timer				   FALSE		     Use microsecond timer for LM hist
_lm_wait_for_hub_rcv_timeout			   300000		     read-only insts wait for hub avaliable to recover in millis
_lmhb_procstate_dump_cputime_limit		   60			     hb diagnostic cputime limit for process state dump in secs
_lmhb_procstate_dump_runtime_limit		   60			     hb diagnostic runtime limit for process state dump in secs
_lob_use_locator_varying_width			   FALSE		     use varying width flag in lob locator
_max_lwt_cpu_ratio				   2			     ratio to determine the maximum CPUs for LWTs
_memoptimize_xmem_pool_size			   0			     Size of MEMOPTIMIZE buffer pool for standard block size buffers on extended memo
									     ry

_memory_adi_module_mask 			   0			     bit mask of modules to enable ADI versioning
_mga_large_page_path							     large page path
_next_pdbid					   3			     Hint for the next PDBID to use when creating a new PDB entry
_no_catalog								     options whose schemas should not be created
_no_snapshot_root_clone 			   FALSE		     No snapshot clone during Application Root Clone creation
_nologging_apply_stall_time			   1000 		     milli-seconds recovery waits after DTC full before changing RCVID
_nologging_fetch_initial_interval		   2			     seconds recovery waits between issuing fetches for old ranges
_nologging_mode_override			   0			     Override the database logging mode; 1=Force, 2=NoForce, 3=LP, 4=DA
_nologging_progress_keep_alive			   10			     Nologging standby progress keep alive time
_nologging_slots				   20			     Nologging standby: initial buffer count
_nologging_standby_cold_buffer_timeout		   500			     Centi-seconds recovery will wait for a buffer that is not being sent by a direct
									      load client in Nologging Standby Data Availability mode

_nologging_standby_dtc_expire			   600			     The number of seconds a Data Transfer Cache buffer may remain unclaimed
_nologging_standby_fetch_disable		   FALSE		     controls whether invalid block ranges are fecthed during recovery
_nologging_standby_hot_buffer_timeout		   500			     Centi-seconds recovery will wait for a buffer being sent by a direct load client
									      in Nologging Standby Data Availabilty mode

_nologging_standby_refetch_disable		   FALSE		     controls fetching of pre-existing invalid block ranges during standby recovery
_optimizer_allow_all_access_paths		   TRUE 		     allow all access paths
_optimizer_answering_query_using_stats		   FALSE		     enable statistics-based query transformation
_optimizer_gather_stats_on_load_all		   FALSE		     enable/disable online statistics gathering for nonempty segments
_optimizer_gather_stats_on_load_hist		   FALSE		     enable/disable online histogram gathering for loads
_optimizer_key_vector_payload			   TRUE 		     enables or disables dimension payloads in vector transform
_optimizer_vector_fact_payload_ratio		   20			     cost based vector transform payload dimension to fact ratio
_parallel_lmd_reconfig				   1			     parallel lmd work in reconfiguration for enqueues.
_partition_by_con_name				   FALSE		     enable partitioning by con$name
_pdb_ignore_table_clauses			   TRUE 		     Ignore subset of clauses in CREATE TABLE and ALTER TABLE
_pdb_isolation_class				   NONE 		     PDB isolation level: NONE, HIGH or MAX
_pdb_ldp_cascade				   0			     pluggable database lockdown profile cascade param
_pga_limit_per_process_minimum			   3145728		     pga_aggregate_limit per-process minimum
_pmon_exitnfy_enabled				   FALSE		     PMON Exit notification enabled
_ptf_enable_objects				   FALSE		     enable object types in PTF
_ptf_max_rows					   1024 		     number of rows per row-buffer
_ptt_max_num					   16			     Maximum number of PTTs per session
_px_granule_alignment				   1024 		     default size of a rowid range granule (in KB)
_px_join_skew_null_handling			   TRUE 		     enables null skew handling improvement for parallel outer joins
_px_join_skew_sampling_percent			   0			     Sets sampling percentage for skew handling sampling queries
_px_join_skew_sampling_time_limit		   50			     Sets execution time limit for skew handling sampling queries
_px_join_skew_use_histogram			   TRUE 		     Enables retrieval of skewed values from histogram when possible
_px_nlj_bcast_rr_threshold			   10			     threshold to use broadcast left random right distribution for NLJ
_px_partition_skew_threshold			   80			     percentage of table size considered as threshold for skew determination
_px_pwise_wif_enabled				   TRUE 		     enable parallel partition wise window function
_px_reuse_server_groups 			   MULTI		     enable/disable reusing of server groups that are already acquired
_px_shared_hash_join				   FALSE		     enable/disable shared hash join
_px_tq_memcpy_threshold 			   100			     threshold for PQ TQ to use memcpy for packing columns
_qksfgi_dynamic_partitions						     enable partition bind SQLIDs for
_qksfgi_feature_level				   0			     controls the feature level for fine-grained cursor invalidation
_rac_propagate_last_rba 			   TRUE 		     Propagate last written log redo address in RAC for log mining
_read_only_slave_timeout			   30			     Time to wait on read only node when hub not available
_read_optimized_table_lookup			   TRUE 		     enables read-optimized table lookup
_reader_farm_isolation_enable			   FALSE		     Reader Farm instances isolation enable
_reader_farm_isolation_time_threshold		   200			     reader farm isolation time threshold
_record_module_name				   TRUE 		     Record module name in BEGIN action
_redo_log_key_reuse_count			   0			     Determines the number of redo logs sharing the same redo log key
_redo_write_sync_single_io			   TRUE 		     enable sync I/O for single redo write
_ref_cons_sql_enforcement			   TRUE 		     disable extended/data ref constraint SQL enforcement
_reg_cache_status				   FALSE		     Enables or disabled caching
_remessage_dbwrs				   0			     DBWR wait and remessage time - in cs
_request_boundaries				   1			     request boundaries mode
_restore_block0 				   on			     restore block0
_result_cache_per_pdb				   TRUE 		     Is service result cache per pdb
_rm_exadata_partition_fc			   FALSE		     Partition flash cache for Exadata
_rm_exadata_pdb_cpu_cnt_mult			   2			     Multiplication factor for PDB cpu count
_rmv_dynamic_priority				   TRUE 		     enable rmv priority modification
_root_clone_state_from_root			   TRUE 		     Application Root Clone's state comes from Application Root
_sequence_scale_extend				   FALSE		     Force sequence creation with scale extend
_sequence_scale_noextend			   FALSE		     Force sequence creation with scale noextend
_shd_atomic_move				   0			     Use atomic move
_show_login_pdb_sessions			   FALSE		     return logon pdb container id from v$session
_simulate_dax_storage				   DISABLE		     Simulate log on DAX storage
_skip_pdb_recovery_if_keystore_not_open 	   FALSE		     Skip PDB recovery when the PDB's keystore is not open
_skip_unconverted_change_vector 		   FALSE		     Skip apply of a CV that has no endian conversion function
_slow_kill_on_pdb_close_immediate		   FALSE		     Kill sessions periodically on pdb close immediate
_sqlexec_cache_aware_hash_aggr_enabled		   TRUE 		     enable/disable cache aware hash aggregation
_sqlexec_pwiseops_with_binds_enabled		   TRUE 		     enable partition wise execution in the presence of bind variables in inlist equa
									     lity operator in where clause

_sqlexec_pwiseops_with_sqlfuncs_enabled 	   TRUE 		     enables partition wise operations even in the presence of functions over table p
									     artition keys

_sqlexec_reorder_wif_enabled			   TRUE 		     enable re-ordering of window functions
_sqlexec_use_kgghash3				   TRUE 		     use CRC-based hash function
_standby_newkey_keystore_location					     Location of keystore on standby having new key
_uniq_cons_sql_enforcement			   TRUE 		     disable extended data unique constraint SQL enforcement
_use_fallocate_for_mga				   FALSE		     MGA fallocate enabled
_use_hugetlbfs_for_SGA				   FALSE		     Enable HugeTLBFS usage for SGA
_use_large_pages_for_mga			   FALSE		     MGA largepage enabled
_verify_encrypted_tablespace_keys		   TRUE 		     if TRUE, verify encryption key signature for data files
_wait_outlier_dump_flags			   0			     Wait Outlier Dump Flags
_wait_outlier_lambda_x1000			   1500 		     Lambda (in thousands) to compute outliers
_wait_outlier_min_waits 			   10			     Minimum waits required to enable wait outliers detection
_wait_outlier_num_outliers			   600			     Max number of outliers tracked
_xt_def_compression_ratio			   4			     Default compression ratio for external table data files
_xt_http_wscl					   FALSE		     Use KGWSCL for HTTP requests
_xt_legacy_debug_flags				   0			     Debug flags for ORACLE_LOADER and ORACLE_DATAPUMP
adg_account_info_tracking			   LOCAL		     ADG user account info tracked in standby(LOCAL) or in Primary(GLOBAL)
awr_pdb_max_parallel_slaves			   10			     maximum concurrent AWR PDB MMON slaves per instance
forward_listener							     forward listener
inmemory_automatic_level			   OFF			     Enable Automatic In-Memory management
inmemory_optimized_arithmetic			   DISABLE		     Controls whether or not DSBs are stored in-memory
inmemory_prefer_xmem_memcompress					     Prefer to store tables with given memcompress levels in xmem
inmemory_prefer_xmem_priority						     Prefer to store tables with given priority levels in xmem
inmemory_xmem_size				   0			     size in bytes of in-memory xmem area
memoptimize_pool_size				   0			     Size of cache for imoltp buffers
multishard_query_data_consistency		   strong		     consistency setting for multishard queries
multishard_query_partial_results		   not allowed		     enable partial results for multishard queries
optimizer_ignore_hints				   FALSE		     enables the embedded hints to be ignored
optimizer_ignore_parallel_hints 		   FALSE		     enables embedded parallel hints to be ignored
parallel_min_degree				   1			     controls the minimum DOP computed by Auto DOP
pdb_template								     PDB template
private_temp_table_prefix			   ORA$PTT_		     Private temporary table prefix
standby_pdb_source_file_dblink						     database link to standby source files
standby_pdb_source_file_directory					     standby source file directory location
tde_configuration							     Per-PDB configuration for Transparent Data Encryption
unified_audit_systemlog 						     Syslog facility and level for Unified Audit
wallet_root								     wallet root instance initialization parameter

356 rows selected.

废弃的参数，在12.2 中存在，可是在 18.3 中已经被驱逐的废弃参数，数量是 43 个，参考如下列表：

 
KSPPINM
--------------------------------------------------
_bloom_use_crchash
_cdbperf_sweep_enabled
_cdt_shared_memory_limit
_cdt_shared_memory_query_percent
_db_new_lost_write_protect
_dbwr_nowrite_tracing_interval
_dmm_blas_lib_enable
_enable_umf_auto_tasks_pool
_gc_cpu_time
_gws_chunk_ver
_hang_ignore_hngmtrc_count
_hcs_no_column_info
_imado_histogram_period
_imcdt_use_mga
_inmemory_ado_enabled
_inmemory_batched_flush
_inmemory_dynamic_scan_analyze_batch_size
_inmemory_periodic_sort
_inmemory_segment_populate_verify
_kcl_max_reg_sz
_key_vector_caching
_kqr_allocate_directly_from_sga
_kswsas_sim_jp_api
_log_event_queues
_optimizer_ignore_hints
_post_wait_queues_dynamic_queues
_px_reuse_server_group
_segdict_analyzer_pct
_segdict_chain_limit
_segdict_check
_segdict_chunk_minalloc
_segdict_enable
_segdict_enable_domaindict
_segdict_max_gdsize
_segdict_reprobe_limit
_segdict_use_ndv
_select_any_dictionary_security_enabled
_set_mgd_recovery_state
_wait_outlier_dlambda
_wait_outlier_plambda
_wait_outlier_report_minute_interval
standby_archive_dest
utl_file_dir

43 rows selected.

一点一滴，Oracle 数据库在发生大变化。

相关文章|Related Articles

• ATP-Oracle自治事务处理(OLTP)数据库与自动索引优化
  
• Oracle 18.3 和 12.2 版本初始化参数缺省值的改变列表
  
• Oracle18.3:透过告警日志从安装初始化过程看 18c 的新改变
  
• Oracle 18c 安装ORA-12754 Runtime Environment的两种解决方案
  
• 极速体验:Oracle 18c 下载和Scalable Sequence新特性
  

作者：eygle 发布在 eygle.com

从 Oracle Database 12.2 到 Oracle 18.3 ，有很多初始化参数的缺省值发生了变化，我整理了一个列表供大家参考。

这其中有些参数和硬件配置有关，但是绝大多数就是因为版本变化做出的改变。尤其是参数值的 True 和 False 的改变。

比如 _use_single_log_writer 的缺省值变成了 TRUE，意味着缺省将禁用自适应 LGWR 的特性。

KSPPINM 		       NEWVALUE 		      OLDVALUE			     KSPPDESC
------------------------------ ------------------------------ ------------------------------ ------------------------------------------------------------
_spin_count		       1			      2000			     Amount to spin waiting for a latch
_super_shared_conversion_threshold 300			      1280			     conversion threshold limit for supershared mode


_num_longop_child_latches      1			      8 			     number of child latches for long op array
_kill_session_dump	       FALSE			      TRUE			     Process dump on kill session immediate
_session_allocation_latches    1			      8 			     one latch per group of sessions
_disable_highres_ticks	       TRUE			      FALSE			     disable high-res tick counter
_enqueue_sync_retry_attempts   15			      3 			     max number of times the bg process to retry synchronous enqu
											     eue open if it failed because master could not allocate memo
											     ry

_enable_shared_pool_durations  TRUE			      FALSE			     temporary to disable/enable kgh policy
_kse_snap_ring_size	       0			      100			     ring buffer to debug internal error 17090
_ksi_clientlocks_enabled       TRUE			      FALSE			     if TRUE, DLM-clients can provide the lock memory
_instant_file_create	       FALSE			      TRUE			     enable instant file creation on sparse media
_ksipc_service_mask	       1			      0 			     KSIPC Service Mask
_proc_grp_enabled	       3			      FALSE			     proc-group enabled
_ksrma_enabled		       off			      OFF			     turn ksrma off, make it automatic, or turn on CMI or KSMSQ p
											     rovider. Default is off

_hang_resolution_promote_proce TRUE			      FALSE			     Hang Management hang resolution promote process termination
ss_termination

_lm_singleton_pdb_opt	       TRUE			      FALSE			     RAC PDB singleton optimization
_lm_rm_object_bypass	       TRUE			      FALSE			     enable read-mostly object bypass for HARIM
_reconfiguration_opt_level     13			      0 			     reconfiguration optimization level
_dlm_stats_collect_mode        4			      0 			     DLM statistics collection mode
_lm_comm_rcv_msg_history_slots 50			      0 			     GES communication receive message history slots
_reliable_block_sends	       TRUE			      FALSE			     if TRUE, no side channel on reliable interconnect
_memory_broker_shrink_heaps    15			      0 			     memory broker allow policy to shrink shared pool
_dbwr_nowrite_assert_interval  7200			      0 			     dbwriter assert interval after no write seconds
_db_block_vlm_check	       FALSE			      TRUE			     check for mapping leaks (debugging only)
_db_cache_miss_check_les       FALSE			      TRUE			     check LEs after cache miss
_db_cache_mman_latch_check     FALSE			      TRUE			     check for wait latch get under MMAN ops in kcb
_db_block_chunkify_ncmbr       FALSE			      TRUE			     chunkify noncontig multi block reads
_db_cache_wait_debug	       0			      1 			     trace new kslwaits
_db_block_iterations_for_rm    2000			      20			     number of blocks to reduce every iteration for RM
_db_dump_from_disk_and_efc     0			      2 			     dump contents from disk and efc
_assert_encrypted_tablespace_blocks TRUE			      FALSE	             if TRUE, assert encrypted tablespace blocks must be encrypted

_high_intrinsic_scn_growth_alert 1440			      60			     high intrinsic SCN growth rate alert time in minutes

compatible		       18.0.0			      12.2.0.0.0		     Database will be completely compatible with this software ve
											     rsion

_num_rlslaves		       2			      16			     number of rl slaves to clear orls
_use_single_log_writer	       TRUE			      ADAPTIVE			     Use a single process for redo log writing
_max_pending_scn_bcasts        8			      9 			     maximum number of pending SCN broadcasts
_gc_trace_freelist_empty       FALSE			      TRUE			     if TRUE, dump a trace when we run out of lock elements
_auto_export_preplugin_backup  TRUE			      FALSE			     auto export pre-plugin backup
_time_based_rcv_ckpt_target    180			      0 			     time-based incremental recovery checkpoint target in sec
_time_based_rcv_hdr_update_int 180			      0 			     time-based incremental recovery file header update interval
erval											     in sec

_nologging_sendbuf_ratio       90			      99			     Nologging standby: outstanding send buffer ratio
_nologging_sdcl_append_wait    200			      100			     Nologging standby append sdcl wait time
_shadow_lost_write_found       118			      22			     Specify shadow lost write error handling

_imtxn_table_enable	       TRUE			      FALSE			     is In-Memory Txn Table cache enabled

_compression_compatibility     18.0.0			      12.2.0.0.0		     Compression compatibility
_dbg_scan		       0			      2048			     generic scan debug
_inmemory_subcusize	       512			      0 			     In-memory subCU size
_inmemory_fsdw_schedlrtm       1			      10			     in-memory faststart defer write scheduler cycle (sec)
_inmemory_repopulate_disable   2			      FALSE			     disable In-memory repopulate
_inmemory_repopulate_flags     2			      0 			     In-memory repopulate decision flags
_inmemory_dynamic_scans        AUTO			      DISABLE			     Enable IM Dynamic Scans
_imado_optimize_period	       0			      20			     IM-store optimize period for AIM (in minutes)
_kql_clientlocks_enabled       15			      1 			     clients allocating DLM memory

_pdb_service_on_root_listener  FALSE			      TRUE			     pdb services on CDB ROOT listeners
_cursor_db_buffers_pinned      76			      2 			     additional number of buffers a cursor can pin at once

_qesma_mvob_lru_sz	       25			      0 			     size of MVOB LRU list for QESMA session cache
_qesma_bo_lru_sz	       25			      0 			     size of base object LRU list for QESMA session cache

optimizer_features_enable      18.1.0			      12.2.0.1			     optimizer plan compatibility parameter
audit_trail		       DB			      NONE			     enable system auditing

_optimizer_undo_cost_change    18.1.0			      12.2.0.1			     optimizer undo cost change
parallel_threads_per_cpu       1			      2 			     number of parallel execution threads per CPU
_parallel_adaptive_max_users   4			      2 			     maximum number of users running with default DOP

_qa_lrg_type		       0			      1 			     Oracle internal parameter to specify QA lrg type
_bloom_folding_min	       0			      128			     bloom filter folding size lower bound (in KB)
_smm_isort_cap		       102400			      0 			     maximum work area for insertion sort(v1)
_sqlmon_max_plan	       20			      160			     Maximum number of plans entry that can be monitored. Default
											     s to 20 per CPU

parallel_servers_target        20			      64			     instance target in terms of number of parallel servers
_px_chunklist_count_ratio      32			      8 			     ratio of the number of chunk lists to the default DOP per in
											     stance

_emon_outbound_connect_timeout 7200000			      30000			     timeout for completing connection set up to clients
_emon_send_timeout	       7200000			      10000			     send timeout after which the client is unregistered
_aq_pt_processes	       10			      15			     Partition background processes
_asm_disable_proact_client_cle FALSE			      TRUE			     disable proactive client cleanup
anup

_asm_disable_patch_compat      FALSE			      TRUE			     disable DG patch compatibility checks
_asm_allow_prepare_split       TRUE			      FALSE			     Allow database prepare and split in non-appliance mode

target_pdbs		       1			      2 			     Parameter is a hint to adjust certain attributes of the CDB
max_pdbs		       254			      4098			     max number of pdbs allowed in CDB or Application ROOT
_cdb_disable_pdb_limit	       FALSE			      TRUE			     CDB Compatible
_cdb_special_old_xplan	       TRUE			      FALSE			     display old-style plan for CDB special fixed table
_upgrade_optim		       TRUE			      FALSE			     Upgrade optimization enabled
_upgrade_capture_noops	       TRUE			      FALSE			     do not skip capturing noops during upgrade
_enable_containers_subquery    TRUE			      FALSE			     enable transformation to containers() sub query

供大家参考了。

相关文章|Related Articles

• ATP-Oracle自治事务处理(OLTP)数据库与自动索引优化
  
• Oracle 18.3 版本参数比较12.2 看新特性优化诊断增强
  
• Oracle18.3:透过告警日志从安装初始化过程看 18c 的新改变
  
• Oracle 18c 安装ORA-12754 Runtime Environment的两种解决方案
  
• 极速体验:Oracle 18c 下载和Scalable Sequence新特性