The three manual methods InfoWorld discovered, which are blocked by patches in Oracle's January 2012 Critical Patch Update, could be used to facilitate an attack on an Oracle database requiring only minimal privileges. By contrast, the risk of elevated SCN numbers spreading and causing problems appears to be confined to large Oracle environments in which databases are heavily interlinked.
Now a fourth method of manually raising the value of the SCN has emerged. In the interest of protecting the security of Oracle customers, we will refrain from describing this method.
More important, we believe, is the organic elevation of the SCN value described by Shamsudeen that could occur in heavily linked environments.
As we explained in the original article, Oracle databases have a constantly moving "soft" SCN limit based on the number of seconds that have elapsed since Jan. 1, 1988, times the number 16,384. Even today, few systems could or would exceed that per-second transaction rate on an ongoing basis -- and certainly not every second over the course of 24 years.
True, in high-end Oracle installations today, systems periodically process more than 16,384 transactions per second -- but in bursts, typically when running batch processes. Average throughput is much lower, so in an isolated system those bursts could never increase the average SCN number faster than 16,384 ticks per second. Yet as Shamsudeen describes, a group of interlinked databases can indeed exceed that rate, because linked databases synch up by adopting whichever SCN value is highest. Shamsudeen outlines the phenomenon like this:
[The] problem comes if many interconnected databases [are] each generating at [a] higher rate in kind of round-robin fashion. DB1 generates 20K SCNs per second in the first 5 minutes, DB2 generates 20K SCNs per second in the next 5 minutes, DB3 generates 20K SCNs per second in the next 5 minutes, etc. In this case, all three Databases will have a sustained 20K SCNs per second rate. [The] database[s are] slowly catching up to soft limit (1 second per every 4 second exactly) and again, it will take many years for them to catch up to the soft limit assuming the databases are active, continuously. But, there is that infamous, hated by my client, hot backup bug.
In other words, in interlinked Oracle environments where the backup bug has already raised SCN values close to the SCN soft limit, this "ping pong" type of escalation could eventually erode the margin between dangerously elevated SCN values and the limit itself.
In addition, in the wake of the story's publication, a source who asked to remain anonymous confirmed to InfoWorld that at least one Oracle environment was now experiencing this ping pong phenomenon in the real world.
Clearly, Oracle shops with databases in this condition need to monitor SCN levels closely. Oracle has released new monitoring scripts and even a color-coded system to inform DBAs of how close they are to the SCN soft limit. New warnings are generated when SCN values hit a certain threshold that Oracle declined to specify to InfoWorld. The warning advises calling Oracle support immediately to address the issue; presumably, remediation recommended by support reps depends on the circumstances surrounding the elevated SCN.