DB2 10.5 for Linux, UNIX and Windows

database_memory - Größe des gemeinsam genutzten Datenbankspeichers (Konfigurationsparameter)

Der Konfigurationsparameter database_memory gibt die Größe der Datenbankspeichergruppe an. Die Größe des Datenbankspeichers wird auf alle geltenden Instanzspeichergrenzwerte angerechnet. Die Einstellung muss hoch genug sein, um die folgenden konfigurierbaren Speicherpools zu berücksichtigen: Pufferpools, Datenbankheapspeicher, Sperrenliste, Zwischenspeicher für Dienstprogramme, Paketcache, Katalogcache, Speicher für gemeinsame Sortierung und einen zusätzlichen Überlaufbereich von mindestens 5 %.

Konfigurationstyp

Datenbank

Gilt für

Datenbankserver mit lokalen und fernen Clients
Datenbankserver mit lokalen Clients
Partitionierten Datenbankserver mit lokalen und fernen Clients

Parametertyp

Online konfigurierbar (Datenbankverbindung erforderlich)
Anmerkung: Erfordert eine Datenbankverbindung. Dynamische Änderungen können bei fixiertem Speicher und umfangreichen Seitenkonfigurationen nur in beschränktem Maße ausgeführt werden.
Nach Member in einer DB2 pureScale-Umgebung und in Umgebungen mit partitionierten Datenbanken konfigurierbar

Standardwert [Bereich]

AUTOMATIC [AUTOMATIC, COMPUTED, 0 - 4 294 967 295]

Maßeinheit

Seiten (4 KB)

Wenn zugeordnet oder festgeschrieben

Unter Linux- und UNIX-Betriebssystemen: Die Anfangsgröße wird bei der Datenbankaktivierung zugeordnet. Zusätzlicher Hauptspeicher wird bedarfsgesteuert zugeordnet.
Unter Windows-Betriebssystemen: Der Hauptspeicher wird bedarfsgesteuert zugeordnet.

Der Speicher für Pufferpools, die Sperrenliste und die Basisinfrastruktur wird während der Aktivierung der Datenbank festgeschrieben. Der zusätzliche Speicher wird bedarfsgesteuert festgeschrieben.

Freigabe

Der gesamte Datenbankspeicher wird freigegeben, wenn eine Datenbank inaktiviert wird. Der Speichermanager für automatische Leistungsoptimierung (STMM - Self Tuning Memory Manager) gibt beim Verringern der Größe des Datenbankspeichers Speicherbereich für das Betriebssystem frei. Die weitere Freigabe von Speicher ist von der Einstellung des Konfigurationsparameters db_mem_thresh abhängig.

Unter UNIX-Betriebssystemen ordnet DB2 nach der Anfangszuordnung der Datenbankspeichergröße bei der Datenbankaktivierung zusätzlichen Hauptspeicher bedarfsgesteuert zu, um dynamische Anforderungen zu unterstützen. Die Zuordnung zusätzlichen Speichers wird abhängig von eventuellen festen Größenbegrenzungen durchgeführt. Der gesamte Datenbankspeicher wird als gemeinsam genutzter Speicher zugeordnet und solange beibehalten, bis die Datenbank inaktiviert wird. Der insgesamt zugeordnete gemeinsame Speicher wird nur auf die Verwendung virtuellen Speichers angerechnet. Während hierbei keine Unterstützung durch den Realspeicher erforderlich ist, ist für virtuellen Speicher bei einigen Betriebssystemen eine Unterstützung durch Auslagerungs- oder Paging-Speicher erforderlich. Unter Windows-Betriebssystemen wird der Datenbankspeicher als privater Speicher bedarfsgesteuert zugeordnet und orientiert sich dabei an festen Größenbeschränkungen. Zuordnungen, die nicht mehr benötigt werden, können dynamisch freigegeben oder zur Wiederverwendung beibehalten werden. Alle ausstehenden Speicherzuordnungen werden freigegeben, wenn die Datenbank inaktiviert wird. Details zur Betriebssystemunterstützung finden Sie im Abschnitt Betriebssystemunterstützung.

