Es gibt eine Reihe von Konfigurationsparametern sowohl auf Datenbank- als auch auch Datenbankmanagerebene, die Auswirkungen auf die Leistung des Systems haben können. Diese Parameter können in folgende Kategorien eingeteilt werden:
Eine Einführung in die Speicherverwaltung von DB2 finden Sie in Verwendung des Speichers durch DB2.
Die folgenden Parameter wirken sich auf den globalen Datenbankspeicher aus, der auf dem System zugeordnet wird:
Lesen Sie im Abschnitt Verwendung des Speichers durch DB2 die Informationen dazu, welches Verhältnis zwischen globalem Datenbankspeicher und dem übrigen Speicher besteht, der vom Datenbankmanager zugeordnet wird.
Jede Datenbank verfügt über mindestens einen Pufferpool (IBMDEFAULTBP, der bei der Erstellung der Datenbank erstellt wird), sie kann jedoch auch mehrere haben. Alle Pufferpools befinden sich im globalen Speicher, der für alle Anwendungen, die die Datenbank verwenden, verfügbar ist. Der Speicher wird auf dem System zugeordnet, auf dem sich die Datenbank befindet. Wenn die Pufferpools groß genug sind, um die angeforderten Daten zu speichern, sind weniger Zugriffe auf die Platte erforderlich. Sind hingegen die Pufferpools nicht groß genug, kann die allgemeine Leistung der Datenbank erheblich beeinträchtigt werden. Außerdem kann die Verarbeitungsgeschwindigkeit des Datenbankmanagers infolge der umfangreichen Festplattenoperationen (E/A), die zur Verarbeitung der Daten für Ihre Anwendung erforderlich werden, auf die Geschwindigkeit der E/A-Operationen für die Festplatte sinken.
Mit dem Parameter buffpage wird die Größe eines Pufferpools gesteuert, wenn die SQL-Anweisung CREATE BUFFERPOOL oder ALTER BUFFERPOOL mit der Angabe NPAGES -1 ausgeführt wurde. Andernfalls wird der Parameter buffpage ignoriert und der Pufferpool mit der Seitenanzahl erstellt, die im Parameter NPAGES angegeben wird.
Führen Sie die folgende Anweisung aus, wenn Sie feststellen möchten, ob der Parameter buffpage für einen Pufferpool aktiv ist:
SELECT * from SYSCAT.BUFFERPOOLS.
Jeder Pufferpool, der den Wert NPAGES -1 hat, verwendet den Parameter buffpage.
Zwischen der Größe des Pufferpools und der Menge an Speicher, die anderen Systembenutzern zur Verfügung gestellt wird, muß ein geeigneter Kompromiß gefunden werden. Der Speicherbedarf von Datenbank-Servern auf Mehrbenutzersystemen mit hohen Transaktionsgeschwindigkeiten ist so groß, daß Datenbank-Server und Datei- oder Kommunikations-Server häufig voneinander getrennt auf verschiedenen Systemen betrieben werden.
Wenn Ihre Abfragen auf Kurznamen zugreifen, erwägen Sie das Erhöhen der Pufferpoolgröße unter folgenden Umständen:
Alle Pufferpools werden zugeordnet, wenn die erste Anwendung die Verbindung zur Datenbank herstellt oder die Datenbank explizit aktiviert wird. Wenn eine Anwendung Daten aus einer Datenbank abfragt, werden die Seiten mit diesen Daten von der Platte in einen der Pufferpools übertragen. (Beachten Sie, daß Datenbankdaten innerhalb der Tabellen auf der Platte in Seiten gespeichert werden.) Die Seiten werden erst wieder auf Platte geschrieben, wenn die Seite geändert wird und eines der folgenden Ereignisse eintritt:
Empfehlungen:
Eine Seitenauslagerung tritt auf, wenn für die Seite, auf die zugegriffen wird, nicht genügend Hauptspeicher verfügbar ist. Dies führt dazu, daß die Seite in einen temporären Speicher auf der Platte geschrieben ("ausgelagert") wird, um Platz für eine andere Seite zu schaffen. Wird die Seite im temporären Speicher wieder benötigt, wird sie wieder in den Hauptspeicher "eingelagert".
Wenn die Gesamtgröße des Pufferpools (oder der Pufferpools) erhöht wird, müssen Sie eventuell auch den Wert des Parameters dbheap erhöhen.
Mit dem Datenbanksystemmonitor können Sie zur Optimierung Ihrer Pufferpools die Effektivität der Zugriffe auf Pufferpools ermitteln. Weitere Informationen finden Sie im Handbuch System Monitor Guide and Reference.
Für jede Datenbank gibt es einen Datenbankzwischenspeicher, der vom Datenbankmanager für alle Anwendungen, die auf die Datenbank zugreifen, verwendet wird. Er enthält Steuerblockdaten für Tabellen, Indizes, Tabellenbereiche und Pufferpools. Er enthält außerdem Speicherbereich für den Protokollpuffer (logbufsz) und den Katalog-Cache (catalogcache_sz). Daher ist die Größe des Zwischenspeichers von der Anzahl der zu einem bestimmten Zeitpunkt in ihm gespeicherten Steuerblöcke abhängig. Die Steuerblockdaten werden im Zwischenspeicher gehalten, bis alle Anwendungen die Verbindung zur Datenbank getrennt haben.
Der Mindestspeicherbereich, den der Datenbankmanager zu Beginn benötigt, wird bei der Herstellung der ersten Verbindung zugeordnet. Der Datenbereich wird nach Bedarf bis zu der Maximalgröße erweitert, die durch den Parameter dbheap definiert ist.
Empfehlung: Dieser Wert muß erhöht werden, wenn eine Anwendung einen Fehler empfängt, der anzeigt, daß zur Verarbeitung einer Anweisung nicht genügend Speicher im Datenbankzwischenspeicher zur Verfügung steht.
Mit Hilfe des Datenbanksystemmonitors können Sie die größte Speichermenge ermitteln, die für den Datenbankzwischenspeicher verwendet wurde. In der Beschreibung zum Monitorelement db_heap_top (Maximaler zugeordneter Datenbankzwischenspeicher) im Handbuch System Monitor Guide and Reference finden Sie weitere Informationen.
Bei der Einstellung dieses Parameters sollten Sie auch folgende Werte berücksichtigen:
Mit diesem Parameter wird der maximale Speicherbereich angegeben, den der Katalog-Cache aus dem Datenbankzwischenspeicher (dbheap) verwenden kann. Der Katalog-Cache dient zum Speichern der Tabellendeskriptorinformationen, die verwendet werden, wenn während der Kompilierung einer SQL-Anweisung auf eine Tabelle, eine Sicht oder einen Aliasnamen verwiesen wird.
Die Verwendung dieses Cache kann die Leistung beim Binden von SQL-Anweisungen (auch dynamisches SQL) verbessern, wenn auf dieselben Tabellen, Sichten oder Aliasnamen bereits in vorherigen Anweisungen verwiesen wurde. Deskriptorinformationen für deklarierte temporäre Tabellen werden nicht im Katalog-Cache gespeichert; statt dessen wird der Zwischenspeicher zur Anwendungssteuerung verwendet.
Durch die Ausführung von DDL-Anweisungen (Data Definition Language - Datendefinitionssprache) für eine Tabelle wird der Eintrag dieser Tabelle im Katalog-Cache gelöscht. Andernfalls wird ein Tabelleneintrag im Cache behalten, bis der Speicherplatz für eine andere Tabelle benötigt wird. Der Eintrag wird jedoch erst aus dem Cache entfernt, nachdem alle Arbeitseinheiten, die auf diese Tabelle verweisen, beendet wurden.
Empfehlung: Verwenden Sie zu Beginn den Standardwert, und optimieren Sie den Wert mit Hilfe des Datenbanksystemmonitors.
Informationen zu folgenden Monitorelementen finden Sie im Handbuch System Monitor Guide and Reference:
Mit Hilfe dieser Elemente des Datenbanksystemmonitors können Sie ermitteln, ob Sie den Wert dieses Konfigurationsparameters anpassen sollten. Bei der Optimierung dieses Parameters sollten Sie den Wert nur in kleinen Schritten vergrößern, z. B. um jeweils zwei Seiten.
Anmerkung: | In einer Umgebung mit mehreren Knoten befindet sich der Katalog-Cache nur auf dem Katalogknoten. |
Im allgemeinen ist ein größerer Cache erforderlich, wenn eine Arbeitseinheit mehrere dynamische SQL-Anweisungen enthält oder wenn Pakete gebunden werden, die zahlreiche statische SQL-Anweisungen enthalten.
Berücksichtigen Sie bei der Einstellung des Katalog-Cache auch die Größe der Protokolldateien (logbufsz), da sowohl catalogcache_sz als auch logbufsz aus dem Datenbankzwischenspeicher (dbheap) zugeordnet werden.
Mit diesem Parameter kann die Menge an Datenbankzwischenspeicher (der durch den Parameter dbheap definiert wird) angegeben werden, die als Puffer für Protokollsätze verwendet werden soll, bevor diese Protokollsätze auf die Festplatte geschrieben werden. Die Protokollsätze werden bei Eintreten eines der folgenden Umstände auf die Festplatte geschrieben:
Der Wert dieses Parameters muß außerdem kleiner oder gleich dem Wert des Parameters dbheap sein. Durch Puffern der Protokollsätze werden E/A-Operationen für die Protokolldateien effektiver, da weniger häufig Schreiboperationen ausgeführt und bei jeder Schreiboperation mehr Protokollsätze auf die Festplatte geschrieben werden.
Empfehlung: Erhöhen Sie den Wert für die Größe dieses Pufferbereichs, wenn umfangreiche Leseaktivitäten auf einer dedizierten Protokollplatte auftreten oder die Festplatte in erheblichem Maße beansprucht wird. Wenn Sie den Wert dieses Parameters erhöhen, sollten Sie auch den Parameter dbheap berücksichtigen, da der Protokollpuffer einen Speicherbereich verwendet, der mit dem Parameter dbheap gesteuert wird.
Sie können mit dem Datenbanksystemmonitor feststellen, wieviel Speicherbereich des Protokollpuffers für eine bestimmte Transaktion (oder Arbeitseinheit) verwendet wird.
Weitere Informationen finden Sie in der Beschreibung des Monitorelements log_space_used (Protokollbereich für Arbeitseinheit) im Handbuch System Monitor Guide and Reference.
Berücksichtigen Sie bei der Einstellung der Protokollpuffergröße auch die Größe des Katalog-Cache (catalogcache_sz), da sowohl logbufsz als auch catalogcache_sz aus dem Datenbankzwischenspeicher (dbheap) zugeordnet werden.
Dieser Parameter gibt die maximale Speichergröße an, die gleichzeitig von BACKUP, RESTORE, LOAD und den Wiederherstellungsprogrammen verwendet werden kann.
Empfehlung: Verwenden Sie den Standardwert, bis Ihren Dienstprogrammen nicht mehr genügend Speicher zur Verfügung steht. Wenn der Speicher nicht ausreicht, müssen Sie den Wert erhöhen. Wenn der auf Ihrem System verfügbare Speicher eingeschränkt ist, können Sie den Wert für diesen Parameter herabsetzen, um den von den Dienstprogrammen der Datenbank verwendeten Speicher zu begrenzen. Wenn ein zu niedriger Parameterwert angegeben wurde, können Sie die Dienstprogramme eventuell nicht mehr gleichzeitig ausführen. Der von Ihnen angegebene Parameterwert muß so groß sein, daß alle Puffer eingerichtet werden können, die Sie den gleichzeitig ablaufenden Dienstprogrammen zuordnen möchten.
Mit diesem Parameter wird die Größe des Puffers angegeben, der zur Sicherung der Datenbank verwendet wird, wenn die Puffergröße nicht explizit beim Aufruf des Sicherungsprogramms angegeben wird. Weitere Informationen zum Sicherungsprogramm finden Sie in Command Reference.
Bei der Sicherung einer Datenbank werden die Daten zunächst in einen internen Puffer kopiert. Wenn der Puffer voll ist, werden die Daten aus diesem Puffer auf den Sicherungsdatenträger geschrieben.
Durch Optimieren dieser Puffergröße kann die Leistung des Sicherungsprogramms erhöht und die Beeinträchtigung der Leistung anderer, parallel ausgeführter Datenbankoperationen minimiert werden.
Mit diesem Parameter wird die Größe des Puffers angegeben, der zur Wiederherstellung der Datenbank verwendet wird, wenn die Puffergröße nicht explizit beim Aufruf des Wiederherstellungsprogramms angegeben wird. Weitere Informationen zum Wiederherstellungsprogramm finden Sie in Command Reference.
Bei der Wiederherstellung einer Datenbank werden die Daten zunächst vom Sicherungsdatenträger in einen internen Puffer kopiert. Wenn der Puffer voll ist, werden die Daten aus diesem Puffer auf den Datenträger der Zieldatenbank geschrieben.
Durch Optimieren dieser Puffergröße kann die Leistung des Wiederherstellungsprogramms erhöht und die Beeinträchtigung der Leistung anderer, parallel ausgeführter Datenbankoperationen minimiert werden.
Dieser Parameter gibt die Speichermenge an, die für die Sperrenliste zugeordnet wird. Für jede Datenbank gibt es eine Sperrenliste, die die Sperren aller gleichzeitig mit der Datenbank verbundenen Anwendungen enthält. Das Sperren ist eine Funktion des Datenbankmanagers zur Steuerung des gleichzeitigen Zugriffs auf Daten der Datenbank durch mehrere Anwendungen. Sowohl Zeilen als auch Tabellen können gesperrt werden. Der Datenbankmanager fordert eventuell auch Sperren für interne Verwendung an.
Jede Sperre nimmt 36 oder 72 Byte der Sperrenliste in Anspruch, je nachdem, ob für das Objekt andere Sperren aktiv sind::
Wenn der Prozentsatz der Sperrenliste, der von einer Anwendung verwendet wird, den Wert des Parameters maxlocks erreicht, führt der Datenbankmanager eine Sperreneskalation von Zeilenebene auf Tabellenebene für die Sperren aus, die von dieser Anwendung aktiviert wurden (siehe unten). Obwohl der Eskalationsprozeß an sich nicht viel Zeit in Anspruch nimmt, wird durch Sperren ganzer Tabellen (im Vergleich zum Sperren einzelner Zeilen) der gemeinsame Zugriff eingeschränkt und die allgemeine Datenbankleistung kann bei nachfolgenden Zugriffen auf die betroffenen Tabellen beeinträchtigt werden. Es wird empfohlen, die Größe der Sperrenliste folgendermaßen klein zu halten:
Sie können den Parameter LOCKSIZE der Anweisung ALTER TABLE auch verwenden, um das Sperren einer bestimmten Tabelle zu steuern. Genauere Informationen finden Sie im Handbuch SQL Reference.
Die Verwendung der Isolationsstufe RR (Wiederholtes Lesen) kann zu einer automatischen Tabellensperre führen. Weitere Informationen zu Isolationsstufen finden Sie in Kapitel 22, Überlegungen zu Anwendungen.
Wenn die Sperrenliste voll ist, kann die Leistung herabgesetzt werden, da die Sperreneskalation mehr Tabellensperren und weniger Zeilensperren erzeugt und auf diese Weise den gemeinsamen Zugriff auf gemeinsam benutzte Objekte in der Datenbank einschränkt. Zudem kann es mehr gegenseitige Sperren zwischen Anwendungen geben (da sie alle auf eine verringerte Anzahl von Tabellensperren warten), was dazu führt, daß Transaktionen zurückgesetzt werden. Ihre Anwendung empfängt einen SQLCODE-Wert -912, wenn die maximale Anzahl von Sperranforderungen für die Datenbank erreicht wurde.
Empfehlung: Wenn die Sperreneskalationen zu Leistungseinbußen führen, müssen Sie eventuell den Wert dieses Parameters oder den Wert des Parameters maxlocks erhöhen. Mit dem Datenbanksystemmonitor können Sie feststellen, ob Sperreneskalationen auftreten.
Weitere Informationen finden Sie in der Beschreibung des Monitorelements lock_escals (Sperreneskalationen) im Handbuch System Monitor Guide and Reference.
Anhand der folgenden Schritte können Sie die Anzahl der Seiten, die für Ihre Sperrenliste erforderlich sind, ermitteln:
(512 * 36 * maxappls) / 4096
In dieser Formel ist 512 ein Schätzwert für die durchschnittliche Anzahl von Sperren pro Anwendung, und 36 ist die Anzahl der benötigten Byte für jede Sperre eines Objekts, für das bereits eine Sperre aktiv ist.
(512 * 72 * maxappls) / 4096
In dieser Formel ist 72 die Anzahl der benötigten Byte für die erste Sperre eines Objekts.
Sie können mit dem Datenbanksystemmonitor die maximale Anzahl der von einer bestimmten Transaktion aktivierten Sperren feststellen.
Weitere Informationen finden Sie in der Beschreibung des Monitorelements locks_held_top (Maximale Anzahl aktiver Sperren) in System Monitor Guide and Reference.
Anhand dieser Informationen können Sie die geschätzte Anzahl der Sperren pro Anwendung bestätigen oder anpassen. Um diese Auswertung durchzuführen, müssen Sie mehrere Probeanwendungen ausführen und dabei beachten, daß die Monitordaten auf einer Transaktionsebene und nicht auf einer Anwendungsebene geliefert werden.
Der Wert des Parameters locklist sollte eventuell auch dann heraufgesetzt werden, wenn der Parameter maxappls erhöht wird oder wenn die Anwendungen, die ausgeführt werden, nur relativ selten Festschreibungen (COMMIT-Operationen) ausführen.
Wenn Sie diesen Parameter geändert haben, sollten Sie Anwendungen eventuell erneut binden (mit dem Befehl REBIND PACKAGE).
Weitere Informationen zur Leistung von Anwendungen und der Beeinflussung der Abfrageoptimierung finden Sie in Teil 10, Optimieren der Anwendungsleistung.
Der Paket-Cache wird aus dem globalen Datenbankspeicher zugeordnet und für das Caching (Zwischenspeichern) statischer und dynamischer SQL-Anweisungen für eine Datenbank verwendet. In einem partitionierten Datenbanksystem gibt es für jede Datenbankpartition einen Paket-Cache.
Das Caching von Paketen ermöglicht dem Datenbankmanager, den internen Systemaufwand zu verringern, da der Zugriff auf die Systemkataloge beim erneuten Laden eines Pakets oder bei dynamischem SQL eine Kompilierung nicht mehr erforderlich ist. Die Abschnitte werden im Paket-Cache behalten, bis einer der folgenden Umstände eintritt:
Dieses Zwischenspeichern des Abschnitts für eine statische oder dynamische SQL-Anweisung kann die Leistung besonders dann verbessern, wenn dieselbe Anweisung mehrere Male von Anwendungen verwendet wird, die mit einer Datenbank verbunden sind. Dies ist insbesondere für eine Anwendung wichtig, die Transaktionen verarbeitet.
Durch Definieren des Standardwerts (-1) in einer Server-Umgebung oder in einer Umgebung mit einer partitionierter Datenbank wird als Wert für die Berechnung der Seitenzuordnung das Achtfache des Werts für den Konfigurationsparameter maxappls genommen. Wenn das Achtfache von maxappls jedoch kleiner als 32 ist, gilt dies nicht. In diesem Fall entspricht der Standardwert -1 für pckcachesz dem Wert 32.
Empfehlung: Bei der Einstellung dieses Parameters sollten Sie überlegen, ob der zusätzliche Speicher, der für den Paket-Cache reserviert wird, günstiger für einen anderen Zweck zugeordnet werden sollte, z.B. für den Pufferpool. Aus diesem Grund sollten Sie zur Optimierung dieses Parameters Vergleichstests (Benchmark-Tests) durchführen.
Die optimale Einstellung dieses Parameters ist von besonderer Bedeutung, wenn zu Beginn mehrere Abschnitte verwendet werden und nur wenige Abschnitte wiederholt ausgeführt werden. Wenn der Cache zu groß ist, wird Speicher zum Behalten von Kopien der Anfangsabschnitte verschwendet.
In System Monitor Guide and Reference finden Sie Informationen zu folgenden Monitorelementen:
Mit Hilfe dieser Elemente des Datenbanksystemmonitors können Sie ermitteln, ob Sie den Wert dieses Konfigurationsparameters anpassen sollten.
Anmerkung: | Der Paket-Cache ist ein Arbeits-Cache, so daß dieser Parameter nicht auf den
Wert 0 gesetzt werden kann. Diesem Cache muß ausreichend Speicherplatz
für alle Abschnitte der SQL-Anweisungen zugeordnet sein, die momentan
ausgeführt werden. Wenn mehr als der momentan benötigte Speicherplatz
zugeordnet ist, werden Abschnitte zwischengespeichert. Diese Abschnitte
können einfach ausgeführt werden, wenn sie das nächste Mal benötigt werden,
und müssen nicht erneut geladen oder kompiliert werden.
Der durch den Parameter pckcachesz angegebene Grenzwert ist ein veränderlicher Grenzwert. Dieser Grenzwert kann, falls erforderlich, überschritten werden, wenn in dem von den Datenbanken gemeinsam benutzten Speicher noch Speicherplatz verfügbar ist. Sie können mit dem Monitorelement pkg_cache_size_top den Höchstwert ermitteln, bis zu dem der Paket-Cache angewachsen ist. Mit dem Monitorelement pkg_cache_num_overflows können Sie ermitteln, wie häufig der durch den Parameter pckcachesz angegebene Grenzwert überschritten wurde. |
Der folgende Parameter gibt den Arbeitsbereich an, der von allen Agenten (sowohl koordinierende als auch Subagenten) verwendet wird, die für eine Anwendung arbeiten:
128 [1-64 000] (UNIX-Plattformen)
Dieser Parameter legt die maximale Größe (in 4-KB-Seiten) des gemeinsam benutzten Speichers für die Anwendungssteuerung fest. Zwischenspeicher für Anwendungssteuerung werden aus diesem gemeinsam benutzten Speicher zugeordnet.
Für jede Anwendung wird in der Datenbank, in der die Anwendung aktiv ist (bzw. bei partitionierten Datenbanksystemen auf jeder Datenbankpartition, auf der die Anwendung aktiv ist), ein Zwischenspeicher für Anwendungssteuerung zugeordnet. Der Zwischenspeicher wird während der Verbindungsverarbeitung vom ersten Agenten zugeordnet, der eine Anforderung für die Anwendung in der Datenbank (oder auf der Datenbankpartition) erhält. Der Zwischenspeicher ist für die gemeinsame Benutzung von Informationen zwischen Agenten erforderlich, die für dieselbe Anwendung arbeiten. (In einer partitionierten Datenbankumgebung findet die gemeinsame Benutzung auf Datenbankpartitionsebene statt, es findet keine gemeinsame Benutzung über Datenbankpartitionen hinweg statt.)
Dieser Zwischenspeicher wird auch zum Speichern von Deskriptorinformationen für deklarierte temporäre Tabellen verwendet. Die Deskriptorinformationen für alle deklarierten temporären Tabellen, die nicht explizit gelöscht wurden, werden in diesem Zwischenspeicher aufbewahrt und können erst nach dem Löschen der deklarierten temporären Tabelle gelöscht werden.
Anmerkungen:
Empfehlung: Verwenden Sie zunächst den Standardwert. Sie müssen den Wert eventuell erhöhen, wenn Sie komplexe Anwendungen ausführen oder ein System mit zahlreichen Datenbankpartitionen oder deklarierte temporäre Tabellen verwenden. Die erforderliche Speicherkapazität erhöht sich mit der Anzahl deklarierter temporärer Tabellen, die gleichzeitig aktiv sind. Der Tabellendeskriptor einer deklarierten temporären Tabelle mit vielen Spalten ist größer als jener einer Tabelle mit wenigen Spalten. Daher erhöht eine große Anzahl Spalten in den deklarierten temporären Tabellen einer Anwendung auch den Bedarf an Zwischenspeicher zur Anwendungssteuerung.
Die folgenden Parameter wirken sich auf die Menge an Speicher aus, die für jeden Datenbankagenten verwendet wird:
Lesen Sie im Abschnitt Verwendung des Speichers durch DB2 die Informationen dazu, welches Verhältnis zwischen privatem Agentenspeicher und dem übrigen Speicher besteht, der vom Datenbankmanager zugeordnet wird.
Mit diesem Parameter wird die maximale Anzahl von Seiten des privaten Speichers definiert, die für private Sortiervorgänge verwendet werden soll, bzw. die maximale Anzahl von Seiten des gemeinsamen Speichers, die für gemeinsame Sortiervorgänge verwendet werden soll. Wenn es sich um einen privaten Sortiervorgang handelt, bezieht sich dieser Parameter auf den privaten Agentenspeicher. Handelt es sich um einen gemeinsamen Sortiervorgang, bezieht sich dieser Parameter auf den gemeinsamen Datenbankspeicher. Jeder Sortiervorgang verwendet einen getrennten Sortierspeicher, der bei Bedarf vom Datenbankmanager zugeordnet wird. Dieser Sortierspeicher ist der Bereich, in dem Daten sortiert werden. Bei Steuerung durch das Optimierungsprogramm wird anhand der vom Optimierungsprogramm bereitgestellten Informationen ein kleinerer als der durch diesen Parameter angegebene Sortierspeicher zugeordnet.
Empfehlung:
Private und gemeinsame Sortiervorgänge verwenden Speicher aus verschiedenen Speicherquellen. Die Größe des gemeinsamen Sortierspeicherbereichs wird auf der Grundlage des Werts von sheapthres statisch vorherbestimmt, wenn die erste Verbindung zu einer Datenbank hergestellt wird. Die Größe des privaten Sortierspeicherbereichs ist nicht begrenzt.
Der Parameter sheapthres wird für private und gemeinsame Sortiervorgänge unterschiedlich verwendet:
Bei folgenden Operationen wird der Sortierspeicher beispielsweise verwendet: Hash-Verknüpfungen und Operationen, bei denen sich die Tabelle im Speicher befindet.
Durch die explizite Angabe des Schwellenwerts wird verhindert, daß der Datenbankmanager übermäßig große Speichermengen für sehr viele Sortiervorgänge verwendet.
Empfehlung: Sie sollten den Wert dieses Parameters möglichst auf ein angemessenes Vielfaches des größten Werts für den Parameter sortheap setzen, der in Ihrem Datenbankmanagerexemplar definiert ist. Der Wert dieses Parameters sollte mindestens zweimal so groß sein wie der größte Sortierspeicher (sortheap), der für eine Datenbank im Exemplar definiert ist.
Wenn Sie private Sortiervorgänge ausführen und Ihr System über genügend Speicher verfügt, kann der Idealwert für diesen Parameter auf folgende Weise berechnet werden:
(normale Anzahl Agenten, die gleichzeitig für die Datenbank ausgeführt werden) * (sortheap, wie für die Datenbank definiert)
Informationen zur Durchführung von Sortieroperationen in einer SMP-Umgebung finden Sie in Strategien für paralleles Sortieren.
Sie sollten Vergleichstests (Benchmark-Tests) ausführen, um die optimale Einstellung für diesen Parameter zu ermitteln, die Sortierleistung und Speicherbedarf gleichermaßen berücksichtigt. Weitere Informationen finden Sie in Kapitel 31, Durchführen von Vergleichstests. Lesen Sie auch Sortieren, um weitere Informationen zum Sortieren zu erhalten.
Mit dem Datenbanksystemmonitor können Sie die Sortieraktivitäten verfolgen.
Weitere Informationen finden Sie in der Beschreibung des folgenden Monitorelements im Handbuch System Monitor Guide and Reference:
Der Anweisungszwischenspeicher wird als Arbeitsbereich für den SQL-Compiler während des Kompilierens einer SQL-Anweisung verwendet. Mit diesem Parameter wird die Größe dieses Arbeitsbereichs angegeben.
Dieser Bereich bleibt nicht permanent zugeordnet, sondern wird für die Verarbeitung jeder SQL-Anweisung einzeln zugeordnet und anschließend wieder freigegeben. Beachten Sie, daß dieser Arbeitsbereich bei dynamischen SQL-Anweisungen während der Ausführung Ihres Programms, bei statischen SQL-Anweisungen hingegen während des Bindens, und nicht während der Ausführung des Programms, verwendet wird.
Empfehlung: In den meisten Fällen kann der Standardwert für diesen Parameter übernommen werden. Wenn Sie sehr große SQL-Anweisungen verwenden und der Datenbankmanager beim Versuch, eine Anweisung zu optimieren, einen Fehler ausgibt (daß die Anweisung zu komplex ist), sollten Sie den Wert dieses Parameters in gleichmäßigen Schritten (z. B. 256 oder 1024) erhöhen, bis die Fehlersituation bereinigt ist.
64 [ 16 - 60 000 ] (mehrere Partitionen)
Mit diesem Parameter wird die Anzahl der Seiten an privatem Speicher definiert, die zur Verwendung durch den Datenbankmanager für einen bestimmten Agenten oder Subagenten zur Verfügung stehen.
Der Zwischenspeicher wird zugeordnet, wenn ein Agent oder Subagent für eine Anwendung initialisiert wird. Die zugeordnete Speichermenge ist die Mindestmenge, die zur Verarbeitung der an den Agenten oder Subagenten übergebenen Anforderung benötigt wird. Wenn der Agent oder Subagent mehr Zwischenspeicher zur Verarbeitung größerer SQL-Anweisungen benötigt, ordnet der Datenbankmanager weiteren Speicher nach Bedarf bis zu der durch diesen Parameter angegebenen Obergrenze zu.
Anmerkung: | In einer partitionierten Datenbankumgebung wird der Zwischenspeicher für die Anwendungssteuerung (app_ctl_heap_sz) verwendet, um Kopien der in Ausführung befindlichen Abschnitte von SQL-Anweisungen für Agenten und Subagenten zu speichern. SMP-Subagenten verwenden hingegen den Parameter applheapsz, wie es auch Agenten in allen anderen Umgebungen tun. |
Empfehlung: Erhöhen Sie den Wert dieses Parameters, wenn Ihre Anwendungen einen Fehler empfangen, weil im Anwendungszwischenspeicher nicht genügend Speicher verfügbar ist.
Der Anwendungszwischenspeicher (applheapsz) wird aus dem privaten Agentenspeicher heraus zugeordnet.
Mit diesem Parameter wird die maximale Größe des Zwischenspeichers angegeben, der bei Erfassung statistischer Daten mit dem Befehl RUNSTATS verwendet wird.
Empfehlung: Der Standardwert ist geeignet, wenn keine Verteilungsstatistikdaten gesammelt werden oder wenn die Verteilungsstatistikdaten nur für relativ schmale Tabellen gesammelt werden. Der Minimalwert ist nicht zu empfehlen, wenn Verteilungsstatistikdaten gesammelt werden, da nur Tabellen mit einer oder zwei Spalten in den Zwischenspeicher passen.
Dieser Parameter sollte nach der Anzahl der Spalten, für die statistische Daten erfaßt werden, angepaßt werden. Schmale Tabellen mit relativ wenigen Spalten erfordern weniger Speicher für die zu sammelnden Verteilungsstatistikdaten. Breite Tabellen mit vielen Spalten machen erheblich mehr Speicher erforderlich. Wenn Sie Verteilungsstatistikdaten für sehr breite Tabellen sammeln und einen großen Statistikzwischenspeicher benötigen, sollten Sie die Statistikdaten in einer Phase geringer Systemaktivität sammeln, um die Speicheranforderungen anderer Benutzer nicht einzuschränken.
Mit diesem Parameter wird die maximale Speichermenge angegeben, die für den Abfragezwischenspeicher zugeordnet werden kann. Ein Abfragezwischenspeicher wird zur Speicherung jeder Abfrage im privaten Speicher des Agenten verwendet. Die Informationen für jede Abfrage bestehen aus dem Eingabe- und Ausgabe-SQL-Deskriptorbereich, dem Text der Anweisung, dem SQL-Kommunikationsbereich, dem Paketnamen, dem Ersteller, der Abschnittsnummer und dem Konsistenz-Token. Mit diesem Parameter kann sichergestellt werden, daß eine Anwendung nicht unnötig große virtuelle Speicherbereiche innerhalb eines Agenten belegt.
Der Abfragezwischenspeicher wird auch als der Speicher verwendet, aus dem der Speicher für Blockcursor zugeordnet wird. Dieser Speicher besteht aus einem Cursorsteuerungsblock und einem vollständig formatierten Ausgabe-SQL-Deskriptorbereich.
Zu Anfang ist der zugeordnete Abfragezwischenspeicher ebenso groß wie der Zwischenspeicher für die Anwendungsunterstützungsebene, der durch den Parameter aslheapsz definiert ist. Der Abfragezwischenspeicher muß größer oder gleich 2 sowie größer oder gleich dem Wert des Parameters aslheapsz sein. Wenn dieser Abfragezwischenspeicher zur Verarbeitung einer Anforderung nicht ausreicht, wird neuer Speicher in der für die Anforderung erforderlichen Größe (nicht über den Wert query_heap_sz hinaus) zugeordnet. Wenn dieser neue Abfragezwischenspeicher mehr als anderthalbmal so groß wie der Wert für aslheapsz ist, wird der Abfragezwischenspeicher in der Größe von aslheapsz neu zugeordnet, wenn die Abfrage beendet ist.
Empfehlung: In den meisten Fällen ist der Standardwert ausreichend. Als Minimalwert sollte für query_heap_sz ein Wert angegeben werden, der mindestens fünfmal so groß wie der Wert für aslheapsz ist. Dadurch können Abfragen größer als aslheapsz sein, und es wird zusätzlicher Speicher für drei oder vier Blockcursor bereitgestellt, die gleichzeitig geöffnet sein können.
Wenn Sie sehr umfangreiche LOBs (große Objekte) haben, müssen Sie möglicherweise den Wert dieses Parameters erhöhen, damit der Abfragezwischenspeicher groß genug für diese LOBs ist.
Mit diesem Parameter wird die Anzahl der Seiten angegeben, die für den von DB2 Connect und der Einrichtung zur Unterstützung von DRDA-Anwendungs-Servern (DRDA Application Server Support Feature) benutzten Speicher zugeordnet werden sollen. Die folgenden Größen haben Einfuß auf die Speicherkapazität, die aus diesem Zwischenspeicher zugeordnet wird:
Empfehlung: Verwenden Sie den Standardwert, sofern Sie keinen Fehlercode empfangen, der auf unzureichenden DRDA-Zwischenspeicher hinweist.
Dieser Parameter gilt sowohl für abgeschirmte als auch für nicht abgeschirmte benutzerdefinierte Funktionen (UDFs). Für eine abgeschirmte benutzerdefinierte Funktion gibt er die Standardzuordnung für Speicher an, der vom Datenbankprozeß und der benutzerdefinierten Funktion gemeinsam benutzt werden soll. In einer Datenbankumgebung mit einer Partition gibt es nur einen gemeinsam benutzten Speicherbereich. In einer partitionierten Datenbankumgebung gibt es einen gemeinsam benutzten Speicherbereich für jeden Datenbankpartitions-Server, und alle Anwendungsagenten und Subagenten, die auf diesem Server aktiv sind, verwenden denselben gemeinsamen Speicherbereich.
Für nicht abgeschirmte benutzerdefinierte Funktionen gibt er die Größe des privaten Arbeitsspeichers an. In einer Datenbankumgebung mit einer Partition wird der Zwischenspeicher aus dem privaten Speicher zugeordnet. In einer partitionierten Datenbankumgebung wird der Zwischenspeicher aus dem globalen Anwendungsspeicher (Application Global Memory) für jeden Datenbankpartitions-Server zugeordnet, und alle Agenten und Subagenten, die auf diesem Datenbankpartitions-Server für diese Anwendung aktiv sind, verwenden denselben gemeinsamen Speicherbereich.
Bei abgeschirmten und nichtabgeschirmten benutzerdefinierten Funktionen wird dieser Speicher zur Übergabe von Daten zwischen der UDF und der Datenbank verwendet.
Wenn keine benutzerdefinierten Funktionen in Anwendungen verwendet werden, wird der Speicher nicht zugeordnet. Wenn sowohl abgeschirmte als auch nichtabgeschirmte UDFs in derselben Anwendung ausgeführt werden, erfolgen zwei Speicherzuordnungen: eine für abgeschirmte UDFs und eine für nichtabgeschirmte UDFs.
Weitere Informationen zu benutzerdefinierten Funktionen finden Sie in Application Development Guide und in SQL Reference.
Empfehlung: In allen Fällen, in denen keine LOB-Daten an eine benutzerdefinierte Funktion übergeben werden, sollte die Standardeinstellung angemessen sein. In Fällen, in denen LOB-Daten an eine benutzerdefinierte Funktion übergeben werden, müssen Sie eventuell den zuzuordnenden Speicherbereich vergrößern. Sie sollten den Wert dieses Parameters mindestens um zwei Seiten größer definieren als die Größe der Eingabeargumente und des Ergebnisses der externen Funktion.
Anmerkung: | Der Speicherbedarf für UDFs ist häufig kumulativ, so daß sich die Anzahl von UDFs, die in einer Anwendung aufgerufen werden, auf die optimale Einstellung dieses Parameters auswirkt. |
Der Agentenstapelspeicher ist der virtuelle Speicherbereich, der von DB2 für jeden Agenten zugeordnet wird. Dieser Speicher wird zugeordnet, wenn er zur Verarbeitung einer SQL-Anweisung angefordert wird. Sie können diesen Parameter zur Optimierung der Speicherauslastung des Servers für einen bestimmten Satz von Anwendungen verwenden. Komplexere Abfragen benötigen im Vergleich zu einfachen Abfragen mehr Stapelspeicherbereich.
Dieser Parameter gilt nicht für auf UNIX basierende Plattformen.
Empfehlung: In den meisten Fällen kann die Standardstapelspeichergröße verwendet werden. Sie sollten den Wert für diesen Parameter nur erhöhen, wenn in Ihrer Umgebung viele extrem komplexe Abfragen ausgeführt werden. Wenn die Stapelspeichergröße zur Verarbeitung Ihrer SQL-Anweisung nicht ausreicht, wird ein Fehlereintrag in der Datei db2diag.log protokolliert und ein SQL-Code zurückgegeben. In diesem Fall müssen Sie den Wert für agent_stack_sz erhöhen und das Datenbankexemplar erneut starten.
Sie können eventuell die Stapelspeichergröße verringern, um anderen Clients mehr Adreßraum zur Verfügung zu stellen. Dies ist möglich, wenn Ihre Umgebung folgende Kriterien erfüllt:
Die Größe des Agentenstapelspeichers und die Anzahl gleichzeitig ausgeführter Clients stehen in einem umgekehrten Verhältnis zueinander: Durch eine Vergrößerung des Stapelspeichers wird die mögliche Anzahl der Clients verringert, die gleichzeitig ausgeführt werden können. Die Ursache hierfür ist, daß der Adreßraum unter OS/2 und Windows NT begrenzt ist. Sie können beispielsweise unter OS/2 400 MB Adreßraum haben. (Diese Größe hängt jedoch von der Angabe in der Datei config.sys ab). Wenn Sie agent_stack_sz auf 1 MB setzen, können Sie nur bis zu 400 Agenten haben. (Aufgrund anderen Bedarfs für Adreßraum, z. B für Pufferpools, werden Sie wahrscheinlich sogar noch viel weniger Agenten verwenden können.) Das heißt, wenn maxagents auf einen größeren Wert (z. B. 5000) gesetzt ist, werden Sie diesen Grenzwert nie erreichen.
Mit diesem Parameter wird die Anzahl der Seiten angegeben, die der Datenbank-Server-Prozeß als privaten virtuellen Speicher reserviert, wenn ein Datenbankmanagerexemplar gestartet wird (db2start). Wenn der Server mehr privaten Speicher benötigt, versucht er gegebenenfalls, mehr Speicher vom Betriebssystem zu erhalten.
Dieser Parameter gilt nicht für auf UNIX basierende Systeme.
Empfehlung: Verwenden Sie den Standardwert.
Sie sollten den Wert dieses Parameters nur ändern, wenn Sie mehr Speicher für den Datenbank-Server reservieren möchten. Dadurch wird der Zeitaufwand für die Zuordnung verringert. Allerdings sollte dieser Wert nicht zu hoch gesetzt werden, da die Leistung anderer Nicht-DB2-Anwendungen beeinträchtigt werden kann.
32 [ -1; 32 - 112 000 ] auf dem Satellitendatenbank-Server mit lokalen Clients
Dieser Parameter wird zur Festlegung des nicht benutzten privaten Agentenspeichers verwendet, der zugeordnet bleibt und zur Verwendung durch neue Agenten, die gestartet werden, zur Verfügung steht. Er gilt nicht für auf UNIX basierende Plattformen.
Nach Beendigung eines Agenten wird nicht automatisch der gesamte, von diesem Agenten benutzte Speicher freigegeben, sondern der Datenbankmanager gibt nur die überschüssigen Speicherzuordnungen frei, die nach der folgenden Formel berechnet werden:
zugeordneter privater Speicher - (benutzter privater Speicher + priv_mem_thresh)
Wenn diese Formel ein negatives Ergebnis liefert, wird keine Aktion ausgeführt.
Die folgende Tabelle enthält ein Beispiel, das verdeutlicht, wann Speicher
zugeordnet und freigegeben wird. In diesem Beispiel wird für den
Parameter priv_mem_thresh der willkürliche Wert 100
verwendet.
Aktionsbeschreibung | Zugeordneter Speicher | Benutzter Speicher |
---|---|---|
Eine Anzahl von Agenten ist aktiv und verfügt über zugeordneten Speicher. | 1000 | 1000 |
Ein neuer Agent wird gestartet und verwendet 100 Seiten Speicher. | 1100 | 1100 |
Ein Agent, der 200 Seiten Speicher benutzte, wird beendet. (Beachten Sie, daß 100 Seiten Speicher freigegeben werden, während die anderen 100 Seiten zur möglichen zukünftigen Verwendung zugeordnet bleiben.) | 1000 | 900 |
Ein Agent, der 50 Seiten Speicher benutzte, wird beendet. (Beachten Sie, daß 50 Seiten Speicher freigegeben werden und 100 überschüssige Seiten, die von den vorhandenen Agenten nicht verwendet werden, zugeordnet bleiben.) | 950 | 850 |
Ein neuer Agent wird gestartet, für den 150 Seiten Speicher erforderlich sind. (100 der 150 Seiten sind bereits zugeordnet, so daß der Datenbankmanager nur noch weitere 50 Seiten für diesen Agenten zuordnen muß.) | 1000 | 1000 |
Der Wert "-1" bewirkt, daß dieser Parameter den Wert des Parameters min_priv_mem verwendet.
Empfehlung: Bei der Einstellung dieses Parameters sollten die Abläufe, wann und wie Clients die Verbindung herstellen bzw. trennen, sowie der Speicherbedarf anderer Prozesse auf derselben Maschine berücksichtigt werden.
Wenn es nur eine kurze Phase gibt, während der viele Clients gleichzeitig mit der Datenbank verbunden sind, verhindert ein hoher Schwellenwert, daß ungenutzter Speicher freigegeben und für andere Prozesse verfügbar gemacht wird. Dies führt zu einer schlechten Speicherverwaltung, die andere Prozesse, für die Speicher erforderlich ist, beeinträchtigen kann.
Wenn die Anzahl gleichzeitig zugreifender Clients eher gleichmäßig hoch ist, aber zahlreiche Verbindungsänderungen auftreten, stellt ein hoher Schwellenwert sicher, daß Speicher für die Client-Prozesse verfügbar ist, und verringert so den Systemaufwand, der durch die Zuordnung und Freigabe von Speicher entsteht.
Die folgenden Parameter wirken sich auf die Menge an Speicher aus, der zum Übergeben von Daten zwischen den Anwendungs- und Agentenprozessen zugeordnet wird:
Lesen Sie im Abschnitt Verwendung des Speichers durch DB2 die Informationen dazu, welches Verhältnis zwischen diesem von Anwendungen und Agenten gemeinsam benutzten Speicher und dem übrigen Speicher besteht, der vom Datenbankmanager zugeordnet wird.
Der Zwischenspeicher für die Anwendungsunterstützungsebene ist ein Kommunikationspuffer zwischen der lokalen Anwendung und dem zugeordneten Agenten. Dieser Puffer wird als gemeinsam benutzter Speicher von jedem Datenbankmanageragenten, der gestartet wird, zugeordnet.
Wenn die Anforderung an den Datenbankmanager oder die zugehörige Antwort nicht in den Puffer paßt, wird sie in zwei oder mehr Sende-/Empfangspufferpaare geteilt. Die Größe dieses Puffers sollte so eingestellt werden, daß die Mehrzahl der Anforderungen mit einem einzigen Sende-/Empfangspufferpaar verarbeitet werden kann. Die Größe der Anforderung hängt von der Speichermenge ab, die zur Speicherung folgender Daten erforderlich ist:
Außer zur Steuerung dieses Kommunikationspuffers wird dieser Parameter auch dazu verwendet, die Größe des E/A-Blocks festzulegen, wenn ein Blockcursor geöffnet wird. Dieser Speicher für Blockcursor wird aus dem privaten Adreßraum der Anwendung zugeordnet. Sie sollten daher die optimale Größe des privaten Speichers, der jedem Anwendungsprogramm zugeordnet werden soll, ermitteln. Wenn der Datenbank-Client keinen Bereich für einen Blockcursor aus dem privaten Speicher der Anwendung zuordnen kann, wird ein Cursor ohne Blockung geöffnet.
Die Daten, die von der lokalen Anwendung gesendet werden, werden vom Datenbankmanager in einem Bereich zusammenhängenden Speichers empfangen, der aus dem Abfragezwischenspeicher zugeordnet wurde. Mit dem Parameter aslheapsz wird die Anfangsgröße des Abfragezwischenspeichers (für lokale und ferne Clients) festgelegt. Die maximale Größe des Abfragezwischenspeichers wird durch den Parameter query_heap_sz definiert.
Empfehlung: Wenn die Anforderungen Ihrer Anwendung im allgemeinen klein sind und die Anwendung auf einem System mit eingeschränkter Speicherkapazität ausgeführt wird, können Sie den Wert dieses Parameters verringern. Wenn Ihre Abfragen im allgemeinen sehr groß sind und mehr als eine Sende- und Empfangsanforderung erfordern und die Speicherkapazität Ihres Systems nicht eingeschränkt ist, können Sie den Wert dieses Parameters erhöhen.
Berechnen Sie anhand der folgenden Formel die Anzahl der Seiten für aslheapsz:
aslheapsz >= ( Größe von(Eingabe-SQL-Deskriptorbereich) + Größe von(jeder Eingabe-SQLVAR) + Größe von(Ausgabe-SQL-Deskriptorbereich) + 250 ) / 4096
Beachten Sie außerdem, welche Auswirkung dieser Parameter auf die Anzahl und die mögliche Größe von Blockcursorn hat. Große Zeilenblöcke führen zu einer erhöhten Leistung, wenn die Anzahl oder die Größe der Zeilen, die übertragen werden, groß ist (z. B., wenn die Datenmenge größer als 4096 Byte ist). Dies hat jedoch den Nachteil, daß größere Satzblöcke die Größe des für jede Verbindung benötigten Arbeitsspeichers erhöhen.
Größere Satzblöcke können außerdem mehr Abrufanforderungen verursachen, als tatsächlich für die Anwendung erforderlich wären. Sie können die Anzahl der Abrufanforderungen mit der Klausel OPTIMIZE FOR in der Anweisung SELECT in Ihrer Anwendung steuern. Weitere Informationen zur Klausel OPTIMIZE FOR finden Sie in Klausel OPTIMIZE FOR n ROWS.
Mit diesem Parameter wird die Größe des Puffers für die Kommunikation zwischen fernen Anwendungen und ihren Datenbankagenten auf dem Datenbank-Server festgelegt. Wenn ein Datenbank-Client die Verbindung zu einer fernen Datenbank anfordert, wird dieser Kommunikationspuffer auf dem Client angelegt. Auf dem Datenbank-Server wird zu Anfang ein Kommunikationspuffer von 32767 Byte zugeordnet, bis eine Verbindung hergestellt ist und der Server den Wert des Parameters rqrioblk auf dem Client ermitteln kann. Wenn der Server diesen Wert ermittelt hat, wird der Kommunikationspuffer auf dem Server neu zugeordnet, sofern der Client-Puffer nicht 32767 Byte groß ist.
Außer für diesen Kommunikationspuffer wird dieser Parameter auch dazu verwendet, die Größe des E/A-Blocks auf dem Datenbank-Client festzulegen, wenn ein Blockcursor geöffnet wird. Dieser Speicher für Blockcursor wird aus dem privaten Adreßraum der Anwendung zugeordnet. Sie sollten daher die optimale Größe des privaten Speichers, der jedem Anwendungsprogramm zugeordnet werden soll, ermitteln. Wenn der Datenbank-Client keinen Bereich für einen Blockcursor aus dem privaten Speicher der Anwendung zuordnen kann, wird ein Cursor ohne Blockung geöffnet.
Empfehlung: Bei Cursorn ohne Blockung könnte ein Grund zur Erhöhung des Werts für diesen Parameter darin bestehen, daß die Daten (z. B. LOB-Daten), die durch eine einzige SQL-Anweisung übertragen werden sollen, so umfangreich sind, daß der Standardwert nicht ausreicht.
Beachten Sie außerdem, welche Auswirkung dieser Parameter auf die Anzahl und die mögliche Größe von Blockcursorn hat. Große Zeilenblöcke führen zu einer erhöhten Leistung, wenn die Anzahl oder die Größe der Zeilen, die übertragen werden, groß ist (z. B., wenn die Datenmenge größer als 4096 Byte ist). Dies hat jedoch den Nachteil, daß größere Satzblöcke die Größe des für jede Verbindung benötigten Arbeitsspeichers erhöhen.
Größere Satzblöcke können außerdem mehr Abrufanforderungen verursachen, als tatsächlich für die Anwendung erforderlich wären. Sie können die Anzahl der Abrufanforderungen mit der Klausel OPTIMIZE FOR in der Anweisung SELECT in Ihrer Anwendung steuern. Weitere Informationen zur Klausel OPTIMIZE FOR finden Sie im Abschnitt Klausel OPTIMIZE FOR n ROWS.
Mit diesem Parameter wird die Größe des Kommunikationspuffers zwischen DOS/Windows 3.1-Anwendungen und deren Datenbankagenten auf dem Datenbank-Server festgelegt. Dieser Parameter ähnelt dem Parameter rqrioblk. Mit ihm kann jedoch ein anderer Wert für mit DOS/Windows 3.1-Clients verwendete Blöcke festgelegt werden. In einer DB2-Konfigurationsdatei können Sie den Parameter rqrioblk (für Windows 32-Bit-, OS/2- und UNIX-Clients verwendet) und den Parameter dos_rqrioblk (für DOS- und Windows 3.1-Clients verwendet) festlegen.
Außer für diesen Kommunikationspuffer wird dieser Parameter auch dazu verwendet, die Größe des E/A-Blocks auf dem Datenbank-Client festzulegen, wenn ein Blockcursor geöffnet wird. Dieser Speicher für Blockcursor wird aus dem privaten Adreßraum der Anwendung zugeordnet. Sie sollten daher die optimale Größe des privaten Speichers, der jedem Anwendungsprogramm zugeordnet werden soll, ermitteln. Wenn der Datenbank-Client keinen Bereich für einen Blockcursor aus dem privaten Speicher der Anwendung zuordnen kann, wird ein Cursor ohne Blockung geöffnet.
Empfehlung: Bei Cursorn ohne Blockung könnte ein Grund zur Erhöhung des Werts für diesen Parameter darin bestehen, daß die Daten (z. B. LOB-Daten), die durch eine einzige SQL-Anweisung übertragen werden sollen, so umfangreich sind, daß der Standardwert nicht ausreicht.
Beachten Sie außerdem, welche Auswirkung dieser Parameter auf die Anzahl und die mögliche Größe von Blockcursorn hat. Große Zeilenblöcke führen zu einer erhöhten Leistung, wenn die Anzahl oder die Größe der Zeilen, die übertragen werden, groß ist (z. B., wenn die Datenmenge größer als 4096 Byte ist). Dies hat jedoch den Nachteil, daß größere Satzblöcke die Größe des für jede Verbindung benötigten Arbeitsspeichers erhöhen.
Größere Satzblöcke können außerdem mehr Abrufanforderungen verursachen, als tatsächlich für die Anwendung erforderlich wären. Sie können die Anzahl der Abrufanforderungen mit der Klausel OPTIMIZE FOR in der Anweisung SELECT in Ihrer Anwendung steuern. Weitere Informationen zur Klausel OPTIMIZE FOR finden Sie im Abschnitt Klausel OPTIMIZE FOR n ROWS.
Die folgenden Parameter wirken sich auf den Speicher aus, der auf Exemplarebene zugeordnet und verwendet wird:
Mit diesem Parameter wird der Speicherbereich in Seiten festgelegt, der für Daten des Datenbanksystemmonitors zugeordnet werden soll. Der Speicher wird aus dem Monitorzwischenspeicher zugeordnet, wenn Sie eine Datenbankmonitorfunktion ausführen, wie z. B. Erstellen einer Momentaufnahme (Snapshot), Aktivieren eines Monitorschalters oder eines Ereignismonitors, Zurücksetzen eines Monitors o. ä.
Erhält der Parameter den Wert 0, kann der Datenbankmanager keine Daten des Datenbanksystemmonitors sammeln.
Empfehlung: Der für die Monitorfunktionen erforderliche Speicherbereich ist von der Anzahl der Überwachungsanwendungen (Anwendungen, die Momentaufnahmen machen, oder Ereignismonitoren), den aktivierten Schaltern und der Datenbankaktivität abhängig.
Mit Hilfe der folgenden Formel kann ein Näherungswert für die Anzahl der für den Monitorfreispeicher erforderlichen Seiten berechnet werden:
( Anzahl der Überwachungsanwendungen + 1 ) * ( Anzahl der Datenbanken * (800 + ( Anzahl der Tabellen im Zugriff * 20 ) + ( ( Anzahl der verbundenen Anwendungen + 1) * (200 + (Anzahl der Tabellenbereiche * 100) ) ) ) ) / 4096
Wenn der verfügbare Speicher in diesem Freispeicher erschöpft ist, wird eine der folgenden Maßnahmen ausgeführt:
Wenn der Parameter dir_cache auf "yes" gesetzt wird, werden die Datenbank-, Knoten- und DCS-Verzeichnisdateien im Cache zwischengespeichert. Durch die Verwendung des Verzeichnis-Cache wird der Aufwand für die Verbindung verringert, indem die E/A-Operationen für Verzeichnisdateien vermieden und die Suchoperationen in Verzeichnissen zum Abruf von Verzeichnisdaten minimiert werden. Es gibt zwei Arten von Verzeichnis-Caches:
Anmerkung: | Für die unterstützten Windows-Umgebungen ist nur der private Cache gültig. |
Ein privater Cache ist ein privater Speicherbereich für eine Anwendung, der zur Zwischenspeicherung der Daten verwendet wird, die in allen Verzeichnisdateien gelesen werden, wenn die Anwendung die erste Verbindungsanforderung absetzt. Der Cache wird vom Anwendungsprozeß auch für nachfolgende Verbindungsanforderungen verwendet und während der Dauer des Anwendungsprozesses beibehalten. Wenn eine Datenbank nicht im privaten Cache gefunden wird, werden die Verzeichnisdateien nach den Daten durchsucht, aber der Cache wird nicht aktualisiert. Wenn die Anwendung einen Verzeichniseintrag ändert, wird durch die nächste Verbindungsanforderung innerhalb dieser Anwendung eine Aktualisierung des Caches für diese Anwendung bewirkt. Der private Cache für andere Anwendungen wird nicht aktualisiert. Wenn der Anwendungsprozeß beendet ist, wird der Cache freigegeben. (Zur Aktualisierung des Verzeichnis-Cache, der von einer Sitzung des Befehlszeilenprozessors verwendet wird, geben Sie den Befehl db2 terminate ein.)
Ein gemeinsam benutzter Cache ist gemeinsam benutzter Speicher, der zur Zwischenspeicherung von Daten verwendet wird, die in allen Verzeichnisdateien gelesen werden, wenn ein Datenbankmanagerexemplar gestartet wird. Dieser Cache wird von einigen der Datenbankmanagerprozesse verwendet und bleibt bestehen, bis das Datenbankmanagerexemplar gestoppt wird (db2stop). Wenn ein Verzeichniseintrag in diesem Cache nicht gefunden wird, werden die Verzeichnisdateien nach den Daten durchsucht. Dieser gemeinsam benutzte Cache wird während der Ausführung des Exemplars zu keinem Zeitpunkt aktualisiert.
Empfehlung: Verwenden Sie einen Verzeichnis-Cache, wenn Ihre Verzeichnisdateien nicht häufig geändert werden und die Leistung von entscheidender Bedeutung ist.
Auf fernen Clients kann darüber hinaus der Verzeichnis-Cache von Vorteil sein, wenn Ihre Anwendungen mehrere verschiedene Verbindungsanforderungen absetzen. In diesem Fall verringert das Zwischenspeichern die Häufigkeit, mit der eine einzige Anwendung die Verzeichnisdateien lesen muß.
Der Verzeichnis-Cache kann auch die Leistung bei der Erstellung von Momentaufnahmen des Datenbanksystemmonitors erhöhen. Außerdem sollten Sie beim Aufruf der Momentaufnahme den Datenbanknamen explizit angeben und nicht den Aliasnamen für die Datenbank verwenden.
Anmerkung: | Bei der Erstellung von Momentaufnahmen können Fehler auftreten, wenn der Verzeichnis-Cache aktiviert wurde und Datenbanken katalogisiert, entkatalogisiert, erstellt oder gelöscht werden, nachdem der Datenbankmanager gestartet wurde. |
Mit diesem Parameter wird die Größe des Puffers für die Prüfung der Datenbank angegeben. Weitere Informationen zur Prüffunktion finden Sie im Abschnitt zum Prüfen von DB2-Aktivitäten im Handbuch Systemverwaltung: Konzept.
Der Standardwert für diesen Konfigurationsparameter ist Null (0). Wenn der Wert Null (0) ist, wird der Prüfpuffer nicht verwendet. Wenn der Wert größer als Null (0) ist, wird dem Prüfpuffer Speicherbereich zugeordnet, in den die von der Prüffunktion generierten Prüfsätze gestellt werden. Der Wert multipliziert mit 4-KB-Seiten ergibt die für den Prüfpuffer zugeordnete Speichermenge. Der Prüfpuffer kann nicht dynamisch zugeordnet werden; DB2 muß gestoppt und anschließend erneut gestartet werden, bevor der neue Wert für diesen Parameter in Kraft tritt.
Wenn Sie den Standardwert für diesen Parameter in einen Wert ändern, der größer als Null (0) ist, schreibt die Prüffunktion Datensätze asynchron im Vergleich zur Ausführung der Anweisungen, die die Prüfsätze generieren, auf Platte. Durch das Erhöhen des Standardparameterwerts Null (0) wird die Leistung von DB2 verbessert. Der Wert Null (0) bedeutet, daß die Prüffunktion Datensätze synchron zur (d. h. zur gleichen Zeit wie die) Ausführung der Anweisungen, die die Prüfsätze generieren, auf Platte schreibt. Die synchrone Verarbeitung während der Prüfung verringert die Leistung von unter DB2 ausgeführten Anwendungen.
Dieser Parameter legt die maximale Größe des Zwischenspeichers fest, der vom Java-Interpreter verwendet wird.
Es gibt einen Zwischenspeicher für jeden DB2-Prozeß (einen für jeden Agenten oder Subagenten auf UNIX-gestützten Plattformen und einen für jedes Exemplar auf anderen Plattformen); außerdem gibt es einen Zwischenspeicher für jede abgeschirmte benutzerdefinierte Funktion und für jede abgeschirmte gespeicherte Prozedur. Nur die Agenten oder Prozesse, die in Java geschriebene benutzerdefinierte Funktionen oder gespeicherte Prozeduren ausführen, ordnen diesen Speicher zu. In partitionierten Datenbanksystemen wird der Zwischenspeicher mit der Anzahl der Datenbankpartitions-Server multipliziert.
Die folgenden Parameter beeinflussen die Sperrenverwaltung in Ihrer Umgebung:
Siehe auch Maximaler Speicher für Sperrenliste (locklist).
Sperren enthält einen allgemeinen Überblick über die Verwendung von Sperren durch den Datenbankmanager zur Erhaltung der Datenintegrität.
Bei Auftreten gegenseitiger Sperren müssen zwei oder mehr Anwendungen, die auf dieselbe Datenbank zugreifen, unendlich lange auf eine Ressource warten. Die Anwendungen warten unendlich lange, da jede Anwendung eine Ressource gesperrt hat, die von der anderen Anwendung zur Fortsetzung der Verarbeitung benötigt wird.
Der Parameter für das Intervall zur Prüfung auf gegenseitige Sperren definiert die Häufigkeit, mit der vom Datenbankmanager alle mit der Datenbank verbundenen Anwendungen auf gegenseitige Sperren überprüft werden.
Anmerkungen:
Empfehlung: Durch Erhöhung des Werts für diesen Parameter wird die Häufigkeit der Prüfung auf gegenseitige Sperren verringert, wodurch die Zeit, die Anwendungsprogramme auf die Aufhebung gegenseitiger Sperren warten müssen, erhöht wird.
Durch Angabe eines niedrigeren Werts für diesen Parameter wird die Häufigkeit der Prüfung auf gegenseitige Sperren erhöht, wodurch die Zeit, die Anwendungsprogramme auf die Aufhebung gegenseitiger Sperren warten müssen, verkürzt, die Zeit, die der Datenbankmanager auf die Prüfung gegenseitiger Sperren verwendet, jedoch verlängert wird. Wenn das Prüfintervall zu klein ist, kann dies zu einer Verschlechterung der Laufzeitleistung führen, weil der Datenbankmanager häufig nach gegenseitigen Sperren sucht. Wenn dieser Parameter mit einem niedrigeren Wert versehen wird, um den gemeinsamen Zugriff zu verbessern, sollten Sie darauf achten, daß die Parameter maxlocks und locklist entsprechend eingestellt sind, um unnötige Sperreneskalationen zu vermeiden, die zu Zugriffskonflikten und weiteren gegenseitigen Sperren führen können.
Eine Sperreneskalation ist der Prozeß, durch den jeweils mehrere Zeilensperren für eine Tabelle durch eine Tabellensperre ersetzt werden, um die Anzahl der Sperren in der Liste zu verringern. Mit diesem Parameter wird definiert, wieviel Prozent der Sperrenliste eine Anwendung belegen muß, damit der Datenbankmanager eine Eskalation ausführt. Wenn die Anzahl der Sperren, die von einer Anwendung aktiviert wurden, diesen Prozentwert der Gesamtgröße der Sperrenliste erreicht, wird für die Sperren dieser Anwendung eine Sperreneskalation ausgeführt. Eine Sperreneskalation wird auch dann ausgeführt, wenn in der Sperrenliste kein weiterer Platz mehr verfügbar ist.
Der Datenbankmanager ermittelt die zu eskalierenden Sperren, indem er die Sperrenliste für die Anwendung nach der Tabelle mit den meisten gesperrten Zeilen durchsucht. Wenn nach der Ersetzung dieser Sperren durch eine einzige Tabellensperre der Wert für maxlocks nicht mehr überschritten wird, wird die Sperreneskalation beendet. Andernfalls wird die Eskalation fortgesetzt, bis der von dieser Anwendung belegte Prozentsatz der Sperrenliste unter den Wert von maxlocks gesunken ist. Das Produkt aus dem Wert des Parameters maxlocks und dem Wert des Parameters maxappls darf nicht kleiner als 100 sein.
Empfehlung: Bei der Einstellung des Parameters maxlocks ist die Größe der Sperrenliste (locklist) zu berücksichtigen:
maxlocks = 100 * (512 Sperren pro Anwendung * 32 Byte pro Sperre * 2) / (locklist * 4096 Byte)
Diese Beispielformel erlaubt jeder Anwendung, das Zweifache der Durchschnittsanzahl von Sperren zu aktivieren.
Sie können den Wert für maxlocks erhöhen, wenn nur wenige Anwendungen gleichzeitig ausgeführt werden, da in diesem Fall kein hohes gleichzeitiges Zugriffsaufkommen für die Sperrenliste zu erwarten ist.
Mit Hilfe des Datenbanksystemmonitors können Sie diesen Konfigurationsparameter verfolgen und seinen Wert optimieren.
Weitere Informationen finden Sie in der Beschreibung des Monitorelements locks_held_top (Maximale Anzahl aktiver Sperren) in System Monitor Guide and Reference.
Für das Optimierungsprogramm ist die Steuerung der Sperreneskalation durch diesen Parameter wichtig, da es diesen Parameter bei der Bestimmung von Zugriffspfaden verwendet. Wenn Sie diesen Parameter geändert haben, sollten Sie Anwendungen eventuell erneut binden (mit dem Befehl REBIND PACKAGE).
Mit diesem Parameter wird die Anzahl der Sekunden angegeben, die eine Anwendung auf eine Sperre wartet. Dies trägt zur Vermeidung globaler gegenseitiger Sperren von Anwendungen bei.
Wenn dieser Parameter auf 0 gesetzt wird, wird nicht auf Sperren gewartet. In diesem Fall erhält die Anwendung, wenn zum Zeitpunkt der Anforderung keine Sperre verfügbar ist, sofort die Rückmeldung -911.
Wenn dieser Parameter auf den Wert -1 gesetzt wird, wird die Überwachung des Zeitlimits für Sperren inaktiviert. In diesem Fall wird auf eine Sperre gewartet (wenn zum Zeitpunkt der Anforderung keine verfügbar ist), bis eine der folgenden Situationen eintritt:
Empfehlung: In einer Umgebung, in der Transaktionen verarbeitet werden (OLTP-Umgebung), können Sie einen Anfangswert von 30 Sekunden verwenden. In einer Umgebung, in der nur Abfragen durchgeführt werden, können Sie mit einem höheren Wert beginnen. In beiden Fällen sollten Sie diesen Parameter jedoch mit Hilfe von Vergleichstests (Benchmark-Tests) optimieren.
Wenn Sie bei der Arbeit mit Data Links File Manager (DLFM) im Protokoll "db2diag.log" des Exemplars von Data Links File Manager Überschreitungen der Sperrzeit feststellen, erhöhen Sie den Wert für den Parameter locktimeout. Erhöhen Sie gegebenenfalls auch den Wert für locklist.
Der Wert sollte so eingestellt werden, daß schnell erkannt wird, wenn Wartezeiten aufgrund außergewöhnlicher Situationen, wie einer blockierten Transaktion (z. B. weil ein Benutzer seine Workstation verlassen hat), auftreten. Sie sollten den Wert so hoch einstellen, daß gültige Sperranforderungen das Zeitlimit nicht aufgrund von Spitzenbelastungen überschreiten, da bei hoher Systemauslastung länger auf Sperren gewartet werden muß.
Mit dem Datenbanksystemmonitor können Sie die Häufigkeit, mit der eine Anwendung (eine Verbindung) das Zeitlimit für Sperren überschreitet, ermitteln oder erkennen, daß eine Datenbank eine Zeitlimitüberschreitung für alle verbundenen Anwendungen festgestellt hat. Weitere Informationen finden Sie in der Beschreibung des Monitorelements locks_timeouts (Anzahl der Zeitlimitüberschreitungen für Sperren) im HandbuchSystem Monitor Guide and Reference.
Hohe Werte für das Monitorelement lock_timeout können folgende Ursachen haben:
Weitere Informationen zur Verwendung dieses Parameters finden Sie in Warten auf Sperren und Zeitlimits.
Die folgenden Parameter beeinflussen den Ein-/Ausgabeaufwand und den Speicherbedarf, die mit dem Betrieb der Datenbank verbunden sind:
Asynchrone Seitenlöschfunktionen schreiben geänderte Seiten aus dem Pufferpool (oder den Pufferpools) auf Platte, bevor der Bereich im Pufferpool von einem Datenbankagenten angefordert wird. Das heißt, daß die Agenten nicht mehr darauf warten, daß eine geänderte Seite auf Platte geschrieben wird, bevor sie eine Seite lesen können. Dadurch erhöht sich die Verarbeitungsgeschwindigkeit für die Transaktionen Ihrer Anwendungen.
Mit diesem Parameter können Sie den Prozentsatz der geänderten Seiten angeben, bei dem die asynchronen Seitenlöschfunktionen gestartet werden, wenn sie zum gegebenen Zeitpunkt nicht aktiv sind. Wenn die Seitenlöschfunktionen gestartet werden, erstellen sie eine Liste der Seiten, die auf Platte zu schreiben sind. Wenn das Schreiben dieser Seiten auf Platte abgeschlossen ist, werden die Seitenlöschfunktionen wieder inaktiv und warten auf den nächsten Startauslöser.
In einer Umgebung mit reinem Lesezugriff (in der z. B. nur Abfragen ausgeführt werden) werden diese Seitenlöschfunktionen nicht verwendet.
Empfehlung: Bei Datenbanken mit hohem Aufkommen an aktualisierenden Transaktionen können Sie allgemein sicherstellen, daß genügend freie Seiten im Pufferpool verfügbar sind, indem Sie diesen Parameter auf einen Wert setzen, der gleich groß wie oder kleiner als der Standardwert ist. Ein Prozentsatz über dem Standardwert kann sich positiv auf die Leistung auswirken, wenn in Ihrer Datenbank eine kleine Anzahl sehr großer Tabellen gespeichert ist.
Mit diesem Parameter können Sie die Anzahl asynchroner Seitenlöschfunktionen für eine Datenbank angeben. Diese Seitenlöschfunktionen schreiben geänderte Seiten aus dem Pufferpool auf Platte, bevor der Bereich im Pufferpool von einem Datenbankagenten angefordert wird. Das heißt, daß die Agenten nicht mehr darauf warten, daß geänderte Seiten auf Platte geschrieben werden, bevor sie eine Seite lesen können. Dadurch sollte sich die Verarbeitungsgeschwindigkeit für die Transaktionen Ihrer Anwendung erhöhen.
Wenn der Parameter auf den Wert 0 gesetzt wird, werden keine Seitenlöschfunktionen gestartet, und infolgedessen schreiben die Agenten alle geänderten Seiten aus dem Pufferpool auf Platte. Dieser Parameter kann erhebliche Auswirkungen auf die Leistung einer Datenbank haben, die auf mehrere physische Speichereinheiten verteilt ist, weil in diesem Fall die Wahrscheinlichkeit größer ist, daß auf einer dieser Einheiten momentan keine Operationen ausgeführt werden. Wenn keine Seitenlöschfunktionen konfiguriert sind, können Ihre Anwendungen in regelmäßigen Abständen auf volle Protokolle stoßen.
Wenn die Anwendungen für eine Datenbank im wesentlichen aus Transaktionen bestehen, mit denen die Daten aktualisiert werden, führt eine Erhöhung der Anzahl der Seitenlöschfunktionen zu einer Leistungsverbesserung. Durch die Erhöhung der Anzahl der Seitenlöschfunktionen wird außerdem die Zeit für Wiederherstellungen nach Systemausfällen, zum Beispiel aufgrund von Netzausfall, verringert, weil der Inhalt der Datenbank auf der Platte zu einem gegebenen Zeitpunkt aktueller ist.
Empfehlung: Bei der Einstellung dieses Parameters müssen folgende Faktoren beachtet werden:
Umgebungen mit hohem Aufkommen an aktualisierenden Transaktionen machen eventuell die Konfiguration weiterer Seitenlöschfunktionen erforderlich.
Umgebungen mit großen Pufferpools machen eventuell auch die Konfiguration weiterer Seitenlöschfunktionen erforderlich.
Mit Hilfe des Datenbanksystemmonitors können Sie diesen Konfigurationsparameter optimieren, indem Sie die Informationen des Ereignismonitors zu Schreibaktivitäten aus einem Pufferpool heranziehen:
Weitere Informationen finden Sie in den Beschreibungen zu folgenden Monitorelementen im Handbuch System Monitor Guide and Reference:
1 [ 1 - 255 ] auf dem Satellitendatenbank-Server mit lokalen Clients
E/A-Server werden für Datenbankagenten verwendet, um Vorablese-E/A-Operationen und asynchrone E/A-Operationen von Dienstprogrammen wie BACKUP (Sicherung) und RESTORE (Wiederherstellung) auszuführen. Mit diesem Parameter wird die Anzahl der E/A-Server für eine Datenbank definiert. Zu jedem beliebigen Zeitpunkt kann nur diese Anzahl von E/A-Servern zum Vorablesen und für Dienstprogramme für eine Datenbank aktiv sein. Ein E/A-Server wartet, während eine vom ihm eingeleitete E/A-Operation ausgeführt wird. Nicht vorabgelesene Ein-/Ausgaben werden direkt von den Datenbankagenten terminiert, so daß diese Ein-/Ausgaben nicht der Begrenzung durch den Parameter num_ioservers unterliegen.
Empfehlung: Um alle E/A-Einheiten des Systems voll auszunutzen, empfiehlt sich im allgemeinen ein Wert, der um 1 oder 2 höher ist als die Anzahl der physischen Einheiten, auf denen sich die Datenbank befindet. Es ist besser, zusätzliche E/A-Server zu konfigurieren, da mit jedem E/A-Server nur geringfügiger Systemaufwand verbunden ist und alle nicht benötigten E/A-Server inaktiv bleiben.
Weitere Informationen finden Sie in Vorablesen von Daten in den Pufferpool und Konfigurieren von E/A-Servern für Vorablesezugriff und parallele E/A.
Mit diesem Parameter wird angegeben, ob bei der Indexerstellung eine Sortierung der Indexschlüssel stattfindet. Die Leistung der Indexerstellung wird verbessert, wenn die Sortierung zuerst stattfindet, besonders bei Indizes mit niedrigen Clusterverhältnissen oder Clusterfaktoren. Auch die Leistung von Abfragen kann verbessert werden, wenn Indizes bei der Erstellung sortiert werden. Durch diese Leistungsverbesserung kommt es jedoch zu einem erhöhten Bedarf an Plattenspeicherplatz für die Sortierung, die das Doppelte des Speicherbereichs einer Indexerstellung ohne Anfangssortierung erforderlich machen könnte.
Empfehlung: Verwenden Sie die Standardeinstellung ("Yes"), sofern Sie über genügend Plattenspeicherplatz verfügen. Beachten Sie, daß der für die Sortierung erforderliche Plattenspeicherplatz ungefähr so groß ist wie der Platz, der für eine SELECT-Anweisung mit einer Klausel ORDER BY auf die indizierten Spalten benötigt wird, mit der die Spalten des Index aus der Tabelle ausgewählt werden.
Wenn Sie in einer symmetrischen Mehrprozessorumgebung (SMP-Umgebung) diesen Parameter auf den Wert "No" setzen, wird der Mehrprozessor, der in einer SMP-Umgebung eingesetzt werden kann, während der Indexerstellung nicht verwendet.
Der Datenbankmanager kann die E/A-Operationen überwachen und, wenn Seiten sequentiell gelesen werden, das E/A-Vorablesen (I/O Prefetching) aktivieren. Diese Art des sequentiellen Vorablesens ist die Sequenzerkennung. Mit dem Konfigurationsparameter seqdetect können Sie steuern, ob der Datenbankmanager die Sequenzerkennung ausführen soll.
Wenn für diesen Parameter der Wert "No" angegeben wird, findet das Vorablesen nur dann statt, wenn der Datenbankmanager erkennt, daß es nützlich ist, z. B. bei Tabellensortierungen, Tabellensuchen oder einem Vorablesezugriff über Listen.
Empfehlung: In den meisten Fällen sollte der Standardwert für diesen Parameter verwendet werden. Inaktivieren Sie die Sequenzerkennung nur dann, wenn andere Optimierungsversuche bisher nicht zur Behebung schwerwiegender Leistungsprobleme bei Abfragen geführt haben.
Bei der Erstellung eines Tabellenbereichs kann wahlfrei PREFETCHSIZE n angegeben werden, wobei n die Anzahl der Seiten ist, die der Datenbankmanager liest, wenn ein Vorablesezugriff erfolgt. Wird PREFETCHSIZE in der Anweisung CREATE TABLESPACE nicht angegeben, verwendet der Datenbankmanager den Wert, der durch diesen Parameter definiert wird.
Weitere Informationen finden Sie in Vorablesen von Daten in den Pufferpool.
Empfehlung: Mit Tools zur Systemüberwachung können Sie feststellen, ob Ihre CPU ausgelastet ist, während das System auf Ein-/Ausgaben wartet. Die Erhöhung dieses Parameterwerts kann nützlich sein, wenn für die Tabellenbereiche, die verwendet werden, kein Wert für PREFETCHSIZE definiert ist.
Dieser Parameter enthält den Standardwert für die gesamte Datenbank und ist eventuell nicht für alle Tabellenbereiche innerhalb der Datenbank geeignet. Beispielsweise kann der Wert 32 für einen Tabellenbereich mit dem Wert 32 Seiten für EXTENTSIZE geeignet sein, aber nicht für einen Tabellenbereich mit dem Wert 25 Seiten für EXTENTSIZE. Im Idealfall sollten Sie den Wert für PREFETCHSIZE für jeden Tabellenbereich explizit angegeben.
Sie sollten als Wert für diesen Parameter einen Faktor oder ein ganzzahliges Vielfaches des Wertes des Parameters dft_extent_sz angeben, um die E/A-Operationen für Tabellenbereiche zu minimieren, die mit dem Standardwert für EXTENTSIZE (Parameter dft_extent_sz) definiert sind. Wenn z. B. für den Parameter dft_extent_sz der Wert 32 angegeben ist, könnten Sie den Wert von dft_prefetch_sz auf 16 (einen Faktor von 32) oder auf 64 (ein ganzzahliges Vielfaches von 32) setzen. Wenn für PREFETCHSIZE ein Vielfaches des Werts für EXTENTSIZE angegeben ist, kann der Datenbankmanager parallele E/A-Operationen ausführen, wenn die folgenden Bedingungen erfüllt sind:
Dieser Parameter, der sich ausschließlich auf SMS-Tabellenbereiche bezieht, gibt die Anzahl der Behälter an, die innerhalb der Standardtabellenbereiche erstellt werden. Dieser Parameter zeigt den Wert an, der bei der Erstellung der Datenbank verwendet wurde, unabhängig davon, ob er in dem Befehl CREATE DATABASE explizit oder implizit angegeben wurde. Von der Anweisung CREATE TABLESPACE wird dieser Parameter nicht verwendet.
Weitere Informationen finden Sie im Abschnitt zu physischen Datenbankverzeichnissen im Handbuch Systemverwaltung: Konzept.
Bei der Erstellung eines Tabellenbereichs kann wahlfrei EXTENTSIZE n angegeben werden, wobei n die Speicherbereichsgröße ist. Wenn Sie EXTENTSIZE n in der Anweisung CREATE TABLESPACE nicht angeben, verwendet der Datenbankmanager den Wert, der durch diesen Parameter definiert wird.
Weitere Informationen finden Sie im Abschnitt zum Entwerfen und Auswählen von Tabellenbereichen im Handbuch Systemverwaltung: Konzept.
Empfehlung: In vielen Fällen geben Sie die Speicherbereichsgröße bei der Erstellung eines Tabellenbereichs explizit an. Bevor Sie einen Wert für diesen Parameter wählen, sollten Sie verstehen, wie die Speicherbereichsgröße in der Anweisung CREATE TABLESPACE explizit gewählt wird. Weitere Informationen finden Sie in Auswirkung des Tabellenbereichs auf die Abfrageoptimierung.
Dieser Parameter gibt die Anzahl der Seiten in jedem Segment des erweiterten Speichers in der Datenbank an. Beim Einstellen dieses Konfigurationsparameters sind plattformspezifische Überlegungen zu berücksichtigen.
Empfehlung: Dieser Parameter ist nur wirksam, wenn erweiterter Speicher verfügbar ist, und er wird wie für den Parameter num_estore_segs dargestellt verwendet. Beim Angeben der in jedem Segment des erweiterten Speichers zu verwendenden Anzahl von Seiten sollten Sie auch die Segmentanzahl im erweiterten Speicher berücksichtigen, indem Sie den Parameter num_estore_segs überprüfen und ggf. ändern. Weitere Informationen zum erweiterten Speicher finden Sie in Erweitern von Speicher.
Dieser Parameter gibt die Anzahl der Segmente im erweiterten Speicher an, die von der Datenbank verwendet werden können.
Die Standardeinstellung ist 0, d. h. für die Datenbank werden keine Segmente im erweiterten Speicher bereitgestellt.
Empfehlung: Verwenden Sie diesen Parameter nur, um die Verwendung von Segmenten im erweiterten Speicher einzurichten, wenn der Speicherplatz Ihrer Systemumgebung den maximalen Adreßraum übersteigt und Sie diesen Speicher nutzen möchten. Beim Angeben der Segmentanzahl sollten Sie auch die Größe der einzelnen Segmente berücksichtigen, indem Sie den Parameter estore_seg_sz überprüfen und ggf. ändern.
Wenn die Konfigurationsparameter num_estore_segs und estore_seg_sz gesetzt sind, sollten Sie mit Hilfe der Anweisungen CREATE/ALTER BUFFERPOOL angeben, welche Pufferpools den erweiterten Speicher verwenden werden. Weitere Informationen zum erweiterten Speicher finden Sie in Erweitern von Speicher.
Die folgenden Parameter können die Anzahl der Anwendungen beeinflussen, die gleichzeitig ausgeführt werden können, um eine optimale Leistung zu erzielen:
Mit diesem Parameter wird die maximale Anzahl der (sowohl lokalen als auch fernen) Anwendungen angegeben, die gleichzeitig auf eine Datenbank zugreifen können. Da jede Anwendung, die die Verbindung zu einer Datenbank herstellt, die Zuordnung privaten Speichers erforderlich macht, entsteht durch Erhöhung dieses Parameters möglicherweise mehr Speicherbedarf.
Der Wert dieses Parameters muß größer oder gleich der Summe der verbundenen Anwendungen plus der Anzahl solcher Anwendungen sein, die gleichzeitig im Begriff sind, eine zweiphasige Festschreibung oder ROLLBACK-Operation zu beenden. Addieren Sie zu dieser Summe die Anzahl unbestätigter Transaktionen, die zu einem gegebenen Zeitpunkt vorhanden sein können. Weitere Informationen zu unbestätigten Transaktionen finden Sie im Abschnitt zum Wiederherstellen bei Problemen während zweiphasiger Festschreibung im Handbuch Systemverwaltung: Konzept.
Wenn eine Anwendung versucht, die Verbindung zu einer Datenbank herzustellen, jedoch der Wert des Parameters maxappls bereits erreicht wurde, wird an die Anwendung ein Fehler zurückgegeben, daß die maximale Anzahl von Anwendungen bereits mit der Datenbank verbunden ist.
Da mehrere Anwendungen Data Links Manager verwenden, muß der Wert für maxappls erhöht werden. Berechnen Sie den erforderlichen Wert anhand folgender Formel:
<maxappls> = 5 * (Anzahl Knoten) + (Höchstanzahl aktiver Anwendungen, die Data Links Manager verwenden)
Der unterstützte Maximalwert für Data Links Manager ist 2 000.
In einer partitionierten Datenbankumgebung ist dies die maximale Anzahl von Anwendungen, die gleichzeitig auf einer Datenbankpartition aktiv sein kann. Dieser Parameter beschränkt die Anzahl aktiver Anwendungen für eine Datenbankpartition auf einem Datenbankpartitions-Server unabhängig davon, ob der Server der Koordinatorknoten für die Anwendung ist oder nicht. Für den Katalogknoten in einer partitionierten Datenbankumgebung ist ein höherer Wert für maxappls erforderlich als für andere Umgebungsarten, weil in der partitionierten Datenbankumgebung jede Anwendung eine Verbindung zum Katalogknoten benötigt.
Empfehlung: Wenn der Wert dieses Parameters erhöht wird, ohne daß der Wert des Parameters maxlocks verringert oder der Wert des Parameters locklist erhöht wird, könnte die maximale Anzahl Sperren (Parameter locklist) eher erreicht werden als die maximale Anzahl der Anwendungen, was zu allgemeinen Problemen durch Sperreneskalation führen kann.
Bis zu einem gewissen Grad wird die maximale Anzahl von Anwendungen auch vom Paramater maxagents bestimmt. Eine Anwendung kann nur dann eine Verbindung zur Datenbank herstellen, wenn eine freie Verbindung (maxappls) sowie ein freier Agent (maxagents) verfügbar ist. Darüber hinaus wird die maximale Anzahl von Anwendungen auch vom Konfigurationsparameter max_coordagents gesteuert, weil keine neuen Anwendungen (d. h. Koordinationsagenten) gestartet werden können, wenn der Wert von max_coordagents erreicht ist.
Mit Hilfe dieses Parameters versucht das SQL-Optimierungsprogramm zu ermitteln, wieviel Pufferpool zur Laufzeit für den ausgewählten Zugriffsplan verfügbar ist. Durch Erhöhen des Werts für diesen Parameter kann das Optimierungsprogramm veranlaßt werden, einen Zugriffsplan für Abfragen zu wählen, der mit der Belegung des Pufferpools etwas sparsamer umgeht.
Empfehlung: Wenn DB2 in einer Mehrplatzsystemumgebung ausgeführt wird, ist es vorteilhaft, wenn das SQL-Optimierungsprogramm weiß, daß mehrere Abfragebenutzer das System verwenden (besonders bei komplexen Abfragen und einem großen Pufferpool), so daß das Optimierungsprogramm in seinen Annahmen zur Verfügbarkeit von Pufferpool weniger großzügig ist.
Bei der Einstellung dieses Parameters sollten Sie die Anzahl der Anwendungen mit komplexen Abfragen berechnen, die die Datenbank durchschnittlich verwenden. Aus dieser Berechnung sollten alle einfachen OLTP-Anwendungen (Online-Transaktionsprogramme) ausgeklammert werden. Wenn Sie bei der Bestimmung dieser Anzahl Probleme haben, multiplizieren Sie folgende Werte miteinander:
Wie bei der Anpassung anderer Konfigurationsparameter, die das Optimierungsprogramm beeinflussen, sollten Sie auch den Wert dieses Parameters in kleinen Schritten ändern. Dadurch können Sie die Differenzen bei der Pfadauswahl minimieren.
Wenn Sie diesen Parameter geändert haben, sollten Sie Anwendungen eventuell erneut binden (mit dem Befehl REBIND PACKAGE).
Mit diesem Parameter wird die maximale Anzahl der Dateikennungen angegeben, die für jeden einzelnen Datenbankagenten geöffnet sein können. Wenn durch das Öffnen einer Datei dieser Wert überschritten wird, werden einige von diesem Agenten verwendete Dateien geschlossen. Wenn der Wert für den Parameter maxfilop zu klein ist, kann der Systemaufwand für das Öffnen und Schließen von Dateien, um diesen Grenzwert nicht zu überschreiten, übermäßig anwachsen und die Leistung beeinträchtigen.
Sowohl SMS-Tabellenbereiche als auch DMS-Tabellenbereichsdateicontainer werden bei der Interaktion des Datenbankmanagers mit dem Betriebssystem als Dateien behandelt, so daß Dateikennungen für sie erforderlich sind. In der Regel werden von SMS-Tabellenbereichen vergleichsweise mehr Dateien verwendet, als von DMS-Dateitabellenbereichen Behälter verwendet werden. Daher wird für diesen Parameter ein höherer Wert benötigt, wenn SMS-Tabellenbereiche verwendet werden, als für DMS-Dateitabellenbereiche erforderlich wäre.
Mit Hilfe dieses Parameters kann außerdem sichergestellt werden, daß die Gesamtzahl der Dateikennungen, die vom Datenbankmanager verwendet werden, den Grenzwert des Betriebssystems nicht überschreitet, indem die Anzahl der Dateikennungen pro Agent auf einen bestimmten Wert gesetzt wird. Die tatsächliche Anzahl ist je nach Anzahl der gleichzeitig aktiven Agenten unterschiedlich.
Mit diesem Parameter wird die maximale Anzahl von Dateien definiert, die von allen Agenten und anderen Threads, die in einem Datenbankmanagerexemplar ausgeführt werden, geöffnet werden können. Wenn durch das Öffnen einer Datei der Wert dieses Parameters überschritten wird, wird ein Fehler an die Anwendung zurückgegeben.
Anmerkung: | Dieser Parameter gilt nicht für auf UNIX basierende Plattformen. |
Empfehlung: Bei der Einstellung dieses Parameters sollte die Anzahl der Dateikennungen beachtet werden, die für jede Datenbank in dem Datenbankmanagerexemplar verwendet werden könnten. Ermitteln Sie auf folgende Weise einen oberen Grenzwert für diesen Parameter:
maxappls * maxfilop
Wenn eine neue Datenbank erstellt wird, sollten Sie den Wert für diesen Parameter neu bestimmen.
Außerdem sollten Sie mit Hilfe der folgenden Formel sicherstellen, daß die Gesamtanzahl der Dateikennungen, die auf Ihrem System verwendet werden kann, den Maximalwert für das System nicht überschreitet:
(Summe der maxtotfilop für alle Exemplare auf dem System) + (kalkulierte Anzahl Dateikennungen, die von anderen Anwendungen benötigt werden) <= 65535
Mit diesem Parameter wird die Priorität gesteuert, die sowohl allen Agenten als auch anderen Prozessen und Threads des Datenbankmanagerexemplars vom Scheduler des Betriebssystems zugewiesen wird. In einer partitionierten Datenbankumgebung gehören dazu auch koordinierende und parallele Agenten, parallele Systemsteuerprogramme und die FCM-Dämonen. Durch diese Priorität wird festgelegt, wie den DB2-Prozessen, -Agenten und -Threads im Vergleich zu den anderen Prozessen und Threads, die auf dem System ausgeführt werden, CPU-Zeit zugewiesen wird. Wenn der Parameter auf den Wert -1 gesetzt ist, wird keine besondere Aktion ausgeführt, und der Datenbankmanager erhält seine CPU-Zeit in der normalen Weise, in der das Betriebssystem allen Prozessen und Threads Prozessorzeit zuweist. Wenn der Parameter auf einen anderen Wert als -1 gesetzt wird, erstellt der Datenbankmanager seine Prozesse und Threads mit einer statischen Priorität, die dem Wert des Parameters entspricht. Dadurch können Sie mit diesem Parameter die Priorität steuern, mit der die Prozesse und Threads des Datenbankmanagers auf Ihrem System ausgeführt werden.
Mit diesem Parameter kann der Durchsatz des Datenbankmanagers erhöht werden. Die Werte für diesen Parameters sind von dem Betriebssystem abhängig, auf dem der Datenbankmanager ausgeführt wird. Beispielsweise ergeben in einer auf UNIX basierenden Umgebung niedrige numerische Werte hohe Prioritäten. Wenn der Parameter auf einen Wert zwischen 41 und 125 gesetzt wird, erstellt der Datenbankmanager seine Agenten mit einer statischen UNIX-Priorität, die dem Wert dieses Parameters entspricht. Dies ist in auf UNIX basierenden Umgebungen von Bedeutung, weil numerisch niedrige Werte hohe Prioritäten für den Datenbankmanager ergeben. Bei anderen Prozessen (einschließlich Anwendungen und Benutzern) können jedoch Verzögerungen auftreten, da sie nicht genügend CPU-Zeit erhalten. Sie sollten den Wert für diesen Parameter mit den anderen Aktivitäten, die Sie auf der Maschine erwarten, abstimmen.
In einer OS/2-Umgebung ergeben höhere numerische Werte höhere Prioritäten.
Empfehlung: Zu Anfang sollte der Standardwert verwendet werden. Dieser Wert stellt einen guten Kompromiß zwischen den Antwortzeiten für andere Benutzer bzw. Anwendungen und dem Durchsatz des Datenbankmanagers dar.
Wenn die Datenbankleistung von Bedeutung ist, können Sie durch Vergleichstests (Benchmark-Tests) die optimale Einstellung für diesen Parameter bestimmen. Eine Erhöhung der Priorität des Datenbankmanagers sollte nur mit großer Vorsicht vorgenommen werden, da die Leistung anderer Benutzerprozesse erheblich beeinträchtigt werden kann, besonders dann, wenn die CPU-Auslastung sehr hoch ist. Durch Erhöhen der Priorität der Datenbankmanagerprozesse und -Threads können bedeutende Leistungssteigerungen erzielt werden.
Anmerkung: | Wenn Sie auf UNIX-Plattformen für diesen Parameter einen anderen als den Standardwert verwenden, können Sie Governor nicht verwenden, um Agentenprioritäten zu ändern. |
400 [1 - 64 000] auf einem partitionierten Datenbank-Server mit lokalen und fernen Clients
10 [ 1 - 64 000 ] auf dem Satellitendatenbank-Server mit lokalen Clients
Mit diesem Parameter wird die maximale Anzahl von Datenbankmanageragenten (koordinierende Agenten und Subagenten) angegeben, die zu einem gegebenen Zeitpunkt zur Verfügung stehen, um Anwendungsanforderungen zu empfangen. Wenn Sie die Anzahl koordinierender Agenten begrenzen möchten, verwenden Sie den Parameter max_coordagents.
Dieser Parameter kann in Umgebungen mit eingeschränkten Speicherkapazitäten nützlich sein, um den Gesamtspeicherbedarf des Datenbankmanagers zu begrenzen, da jeder zusätzliche Agent zusätzlichen Speicher benötigt.
Empfehlung: Der Wert des Parameters maxagents sollte mindestens der Summe der Werte für maxappls aller Datenbanken, auf die gleichzeitig zugegriffen werden kann, entsprechen. Wenn die Anzahl der Datenbanken größer als der Wert des Parameters numdb ist, dann besteht die sicherste Methode zur Angabe dieses Werts darin, das Produkt von numdb und dem größten Wert für maxappls zu bilden.
Für die Initialisierung und Verwaltung jedes weiteren Agenten ist zusätzlicher Speicher erforderlich, der beim Starten des Datenbankmanagers zugeordnet wird.
Mit diesem Parameter wird die maximale Anzahl koordinierender Datenbankmanageragenten festgelegt, die gleichzeitig eine Datenbankmanagertransaktion ausführen können. Dieser Parameter wird zur Steuerung der Systembelastung in Phasen hoher gleichzeitiger Anwendungsaktivität verwendet. Sie können beispielsweise ein System haben, das eine große Anzahl von Verbindungen anfordert, jedoch nur über eine begrenzte Speicherkapazität zur Verarbeitung dieser Verbindungen verfügt. In diesem Fall kann die Anpassung dieses Parameters sehr nützlich sein, da es hier aufgrund hoher gleichzeitiger Aktivität zu übermäßigem Seitenwechseln durch das Betriebssystem kommen kann.
Dieser Parameter schränkt nicht die Anzahl der Anwendungen ein, die mit einer Datenbank verbunden sein können. Er begrenzt nur die Anzahl der Datenbankmanageragenten, die gleichzeitig vom Datenbankmanager verarbeitet werden können, wodurch der Bedarf an Systemressourcen in Phasen sehr starker Belastung eingeschränkt wird.
Ein Wert von -1 gibt an, daß der Grenzwert gleich dem Wert des über den Parameter max_coordagents festgelegten Grenzwerts ist.
Empfehlung: In den meisten Fällen kann der Standardwert für diesen Parameter übernommen werden. In Fällen, wo es durch hohe Simultanverarbeitung von Anwendungen zu Problemen kommt, können Sie durch Vergleichstests (Benchmark-Tests) die optimale Einstellung für diesen Parameter ermitteln.
[-1, 0-maxagents]
In partitionierten Datenbankumgebungen und Umgebungen, in denen intra_parallel auf "Yes" gesetzt ist, ist der Standardwert maxagents - num_initagents; andernfalls ist der Standardwert maxagents. Dadurch wird sichergestellt, daß in nicht partitionierten Datenbankumgebungen max_coordagents immer gleich maxagents ist, außer wenn das System für partitionsinterne Parallelität konfiguriert ist.
Wenn Sie nicht mit einer partitionierten Datenbankumgebung arbeiten und den Parameter intra_parallel nicht aktiviert haben, muß max_coordagents gleich maxagents sein.
Dieser Parameter legt die maximale Anzahl koordinierender Agenten fest, die in einer partitionierten oder nicht partitionierten Datenbankumgebung gleichzeitig auf einem Server vorhanden sein können.
Für jede lokale oder ferne Anwendung, die eine Verbindung zu einer Datenbank oder einem Exemplar herstellt, wird ein koordinierender Agent aufgerufen. Anforderungen, für die eine Exemplarverbindung erforderlich ist, sind z. B. CREATE DATABASE, DROP DATABASE und Befehle des Datenbanksystemmonitors.
Dieser Parameter steuert die maximale Anzahl der Anwendungen, die mit dem Exemplar verbunden sein können. In der Regel wird jede Anwendung einem Koordinationsagenten zugeordnet. Ein Agent erleichtert die Operationen zwischen der Anwendung und der Datenbank. Die Konzentratorfunktion wird nicht aktiviert, wenn der Standardwert für diesen Parameter verwendet wird. Daher arbeitet jeder Agent mit seinem eigenen privaten Speicher und benutzt Ressourcen des Datenbankmanagers und globale Datenbankressourcen, wie z. B. den Pufferpool, gemeinsam mit anderen Agenten. Die Konzentratorfunktion wird hingegen aktiviert, wenn der Parameter auf einen Wert gesetzt wird, der den Standardwert übersteigt. Es ist die Aufgabe des Konzentrators, die Anzahl der Server-Ressourcen pro Client-Anwendung so weit zu verringern, daß ein DB2 Connect-Gateway mehr als 10 000 Client-Verbindungen verarbeiten kann.
Ein Wert von -1 gibt an, daß der Grenzwert gleich dem Wert des über den Parameter max_coordagents festgelegten Grenzwerts ist.
Der Wert für einen Server mit einer nicht partitionierten Datenbank und lokalen Clients ist bei Verwendung des Standardwerts der größere der beiden Werte maxagents/50 und max_querydegree.
Der Wert für einen Server mit einer nicht partitionierten Datenbank und lokalen und fernen Clients ist bei Verwendung des Standardwerts der größere der beiden folgenden Werte: maxagents/50 x max_querydegree oder maxagents - max_coordagents.
Der Wert für einen Datenbankpartitions-Server ist bei Verwendung des Standardwerts der größere der beiden folgenden Werte: maxagents/10 x max_querydegree oder maxagents - max_coordagents.
Dieser Parameter stellt eine Richtlinie für die maximale Größe des Agentenpools dar (er ersetzt den Parameter max_idleagents, der in DB2 Version 2 verwendet wurde).
Der Agentenpool enthält Subagenten und freie Agenten. Freie Agenten können als parallele Subagenten oder als koordinierende Agenten verwendet werden. Wurden mehr Agenten erstellt, als der Wert dieses Parameters angibt, werden diese nach Ausführung ihrer aktuellen Anforderung nicht in den Pool zurückgestellt sondern beendet.
Ist der Wert für diesen Parameter 0, werden nach Bedarf Agenten erstellt und möglicherweise beendet, sobald sie ihre aktuelle Anforderung ausgeführt haben. Ist der Wert maxagents und ist der Pool gefüllt mit zugeordneten Subagenten, kann der Server nicht als Koordinatorknoten verwendet werden, weil keine neuen koordinierenden Agenten erstellt werden können.
Empfehlung: Wenn Sie eine Entscheidungshilfeumgebung verwenden, in der nur wenige Anwendungen gleichzeitig mit der Datenbank verbunden sind, setzen Sie num_poolagents auf einen kleinen Wert, um zu verhindern, daß ein Agentenpool mit freien Agenten angefüllt wird.
Wenn Sie eine Transaktionsverarbeitungsumgebung verwenden, in der viele Anwendungen gleichzeitig mit der Datenbank verbunden sind, erhöhen Sie den Wert für num_poolagents, um den Aufwand für die häufige Erstellung und Beendigung von Agenten zu vermeiden.
Dieser Parameter gibt an, wie viele freie Agenten beim Ausführen von DB2START im Agentenpool erstellt werden.
Die folgenden Parameter können die DARI-Anwendungen beeinflussen:
Anmerkung: | Der Begriff DARI bezieht sich auf gespeicherte Prozeduren. |
Mit diesem Parameter wird angegeben, ob ein DARI-Prozeß nach Abschluß eines DARI-Aufrufs beibehalten wird oder nicht. DARI-Prozesse werden als getrennte Definitionseinheiten des Systems erstellt, um vom Benutzer geschriebenen DARI-Code vom Agentenprozeß des Datenbankmanagers zu isolieren. Dieser Parameter gilt nur für Datenbank-Server.
Wenn der Parameter keepdari auf no gesetzt ist, wird für jeden DARI-Aufruf ein neuer DARI-Prozeß erstellt und wieder gelöscht. Wenn der Parameter keepdari auf yes gesetzt ist, wird ein DARI-Prozeß für nachfolgende DARI-Aufrufe wieder verwendet. Wird der Datenbankmanager gestoppt, werden alle noch nicht beendeten DARI-Prozesse beendet.
Wenn dieser Parameter auf yes gesetzt wird, werden vom Datenbankmanager zusätzliche Systemressourcen für jeden DARI-Prozeß in Anspruch genommen, der aktiviert wird, solange die durch den Parameter maxdari definierte Anzahl noch nicht erreicht ist. Dies gilt nur, wenn kein bereits aktiver DARI-Prozeß zur Verarbeitung eines nachfolgenden DARI-Aufrufs verfügbar ist. Dieser Parameter wird ignoriert, wenn der Parameter maxdari den Wert 0 hat.
Empfehlung: In einer Umgebung, in der die Anzahl der DARI-Anforderungen im Vergleich zu den übrigen Anforderungen groß ist und Systemressourcen nicht begrenzt sind, kann dieser Parameter auf yes gesetzt werden. Dadurch wird die DARI-Leistung erhöht, weil der zusätzliche Systemaufwand zur Ersterstellung eines DARI-Prozesses vermieden wird, da ein bereits vorhandener DARI-Prozeß zur Verarbeitung des Aufrufs verwendet wird.
Zum Beispiel könnte bei einer OLTP-Bankanwendung (OLTP - Online-Transaktionsprogramm) für Soll- und Haben-Transaktionen der Code, mit dem jede Transaktion erfaßt wird, in einer gespeicherten Prozedur ausgeführt werden, die in einem DARI-Prozeß arbeitet. In dieser Anwendung wird die Hauptarbeit aus DARI-Prozessen heraus geleistet. Wenn dieser Parameter auf no gesetzt wird, entsteht für jede Transaktion der Systemaufwand zur Erstellung eines neuen DARI-Prozesses, wodurch die Leistung erheblich beeinträchtigt wird. Wenn dieser Parameter jedoch auf yes gesetzt wird, versucht jede Transaktion, einen vorhandenen DARI-Prozeß zu verwenden, wodurch der zusätzliche Systemaufwand vermieden wird.
Mit diesem Parameter wird die maximale Anzahl von DARI-Prozessen angegeben, die auf dem Datenbank-Server aktiv sein können. Wenn dieser Grenzwert erreicht wird, können keine neuen DARI-Anforderungen mehr aufgerufen werden. Dieser Parameter gilt nur für Datenbank-Server.
Da für einen koordinierenden Agenten nicht mehr als ein DARI-Prozeß aktiv sein kann, wird die maximale Anzahl von DARI-Prozessen auch von der maximalen Anzahl koordinierender Agenten (max_coordagents) beschränkt.
Empfehlung: Wenn die Umgebung die Verwendung der DARI-Funktion innerhalb des Datenbankmanagers ermöglicht, dann kann mit Hilfe dieses Parameters sichergestellt werden, daß eine geeignete Anzahl von DARI-Prozessen zur Verarbeitung von DARI-Aufrufen, die innerhalb des Datenbankmanagers gleichzeitig erfolgen, verfügbar ist.
Wenn der Wert dieses Parameters auf -1 gesetzt wird, ist die maximale Anzahl von DARI-Prozessen gleich dem für den Parameter max_coordagents definierten Wert.
Wenn sich herausstellt, daß der Standardwert für Ihre Umgebung nicht geeignet ist, weil eine unangemessen große Menge Systemressourcen für DARI-Prozesse verwendet wird und es deshalb zu Leistungseinbußen des Datenbankmanagers kommt, kann anhand der folgenden Informationen eine erste Optimierung für die Einstellung dieses Parameters vorgenommen werden:
maxdari = Anzahl Anwendungen, die gleichzeitig DARI-Aufrufe absetzen dürfen
Wenn der Parameter keepdari auf den Wert yes gesetzt ist, bleibt jeder erstellte DARI-Prozeß bestehen und verbraucht auch dann noch Systemressourcen, wenn die Verarbeitung des DARI-Aufrufs beendet und die Steuerung an den Agenten zurückgegeben wurde.
Wenn in Ihrer Umgebung Systemressourcen so eingeschränkt sind, daß die Verarbeitungsressourcen für DARI nicht zur Verfügung stehen, können Sie DARI dadurch inaktivieren, daß Sie diesen Parameter auf den Wert 0 setzen.
Dieser Parameter gibt an, ob jeder abgeschirmte DARI-Prozeß beim Start die Java Virtual Machine (JVM) lädt. Dieser Parameter verringert die einleitende Startzeit für abgeschirmte gespeicherte Java-Prozeduren, insbesondere wenn er zusammen mit dem Parameter num_initdaris verwendet wird. Dieser Parameter kann eventuell die einleitende Ladezeit für abgeschirmte gespeicherte Nicht-Java-Prozeduren erhöhen, weil für sie die JVM nicht erforderlich ist.
Dieser Parameter gibt die Anfangsanzahl der inaktiven abgeschirmten DARI-Prozesse an, die bei der Ausführung von DB2START im DARI-Pool erstellt werden. Wenn Sie diesen Parameter entsprechend einstellen, wird die einleitende Startzeit für abgeschirmte gespeicherte Prozeduren verringert. Dieser Parameter wird ignoriert, wenn keepdari nicht angegeben wird.