Since InfoWorld published "Fundamental Oracle flaw revealed" on Jan. 17, we've received abundant feedback from Oracle users and consulted with Oracle representatives, who went through the story point by point, offering clarifications and additional details, including information about the patches that address the flaw.
Moreover, recognized Oracle expert Riyaj Shamsudeen, president of the database services company OraInterals, has zeroed in on another aspect of the flaw in a Jan. 20 post entitled "SCN -- What, why, and how?" Shamsudeen notes that he had held off posting the blog entry "for many months." In a reference to InfoWorld's article, he adds: "Since this issue is in the public knowledge domain, I can share the knowledge without any repercussions."
[ See the original story, "Fundamental Oracle flaw revealed," which includes clarifications and additional information. | Also see Editor in Chief Eric Knorr's message to the Oracle community: "Calling all Oracle customers." ]
Before we address this new development, a quick recap of where things stand: Oracle has acknowledged that InfoWorld uncovered undocumented, manual methods to raise the Oracle SCN (System Change Number) -- a sort of "time stamp" for every Oracle transaction -- which could cause an Oracle database to hit the SCN limit and cease to function properly. Oracle also corroborates another key point in the story: that elevated SCN values can be passed among Oracle databases, so that in heavily linked environments, those values may spread quickly.
But with steadfast consistency, Oracle has characterized the risk posed by these problems as minimal. In a conversation several days after publication, Oracle's Mark Townsend, vice president of database product management, told InfoWorld that the hot-backup bug described in the story was, in all likelihood, the only way Oracle Database systems might reach the SCN limit. (That bug is confined to Oracle Database 11g releases 126.96.36.199 and 188.8.131.52 and is listed as 12371955: "High SCN growth rate from ALTER DATABASE BEGIN BACKUP in 11g.")
Since our last conversation with Oracle, however, we have discovered a new method by which the SCN might be manually elevated -- and have received corroboration for an additional scenario we could only speculate about until Shamsudeen confirmed it in his post.
SCN rising: Two new possibilities
From the outset, InfoWorld has made a clear distinction between two aspects of the Oracle flaw: Manual methods by which a bad actor might raise the SCN value of a database and cause it to hit the limit -- and organically elevated SCN numbers that occur through a bug such as the hot backup bug. Both cases can result in extreme SCN value increases among interconnected databases.