Oracle
 sql >> Datenbank >  >> RDS >> Oracle

Wie kann man Leistungsprobleme in relationalen Datenbanken beschreiben?

Für Oracle-Datenbank Geben Sie diese Informationen an:

Beschreiben Sie die Symptome des Problems

Beschreiben Sie das Verhalten, das das Problem verursacht. Ist das Verhalten der Abfrage stabil oder tritt das Problem nur manchmal, mit bestimmten Parametern oder einfach zufällig auf. Können Sie dieses Verhalten in einer IDE (z. B. SQL Developer) reproduzieren?

Beschreiben Sie die Umgebung

Definieren Sie die genaue Version von Oracle

 select * from v$version

Beschreiben Sie, wie Sie sich mit der Datenbank verbinden:Treiber, ORM, Programmiersprache. Geben Sie Namen und/oder Versionsnummern an.

Beschreiben Sie die Abfrage

Poste den Abfragetext. Versuchen Sie es zu vereinfachen - zeigen Sie ein reproduzierbares Minimalbeispiel .

Beispiel - Ihre problematische Abfrage verbindet 10 Tabellen. Überprüfen Sie, ob Sie dieselben Symptome in einer Abfrage mit 9 oder 8 Joins sehen. Gehen Sie zurück, bis Sie die Probleme sehen, und zeigen Sie nur die reduzierte Abfrage an.

Ja, das ist kostspielig, aber es erhöht die Wahrscheinlichkeit, dass Sie Unterstützung erhalten, erheblich! Je kleiner die Anfrage ist, desto mehr zieht sie die Unterstützer an.

Beschreiben Sie den Ausführungsplan

Um den Ausführungsplan zu erhalten, führen Sie diese Anweisung aus (ersetzen Sie Ihren Abfragetext)

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

Der Ausführungsplan wird in PLAN_TABLE gespeichert , um es zu sehen, führen Sie diese Abfrage aus

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

Zeigen Sie das vollständige Ergebnis (nicht nur die Tabelle mit dem Ausführungsplan). Äußerst wichtig können der Prädikatabschnitt und die Anmerkungen unten sein.

Beispiel für 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]

Das grafische Ergebnis nicht ausschneiden und einfügen Ihres IDE-Explain-Plans.

Ist dieser Ausführungsplan der echte, der ausgeführt wird?

Leider nicht immer. Es gibt mehrere Gründe, die erklärt werden Ausführungsplan kann vom tatsächlichen abweichen.

Wenn Sie Zweifel haben (insbesondere wenn Sie einen guten Plan sehen, aber die Abfrage schlecht läuft), können Sie den Plan aus dem DB-Cache extrahieren und eine SQL_ID angeben .

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

Die SQL_ID für eine Abfrage, die gerade ausgeführt wird (oder in Kürze ausgeführt wurde und noch zwischengespeichert ist), kann mit Textübereinstimmung und/oder dem Datenbankbenutzer ermittelt werden:

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>';

Wenn Sie über eine AWR-Lizenz verfügen, können Sie den Ausführungsplan von dort abrufen, sogar für Abfragen, die im Verlauf ausgeführt werden.

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

Die SQL_ID kann mit

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

Beschreiben Sie die Daten

Zeigen Sie die DDL der Tabellen und Indizes für diese Tabellen an.

Erwähnen Sie, ob die Optimierungsstatistiken kürzlich gesammelt wurden, und zeigen Sie die verwendeten dbms_stats an Sammelerklärung.

Geben Sie für die kritische(n) Tabelle(n) Informationen zu Segmentgröße, Zeilennummer, Partitionierung, ...

an

Denn die in Zugriff oder Joins verwendeten Spalten geben Auskunft über die Anzahl unterschiedlicher Werte. Sind die Werte gleichmäßig verteilt oder schief (z. B. eine kleine Anzahl von Werten, die sehr häufig vorkommen, und eine große Anzahl von seltenen Werten). Definieren Sie Histogramme?

Sonst noch etwas?

Natürlich sind dies nur die Grundlagen, und es können noch weitere Informationen erforderlich sein, z. B. Systemstatistiken oder Optimierungsparameter. Versuchen Sie jedoch noch einmal, die minimalen Informationen bereitzustellen, die (Ihr Ding) das Problem identifizieren können. Posten Sie zusätzliche Informationen auf Anfrage. P>

Viel Glück!