As with any upgrade it is very important to have as proper test plan to test your application prior to a database upgrade. DBA's try to work with their application teams to ensure that the test are fair and balanced and go thru many weeks of planning before actually upgrading a major system.
One thing many DBA's do as a precautionary measure is to ensure that a backout plan is in place. For most it might includes backup, flashback or both. Once other medium of protecting your self is the compatibility parameters. After an upgrade the compatibility parameter is most often not changed till the application is stable. The compatibility parameter to a lower value allows for potentially downgrading your database.
But what if your application testing was done with the compatibility parameter not set to the right version. This can cause a lot of headaches for the DBA's and the Application teams that are testing/
Compatibility parameters not only change the redo logs and the control file structure but also allow for oracle to take new code paths. Something that was very painfully evident to us when we migrated from 10.2.0.4 to 11.2.0.2 RAC. The compatibility changed actually caused us a lot of instability due to some new processes that oracle introduced. This change caused us to go from a fully stable system to crashing down every couple of hours.
Unfortunately there is no easy remedy for changing the compatible parameter and we had to work thru the issues. A lesson well learned for us. Testing needs to be done with compatibility changes done on dev and test to ensure process behaviour does not change
