oracle - ¿Cómo describir un problema de rendimiento en una base de datos relacional?

performance relational-database

Question

Tengo una consulta ejecutándose en una base de datos relacional que no cumple con las expectativas de los usuarios.

¿Qué información debo proporcionar y qué debo evitar para poder recibir una ayuda efectiva en este sitio?

Answer 1

Para Oracle Database, proporcione esta información:

Describir los síntomas del problema.

Describa el comportamiento que causa el problema. ¿Es estable el comportamiento de la consulta o el problema ocurre solo algunas veces, con parámetros específicos o aleatorios simples? ¿Se puede reproducir este comportamiento en un IDE (por ejemplo, SQL Developer)?

Describa el medio ambiente.

Definir la versión exacta de Oracle

 select * from v$version

Describa cómo se conecta a la base de datos: controlador, ORM, lenguaje de programación. Proporcione nombres y / o números de versión.

Describa la consulta.

Publique el texto de la consulta. Intenta simplificar: muestra un ejemplo mínimo reproducible .

Ejemplo: su consulta problemática une 10 tablas. Compruebe si ve los mismos síntomas en una consulta con 9 u 8 combinaciones. Baja hasta que veas los problemas y muestres solo la consulta reducida.

Sí, esto es costoso, ¡pero aumenta enormemente la posibilidad de que reciba soporte! Cuanto más pequeña es la consulta, mayor es la atracción de los seguidores.

Describa el plan de ejecución.

Para obtener el plan de ejecución, ejecute esta instrucción (sustituya el texto de su consulta)

 EXPLAIN PLAN  SET STATEMENT_ID = ''<some_id>'' into   plan_table  FOR
     select * from ....   -- your query here 
 ;

El plan de ejecución se almacena en PLAN_TABLE , para verlo ejecutar esta consulta

 SELECT * FROM table(DBMS_XPLAN.DISPLAY(''plan_table'', ''<some_id>'',''ALL'')); 

Mostrar el resultado completo (no solo la tabla con el plan de ejecución). Extremadamente importante puede ser la sección del predicado y las notas a continuación.

Ejemplo para select * from dual where dummy = :1;

Plan hash value: 272002086

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |
|*  1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------

Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------

   1 - SEL$1 / DUAL@SEL$1

Predicate Information (identified by operation id):
---------------------------------------------------

   1 - filter("DUMMY"=:1)

Column Projection Information (identified by operation id):
-----------------------------------------------------------

   1 - "DUMMY"[VARCHAR2,1]

No corte y pegue el resultado gráfico de su plan de explicación IDE.

¿Es este plan de ejecución el real que se ejecuta?

Lamentablemente no siempre. Hay varias razones por las que el plan de ejecución explicado puede diferir del plan real .

Si tiene dudas (especialmente cuando ve un buen plan, pero la consulta funciona mal), puede extraer el plan del caché de la base de datos que proporciona un SQL_ID .

 SELECT t.* FROM  table(DBMS_XPLAN.DISPLAY_CURSOR(''<SQL_ID>'',null,''ALL'')) t; 

El SQL_ID para una consulta que se está ejecutando actualmente (o se ejecutó en breve y aún se almacena en caché) se puede encontrar con coincidencia de texto y / o el usuario de la base de datos:

select sql_id, sql_fulltext from v$sql a where 
 lower(sql_text) like lower(''%<some identifying part of the query text>%'') 
  and parsing_schema_name = ''<user running the query>'';

Si tiene licencia AWR, puede obtener el plan de ejecución desde allí, incluso para consultas que se ejecutan en el historial.

SELECT t.*
FROM  table(DBMS_XPLAN.DISPLAY_AWR(''10u2rj016s96k''  )) t;

El SQL_ID se puede encontrar usando

select sql_id, sql_text 
from dba_hist_sqltext a 
where lower(sql_text) like lower(''%<some identifying part of the query text>%'')

Describa los datos.

Mostrar el DDL de las tablas e índices en esas tablas.

Mencione si las estadísticas del optimizador se recopilan recientemente y muestran la declaración de recopilación dbms_stats utilizada.

Para las tablas críticas, proporcione información sobre el tamaño del segmento, el número de fila, la partición, ...

Para las columnas utilizadas en el acceso o las uniones, proporcione información sobre el número de valores distintos. Son los valores distribuidos uniformemente o sesgados (por ejemplo, una pequeña cantidad de valores que ocurre con mucha frecuencia y una gran cantidad de valores raros). ¿Define histogramas?

¿Algo más?

Por supuesto, esto es solo lo básico y aún puede ser necesaria otra información, como estadísticas del sistema o parámetros del optimizador. Pero una vez más, trate de proporcionar la información mínima que (usted) puede identificar el problema. Publique información adicional a pedido.

¡Buena suerte!