Datenbankadministration

Transkript

1 Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Prof. Dr. K. Küspert Dipl.-Math. K. Büchse Dipl.-Inf. A. Göbel Datenbankadministration Projekt 1: DB2-Konguration und physischer Datenbankentwurf WS 2012/2013 Beginn: Abgabe: Besprechung: Einleitung In diesem Projekt sollen Sie exemplarisch für DB2-Kongurationsfragen sensibilisiert und mit einigen wichtigen Fragestellungen beim physischen Datenbankentwurf konfrontiert werden. Der erste Teil dient dem Kennenlernen von einigen im Verlauf des weiteren Praktikums benötigten Kongurationsparametern und dem Analysieren der logischen und physischen Struktur der Datenbank ADMIN, welche für das Praktikum vorbereitet wurde. Die Aufgaben im zweiten Teil des Projekts beschäftigen sich mit der Bestimmung eines geeigneten physischen Entwurfs zu einer beschriebenen Datenbank sowie mit der Transformation der physischen Struktur der bereits vorhandenen Datenbank (ADMIN). Hinweis: Machen Sie sich vor der Bearbeitung der folgenden Aufgaben mit der Arbeitsweise auf dem AIX-Datenbankserver vertraut. Hierzu steht Ihnen auf der Website der Lehrveranstaltung das Dokument Informationen und Hinweise zur Verfügung. Des Weiteren sollten Sie sich einen Überblick des DB2 Information Centers 1 verschaen. Diese ist in englischer Sprache und deutscher Übersetzung verfügbar, passen Sie ggf. die Sprache der Benutzeroberäche Ihres Browsers an. Die mit einem Stern markierten Aufgaben bzw. Teilaufgaben sind nur von Studierenden eines Diplomstudiengangs zu bearbeiten. Alle Aufgaben und Ergebnisse sind zu dokumentieren: Anfragen, Befehle, Ergebnisse und ggf. der Lösungsweg mit sämtlichen Rechnungen sind mit evtl. Erläuterungen und Begründungen abzugeben. Reduzieren Sie die DB2-Ausgaben stets auf die relevanten Teile, so sind die Ergebnismengen von SQL-Anfragen stets auf maximal 20 Tupel zu begrenzen. Notieren Sie Ihr Kennzeichen (Login) und die Namen der zugehörigen Gruppenmitglieder auf dem Deckblatt Ihrer Aufgabenlösungen. Geben Sie ihre Lösung in schriftlicher Form (geheftet oder getackert, 1- oder 2-spaltig) als auch elektronisch per an andreas.goebel@uni-jena.de bis zur Veranstaltung am Abgabetermin ab. Teil 1 Konguration Vertiefende Informationen: Aufgaben 1, 2 und 4: Im DB2 Information Center nden Sie unter dem Punkt Database reference u.a. die notwendigen Informationen zu Kongurationsparametern (Conguration parameters), Register- und Umgebungsvariablen (Registry and environment variables), 1 zu nden unter: 1

2 DB2-Befehlen (Commands CLP Commands) und eine umfassende Katalog-Beschreibung (SQL Catalog views). Aufgabe 3: Informationen zu den DB2-Prozessen nden Sie in dem Abschnitt The DB2 process model im DB2 Information Center. Aufgabe 5: Die notwendigen DB2-Befehle sind im Abschnitt Database reference Commands CLP Commands des DB2 Information Centers beschrieben. Wir empfehlen Ihnen, sich durch das Studium des Abschnitts Database administration Administration concepts Databases mit den für den physischen Entwurf zentralen Begrien Table Space (SMS, DMS, dynamischer Speicher), Container sowie Extent vertraut zu machen. Ebenfalls ist folgender Artikel DB2 Storage Trivia zu empfehlen 2 : Aufgabe 1 (Datenbankverzeichnis) a) Stellen Sie fest, welche Datenbanken zu Ihrer Instanz gehören. Falls die Datenbank ADMIN noch nicht für Ihre Instanz generiert wurde, so holen Sie dies bitte durch Start von admin_db 3 nach. Die erfolgreiche Erstellung der Datenbank wird nach wenigen Minuten mit der Ausgabe Done bestätigt. Prüfen Sie, ob die Datenbank erfolgreich zum Datenbankverzeichnis hinzugefügt wurde. b) Umgebungswerte für DB2 können sowohl in Umgebungsvariablen des Betriebssystems als auch auch in sogenannten Registervariablen mittels db2set gespeichert werden. Mit welchem Wert ist die für Ihre Instanz gesetzte Umgebungsvariable DB2INSTANCE belegt? Wann und wo wird diese gesetzt, und welche Bedeutung hat sie? c) Erzeugen Sie die Datenbank SAMPLE mit dem Befehl db2sampl. Benutzen Sie die DB2DBDFT- Variable, um die Datenbank SAMPLE zeitweilig zu Ihrer Default-Datenbank zu machen. Wozu dient die Default-Datenbank? Können Sie diese Umstellung in der laufenden DB2-Sitzung vornehmen? Hat eine solche Umstellung einen unmittelbaren Eekt? Hinweise: a) Die aktuelle DB-Verbindung können Sie mit GET CONNECTION STATE ermitteln. b) DB2 verwendet einen Hintergrundprozess, über welchen die Abarbeitung aller Befehle und Kommandos erfolgt. Dieser Prozess liest alle Umgebungs- und DB2-Registry-Variablen beim Starten ein und überwacht nicht, ob später Änderungen erfolgen. Daher ist es mitunter notwendig, das DB2-Kommando TERMINATE zu verwenden, um diesen Hintergrund zu beseitigen. Aufgabe 2 (Kongurationsparameter) a) Lassen Sie sich die Kongurationsparameter Ihrer Instanz (DBM) am Bildschirm anzeigen. Beschreiben Sie die Bedeutung der Parameter INDEXREC und DFTDBPATH in eigenen Worten. Welchen Wert besitzen sie? Verändern Sie den INDEXREC-Parameter und setzen Sie ihn danach auf den alten Wert zurück. Belegen Sie DFTDBPATH mit dem Namen eines von Ihnen in Ihrem Instanzenverzeichnis zu erzeugenden Unterverzeichnisses. Testen Sie die Wirkung des Parameters DFTDBPATH und setzen Sie ihn danach wieder zurück. b) Zeigen Sie die Kongurationsparameter Ihrer Datenbank ADMIN am Bildschirm an. Welche Bedeutung und Werte haben die Parameter DFT_EXTENT_SZ, DFT_PREFETCH_SZ, NEWLOGPATH, und Path to log files? Setzen Sie DFT_EXTENT_SZ auf 2 und verändern Sie temporär die Lokation der Log-Dateien. Weisen Sie jeweils die Wirksamkeit der gemachten Veränderungen nach. Setzen Sie danach Ihre Kongurationsparameter für die Instanz und die Datenbank ADMIN auf die Standardwerte zurück mit reset dbm cfg und reset db cfg for ADMIN! 2 Der Artikel bezieht sich auf eine ältere DB2-Version, die Table Spaces mit dynamischem Speicher nicht unterstützt. 3 Sie nden die Datei admin_db im Verzeichnis /../db2i00/bin/. 2

