Wie in der letzten Ausgabe angekündigt, schauen wir uns in dieser ORDIX News die „dynamische Speicherung“ aus dem Bereich der automatischen Datenbankverwaltung an. Was in der deutschen Übersetzung oft als „dynamischer Speicher“ bezeichnet wird, ist in der DB2-Originaldokumentation als „Automatic Storage“ wiederzufinden. Diese Bezeichnung findet sich auch in der Syntax der verschiedenen DB2-Kommandos wieder. Wir verwenden im Folgenden den Begriff „dynamischer Speicher“.

Rückblick Tablespaces

Beim Anlegen einer Datenbank werden immer drei Default Tablespaces angelegt: SYSCATSPACE, TEMPSPACE und USERSPACE. Für alle weiteren Tablespaces, die nachträglich von Hand erstellt werden, müssen explizit Container mit der Klausel MANAGED BY SYSTEM (SMS) oder MANAGED BY DATABASE (DMS) des Kommandos CREATE TABLESPACE benannt werden.

DMS

Der Speicherplatz eines DMS-Bereichs wird vom Datenbankmanager verwaltet und sofort nach Anlegen eines Containers komplett reserviert. Dieser Speicherplatz steht dann ausschließlich der Datenbank zur Verfügung. Vom Datenbankadministrator kann für einen Container entweder eine Datei oder eine unformatierte Einheit (Raw Device) angegeben werden.

SMS

Der Speicherplatz eines SMS-Bereichs wird vom Betriebssystem verwaltet und nur so weit reserviert, wie er benötigt wird. Der Datenbankadministrator gibt lediglich das Verzeichnis für die Container vor. Welche Dateien dann letzten Endes unterhalb dieses Verzeichnisses angelegt werden, wird dem Datenbanksystem überlassen. Der Zugriff darauf erfolgt aber immer über das Betriebssystem.

Wird beispielsweise eine Tabelle mit Daten befüllt, so wird auch erst zu diesem Zeitpunkt der Speicherplatz extern für Extent auf der Festplatte reserviert. Und dann auch nur in dem Maße, wie er für die neuen Daten tatsächlich benötigt wird.

Datenbanken mit dynamischem Speicher

Im Gegensatz zur festen Definition der Container eines Tablespace über die Syntaxklauseln MANAGED BY SYSTEM oder MANAGED BY DATABASE werden die Container beim Einsatz von dynamischem Speicher vom Datenbankmanager angelegt und verwaltet. Ob eine Datenbank mit dynamischem Speicher arbeitet oder nicht, wird beim Anlegen der Datenbank festgelegt. Eine nachträgliche Änderung, sowohl das Einschalten als auch das Ausschalten, ist nicht mehr möglich.

Anstelle der Container bzw. der Pfade der Container werden bei der Verwendung von dynamischem Speicher nur Speicherpfade bzw. Gruppen von Speicherpfaden definiert. Dahinter verbirgt sich nichts anderes als Verzeichnisse im Dateisystem.

Wird eine Datenbank mit dynamischem Speicher angelegt, werden die drei Default Tablespaces ebenfalls mit dynamischem Speicher angelegt. Ab der Version 9.1 ist die Verwendung von dynamischem Speicher beim Anlegen einer Datenbank Standard. Soll eine Datenbank ohne dynamischen Speicher angelegt werden, so muss man bei dem Kommando CREATE DATABASE die Syntaxerweiterung AUTOMATIC STORAGE NO verwenden.

Die Speicherpfade, die bei der Verwendung von dynamischem Speicher definiert werden können, sind der Datenbankpfad und der Speicherpfad. Die für den Datenbank- bzw. Speicherpfad angegebenen Verzeichnisse müssen vorhanden und vom Eigentümer der Instanz beschreibbar sein. Mit dem Kommando ALTER DATABASE ADD STORAGE kann der Speicherpfad um weitere Pfade erweitert werden.

Datenbankpfad

Im Datenbankpfad werden vom Datenbankmanager interne Verwaltungsinformationen für die Datenbank gespeichert. Wird beim Anlegen einer Datenbank der Datenbankpfad nicht definiert, so wird dafür der Standarddatenbankpfad (Datenbankmanager Konfigurationsparameter DFTDBPATH) verwendet, der durch die Klausel DBPATH ON beim Anlegen einer Datenbank festgelegt wird. Wird beim Anlegen der Datenbank nur der Speicherpfad mit der Klausel ON definiert, so wird für den Datenbankpfad der erste Pfad des Speicherpfades verwendet.

