Wie um zu überprüfen, ob der index verwendet wird oder nicht in Oracle

SELECT * 
FROM   (SELECT TEMP.*, 
               ROWNUM RNUM 
        FROM   (SELECT entry_guid 
                FROM   alertdevtest.ENTRY 
                WHERE  Upper(alert_name) = 'alertname' 
                       AND user_guid = 'AlertProductClientTest' 
                       AND product_code = '-101' 
                       AND status_code != 13) TEMP 
        WHERE  ROWNUM <= 2500) 
WHERE  rnum >= 0; 

SELECT * 
FROM   (SELECT TEMP.*, 
               ROWNUM RNUM 
        FROM   (SELECT entry_guid 
                FROM   alertdevtest.ENTRY 
                WHERE  Upper(alert_name) = 'alertname' 
                       AND user_guid = 'AlertProductClientTest' 
                       AND product_code = '-101' 
                       AND status_code != 13 
                       AND product_view IN ( 'PView' )) TEMP 
        WHERE  ROWNUM <= 2500) 
WHERE  rnum >= 0;

Bin mit oben genannten Fragen und zu sehen, Leistungsabfall in der zweiten Abfrage ist im Vergleich zu den ersten. Der einzige Unterschied ist der zusätzliche filter UND PRODUCT_VIEW IN ('PView') in der zweiten Abfrage. Aber es hat index auf die Spalte. Bitte lassen Sie mich wissen, was kann der Grund für Leistungseinbrüche und wie kann ich überprüfen, ob ein index verwendet wird oder nicht? Bin mit Oracle SQL developer und versucht die Kontrolle zu erklären plan, aber konnte nicht viel details.

  • Können Sie PRODUCT_VIEW = 'PView' statt PRODUCT_VIEW IN ('PView')? Es wird Ihnen eine bessere Leistung. Auch können Sie uns Ihren plan erklären?
  • Ich habe zu verwenden, als Suche kann mit mehreren string-Werte. Ich bin nicht hochladen, ein Bild zu erklären, hier plan. Für die erste Abfrage sehe 2 Teile, vor allem,
InformationsquelleAutor Rajesh Bhat | 2015-09-21
  1. 4

    In Oracle SQL Developer, wenn Sie SQL in das Arbeitsblatt, dort gibt es einen button "Explain Plan", können Sie auch Treffer F10. Nachdem Sie ausführen, Erklären, planen, es wird sich zeigen in der Ansicht von unten von SQL Developer. Es gibt eine Spalte "OBJEKTNAME", es wird Ihnen sagen, welche index verwendet wird. Zum Beispiel, in einer Abfrage, die ich nur ran, in der linken Spalte (OPERATION) zeigt "SELECT-ANWEISUNG" zuerst, dann SORT (AGGREGATE) und dann INDEX (RANGE SCAN) und dann in der Spalte OBJECT_NAME es zeigt TICKER_IDX1, das ist der name eines Indexes auf meinem Tisch.

    Damit Sie sehen können, über die Spalte OBJECT_NAME, welche Indizes verwendet werden.

    Kann es passieren, dass der Oracle Cost-Based Optimierer wählt einen sub-optimalen Ausführungsplan. Viele Male die Aktualisierung der Statistiken das Problem lösen wird. Andere Möglichkeiten sind das hinzufügen zusätzlicher Indizes, in anderen Worten, ein multi-column-index". Sie können Tipp eine SQL-Anweisung, aber das ist nur selten erforderlich. Es ist auch möglich die Abfrage neu schreiben.

    • Beide Abfragen mit verschiedenen Index-Namen unter object_name Feld. So, dass ist der Grund für die langsame Reaktionszeit? Erste Abfrage zeigt product_code-index und der zweite zeigt product_View index. Warum nicht beide Indizes werden nicht verwendet, im zweiten Abfrage?
    • Die Oracle-CBO berechnet die Kosten, und nicht versuchen, auszuführen, was es glaubt, dass es die optimale Lösung. Also, wenn es nicht mit einem zweiten index, ist es, weil es glaubt, das würde tatsächlich verlangsamen Sie die Abfrage. Wenn es offensichtlich falsch ist - dies ist oft, weil Sie keinen gültigen Statistiken. So, das ist eine Sache, zu prüfen, die Statistiken aktualisiert wurden vor kurzem? Können Sie erneut Statistiken für die Tabelle und Indizes?
    • Wo haben Sie relativ lange Laufenden Abfragen mit Prädikaten für mehrere Spalten, dynamic-sampling kann auch helfen.
    InformationsquelleAutor Robert Dupuy
  2. 3

    Den EXPLAIN PLAN - Anweisung ist der beste Weg, um zu überprüfen, die Ausführung zu planen.
    Grafische Ausführungspläne als schädlich.

    EXPLAIN PLAN hat viele Vorteile, die über gemeinsame grafische Darstellung von Ausführungsplänen:

    1. Einfache, Standard-Format DBMS_XPLAN.DISPLAY funktioniert in jeder Umgebung und erzeugt eine Ausgabe, die jeden Oracle-Profi gewohnt ist. Jeder mit Zugriff auf Oracle kann das Problem reproduzieren, und jeder kann besprechen Sie das Problem mit den gleichen Namen. SQL-Entwickler kann frei sein, aber die meisten Entwickler und DBAs verwenden Sie es nicht.
    2. Leicht zu Verarbeiten-Ausgabe Die Ausgabe ist leicht zu speichern und teilen - speichern Sie die Ausgabe in einer Tabelle, kopieren Sie den text in Notepad, etc. Es ist auch viel leichter zu vergleichen mit einem Programm wie WinMerge. Große Abfragen könnten produzieren Hunderte von Zeilen in der Ausführung plan, mit einem diff-Werkzeug kann machen die tuning viel einfacher. Für Programmier-Aufgaben-text ist besser als ein Bild.
    3. Enthält Wichtige Abschnitte aus unerfindlichen Gründen IDEs, enthalten niemals die Note Abschnitt in der Ausführung der Pläne. Abschnitt enthält oft wichtige Informationen. In deinem Beispiel, ist es möglich, dass ein DBA festen eine SQL Plan Baseline für eine der Abfragen, aber nicht die anderen. Ohne die Notes Abschnitt werden wir nur zu erraten, wenn es etwas unheimliches vorgeht.
    4. Genauer Einige tools verwenden Sie eine separate Sitzung zum generieren von grafischen Ausführungsplänen und erzeugen falsche Ergebnisse. Zum Beispiel, Pläne können sehr unterschiedlich sein, ohne alter session enable parallel dml;. Dies scheint nicht ein Problem mit dem SQL-Developer, aber ich habe gesehen, dass es mit anderen Programmen.
    5. Mächtiger DBMS_XPLAN Skripts verwendet werden kann und hat viele leistungsstarke Funktionen, wie format => '+outline', dbms_xplan.display_awr usw.

    Unten ist ein einfaches Beispiel für EXPLAIN PLAN. Dieser plan ist gut, aber es hat eine riesige rote fahne, die die meisten grafischen Ausführungsplänen würde nicht zeigen. Die Letzte Zeile,
    dynamic statistics used: dynamic sampling (level=2) impliziert, dass eine der Tabellen fehlt der optimizer-Statistiken.

    drop table test1;
