First details on the Oracle patches
Oracle has provided InfoWorld with additional information about the "inoculation" patch mentioned in the original story. When applied to an Oracle database instance, the patch causes the database to refuse connection with other databases that have SCN values Oracle considers too close to the SCN soft limit. In effect, a second soft limit is introduced.
In mathematical terms, without the patch, an Oracle database allows a connection from another database as long as the transmitted SCN is x-1 or lower, but not x or x+1 (x equals the SCN soft limit during the second at which the connection was attempted). The patch prevents a connection from a database if the connecting database has an SCN value of x-y, where y equals a time value -- a value that Oracle has declined to reveal to InfoWorld.
The patch will indeed prevent a database from accepting an elevated SCN that could cause that database to hit the soft limit during normal processing and cause problems ranging from lost transactions to a database shutdown. But it may also interfere with normal operations if the calling database has an elevated SCN acquired through a bug or other means. This means that a database with a sufficiently elevated SCN may not be able to link with patched databases until enough time has elapsed to push its SCN below the new, second limit.
In rolling out the patches in its January 2012 Critical Patch Update, Oracle revoked a patch described in "Fundamental Oracle flaw revealed" that increased the SCN soft limit multiplier to 32,768 and allowed admins to further increment that multiplier. According to Oracle, "this capability was withdrawn by Oracle as it potentially can incur more problems than it solves, as further outlined in the story," such as the potential for two databases working with different multipliers to refuse connection.
This means that Oracle is stuck with the 16,384 multiplier for the foreseeable future, unless it can come up with a way to completely segment databases that use the higher calculation from ever linking with databases that use the lower calculation.
Then there's Moore's Law: What happens when a single Oracle database instance becomes capable of averaging more than 16,384 transactions per second? As we now know, in highly interconnected environments, multiple instances working in tandem are already closing in on that limit. Servers that have two or three times the processing power of today's fastest servers could further shorten the distance between a high SCN value and the SCN soft limit, posing a special risk to environments where SCN levels are already running hot.
If SCN values were easy to reset, this discussion would be moot. But the fact remains that rebuilding a database is the only way we know of (or that Oracle has disclosed) to roll back the SCN value. Otherwise, customers can shut down systems for a period of time to allow the SCN limit to increase -- an impractical solution for most high-end database environments.
Given the number of undocumented features we have encountered in the course of this investigation, we invite other Oracle experts who may have more information to contact InfoWorld.
This article, "The Oracle flaw: Clarifications and more information," was originally published at InfoWorld.com. Follow the latest developments in business technology news and get a digest of the key stories each day in the InfoWorld Daily newsletter. For the latest business technology news, follow InfoWorld on Twitter.