在微博上，一个国外的技术专家写道：最新的跨物种传播 - 该病毒（COVID-19）从人类跃入数据库，在那里造成了严重的麻烦。
这条微博引发了热议，并引发了网友对于 Oracle 数据库中 2252 这一错误的广泛兴趣，到底是什么问题被认为是 Oracle 数据库中的 COVID-19 ?
作者进一步声明：
No jokes please. This is a serious matter.
According to the bug note, SMON is recovering from COVID-19.
Is PMON infected as well?
Can the virus jump to SMONs of other instances running on the same server?
Can it spread over interconnect?
翻译一下是：
请不要开玩笑。 这是一个严重的问题。
根据错误说明，SMON正在从COVID-19中恢复。
PMON也被感染了吗？
病毒可以跳到同一服务器上运行的其他实例的SMON吗？
它可以通过中间互连传播吗？
其实 2252 是 Oracle 数据库中由来已久的问题。
详细内容可以参考墨天轮技术文章：https://www.modb.pro/db/5907
首先 Oracle SCN （System Commit Number）可以通过 DB Link 的互联进行同步，如果某个数据库（传染源）具有异常高的 SCN，也会因此被同步到所有互联的数据库中，也就是具备传播性。再加上 SCN 具有上限，一旦达到上限，则数据库事务将无法进行，限于停摆。所以 ORA-600 2252 就是指 Oracle 为事务计算出来的 SCN 号是不合理的数值，无法指定，数据库服务就中断了。
那么 DB Link 在数据库中用的有多广泛呢？ 云和恩墨 Bethune 专有特性展示的 DB Link 图谱可能会让您大吃一惊。
下图是来自真实场景的报告，所有的数据库都被连接在一起，而且 SCN 都贴近上限，最后通过艰苦的整改工作，才能够帮助用户彻底规避这一安全风险：
这一问题在过去几年大量用户都遇到了，Oracle 也发布了相关的补丁修正，解决这一问题，云和恩墨在过去处理过与此相关大量的突发情况，直到 2020年，仍然有很多用户在被这个问题困扰。
Oracle 在 12.2 版本中，改进了 SCN 算法，通过 BigSCN 将 6 Bytes 的 SCN 提升到 8 Bytes 的长度，从而让 SCN 具备了高扩展性，这一改变值得 DBA 们关注。
关于这个系列的问题，参考专栏：https://www.modb.pro/topic/564
