Recently, to solve a production problem identified as a bug (solventable with Path Set 10.2.0.4) has been necessary to update BD Oracle version 10.2.0.1 to 10.2.0.5 (that matter we are going to last Patch Set).
After installing the Path Set 10.2.0.5 for Linux 64 bits, which went smoothly and update catalogs databases, everything seemed to go perfectly.
At the moment the COMPATIBLE parameter remained with the original version 10.2.0.1.
Problems occurred about a day later when a report stopped working, the alert displays:
Wed Nov 16 09:24:00 CET 2011 Errors in file /u01/oracle10/admin/primaria/udump/primaria_ora_27964.trc: ORA-07445: se ha encontrado una excepción: volcado de memoria [kkecdn()+9776] [SIGSEGV] [Address not mapped to object] [0x00000015C]  
You looking in the trace file mentioned in the alert, you are an innocent sentence so far worked (and still working in development that has not yet been updated):
*** 2011-11-16 09:24:00.828 ksedmp: internal or fatal error ORA-07445: se ha encontrado una excepciÃ³n: volcado de memoria [kkecdn()+9776] [SIGSEGV] [Address not mapped to object] [0x0000015C]   Current SQL statement for this session: SELECT CAD.F_TOMPOS F_TOMPOS1 ,CAD.F_CESE F_CESE ,CAD.X_EMPLEADO X_EMPLEADO4 ,CAD.F_TOMPOSCEN F_TOMPOSCEN ,CAR.D_CARGO D_CARGO FROM SECARDOCEMP CAD ,SECARGOS CAR WHERE ( CAR.C_CARGO = CAD.C_CARGO and cad.f_tomposcen <= sysdate AND CAD.F_TOMPOS <= NVL ( : P_FECHA , SYSDATE ) ) AND ( :X_EMPLEADO3 = CAD.X_EMPLEADO) AND ( :F_TOMPOS2 = CAD.F_TOMPOSCEN) ORDER BY CAD.F_TOMPOS
What is my surprise to find and connect to Metalink nothing appears the problem applies to version 10.2.0.5. It was time to open a SR, but the truth is you could feel the tense atmosphere and speed the resolution of the incident was most important.
In the pre-production environment (which was also applied the 10.2.0.5 Patch Set and the problem was totally reproducible), it was tested:
- Rebuild all indexes.
- Generate statistics entire BD.
- Verification all datafiles.
All unsuccessful but allowed discard any physical storage or error. If there was a problem in the data, it was quite possible that the problem was in how they accessed it.
The COMPATIBLE parameter is modified to 10.2.0.5, also without success.
Before the application of Path Set the parameter:
He was not defined, this implies that takes default version of the binary, before apply Patch Set the value is:
Alter apply Patch Set is:
The use of optimizer is forced to 10.2.0.1:
ALTER system SET optimizer_features_enable='10.2.0.1' SCOPE=memory;
And the problem is solved, a joy !!!.
Changes become permanent:
ALTER system SET optimizer_features_enable='10.2.0.1' SCOPE=spfile;
The solution is applied to production.
In summary the problem is solved by simply changing the OPTIMIZER_FEATURES_ENABLE = ‘10.2.0.1 ‘setting, without changing the COMPATIBLE parameter.
As whenever a patch/upgrade is applied, some problems are solved but others are introduced … it’s something that has no end it reinforces my theory that if successful the BD no patch/upgrade unless it is for reasons force majeure.