Für optimale Funktionalität möchte diese Seite Cookies verwenden. Bitte erlauben Sie der Seite, Cookies zu setzen         mehr Infos
 

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:

variantetime elapsedCPU-time elapsedIn-DB2 elapsedIn-DB2 CPU
1619 ms450 ms546 ms394 ms
2584 ms400 ms509 ms345 ms
3354 ms232 ms288 ms183 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.


Zurück zu DB2 Home Impressum