Home 
ORDIX News 4/2004
ORDIX News 4/2004
ORDIX News 4/2004
Das IT-Magazin der ORDIX AG mit Fachbeiträgen zu Datenbanken, Unix und Java/XML.
Betrachten wir die Entwicklung der Festplatten in den vergangenen Jahren. Vor einigen Jahren war die Festplattenkapazität um ein Vielfaches kleiner und auch die Zugriffszeiten waren deutlich langsamer als bei den heutigen Plattensubsystemen. Deshalb versuchte man, Tabellen mit wenigen, dafür aber großen Extents anzulegen. Idealerweise wurden RAW Devices in der "Mitte" des Plattenstapels erzeugt, damit die Positionierungswege des Schreib-/Lesearms möglichst kurz waren.
Der Leitsatz lautete:
Wenige Extents pro Objekt = bessere Performance".
Heute wird der Effekt der Fragmentierung noch zusätzlich unterstützt und gewollt (Volume Manager, RAID 10 usw.). Auch die zusätzliche Fragmentierung von Daten aus der logischen Sicht (z. B. Fragmentation by Round Robin) ist nichts anderes als ein zusätzliches "Striping".
Der Leitsatz heute heißt: "SAME, Stripe and Mirror everything = viele Fragmente = bessere Performance".
Trotzdem sollte man die Anzahl der Extents je Datenbankobjekt möglichst gering halten. IBM Informix kann pro Objekt nur eine bestimmte Anzahl an Extents verwalten. Des Weiteren ist der Verwaltungsaufwand umso größer, je mehr Extents ein Objekt besitzt. Somit trifft der Leitsatz von früher "Wenige Extents pro Objekt = bessere Performance" auch noch heute zu.
Das eigentliche Problem hierbei liegt jedoch nicht ausschließlich im schlechteren I/O Verhalten, sondern in der Verwaltung der Extents, und zwar in der Struktur des Tablespace-Tablespace.
Das Tablespace-Tablespace verwaltet alle Partitionen/Tablespaces eines DBspace. Das bedeutet, jede Tabelle belegt genau eine Page, die Partition Page, innerhalb des Tablespace-Tablespace.
|
Jedes DBspace beinhaltet ein eigenes Tablespace-Tablespace (siehe Abbildung 1). Dieses wird in den ersten Pages des initial Chunks angelegt. Die Extent Größe des Tablespace-Tablespace beträgt 50 Pages und ist nicht änderbar. Beim Neuanlegen eines DBspaces werden diese 50 Pages direkt belegt (onspaces). Jedes Tablespace hat eine Tablespace-Nummer. In diesem Zusammenhang spricht man auch von der Partition Nummer (partnum). Das Wort Tablespace und Partition sind gleichzusetzen.
Die Partition Nummer (partnum) hat folgenden Aufbau:
0 x DDD LLLLL
 |
| Abb. 2: DBINFO Funktion. |
Die ersten 3 Halfbytes (1 ½ Bytes) stellen die DBspace Nummer dar. Die letzten 5 Halfbytes (2 ½ Bytes) die logical Page Nummer. Insgesamt belegt die Partnum 4 Bytes. Mit Hilfe der SQL-Funktion DBINFO kann man sich den DBspace Namen anhand einer Partnum ausgeben lassen (siehe Abbildung 2).
 |
| Abb. 3: Partitions-Nummer innerhalb der lokalen System- und SMI-Tabellen. |
Die Partition Nummer einer Tabelle bzw. eines Indizes kann man aus dem System Catalog (Systables) der lokalen Datenbank oder aus den SMI-Tabellen (Sysmaster Datenbank) entnehmen (siehe Abbildung 3).
Abbildung 4 zeigt die Ausgabe des Befehls onstat –d und eine Beispielerklärung, nachdem ein "neuer" DBspace erzeugt wurde.
 |
