SYSDATE y las paradojas del tiempo

SYSDATE y las paradojas del tiempo

Por Enrique Orbegozo
Publicado en abril 2012
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:

Elapsed: 00:00:32.62

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:

Elapsed: 00:00:51.53

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:

Elapsed: 00:00:43.43

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 addeded 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:

Elapsed: 00:00:17.19

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 podrian 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.