以下文章来源于甲骨文云技术 ，作者祁国辉
甲骨文云技术甲骨文官方数据库相关技术介绍，分享Oracle 数据库、公有云、混合云服务解决方案和大数据领域最新咨讯、前沿技术、专家视点，专家问答交流以及市场活动，第一时间发布甲骨文官方免费资源。
The SCN headroom for this database is only 3 days! 收到这种告警信息怎么处理？本文深入讲解SCN Head Room的原理，希望对大家有帮助。
警告
Warning: The SCN headroom for this database is only 3 days!
很多用户第一次看到这个告警信息的时候，我的数据库怎么了？三天之后，是不是我的数据库就没法继续使用了， 我的业务怎么办？ 别方， 仔细看下面的文章， 让我们细细道来，相信你看完会对SCN Head Room的原理有一个深入的了解。
背景回顾
SCN（System Change Number）是Oracle数据库内部一个单向增长的数字， 用来精确记录所有操作的前后顺序，所以SCN实际上是数据库内部的一个用数字表达的逻辑时钟。而SCN也会被记录在数据库内部的不同位置，来确保数据库是一个完整的整体。
作为数据库内部的逻辑时钟，数据库事务依SCN而排序，Oracle也依据SCN来实现读一致性（Read Consistency）等重要数据库功能。每次数据库事务开始和结束之后，系统都会生成一个唯一的SCN号来标记变化顺序，同时在所有磁盘文件中也会有相应记录；当系统出现崩溃之后， 系统会根据SCN的完整性来决定是否需要做数据库恢复。
SCN在数据库中是唯一的，并随时间而增加，但是可能并不连贯。除非重建数据库，SCN的值永远不会被重置。因而Oracle在开始设计的时候， 定义SCN是一个48位的数字，其最大值是：281,474,976,710,656（281万亿）。为了防止因为软件BUG或者人为恶意修改当前SCN， 导致数据库SCN直接达到最大值，最终必须重建数据库。 Oracle决定限制数据库每秒的SCN变化， 依据当时系统负荷和预测， 定义了一个通用的SCN增长速率， 每秒最大增长不超过16K， 按照这个速率， 281万亿的SCN上限，需要500年才能达到，这个定义叫做Maximum Reasonable SCN Rate，最大可允许SCN增长速率。
按照这个逻辑， 我们就可以计算出一个数据库当前最大可允许SCN的值， 具体算法是（当前时间-1988年1月1日）*24 *3600*16K ，这个数字叫做当前最大可用SCN，事实上， 绝大多数数据库的SCN增长速度不会达到那么高， 一般而言，SCN的增长速度是和数据库繁忙程度相关的， 每次事务之前和之后都会生成新的SCN， 所有数据库的当前SCN会落后于最大可用SCN。 这两个数字之间的差异， 就叫做SCN Head Room。
但是因为数字太大，为了便于理解， 这个差值会按照每秒16K的折算， 再次折算成时间， 所以， 一般而言，我们会看到一个数据库的Head room 还有多少天。 Oracle提供了一个脚本scnhealthcheck.sql 用于检查数据库当前SCN的剩余情况。但是用户也没有必要为了这个天数而感到惊慌， 很多用户听到这个消息会担心， 是不是我的数据库在几天后就不能用了？事实上， 因为最大可用SCN一直在稳定地以每秒16K的速度在增长， 只要用户的SCN增长速率不是持续超过16K， 就不可能出现追上的情况。
常见的SCN异常增长的几种场景如下：
-
数据库持续保持非常高的事务量，因为每次数据库事务至少生成两个SCN， 所以造成SCN高速增长， 但是这种情况比较少见；
-
当用户SQL使用不当， 或者在触发部分SCN相关的BUG之后， SCN可能会出现每秒上百K的剧烈增长， 从而导致SCN Head Room每天缩小几十天， 这是导致SCN HeadRoom 问题的最主要原因；
-
当用户在数据库中使用DBLink， 然后跨DBLINK进行数据查询， 因为要保证两个数据库之间的交易完整性， 两个数据库会进行SCN同步， 支持跨数据库的读一致性。而SCN不能回退， 所以两个数据库会把SCN同步到相对较大的那个SCN。当数据库出现问题二的时候， 首先出问题的数据库自身的SCN会快速增长， 同时所有和这个数据库建立了DBLINK的数据库， 因为同步机制，也会出现SCN剧烈增长， 当有多个数据库都出现问题二的时候， 问题三还可能导致叠加， 从而问题进一步加剧。
当数据库的当前SCN已经到达最大可用SCN的时候， 系统会hang，等待下一秒新的SCN上限， 因为又会有16K可用， 而当数据库RECO正在工作时， 则有可能造成宕机。
Oracle提供了一个脚本 scnhealthcheck.sql 用于检查数据库当前SCN的剩余情况， 同时当你的数据库SCN Head Room不足时， 数据库Alert 日志当中也会有Warning。 考虑到DBlink 同步对SCN 影响较大， Oracle 2012年之后的数据库补丁中都加入了一个新的隐含参数 _external_scn_rejection_threshold_hours , 当外来DBLINK触发SCN同步时， 如果外来SCN远超出当前数据库的SCN ，系统会自动拒绝该请求， 该参数的缺省设置是24小时。 同时远端数据库会提示ORA-19706：invalid SCN。
问题防范
对于SCN Head Room问题， 预防大于治疗， 毕竟SCN一旦上涨， 不可能回退， 所以对于数据库的日常管理，强烈建议按照如下最佳实践进行管理。
-
对于大型复杂环境， 必须严格控制DBLINK的使用， 确保所有的DBLINK都是有意义， 可跟踪，可管理的，同时最好维护一份准确的DBLINK 拓扑图， 以备问题出现时，迅速定位。
-
按照Oracle MOS建议， 确保所有在网数据库都打上了强制SCN补丁。
-
设置隐含参数_external_scn_rejection_threshold_hours=24,避免外来SCN引起SCN剧烈变化。
-
定期运行$ORACLE_HOME/rdbms/admin/scnhealthcheck.sql 检查SCN Headroom 状态。
-
在日常监控软件如OEM中设定监控点和阈值， 当SCN出现剧烈变化时， 及时提醒用户关注， 之前就有用户SCN Head room每天减少20多天居然完全没有发现。
进一步的解决方法
SCN Head room不足的现象在2010年前后集中出现，主要原因是计算机处理能力越来越强， 另外大量跨数据库的分布式事务，也进一步加剧了SCN同步的影响。 Oracle除了提供隐含参数和相关的监控防范机制之外， 也尝试了其他不同的方法， 在11.2.0.2 中把SCN最大增长速率从16K提升到32K， 从而提升SCN Head Room， 但是由于当时市场上10G和11G数据库是混合部署，当用户现网中数据库使用两种不同速率的时候， 容易造成10G数据库的最大用SCN远远低于11G的当前SCN， 从而无法在不同版本建立DBLINK。
但是Oracle并没有放弃解决这个问题的努力， 在后来的版本中， Oracle把SCN从原来的48位改成64位， 这样一来， SCN的空间就大了很多，同时允许Maximum_Reasonable_scn_rate 设为更大的值，设定了一个SCN compatibility 的参数，兼容性特性有4个选项，可以修改为：1、2、3 ,最大增长速率可以设定到每秒96K，这样用户就可以根据实际情况自行选择SCN增长速率，为了让所有用户逐渐过渡到96K Oracle在SCN补丁中启用了一个AUTO_ROLLOVER的机制，为每个 SCN 的兼容性设置了时间点，也就是说，低级别的兼容性将在一定的时间后自动过期，而最终切换时间点设定为2019年6月23日，全世界所有的数据库都将在2019年6月23日统一调整到兼容性 3， （限于打过SCN补丁的11G和所有12C以后的版本）SCN compatibility 3 级允许更高的 SCN 增长率, 但并不改变系统中SCN自身变化的速率，也不会修改当前的SCN，只是让系统在当前时间点可以生成更大的SCN，应对更忙的数据库，更高的事务速率。
对用户的影响
如果所有数据库的事务处理速率没有任何重大变化, SCN都低于低速率的当前最大SCN允许值，应用补丁和未应用补丁的数据之间使用DBLINK还是可以正常的访问，不受应用补丁后允许更大速率的影响。
如果应用了补丁数据允许更大的增长速率，同时因为数据库SCN使用较快比如超过了32K每秒， 那当前SCN如果超过了未打补丁数据库的最大SCN，两个库通过DBLINK访问时就会因为无法同步SCN，而访问会被拒绝。而这种情况需要综合几个条件， 发生的几率不高。
但是由于之后maximum reasonable SCN 增速不一致， 可能会造成DBLINK不可用的情况。
如果96K的数据库和16K的数据库在同一个DBLINK网络里的时候， 如果SCN正常增长， 系统不会有什么影响。
但是当SCN增速较大， 96K速率的数据库当前SCN超过低速率的数据库的最大可允许SCN的时候， 就会出现ORA-19706错误。
行动指南
毕竟6月23日迫在眉睫， 我们需要做哪些事情确保平滑过渡呢？
-
数据库版本为11.1.0.2之前， 包括10G的所有版本， 并且当前数据库与其他高版本数据库有DBLINK通信， 需要升级到支持的版本。
-
如果是11.1.0.7或者11.2.0.3则需要升级到指定的PSU或者更高版本。
-
12.2.0.1和更高版本，11.2.0.4 和12.1.0.2 的patchset 已经包含了该修正。
-
详细情况请参考如下官方文档（可在MOS中搜索 2335265.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)
列表如下 ：
9i 请升级到11.2.0.4 或更高版本
10G 请升级到11.2.0.4 或更高版本
11.2.0.1,11.2.0.2 请升级到11.2.0.4 或更高版本
11.1.0.2 请升级到11.2.0.4 或更高版本
11.1.0.7 PSU 11.1.0.7.20 patch 18522513
11.1.0.7（windows ） Patch 18944208 (Win x64) | Patch 18944207 (Win 32-Bit)
11.2.0.1,11.2.0.2 请升级到11.2.0.4 或更高版本
11.2.0.3 PSU 11.2.0.3.9 Patch 17540582
11.2.0.3（windows） Patch 18075406 （Win X64），Patch 18075405 （win 32）
11.2.0.3（Exadata） Exadata PSU 11.2.0.3.22 Patch 7747147
相关问答
1. 不升级/不打补丁现有DB Link或数据库就必然会有问题吗？
不是！系统SCN的变化是基于系统的繁忙情况，事务的多少和DBLINK的同步， 在打上该补丁后，系统SCN的变化速度并不改变，只是允许系统上支持更繁忙事务和当前SCN允许更大的值，这样在通过DBLINK同步到其他低SCN又未打补丁的系统上时，才会有可能造成DB link访问拒绝或其它未知问题。
2. 升级/打补丁之后DB Link因SCN拒绝或SCN headroom问题就不存在了么？
不是。 该补丁本质只是增大了SCN增长速度和上限限制，如果某系统上依然存在bug或其他原因导致SCN的异常增长， 即使是所有系统都打上了该补丁，DB Link间的SCN同步依然会发生，同样会将SCN的异常传播到整个DB Link网络，SCN Headroom问题依然存在。
3. 对于10.2 版本以及更早版本影响
如果不存在SCN headroom问题和也不存在DB Link 指向已安装补丁的数据库，可以不做任何改变；
2019年6月之后，如果老版本数据库和已安装了补丁并使用了新的SCN兼容性的数据库存在DB Link，如果已安装补丁数据库SCN 使用速度没有变化（虽然已允许更快的速率），老版本的DB Link仍可以正常访问； 如果DB Link 另一端已安装补丁的数据库SCN 增长超过了16K, 可能就会因为DB Link 同步老版本的数据库SCN导致SCN headroom问题甚至拒绝链接，并且那时需要断开这些DB Link连接或升级。Oracle研发目前正在评估为10.2.0.5提供补丁的需求和可行性。
4. 对于11.2.0.4,12.1.0.2和12.2.0.1版本数据库需要做什么？
什么都不用做， 所有需要的修补程序已包含在这些版本中，但是并不是SCN就不会有SCN headroom问题，只是概率非常低，很少有数据库事务率会使用SCN每秒增长超过90多K。
5. 未安装补丁的数据库DBLINK间是否会有问题？
不会， 两个未修复的数据库或两个旧版本的数据库之间，如10204,9i的版本数据DB Link连接不受此更改的影响。
6. 应该优先处理什么样的系统？
综上，我们应该优先处理环境中目前是否存在SCN增长过快的系统和SCN headroom天数较小的系统。建议检查目前环境中的所有数据库的SCN值和headroom是否都大于30天。
如何查看具体的DBLINK信息？
-
所有的数据库版本可以使用DBA_DB_LINKS视图查看现在数据库中存在的DB Link。
-
对于12.1以后的数据库可以查询dba_db_link_sources视图查看。
-
从12.2 版本起数据库提供了DBA_EXTERNAL_SCN_ACTIVITY 视图可以排查SCN 的跳跃信息，更新信息查看MOS note ID 2171090.1。