Oracle
 sql >> Base de données >  >> RDS >> Oracle

Comment décrire un problème de performances dans une base de données relationnelle ?

Pour la base de données Oracle fournissez ces informations :

Décrivez les symptômes du problème

Décrivez le comportement à l'origine du problème. Le comportement de la requête est-il stable ou le problème ne se produit-il que parfois, avec des paramètres spécifiques ou simplement aléatoires. Pouvez-vous reproduire ce comportement dans un IDE (par exemple SQL Developer) ?

Décrire l'environnement

Définir la version exacte d'Oracle

 select * from v$version

Décrivez comment vous vous connectez à la base de données :pilote, ORM, langage de programmation. Indiquez les noms et/ou les numéros de version.

Décrivez la requête

Publiez le texte de la requête. Essayez de simplifier - montrez un exemple reproductible minimal .

Exemple :votre requête problématique joint 10 tables. Vérifiez si vous voyez les mêmes symptômes dans une requête avec 9 ou 8 jointures. Descendez jusqu'à ce que vous voyiez les problèmes et affichez uniquement la requête réduite.

Oui, cela coûte cher, mais cela augmente fortement les chances que vous receviez de l'aide ! Plus la requête est petite, plus elle attire les supporters.

Décrivez le plan d'exécution

Pour obtenir le plan d'exécution, exécutez cette instruction (remplacez le texte de votre requête)

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

Le plan d'exécution est stocké dans la PLAN_TABLE , pour le voir exécuter cette requête

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

Afficher le résultat complet (pas seulement le tableau avec le plan d'exécution). La section des prédicats et les notes ci-dessous peuvent être extrêmement importantes.

Exemple pour 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 / [email protected]$1

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

   1 - filter("DUMMY"=:1)

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

   1 - "DUMMY"[VARCHAR2,1]

Ne coupez pas et ne collez pas le résultat graphique de votre plan d'explication IDE.

Ce plan d'exécution est-il le vrai qui est exécuté ?

Malheureusement pas toujours. Il y a plusieurs raisons pour lesquelles le expliqué le plan d'exécution peut différer du vrai.

Si vous avez des doutes (en particulier lorsque vous voyez un bon plan, mais que la requête s'exécute mal), vous pouvez extraire le plan du cache de la base de données en fournissant un SQL_ID .

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

Le SQL_ID d'une requête en cours d'exécution (ou en cours d'exécution peu de temps et toujours en cache) peut être trouvé avec la correspondance de texte et/ou l'utilisateur de la base de données :

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 vous avez une licence AWR, vous pouvez obtenir le plan d'exécution à partir de là, même pour les requêtes exécutées dans l'historique.

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

Le SQL_ID peut être trouvé en utilisant

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

Décrivez les données

Afficher le DDL des tables et des index sur ces tables.

Mentionnez si les statistiques de l'optimiseur ont été collectées récemment et affichez les dbms_stats utilisés recueillir la déclaration.

Pour les tables critiques, fournissez des informations sur la taille des segments, le nombre de lignes, le partitionnement,...

Pour les colonnes utilisées dans l'accès ou les jointures, fournissez des informations sur le nombre de valeurs distinctes. Les valeurs sont-elles uniformément réparties ou asymétriques (par exemple, un petit nombre de valeurs qui se produisent très souvent et un grand nombre de valeurs rares). Définissez-vous des histogrammes ?

Autre chose ?

Bien sûr, ce ne sont que les bases et d'autres informations peuvent encore être nécessaires, telles que les statistiques du système ou les paramètres de l'optimiseur. Mais encore une fois, essayez de fournir les informations minimales qui (vous) peuvent identifier le problème. Publiez des informations supplémentaires sur demande.

Bonne chance!