All Things Oracle

Las paradojas del tiempo

En esta ocasión les voy a contar sobre un problema muy singular y la forma en que fue resuelto, estoy seguro que muchos usuarios de AIX 6.1, y quizás de otras plataformas, deben tener este problema y no lo han notado aún. La historia se remonta a unos meses atrás, había concluido el upgrade de una base de datos desde Oracle 10.2.0.3 hacia Oracle 11.2.0.2.3, que era la versión más reciente en ese momento, y luego de ello nos percatamos de que los tiempos de respuesta se habían deteriorado, sin explicación alguna. Como el upgrade incluyó la migración de la base de datos a un nuevo servidor, empezamos a hacer algunas pruebas usando ambos servidores y ambas versiones de Oracle y finalmente logramos reducir el problema al uso de SYSDATE, con los resultados que se muestra a continuación.
DECLARE
  v_dt DATE;
BEGIN
  FOR i IN 1 .. 1000000 LOOP
    SELECT SYSDATE INTO v_dt FROM dual;
  END LOOP;
END;
/

Antiguo servidor
10.2.0.3:
Elapsed: 00:00:32.17

11.2.0.2.3:
Elapsed: 00:00:41.09

Nuevo servidor
11.2.0.2.3:
Elapsed: 00:00:56.89

Noten como en el antiguo computador, Oracle 11.2 toma 28% más tiempo en procesar que Oracle 10.2, y en el nuevo computador la situación es más grave aún pues toma 78% más tiempo, esto considerando que el nuevo computador es el doble de rápido que el antiguo!

Como el problema era evidente recurrimos a Oracle Support, quienes finalmente nos recomendaron hacer upgrade al reciente Oracle 11.2.0.3, lo que hicimos inicialmente en el antiguo servidor, con el siguiente resultado:

La situación mejoró notablemente y ya se observaban tiempos similares a los que Oracle 10.2.0.3 proporcionaba, así que iniciamos el upgrade del servidor de producción hacia Oracle 11.2.0.3. Grande fue nuestra sorpresa cuando luego de ello encontramos lo siguiente:

La mejora solo fue de 9%, terrible, inexplicable, desalentador. Fue entonces que Oracle sacó su as bajo la manga y nos indicó aplicar el patch para el bug 12596494 GENERALLY HIGHER CPU USAGE IN 11.2.0.2 THAN 10.2.0.4 11.2.0.3.0 IBM AIX on POWER Systems (64-bit), que ya habíamos aplicado en Oracle 11.2.0.2.3 pero que no había sido resuelto aún en 11.2.0.3. Con la esperanza de que finalmente resolveríamos el problema lo aplicamos en el servidor de producción, obteniendo el siguiente resultado:

Aún con el patch aplicado, el tiempo era 34% superior al que Oracle 10.2.0.3 lograba en el antiguo servidor, con procesadores mucho más lentos que el de producción.

Ya se nos habían agotado todas las ideas, pero como bien dicen: cuando está todo más oscuro, es porque está por amanecer, y fue justo en este momento que IBM hizo su aparición: un Ingeniero de IBM de Argentina nos dirigió al APAR IZ86764 PERFORMACE DIFFERENCE WHEN USING OLSON TZ .VS. POSIX TZ:

Problem summary
Doc change noting performance impact when using Olson time zone instead of Posix time zone.

Problem conclusion
There will be new information added to the "Miscellaneous tunable parameters" section under "Tunable parameters – Environment variables" in the Performance Management Guide regarding the Olson time zone, basically stating that TZ in AIX 6.1 and later are defaulted to Olson time zone, and may be tuned to POSIX time zone for performance sensitive applications that do not depend on adequately handled changes to time zone rules and daylight saving time.

¡Bingo! Comparando el antiguo y el nuevo servidor encontramos:
[root@old.server]$ oslevel –s
5300-07-00-0000
[root@old.server]$ echo $TZ
EST5 (POSIX)

[root@new.server]$ oslevel –s
6100-06-05-1115
[root@new.server]$ echo $TZ
America/Lima (OLSON)
En efecto, esa era la diferencia entre ambos servidores, el antiguo usaba un TZ del tipo Posix, a diferencia del nuevo, que usaba TZ del tipo Olson, así que de inmediato hicimos el cambio:
/etc/environment
#TZ=America/Lima
TZ=EST5
Y a continuación realizamos la prueba de rigor, con el resultado:

Finalmente logramos que el proceso se ejecutara en menos tiempo, siendo 88% más rápido con respecto a los tiempos observados en el antiguo computador, ¡problema resuelto!

Algún tiempo después he tenido la oportunidad de trabajar con instalaciones similares (AIX 6.1 con Oracle 11.2), en las que venían trabajando con TZ del tipo Olson y sin aplicar patch alguno, por lo que me temo que para la gran mayoría de usuarios de esta combinación el problema no ha sido notado aún y por consiguiente no tienen el desempeño que podrían tener.

Hasta acá llegamos por ahora, espero que con lo indicado logren obtener mejoras en sus instalaciones, quizás esto ocurre también en otras plataformas, de ser así por favor compartan su experiencia por este medio, les estaremos muy agradecidos, ¡hasta la próxima!

¿Te pareció interesante este artículo?, ¿te quedaron algunas dudas?, ¿quieres sugerirme un tema a tratar?, pues déjame tus comentarios o ¡contáctame ahora mismo!

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.

Posts Relacionados

Articulo publicado en ToadWorld, sobre cómo superar la falta de archived logs para sincronizar un standby.
El evento enq: CF - contention podría resolverse con mantenimiento al controlfile si este contiene gran numero de registros de archived logs.
Si el optimizador escoge planes de ejecucion ineficientes en queries que usan MAX o MIN, es posible que se trate del bug 5611962.

¿Necesitas Ayuda?

Completa estos datos y estaré en contacto a la brevedad.