Beim gebundenen Speicher handelt es sich um Speicher, der durch das Betriebssystem abgesichert ist. Mit Ausnahme des fixierten Speichers, der umfangreiche Seitenkonfigurationen umfasst, wird der zugeordnete Speicher entsprechend den Anforderungen der Hauptspeicherpools festgeschrieben. Der gebundene Speicher, der von Speicherpools nicht mehr benötigt wird, wird entweder im Cache zwischengespeichert, um die Leistung zu verbessern, oder freigegeben und als nicht gebundener Speicher wieder dem Betriebssystem zur Verfügung gestellt. Die ausgeführte Aktion hängt von der Einstellung des Konfigurationsparameters db_mem_thresh ab. Speicher wird auch bei Bedarf freigegeben, wenn die für database_memory angegebene Größe verringert wird, beispielsweise durch STMM. Der gesamte gebundene Speicher wird freigegeben, wenn die Datenbank inaktiviert wird.

Die Größe des Datenbankspeichers wird auf die Speicherbelegung der Instanz angerechnet. Der Überlaufbereich des Datenbankspeichers ist äquivalent zum Cachespeicher der Instanz für den Datenbankspeicherkonsumenten. Ein Überlauf des Datenbankspeichers kann dynamisch reduziert werden, wenn dies zur Erfüllung der Anforderungen anderer Speicherbereiche notwendig ist, die von der Datenbankinstanz verwendet werden. Dieser Vorgang wird automatisch durchgeführt, wenn eine Instanzspeicherbegrenzung wirksam ist.

Die konfigurierten Größen des zugrunde liegenden Speicherpools werden aus der Datenbankspeichergröße reserviert. Der verbleibende Datenbankspeicher wird als Überlaufspeicher eingestuft. Die Speicherpools haben normalerweise die Möglichkeit zur Nutzung des gesamten Überlaufspeichers, der auch als nicht reservierter Speicher bezeichnet wird.

STMM (Self Tuning Memory Manager) ist eine Funktion, die Sie zur automatischen Konfiguration der Schlüsselspeicherbereiche verwenden können. Sie können STMM zur Optimierung der Gesamtgröße des Datenbankspeichers sowie zur Optimierung der folgenden Bereiche innerhalb des Datenbankspeichers aktivieren:

Pufferpools
Sperrenliste
Speicher für gemeinsame Sortierung (wenn SHEAPTHRES gleich 0)
Paketcache

Die Größe des Überlaufbereichs ist abhängig von der Größe des Datenbankspeichers. Für große Datenbankspeicher ist ein kleinerer Überlauf erforderlich und für kleine Datenbankspeicher ein größerer Überlauf bis zu einem maximalen Wert von 10 %. Die Überlaufmenge wird während der Datenbankaktivierung und mit unbestimmter Laufzeit als Teil der STMM-Überlaufoptimierung berechnet.

Tabelle 1. Vergleich von Datenbankspeichergröße und Überlauf
Datenbankspeichergröße	Überlaufziel
Höchsten 64 GB	10 %
64 - 96 GB	9 %
96 - 156 GB	8 %
156 - 266 GB	7 %
266 - 493 GB	6 %
Mindestens 493 GB	5 %

Das Verhalten der Werte, die database_memory zugeordnet werden können, lautet wie folgt.

AUTOMATIC

Wenn für database_memory die Einstellung AUTOMATIC definiert wurde, dann wird die Anfangsgröße des Datenbankspeichers auf Basis der zugrunde liegenden Konfigurationsanforderungen berechnet. Dies gilt für die folgenden Komponenten:

Pufferpools
Datenbankheapspeicher
Sperrenliste
Zwischenspeicher für Dienstprogramme
Paketcache
Katalogcache
Speicher für gemeinsame Sortierung (sofern aktiviert)
Überlaufbereich

Die Einstellung AUTOMATIC ermöglicht ein Anwachsen des Datenbankspeichers über die Anfangsgröße hinaus, wenn unvorhersehbare Anforderungen auftreten, die vom Überlaufbereich nicht abgedeckt werden können. Dynamische Konfigurationsänderungen, die manuell oder mit STMM an einzelnen Speicherpools durchgeführt werden, führen auch zu einer Anpassung der Datenbankspeichergröße um den entsprechenden Betrag.

