[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    Aug 2003
    Beiträge
    1.508

    Verarbeitung der SQE

    Hi,

    ich hab ne Frage an die SQL/DB2-Profis:

    Habe eine einfache Tabelle (5 Spalten) in ein Schema erstellt und diese beinhaltet knapp über 100 Datensätze.

    Wenn ich ein folgendes Select absetze führt die SQE ein Table-Scan durch:
    Code:
    Select * from FTPLOG
    Code:
    Select * from FTPLOG where NR > 50
    Wenn ich nun statt dem Größer (>) ein Gleich (=) verwende, erstellt mir die SQE einen Temporären Index und Row-Liste:
    Code:
    Select * from FTPLOG where NR = 50
    Dies dauert um ein Vielfaches länger als die erste variante.

    Ich habe beide Abfragen öfters ausgeführt, um der SQE die Möglichkeit zu geben den Zugriffspfad zu optimieren. Leider ohne Erfolg.

    Ich hatte für diese Tabelle aus Testgründen einige Indizes erstellt. Diese sind jedoch nicht mehr vorhanden.

    Weis jemand warum sich die SQE für solch einen Aufwand entscheidet, wenn ein einfacher Table-Scan um einiges schneller ist?

    lg Andreas

  2. #2
    Registriert seit
    Aug 2009
    Beiträge
    121

    SQE

    Ohne nähere Details zu kennen, ist es schwer zu sagen, warum der SQL-Optimizer eine bestimmte Entscheidung trifft. Bei diesem Beispiel wäre es hilfreich zu wissen, ob die Spalte NR eventuell einen (eindeutigen) Schlüssel darstellt, und wie sich die Werte innerhalb der Spalte NR verteilen. Außerdem könnte mit einfließen, über welches Interface das SQL-Statement abgesetzt wird (interaktives SQL, ODBC, embedded SQL), weil die Frage interessant sein kann, ob für "First I/O" oder für "All I/O" optimiert wird.

    Grundsätzlich kann man wohl vermuten, daß bei einer Abfrage WHERE NR > 50 mehr Sätze zurückgegeben werden als bei einer Abfrage WHERE NR = 50, und das könnte die unterschiedliche Entscheidung des Optimizers erklären. Ein Table-Scan geht zwar bei einer relativ kleinen Tabelle schneller, kann aber bei wiederholtem Aufruf, wachsender Tabellengröße und kleiner Ergebnismenge negative Auswirkungen auf das Paging-Verhalten haben.

    Mit freundlichen Grüßen,
    Christian Bartels.

  3. #3
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Da SQL ggf. ODP's ja offen hält, macht der Aufbau eines Index durchaus Sinn, damit alle folgenden Abfragen dann bei geöffnetem ODP erheblich schneller sind.
    Im interaktiven SQL hast du natürlich Recht wenn du die Abfrage nur 1 Mal machst.
    Aber woher soll der Optimizer das wissen ?
    Wiederhole die Abfrage einfach mehrmals mit unterschiedlichen Schlüsseln und du wirst sehen, dass diese dann erheblich schneller sind.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  4. #4
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Zunächst danke für die Antworten!

    Die Tabelle ist wie folgt aufbeaut:
    Code:
    CREATE TABLE MYFTPLOG                            
                 (ACTCNT    INTEGER                  
                               NOT NULL WITH DEFAULT,
                  BEZ       CHAR (35)                
                               NOT NULL WITH DEFAULT,
                  JOBNR     INTEGER                  
                               NOT NULL WITH DEFAULT,
                  SEQNR     INTEGER                  
                               NOT NULL WITH DEFAULT,
                  CMD       CHAR (10)                
                               NOT NULL WITH DEFAULT,
                  LOG       VARCHAR (1024)           
                               NOT NULL WITH DEFAULT,
                  DATUM     TIMESTAMP                
                               NOT NULL WITH DEFAULT)
    Es gibt keine Primärschlüsseln (außer die RRN), da es keine Referenzierung auf andere Tabellen benötigt wird, bzw die Datensätze durchaus öfters auftreten können.
    (ich weis, eine eigene Spalte mit laufenden Zähler und diesen als PK wäre schöner)

    Den Test habe ich über den iSeries Navigator ausgeführt (JDBC).

    Habe die Abfrage auch schon mit unterschiedlichen Filterungen durchgeführt. Das Ergebnis war immer das Gleiche. Table-Scan war immer schneller.
    Das liegt mit ziemlich ganz sicher daran, dass es eben eine nur sehr kleine Tabelle ist.
    Bin mir auch sicher, dass bei entsprechenden Datenmengen die Entscheidung der SQE die Richtige wäre.

    Was ich interessant finde ist eben die Tatsache, dass für diesen Fall der Table-Scan schneller wäre, sich der Optimizer aber dennoch für einen anderen weg entschieden hat.

    Beim ersten ausführen von WHERE NR = 50 hatte er auch einen Table-Scan durchgeführt (der war auch schneller).

  5. #5
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Bei wenigen Sätzen/Zeilen und Spalten in einer Datei ist ein Table Scan immer schneller als ein Index-Zugriff!

    Wenn die SQL-Abfrage wirklich mit der SQE und nicht mit der CQE ausgeführt wird, ist ein temporärer Index quasi permanent, d.h. existiert bis zum nächsten IPL und kann von allen Jobs (bzw. allen SQL-Abfragen) verwendet werden.

    Der Optimizer interagiert mit dem Statistics-Mangager und erhält Informationen darüber wie groß der Anteil der ausgewählten Sätze am Gesamt ist. Bis zu ca. 20% wird ein Index bevorzugt.

    Was mich allerdings wundert ist, dass bei einer Abfrage ein temporärer Index gebildet wird. Das passiert eigentlich nur, wenn man darauf besteht mit Echt-Daten (Datenkopie zulässig = *NO oder SENSITIVER CURSOR) zu arbeiten.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  6. #6
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Hi Brigitta,
    Danke für die Antwort!

    Es ist alles reines SQL (Tabelle, Schema), und auch mit der SQE abgearbeitet. Der Temporäre Index bleibt auch bestehen.

    Nach löschen, der Statistik-Daten hat der Optimizer zumindest keine Row-Liste erstellt.

    Jetzt geht er nur noch über den Temporären Index.

    Allerdings wenn ich den Filter entsprechend auswähle, dass möglichst wenig Datensätze ausgegeben werden, wird ein Table-Scan durchgeführt

    Interessant ist auch, dass wenn ich den zusatz "FETCH FIRST ROW ONLY" verwende, trotzdem über den längeren Zugriffspfag gegangen wird, da trotzdem alle Datensätze gelesen werden und erst zum Schluss der erste Satz ausgegeben wird.

    Danke jedenfalls für die Unterstützung!
    lg Andreas

  7. #7
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    FETCH FIRST ROW ONLY ist für den Optimizer nicht relevant.
    Hierfür ist OPTIMIZE FOR n ROWS gedacht.
    Zusätzlichen Einfluss kann man über SET OPTION ALWBLK=..., ALWCPYDTA=... sowie die QAQQINI nehmen.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  8. #8
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... da gehts der Query Engine nicht viel anders als der Kriminalpolizei: die rät - und manchmal falsch

    D*B
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  9. #9
    Registriert seit
    Aug 2003
    Beiträge
    1.508
    Vielen Dank für die zahlreichen Antworten!!

    Über SQL selbst hab ich es nicht mehr geschafft ein einfaches Table-Scan durchzuführen.
    PHP-Code:
    select from myftplog
    where actcnt 
    1332
    fetch first row only
    optimize 
    for 1 rows
    for read only 
    Müsste scheinbar wirklich wie Fuerchau geschrieben hat, mit SET OPTION oder in der QAQQINI einstellungen vornehmen, dass zB keine temporären Objekte erstellt werden dürfen. (Für diese Abfrage zumindest.)

    So wie es aussieht ist die Antwort von BenderD am plausibelsten.

    Danke auf jeden Fall für eure Hilfe

Similar Threads

  1. String Verarbeitung Free Format
    By co_steffl in forum IBM i Hauptforum
    Antworten: 19
    Letzter Beitrag: 08-12-09, 13:14
  2. Verarbeitung mit variabler Satzstruktur
    By RaMai in forum NEWSboard Programmierung
    Antworten: 5
    Letzter Beitrag: 02-11-07, 18:21
  3. MQ-Series: Automatische Verarbeitung
    By RLurati in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 20-10-06, 10:09
  4. MQ-Series: Automatische Verarbeitung
    By RLurati in forum IBM i Hauptforum
    Antworten: 1
    Letzter Beitrag: 20-10-06, 09:31
  5. Fehler bei Verarbeitung von QSZPAVL
    By Brownie in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 28-07-04, 11:56

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •