SQL und LF mit SST-Felder

[Joe]

Hallo Forum.

Ich benutze eine LF mit 3 Key-Feldern. Eines der Felder ist ein SST-Feld (LOG060K).
Erstellt mit "LOG060K I SST(LOG060 1001 21)"

Ein SQL-Select mit diesen Key-Feldern dauert ewig
wobei ein Chain auf die LF in erwartet kurzer Zeit erledigt ist.

Was muss ich ändern, um dem SQL auf die Sprünge zu helfen?
Ein Select mit Substring(LOG060,1001,21) ist auch nicht schneller.

Gruß Joe

[Fuerchau]

Das geht wohl erst mit V6 oder V7 und berechneten Indizes:

CREATE INDEX

DEPT_TYPE

ON

DEPARTMENT (SUBSTR(DEPTNO,2,2))

Ansonsten kann SQL keinen Index mit berechneten Feldern verwenden, da ist dann leider immer ein Table-Scan nötig.

[Joe]

Das geht wohl erst mit V6 oder V7 und berechneten Indizes:

CREATE INDEX

DEPT_TYPE

ON

DEPARTMENT (SUBSTR(DEPTNO,2,2))

Ansonsten kann SQL keinen Index mit berechneten Feldern verwenden, da ist dann leider immer ein Table-Scan nötig.

Vielen Dank für die Info.
Also bei SQL Finger weg von solchen Log.Dateien.

Gruß Joe

[Fuerchau]

Das sowieso, da im Endeffekt SQL immer auf die PF geht.
Enthält eine LF entsprechende Select/Omit wird die Where-Klausel deines SQL's automatisch um die Select/Omit's ergänzt und dann die PF abgefragt.
Dies führt ggf. wieder zu einem Tablescan, da eine Select/Omit-LF nicht verwendet werden kann.

Ab V6 kann dann ein Index auch Where-Klauseln beinhalten, so dass der Optimizer diese ggf. verwenden kann.

In wie weit dann ein SQL genau aussehen muss, damit ein solcher Index dann auch genommen wird, kann Birgitta vielleicht erklären.

[Joe]

Das sowieso, da im Endeffekt SQL immer auf die PF geht.
Enthält eine LF entsprechende Select/Omit wird die Where-Klausel deines SQL's automatisch um die Select/Omit's ergänzt und dann die PF abgefragt.
Dies führt ggf. wieder zu einem Tablescan, da eine Select/Omit-LF nicht verwendet werden kann.

Ab V6 kann dann ein Index auch Where-Klauseln beinhalten, so dass der Optimizer diese ggf. verwenden kann.

In wie weit dann ein SQL genau aussehen muss, damit ein solcher Index dann auch genommen wird, kann Birgitta vielleicht erklären.

Was mich jetzt noch irritiert:

Wenn ich im interaktiven SQL (vorher STRDBG) die Select-Anweisung mit
Substring(log060,1001,21) auf die PF mache zeigt mir das
Debug Protoll als verwendeten Zugriffspfad die LF mit den SST-Felder an.
Noch Fragen??

Gruß Joe

[Joe]

Was mich jetzt noch irritiert:

Wenn ich im interaktiven SQL (vorher STRDBG) die Select-Anweisung mit
Substring(log060,1001,21) auf die PF mache zeigt mir das
Debug Protoll als verwendeten Zugriffspfad die LF mit den SST-Felder an.
Noch Fragen??

Gruß Joe

Entschuldigung und alles zurück.

Ich habe im Debug-Protokoll nicht weit genug gelesen. SQL
benutzt nur die "nicht SST.Felder" der LF.

Gruß und vielen Dank
Joe

[andreaspr@aon.at]

SQL kann schon die Select/Omit-LFs verwenden. Allerdings sind diese LFs nur in der alten Engine (CQE) unterstützt. In der neuen SQE werden sie erst ab 7.1 unterstützt.

Ob die Engine diese LFs überhaupt benützt liegt an dem QAQQINI eintrag "Ignore Derived Index". Ist dieser auf *NO gesetzt (ist ab 6.1 Default), werden ALLE LFs mit Select/Omit ignoriert.

Wenn du keinen entsprechenden Index ohne Select/Omit hast und auch keinen neuen Index erstellen willst könntest du im Notfall ein Select auch direkt auf das LF absetzen.

[Fuerchau]

Wie oben schon beschrieben dauert ja eben genau der Select auf die LF lange, da dieser einen Tablescan erfordert.

[andreaspr@aon.at]

Ich hab nur gelesen, dass Key-Felder verwendet wurden, nicht aber dass das Select direkt auf das LF abgesetzt wurde.
Zumindest ist das für mich nicht eindeutig herauslesbar.