Recientemente para solucionar un problema en producción identificado como un bug (solventable con el Path Set 10.2.0.4) , ha sido necesario upgradear la BD Oracle de la versión 10.2.0.1 a 10.2.0.5 (ya puestos nos vamos al último Patch Set).

Después de la instalación del Path Set 10.2.0.5 para Linux 64 bits, que se realizó sin problemas y upgradear los catálogos de las bases de datos, todo parecía ir sobre ruedas.

De momento el parámetro COMPATIBLE se mantuvo con la versión original 10.2.0.1.

Los problemas surgieron aproximadamente un día más tarde cuando un report dejó de funcionar, el alert muestra:

Source

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] [] []

Buscando en el fichero de traza mencionado en el alert, se encuenta una inocente sentencia que hasta ahora funcionaba (y seguía funcionando en desarrollo que todavía no se ha upgradeado):

Source

*** 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

Cual es mi sorpresa que al conectarmen a Metalink y buscar el problema no aparece nada aplicable a la versión 10.2.0.5. Era el momento de abrir un SR, pero la verdad es que se podía palpar la tensión en el ambiente y la velocidad en la resolución de la incidencia era lo más importante.

En el entorno de preproducción (que también estaba aplicado el Patch Set 10.2.0.5 y el problema era totalmente reproducible), se probó:

1. Reconstruir todos los índices.
2. Generar estadísticas de toda la BD.
3. Verficaron todos datafiles.

Todo sin éxito pero si permitió descartar cualquier error físico o de almacenamiento, bueno pues si no había un problema en los datos, era bastante posible que el problema estaba en como se accedía a ellos.

Se modifica el parámetro COMPATIBLE a 10.2.0.5, también sin éxito.

Antes de la aplicación del Path Set el parámetro:

Source

optimizer_features_enable

No estaba definido, esto implica que toma valor por defecto de la versión de los binarios, antes de la aplicación tomaba:

Source

optimizer_features_enable='10.2.0.1'

Después del Patch Set pasa a:

Source

optimizer_features_enable='10.2.0.5'

Se fuerza el uso del optimizador de 10.2.0.1 con:

Source

ALTER system SET optimizer_features_enable='10.2.0.1' SCOPE=memory;

Y el problema queda solucionado, toda una alegría!!!.

Se hacen permanentes los cambios:

Source

ALTER system SET optimizer_features_enable='10.2.0.1' SCOPE=spfile;

Se aplica la solución a producción.

En resumidas cuentas el problema se soluciona simplemente cambiando el parámetro OPTIMIZER_FEATURES_ENABLE=’10.2.0.1′, sin modificar el paŕametro COMPATIBLE.

Como siempre que se aplica un parche/upgrade, se solucionan algunos problemas pero se introducen otros… es algo que no tiene fin que refuerza mi teoría de que, si funciona bien la BD no parche/upgrade a no ser que sea por motivos de fuerza mayor.