3 c) Katalogisieren Sie Ihre Instanz über TCP/IP (IPAdresse oder localhost) als Knoten LOOPBACK. Damit simulieren wir den Zugri auf eine DB2-Instanz auf einem anderen Rechner. Katalogisieren Sie Ihre Datenbank ADMIN über diesen (über das Netzwerk erreichbaren) Knoten und nennen Sie die neu-katalogisierte Datenbank REMOTE. Beachten Sie, dass Sie für das Kommunikationsprotokoll TCP/IP aktivieren 4 müssen, um sich erfolgreich zur Datenbank REMOTE verbinden zu können. Jeder Instanz wurde ein Port DB2_db2i?? zugewiesen (siehe /etc/services). Verwenden Sie ausschlieÿlich diesen Port in der Konguration Ihres Datenbankmanagers. d) Welches Ergebnis liefert nun die in Aufgabe 1a) gestellte Anfrage und woran erkennen Sie, welche Datenbank zu Ihrer Instanz gehört und welche nicht? e*) Zeigen Sie die Kongurationsparameter der Datenbank REMOTE am Bildschirm an. Welche Bedeutung haben die Parameter DFT_DEGREE und DFT_QUERYOPT? Ändern Sie die Parameter durch selbstgewählte, aber abweichende Werte. Welche Auswirkung hat die Änderung auf die Datenbank ADMIN und warum? Gilt dies auch für Änderungen von Kongurationsparametern des Datenbankmanagers? Setzen Sie mittels reset database configuration und reset database manager configuration die Kongurationen zurück. Entfernen sie anschlieÿend die katalogisierte Datenbank REMOTE und den Knoten LOOPBACK. Aufgabe 3 (Prozesse*) Der Befehl db2pd -edus dient dem Anzeigen von Prozessen und Threads der Instanz für den aktuellen Nutzer. Önen Sie für diese Aufgabe zwei Konsolenfenster C1 und C2 für Datenbankverbindungen sowie eine weitere Konsole C3 für das Anzeigen der Prozessinformationen. a) Stoppen Sie Ihre Instanz in C3 mittels db2stop force und starten Sie sie erneut. Benennen Sie die laufenden DB2-Prozesse. b) Verbinden Sie sich in C1 zur Datenbank ADMIN. Welche Prozesse sind mit dieser Datenbank verbunden? Erläutern Sie deren Aufgabe und verbinden Sie sich parallel in C2 mit ADMIN. Welche Prozesse werden gemeinsam genutzt? c) Verbinden Sie sich in C2 mit der Datenbank SAMPLE. Welche Prozesse werden nicht pro Verbindung, sondern pro Datenbank gestartet? Aufgabe 4 (Datenbankschema*) a) Bestimmen Sie Schemainformationen für die Datenbank ADMIN. Bitte geben Sie diese Informationen nicht für die Systemtabellen an, die in den Schemata SYSCAT, SYSSTAT und SYSIBM sowie allen weiteren Schemata, deren Namen mit SYS beginnen, zu nden sind. Auszugeben seien die Tabellen mit ihren Attributen und deren Datentypen. Von Interesse seien auÿerdem Primär- und Fremdschlüsseldenitionen, Trigger sowie implizit bzw. explizit angelegte Indizes. Weitergehende Aspekte wie User-dened Functions (UDF's), Stored Procedures,... sollen an dieser Stelle nicht betrachtet werden. Hinweis: Als Hilfsmittel können Sie beispielsweise das Tool db2look verwenden. b) Machen Sie sich mit dem Inhalt von ADMIN vertraut und erstellen Sie ein E/R-Diagramm für die Tabellen dieser Datenbank. Beachten Sie dabei insbesondere das geeignete Re-Engineering der Fremdschlüssel und nutzen Sie für die Kardinalitäten die 1:n-Notation. Grundlageninformationen zum Entity-Relationship-Modell sind bei den vertiefenden Materialien zur Veranstaltung auf der Lehrstuhlwebsite zu nden. c) Mit dem im Verzeichnis /../db2i00/bin/ abgelegten Programm showpic können Sie auf die in den BLOB-Spalten der Tabelle BLOB_DATA abgelegten Fotos zugreifen. Tun Sie das, mit dem ImageMagick-Kommando display können Sie sich die Bilder anschauen. 4 Nutzen Sie für die notwendige Konguration die Informationen des Abschnitts Kongurieren der TCP/IP- Kommunikation für eine DB2-Instanz im DB2 Information Center. 3

4 d) Durch welche Abfragen an die Datenbankkatalogtabellen wurden die Sichten SYSCAT.VIEWS und SYSCAT.TABLES des Katalogs implementiert? Aufgabe 5 (Tablespaces und Container) Analysieren Sie die physische Struktur der Datenbank ADMIN (in deren Ausgangszustand). Ermitteln Sie durch DB2-Befehle bzw. durch Anfragen an den Katalog die Antworten auf die folgenden Fragen. a) Aus welchen Tablespaces besteht die Datenbank ADMIN? Wie groÿ sind diese und wieviel Speicherplatz davon ist belegt? Welchen Typs sind die einzelnen Tablespaces, wie groÿ sind die zugehörigen Extents und Pages? b) Aus welchen Containern bestehen die einzelnen Tablespaces? Versuchen Sie die in a) für die Tablespaces gestellten Fragen analog für die Container zu beantworten. c) In welchen Tablespaces liegen die Katalogtabellen? d) In welchen Tablespaces liegen die eigentlichen Nutzertabellen? Wo liegen deren Indizes und LOB's? Ist die Antwort auf die zweite Frage überraschend? Warum? e) Wo liegen die aktiven Log-Dateien der ADMIN? f) Sind die CLOB's der Tabelle CLOB_DATA mit der im Schema (Tabellendenition) angegebenen maximalen Länge abgespeichert? Berechnen Sie die Gesamtgröÿe der gespeicherten BLOB's in Tabelle BLOB_DATA 5 sowie die dafür benötigten Seiten. Teil 2 Physischer Datenbankentwurf Vertiefende Informationen: Aufgabe 6: Informationen zum physischen Datenbankentwurf nden Sie in dem Abschnitt Considerations when choosing table spaces for your tables im DB2 Information Center, ergänzt durch den Abschnitt Comparison of SMS, DMS and automatic storage table spaces. Aufgabe 7: Der Abschnitt Database administration Data movement utilities and reference im DB2 Information Center bietet umfangreiche und weiterführende Informationen zum Versetzen von Daten. Aufgabe 6 (Konzept eines physischen Datenbankentwurfs) In der ersten Aufgabe des Komplexes Physischer Datenbankentwurf sollen Sie für eine Datenbank, deren Eigenschaften und Anforderungen im folgenden verbal beschrieben werden, eine geeignete physische Abbildung der Nutzerdaten (Katalog- und temporäre Daten sollen hier nicht betrachtet werden) in DB2 vorschlagen und begründen. Zur physischen Struktur gehören Angaben über zu erstellende Tablespaces (mit welchen Containern und für welche Daten, Verwaltungsform 6 ), die geeignete Festlegung von Seiten- und Extent-Gröÿen sowie der Anzahl der Extents für das Prefetching 7. Die zu betrachtende Datenbank enthält drei Tabellen (A, B und C). Die (zentrale) Tabelle B enthält sehr viele Tupel (> ) mit einer durchschnittlichen Länge von 80 Byte. Sie wird fortlaufend um neue Daten ergänzt und beim lesenden Zugri werden in einer Anfrage oftmals groÿe Tupelmengen abgerufen. Aufgrund der groÿen Datenmengen sind Leseanfragen auf B zeitkritisch. Die weitgehend unveränderlichen Tabellen A und C enthalten dagegen nur eine geringe Anzahl an Tupeln (< 100) mit einer durchschnittlichen Länge von 5000 Byte (nur Primärdaten). Zusätzlich enthalten die Tabellen A und C LOB-Daten in gröÿerem Umfang. 5 Nutzen Sie zur Berechnung die Funktion length(picture) und beachten Sie, dass eine 4 KB-Seite abzüglich Overhead nur Byte Nutzdaten aufnehmen kann. 6 Es sollen ausschlieÿlich DMS- und SMS-Tablespaces verwendet werden. Verzichten Sie entsprechend auf Table Spaces mit automatischer Speicherverwaltung. 7 Geben Sie die Gröÿe der Extents sowie die Extentanzahl für das Prefetching mit den Begrien klein, mittel oder groÿ an. 4