create table test1(a number);
explain plan for insert into test1 select * from test1;
select * from table(dbms_xplan.display);

Plan hash value: 4122059633

----------------------------------------------------------------------------------
| Id  | Operation                | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------
|   0 | INSERT STATEMENT         |       |     1 |    13 |     2   (0)| 00:00:01 |
|   1 |  LOAD TABLE CONVENTIONAL | TEST1 |       |       |            |          |
|   2 |   TABLE ACCESS FULL      | TEST1 |     1 |    13 |     2   (0)| 00:00:01 |
----------------------------------------------------------------------------------

Note
-----
   - dynamic statistics used: dynamic sampling (level=2)

    Einen quick check an, es ist leichter zu treffen, F10, F5, Strg+E, oder was auch immer die Verknüpfung in Ihre IDE. Aber für ernsthafte Analyse, die mit anderen geteilt werden, verwenden Sie immer EXPLAIN PLAN.

    • Ich denke, das sollte die akzeptierte Antwort.
    InformationsquelleAutor Jon Heller
  3. 0

    Beste Sache, um zu verstehen, auf Grund schlechter performance zu bekommen, SQL*Spur.
    Es gibt mehrere Möglichkeiten, um die Ablaufverfolgung aktivieren http://docs.oracle.com/cd/B19306_01/server.102/b14211/sqltrace.htm#g33356
    Zum Beispiel

    EXECUTE DBMS_SESSION.SESSION_TRACE_ENABLE(waits => TRUE, binds => TRUE);

    Müssen Sie die Ablaufverfolgung aktivieren, führen Sie diese Abfragen, abrufen von Daten bis zum Ende (da in der Regel die meisten arbeiten von Oracle ausführen, während fetch), Sitzung schließen (cursor geschlossen werden müssen, um den Ausführungsplan mit Statistiken erscheinen im trace-Datei).

    Dann sollten Sie gehen, um dump-Ordner auf Datenbank-server, Holen Sie trace-Datei, die Benutzer-tkprof-utility zum konvertieren von mehr lesbar, finden Sie diese Abfragen innerhalb, genießen :).

    Vorteile von SQL Trace ist, dass es gibt real-plan, der verwendet wurde, während die SQL-Ausführung, und es gibt sehr genaue Zeit,liest,gets, consistent, cpu-Statistiken für jeden Schritt des plans (leider kenne ich keine anderen Tools, die das können).

    Nachteil ist, dass Sie benötigen Berechtigungen zum starten der Ablaufverfolgung, und Sie müssen Zugang zu dump-Ordner (oder Sie müssen sich Fragen, DBA to execute query mit der observation und server-admin get file).

    Rau ist die option zum aktivieren der überwachung für SQL (z.B. mit /*+ monitor */hint), und verwenden Sie DBMS_SQLTUNE.REPORT_SQL_MONITOR http://docs.oracle.com/cd/B28359_01/appdev.111/b28419/d_sqltun.htm#CHDBHIBG - es können zu generieren, hübsche HTML-Seiten mit Statistiken für jeden Schritt der Ausführung plan (wie in SQL-Trace)

    Vorteil ist die Benutzerfreundlichkeit (die Sie nicht brauchen, um den Zugriff auf server-Ordner zu verwenden).

    Nachteil ist, dass Getreide von Statistiken in diesem Fall ist in der Regel 1 Sekunde, so ist es nur sinnvoll, für lang andauernde Abfragen (10 Sekunden und mehr).

    Wenn Sie müssen nur prüfen, ob der index verwendet wurde, während die SQL-Ausführung, Sie können die Abfrage v$sql_plan view v$sql, v$sql_monitor Ansichten zu finden, die entsprechenden plan.

    InformationsquelleAutor Anton Zaviriukhin
Schreibe einen Kommentar