Ungültiger Zugriffspfad in PLAN_TABLE?
- Dieses Thema hat 9 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahre, 2 Monaten vonMitglied.
- AuthorPosts
- 5. April 2005 um 11:28 Uhr #2529
Hallo zusammen,
ich bekomme bei einem Exlplain eines nicht zu komplexen SQLs einen offensichtlich ungültigen Zugriffspfad in der PLAN_TABLE. ACCESSTYPE und ACCESSNAME ist blank und der Rest ist im Wesentlichen auch Blank oder 0.
Außerdem ist nur eine Row für diesen Explain in der Plan_Table, obwohl es sich bei dem SQL um einen Correlated Subselect handelt (also min. 2 Rows drin sein müßten).
Was aber auffällt: Die Column QBLOCK_TYPE enthält den Wert PRUNED (ist bei der Plan-Table (SQL-Reference, Explain) nicht dokumentiert).
Hat jemand sowas schon mal gehabt? Ist ein PMR notwendig?
Das ganze übrigends in DB2 V8, NFM.Ciao, Rolf
6. April 2005 um 5:41 Uhr #2986Ja, PRUNED kenne ich.
Wenn Du z.B. schreibst
SELECT * FROM SYSIBM.SYSDUMMY1
WHERE IBMREQD = ‚N‘
AND Â Â Â IBMREQD = ‚Y‘dann erkennt DB2 beim EXPLAIN, dass die WHERE-Bedingung Quatsch ist ist gibt so eine "PRUNED"-Zeile aus.
das war auch schon in früheren Versionen von DB2 so.
Schau mal nach, ob sich nicht in Deine WHERE-Bedingung ein Fehler eingeschlichen hat
6. April 2005 um 6:29 Uhr #3303Hallo,
dass DB2 unsinnige where-Klausel find ich ja pfiffig. Bis ins R3 reicht es dann aber nicht mehr.
Das wirft nämlich so einen Plan aus:Explanation of query block number: 1 step: 0
Performance appears to be bad
Method:
. access new table.
. unknown or no sequential prefetch is used
. new table:
. SYSIBM.SYSDUMMY1
. table space locked in mode: Nscnr
Kay6. April 2005 um 6:51 Uhr #3508Hi,
das mit dem pruned bei preds, die zu einer leeren Menge führen hab ich im Interent auch gefunden – wenn es auch in der SQL-Ref nicht dokumentiert ist.
Nur leider trifft es bei diesem SQL nicht zu, alle Preds sind "vernünftig", führen also nicht zwangsläufig zu einer leeren Menge.Werde mal einen PMR eröffnen…
MfG Rolf
6. April 2005 um 6:54 Uhr #3647Kay,
das scheint schon der gleiche Pfad zu sein, nur nutzt du wohl ein Tool das die Plan_Table interpretiert und mit dem Eintrag nicht klarkommt (so wie ich).
MfG Rolf
6. April 2005 um 8:21 Uhr #3751Stell doch mal den SELECT rein, der dieses PRUNED verursacht.
6. April 2005 um 8:29 Uhr #3815Hier das SQL:
SELECT A.KKT_NR, A.KWP_NR, A.KKT_DAT_ZHL_WPH_E,
A.KKT_SL_ARG_WVSE, A.KKT_BETR_NE_WPH_E,
A.KKT_BETR_SOLZGAE, A.KKT_BETR_ABZ_KESTE,
A.KKT_BETR_QST_FIKE, A.KKT_BETR_QST_GWPHE,
A.KKT_BETR_ABZ_ZAST, A.KKT_SL_WAE_GUTSCHE,
A.KKT_BETR_KRS_DEV_E, A.KKT_NR_ANF_E,
A.KKT_NR_ERT_E, A.KKT_BETR_NOM_SZWPE
FROM K1LT.KKTWPBE A
WHERE A.KIN_NR = ?
AND A.KKT_NR = ?
AND A.KKT_NR_SKT = 0
AND A.KKT_DAT_ZHL_WPH_E > ?
AND A.KKT_DAT_ZHL_WPH_E < ?
AND A.KKT_SL_ARG_WVSE > ‚2‘
AND A.KKT_SL_ARG_WVSE < ’16‘
AND A.KKT_SL_ARG_WVSE <> ’14‘
AND A.KKT_SL_STO_WPH_E = ‚N‘
AND A.KKT_NR_ANF_E NOT IN
(SELECT B.KKT_NR_ANF_E
FROM K1LT.KKTWPBE B
WHERE A.KIN_NR = B.KIN_NR
AND A.KKT_NR = B.KKT_NR
AND A.KKT_NR_SKT = B.KKT_NR_SKT
AND A.KWP_NR = B.KWP_NR
AND A.KKT_NR_ANF_E = B.KKT_NR_ANF_ALT_E
AND A.KKT_NR_ERT_E = B.KKT_NR_ERT_ALT_E
AND B.KKT_SL_STO_WPH_E = ‚J‘)
;MfG Rolf
6. April 2005 um 8:32 Uhr #3856AND A.KKT_SL_ARG_WVSE > ‚2‘
AND A.KKT_SL_ARG_WVSE < ’16‘wenn das ein CHAR-Feld ist, dann wird diese Bedingung wohl nie eintreffen können
6. April 2005 um 9:03 Uhr #3887Ja, die Col ist CHAR (2). Mir ist aber nicht klar warum die Bedingung nie zutreffen kann…
Wird aus ‚2‘ ein ‚2 ‚ (mit Blank) und damit x’F240′ und aus ’16‘ x’F1F6′? Und ein Wert kann nie > x’F240′ und gleichzeitig < x’F1F6′ sein?
Ich glaube mir schwant da was… Richtig?
MfG Rolf
6. April 2005 um 9:21 Uhr #3909korrekt, Character-Felder werden rechtsbündig mit Blanc aufgefüllt.
und demnach ist ‚2‘ immer grösser als ’16‘
- AuthorPosts
You must be logged in to reply to this topic.