5 Während auf die Primärdaten häug zugegrien werden muss, werden die LOB-Daten nur sehr selten gebraucht. Darüber hinaus erfolgt der Lesezugri auf A und C sehr selektiv, d.h. Anfrageergebnisse enthalten nur sehr wenige Tupel. Für die Speicherung der physischen Granulate der Datenbank und ihrer Zusatzdaten stehen die folgenden Festplatten zur Verfügung: Platte Disk1 Disk2 Disk3 Disk4 Disk5 Geschwindigkeit langsam schnell schnell schnell sehr schnell Denken Sie an eine ausreichende Begründung Ihrer Entwurfsentscheidungen. Eine gute Lösung schöpft die vorhandenen Ressourcen (Platten) optimal aus, wobei zur Vereinfachung jeder Festplatte nur ein Container zugeordnet werden soll, welcher jeweils die komplette Platte belegt. Vergessen Sie nicht anzugeben, wo die Log-Dateien gespeichert werden sollen. Aufgabe 7 (Transformation der ADMIN-Datenbank) In der zweiten Aufgabe des Komplexes Physischer Datenbankentwurf soll die Beispieldatenbank ADMIN in ihrer physischen Struktur transformiert werden. Gründe für die Durchführung einer solchen Transformation können sowohl in Speicherplatz- als auch in Performance-Motiven liegen. Bei wachsenden Datenvolumina müssen z.b. neue Platten an die Datenbank angeschlossen werden können. Stellt man fest, dass gewisse Daten häug benötigt werden, so kann es sinnvoll sein, diese von langsameren Platten auf schnellere zu verlagern. Umgekehrt kann es nützlich sein, selten benötigte Daten auf langsamere Platten umzuspeichern, damit auf den schnelleren Platten Platz für häuger gebrauchte Daten frei wird etc. Beim Wechsel auf neue Hardware ist die Notwendigkeit einer solchen Transformation oensichtlich. Manchmal muss man sogar bei einem DBM-Release-Wechsel die zugrundeliegenden Datenbanken physisch transformieren. Bei Datenbanken in Gröÿenordnungen von Giga- und Terabytes ist dies naturgemäÿ sehr aufwendig. In der Aufgabe wollen wir von den konkreten Gröÿenverhältnissen der Tabellen sowie eventuell vorhandener Workload-Anforderungen abstrahieren. Ziel ist es, fünf zusätzliche Platten einzubeziehen, auf denen sich die Nutzerdaten nach der Transformation benden sollen. Diese Platten sollen aus naheliegenden technischen Gründen durch Unterverzeichnisse ( /disk1,..., /disk5) Ihres Instanzenverzeichnisses simuliert werden. Die angestrebte neue Datenverteilung hat folgendes Aussehen: Die primären Daten (d.h. ohne LOB's) aller Tabellen benden sich im Tablespace PRIMTBS, welcher die beiden Platten disk1 und disk2 umfassen soll. Die LOB-Daten aller Tabellen liegen im Tablespace LOBTBS, welcher auf disk3 plaziert sein soll. Die Indizes sämtlicher Tabellen werden im Tablespace INDTBS auf disk4 gespeichert. Die Logles sollen auf disk5 ihren Platz nden. Die Tablespaces für Katalog- und temporäre Daten sollen nicht verändert werden. Bei der Durchführung der Transformation sollen die folgenden zusätzlichen Anforderungen beachtet werden: Verwendung einer minimalen Anzahl von Containern. Jeder Tablespace soll aus rein didaktischen Gründen mit minimaler Gröÿe erzeugt werden, d.h. so klein dass gerade noch alle Daten darin Platz nden. Bitte beachten Sie, dass die beiden Parameter EXTENTSIZE und PAGESIZE einen Einuss auf Ihre Berechnungen haben können! 5

6 Während des Transformationsprozesses soll möglichst wenig zusätzlicher Speicherplatz verbraucht werden. Bearbeiten Sie bei der Durchführung der Transformation die folgenden Teilaufgaben: a) Reorganisieren Sie alle Nutzertabellen und die zugehörigen Indizes durch die Verwendung des DB2-Kommandos REORG. Aktualisieren Sie anschlieÿend die Statistiken aller Spalten und Indizes der Nutzertabellen durch das DB2-Kommando RUNSTATS. b) Schätzen Sie mittels der im Datenbankkatalog hinterlegten Statistiken zu belegten Seiten den Nettoumfang der Primärdaten (syscat.tables) und Indizes (syscat.indexes). Ermitteln Sie im zweiten Schritt anhand der im Anhang angegebenen Faustformel 8 zur Festlegung von Tablespace-Gröÿen die Bruttogröÿe (d.h. mit Berücksichtigung des Struktur-Overheads) des jeweiligen Tablespace, so dass die entsprechenden Nettodatenmengen gerade noch Platz im Tablespace nden müssten. Nutzen Sie für die Abschätzung eine EXTENTSIZE von 2 Seiten und eine PAGESIZE von 4KB. c*) Schätzen Sie den Netto-Umfang der im jeweiligen Tablespace abzulegenden Daten nun anhand der im Anhang angegebenen Überschlagsformeln für Primär-, Index- und LOB-Daten. Im Gegensatz zum Neuanlegen einer Datenbank müssen Sie die dort vorkommende Gröÿe AverageColumnSize (für jede Spalte) nicht intuitiv oder nach einer aufwendigen Analyse von repräsentativen Daten festlegen, sondern können diese einfach anhand der existierenden Daten oder Statistiken berechnen. Ermitteln Sie analog zur Aufgabe b) anhand der im Anhang angegebenen Faustformel zur Festlegung von Tablespace-Gröÿen die Bruttogröÿe gemäÿ dem nun berechneten Netto-Umfang. d) Führen Sie die eigentliche Transformation bei Verwendung der Schätzungen aus Aufgabe c), alternativ aus Aufgabe b), durch. Planen Sie dabei Ihr Vorgehen in Bezug auf die oben geforderte Speicherökonomie. Zum Datentransport können Sie beispielsweise die DB2-Tools export und import verwenden. Aufgabe 8 (Überprüfung der Transformation*) Überprüfen Sie durch Anfragen bzw. Kommandos: a) Überprüfen Sie die Inhalte der Tabellen durch verschiedene Abfragen bzw. mittels showpic! b) Kontrollieren Sie die nach der Transformation vorliegende physische Struktur, indem Sie noch einmal die Fragen a) bis e) aus Aufgabe 5 (Teil 1) beantworten. c) Wurden alle Indizes angelegt und geschah dies im Tablespace INDTBS? d) Die LOB's welcher Tabellen liegen im Tablespace LOBTBS? Haben diese Tabellen auch LOB- Attribute? e) Vergleichen Sie für jeden der neuen Tablespaces den zur Speicherung der jeweiligen Daten berechneten mit dem nach erfolgreicher Transformation wirklich belegten Speicherplatz. Gibt es Diskrepanzen? Wenn ja, haben Sie eine Erklärung dafür? Anhang Im Folgenden sind die Überschlagsformeln zusammengefasst, die Sie zur Bearbeitung der gestellten Aufgaben benötigen. (Quelle ist der Abschnitt: Designing Tables im DB2 Information Center.) Speicherplatz eines Datenobjekts (Data Object) Datenobjekte, welche in Tablespaces abgespeichert werden, sind jeweils pro Tabelle die Primärdaten (ohne LOBs), die LOB-Daten und Index-Daten. 8 Die im ersten Schritt berechneten Nettogröÿen sowie der in Aufgabe 5f) ermittelte Seitenbedarf der BLOBs entsprechen der NettoObjectSize. Vergessen Sie in Ihrer Rechnung nicht die Tabelle CLOB_DATA. 6

