Meine Abfrage läuft schneller, das zweite mal herum, wie kann ich das stoppen?

ich bin beim ausführen einer Abfrage in oracle 10 select A from B where C = D
B hat Millionen von Datensätzen, und es gibt keinen index auf C

Als ich das erste mal ausführen, dauert es etwa 30 Sekunden, das zweite mal, dass ich die Abfrage ausgeführt dauert es etwa 1 Sekunde.

Ist es natürlich, caching etwas und ich will es zu stoppen, jedes mal, wenn ich die Abfrage ausführen will ich es nehmen 30s - so wie es war, zum ersten mal ausgeführt.

  • bin ich über die-vereinfacht das Problem, dass ich aus Gründen der Herstellung, die Frage der Lesbarkeit.

Dank

  • Tun Sie etwas dagegen, zu erklären, warum Sie wollen es ständig zu langsam läuft?
  • Wahrscheinlich Antwort : Performance-tuning und Test
  • Wie zu zwingen, einen hard-parse: oracle-randolf.blogspot.com/2009/02/...
  • ich brauche eine konsistente Art und Weise testen, ob die Indexe erstelle ich tun jedem gut, und es ist schwer, wissenschaftlich über es, wenn meine Fragen nehmen Sie nicht die gleiche Zeit für den gleichen Satz von Daten.
InformationsquelleAutor LoudNPossiblyWrong | 2011-07-07
  1. 10

    Löschen des caches, um die Leistung zu Messen, ist möglich, aber sehr unhandlich.

    Eine sehr gute Maßnahme für die Verfolgung erreicht performance-tuning-Anstrengungen ist das zählen der Anzahl der zu lesenden Blöcke während der Ausführung der Abfrage. Einer der einfachste Weg, dies zu tun ist mit sqlplus mit autotrace, etwa so:

    set autotrace traceonly
<your query>

    Ausgänge

    ...
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
          1  consistent gets
          0  physical reads
          0  redo size
        363  bytes sent via SQL*Net to client
        364  bytes received via SQL*Net from client
          4  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

    Die Anzahl von Blöcken, die gelesen wurden, werden Sie aus dem cache oder von der Festplatte, ist consistent gets.

    Andere Möglichkeit ist das ausführen der Abfrage mit erhöhter Statistik, d.h. mit dem Hinweis gather_plan_statistics betrachtet und dann die Abfrage-plan aus dem cursor cache:

    auto autotrace off
set serveroutput off
<your query with hint gather_plan_statistics>
select * from table(dbms_xplan.display_cursor(null,null,'typical allstats'));

    Die Anzahl der Blöcke, die gelesen wird, die Ausgabe in Spalte buffers.

    ---------------------------------------------------------------------------------------------------------------------
| Id  | Operation        | Name           | Starts | E-Rows | Cost (%CPU)| E-Time   | A-Rows |   A-Time   | Buffers |
---------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT |                |      3 |        |     1 (100)|          |      3 |00:00:00.01 |       3 |
|   1 |  SORT AGGREGATE  |                |      3 |      1 |            |          |      3 |00:00:00.01 |       3 |
|   2 |   INDEX FULL SCAN| ABCDEF         |      3 |    176 |     1   (0)| 00:00:01 |    528 |00:00:00.01 |       3 |
---------------------------------------------------------------------------------------------------------------------
    • interessant, aber ich erstellt einen zusammengesetzten index für die Spalten, die ich mit in eine analytische Funktion, ich will sehen, ob und wie effektiv dieses index ist. Kann ich mit dem, was Sie beschreiben, dieser Effekt? thx
    • ja, jeder Teil der Abfrage-plan zeigt auf Ihre Kosten. Mit Ihren composite-index, wenn nichts unerwartetes passiert. Eine unerwartete Sache könnte sein, dass Ihr index nicht verwendet.
    InformationsquelleAutor Peter G.
  2. 5

    Sehen diese Frage...

    Es zeigt, wie klar-caches für Daten und Ausführungsplänen, aber auch erweitert auf, ob es eine gute Idee ist oder nicht.

    InformationsquelleAutor MatBailie
  3. 2

    Die offensichtliche Antwort ist, für jeden Testfall, um die Abfrage auszuführen, die mehrere Male, und werfen aus der ersten Folge.

    Nicht leicht vollständig repliziert die Bedingungen der ersten Abfrage ausgeführt werden, da die verschiedenen caches beteiligt: einige Oracle-caches (cursor, Puffer, etc.); einige sind OS (Festplatten-cache, je nach Oracle-config); einige sind hardware (SAN, RAID, Festplatte).

    Neustart der Datenbank-server vor jeder Prüfung wird wohl kommen ziemlich nah an Konstante Bedingungen.

    • Wäre das nicht das erste Ergebnis ist die Genaueste?
    • Eigentlich, wäre das nicht die erste Folge sein, die am wenigsten präzise? Wenn Sie lief es 100 mal, und die ersten zu den 30er Jahren und der rest nahm 1s, ich thinkg--in Bezug auf die Benutzer-Erfahrung -, dass das 30s-Wert ist ziemlich ungenau.
    InformationsquelleAutor derobert
  4. -2

    Könnte es helfen, Sie

    http://www.mssqltips.com/tip.asp?tip=1360

    CHECKPOINT;

    GO DBCC DROPCLEANBUFFERS;

    GEHEN

    • eine Weitere Lösung
    • EXEC sys.sp_configure N'max server memory (MB)', N'2147483646' GO RECONFIGURE WITH OVERRIDE GO (Größe, seine bis zu Ihnen)
    • Falsche Datenbank... wird nicht helfen, die OP zu sehr auf Oracle. (Schauen Sie sich die tags auf die Frage)
    • Lesen Sie die Frage, das ist etwa oracle, nicht sql-server.
    InformationsquelleAutor Irvin Dua
Schreibe einen Kommentar