SYSIBM.SYSDUMMY1
noch aktuell oder schon veraltet ?
Um diverse Funktionalität von DB2 - allem voran die Zeitarithmetik - nutzen zu können, war früher ein SELECT ... INTO... FROM tabelle
notwendig. Dies führte dazu, dass viele Anwender sich eine eigene Tabelle mit nur einer Zeile eingerichtet haben um derartige
Zuweisungen durchführen zu können. Andere Anwender behalfen sich mit Hilfskonstruktionen wie
SELECT MIN ( CURRENT DATE + 3 DAYS ) INTO ... oder
SELECT DISTINCT ( CURRENT DATE + 3 DAYS ) INTO ...
und verwendeten eine beliebige Tabelle als Basis.
Alles in allem waren letztere SELECTs nicht besonders performante Varianten.
Mit der Version 5 hat IBM schliesslich die Tabelle SYSIBM.SYSDUMMY1 eingeführt, um derartige Abfragen in eingeschränktem Masse standardisieren zu können.
Allerdings hat diese Tabelle einen kleinen Haken:
Sie befindet sich im Tablespace DSNDB06.SYSSTR zusammen mit anderen Tabellen ( der SYSIBM.SYSCHECKS , SYSIBM.SYSCHECKS2 , SYSIBM.SYSCHECKDEP und SYSIBM.SYSSTRINGS ). Auch wenn die Tabelle SYSIBM.SYSDUMMY1 nur eine einzige Zeile beinhaltet, führte jeder dieser SELECTs zu einem Tablespace-Scan. Gut - der Tablespace ist segmented, darum beschränkt sich der Scan auf ein einzelnes Segment, und darum macht sich der Scan nicht so stark bemerkbar. Nichtsdestotrotz ist ein Tablespace-Scan ein Tablespace-Scan.
Ein Index über die Tabellenspalte IBMREQD hilft Ihnen auch nicht unbedingt weiter. Sie können zwar dann durch die zusätzliche Angabe von
WHERE IBMREQD = 'Y'
den SELECT index-only machen, aber dann haben Sie die GETPAGES statt auf den Daten lediglich auf den Index verlagert. Und LOCKS ersparen Sie sich auch keine.
Letztere können Sie aber vermeiden, indem Sie an den SELECT ein ... WITH UR anhängen.
Bereits in Version 6 erweiterte IBM die SET :host - Anweisung und erlaubte auch arithmetische Operationen in der Zuweisung.
Dadurch wurde die SYSIBM.SYSDUMMY1 grösstenteils obsolet. Trotzdem wurde und wird sie auch heute noch in grossem Umfang verwendet.
Ist die SET - Anweisung nun wirklich um so vieles besser als der "gute alte" SELECT auf die SYSDUMMY1 ?
Kosten diese beiden GETPAGES wirklich so viel ? Und bringt WITH UR wirklich was ? Nun, da gibt ein einfacher DB2-Trace Auskunft.
Folgendes Test-Szenario wurde durchgeführt:
In einem PLI-Programm wurde eine Schleife
DO I = 1 TO 10000 ;
kodiert und innerhalb der Schleife abgesetzt:
1) SELECT CURRENT DATE + :i DAYS
INTO :host
FROM SYSIBM.SYSDUMMY1;
2) SELECT CURRENT DATE + :i DAYS
INTO :host
FROM SYSIBM.SYSDUMMY1 WITH UR;
3) SET :host = CURRENT DATE + :i DAYS
( Der Tablespace DSNDB06.SYSSTR befand sich die ganze Zeit im Bufferpool )
Das Ergebnis ist ziemlich eindeutig:
| variante | time elapsed | CPU-time elapsed | In-DB2 elapsed | In-DB2 CPU |
| 1 | 619 ms | 450 ms | 546 ms | 394 ms |
| 2 | 584 ms | 400 ms | 509 ms | 345 ms |
| 3 | 354 ms | 232 ms | 288 ms | 183 ms |
Gegenüber dem SELECT ist der Resourcenverbrauch der SET Anweisung in etwa halbiert. Die Vermeidung von LOCKS durch die Angabe von WITH UR spart ungefähr 10%-15% ein.
Wenn Sie also in einem Ihrer Programme über die SYSIBM.SYSDUMMY1 stolpern, dann sollten Sie prüfen, ob der SELECT nicht durch eine SET - Anweisung ersetzt werden kann.