Oracle, SQL * Net oder ORDER BY sparen Netzwerkressourcen ...

    Jeder glaubt zu Recht, dass das ORDER BY-Konstrukt Ressourcen für das Sortieren des Ergebnisses aufwendet, und am Ende sollten wir das Ergebnis etwas später erhalten. Ist das immer der Fall? ..

    Lassen Sie uns eine einfache triviale Abfrage einführen:

    SET echo OFF
    SET linesize 192
    SET pagesize 0
    SET TRIM ON
    SET trims ON
    SET feedback OFF
    SET heading OFF
    SET term OFF
    SET TIME ON
    SET timing ON
    SET autot ON stat
    spool s.txt
    SELECT clnt_clnt_id,
           name,
           start_date,
           end_date
      FROM client_histories;
    spool OFF
    exit
    


    Alles scheint einfach zu sein:
    1. Eine Auswahl wird aus der Tabelle getroffen
    2. Das Ergebnis wird in eine Datei verschoben
    3. Das Ergebnis wird nicht auf dem Terminal angezeigt
    4. Am Ende der Anforderung werden Uhrzeit und Statistik angezeigt


    Schauen Sie sich jetzt die Statistik an:

    Затрач.время: 00:00:17.97
    Статистика
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
           6515  consistent gets
              0  physical reads
              0  redo size
       14182576  bytes sent via SQL*Net to client
         242558  bytes received via SQL*Net from client
          22012  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
         330154  rows processed
    


    Stellen Sie sich nun vor, wir müssen die Daten rationalisieren. Frage - was wird mit der Zeit passieren? Die erste Meinung ist, dass das Sortieren einige Zeit in Anspruch nehmen wird und das Ergebnis später kommt. Gut gemacht:

    SET echo OFF
    SET linesize 192
    SET pagesize 0
    SET TRIM ON
    SET trims ON
    SET feedback OFF
    SET heading OFF
    SET term OFF
    SET time ON
    SET timing ON
    SET autot ON stat
    spool s1.txt
    SELECT clnt_clnt_id ,
           name ,
           start_date ,
           end_date
    FROM client_histories
    ORDER BY 1,
             2;
    spool OFF
    exit
    


    Schauen Sie sich jetzt die Statistik an:

    Затрач.время: 00:00:16.92
    Статистика
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
           6115  consistent gets
              0  physical reads
              0  redo size
       13166047  bytes sent via SQL*Net to client
         242558  bytes received via SQL*Net from client
          22012  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
         330154  rows processed
    


    Es stellt sich heraus, dass wir bei der Verwendung von order by das Ergebnis schneller erhalten. In der Statistik gibt es nur zwei Unterschiede: die für den Vorgang aufgewendete Zeit und die Menge der über SQL * Net übertragenen Informationen.

    Eine Schlussfolgerung ist, dass der Sortiervorgang um 33.000 Zeilen schneller ist als das Senden von Daten über den vorhandenen Kanal mit 992 KB.

    Aber woher kommt der Unterschied? ..
    Und die Sache ist, dass die über sql * net gesendeten Daten durch Puffer komprimiert und komprimiert werden. Dies wird durch die SDU-Größe in der TNS SQL * Net-Beschreibung sowie durch die Größe des Puffers beeinflusst, der in SQL * Plus mit dem Parameter ARRAYSIZE konfiguriert wurde (standardmäßig 15). T.O. Über SQL * Net werden weniger Daten übertragen.

    Lassen Sie uns experimentieren, und zwar eine kleine Änderung am zweiten Skript vornehmen:

    SET autot ON stat
    SET arraysize 5000
    spool s1.txt
    


    Jetzt haben wir die Größe des Puffers auf 5000 erhöht (dies ist das Maximum) und die Anforderung mit Sortieren erfüllt. Schauen Sie sich das Ergebnis an:

    Затрач.время: 00:00:06.47
    Статистика
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
           6115  consistent gets
              0  physical reads
              0  redo size
       11278863  bytes sent via SQL*Net to client
           1174  bytes received via SQL*Net from client
             68  SQL*Net roundtrips to/from client
              1  sorts (memory)
              0  sorts (disk)
         330154  rows processed
    


    • Wir haben die Menge der an den Kunden übermittelten Informationen um weitere 1,8 MB reduziert
    • Wir haben die vom Kunden übermittelte Informationsmenge um das 200-fache reduziert (um 235 KB).
    • Wir haben die Anzahl der Roundtrips (Abfragen zwischen dem Client und dem SQL * Net-Server) um das 300-fache reduziert (von 22012 auf 68).


    Insgesamt: Aufgrund der Vergrößerung des Puffers reduzieren wir die Anzahl der Roundtrips während der Datenübertragung, was sich fast immer positiv auf große Anforderungen auswirkt. Interessanterweise kann sich jedoch auf langsamen Kommunikationskanälen (z. B. 1 m / Bit und langsamer) auch das übliche Sortieren von Daten positiv auf das Ergebnis der Anforderungszustellung auswirken.

    Ja und in Bezug auf die Komprimierung. Lassen Sie Ihre Daten wie folgt aufbereiten:

    CREATE TABLE tbl0 AS
    SELECT object_name,
           object_id,
           min(object_id) over (partition BY object_name) AS min_object_id
      FROM dba_objects;
    CREATE TABLE tbl1 AS SELECT DISTINCT object_name,
                                         object_id
                                    FROM tbl0
                                   WHERE object_id = min_object_id;
    CREATE TABLE tbl2 AS SELECT object_name FROM tbl1 WHERE rownum < 1;
    BEGIN
      FOR i IN 1..20 LOOP
        INSERT INTO tbl2 SELECT object_name
                           FROM tbl1
                          ORDER BY reverse(object_id||object_name);
      END LOOP;
      COMMIT;
    END;
    


    Vergleichen Sie nun die Statistiken für ARRAYSIZE 5000 mit den Abfragen:

    SELECT object_name
    FROM tbl2;
    SELECT object_name
    FROM tbl2
    ORDER BY 1;
    


    Wir erhalten folgende Statistiken:

    Статистика
    ----------------------------------------------------------
              0  recursive calls
              0  db block gets
           4992  consistent gets
              0  physical reads
              0  redo size
       34152895  bytes sent via SQL*Net to client
           3088  bytes received via SQL*Net from client
            250  SQL*Net roundtrips to/from client
              0  sorts (memory)
              0  sorts (disk)
        1242280  rows processed
    Статистика
    ----------------------------------------------------------
            167  recursive calls
             16  db block gets
           5211  consistent gets
          16377  physical reads
              0  redo size
        7629058  bytes sent via SQL*Net to client
           3088  bytes received via SQL*Net from client
            250  SQL*Net roundtrips to/from client
             21  sorts (memory)
              4  sorts (disk)
        1242280  rows processed
    


    Wie wir sehen können, werden mit ARRAYSIZE 5000 alle 1,2 Millionen Leitungen für die gleiche Anzahl von Roundtrips gepumpt, d. H. Die Auswirkungen von SQL * Net-Verzögerungen auf die Anforderung / Antwort sind ungefähr gleich, aber die Informationsmenge für sortierte Daten beträgt 7,3 MB gegenüber 32,5 MB für nicht sortierte Daten. T.O. Bei der vorläufigen Sortierung von wiederholten Daten haben wir das Verkehrsaufkommen über das Netzwerk um das 4,5-fache reduziert, was bei langsamen Kommunikationskanälen sehr wichtig ist.

    Jetzt auch beliebt: