PeopleSoft, Oracle y un DBA sin suerte

Si eres un administrador de bases de datos Oracle, es posible que tengas que manejar bases de datos PeopleSoft. Son bases de datos grandes, complejas, que de pronto se les acaba el espacio temporal o se incrementa varias veces el tiempo de procesamiento usual, volviendo loco al administrador de bases de datos Oracle en el proceso.

En resumen, para soportar otros motores de bases de datos PeopleSoft usa tablas normales como tablas temporales y las etiqueta en la tabla PSRECDEFN como rectype=7, por lo tanto no puedes simplemente recolectar estadísticas de objetos como usualmente se hace debido a que las tablas temporales crecen mucho y se quedan vacías bastante rápido. Primero que nada, tienes que usar el script del apéndice A del PeopleSoft Enterprise Performance on Oracle 10g Database Red Paper, y si lees el documento completo valdrá la pena el tiempo invertido.

Esto es lo que sé de primera mano. El problema es que algunas veces este procedimiento especial de recolectar estadísticas no es suficiente y de todas formas tienes los problemas arriba mencionados, pero un compañero administrador de bases de datos Oracle después de analizar un montón de reportes de AWR, concluyó que ayuda recolectar estadísticas de los siguientes objetos:

DBMS_STATS.GATHER_TABLE_STATS (
   OWNNAME            => 'SYSADM',
   TABNAME            => 'PS_GP_ITER_TRGR',
   estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
   method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
   DEGREE             => DBMS_STATS.AUTO_DEGREE,
   CASCADE            => TRUE);

DBMS_STATS.GATHER_TABLE_STATS (
   OWNNAME            => 'SYSADM',
   TABNAME            => 'PS_GP_RUNCTL',
   estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
   method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
   DEGREE             => DBMS_STATS.AUTO_DEGREE,
   CASCADE            => TRUE);

DBMS_STATS.GATHER_TABLE_STATS (
   OWNNAME            => 'SYSADM',
   TABNAME            => 'PS_GP_CAL_RUN',
   estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
   method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
   DEGREE             => DBMS_STATS.AUTO_DEGREE,
   CASCADE            => TRUE);

DBMS_STATS.GATHER_TABLE_STATS (
   OWNNAME            => 'SYSADM',
   TABNAME            => 'PS_GP_PYE_PRC_STAT',
   estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
   method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
   DEGREE             => DBMS_STATS.AUTO_DEGREE,
   CASCADE            => TRUE);

DBMS_STATS.GATHER_TABLE_STATS (
   OWNNAME            => 'SYSADM',
   TABNAME            => 'PS_GP_HST_WRK',
   estimate_percent   => DBMS_STATS.AUTO_SAMPLE_SIZE,
   method_opt         => 'FOR ALL COLUMNS SIZE AUTO',
   DEGREE             => DBMS_STATS.AUTO_DEGREE,
   CASCADE            => TRUE);

analyze index SYSADM.PS_GP_PYE_SEG_STAT compute statistics;
analyze index SYSADM.PSAGP_PYE_PRC_STAT compute statistics;
analyze index SYSADM.PS_GP_PYE_PRC_STAT compute statistics;

No estoy seguro por qué este procedimiento resuelve problemas de desempeño y espacio temporal, pero funciona para mi y el administrador de bases de datos Oracle que escribió este procedimiento es muy bueno, por lo que podría funcionar para ti también.

Pusimos este procedimiento como un job diario en una base de datos PeopleSoft y en general trabaja bien, pero aún así hay problemas de vez en cuando con esta base de datos; esto me lleva a pensar que este procedimiento debe ejecutarse antes de programar una tarea de PeopleSoft grande o compleja ya que ejecutando este procedimiento no aparece ningún problema. Lo que quiero decir es que si tienen que correrse dos o más trabajos complejos de PeopleSoft en un día, sería mejor ejecutar este procedimiento antes de correr cada trabajo de PeopleSoft.