jueves, febrero 05, 2009

Una migración siempre tiene su complicación




Os voy a contar un caso real que demuestra que por mucho que prepares una migración, Murphy está siempre al acecho y tarde o temprano tus usuarios descubrirán un error.


Si puedes, solucionarás el problema, y después pensarás en lo que puedes hacer la próxima vez para que ese tipo de error no vuelva a ocurrir.

Este error que os presento es prácticamente imprevisible por eso creo que tiene interés.

Hace unos meses realizamos una importante migración en la empresa. Pasamos de Oracle 9i a Oracle10g. Ya dejé constancia de un bug Oracle.
El bug se detecto en las pruebas realizadas en laboratorio (entorno de pruebas) y no resultó muy problemático ya que Oracle lo tenía identificado, había un parche, y también había un patchset superior que no tenía el problema. La cosa salió bien porque había un laboratorio previo a la migración. Lección aprendida de migraciones anteriores.

Ahora bien, para lo que hemos descubierto esta semana no hay laboratorio que valga. Ni hay una estrategia que asegure el éxito.

Resulta que en Oracle, de toda la vida, cuando hacías un GROUP BY el resultado salía ordenado por los campos que componen el GROUP BY.

Pues en Oracle10 esto ya no es así. La explicación que dan es que la ordenación en las versiones anteriores se producía por el plan de ejecución utilizado por el optimizador. En Oracle10g ha cambiado el método y por lo tanto también el plan de ejecución. Todo ello produce que la salida no salga ordenada.

Solución: Modificar los GROUP BY de todas las aplicaciones incluyendo la ordenación ORDER BY.

Solución2: pan para hoy y hambre para mañana, y además no utilizamos las mejoras del optimizador:
Modificar uno de los siguientes parámetros init/spfile:
"_gby_hash_aggregation_enabled" = false
o
optimizer_features_enabled=9.2.0
o
optimizer_features_enabled=8.1.7
Cuidado: Oracle avisa que a pesar de modificar estos parámetros no se puede asegurar la ordenación clásica.

Saludos.

P.D.: más información en el Doc ID ORACLE: 345048.1 ('GROUP BY' DOES NOT SORT IF YOU DON'T USE ORDER BY IN 10G).

1 comentario:

David Fernández dijo...

Yo había pasado por alto siempre esto ya que soy de los que poner el ORDER BY muy a menudo, pero tras ver esto lo tendré en cuenta.