Compatible Calamity

What do you tend to set your compatible parameter to? There is a school of thought that after you upgrade you should keep it to the previous version for a while just to make sure you have no regression straight after the release. Obviously this can preclude you from utilising various new features.

So when you do decide to bump up the compatible number what do you tend to set it to? I’ve tended to stick to the full version numbering, e.g. with a 10gR2 database that had been patched up to I would have the compatible set to

So upon upgrading to the release I would also have compatible set to this value. The compatible parameter is not a dynamic parameter it needs a database restart to take effect. Upon bumping up this parameter in an 11gR2 RAC database running with ASM storage (and an spfile on ASM) to be, matching the release number, the following happened:

SQL> startup
ORA-00600: internal error code, arguments: [kck_rls_check must use (11,0,0,0,0) or lower], [kdt.c], [9419], [], [], [], [], [], [], [], [], []

That’s not good.

The database was humming along nicely when compatible was set to 11.2.0 so lets try setting the compatible back to be just 11.2.0. Maybe I was pushing it going for that extra .1:

SQL> startup
ORA-00201: control file version incompatible with ORACLE version
ORA-00202: control file: '+DATA1/dba/control01.ctl'

There really is no going back on compatible, once you’ve gone up, you are up and there is no coming back down again. At this point I was starting to consider restore options, this was a test database so wiping was not a problem.

However, Oracle is not actually complaining about the compatible parameter itself, it’s not that setting compatible to be is actually the root of the issue.

Thankfully it was metalink to the rescue with note 1064264.1. It’s a bug related to an underscore parameter _compression_compatibility which it seems can’t handle being set to If it’s unset it seems to default to the same value as the compatible parameter. However you can set this explicitly to the lower value of 11.2.0 while leaving the compatible parameter still set to the higher value.

And lo your database will start again. As I said this was in testing, for production I decided to stick with 11.2.0 and not go messing with underscore parameters for that extra .1. Apparently this bug is marked as fixed in 12.1. I have not as yet tested with


One thought on “Compatible Calamity

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s