DB2-V8 Index statt Tablespacescan
- Dieses Thema hat 2 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 15 Jahre, 3 Monaten von
Anonym.
-
AuthorPosts
-
29. Mai 2008 um 17:20 Uhr #2855
AnonymInaktivLiebes Forum!
Ich habe da ein eigenartiges Phänomen mit DB2-V8 z/OS:
Eine Tabelle ‚TEST1‘ mit 2 Spalten hat auf COL1 (=Primary Key) einen Unique Index, COL2 ist nicht indiziert. Nach dem Runstats mache ich ein Explain für folgendes S ELECT:S ELECT COL1, COL2 from TEST1 where COL1 > 10 OR COL2 = ‚DD‘;
Dabei zeigt das Explain einen nonmatching Index-Scan über den Index der 1. Spalte. Wie kann die 2. Bedingung (COL2 = ‚DD‘) dabei ohne Tablespacescan geprüft werden? Bei DB2 V6 und V7 hatte ich bei einem derartigen Statement auch einen Tablespacescan!
Performance ist zwar gut, aber ich kann sie mir eben nicht erklären.
Wären die beiden Bedingungen mit AND verknüpft, dann wäre dies verständlich, so aber eben nicht. C REATE TABLE TEST1 Â
 ( COL1 SMALLINT NOT NULL,
  COL2 CHAR(10) NOT NULL,
  PRIMARY KEY (COL1)   )
 IN DATABASE TESTDB;
 Â
 C REATE UNIQUE INDEX XTEST1 ON TEST1 (COL1); I NSERT INTO TEST1 VALUES (1,’AA‘); Â
 I NSERT INTO TEST1 VALUES (2,’BB‘); Â
 I NSERT INTO TEST1 VALUES (3,’CC‘); Â
 I NSERT INTO TEST1 VALUES (4,’DD‘); Â
 I NSERT INTO TEST1 VALUES (5,’EE‘); Â
 I NSERT INTO TEST1 VALUES (6,’FF‘); Â
 I NSERT INTO TEST1 VALUES (7,’GG‘); Â
 I NSERT INTO TEST1 VALUES (8,’HH‘); Â
 I NSERT INTO TEST1 VALUES (9,’II‘); Â
 I NSERT INTO TEST1 VALUES (10,’JJ‘); Â
 I NSERT INTO TEST1 VALUES (11,’KK‘); Â
 I NSERT INTO TEST1 VALUES (12,’LL‘); Â
Â
— DANACH RUNSTATS:
— RUNSTATS TABLESPACE
— TESTDB.TEST1 TABLE(TEST1) COLUMN(ALL) INDEX(ALL)
Â
 D ELETE FROM PLAN_TABLE;
 EXPLAIN PLAN SET QUERYNO = 1 FOR  Â
 S ELECT COL1, COL2 FROM TEST1 Â
 WHERE COL1 = 5 OR COL2 = ‚GG‘;  Â
Â
 S ELECT SMALLINT(QUERYNO) AS QNO, SMALLINT(QBLOCKNO) AS QBNO,
 SMALLINT(PLANNO) AS PNO,  Â
 METHOD AS METH, SUBSTR(TNAME,1,10) AS TNAME, Â
 ACCESSTYPE AS ACT, MATCHCOLS AS MCOL, INDEXONLY AS XO,
 SUBSTR(ACCESSNAME,1,10) AS ACCNAME
 FROM PLAN_TABLE ORDER BY 1, 2, 3; ÂDB2-V8:
———+———+———+———+———+–
QNO Â QBNO Â PNO Â METH Â TNAME Â ACT MCOL Â XO Â ACCNAME Â
———+———+———+———+———+–
 1   1   1   0  TEST1  I 0  N  XTEST1 ÂDB2-V6 und V7:
———+———+———+———+———+–
QNO Â QBNO Â PNO Â METH Â TNAME Â ACT MCOL Â XO Â ACCNAME Â
———+———+———+———+———+–
 1   1   1   0  TEST1  R 0  N  ÂKann mir das wer erklären? Bitte helft mir, das zu verstehen.