Wenn STMM aktiviert ist (Wert für SELF_TUNING_MEM ist ON), dann steuert STMM die Gesamtgröße des Datenbankspeichers. STMM berücksichtigt dabei die zugrunde liegenden Konfigurationsanforderungen einschließlich des Überlaufs sowie die Leistungsvorteile, die sich durch das Anfordern zusätzlichen Speichers ergeben. Abhängig von der Einstellung für instance_memory optimiert STMM den Datenbankspeicher, um Engpässe beim System- und Instanzspeicher zu vermeiden. Ein Prozentsatz an Speicher, den Sie über die Variable DB2_MEM_TUNING_RANGE steuern können, steht weiterhin zur Verfügung, um flüchtige Anforderungen zu erfüllen. Wenn eine Datenbank aktiviert wird und nicht genügend System- oder Instanzspeicher zur Unterstützung der Startkonfiguration zur Verfügung steht, dann werden alle von STMM optimierten Speicherbereiche reduziert, um vorhandene Speicherbeschränkungen zu berücksichtigen. Bei dieser Aktion werden die erzwungenen Minimumgrößen berücksichtigt.

Fester Wert

Sie können dem Konfigurationsparameter database_memory einen spezifischen Wert zuordnen. Der angegebene Wert muss jedoch hoch genug sein, um die Mindestkonfigurationsanforderungen zu unterstützen. Dies gilt für die folgenden Komponenten:

Pufferpools
Datenbankheapspeicher
Sperrenliste
Zwischenspeicher für Dienstprogramme
Paketcache
Katalogcache
Speicher für gemeinsame Sortierung (sofern aktiviert)
Mindestüberlaufbereich von 5 %

Wenn der zugeordnete Wert zu gering ist, dann wird die höhere Minimumgröße zugeordnet, die zur Unterstützung der Konfiguration erforderlich ist. Der zugeordnete Datenbankspeicher darf die feste Einstellung oder die höhere der Minimumgrößen nicht überschreiten. Die Einstellung für den Datenbankspeicher kann dennoch dynamisch erhöht oder in AUTOMATIC geändert werden. Die dynamische Erhöhung der Konfigurationswerte für die Speicherpools kann nur erfolgreich ausgeführt werden, wenn genügend Überlaufspeicher verfügbar ist.

Wenn STMM aktiviert ist (Wert für SELF_TUNING_MEM ist ON), dann werden nur die zugrunde liegenden Speicherpools und der zugrunde liegende Überlaufspeicher optimiert. Wenn zum Zeitpunkt der Datenbankaktivierung eine feste Einstellung existiert, die zu niedrig ist, um die aktuelle Konfiguration zu unterstützen, dann werden die individuellen Bereiche, die von STMM optimiert wurden, reduziert. Auf diese Weise können vorhandene Speicherbeschränkungen berücksichtigt werden. Bei dieser Aktion werden die erzwungenen Minimumgrößen berücksichtigt. Es wird empfohlen, mindestens die Hälfte einer in database_memory definierten festen Konfiguration für die STMM-Optimierung bereitzustellen. Beispiel: Wenn die Größe der Pufferpoolbereiche manuell definiert wird, dann sollten die Pufferpools nicht mehr als die Hälfte des in der Einstellung für database_memory angegebenen festen Werts betragen. Andernfalls kann es zu Einschränkungen bei den STMM-Optimierungsfunktionen und zu einer suboptimalen Leistung sowie zu Symptomen kommen, die in Zusammenhang mit den beschränkten Speicherressourcen stehen.

COMPUTED

COMPUTED ist eine Einstellung, die nicht mehr verwendet wird. Ihr Verhalten ähnelt dem von AUTOMATIC, wenn STMM nicht aktiviert ist. Wenn STMM aktiviert ist, dann ähnelt das Verhalten von COMPUTED dem eines festen Werts.

Betriebssystemunterstützung

