Ein Governor-Exemplar besteht aus einem Front-End-Dienstprogramm und mindestens einem Dämon. |Jedes Governor-Exemplar, das Sie starten, ist genau einem Exemplar des Datenbankmanagers zugeordnet. Wenn Sie den Governor starten, wird auf jeder Partition einer partitionierten Datenbank standardmäßig ein Governor-Dämon gestartet. Sie können jedoch angeben, dass auf einer einzelnen zu überwachenden Partition ein Dämon gestartet werden soll.
| |Jeder Governor-Dämon sammelt Daten zu den Anwendungen, die für die Datenbank ausgeführt werden. +Anschließend überprüft der Governor-Dämon diese Daten anhand von Regeln, die Sie in der Governor-Konfigurationsdatei für diese Datenbank angeben.
| | |Wenn Sie die Inplace-Tabellenreorganisation (statt der herkömmlichen Tabellenreorganisation) in Betracht ziehen, sollten Sie beachten, dass die Inplace-Tabellenreorganisation mehr Protokollspeicherbereich erfordert.
|Da die Inplace-Tabellenreorganisation ihre Aktivitäten protokolliert, um nach einem unvorhergesehenen Ausfall eine Wiederherstellung ausführen zu können, wird für diesen Reorganisationstyp mehr Protokollspeicherbereich benötigt als für die herkömmliche Reorganisation.
|Die Inplace-Tabellenreorganisation kann unter Umständen als Protokollspeicherbereich ein Vielfaches der Größe der reorganisierten Tabelle erfordern. Die Größe des erforderlichen Speicherbereichs hängt von der Anzahl der verschobenen Zeilen sowie von der Anzahl und Größe der Indizes für die Tabelle ab.
|Empfehlung: Wählen Sie die Inplace-Tabellenreorganisation für Operationen aus, die mit minimalen Wartungszeiten rund um die Uhr ausgeführt werden.
|Während einer Onlinetabellenreorganisation einer DMS-Tabelle können Sie eine Onlinesicherung für einen Tabellenbereich aufrufen, in dem sich die Tabelle befindet. Während der Abschneidephase können für die Reorganisationsoperation Wartestatus für Sperren (Lock Waits) auftreten.
|Detaillierte Informationen zur Ausführung dieser Tabellenreorganisationsmethoden finden Sie in den Beschreibungen zur Syntax von REORG TABLE.
| | |Unter AIX(R) 5L, 64 Bit, unterstützt die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM nun das Schlüsselwort FCM.
|Unter AIX 5L(TM), 64 Bit, befindet sich FCM-Speicher standardmäßig in der DBMS-Speichergruppe. Wenn jedoch die Registrierdatenbankvariable DB2_FORCE_FCM_BP aktiviert ist, befindet sich der FCM-Speicher in seiner eigenen Speichergruppe. Unter AIX 5L, 64 Bit, unterstützt die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM die Angabe der DBMS-Speichergruppe. Wenn sich FCM-Speicher in der DBMS-Speichergruppe befindet und die Unterstützung großer Seiten für diese Speichergruppe aktiviert ist, verfügt der FCM-Speicher über größere Seiten. Wenn FCM-Speicher sich in einer eigenen Speichergruppe befindet, muss dem Wert der Registrierdatenbankvariablen DB2_LARGE_PAGE_MEM das Schlüsselwort FCM hinzugefügt werden, damit große Seiten für FCM-Speicher unterstützt werden.
Ab DB2 Universal Database(TM) (UDB) Version 8.2.2 (äquivalent zu Version 8.1 FixPak 9) akzeptiert die Konfigurationsdatei, die von der Registrierdatenbankvariablen DB2_RESOURCE_POLICY angegeben wird, ein SCHEDULING_POLICY-Element. Das SCHEDULING_POLICY-Element kann einigen Plattformen zur Auswahl folgender Elemente verwendet werden:
Die Registrierdatenbankvariablen DB2PRIORITIES und DB2NTPRICLASS können einzeln zum Steuern der Planungsrichtlinie des Betriebssystems und zum Festlegen von DB2-Agentenprioritäten verwendet werden.
Durch die Angabe eines SCHEDULING_POLICY-Elements in der Konfigurationsdatei für die Ressourcenrichtlinie können Sie die Planungsrichtlinie und die zugehörigen Agentenprioritäten an einer Stelle festlegen.
Auswahl der AIX-Planungsrichtlinie SCHED_FIFO2 mit gleichzeitiger Zuordnung einer höheren Priorität für die Prozesse der DB2-Ein- und -Ausgabeprogramme für Protokolle:
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>SCHED_FIFO2</POLICY_TYPE>
<PRIORITY_VALUE>60</PRIORITY_VALUE>
<EDU_PRIORITY>
<EDU_NAME>db2loggr</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
<EDU_PRIORITY>
<EDU_NAME>db2loggw</EDU_NAME>
<PRIORITY_VALUE>56</PRIORITY_VALUE>
</EDU_PRIORITY>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>Ersatz für DB2NTPRICLASS=H unter Windows.
<RESOURCE_POLICY>
<SCHEDULING_POLICY>
<POLICY_TYPE>HIGH_PRIORITY_CLASS</POLICY_TYPE>
</SCHEDULING_POLICY>
</RESOURCE_POLICY>In FixPak 8 wurden die Systemumgebungsvariablen DB2_MAPPED_BASE und DB2DBMSADDR hinzugefügt.
Nur fortgeschrittene Benutzer sollten diese Registrierdatenbankvariablen verwenden.
Wenn diese Variable nicht gesetzt ist, versucht DB2 UDB, die gemeinsam genutzten Bibliotheken an die virtuelle Adresse 0x10000000 zu verlagern.
Die Registrierdatenbankvariable kann auch auf eine beliebige virtuelle Adresse (hexadezimal) im Bereich des 31- und 32-Bit-Adressraums gesetzt werden.
db2set DB2_MAPPED_BASE=
Die folgende Nachricht kann mehrmals in der Datei db2diag.log vorkommen, da diese Änderung für jeden logischen Knoten einmal erforderlich ist:
ADM0506I DB2 hat den Kernelparameter "mapped_base" automatisch von "0x40000000(hex) 1073741824(dec)" auf den empfohlenen Wert "0x10000000(hex) 268435456(dec)" aktualisiert.
Diese Nachricht wird nur angezeigt, wenn das Setzen der Registrierdatenbankvariablen erfolgreich war, und sie enthält die Adresse, an die die gemeinsam genutzten Bibliotheken verlagert werden.
db2set DB2DBMSADDR=
Diese Variable können Sie in Verbindung mit DB2_MAPPED_BASE oder alleine setzen, um die Adressraumbelegung von DB2 UDB-Prozessen zu optimieren. Diese Variable ändert die Position des gemeinsam genutzten Speichers für das Exemplar von der aktuellen Position bei der virtuellen Adresse 0x20000000 in den neu angegebenen Wert.
In Version 8.2 wurde die Registrierdatenbankvariable DB2TCP_CLIENT_RCVTIMEOUT hinzugefügt.
In Version 8.2 wurde die Leistungsvariable DB2_LARGE_PAGE_MEM hinzugefügt.
| Variablenname | Betriebssysteme | Werte |
|---|---|---|
| Beschreibung | ||
| DB2_LARGE_PAGE_MEM |
Nur AIX 5.x (64 Bit) Linux |
Standardwert=NULL
Geben Sie mit Hilfe eines Sterns (*) an, dass alle gültigen Speicherbereiche große Seitenspeicher verwenden sollen, oder geben Sie eine durch Kommas getrennte Liste spezifischer Speicherbereiche an, die den großen Seitenspeicher verwenden sollen. Die verfügbaren Bereiche variieren je nach dem verwendeten Betriebssystem. Unter AIX 5.x (64 Bit) können die folgenden Bereiche angegeben werden: DB, DBMS oder PRIVATE. Unter Linux kann der folgende Bereich angegeben werden: DB. |
|
Der große Seitenspeicher wird lediglich für DB2 Universal Database (UDB) für AIX 5L (64-Bit-Edition) und DB2 UDB für Linux unterstützt. Die Registrierdatenbankvariable DB2_LARGE_PAGE_MEM wird verwendet, um unter AIX 5.x oder für eine beliebige Linux-Architektur mit der entsprechenden Kernelunterstützung die Unterstützung für große Seiten zu aktivieren. Sie ersetzt die Registrierdatenbank- variable DB2_LGPAGE_BP, die lediglich zur Aktivierung des großen Seitenspeichers für den gemeinsam genutzten Datenbankspeicherbereich verwendet wird. Dieser kann jetzt durch die Angabe von DB2_LARGE_PAGE_MEM=DB aktiviert werden. In einigen Doku- mentationen wird erläutert, dass große Seiten mit der Registrierdatenbankvariablen DB2_LGPAGE_BP ermöglicht werden. Dies entspricht der Einstellung DB2_LARGE_PAGE_MEM=DB. Die Verwendung großer Seiten dient hauptsächlich zur Leistungsverbesserung hochleistungsfähiger Datenverarbeitungsanwendungen. Bei Anwendungen, die einen intensiven Speicherzugriff erfordern und große Mengen an virtuellem Speicher verwenden, kann die Verwendung großer Seiten zu einer Leistungsverbesserung führen. Um DB2 UDB für die Verwendung großer Seiten zu aktivieren, müssen Sie zunächst das Betriebssystem für die Verwendung solcher Seiten konfigurieren. Durch die Aktivierung großer privater Seiten nimmt die DB2 UDB-Speicherbelegung deutlich zu, da jeder DB2 UDB-Agent mindestens eine große Seite (16 MB) an physischem Speicher belegt. Zum Aktivieren großer Seiten für privaten Agentenspeicher auf 64-Bit-DB2 UDB für AIX (Einstellung DB2_LARGE_PAGE_MEM=PRIVATE) müssen große Seiten auf dem Betriebssystem konfiguriert sein. Außerdem müssen die folgenden Voraussetzungen gegeben sein:
Unter DB2 UDB für AIX (64 Bit) reduziert diese Variable die Größe des gemeinsamen Speichersegments, das den Datenbankspeicher unterstützt, auf den Mindestbedarf. Standardmäßig wird ein 64-GB-Segment erstellt. Weitere Informationen hierzu finden Sie unter dem Konfigurationsparameter für die Größe des gemeinsamen Datenbankspeichers. Dadurch wird vermieden, dass mehr gemeinsam genutzter Speicher im Arbeitsspeicher belassen wird als voraussichtlich verwendet wird. Die Aktivierung dieser Variablen schränkt die Möglichkeit ein, die Konfiguration für den gesamten gemeinsamen Daten- bankspeicher dynamisch zu erhöhen (z. B. Vergrößerung der Pufferpools). Unter Linux muss als zusätzliche Voraussetzung die Bibliothek libcap.so verfügbar sein. Diese Bibliothek muss installiert sein, damit diese Option funktioniert. Wenn die Option aktiviert wird und die Bibliothek nicht im System vorhanden ist, inaktiviert DB2 UDB die großen Kernelseiten und setzt die Verarbeitung wie zuvor fort. Um unter Linux zu prüfen, ob große Kernelseiten verfügbar sind, können Sie den folgenden Befehl absetzen: cat /proc/meminfo Wenn sie verfügbar sind, sollten die drei folgenden Zeilen angezeigt werden (mit anderen Werten, je nach Größe des auf Ihrer Maschine konfigurierten Speichers): HugePages_Total: 200
HugePages_Free: 200
Hugepagesize: 16384 KB
Wenn diese Zeilen nicht angezeigt werden oder HugePages_Total den Wert 0 hat, ist eine Konfiguration des Betriebssystems oder des Kernels erforderlich. |
||
Die folgende Aktualisierung gilt für das Thema "Variablen des SQL-Compilers" im Anhang A "Registrierdatenbank- und Umgebungsvariablen von DB2" des Handbuchs Systemverwaltung: Optimierung:
Wenn mindestens eine der beiden DB2-Compilervariablen DB2_MINIMIZE_LISTPREFETCH und DB2_INLIST_TO_NLJN auf ON gesetzt ist, bleibt sie selbst dann aktiv, wenn REOPT(ONCE) angegeben ist.
Im Folgenden finden Sie die Aktualisierungen der Dokumentation zu den Konfigurationsparametern:
Der Konfigurationsparameter für den Authentifizierungstyp (authentication) des Datenbankmanagers akzeptiert außerdem die folgenden Werte:
Der Server akzeptiert verschlüsselte SERVER-Authentifizierungsschemata und die Verschlüsselung von Benutzerdaten. Die Authentifizierung funktioniert genau wie für SERVER_ENCRYPT.
Die folgenden Benutzerdaten werden bei Verwendung dieses Authentifizierungstyps verschlüsselt:
Der Server akzeptiert verschlüsselte SERVER-Authentifizierungsschemata und die Verschlüsselung von Benutzerdaten. Darüber hinaus bietet dieser Authentifizierungstyp Kompatibilität mit Produkten früherer Versionen, die den Authentifizierungstyp DATA_ENCRYPT nicht unterstützen. Diese Produkte erhalten die Möglichkeit, die Verbindung mit dem Authentifizierungstyp SERVER_ENCRYPT und ohne Verschlüsselung von Benutzerdaten herzustellen. Produkte, die den neuen Authentifizierungstyp unterstützen, müssen ihn verwenden. Dieser Authentifizierungstyp ist nur in der Konfigurationsdatei des Datenbankmanagers des Servers, jedoch nicht im Befehl CATALOG DATABASE gültig.
Ab DB2 Universal Database Version 8.2 wird der Standardwert des Konfigurationsparameters Auslastungswirkung durch gedrosselte Dienstprogramme (util_impact_lim) für den Datenbankmanager von 100 in 10 geändert.
Die folgenden Konfigurationsparameter für den Datenbankmanager akzeptieren auf allen Plattformen bis zu 30 Byte lange Gruppennamen:
Die Tabelle unter der Übersicht über die Konfigurationsparameter des Datenbankmanagers (Handbuch Systemverwaltung: Optimierung) enthält falsche Datentypen zu diesen Konfigurationsparametern für den Datenbankmanager. Der richtige Wert muss in allen Fällen char(30) lauten.
Die Maximalgröße für den Datenbankkonfigurationsparameter Segmentgröße für erweiterten Speicher (estore_seg_size) auf Windows-Plattforman lautet 16.777.216.
Die richtige Obergrenze für den Datenbankkonfigurationsparameter HADR-Zeitlimitwert (hadr_timeout) lautet 4.294.967.295.
In der Dokumentation zum Datenbankkonfigurationsparameter Max. Speicher für Sperrenliste (locklist) steht, dass der Maximalwert für Windows-64-Bit- und 32-Bit-Server, die nur Server für lokale Clients sind, 60.000 beträgt. Dieser Wert ist falsch. Er muss 524.288 lauten.
Der Wertebereich für den Datenbankkonfigurationsparameter Anzahl der Datenbanksicherungen (num_db_backups) ist falsch. Der richtige Bereich ist 0 - 32.767.
Nach der Migration von Version 8.1 auf DB2 Universal Database (UDB) Version 8.2 verwendet DB2 UDB eine neue 16 KB große Datei für Datenbankkonfigurationsparameter mit dem Namen SQLDBCONF. (In Version 8.1 war die Datei für Datenbankkonfigurationsparameter nur 4 KB groß und hieß SQLDBCON.)
Ab Version 8.1 ist die Registrierdatenbankvariable DB2_HASH_JOIN standardmäßig auf ON gesetzt.
Die Hashverknüpfungsvariable DB2_HASH_JOIN sollte verwendet werden, muss jedoch optimiert werden, um die maximale Leistung zu erzielen.
Die Leistung der Hashverknüpfung ist am besten, wenn Sie Hashschleifen und Überläufe auf den Plattenspeicher vermeiden können. Zur Optimierung der Leistung von Hashverknüpfungen schätzen Sie die maximale Speichergröße ab, die für den Parameter sheapthres verfügbar ist, und optimieren anschließend den Parameter sortheap. Erhöhen Sie den Wert dieses Parameters, bis Sie möglichst viele Hashschleifen und Überläufe auf den Plattenspeicher vermeiden, jedoch nicht den durch den Parameter sheapthres definierten Grenzwert erreichen.
Weitere Informationen finden Sie im Thema "Verknüpfungsmethoden" im Handbuch Systemverwaltung: Optimierung.
Die zuvor durch die Variable DB2NTNOCACHE erreichte Funktionalität kann auf Tabellenbereichsebene erreicht werden, indem in der Anweisung CREATE TABLESPACE oder ALTER TABLESPACE die Klausel NO FILE SYSTEM CACHING angegeben wird. Weitere Informationen hierzu finden Sie im Handbuch SQL Reference. Die Registrierdatenbankvariable DB2NTNOCACHE wird in einem zukünftigen Release entfernt.
EXPLAIN-Tabellen können für mehrere Benutzer gemeinsame Daten enthalten. Die EXPLAIN-Tabellen können jedoch auch für nur einen Benutzer definiert werden. Außerdem können Aliasnamen für jeden weiteren Benutzer definiert werden, der denselben Namen verwendet, um auf die definierten Tabellen zu verweisen. Die EXPLAIN-Tabellen können auch unter dem Schema SYSTOOLS definiert werden. Die EXPLAIN-Funktion verwendet standardmäßig das Schema SYSTOOLS, wenn keine anderen EXPLAIN-Tabellen oder -Aliasnamen unter der Sitzungs-ID des Benutzers für dynamisches SQL oder unter der Berechtigungs-ID der Anweisung für statisches SQL gefunden werden. Jeder Benutzer, der auf die gemeinsamen EXPLAIN-Tabellen zugreift, muss das Zugriffsrecht INSERT zum Einfügen für diese Tabellen aufweisen. Der Lesezugriff für die allgemeinen EXPLAIN-Tabellen muss ebenfalls eingeschränkt werden, speziell für Benutzer, die die EXPLAIN-Informationen analysieren.
EXPLAIN-Daten werden bei der Kompilierung einer SQL-Anweisung erfasst, wenn Sie dies anfordern. Bei der Anforderung von EXPLAIN-Daten sollten Sie berücksichtigen, wie die erfassten Informationen später verwendet werden sollen.
Informationen für EXPLAIN-Tabellen werden in folgenden Fällen erfasst:
Der Parameter für Sortierinformationen kann nur mit der API db2CfgGet angezeigt werden. Er kann nicht mit Hilfe des Befehlszeilenprozessors oder der Steuerzentrale angezeigt werden.
Dieser Parameter enthält 260 Byte mit Informationen zur Sortierfolge der Datenbank. Die ersten 256 Byte geben die Sortierfolge der Datenbank an, wobei Byte "n" die Sortierwertigkeit des Codepunkts enthält, dessen zu Grunde liegende dezimale Darstellung "n" in der Codepage der Datenbank ist.
Die letzten 4 Byte enthalten interne Informationen zum Typ der Sortierfolge. Bei den letzten vier Byte von collate_info handelt es sich um eine ganze Zahl. Die ganze Zahl erkennt die Endian-Folge der Plattform. Die möglichen Werte sind:
Wenn Sie diese internen Informationen zum Typ der Sortierfolge verwenden, müssen Sie eine Bytefolgeumkehrung in Betracht ziehen, wenn Informationen zu einer Datenbank auf einer anderen Plattform abgerufen werden.
Sie können die Sortierfolge bei der Erstellung der Datenbank angeben.
Ab DB2 Universal Database (UDB) Version 8.2 können Sie als Vorablesezugriffsgröße für einen Tabellenbereich die Einstellung AUTOMATIC verwenden. DB2 UDB aktualisiert automatisch die Vorablesezugriffsgröße, sobald sich die Anzahl der Behälter für den Tabellenbereich ändert.
Die Syntax der Registrierdatenbankvariablen DB2_PARALLEL_IO wird so erweitert, dass Behälter mit unterschiedlichen Merkmalen für die E/A-Parallelität erkannt werden. Bei der erweiterten Syntax können Behälter für unterschiedliche Tabellenbereiche unterschiedliche Merkmale für die E/A-Parallelität aufweisen. Die Merkmale für die E/A-Parallelität der einzelnen Tabellenbereiche werden verwendet, wenn für den Tabellenbereich als Vorablesezugriffsgröße AUTOMATIC angegeben ist. Wenn die Registrierdatenbankvariable DB2_PARALLEL_IO aktiviert ist, die erweiterte Syntax zur Angabe besonderer Merkmale für die E/A-Parallelität für Tabellenbereiche jedoch nicht verwendet wird, wird die Standardstufe für die Parallelität vorausgesetzt. Die Standardstufe ist RAID 5 (6+1).
Die vom Optimierungsprogramm verwendeten Daten für die Vorablesezugriffsgröße werden nur aktualisiert, wenn Sie eine ALTER TABLESPACE-Anweisung absetzen, die die Vorablesezugriffsgröße eines Tabellenbereichs oder die Anzahl der Behälter (mit ADD/DROP/BEGIN NEW STRIPE SET/ADD TO NEW STRIPE SET) ändert. Wenn sich die Anzahl physischer Festplatten pro Behälter in den Registry-Einstellungen ändert, muss die Anweisung ALTER TABLESPACE <tabellenbereichsname> PREFETCHSIZE AUTOMATIC abgesetzt werden, um die Daten des Optimierungsprogramms zu aktualisieren (es sei denn, eine ALTER TABLESPACE-Anweisung zur Aktualisierung der Daten des Optimierungsprogramms wurde bereits abgesetzt).
Wenn ein Tabellenbereich umgeleitet oder wiederhergestellt wird, so dass eine andere Anzahl von Behältern verwendet wird, sollten Sie die Daten des Optimie- rungsprogramms aktualisieren, indem Sie eine Anweisung ALTER TABLESPACE <tabellenbereichsname> PREFETCHSIZE AUTOMATIC absetzen. Wenn in einem Tabellenbereich mehrere Stripe-Sets vorhanden sind, wird der Stripe-Set mit der maximalen Anzahl von Behältern zur Berechnung der Vorablesezugriffsgröße verwendet. Wenn die berechnete Vorablesezugriffsgröße die Maximalgröße (32.767 Seiten) überschreitet, wird als Vorablesezugriffsgröße das größte Vielfache der Behäl- teranzahl verwendet, das kleiner als die Maximalgröße ist.
Wenn ein Tabellenbereich in einer DB2 UDB Enterprise Server Edition-Umgebung die Einstellung AUTOMATIC für die Vorablesezugriffsgröße verwendet, kann die Vorablesezugriffsgröße auf unterschiedlichen Datenbankpartitionen voneinander abweichen. Diese Situation kann eintreten, da unterschiedliche Datenbankpartitionen eine unterschiedliche Anzahl von Behältern aufweisen können, die zur Berechnung der Vorablesezugriffsgröße verwendet werden. Zum Generieren des Abfragezugriffsplans verwendet das Optimierungsprogramm die Vorablesezugriffsgröße aus der ersten Partition innerhalb einer Datenbankpartitionsgruppe.
[ Seitenanfang |Vorherige Seite | Nächste Seite | Inhaltsverzeichnis ]