7 Primärdaten (User Table Data) Für die Primärdaten gilt: NumberOfPages = NumberOfRecords 1.1 (1) RecordsPerPage wobei gilt: UsableDataSize RecordsPerPage = AverageRowSize + 10 Der Wert UsableDataSize ergibt sich aus der jeweiligen PageSize, abzüglich etwas Overhead, d.h für 4 KB, für 8 KB und KB für 16 KB sowie für 32 KB groÿe Seiten. Die durchschnittliche Länge einer Zeile in Bytes ist: AverageRowSize = AverageColumnSize NumberOfColumns Die für die Bestimmung der mittleren Spaltenlängen zu mittelnden physischen Spaltenlängen (Stichwort byte counts) nden Sie für die verwendeten Datentypen in der SQL Reference bei der Beschreibung des CREATE TABLE-Statements. Berücksichtigen Sie Spalten die SQL NULL enthalten können, und beachten Sie, dass bei den Primärdaten anstelle der LOBs sogenannte LOB-Descriptoren (mit von der maximalen LOB-Gröÿe abhängiger Länge) abgespeichert werden. LOB-Daten (Large Object Data) Bei der Speicherung von LOB-Daten sind zwei Tabellenobjekte zu berücksichtigen: LOB Data Objects und LOB Allocation Objects. Als grobe Näherung können Sie folgene Formel für die Gröÿenabschätzung verwenden: LOBDataObjSize = AverageLOBSize NumberOfRows 1.5 [Bytes] (2) LOBAllObjSize = LOBDataObjSize + 64 GB U sabledatasize LOBDataObjSize 8 MB [Pages] (3) Index-Daten (Index Data) Für einen Tabellenindex gilt: (AverageKeySize + 8) NumberOfRows 2 IndexDataSize = U sabledatasize [Pages] (4) Speicherplatz eines Tablespace Für einen Database Managed Tablespace (DMS) gilt (mit ExtentSize in #Pages): TBSSize = NumberOfContainers (eine Seite Overhead pro Container) + 3 ExtentSize (drei Extents Overhead pro Tablespace) + NumberOfObjects ExtentSize (Overhead für Extent-Map pro DataObject) + NettoObjectSize Beachten Sie bitte, dass auch eine leere Tabelle für jedes ihrer Datenobjekte (Primärdaten, Indizes, LOB Daten), inklusive Extent-Map, 2 Extents benötigt. (5) 7