« Oracle Linux 操作系统及数据库的时区机制分析 | Blog首页 | Oracle ACOUG两周年交流活动记 »
Oracle SCN exhaustion BUG - CPU Jan 2012
作者:eygle | 【转载请注出处】|【云和恩墨 领先的zData数据库一体机 | zCloud PaaS云管平台 | SQM SQL审核平台 | ZDBM 数据库备份一体机】
链接:https://www.eygle.com/archives/2012/03/oracle_scn_bug_exhaused.html
在2012第一季度,Oracle发布的CPU补丁中,包含了两个BUG修正,其中一个与SCN有关。链接:https://www.eygle.com/archives/2012/03/oracle_scn_bug_exhaused.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
历史上的今天...
>> 2011-03-22文章:
>> 2006-03-22文章:
>> 2005-03-22文章:
By eygle on 2012-03-22 08:15 | Comments (0) | Backup&Recovery | 2976 |