|Diese Funktion wird nur in der Sun Solaris-Betriebsumgebung |unterstützt.
|Aufgrund von E/A-Systemaufwand ist das Bereitstellen von Seiten von |Platte aufwendig. Die DB2-Bereitstellungsfunktion verbessert den |Durchsatz erheblich, wenn die Verarbeitung mit E/A überlappt werden |kann. Die meisten Plattformen bieten leistungsfähige Basiselemente zum |Lesen zusammenhängender Seiten von Platte in nicht zusammenhängende |Speicherbereiche. Diese Basiselemente werden in der Regel als |"gestreutes Lesen" oder "über Vektor gesteuerte E/A" |bezeichnet. Auf einigen Plattformen kann sich die Leistung dieser |Basiselemente nicht mit der Leistung von E/A in großen Blockgrößen |messen. Standardmäßig sind die Pufferpools seitenbasiert. |D. h., zusammenhängende Seiten auf Platte werden in nicht |zusammenhängende Seiten im Speicher bereitgestellt. Die |Bereitstellungsleistung kann auf diesen Plattformen noch weiter verbessert |werden, wenn Seiten von Platte in zusammenhängende Seiten in einem Pufferpool |gelesen werden können. Mit der Registrierdatenbankvariablen |DB2_BLOCK_BASED_BP können Sie einen Bereich im Pufferpool erstellen, der Sätze |zusammenhängender Seiten enthält. Diese Sätze zusammenhängender Seiten |werden als "Blöcke" bezeichnet. Durch das Setzen dieser |Registrierdatenbankvariablen liest eine sequenzielle Bereitstellung die Seiten |von Platte direkt in diese Blöcke, statt jede Seite einzeln zu lesen. |Dadurch wird die /A-Leistung verbessert. Weitere Informationen zu |dieser Registrierdatenbankvariablen finden Sie im Abschnitt zu den |Registrierungs- und Umgebungsvariablen des Handbuchs Systemverwaltung. |
|Mehrere Tabellenbereiche unterschiedlicher Speicherbereichsgrößen können an |einen Pufferpool derselben Blockgröße gebunden werden. Es besteht eine |enge Beziehung zwischen Speicherbereichsgrößen und Blockgrößen, obwohl es sich |dabei um unterschiedliche Konzepte handelt. Ein Speicherbereich ist die |Granularität, mit der Tabellenbereiche einheitenübergreifend in mehreren |Behältern gespeichert werden. Ein Block ist die einzige Granularität, |bei der E/A-Server, die sequenzielle Bereitstellungsanforderungen |abarbeiten, blockbasierte E/A in Betracht ziehen.
|Einzelne sequenzielle Bereitstellungsanforderungen verwenden Seiten in |Speicherbereichsgröße. Wenn eine solche Bereitstellungsanforderung |empfangen wird, ermittelt der E/A-Server den Aufwand und die Vorteile |der Abarbeitung jeder Anforderung bei blockbasierter E/A (wenn ein |blockbasierter Bereich im Pufferpool vorhanden ist) im Vergleich zur |seitenbasierten E/A mit gestreutem Lesen. Der Vorteil von |blockbasierter E/A ist der Leistungsvorteil durch das Lesen von |zusammenhängenden Platten in zusammenhängenden Speicher. Der Aufwand |ist die Größe des verschwendeten Pufferpoolspeichers, der sich bei dieser |Methode ergeben kann.
|Die Verschwendung von Pufferpoolspeicher kann bei blockbasierter E/A |zwei Ursachen haben: |
|Der E/A-Server erlaubt einige verschwendete Seiten in jedem Block, um |die Vorteile der blockbasierten E/A nutzen zu können. Wenn jedoch |ein zu großer Teil eines Blocks verschwendet wird, kehrt der E/A-Server |zur seitenbasierten Bereitstellung in den Seitenbereich des Pufferpools |zurück. Ein Teil der E/A bei der Bereitstellung ist daher nicht |blockbasiert. Dies ist keine optimale Rahmenbedingung.
|Für eine optimale Leistung sollten Sie Tabellenbereiche der gleichen |Speicherbereichsgröße haben, die an einen Pufferpool derselben Blockgröße |gebunden sind. Eine gute Leistung kann auch noch erreicht werden, wenn |die Speicherbereichsgröße einiger Tabellen die Blockgröße des Pufferpools |übersteigt, an den sie gebunden sind. Es empfiehlt sich nicht, |Tabellenbereiche an einen Pufferpool zu binden, wenn die Speicherbereichsgröße |geringer als die Blockgröße ist.
|Es ist nicht möglich, AWE und blockbasierte Unterstützung gleichzeitig für |einen Pufferpool einzurichten. Wenn die Registrierdatenbankvariablen |DB2_AWE und DB2_BLOCK_BASED_BP beide auf denselben Pufferpool verweisen, hat |AWE Vorrang. Die blockbasierte Unterstützung wird in diesem Fall |inaktiviert und erst wieder aktiviert, wenn AWE inaktiviert ist.
|Ein Pufferpool, der erweiterten Speicher nutzt, unterstützt keine |blockbasierte E/A. |
|Bevor Sie mit einem der Beispiele arbeiten, müssen Sie die Kennungen für |die Pufferpools auf Ihrem System kennen. Die ID des Pufferpools sehen |Sie in der Spalte BUFFERPOOLID der Systemkatalogsicht |SYSCAT.BUFFERPOOLS.
|Szenario 1
|Sie haben einen Pufferpool mit der ID 4, der 1000 Seiten enthält. |Sie wollen einen Blockbereich erstellen, der aus 700 Seiten besteht, wobei |jeder Block 32 Seiten enthält. Sie müssen dazu folgenden Befehl |ausführen:
| db2set DB2_BLOCK_BASED_BP=4,700,32
|Beim Start der Datenbank wird der Pufferpool mit der ID 4 mit einem |Blockbereich von 672 Seiten und einem Seitenbereich von 328 Seiten |erstellt. Die 700 gewünschten Seiten in diesem Beispiel können nicht |ohne Rest durch 32 geteilt werden. D. h., die |angegebene Blockbereichsgröße muss mit folgender Formel auf die nächste |Blockgrößengrenze verringert werden:
| ((Blockbereichsgröße)) | FLOOR(-----------------) X Blockgröße | ( (Blockgröße) ) | ( 700 ) | = FLOOR(-----------------) X 32 | ( 32 ) | = 21 x 32 | = 672
|Szenario 2
|Sie haben einen Pufferpool mit der ID 11, der 3000 Seiten enthält. |Sie wollen einen Blockbereich erstellen, der aus 2700 Seiten besteht. |Sie müssen dazu folgenden Befehl ausführen:
| db2set DB2_BLOCK_BASED_BP=11,2700
|Beim Start der Datenbank wird der Pufferpool mit der ID 11 mit einem |Blockbereich von 2688 Seiten und einem Seitenbereich von 312 Seiten |erstellt. Da für die Blockgröße kein expliziter Wert angegeben ist, |wird der Standardwert 32 verwendet. Die 2700 gewünschten Seiten in |diesem Beispiel können nicht ohne Rest durch 32 geteilt werden. |D. h., die angegebene Blockbereichsgröße muss mit folgender |Formel auf die nächste Blockgrößengrenze verringert werden:
| ((Blockbereichsgröße)) | FLOOR(-----------------) X Blockgröße | ( (Blockgröße) ) | ( 2700 ) | = FLOOR(-----------------) X 32 | ( 32 ) | = 84 x 32 | = 2688