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 10.2.0.4 I would have the compatible set to 10.2.0.4.
So upon upgrading to the 220.127.116.11 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 18.104.22.168, 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], , [22.214.171.124.0], , , , , , , , 
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 126.96.36.199.0 incompatible with ORACLE version 188.8.131.52.0 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 184.108.40.206 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 220.127.116.11. 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 18.104.22.168.