1. Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> Performance Tuning Guide -> 1 Performance Tuning Overview -> Introduction to Performance Tuning Features and Tools
2. Existen numerosas herramientas para optimizar la BD (Tuning). Algunas de estas herramientas se ven en los siguientes objetivos, como SQL Tuning Advisor o SQL Access Advisor. A continuación se detallan practicamente todas las herramientas y características que ofrece Oracle para hacer Tuning de la BD. Algunas de ellas requieren licencias adicionales, aunque no es necesario instalar nada para utilizarlas.
· Herramientas de traza
· Sistema de alertas integrado
· Repositorio AWR
· Monitor de Diagnóstico ADDM
· Histórico de Sesiones Activas (ASH)
· Herramientas de Performance dentro de OEM
· Vista de rendimiento V$ (V$ Performance Views)
· Advisors adicionales (Memoria, Segmentos y Undo)
· SQL Tuning Advisor*
· SQL Access Advisor*
· SQL Performance Analyzer*
· Database Replay**
· Oracle Statspack***
* Estas herramientas tienen objetivos dedicados así que se ven por separado
** Database Replay no entra dentro del examen
*** No vamos a ver Statspack ya que AWR es predominante en Oracle 11g
3. Las herramientas de traza nos sirven para monitorizar y analizar la actividad de las aplicaciones contra la base de datos. Nos aportan información para identificar la raiz de un problema de carga de trabajo excesiva, como pude ser una sentencia SQL problemática, una sesión «rebelde», etc…
Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> Performance Tuning Guide -> 21 Using Application Tracing Tools
El ejercicio que vamos a realizar incluye la activación de las estadísticas y trazas de una sesión. Empezamos con la parte de estadísticas. En general esto es muy útil, pero muchas veces el equipo de desarrollo se olvida de instrumentar las acciones que realiza en la BD, y luego es complicado monitorizar y diagnósticar un problema. Así que corre de nuestra cuenta «evangelizar» a Desarrollo para que se acostumbre a rellenar la información como CLIENT_IDNTIFIER, MODULE y ACTION.
# Para esta prueba es importante conectarnos a través del servicio OCM
sqlplus hr/hr@OCM
-- Seteamos las columnas CLIENT_IDENTIFIER, MODULE_NAME y ACTION_NAME
EXEC DBMS_SESSION.SET_IDENTIFIER ('HR');
EXEC DBMS_APPLICATION_INFO.SET_MODULE ('HR.MODULE', 'HR.ACTION');
-- Comprobamos desde otra sesión que la configuración es correcta
-- Ej.:
-- SID SERIAL# CLIENT_IDE MODULE ACTION SERVICE_NAME
-- -------- ---------- ---------- --------------- --------------- ---------------
-- 158 821 HR HR.MODULE HR.ACTION OCM
--
COL CLIENT_IDENTIFIER FORMAT A10
COL MODULE FORMAT A15
COL ACTION FORMAT A15
COL SERVICE_NAME FORMAT A15
SELECT SID, SERIAL#, CLIENT_IDENTIFIER, MODULE, ACTION, SERVICE_NAME
FROM V$SESSION WHERE CLIENT_IDENTIFIER = 'HR';
-- Habilitamos estadísticas y trazas para dicha sesión
-- Podemos habilitar estadísticas por el campo CLIENT_IDENTIFIER
EXEC DBMS_MONITOR.CLIENT_ID_STAT_ENABLE(client_id => 'HR');
-- También se puede agrupar estadísticas por SERVICE, MODULE y ACTION
EXEC DBMS_MONITOR.SERV_MOD_ACT_STAT_ENABLE(service_name => 'OCM', module_name => 'HR.MODULE', action_name => 'HR.ACTION');
-- Lanzamos una consulta de ejemplo en la sesión anterior
SELECT SUM(SALARY) FROM EMPLOYEES;
-- Ya podemos consultar las estadísticas que se han generado
-- Primero revisamos la estadísticas por CLIENT_IDENTIFIER
SELECT * FROM V$CLIENT_STATS;
-- Además podemos obtener las estadísticas globales de todas las sesiones que pertenecen a un servicio
SELECT * FROM V$SERVICE_STATS WHERE SERVICE_NAME='OCM';
-- Luego podemos sacar estadísticas en función del MODULE y ACTION por separado
SELECT * FROM V$SERV_MOD_ACT_STATS WHERE MODULE='HR.MODULE' AND ACTION='HR.ACTION';
A través del Enteprise Manager es bastante sencillo identificar y monitorizar las estadísticas por cualquiera de las agrupaciones que hemos visto. Otra ventaja adicional es que no tenemos que activar las estadísticas. Una vez entramos en la página de estadísticas ya se han activado.
Click «Databases» ->
-> Click «OCM» ->
-> Click «Performance» ->
-> Click «Search Sessions» ->
-> Aquí podemos buscar por SID o cualquier otro campo de V$SESSION ->
-> «Specify search criteria using WHERE clause = «MODULE = ‘HR.MODULE'» ->
-> Click «Go» ->
-> Nos aparece nuestra sesión y podemos hacer click en Sid, Service, Module o Action ->
-> Click «HR.ACTION» ->
-> Vemos las estadísticas
-- Deshabilitamos las estadísticas EXEC DBMS_MONITOR.CLIENT_ID_STAT_DISABLE(client_id => 'HR'); EXECUTE DBMS_MONITOR.SERV_MOD_ACT_STAT_DISABLE(service_name => 'OCM', module_name => 'HR.MODULE', action_name => 'HR.ACTION');
4. Para habilitar trazas existen múltiples opciones. Hago un resumen de como habilitar y deshabilitarlas con los métodos más usados.
-- En 11g se recomienda utilizar DBMS_MONITOR EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 158, serial_num => 821, waits => TRUE, binds => TRUE); EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(session_id => 158, serial_num => 821); -- También se pueden habilitar trazas por SERVICE, MODULE y/o ACTION EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_ENABLE(service_name => 'OCM', module_name => 'HR.MODULE', action_name => 'HR.ACTION', waits => TRUE, binds => TRUE); EXECUTE DBMS_MONITOR.SERV_MOD_ACT_TRACE_DISABLE(service_name => 'OCM', module_name => 'HR.MODULE', action_name => 'HR.ACTION'); -- En nuestra propia sesión tenemos varias formas de hacerlo ALTER SESSION SET SQL_TRACE=TRUE; ALTER SESSION SET SQL_TRACE=FALSE; EXEC DBMS_SESSION.SET_SQL_TRACE(SQL_TRACE => TRUE); EXEC DBMS_SESSION.SET_SQL_TRACE(SQL_TRACE => FALSE); ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'; ALTER SESSION SET EVENTS '10046 trace name context off'; -- Para ver una lista más extensa de las opciones que tenemos para habilitar trazas adjunto esta URL -- · http://www.oracle-base.com/articles/misc/sql-trace-10046-trcsess-and-tkprof.php -- Se pueden habilitar trazas para toda la BD (no recomendado para entornos con mucha carga) -- Habilitamos trazas para toda la BD con información de esperas y Bind Variables EXECUTE DBMS_MONITOR.DATABASE_TRACE_ENABLE(waits => TRUE, binds => TRUE); -- Deshabilitamos trazas EXECUTE DBMS_MONITOR.DATABASE_TRACE_DISABLE(); -- Una vez hemos habilitado las trazas, podemos obtener el nombre del fichero en la vista V$DIAG_INFO -- Ej.: /u01/app/oracle/diag/rdbms/ocm/OCM/trace/OCM_ora_24242.trc SELECT VALUE FROM V$DIAG_INFO WHERE NAME LIKE '%Trace File%';
Una vez que tenemos el/los fichero/s de traza/s podemos abrirlos y estudiarlos directamente. Normalmente se recomienda utilizar las herramientas trcess y tkprof porque agrupan y muestran la información de una forma más «amigable».
-- Lanzamos las siguientes para generar dos ficheros de trazas distintas
-- Hemos generado dos ficheros de trazas diferentes
-- · /u01/app/oracle/diag/rdbms/ocm/OCM/trace/OCM_ora_30574.trc
-- · /u01/app/oracle/diag/rdbms/ocm/OCM/trace/OCM_ora_30576.trc
CONN HR/hr@OCM
EXEC DBMS_SESSION.SET_IDENTIFIER ('HRTRACE');
ALTER SESSION SET SQL_TRACE=TRUE;
SELECT SUM(SALARY) FROM EMPLOYEES;
ALTER SESSION SET SQL_TRACE=FALSE;
SELECT VALUE FROM V$DIAG_INFO WHERE NAME LIKE '%Trace File%';
-- Ejecutamos el codigo dos veces para demostrar posteriormente el comando trcsess
CONN HR/hr@OCM
EXEC DBMS_SESSION.SET_IDENTIFIER ('HRTRACE');
ALTER SESSION SET SQL_TRACE=TRUE;
SELECT COUNT(*) FROM DEPARTMENTS;
ALTER SESSION SET SQL_TRACE=FALSE;
SELECT VALUE FROM V$DIAG_INFO WHERE NAME LIKE '%Trace File%';
Ahora vamos a utilizar trcsess y tkprof sobre los ficheros de trazas.
# Nos movemos al directorio de trazas de usuario cd /u01/app/oracle/diag/rdbms/ocm/OCM/trace/ # Agrupamos los ficheros de trazas en base al identificador de cliente trcsess clientid=HRTRACE > trazasHR.trc # Ejecutamos tkprof para interpretar el fichero generado # · Eliminamos todo el SQL recursivo como SYS=NO # · Obtenemos los planes de ejecución para cada consulta, por eso necesitamos el argumento EXPLAIN tkprof trazasHR.trc trazasHR.tkp sys=no explain=hr/hr # Ya podemos abrir el fichero para ver las estadísticas, planes de ejecución y operaciones de forma resumida cat trazasHR.tkp
5. Una característica muy importante que aporta Oracle son las alertas. En el Alert Log se muestran eventos críticos que pueden afectar a la BD, como la parada y arranque de la BD, la modificación de parámetros de sistema, errores internos (ORA-00600), corrupción de bloques (ORA-01578), Deadlocks (ORA-00060), llenado del area FRA, problemas con el refresco de vistas materalizadas, etc, etc…
Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> Administrator’s Guide -> 8 Monitoring Database Operations
En el directorio del Alert Log (parámetro BACKGROUND_DUMP_DEST) se generan también ficheros de trazas automáticamente con de procesos críticos como LGWR, DBWR, … Cuando tenemos un problema en la BD es recomendable ir a este directorio, revisa los últimos mensajes del Alert Log y chequear si hay alguna traza de algún proceso crítico que sean recientes.
Por último, podemos consultar la vista DBA_OUTSTANDING_THRESHOLDS cuando haya algún problema, ya que contendrá información de los problemas activos que existan en la BD.
6. El repositorio AWR nos puede dar información muy valiosa para diagnosticar problemas de rendimiento de la base de datos. Se suele utilizar para identificar problema generales a nivel de instancia ya que todas las estadísticas que ofrece se corresponde con toda la actividade la BD en un periodo determinado. Por lo que la actividad de una única sesión, aunque presente un problema de rendimiento, puede enmascararse entre todas las estadísticas de la instancia y pasar desaparcibido.
Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> Performance Tuning Guide -> 5 Automatic Performance Statistics
-- Los siguientes parámetros son necesarios para el correcto funcionamiento de AWR -- STATISTICS_LEVEL = TYPICAL -- TIMED_STATISTICS = TRUE SHOW PARAMETER STATISTICS_LEVEL SHOW PARAMETER TIMED_STATISTICS -- Por defecto, la retención de la información en el repositorio es de 8 días -- · SNAP_INTERVAL control la frecuencia de generación de SNAPSHOTS -- · RETENTION controla el perido de retención de cada SNAPSHOT SELECT * FROM DBA_HIST_WR_CONTROL; -- Podemos modificar la frecuencia (30 días) y retención de generación de SNAPSHOTS (cada 15 minutos) EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(RETENTION => 43200, INTERVAL => 15, TOPNSQL => 100); -- Para generar un SNAPSHOT manualmente (útil cuando queremos un informe entre dos momentos concretos) EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- Estos son los scripts más utilizadas para generar informes AWR -- Script para generar un informe AWR @?/rdbms/admin/awrrpt.sql -- También se puede generar un AWR de una BD con RAC @?/rdbms/admin/awrgrpt.sql -- Script para generar un informe de una instancia concreta en RAC @?/rdbms/admin/awrgrpti.sql -- Podemos generar un informe AWR (parcial) de una sentencia SQL concreta (a partir del SQL_ID) @?/rdbms/admin/awrsqrpt.sql -- En ocasiones nos interesará comparar dos informes entre dos periodos distintos -- Comparar periodos en la instancia local @?/rdbms/admin/awrddrpt.sql -- Comparar informes en una BD en RAC @?/rdbms/admin/awrgdrpt.sql -- Una buena práctica es almacenar un conjunto de informes AWR (BASELINE) cuando la BD tiene una actividad normal -- Cuando surja un problema de rendimiento, podemos comparar la actividad actual de la BD con el BASELINE -- Creamos un BASELINE para guardar los SNAPSHOTS de 1153 a 1156 EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(START_SNAP_ID=>1153,END_SNAP_ID=>1156,BASELINE_NAME=>'OCM_BASELINE'); -- Veamos como se borra el BASELINE EXEC DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE(BASELINE_NAME=>'OCM_BASELINE'); -- También se pueden borrar SNAPHOSTS a mano, aunqune lo recomendable es que se purguen automáticamente por la retención establecida EXEC DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE(LOW_SNAP_ID=>1153, HIGH_SNAP_ID=>1154);
7. Ya en la versión 10g se introdujo la vista V$ACTIVE_SESSION_HISTORY. Cada segundo se guarda una muestra de las sesiones activas que aparecen en V$SESSION en memoria. Se accede a esta información a través de la vista V$ACTIVE_SESSION_HISTORY. Es un buffer circular que se va reciclando en memoria, pero una muestra de cada 10 se almacena en los snapshots de AWR, accesible a través de la vista DBA_HIST_ACTIVE_SESS_HISTORY. Se pueden lanzar consultas muy potentes sobre esas dos vistas para analizar la actividad de la BD en el pasado. Por ejemplo, podemos consultar las sesiones que estaban siendo bloqueadas buscando por el evento «enq: TX – row lock contention».
-- Con una consulta rápida, podemos ver la distribución de los eventos de las sesiones activas de la última hora con el SQL_ID SELECT SQL_ID, SESSION_STATE, EVENT, COUNT(*), ROUND(RATIO_TO_REPORT(COUNT(*)) OVER() * 100,1) PCT FROM V$ACTIVE_SESSION_HISTORY WHERE SAMPLE_TIME > SYSDATE-1/24 AND SESSION_TYPE='FOREGROUND' GROUP BY SQL_ID, SESSION_STATE, EVENT ORDER BY COUNT(*) DESC / -- Podríamos reemplazar V$ACTIVE_SESSION_HISTORY por DBA_HIST_ACTIVE_SESS_HISTORY para consultar todo el AWR SELECT SQL_ID, SESSION_STATE, EVENT, COUNT(*), ROUND(RATIO_TO_REPORT(COUNT(*)) OVER() * 100,1) PCT FROM DBA_HIST_ACTIVE_SESS_HISTORY WHERE SESSION_TYPE='FOREGROUND' GROUP BY SQL_ID, SESSION_STATE, EVENT HAVING COUNT(*) > 10 ORDER BY COUNT(*) DESC / -- De formas similar a los informes AWR, podemos generar informes AWR del periodo que deseemos -- Este informe nos sirve para sacar información de la actividad de las sesiones (Top Sessions, Top Blocking Sessions, ...) @?/rdbms/admin/ashrpt.sql
8. Continuamos con las distintas herramientas que tiene Oracle para el diagnóstico y monitorización del rendimiento de Orcle. En la versión 10g introdujeron el monitor ADDM (Automatic Database Diagnostic Monitor). Cada vez que se genera un SNAPSHOT de AWR, se invoca al monitor ADDM para analizar las estadísticas del snapshot, diagnosticar posibles causas raiz de problemas de rendimiento que detecte y proporcionar recomendaciones para solucionarlos. Se recomendia que la salida de ADDM sea el primer lugar que el DBA debe mirar cuando se le notifica un problema de rendimiento.
Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> Performance Tuning Guide -> 6 Automatic Performance Diagnostics
El monitor ADDM toma como partida dos SNAPSHOTS de AWR para generar los informes. Por defeco se utilizan los dos últimos SNAPSHOTS generados, pero podemos lanzar el informe manualmente para definir el intervalo que queramos. Tenemos dos formas sencillas de invocar ADDM.
-- Generamos un informe con el paquete DBMS_ADDM -- Hemos utilizado el procedimiento ANALYZE_DB pero también tenemos disponibles estos otros: -- · ANALYZE_INSTANCE para generar un informe ADDM de una instancia -- · ANALYZE_PARTIAL para generar un informe de un subconjunto de instancias DECLARE tname VARCHAR2(20); BEGIN tname := 'TEST_ADDM'; DBMS_ADDM.ANALYZE_DB(:tname,1169,1170); END; / -- Mostramos el informe generado -- Este informe nos puede indicar recomendaciones como aumentar la SGA, SQL problemáticas, etc... SET LONG 10000000 PAGESIZE 0 SELECT DBMS_ADDM.GET_REPORT(:tname) FROM DUAL; -- Otra formas más sencilla aún de generar el informe es utilizar el script addmrpt.sql @?/rdbms/admin/addmrpt.sql
Las siguientes vistas pueden ser útiles para revisar la información de ADDM:
· DBA_ADVISOR_FINDINGS
· DBA_ADDM_FINDINGS
· DBA_ADVISOR_FINDING_NAMES
· DBA_ADVISOR_RECOMMENDATIONS
· DBA_ADVISOR_TASKS
9. La herramienta de Enterprise Manager, ya sea Grid Control o Database Control, es muy eficaz en algunas ocasiones para diagnosticar un problema. Se accede a través de la pestaña «Performance» una vez dentro de la instancia. La gráfica «Average Active Sessions» es muy intuitiva y a golpe de vista podemos detectar problemas en Enqueues, CPU excesiva, … Además si nos fijamos el gráfica, lo que se presenta es la actividad media de las sesiones activas ordenadas por clase de espera. Por ejemplo, si una sesión está siendo bloqueada el 100% del tiempo, veremos una franja roja de 1 unidad (1 CPU) continua. Además podemos interactuar con el gráfico para ir hasta el problema.
La documentación que adjunto utiliza Enterprise Manager con muchos ejemplos para resolver distintos problemas de rendimiento.
Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> 2 Day + Performance Tuning Guide
-- Vamos a generar un bloqueo sencillo para analizarlo con OEM -- En una sesión bloqueamos todas filas de la tabla empleados SELECT * FROM HR.EMPLOYEES FOR UPDATE; -- En otra sesión intentamos modificar los salarios un 10% -- La segunda sesión se queda a la espera de que la primera finalice la transacción y libere los bloqueos UPDATE HR.EMPLOYEES SET SALARY=SALARY*1.10
Vamos a OEM a la pestaña de «Performance» para ver como aparece una franja roja de 1 unidad (1 CPU).
Click en «Blocking Sessions» ->
-> Aquí podemos ver el árbol de bloqueos y matar la sesión bloqueante si queremos ->
-> Click «Hang Analysis» ->
-> Vemos una representación gráfica del árbol ->
-> Click «Top Activity» ->
-> Nos sale una muestra de las SQL con más actividad y las sesiones ->
-> Click SQL_ID «8brd8qcyufqnk» ->
-> VEremos nuestra consulta y podemos hacer muchas tareas con ella (optimizarla, etc..) ->
-> Click «Top Activity» ->
-> Click «Blocking Session» ->
-> Seleccionamos la primera sesión ->
-> Click «Kill Session» ->
-> Seleccioanmos «Kill Immediate» ->
-> Click «Yes»
10. Las vistas de rendimiento V$ contienen muchísima información. Muchas veces hay tanta información que cuesta moverse entre ellas para resolver un problema. Oracle tiene un curso de una semana de duración que comprende bastante teoría, técnicas y ejemplos concretos. Es imposible condensar 30-40 horas de formación en este punto. Pero os recomiendo leeros la siguiente documentación con los ejemplos incluidos para conocer las principales vistas V$ de rendimiento que hay y como utilizarlas.
Documentación en Tahiti -> Oracle Database, 11g Release 2 (11.2) -> Masters Book List -> Performance Tuning Guide -> 10 Instance Tuning Using Performance Views
11. En los próximos objetivos vamos a ver diferentes Advisors (SQL Tuning, SQL Access y SQL Performance Analyzer) y en este mismo objetivo ya hemos visto el Advidor ADDM. Pero hay muchos más. La lista completa la podemos sacar de la vista DBA_ADVISOR_DEFINITIONS. Casi todos los advisors comentados ya existen paquetes específicos para invocarlos (DBMS_ADDM, DBMS_SQLTUNE y DBMS_SQLPA), excepto SQL Access Advisor. El paquete DBMS_ADVISOR sirve para este último y todos los que no hemos visto aun. La forma más rápida de utilizar cuaquier Advisor es a través de Enterprise Manager.
-- Listamos todos los ADVISORS disponibles para ejecutar con DBMS_ADVISOR -- Para ADDM, SQL Tuning Advisor y SQL Performance Analyzer utilizaremos sus paquetes respectivos SELECT * FROM DBA_ADVISOR_DEFINITIONS;
Veamos un ejemplo de ejecución de un Advisor con OEM y otro con el paquete DBMS_ADVISOR. En el primero ejemplo vamos a utilizar el Advisor de memoria para ver si tenemos correctamente dimensionada la BD.
Click «Databases» ->
-> Click «OCM» ->
-> Click «Advisor Central» en la sección inferior ->
-> Click «Memory Advisors» ->
-> Click «Advice»
Vemos un gráfico donde la línea azul marca el porcentaje de mejora en función del aumento de memoria. En mi caso cuando se llega al máximo no hay mejora alguna, por lo que no habría necesidad de aumentar la memoria. La siguiente prueba consiste en lanzar el Advisor de gestión de UNDO a través del paquete DBMS_UNDO.
-- Obtenemos los dos últimos SNAPSHOTS Id
SELECT MAX(snap_id)-1, MAX(snap_id) FROM dba_hist_snapshot;
-- Lanzamos el Advisor de UNDO
DECLARE
tid NUMBER;
tname VARCHAR2(30) := 'Undo Advisor';
oid NUMBER;
BEGIN
DBMS_ADVISOR.CREATE_TASK('Undo Advisor', tname, 'Undo Advisor Task');
DBMS_ADVISOR.CREATE_OBJECT(tname, 'UNDO_TBS', null, null, null, 'null', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'TARGET_OBJECTS', oid);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'START_SNAPSHOT', 1176);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'END_SNAPSHOT', 1177);
DBMS_ADVISOR.SET_TASK_PARAMETER(tname, 'INSTANCE', 1);
DBMS_ADVISOR.execute_task(tname);
END;
/
-- Comprobamos el estado de la tarea
SELECT TASK_NAME, STATUS FROM DBA_ADVISOR_TASKS WHERE TASK_NAME='Undo Advisor';
-- Mostramos los resultados
SELECT * FROM DBA_ADVISOR_FINDINGS WHERE TASK_NAME='Undo Advisor';
SELECT * FROM DBA_ADVISOR_RECOMMENDATIONS WHERE TASK_NAME='Undo Advisor';
12. El Advisor de UNDO, al igual que los de memoria, es mucho más sencillo utilizarlo a través del Enterprise Manager.
Vamos a la página principal de EM ->
-> Click «Databases» ->
-> Click «OCM» ->
-> Click «Advisor Central» ->
-> Click «Automatic Undo Management» ->
-> Analysis Time Period = «Last One Day» (podemos coger otros intervalos) ->
-> Seleccionamos «Specified manually to allow for longer duration queries or flashback» ->
-> Duration = «2 hours» ->
-> Click «Run Analysis» ->
-> Comprobamos en el apartado inferior las recomendaciones (Minimum Undo y Recommended Undo) ->
-> Podemos ver más información en formato gráfico haciendo Click en «Show Graph»