In der Literatur (und auch mittels Google) habe ich nichts gefunden.Liebe Grüße
GünterPS: Ach ja, noch was:
Der Index wird sogar benutzt, wenn ich gar nicht die indizierte Spalte abfrage:EXPLAIN PLAN SET QUERYNO = 2 FOR
S ELECT COL1, COL2 FROM TEST1
WHERE COL2 = ‚GG‘;S ELECT SMALLINT(QUERYNO) AS QNO, SMALLINT(QBLOCKNO) AS QBNO,
SMALLINT(PLANNO) AS PNO,
METHOD AS METH, SUBSTR(TNAME,1,10) AS TNAME,
ACCESSTYPE AS ACT, MATCHCOLS AS MCOL, INDEXONLY AS XO,
SUBSTR(ACCESSNAME,1,10) AS ACCNAME
FROM PLAN_TABLE ORDER BY 1, 2, 3;
———+———+———+———+———+–
QNO QBNO PNO METH TNAME ACT MCOL XO ACCNAME
———+———+———+———+———+–
2 1 1 0 TEST1 I 0 N XTEST1
2. Juni 2008 um 19:35 Uhr #3218
AnonymInaktivHallo Günter
Schau dir mal die Anz. Pages bei deinen Objekten in den Catalog Tables an (sieht bei Dir vermutlich ähnlich aus):
SYSTABLESPACE NACTIVE (zB. 180)
SYSTABLES NPAGES (zB. 1)
SYSINDEXES NLEAF & NLEVELS (zB. 1 & 2)Bei einem tablespace scan muss DB2 alle Pages des Tablespace durchlesen (im Bsp oben 180). Mittels nonmatching index scan findet DB2 anhand der RID’s (PageNr & IDMap Entry Nr) auf den Leaf Pages (im Bsp oben 1) des Index alle Pages der Table (im Bsp oben 1), welche zu lesen sind. Somit ist ein nonmatching index scan im obigen Bsp effizienter als ein tablespace scan.
Gruss
Hke
20. Juni 2008 um 8:41 Uhr #3460
AnonymInaktivHallo hke!
Danke für Deine Antwort. Bin erst aus dem Urlaub zurück gekommen, daher kommt meine Antwort so spät.
Meine Statistiken sehen wirklich ähnlich den von Dir geposteten aus:
SYSTABLESPACE NACTIVE 12
SYSTABLES NPAGES 1
SYSINDEXES NLEAF & NLEVELS 1 & 2Da es sich dabei um einen nicht segmentierten Tablespace mit nur 1 Tabelle handelt, bin ich davon ausgegangen, dass ohnehin alle Pages des Tablespaces gelesen werden müssten. Dies stimmt jedoch nur, wenn alle Tablespace-Pages auch wirklich bereits mit Daten befüllt sind. Nun hat jeder Tablespace jedoch eine gewisse Default-Grösse, welche bei mir 12 Pages beträgt. Die Daten dieser Mini-Tabelle liegen natürlich auf 1 Datenpage. Da ist, wie Du richtig gemeint hast, ein Index-Zugriff besser, da ja ALLE RID’s auf 1 Datenpage zeigen.
Jetzt habe ich die Tabelle gelöscht und in einem explizit angelegten Tablespace (mit MAXROWS 1) neu angelegt, damit sich die Datenzeilen auf alle Tablespace-Pages verteilen (verifiziert mit DSN1PRNT). Eigentlich sollte damit doch der Indexzugriff nicht mehr gewählt werden, sondern stattdessen ein Tablespacescan.
Leider kann ich dies jedoch jetzt nicht mehr unter DB2-V8 auf z/OS ausprobieren, da ich Ende Mai nur temporär die Möglichkeit hatte, auf diesem System zu arbeiten. Bei den Host-Systemen, die ich dauerhaft im Zugriff habe, wird aus wirtschaftlichen Gründen noch V5 und V7 eingesetzt – LEIDER :'(
Und diese Systeme machen auch bei der ursprünglichen Variante einen Tablespacescan!Unter Windows und AIX hätte ich zwar einige DB2’s (Version 7, 8 und 9) zum Testen, das ist aber eher weniger vergleichbar.
Ich nehme an, Du hast dauerhaften Zugang zu einem Host-DB2 mit Version 8!? Könntest Du bitte ausprobieren, ob auch dann ein Index verwendet wird, wenn ALLE Pages eines (mit MAXROWS 1 und wenig Pages angelegten) Tablespaces mit Daten der abzufragenden Tabelle beschrieben sind? Eigentlich wäre dann ja ein nonmatching index scan kontraproduktiv!
Gruss
Günter
-
AuthorPosts
You must be logged in to reply to this topic.