Fundamental Oracle flaw revealed??? Really …?

This Infoworld article from Jan 17, 2012  Fundamental Oracle flaw revealed did alert Oracle database customers.Infoworld has raised this issue to Oracle before going public with it. Patches are included in the Jan 2012 CPU and PSU. So again, it’s strongly recommended to apply the Jan 2012 PSU (or CPU if you are just asking for security fixes) to your environments.

• Please read on OTN the Critical Patch Update Advisory from January 2012
• You’ll find an explanation from Oracle Support in
  MOS Note:1376995.1: Information on the System Change Number (SCN) and how it is used in the Oracle Database

What is the background of this issue?
Everything in an Oracle database is dependent on the SCN (System Change Number). This number is crucial to ensure read consistency. It will always be just incremented and is defined as a large 48-bit integer (281 trillion SCNs). But the SCN can jump as well – especially in cases of distributed transactions. Besides that hard limit there’s also a soft limit for the SCN (see the MOS Note for more information).

Hot backup bug
Now there’s a backup bug which will increment the SCN to a much higher value once ALTER DATABASE BEGIN BACKUP gets used. We call this putting tablespaces into hot backup mode. Actually I’d assume that most people out there (at least those doing backups on a regular basis) use RMAN – and RMAN does not need to put anything into hot backup mode when creating online backups as the real downside of the hot backup mode is an increased value of log information.
Strong recommendation: Use RMAN! And you may apply patch 12371955: “High SCN growth rate from ALTER DATABASE BEGIN BACKUP in 11g” to your environment.

Combination of backup up and distributed transactions
The people who’ve detected this issue paint now a large Oracle database infrastructure to the wall – with many databases running distributed transactions – and a misbehaving BEGIN BACKUP routine in combination. This would elevate the SCN over and over again – on all interconnected databases – over time as the SCN will be synched over and over again – and will do huge jumps because of the backup bug.

What’s the real risk?
I’m not a security expert – but I’ve seen many customer environments in the real world. I’d say (and skilled DBAs gotten interviewed by Infoworld and others stated similar opinions) it may be just a small risk in larger environments where many databases are connected together – and CPUs or PSUs got not applied on a regular basis. The PSU/CPU fix will prevent the SCN to be incremented in extensive jumps by several ways.
I’d completly disagree with Infoworld’s prediction that databases will crash or abandon – transactions won’t be executed anymore and an error will be raised. Yes, this is bad enough – true – but the database(s) will remain open.

What should you do?
Apply the January 2012 PSU or CPU and hot backup fix covered by patch 12371955. But keep in mind

• Take the PSUs over CPUs as PSUs will contain also important non-dictionary changing fixes whereas CPUs contain security fixes only
• You can’t put a CPU on top of a previous applied PSU
• Both CPUs and PSU are cummulative
• And well, you’ll need Extended Support to get acces to PSUs or CPUs for Oracle Database 10.1 and 10.2 – and yes, please don’t cry: We’ve asked you to upgrade a looooooong time ago 😉