Tabelle 2. Betriebssystemunterstützung
Betriebssystem	Verfügbare Unterstützung
AIX	Verwendet standardmäßig Seiten mittlerer Größe (64 K), die sich positiv auf die Leistung auswirken können. AIX unterstützt fixierten Speicher und große bis sehr große Seiten (16 MB/16 GB).¹
HP-UX	Der zugeordnete, gemeinsam genutzte Speicher muss durch virtuellen Auslagerungsspeicher abgesichert werden. HP-UX unterstützt fixierten Speicher.¹
Linux	Der zugeordnete, gemeinsam genutzte Speicher wird auf die Begrenzung des gemeinsam genutzten, virtuellen Speichers (shmall) angerechnet. Linux unterstützt fixierten Speicher und große Seiten (2 MB).¹
Solaris	Der zugeordnete, gemeinsam genutzte Speicher muss durch virtuellen Auslagerungsspeicher abgesichert werden und wird auf definierte Begrenzungen des virtuellen Speichers angerechnet. Solaris unterstützt den fixierten ISM-Speicher und große Seiten.²
Windows	Unterstützt große Seiten (2 MB).¹
Anmerkung: Die Verwendung der Speicherfixierung (DB2_PINNED_BP) und großer bzw. sehr großer Seiten (DB2_LARGE_PAGE_MEM) schränkt die Möglichkeit zur dynamischen Freigabe von Speicherplatz ein. STMM führt eingeschränkte Optimierungsoperationen in diesem Umgebungstyp aus und versucht nicht, die Gesamtgröße des Datenbankspeichers anzupassen. Es wird empfohlen, einen festen Wert für database_memory zu konfigurieren, wenn STMM in diesen Konfigurationen verwendet wird. Dadurch wird es für STMM möglich, eine einheitliche Größenanpassung für den Datenbankspeicher optimal zu nutzen. Wenn für database_memory unter einem Solaris-Betriebssystem die Einstellung AUTOMATIC verwendet wird, dann verwendet der Datenbankmanager den umlagerbaren Speicher für den gemeinsam genutzten Datenbankspeicher. Dadurch kann die Konfiguration des Datenbankspeichers vollständig dynamisch durchgeführt werden und STMM kann die Gesamtgröße des Datenbankspeichers optimieren. In SPARC-Architekturen versucht der Datenbankmanager, Speicherseiten mit einer Größe von 64 KB zu verwenden, sofern solche Seiten verfügbar sind. Andernfalls werden 8-KB-Speicherseiten verwendet. In 64-Bit-Architekturen verwendet der Datenbankmanager 4-KB-Speicherseiten. Wenn eine feste Option oder die Option COMPUTED für den Datenbankspeicher verwendet wird, wird (fixierter) ISM-Speicher zugeordnet. In diesem Fall wählt Solaris die größte geeignete Seitengröße aus, durch die Leistungsverbesserungen erzielt werden können. Die dynamischen Änderungen der Datenbankspeicherkonfiguration sind jedoch beschränkt und STMM versucht nicht, die Gesamtgröße des Datenbankspeichers zu optimieren. Änderungen zwischen AUTOMATIC und den anderen Optionen für database_memory können unter Solaris-Betriebssystemen nicht dynamisch ausgeführt werden.

Überwachung

Die Datenbankspeichergruppe kann mithilfe der Routinen MON_GET_MEMORY_SET und MON_GET_MEMORY_POOL überwacht werden. Beispiel: Mit dem Befehl

db2 "select member, substr(db_name,1,10)as db_name, substr(memory_set_type,1,10) as set_type, 
memory_set_size, memory_set_committed, memory_set_used, memory_set_used_hwm 
from table(mon_get_memory_set('DATABASE','',-1))"

können die folgenden Informationen zurückgegeben werden:

MEMBER DB_NAME    SET_TYPE   MEMORY_SET_SIZE      MEMORY_SET_COMMITTED MEMORY_SET_USED      MEMORY_SET_USED_HWM 
------ ---------- ---------- -------------------- -------------------- -------------------- -------------------- 
     0 SAMPLE     DATABASE                 154927                68616                67829                68616 
     0 TEST       DATABASE                 238092               123404               123404               123404 

  2 Satz/Sätze ausgewählt.

In diesem Fall verwendet die Datenbankspeichergruppe einen Wert von 154927 KB für instance_memory (MEMORY_SET_SIZE) und einen Wert von 68616 KB für den Systemspeicher (MEMORY_SET_COMMITTED), von dem 67829 KB (MEMORY_SET_USED) den Speicherpools zugeordnet sind.

Der Datenbankspeicher kann auch mit dem Dienstprogramm db2pd überwacht werden:

db2pd -db  <datenbankname> -memsets -mempools, db2pd -dbptnmem