1/20/2012 - Announced Oracle SCN bug in 11G may cause db's to become unstable and unrecoverable. Some issues in older Db's, but not as severe.
ISSUE Details:
While taking Manual physical hot back ,SCN cause the DB become unstable and un recoverable.
But Oracle 11G evidently has a major bug in 11G regarding how SCN is treated and incremented during backups.
But Oracle 11G evidently has a major bug in 11G regarding how SCN is treated and incremented during backups.
Oracle doesn’t clearly state whether the issue exists RMAN backups. The 11G Backup Database command “ALTER DATABASE BEGIN BACKUP” is messing up the way SCN in incremented and can artificially raise it above a “soft” limit built into the RDBMS.
At that point the db becomes unstable and possibly unrecoverable. This issue first appeared in the rags on 1/20/2012. But it is getting a lot of press since some companies have already encountered the issue. Evidently there are other problems which can also cause SCN sequence issues in 11G and earlier oracle db’s. But in most cases these never cause issues. The backup command bug in 11G was causing the SCN to increase by “billions”.
Affected Environment:
Versions 9.2.0.8 – 11.2.0.3
Per the articles:
“Oracle released a patch to fix the arbitrary SCN growth rate bug in the hot backup code before InfoWorld began researching this story. The backup bug is listed as 12371955: "High SCN growth rate from
ALTER DATABASE BEGIN BACKUP in 11g."
ALTER DATABASE BEGIN BACKUP in 11g."
If you have not already done so, Oracle recommends that you install this patch immediately. (The hot backup bug is confined to Oracle Database 11g releases 11.1.0.7 and 11.2.0.2.)
The SCN is a moving line that cannot be crossed. The line moves up by 16,384 every second; as long as the SCN growth rate is slower, all should be well.
The SCN is a moving line that cannot be crossed. The line moves up by 16,384 every second; as long as the SCN growth rate is slower, all should be well.
(Note: Oracle has provided a script that allows customers to identify which databases are at risk. The script is referenced in support document 1393363.1.)”
These articles also noted that oracle’s January CPU release includes a series of patches that remove various methods of increasing the SCN and implement a new method of “inoculation” for oracle databases. These patches also were put in the Oracle 10G CPU’s because some of the SCN growth issues may be present in that and older version of Oracle. But only the 11G version had the backup bug which was causing most of the problem.
These articles also noted that oracle’s January CPU release includes a series of patches that remove various methods of increasing the SCN and implement a new method of “inoculation” for oracle databases. These patches also were put in the Oracle 10G CPU’s because some of the SCN growth issues may be present in that and older version of Oracle. But only the 11G version had the backup bug which was causing most of the problem.
Support Documents:
Oracle documents dealing with this issue (all updated on 1/19/2012 or later)
System Change Number (SCN), Headroom, Security and Patch Information [ID 1376995.1]
Installing, Executing and Interpreting output from the "scnhealthcheck.sql" script [ID 1393363.1]
Evidence to collect when reporting "high SCN rate" issues to Oracle Support [ID 1388639.1]
System Change Number (SCN), Headroom, Security and Patch Information [ID 1376995.1]
Installing, Executing and Interpreting output from the "scnhealthcheck.sql" script [ID 1393363.1]
Evidence to collect when reporting "high SCN rate" issues to Oracle Support [ID 1388639.1]
Oracle provides SCN health check scripts from Versions 9.2.0.8 to 11.2.0.3
Output of SCN health check scripts:
SQL> @scnhealthcheck.sql
--------------------------------------------------------------
ScnHealthCheck
--------------------------------------------------------------
Current Date: 2012/02/03 07:56:28
Current SCN: 10394068544046
Version: 11.1.0.7.0
--------------------------------------------------------------
Result: A - SCN Headroom is good
Apply the latest recommended patches
based on your maintenance schedule
AND set _external_scn_rejection_threshold_hours=24 after apply.
For further information review MOS document id 1393363.1
Take the appropriate action as indicated by the "Result":
Refer the below note:
I Hope this article helped you. Suggestions are welcome.