The controlfile sequence# has now reached architectural limit

A test database (an out of support 11.2.0.4) running in noarchive log mode had the following message on the alert log.

*************************************************************************
ATTENTION: The controlfile sequence# has now reached 4294967295 (0xffffffff),
           which is the architectural limit. Further controlfile updates
           are no longer possible. To resume normal database operation
           it is necessary to shutdown abort all instances and perform
           the steps described in Doc ID 20324049.8 at My Oracle Support
           to reset the controlfile sequence# to 1.
*************************************************************************
Errors in file /opt/app/oracle/diag/rdbms/uat/uat/trace/uat_ora_28299.trc  (incident=1295436):
ORA-00600: internal error code, arguments: [kccfhb_3], [4294967295], [], [], [], [], [], [], [], [], [], []
Incident details in: /opt/app/oracle/diag/rdbms/uat/uat/incident/incdir_1295436/uat_ora_28299_i1295436.trc

In this situation database would not mount, only starting with nomount mode is possible.
The MOS doc 20324049.8 mentioned in the message is helpful in resolving the issue.
The workaround option given in it, which is to set the db_unrecoverable_scn_tracking=false did not work. It is mentioned in the MOS that setting this parameter is a proactive step not a reactive. So once the issue has occured this workaround is of no help.



The solution is to backup the controlfile to a trace file and then use it to recreate the controlfile. But for this the database must be (at least) in mount mode. As stated earlier database cannot be mounted at this stage. So opted to create a control file backup of a different database. Then modified that trace file by replacing the database name, online logfile and datafile names and locations with the names and locations from the problem database. Then started the database in nomount mode without setting the db_unrecoverable_scn_tracking parameter (MOS doc states "after installing this fix" without specifying what it is). Ran the create contfolfile script which resulted in new control files being created. Finally recover and open the database (without resetlogs). This resolved the issue and database is able to function as before without incuring any data loss.
The MOS doc mentions ORA-00227 associated with this issue. There were no ORA-00227 messages on the alert log. It was associated only with an ora-6000 [kccfhb_3] which is listed in the MOS doc as one of the symptoms of this issue.

Useful MOS doc
Bug 20324049 - ORA-227 Controlfile Corruption when reaching Maximum Value for Control Seq kccfhcsq [20324049.8]