As mentioned, the risk of such a scenario playing out is very small except in large, highly interconnected environments where an elevated SCN can flow like a virus from server to server. But once a server is infected, there's no going back. Also, if the SCN is incremented arbitrarily -- or manually, with malicious intent -- then that 48-bit integer hard limit is suddenly not as astronomical as it might seem.
The community reaction
InfoWorld contacted a number of Oracle sources for this story. Several lacked familiarity with the problem; others noted that Oracle licensing agreements prevented them from commenting on any aspect of their product usage. The head of the Independent Oracle User Group (IOUG), Andy Flower, offered this statement on the record: "This bug with the SCN number is obviously something our membership would be concerned about -- and will need to consider what sort of challenges that may present and if any mitigation strategies will be needed. I'm sure it will be a topic that some of our larger members will probably get together and discuss."
Among the Oracle experts we spoke with, Shirish Ojha, senior Oracle DBA for Logicworks, a hosting and private cloud service provider, was the most familiar with SCN issues, including the bug numbers associated with the problem. He acknowledges that although few Oracle environments are likely to encounter the problem, the consequences may be severe. "If there is a dramatic jump in SCN due to any Oracle bug, there is a minimalistic probability of breach of this seemingly high number," said Ojha, who has earned the coveted title of Oracle Certified Master. "If this occurs in a high-transaction and large interconnected Oracle architecture, this will render all interconnected Oracle databases useless in a short period of time."
Ojha continues: "If this occurs, even though its probability is low, the potential [financial] loss ... is very high." By definition, he said, the problem has the potential to affect only large Oracle customers. But "once the SCN limit is reached, there is no easy way to get out of the problem, other than shutting down all databases and rebuilding databases from scratch."
Anton Nielsen, the president of C2 Consulting and an Oracle expert, focused on the potential risk of malicious attack using an elevated SCN: "In theory, the elevated SCN attack is similar to a DoS attack in two significant ways: It can bring a system to its knees, rendering it inoperable for a significant period of time, and it can be accomplished by a user with limited permissions. While a DoS can be perpetrated by anyone with network access to a Web server, however, the elevated SCN requires a database username and password with the ability to connect."
The Oracle reaction
When we first contacted Oracle about the SCN issue, Mark Townsend, vice president of database product management, offered this reaction to our discovery of a low-privilege method to arbitrarily increase the SCN: "The way that you're putting these [issues] together is nothing that we've seen ... we need to understand what it is that you're doing to raise the SCN by trillions. Obviously I need to have some time to have the dev people look at that. "
After much discussion and exchange of technical data, Oracle acknowledged that there were ways to increase the SCN at will. Referring to one method, Townsend said, "This is an undocumented, hidden parameter, so it was never intended for customers to discover and use this."