在2012第一季度,Oracle发布的CPU补丁中,包含了两个BUG修正,其中一个与SCN有关。
这个BUG的BUG号是:13489660 - DB-10.2.0.5-MOLECULE-020-CPUJAN2012
该BUG修正了SCN的问题,我们先从文件影响上来看看,大量内核相关的文件被更新:
以下是转引InfoWorld上的描述说明:
参考链接:
http://www.infoworld.com/d/security/fundamental-oracle-flaw-revealed-184163-0
http://www.infoworld.com/d/security/the-oracle-flaw-clarifications-and-more-information-184775
http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html
这个BUG的BUG号是:13489660 - DB-10.2.0.5-MOLECULE-020-CPUJAN2012
该BUG修正了SCN的问题,我们先从文件影响上来看看,大量内核相关的文件被更新:
files eygle$ ls -R这个BUG的影响在于,Oracle的SCN可能会被异常的增进,而至于极限,导致数据库无法正常工作,在这种情况下,只能重建数据库。但是这个风险的发生概率低,因为Oracle会在数据库内部控制SCN的合理增长,每秒SCN最多增长16348,这会将SCN控制在一个合理的增长范畴内。
lib rdbms
./lib:
libpls10.a libserver10.a
./lib/libpls10.a:
pef.o pei.o pgmc.o
./lib/libserver10.a:
dmsvma.o k2s.o kjcs.o kkxm.o kpostr.o ncodef.o opiexe.o qeroc.o qmix.o
k2.o kcm.o kjcts.o knl.o ksms.o npi.o psdicd.o qeroi.o qmxtk.o
k2r.o kcs.o kjm.o kpoal8.o kspt.o opial7.o psdpgi.o qerrm.o qxim.o
./rdbms:
lib
./rdbms/lib:
kkxwtp.o ksms.o libknlopt.a
./rdbms/lib/libknlopt.a:
kkxwtp.o
以下是转引InfoWorld上的描述说明:
At the core of the issue is the System Change Number (SCN) in Oracle. This is a number that increments sequentially with every database commit: inserts, updates, and deletes. The SCN is also incremented through linked database interactions.
The SCN is crucial to normal Oracle database operation. The SCN "time stamp" is the key to maintaining data consistency in Oracle, allowing the database to respond to every user's query with the appropriate version of data at every point in time. It functions as the database's clock, so to speak. And like time, the SCN cannot decrement. It must always tick forward.
When Oracle databases link to each other, maintaining data consistency requires them to synchronize to a common SCN. This is necessarily the highest SCN carried by any participating Oracle database instance because the SCN clock cannot run backward -- so database linking causes the SCN in many databases to jump during normal operations. And only very basic permissions are required to make a connection that can cause one database to increment the SCN on another.
The architects of Oracle's flagship database application must have been well aware the SCN needed to be a massive integer. It is: a 48-bit number (281,474,976,710,656). It would take eons for an Oracle database to eclipse that number of transactions and cause problems -- or so you might think.
参考链接:
http://www.infoworld.com/d/security/fundamental-oracle-flaw-revealed-184163-0
http://www.infoworld.com/d/security/the-oracle-flaw-clarifications-and-more-information-184775
http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