| Abb. 6: Zusammenhang DBspaces, Chunks, Tablespace und Pages. |
Alle weiteren Chunks, die zu einem DBspace hinzugefügt werden, belegen anfänglich nur 3 Pages (1 + 2 Chunk Page + Page 3, die Free Chunk Page). Die maximale Größe eines Extents ist durch die Größe eines Chunks begrenzt. Ein Tablespace hingegen kann sich über mehrere Chunks erstrecken, wie in Abbildung 6 zu sehen ist.
Eine Page im Tablespace-Tablespace wird auch Partition Page genannt.
Der Aufbau einer Partition Page entspricht einer ganz "normalen" Daten Page. Der Unterschied besteht lediglich darin, dass die Informationen, die in dieser Page gespeichert sind, keine Daten bzw. Indexdaten sind, sondern Informationen zu der Tabelle, die sie beschreibt. Des Weiteren besteht eine Partition Page ausschließlich aus 5 Slots (siehe Abbildung 7).
 |
| Abb. 7: Aufbau einer Partition Page (Page aus dem Tablespace-Tablespace). |
Der Page Header belegt immer eine feste Größe von 24 Bytes. Folgende "interne" Page Felder müssen noch berücksichtigt werden:
Slot 1: Partitionsstruktur
Informationen zur Partitionsstruktur (56 Bytes).
Slot 2: Objekt-Namen
Informationen zu DBspace Namen, Table Owner, Table Name und NLS Collations.
Slot 3: Special Columns
Informationen über Special Columns. Dieses sind z. B. VARCHAR, TEXT, BYTE, CLOB, BLOB Datentypen.
Slot 4: Index Informationen
Infomationen zu allen Indizes, die auf dieser Tabelle hinterlegt sind.
Slot 5: Extent Liste
Informationen zu Anzahl, Größe sowie der Position des Extents innerhalb des Chunks. Jeder Eintrag, also jedes Extent, belegt 8 Bytes.
Daraus resultieren folgende Größenverhältnisse:
| Page Header | 24 Bytes |
| Slot Table | 20 Bytes (4 Bytes * 5 Slots) |
| Slot 1 | 56 Bytes |
| 100 Bytes |
Das bedeutet, dass bei einer angenommenen Pagesize von 4096 Bytes für die Slots 2 - 5 3996 Bytes zur Verfügung bleiben.
Die maximale Anzahl der Extents pro Tabelle ist, wie oben ersichtlich, in besonderer Weise von folgenden Gegebenheiten abhängig:
Der Rest des Speicherplatzes in der Partition Page steht somit dem Slot 5 der Extent Liste zur Verfügung. Die maximale Anzahl Extents je Tabelle kann somit variieren. Im Durchschnitt können Tabellen mit einer Pagesize von 2K ca. 250 Extents und bei einer Pagesize von 4K ca. 400 Extents belegen.
Wird ein neues Extent erzeugt, bedeutet das somit auch einen weiteren 8 Byte Eintrag im Slot 5 in der Partition Page. Der Verwaltungsaufwand wird genau an dieser Stelle sichtbar. Besteht ein Objekt aus wenigen Extents, ist der Verwaltungsaufwand geringer. Besteht eine Tabelle aus vielen Extents, wirkt sich dieses nicht nur negativ auf das I/O Verhalten aus, sondern der Verwaltungsaufwand der Extents steigt – durch die längere Extent Liste – deutlich an.
Das SQL-Skript in Abbildung 8 gibt Auskunft über die Anzahl der Extents einer Tabelle. Also u. a. die Sicht auf unser Tablespace-Tablespace.
Mit diesem Artikel erläuterten wir Ihnen zunächst die interne Architektur des IBM Informix Dynamic Servers bezüglich der Verwaltung der Extents. Im 2. Teil dieser Reihe, der in einer der nächsten ORDIX News Ausgaben erscheint, lesen Sie, welche Mittel und Möglichkeiten Sie haben, um eine Reorganisation "performant" durchzuführen.
Guido Saxler (info@ordix.de).
