Desktop Help 10.0 - Minimieren des E/A-Konkurrenzbetriebs in DB2

Der Eingabe/Ausgabe-Konkurrenzbetrieb in einer IBM DB2-Datenbank wird durch ordnungsgemäßes Anordnen der Datenbankkomponenten im Dateisystem minimiert. Letztendlich muss der Datenbankadministrator die Möglichkeit reduzieren, dass ein Prozess auf den anderen wartet, um seine Eingabe/Ausgabe-Anfrage abzuschließen. Dies wird oft als "Warten auf E/A" bezeichnet.

Es folgen Empfehlungen, die Ihnen bei der Vermeidung des Ressourcen-Konkurrenzbetriebs helfen.

Verwenden Sie SMS für temporäre Benutzer-Tablespaces und DMS für alle anderen Tablespaces.
DB2 bietet zwei Arten von Tablespace-Speichermodellen: System Managed Space (SMS) und Database Managed Space (DMS). Esri empfiehlt die Verwendung von SMS-Tablespaces für temporäre Benutzer-Tablespaces und von DMS für andere Tablespaces, weil Sie damit eine bessere Performance erzielen, besonders dann, wenn Ihre Datenmenge regelmäßig größer wird.
Hinweis:

Bei DB2 9 ist eine zusätzliche globale temporäre Tabelle von DB2 (DECLARE GLOBAL TEMPORARY TABLE) erforderlich. Laut DB2-Dokumentation ist für das Deklarieren von globalen Tabellen eine der folgenden Berechtigungen erforderlich: SYSADMIN, DBADM oder USE für einen USER TEMPORARY-Tablespace.

Bei DB2 9 sollten Sie die automatische Speicherung für Datenbanken nutzen und die Attribute für die automatische Größeneinstellung für Tablespaces einstellen. In DB2 9 können DMS-Tablespaces zusätzlichen Speicher zur Verfügung stellen, wenn dieser erforderlich wird.
Richten Sie Puffer-Pools ein.
Das Einrichten der Puffer-Pools ist sehr wichtig für die Leistung. DB2 bietet standardmäßig einen kleinen Puffer-Pool mit dem Namen IBMDEFAULTBP. Bei DB2 9 ist für den IBMDEFAULTBP-Puffer-Pool standardmäßig die automatische Größeneinstellung konfiguriert. Der Datenbankmanager passt die Größe dieses Puffer-Pools entsprechend der Nutzungslast an.