Speicherpfad

db2>
db2> CREATE DATABASE MYDB1
db2>

db2>
db2> CREATE DATABASE MYDB2 ON /db/pfad1
db2>

db2>
db2> CREATE DATABASE MYDB3 ON /db/pfad1, /db/pfad2
db2>

db2>
db2> CREATE DATABASE MYDB4 ON /db/pfad1 DBPATH ON /db/pfad2
db2>

db2>
db2> CREATE TABLESPACE MYTBS1
db2>
db2> CREATE TABLESPACE MYTBS2 MANAGED BY AUTOMATIC STORAGE
db2>

db2>
db2> CREATE TEMPORARY TABLESPACE TMPTBS
db2>

db2>
db2> CREATE USER TEMPORARY TABLESPACE UTMPTBS
MANAGED BY AUTOMATIC STORAGE
db2>

db2>
db2> CREATE LONG TABLESPACE LONGTBS
db2>

Im Speicherpfad werden die eigentlichen Daten (Tabelleninhalte und Indizes) gespeichert. Auch für den Speicherpfad wird als Standardwert der Standarddatenbankpfad (Datenbankmanager Konfigurationsparameter DFTDBPATH) verwendet.

Die Abbildungen 1 - 4 zeigen verschiedene Beispiele zum Anlegen einer Datenbank mit dynamischem Speicher.

Tablespaces mit dynamischem Speicher

Bei Datenbanken ohne dynamischen Speicher müssen die Container den Tablespaces mit MANAGED BY SYSTEM (SMS) und MANAGED BY DATABASE (DMS) fest zugeordnet werden. Für dynamischen Speicher gibt es beim Kommando CREATE TABLESPACE die Syntaxerweiterung MANAGED BY AUTOMATIC STORAGE. Es ist auch möglich, das Kommando ohne eine MANAGED BY Klausel zu verwenden. Dadurch wird für den neuen Tablespace implizit dynamischer Speicher verwendet.

Die Abbildungen 5 - 8 zeigen verschiedene Beispiele zum Anlegen von Tablespaces mit dynamischem Speicher. Diese gelten allerdings nur für Datenbanken, die ebenfalls mit dynamischem Speicher angelegt wurden.

Dynamischer Speicher - SMS oder DMS?

Auch für den dynamischen Speicher gibt es die beiden Varianten SMS bzw. DMS. Allerdings ist die Verwendung fest vorgegeben. Reguläre und Large Tablespaces werden als DMS mit Datei-Containern angelegt. Dagegen werden Temporäre Tablespaces als SMS mit Verzeichnis-Containern angelegt. Diese Zuordnung gilt für die Version 9.1 und kann sich gemäß der IBM-Dokumentation in zukünftigen Versionen ändern.

Namen der Container

Die vom Datenbankmanager im Speicherpfad angelegten Container haben den Namen:
<Speicherpfad>/<Instanz>/NODE####/<Datenbank>/T#######/C#######.<ERW> Dabei ist:

<ERW> kann sein:

Dynamischer Speicher - RESTORE DATABASE

Beim Restore einer Datenbank mit dynamischem Speicher können der Datenbank- und der Speicherpfad neu definiert werden. Dies entspricht dem umgeleiteten Restore (Redirected Restore) einer Datenbank ohne dynamischen Speicher. Dazu gibt es beim RESTORE DATABASE die Klauseln TO, ON und DBPATH ON.

Für den Datenbankpfad gilt dabei Folgendes:

Ist eine Datenbank mit dem gleichen Namen auf dem System schon vorhanden und soll durch Restore ersetzt bzw. überschrieben werden, kann der Datenbankpfad nicht geändert werden. Mit den Klauseln ON beziehungsweise DBPATH ON wird der Datenbankpfad definiert, der für die wiederhergestellte Datenbank verwendet werden soll.

Wird nur der Speicherpfad angegeben, so wird für den Datenbankpfad der erste Speicherpfad verwendet. Wird keine der Klauseln TO, ON oder DBPATH ON angegeben, wird für den Datenbankpfad der Wert des Parameters DFTDBPATH der Konfiguration des Datenbankmanagers verwendet.

