Das Abschätzen der Größe von Datenbankobjekten ist ein ungenaues Unterfangen. Der Systemaufwand, der durch Datenträgerfragmentierung, freien Speicherbereich und die Verwendung von Spalten variabler Länge bedingt ist, macht eine Abschätzung schwierig, weil es eine große Bandbreite an Möglichkeiten für Spatlentypen und Zeilenlängen gibt. Erstellen Sie nach dem Abschätzen der Größe Ihrer Datenbank eine Testdatenbank, und füllen Sie sie mit repräsentativen Daten.
Über die Steuerzentrale können Sie auf eine Reihe von Dienstprogrammen zugreifen, die Sie bei der Ermittlung der Größenanforderungen verschiedener Datenbankobjekte unterstützen:
In allen diesen Fällen steht Ihnen entweder der Knopf "SQL anzeigen" oder der Knopf "Befehl anzeigen" zur Verfügung. Sie können die generierten SQL-Anweisungen oder Befehle auch in Prozedurdateien sichern, um diese später zu verwenden. In allen diesen Dienstprogrammen werden Sie durch eine Online-Hilfefunktion unterstützt.
Sie sollten diese Einrichtungen bei der Planung Ihrer physischen Datenbankanforderungen berücksichtigen.
Bei der Abschätzung der Größe einer Datenbank müssen die Auswirkungen der folgenden Elemente berücksichtigt werden:
Der Platzbedarf folgender Elemente wird nicht behandelt:
Systemkatalogtabellen werden erstellt, wenn eine Datenbank erstellt wird. Der Umfang dieser Systemtabellen nimmt in dem Maße zu, wie der Datenbank Datenbankobjekte und Zugriffsrechte hinzugefügt werden. Zu Beginn belegen diese Tabellen einen Plattenspeicherplatz von ungefähr 3,5 MB.
Die Größe des Speicherbereichs, der für die Katalogtabellen zugeordnet wird, hängt von der Art des Tabellenbereichs und der Größe des durch EXTENTSIZE definierten Bereichs des Tabellenbereichs mit den Katalogtabellen ab. Wenn z. B. ein DMS-Tabellenbereich mit einem EXTENTSIZE-Wert von 32 verwendet wird, wird dem Katalogtabellenbereich anfangs ein Speicherbereich von 20 MB zugeordnet. Weitere Informationen finden Sie in Entwerfen und Auswählen von Tabellenbereichen.
Anmerkung: | Für Datenbanken mit mehreren Partitionen befinden sich die Katalogtabellen nur in der Partition, von der aus der Befehl CREATE DATABASE abgesetzt wurde. Plattenspeicherplatz für die Katalogtabellen ist nur für diese Partition erforderlich. |
Standardmäßig werden die Tabellendaten auf Seiten von jeweils 4 KB gespeichert. Jede Seite enthält (unabhängig von der Seitengröße) 76 Byte Systemaufwand für den Datenbankmanager. Dadurch bleiben 4020 Byte für die Benutzerdaten (oder Zeilen), obwohl keine Zeile auf einer 4-KB-Seite die Länge von 4005 Byte überschreiten kann. Eine Zeile kann sich nicht über mehrere Seiten erstrecken. Wenn Sie Seiten mit jeweils 4 KB verwenden, sind maximal 500 Spalten möglich.
Tabellendatenseiten enthalten keine Daten für Spalten mit den Datentypen LONG VARCHAR, LONG VARGRAPHIC, BLOB, CLOB oder DBCLOB. Die Zeilen einer Tabellendatenseite enthalten jedoch einen Deskriptor für diese Spalten. (Informationen zur Ermittlung des Platzbedarfs für die Tabellenobjekte, die diese Datentypen enthalten, finden Sie in den Abschnitten Langfelddaten und Daten großer Objekte (LOB-Daten).)
Zeilen werden normalerweise an der ersten passenden Stelle in einer Tabelle eingefügt. Die Datei wird nach dem ersten verfügbaren Speicherbereich durchsucht (unter Verwendung einer Liste der freien Speicherbereiche), der groß genug ist, um die neue Zeile aufzunehmen. Das Aktualisieren einer vorhandenen Zeile erfolgt an der ursprünglichen Stelle, es sei denn, der freie Bereich der 4-KB-Seite reicht nicht aus, um die aktualisierte Zeile aufzunehmen. In diesem Fall wird an der Position, an der sich die Originalzeile befand, ein Datensatz erstellt, der auf die neue Speicherposition der aktualisierten Zeile in der Tabellendatei verweist.
Bei Verwendung der Anweisung ALTER TABLE APPEND ON werden Daten immer angehängt und es werden keine Informationen zum freien Speicherbereich der Datenseiten aufgezeichnet. Weitere Informationen zu dieser Anweisung finden Sie im Handbuch SQL Reference.
Die Anzahl der 4-KB-Seiten für jede Benutzertabelle in der Datenbank kann nach folgender Berechnung abgeschätzt werden:
ABRUNDEN(4020/(durchschnittszeilengröße + 10)) = datensätze_pro_seite
Das Ergebnis wird in folgende Berechnung eingefügt:
(zahl_der_datensätze/datensätze_pro_seite) * 1,1 = anzahl_der_seiten
Dabei ist die durchschnittliche Zeilenlänge die Summe der durchschnittlichen Spaltengrößen (Informationen über die Größe jeder Spalte finden Sie in der Beschreibung der Anweisung CREATE TABLE im Handbuch SQL Reference.), und der Faktor "1,1" dient zur Kalkulation des Systemaufwands.
Anmerkung: | Diese Formel ergibt nur einen Schätzwert. Die Genauigkeit des Schätzwerts nimmt ab, wenn die Datensatzlänge durch Fragmentierung und Überlaufsätze variiert. |
Sie können auch Pufferpools oder Tabellenbereiche mit einer Seitengröße von 8 KB, 16 KB oder 32 KB erstellen. Alle Tabellen, die innerhalb eines Tabellenbereichs einer bestimmten Größe erstellt wurden, besitzen eine übereinstimmende Seitengröße. Die maximale Größe für ein einzelnes Tabellen- oder Indexobjekt beträgt 512 GB bei einer einer Seitengröße von 32 KB. Wenn Sie Seiten mit einer Größe von 8 KB, 16 KB oder 32 KB verwenden, sind maximal 1012 Spalten möglich. Für eine 4-KB-Seite beträgt die maximale Spaltenanzahl 500. Die maximalen Zeilenlängen variieren ebenfalls je nach Seitengröße:
Durch größere Seiten wird es möglich, die Zahl der Indexstufen in einem Index zu verringern. Wenn Sie mit OLTP-Anwendungen arbeiten, die wahlfreie Lese- und Schreibzugriffe durchführen, ist eine geringere Seitengröße empfehlenswert, weil dadurch weniger Pufferspeicher durch unerwünschte Zeilen belegt wird. Wenn Sie mit DSS-Anwendungen (Decision Support System) arbeiten, die jeweils auf eine große Anzahl aufeinanderfolgender Zeilen zugreifen, sind größere Seiten empfehlenswert, weil dadurch weniger E/A-Anforderungen erforderlich sind, um eine bestimmte Anzahl Zeilen zu lesen. Eine Ausnahme bildet der Fall, wenn die Zeilengröße kleiner ist als die Seitengröße dividiert durch 255. In diesem Fall wird auf jeder Seite ungenutzter Speicherbereich verschenkt. (Weil jede Seite maximal nur 255 Zeilen aufnehmen kann.) Zur Verringerung des unbenutzten Speicherbereichs kann eine geringere Seitengröße besser geeignet sein.
Eine Sicherung kann nicht in einer anderen Seitengröße wiederherstellt werden.
Sie können keine IXF-Datendateien importieren, die mehr als 755 Spalten beinhalten. Weitere Informationen zum Importieren von Daten in Tabellen und IXF-Datendateien finden Sie im Handbuch Versetzen von Daten Dienstprogramme und Referenz.
Deklarierte temporäre Tabellen können nur in einem eigenen Tabellenbereichstyp für temporäre Benutzertabellen erstellt werden. Es gibt keinen Standardtabellenbereich für temporäre Benutzertabellen. Temporäre Tabellen können keine Daten mit LONG-Typen enthalten. Die Tabellen werden implizit gelöscht, wenn eine Anwendung die Verbindung zur Datenbank trennt. Schätzungen über den entsprechenden Platzbedarf sollten dies berücksichtigen.
Langfelddaten werden in einem separaten Tabellenobjekt gespeichert, das anders als bei anderen Datentypen strukturiert ist (siehe Benutzertabellendaten und Daten großer Objekte (LOB-Daten)).
Die Daten werden in Bereichen von 32 KB gespeichert, die sich aus Segmenten zusammensetzen, deren Größen sich aus dem Produkt der Zweierpotenzen und 512 Byte errechnen. (Diese Segmente können also aus 512 Byte, 1024 Byte, 2048 Byte usw. bis 32 700 Byte bestehen.)
Langfelddatentypen (LONG VARCHAR oder LONG VARGRAPHIC) werden auf eine Weise gespeichert, die eine problemlose Neuverwendung freien Speicherbereichs ermöglicht. Die Informationen zur Zuordnung und zu freien Speicherbereichen werden in Zuordnungsseiten von jeweils 4 KB gespeichert, die gelegentlich im Objekt erscheinen.
Der Bereich des freien Speicherplatzes in den Objekten ist von der Größe der Langfelddaten sowie davon abhängig, ob diese Größe bei jedem Vorkommen der Daten relativ konstant ist. Bei Dateneinträgen von mehr als 255 Byte kann dieser nicht genutzte Speicherplatz bis zu 50 Prozent der Größe der Langfelddaten ausmachen.
Wenn Zeichendaten kleiner als die Seitengröße sind und sie zusammen mit dem Rest der Daten in den Datensatz passen, sollten anstelle der Datentypen LONG VARCHAR oder LONG VARGRAPHIC die Datentypen CHAR, GRAPHIC, VARCHAR oder VARGRAPHIC verwendet werden.
Daten großer Objekte (LOB-Daten) werden in zwei separaten Tabellenobjekten gespeichert, die anders als bei anderen Datentypen strukturiert sind (siehe Benutzertabellendaten und Langfelddaten).
Bei der Abschätzung des für LOB-Daten erforderlichen Speicherbereichs müssen Sie die beiden Tabellenobjekte berücksichtigen, die zum Speichern von Daten dieser Datentypen verwendet werden:
Die Daten werden in Bereichen von 64 MB gespeichert, die sich aus Segmenten zusammensetzen, deren Größen sich aus dem Produkt der Zweierpotenzen und 1024 Byte errechnen. (Diese Segmente können also aus 1024 Byte, 2048 Byte, 4096 Byte usw. bis 64 MB bestehen.)
Zur Verringerung des für LOB-Daten erforderlichen Plattenspeicherplatzes können Sie den Parameter COMPACT in der Klausel für die LOB-Optionen der Anweisungen CREATE TABLE und ALTER TABLE angeben. Die Option COMPACT minimiert die Größe des für die LOB-Daten erforderlichen Speicherplatzes dadurch, daß die LOB-Daten in kleinere Segmente aufgeteilt werden können. Dieser Prozess beinhaltet keine Datenkomprimierung, sondern verwendet lediglich den kleinstmöglichen Speicherbereich bis zur nächsten 1-KB-Grenze. Die Angabe der Option COMPACT kann zu einer geringeren Leistung führen, wenn Daten an LOB-Werte angehängt werden.
Der Umfang des freien Speicherbereichs innerhalb der LOB-Datenobjekte wird vom Umfang der Aktualisierungs- und Löschaktivitäten sowie von der Größe der eingefügten LOB-Werte beeinflußt.
Die Informationen zur Zuordnung und zu freien Speicherbereichen werden in Zuordnungsseiten von jeweils 4 KB gespeichert, die von den eigentlichen Daten getrennt sind. Die Anzahl dieser 4-KB-Seiten ist vom Umfang der Daten (einschließlich des nicht genutzten Speicherbereichs) abhängig, die für die LOB-Daten zugeordnet wurden. Der Systemaufwand errechnet sich wie folgt: eine 4-KB-Seite pro 64 GB plus eine 4-KB-Seite pro 8 MB.
Wenn Zeichendaten kleiner als die Seitengröße sind und sie zusammen mit dem Rest der Daten in den Datensatz passen, sollten anstelle der Datentypen BLOB, CLOB oder DBCLOB die Datentypen CHAR, GRAPHIC, VARCHAR oder VARGRAPHIC verwendet werden.
Für jeden Index kann der erforderliche Speicherbereich wie folgt abgeschätzt werden:
(Durchschnittliche Indexschlüsselgröße + 8) * Anzahl der Zeilen * 2
Dabei gilt folgendes:
Anmerkung: | Fügen Sie für jede Spalte, die einen Nullwert (NULL) zuläßt, ein zusätzliches Byte für den Nullanzeiger hinzu. |
Bei der Indexerstellung ist temporärer Speicherplatz erforderlich. Der maximal während der Indexerstellung erforderliche temporäre Speicherplatz kann folgendermaßen abgeschätzt werden:
(Durchschnittliche Indexschlüsselgröße + 8) * Anzahl der Zeilen * 3,2
Dabei wird der Faktor 3,2 für den Indexaufwand sowie für den Speicherbereich einkalkuliert, der für während der Indexerstellung anfallende Sortierungen erforderlich ist.
Anmerkung: | Für nichteindeutige Indizes werden zum Speichern doppelter Schlüsseleinträge nur vier Byte benötigt. Die oben gezeigten Berechnungen gehen von eindeutigen Indizes aus. Der zum Speichern eines Index erforderliche Speicherbereich kann durch die oben gezeigte Formel eventuell zu groß abgeschätzt werden. |
Die beiden folgenden Formeln können zum Abschätzen der Anzahl von Blattseiten eines Index verwendet werden. (Die zweite Formel liefert einen etwas genaueren Schätzwert.) Die Genauigkeit dieser Schätzwerte hängt im wesentlichen davon ab, wie gut die verwendeten Durchschnittswerte die tatsächlichen Daten widerspiegeln.
Anmerkung: | Für einen SMS-Tabellenbereich ist der minimale Speicherbedarf 12 KB. Für DMS-Tabellenbereiche ist der minimale Speicherbedarf ein durch EXTENTSIZE definierter Bereich. |
(0,9 * (U - (M*2))) * (D + 1) ----------------------------- K + 6 + (4 * D)Dabei gilt folgendes:
Beachten Sie, daß die Werte für minimale Schlüsselgröße und durchschnittliche Schlüsselgröße ein Byte extra für jeden Teil des Schlüssels haben müssen, der einen Nullwert enthalten kann, und ein zusätzliches Byte für die Länge jedes Teils des Schlüssels mit variabler Länge.
Wenn INCLUDE-Spalten vorhanden sind, müssen sie in den Werten für minimale Schlüsselgröße und durchschnittliche Schlüsselgröße berücksichtigt werden.
0,9 kann durch einen beliebigen, mit (100 - pctfree)/100 berechneten Wert ersetzt werden, wenn während der Indexerstellung ein anderer Prozentwert für freien Speicherbereich (pctfree) angegeben wurde als der Standardwert zehn.
L = Blattseitenzahl = X / (Durchschnittszahl von Schlüsseln pro Blattseite)Dabei ist X die Gesamtzahl der Zeilen in der Tabelle.
Einen Schätzwert für die Originalgröße eines Indexes können Sie wie folgt berechnen:
L + 2L/(Durchschnittszahl von Schlüsseln pro Blattseite)) * Seitengröße
Für DMS-Tabellenbereiche addieren Sie die Größen aller Indizes einer Tabelle zusammen, und runden Sie auf ein Vielfaches des Werts für EXTENTSIZE für den Tabellenbereich auf, in dem sich der Index befindet.
Sie sollten weiteren Speicherbereich für das Anwachsen des Index durch INSERT/UPDATE-Vorgänge bereitstellen, die zur Teilung von Seiten führen können.
Durch die folgenden Berechnungen erhalten Sie einen genaueren Schätzwert für die Originalgröße des Indexes sowie einen Schätzwert für die Anzahl der Indexstufen. (Dies ist möglicherweise von besonderem Interesse, wenn in der Indexdefinition INCLUDE-Spalten verwendet werden.) Die Durchschnittszahl von Schlüsseln pro Nichtblattseite kann mit folgender Formel grob abgeschätzt werden:
(0,9 * (U - (M*2))) * (D + 1) ----------------------------- K + 12 + (8 * D)
Dabei gilt folgendes:
Die minimale Schlüsselgröße und die durchschnittliche Schlüsselgröße für Nichtblattseiten stimmen mit den Werten für Blattseiten überein, sofern keine INCLUDE-Spalten vorkommen. INCLUDE-Spalten werden auf Nichtblattseiten nicht gespeichert.
Sie sollten 0,9 nur durch (100 - pctfree)/100 ersetzen, wenn dieser Wert größer als 0,9 ist, weil auf Nichtblattseiten bei der Indexerstellung maximal 10% Speicherbereich frei bleibt.
Die Zahl der Nichtblattseiten kann mit folgender Formel abgeschätzt werden:
if L > 1 then {P++; Z++} While (Y > 1) { P = P + Y Y = Y / N Z++ }
Dabei gilt folgendes:
Als Gesamtzahl der Seiten ergibt sich:
T = (L + P + 2) * 1,0002
Die zusätzlichen 0,02% sind für Systemaufwand (einschließlich Speicherabbildseiten).
Der für die Indexerstellung erforderliche Speicherbereich läßt sich folgendermaßen abschätzen:
T * Seitengröße