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.89Noten 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.62La 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.53La 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.43Aú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.
[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)/etc/environment
#TZ=America/Lima
TZ=EST5Elapsed: 00:00:17.19Finalmente 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!