Erstellen Sie einen separaten Puffer-Pool für jeden Tablespace. Überprüfen Sie den Datenbankschnappschuss, um die physisch gelesenen Werte des Puffer-Pools zu prüfen. Der Puffer-Pool sollte groß genug sein, dass ein Schnappschuss einer Kartenneuzeichnung eine kleine Anzahl physischer Lesevorgänge ergibt. Um die Effizienz eines Puffer-Pools zu ermitteln, können Sie seine Trefferrate (Buffer Pool Hit Ratio, BPHR) berechnen. Eine ideale BPHR liegt etwas über 90 %. Die Formel für die Berechnung lautet wie folgt:
```
BPHR (%) = (1 - (("Buffer pool data physical reads" 
+ "Buffer pool index physical reads")
 / ("Buffer pool data logical reads" 
+ "Buffer pool index logical reads"))) * 100
```
Eine andere Methode für die Prüfung der Trefferraten für Puffer-Pools besteht in der Verwendung der Verwaltungssicht SYSIBMADM.BP_HITRATIO. In dieser Ansicht können verschiedene Trefferraten wie Gesamttrefferrate, Datentrefferrate, XDA-Trefferrate und Indextrefferrate für alle Puffer-Pools ermittelt werden.
```
SELECT SUBSTR(DB_NAME,1,8) AS DB_NAME, 	
SUBSTR(BP_NAME,1,140) AS BP_NAME,
TOTAL_HIT_RATIO_PERCENT, 
DATA_HIT_RATIO_PERCENT, 	
INDEX_HIT_RATIO_PERCENT, 
XDA_HIT_RATIO_PERCENT, DBPARTITIONNUM
FROM SYSIBMADM.BP_HITRATIO
ORDER BY DBPARTITIONNUM
```
Legen Sie einen Schwellenwert für die Tabellengröße fest.
Grundsätzlich gilt, dass kleine Tabellen zusammen im gleichen Tablespace und große Tabellen separat in ihren eigenen Tablespaces gespeichert werden sollten. Entscheiden Sie, wie groß eine Tabelle sein muss, bevor sie ihren eigenen Tablespace erfordert. Im Allgemeinen entspricht der Schwellenwert zum Teil der maximalen Containergröße. Tabellen, die die maximale Containergröße belegen können, sollten in ihren eigenen Tablespaces gespeichert werden. Tabellen, die nahe an dieser Schwelle liegen, sollten auch berücksichtigt werden. Wenden Sie die gleiche Methode bei Indizes an. Teilen Sie die Tabellen und Indizes in solche auf, die ihre eigenen Tablespaces benötigen, und in solche, die zusammen gruppiert werden. Speichern Sie niemals große Tabellen oder Tabellen, auf die häufig zugegriffen wird, mit ihren Indizes zusammen im gleichen Tablespace. Wenn Sie DB2 9 verwenden, sollten Sie erwägen, Attribute für die automatische Speicherung für Tablespaces zu verwenden.
Speichern Sie kleine Tabellen und Indizes nach Zugriff.
Entscheiden Sie auf Grundlage des erwarteten Zugriffs, welche kleinen Tabellen zusammen im gleichen Tablespace gespeichert werden sollen. Speichern Sie Tabellen, auf die häufig zugegriffen wird, in einem Tablespace und Tabellen, auf die selten zugegriffen wird, in einem anderen Tablespace. Mit dieser Methode können Sie die Container der Tablespaces, auf die häufig zugegriffen wird, mit Containern, auf die selten zugegriffen wird, zusammen positionieren. Dasselbe gilt für Indizes. Indizes sollten auch nach Zugriff getrennt werden. Es wird empfohlen, für DB2-Protokolle separate Festplatten getrennt von Indizes und Daten zu nutzen. Esri empfiehlt, dass Sie für den Kernelparameter MAXUPROC des Betriebssystems einen höheren Wert als den Standardwert festlegen, sodass alle Prozesse, die den Benutzern der ArcSDE- und DB2-Instanz gehören, bei einem Aufruf ausgeführt werden können.
Deaktivieren Sie bei AIX-Betriebssystemen db2set DB2_MMAP_READ und db2set DB2_MMAP_WRITE.
Esri empfiehlt, dass Sie die folgenden Variablen bei AIX deaktivieren, um die Leistung zu verbessern. Diese Variablen werden in Verbindung miteinander verwendet, damit DB2 MMAP (Multifunction, Multiservice Access Platform) als alternative Eingabe/Ausgabe-Methode verwenden kann. Dies wird verwendet, um Sperren des Betriebssystems zu vermeiden, wenn mehrere Prozesse parallel in verschiedene Abschnitte derselben Datei schreiben. Die Standardeinstellung ist "ON".
```
db2set DB2_MMAP_READ=OFF
db2set DB2_MMAP_WRITE=OFF
```
Trennen Sie die Tabellen STATES, STATE_LINEAGES und MVTABLES_MODIFIED der ArcSDE-System-Tablespaces von deren Indizes, wenn Sie ausgiebig mit versionierten Änderungen arbeiten.
In den ArcSDE-Systemtabellen werden die ArcSDE- und Geodatabase-Systemtabellen und -Indizes gespeichert, die mit dem ArcSDE-Befehl "sdesetup" erstellt wurden. Die Anzahl und Platzierung der Tablespaces hängt davon ab, wofür Sie die ArcSDE-Datenbank verwenden möchten. Die Platzierung dieser Tabellen und ihrer Indizes wird durch die Speicherparameter des Konfigurationsschlüsselwortes "DBTUNE DATA_DICTIONARY" gesteuert. Das Schlüsselwort "DATA_DICTIONARY" wird ausschließlich für die Erstellung der ArcSDE- und Geodatabase-Systemtabellen verwendet. Versionierte Datenbanken, die ArcGIS-Anwendungen unterstützen, haben einen sehr aktiven State-Tree. Im State-Tree werden die States aller Bearbeitungsvorgänge verwaltet, die auf als versioniert registrierten Tabellen aufgetreten sind. In den vier ArcSDE-Systemtabellen "STATES", "STATE_LINEAGES", "MVTABLES_MODIFIED" und "VERSIONS" werden die Transaktionsinformationen des State-Trees der versionierten Datenbank verwaltet. In einer aktiven versionierten Datenbank kann die Tabelle "STATES_LINEAGE" sehr schnell mehr als eine Million Datensätze haben und mehr als 26 MB Tablespace belegen. Die Tabelle "STATES" ist sehr viel kleiner. In dieser Tabelle werden ungefähr 5.000 Datensätze gespeichert, die ca. 2 MB Tablespace belegen. Die Tabelle MVTABLES_MODIFIED hat gewöhnlich ungefähr 50.000 Einträge, die ca. 1 MB Tablespace belegen. Die Tabelle VERSIONS ist gewöhnlich recht klein. Sie enthält weniger als 100 Zeilen, die ungefähr 64 KB belegen. Bei ArcGIS-Anwendungen, die sehr häufig Bearbeitungsvorgänge durchführen, müssen die Tabellen STATES, STATE_LINEAGES und MVTABLES_MODIFIED sowie deren Indizes in separaten Tablespaces erstellt und im gesamten Dateisystem positioniert werden, um den Eingabe/Ausgabe-Konkurrenzbetrieb zu minimieren.
Hinweis:

Wenn Sie keine versionierte Datenbank verwenden, reduzieren Sie die Ausdehnungsgrößen der Tabellen STATE_LINEAGES, STATES und MVTABLES_MODIFIED und den zugehörigen Indizes auf 40 KB. Erstellen Sie zwei Tablespaces mit der Größe 5 MB auf unterschiedlichen Laufwerken: ein Tablespace für die Tabellen und ein Tablespace für die Indizes.
Erstellen Sie große Tablespaces für Raster-Tabellen, und erstellen Sie einen separaten Tablespace für die Tabelle mit den Raster-Blöcken (BLK).
Die Tabelle für die Raster-Blöcke kann sehr groß werden. Erstellen Sie unbedingt einen separaten, großen Tablespace, um diese Tabelle zu speichern. Sie können einen weiteren Tablespace erstellen, um die verbleibenden Raster-Tabellen zu speichern. Bei der Erstellung der Tablespaces für die Raster-Blocktabelle sollten Sie eine Ausdehnungsgröße von 64 KB und eine Seitengröße von 32 KB verwenden. Mit der Ausdehnungsgröße wird die Anzahl der Seitengröße-Seiten angegeben, die in einen Container geschrieben werden, bevor mit dem nächsten Container fortgefahren wird.
Vorsicht:

Die Ausdehnungsgröße wird bei der Tablespace-Erstellung definiert. Diese Größe kann anschließend nicht einfach geändert werden.
Legen Sie beim Laden großer Datenmengen, z. B. Raster-Daten, fest, dass die Datenbank eine Umlaufprotokollierung verwendet.
Bei der Umlaufprotokollierung werden Datenbankänderungen in einem "Ring" von Protokolldateien aufgezeichnet. Wenn das letzte Protokoll im Ring voll ist, wird wieder die erste Datei verwendet. Da Transaktionsinformationen überschrieben werden können, ist bei Verwendung der Umlaufprotokollierung keine aktualisierende Wiederherstellung möglich. Beim Laden von Daten ist jedoch normalerweise keine Wiederherstellung erforderlich. Die Umlaufprotokollierung ist das Standardprotokollierungsmodell. Wenn Sie die aktualisierende Wiederherstellung verwenden müssen, setzen Sie die Archivprotokollierung ein. Bei der Archivprotokollierung werden die Protokolldateien nicht überschrieben, sondern es werden zusätzliche Protokolle erstellt, um alle seit der letzten Sicherung erfolgten Transaktionen aufzuzeichnen. Beachten Sie, dass für die Archivprotokollierung mehr Festplattenspeicher erforderlich ist, da die Protokolle nicht wie bei der Umlaufprotokollierung immer wieder verwendet werden.

Sogar nach der Optimierung Ihrer Datenbank, um Eingabe/Ausgabe-Konkurrenzbetrieb zu reduzieren, kann es manchmal passieren, dass Deadlocks auftreten. Informationen zu Deadlocks finden Sie unter Deadlocks in einer DB2-Datenbank.

7/10/2012