Plan de ejecución y operaciones destacadas

El plan de ejecución muestra por dónde pasó la sentencia para encontrar las filas y cuánto costó cada paso. El informe separa lo que corresponde a cada operación y destaca las que concentran el trabajo.

Qué muestra la sección

En el detalle de la sentencia, cada plan grabado en el trace se convierte en un bloque Plan de ejecución seguido del hash del plan. El plan sale de las líneas STAT del trace; sin ellas, el bloque no aparece (qué contiene el trace). Debajo del título, De las líneas STAT del trace. o, cuando el mismo plan se grabó más de una vez, plan registrado N veces, se muestra el último. En una sentencia con la etiqueta N variantes, el plan suma las grabaciones de las variantes y muestra las filas de la ejecución grabada más lenta entre ellas, y la nota dice plan registrado N veces, se muestra el registro más lento.

Cuando el plan tiene más de una operación, el bloque Dónde gasta el plan lista las operaciones destacadas, por el valor propio de cada operación, sin el de las operaciones debajo de ella: las que concentran el tiempo o las lecturas lógicas del plan, de la más pesada a la menos pesada.

Cada elemento trae el enlace Id N · operación, la parte del tiempo y de las lecturas lógicas y, cuando la hay, una explicación de lo que suele haber detrás, como Visita la tabla fila a fila a partir del índice: índice poco selectivo o sin las columnas que usa el filtro.

El número de cada operación destacada aparece también en su fila del plan y en el texto de la sentencia, marcando el objeto que lee.

Cómo leerla

La línea STAT trae el tiempo y las lecturas de cada operación sumados a los de las operaciones debajo de ella, que son las que le entregan filas. El informe muestra esos valores acumulados y también los propios, que descuentan las operaciones de abajo.

Oracle mide el tiempo por operación por muestreo, así que el tiempo de una operación puede no cuadrar con el de las operaciones de abajo; las lecturas lógicas se cuentan siempre. Cuando la muestra da un tiempo propio negativo, el informe muestra cero.

En el informe de ejemplo, la operación 1, TABLE ACCESS BY INDEX ROWID T, tiene CR 10 y la operación 2, INDEX UNIQUE SCAN T_PK, justo debajo, tiene CR 2. El LIO propio de la operación 1 es 8, o el 80,0% de las lecturas lógicas del plan, y su tiempo propio es el 98,0% del tiempo.

Filas estimadas y reales

Filas/exec y Estimado se ponen en rojo cuando el optimizador se equivocó en la cantidad de filas por un factor de 10 o más, como dice la nota debajo del plan; un error en una operación de pocas filas no se pone en rojo. Con el puntero sobre el número estimado aparece el error completo, como el optimizador estimó 1 fila por ejecución y llegaron 5.000 (5.000 veces más). La comparación necesita el str= en el trace.

Con la estimación errónea, el optimizador elige mal el orden y el método de join. El hallazgo estimación de filas errónea señala, en las sentencias que pesan en el tiempo total, la operación en la que empieza la estimación errónea, en una rama del plan que trabaja de verdad: el error de abajo se propaga hacia arriba.

La tarjeta de cada operación

Haga clic en una operación para abrir su tarjeta. La consola tiene tarjeta para más de 50 operaciones, como TABLE ACCESS FULL, INDEX RANGE SCAN, NESTED LOOPS, HASH JOIN y SORT ORDER BY; la variante STORAGE de Exadata usa la tarjeta de la operación común. Una operación fuera del catálogo aparece sin botón. La tarjeta trae:

Buena cuando

Cuándo la operación es la elección correcta.

Mala cuando

El patrón que la vuelve cara y su causa habitual.

En el plan, mire

Qué columnas revisar, como las filas de esta operación comparadas con las del index scan justo debajo.

Cuándo preocupa

• Una operación destacada con LIO propio alto y pocas filas: lee demasiados bloques para lo que devuelve. En un acceso por índice, el índice es poco selectivo o no tiene la columna del filtro.
• Exec en los miles en el lado interno de un NESTED LOOPS: la operación se ejecuta una vez por fila del lado externo, y el costo bajo de cada ejecución se convierte en un costo alto en total.
• PW mayor que cero en una ordenación o un hash join: la operación escribió en el TEMP porque la memoria de la sesión no alcanzó.
• Números en rojo: la estimación errónea suele venir de estadísticas desactualizadas, columnas correlacionadas o bind peeking.
• TABLE ACCESS FULL en una tabla grande para devolver pocas filas: falta un índice para el filtro, o no se usa.

El hallazgo operación que concentra el plan señala la primera operación destacada de las sentencias que más pesan en el tiempo total, con el enlace Ver en el plan de la sentencia #n.

Adónde ir después

• Operación 1 del plan de la sentencia #1, en el informe de ejemplo: haga clic en TABLE ACCESS BY INDEX ROWID T para abrir la tarjeta.
• Objetos, para consultar en la base de datos la tabla o el índice de la operación.
• Detalle de la sentencia, para las llamadas y el SQL recursivo.