Für den Speicherpfad gibt es nur die beiden Varianten mit ON-Klausel und ohne ON-Klausel. Wird keine ON-Klausel verwendet, so werden die Speicherpfade des Backup Images verwendet. Durch Verwendung der ON-Klausel, werden die Speicherpfade für die wiederherzustellende Datenbank neu definiert.

Ob eine gesicherte Datenbank mit oder ohne dynamischem Speicher gearbeitet hat und welche Speicherpfade gegebenenfalls verwendet wurden, kann mit dem Kommando db2ckbkp -s ermittelt werden. Dem Kommando wird neben der Option -s das Backup Image als Parameter übergeben. Die Ausgabe liefert unter anderem Informationen über die Speicherpfade und ob dynamischer Speicher verwendet wurde.

Überwachung des Speicherplatzes

Wie viel Speicherplatz durch den dynamischen Speicher belegt ist, ermittelt man mit einem Snapshot auf die Datenbank. Das Kommando GET SNAPSHOT FOR DATABASE ON <Datenbank> liefert die Anzahl der für den dynamischen Speicher definierten Pfade.

Für jeden Pfad werden neben dem Namen eine Filesystem-ID und der freie Speicher in dem Speicherpfad ausgegeben. Zudem wird die Größe des Dateisystems ermittelt, in dem der Speicherpfad liegt und wie viel Speicher darin schon verwendet wird.

Einschränkungen

Bei der Verwendung von dynamischem Speicher sind einige Einschränkungen zu beachten:

• Ob dynamischer Speicher verwendet wird oder nicht, wird beim Anlegen der Datenbank festgelegt und kann nachträglich nicht mehr geändert werden.
• Die verwendeten Speicherpfade müssen absolute Pfade sein.
• Reguläre und LOB-Tablespaces werden bei der Verwendung von dynamischem Speicher immer als DMS angelegt. Einzelne Container können dabei nicht definiert werden.
• Der Standardwert für die automatische Größenanpassung der Container ist ON. Somit ist die Größe der regulären und der LOB-Tablespaces nur durch das Dateisystem beschränkt. Die Startgröße für einen Container kann über die Klausel INITIALSIZE angegeben werden. Die Anfangsgröße für LOBS ist 32 MB.
• Operationen, die auf DMS- oder SMS-Containern ausgeführt werden können, wie z. B. ALTER TABLESPACE (ADD, DROP, BEGIN NEW STRIPE SET usw.) sind bei der Verwendung von dynamischem Speicher nicht möglich.
• Wie bereits beschrieben, können bei einem Restore nur der Datenbank- und der Speicherpfad geändert werden. Einzelne Container können nicht neu definiert werden. Somit ist der Befehl SET TABELSPACE CONTAINERS nicht möglich.

Fazit

Die „dynamische Speicherung“ gehört mit Sicherheit zu den interessantesten Neuerungen aus dem Bereich der automatischen Datenbankverwaltung. Sie bringt sowohl Vor- als auch Nachteile mit sich. So muss sich der Datenbankadministrator zum Beispiel nicht mehr um die Verwaltung der Container kümmern. Diese Aufgabe wird ihm vom Datenbanksystem abgenommen. Auch ein umgeleiteter Restore ist um einiges einfacher und kann sogar in einem Schritt durchgeführt werden.

Bei der Verwendung von dynamischem Speicher gibt der Datenbankadministrator jedoch die Möglichkeit aus der Hand, eine Zuordnung auf Ebene der physikalischen Platten vorzunehmen. Dies ist beim Einsatz von SAN kaum möglich.

Die Verwendung von RAW Devices für die Container ist bei der dynamischen Speicherung nicht mehr möglich. Da die meisten Datenbankadministratoren dies bis jetzt auch nicht verwendet haben, ist das sicher kein großes Manko. Der freiwillige Verzicht auf bis zu 10 Prozent der I/O-Leistung sollte allerdings dabei bedacht werden.

Haben Sie Fragen zu diesem Thema? Dann sprechen Sie uns an!

Holger Demuth und Thorsten Schuhmacher (info@ordix.de).

Seitenanfang

Seite drucken

Seite weiterempfehlen