在InfoWorld独家报道了甲骨文旗舰数据库产品的一个缺陷后，甲骨文介入，新的开发出现
资讯世界出版后"神谕的基本缺陷暴露1月17日，我们收到了甲骨文用户的大量反馈，并咨询了甲骨文的代表，他们一点一点地讲述了这个故事澄清和其他细节，包括关于解决该缺陷的补丁的信息。
此外，数据库服务公司的总裁，公认的甲骨文专家Riyaj ShamsudeenOraInterals，已经把注意力集中在a的缺陷的另一个方面1月20日发表题为“SCN——什么，为什么，如何?”Shamsudeen指出，他已经拖延了“好几个月”才发布这篇博客文章。在提到InfoWorld的文章时，他补充道:“由于这个问题属于公共知识领域，我可以在没有任何后果的情况下分享这些知识。”
(看看原始的故事，”神谕的基本缺陷暴露，包括澄清和附加信息。|还可以看到主编Eric Knorr对Oracle社区的消息:呼叫所有Oracle客户"),
之前解决这一新的发展,快速回顾事情的立场:Oracle已经承认,信息世界发现无证、手动方法来提高Oracle SCN(系统更改号码)——一种“时间戳”对于每一个Oracle事务——这可能导致Oracle数据库的SCN限制和停止正常工作。Oracle还证实了这个故事中的另一个关键点:升高的SCN值可以在Oracle数据库之间传递，因此在高度链接的环境中，这些值可以快速传播。
但甲骨文始终如一地认为，这些问题带来的风险微乎其微。在文章发表几天后的一次谈话中，Oracle数据库产品管理副总裁Mark Townsend告诉InfoWorld，在文章中描述的热备份错误这个故事是Oracle数据库系统达到SCN限制的唯一途径。(这个bug仅限于Oracle数据库11g发布的11.1.0.7和11.2.0.2版本，并被列出为12371955:“高SCN增长率来自于ALTER数据库在11g中开始备份。”)
然而，自从我们与Oracle的最后一次对话之后，我们发现了一种可以手动提升SCN的新方法——并且已经得到了一个附加场景的证实，我们只能在此之前进行推测Shamsudeen在他的帖子中证实了这一点。
SCN的崛起:两种新的可能性从一开始,信息世界”做出了明确区分Oracle的两个方面的缺陷:坏蛋的手工方法可能引起的视交叉上核值数据库,使它达到极限,以及organically 高架SCN号通过一个错误出现的热备份等错误。这两种情况都可能导致相互连接的数据库之间的SCN值急剧增加。
InfoWorld发现的三种手工方法都被Oracle的补丁所阻止2012年1月关键补丁更新，可用于帮助攻击只需要最少特权的Oracle数据库。相比之下，SCN数量增加、扩展和引发问题的风险似乎仅限于数据库高度互连的大型Oracle环境。
现在，第四种人工提升SCN价值的方法出现了。为了保护Oracle客户的安全，我们将不再描述这种方法。
我们相信，更重要的是由Shamsudee描述的SCN值的有机升高这可能发生在紧密相关的环境中。
正如我们在最初的文章中所解释的，Oracle数据库有一个不断变化的“软”SCN限制，这个限制基于自1988年1月1日以来所经过的秒数乘以16,384。即使在今天，也很少有系统能够或将在持续的基础上超过每秒的事务速率——当然不是在24年的时间里每秒都超过。
的确，在当今的高端Oracle安装中，系统每秒会周期性地处理超过16,384个事务——但通常在运行批处理时以突发的方式处理。平均吞吐量要低得多，因此在一个隔离系统中，这些突发事件永远不会使平均SCN数量增加到高于每秒16,384嘀嗒的速度。然而，正如Shamsudeen所描述的，一组相互链接的数据库实际上可以超过这个速率，因为链接数据库通过采用SCN值最高的那个来同步。Shamsudeen这样描述这种现象:
如果许多相互连接的数据库每个都以更高的速率循环生成，问题就来了。DB1在前5分钟内每秒生成20K个SCNs, DB2在接下来的5分钟内每秒生成20K个SCNs, DB3在接下来的5分钟内每秒生成20K个SCNs，以此类推。在这种情况下，所有三个数据库都将保持每秒20K SCNs的速度。数据库正在慢慢地赶上软限制(确切地说，是每4秒1秒)，同样，如果数据库是持续活动的，它们将需要很多年才能赶上软限制。但是，有一个臭名昭著的，我的客户讨厌的，热备份的错误。
换句话说，在相互连接的Oracle环境中，备份错误已经将SCN值提高到接近SCN软限制的程度，这种“乒乓”式的升级最终可能会侵蚀SCN值的危险升高与限制本身之间的差距。
此外，在……之后这个故事一位不愿透露姓名的消息人士向InfoWorld证实，目前至少有一个Oracle环境在现实世界中正在经历这种“乒乓现象”。
显然，在这种情况下使用数据库的Oracle商店需要密切监视SCN级别。Oracle已经发布了新的监视脚本，甚至还发布了一个彩色编码系统，以告知dba他们已经接近SCN的软限制。当SCN值达到Oracle拒绝向InfoWorld指定的某个阈值时，会产生新的警告。该警告建议立即呼叫Oracle支持来解决这个问题;据推测，支持代表推荐的补救措施取决于围绕着升高的SCN的环境。
关于Oracle补丁的第一个细节甲骨文公司向InfoWorld提供了关于原始故事中提到的“接种”补丁的额外信息。当应用到Oracle数据库实例时，该补丁会导致数据库拒绝与其他数据库连接，这些数据库的SCN值被Oracles认为过于接近SCN软限制。实际上，引入了第二个软限制。
在数学术语中，如果没有补丁，Oracle数据库允许从另一个数据库连接，只要传输的SCN是x-1或更低，但不能是x或x+1 (x等于尝试连接时的SCN软限制)。如果连接的数据库的SCN值为x-y，其中y等于时间值——Oracle拒绝向InfoWorld透露这个值，则该补丁将阻止与数据库的连接。
该补丁将确实防止数据库接受SCN升高，因为后者可能导致数据库在正常处理期间达到软限制，并导致从丢失事务到数据库关闭等问题。但是，如果调用数据库通过错误或其他方法获得了一个较高的SCN，那么它也可能干扰正常操作。这意味着SCN足够高的数据库可能无法连接到修补过的数据库，直到有足够的时间将其SCN推到新的第二限制之下。
未来的吞吐量在its中推出补丁2012年1月关键补丁更新， Oracle撤消了在"神谕的基本缺陷暴露这使得SCN的软限制乘法器增加到32,768，并且允许管理员进一步增加这个乘法器。根据Oracle的说法，“Oracle取消了这一功能，因为它可能引发的问题比它解决的问题更多，正如文章中进一步描述的那样”，比如两个数据库使用不同的乘数可能会拒绝连接。
这意味着Oracle在可预见的未来会被16,384乘数所拖累，除非它能够找到一种方法，将使用较高计算的数据库与使用较低计算的数据库完全分割开来。
还有摩尔定律:当一个Oracle数据库实例能够平均每秒处理超过16,384个事务时，会发生什么?正如我们现在所知道的，在高度互联的环境中，多个协同工作的实例已经接近了这个极限。处理能力是当今最快服务器的两到三倍的服务器可能进一步缩短高SCN值和SCN软限制之间的距离，从而给SCN级别已经处于高温状态的环境带来特殊风险。
如果SCN值很容易重置，那么这个讨论就没有意义了。但事实是，重建数据库是我们所知道的(或者Oracle已经披露的)回滚SCN值的唯一方法。否则，客户可以关闭系统一段时间，以允许SCN限制增加——对于大多数高端数据库环境来说，这是一个不切实际的解决方案。
考虑到我们在调查过程中遇到的大量未归档的特性，我们邀请其他有更多信息的Oracle专家与InfoWorld联系。
这篇文章中,“Oracle的缺陷:澄清和更多的信息，最初发表于InfoWorld.com。遵循商业科技新闻的最新发展并在每天的报纸上获得重要新闻的摘要信息世界每日简报。最新商业科技资讯，在Twitter上关注InfoWorld。
阅读更多有关安全的内容在信息世界的安全频道。
这个故事，“甲骨文的缺陷:澄清和更多的信息”最初是由信息世界 。