4. Tablespaces und Pufferpool. Datenbankadministration

Transkript

1 4. Tablespaces und Pufferpool Datenbankadministration

2 Architektur von Datenbanksystemen ÜBERSICHT DER FUNKTIONEN Puffer Tablespaces 2

3 Tablespaces

4 CREATE DATABASE revisited CREATE DATABASE <NAME> Initialisieren einer Hierarchie von Verzeichnissen und Dateien Anlegen von Verwaltungs-, Monitoring und Recoverydateien (Möglicherweise) wird ein Bufferpool angelegt Drei Tablespaces werden angelegt Weitere Konfigurationen 4

5 CREATE DATABASE revisited (2) CREATE DATABASE TEST /home/db2ins49/db2ins49/node0000/test. ---T #C CAT ---T #C TMP -----C TMP -----#SQLTAG.NAM ---T #C LRG /home/db2ins49/db2ins49/node0000/sql #db2rhist.asc #db2rhist.bak #SQLBP.1 #SQLBP.2 #SQLDBCON #SQLDBCONF #SQLINSLK #SQLOGCTL.LFH.1 #SQLOGCTL.LFH.2 #SQLOGDIR #SQLOGMIR.LFH #SQLSGF.1 #SQLSGF.2 #SQLSPCS.1 #SQLSPCS.2 #SQLTMPLK ---db2event -----db2detaildeadlock -----# evt -----#db2event.ctl ---SQLOGDIR ---#S LOG ---#S LOG ---#S LOG 5

6 DB2 Tabellenbereiche TABELLENBEREICH (TABLE SPACE) Logische Speicherstruktur/Abstraktionsebene - enthält Datenbankobjekte, z.b. Tabellen, Indizes, LOB- und LONG-Daten besteht aus Behältern (container) - Verzeichnis - Datei - Device (logisches Gerät) durch Betriebssystem oder DBMS verwaltet - Verfügbarkeit der Container abhängig von Verwaltungsstrategie können explizit bei Erstellung von Datenbankobjekten angegeben werden CREATE TABLE <name> ( ) [IN <tablespace_name>] [INDEX IN <tablespace_name>] [LONG IN <tablespace_name>] nur wenn der primäre Tablespace DMS ist und nur DMS Tablespaces für LONG IN GENERELLER EINSTIEG INS THEMA 6

7 DB2 Tabellenbereiche (2) Daten werden Round-Robin geschrieben. Eine Tabelle ist einem Tabellenbereich zugeordnet (Indizes und LONG/LOB eventuell in (je einem) weiteren Tabellenbereich). Extent size: Anzahl der Seiten die in einen Container geschrieben werden bevor zum nächsten gewechselt wird Einem Tabellenbereich sind ein bis mehrere Container zugeordnet 7

8 DB2 Tabellenbereiche (3) KLASSIFIKATION DER TABELLENBEREICHE Katalogtabellenbereich (Catalog table space) - enthält Systemkatalogtabellen und sichten - ist immer erforderlich, aber existiert nur einmal pro Datenbank - kann nicht gelöscht werden Reguläre Tabellenbereiche (Regular table space) - speichert sämtliche permanenten Nutzerdaten Tabellen- und Indexdaten kann auch LOB- und LONG-Daten enthalten - kann keine temporären Tabellen enthalten - ein regulärer oder ein Tabellenbereich für lange Objektdaten notwendig Temporärer Systemtabellenbereich (System temporary table space) - speichert interne temporäre Daten, z.b. beim Sortieren, Reorganisieren oder bei Verbundoperationen - ist notwendig 8

9 DB2 Tabellenbereiche (4) KLASSIFIKATION DER TABELLENBEREICHE (2) Tabellenbereich für lange Objektdaten (Large table space) - speichert sämtliche permanenten Nutzerdaten - primär für das Speichern von LOB- und LONG-Daten ausgelegt Tabellen können größer werden als bei regulären Tabellenbereichen (z.b. 64 GB regular vs GB large) - es können mehr als 255 Zeilen pro Seite gespeichert werden - Indizes werden größer! - wenn nicht definiert, wird ein regulärer Tabellenbereich genutzt - muss durch Datenbank verwaltet sein (DMS) somit nur bestimmte Container nutzbar Temporäre Benutzertabellenbereiche (User temporary table space) - speichert temporäre Tabellen (DECLARE GLOBAL TEMPORARY TABLE) z.b. Zwischenergebnisse von Stored Procedures - sind optional 9

10 DB2 Tabellenbereiche (5) JEDE DATENBANK MUSS MINDESTENS 3 TABELLENBEREICHE ENTHALTEN einen Katalogtabellenbereich - default: SYSCATSPACE einen oder mehrere Tabellenbereiche für persistente Nutzerdaten - default: USERSPACE1 einen oder mehrere temporäre Systemtabellenbereiche - default: TEMPSPACE1 werden beim Erzeugen einer Datenbank automatisch angelegt, können aber auch explizit spezifiziert werden - CREATE DB <name> [CATALOG TABLESPACE ( )] [USER TABLESPACE ( )] [TEMPORARY TABLESPACE ( )] Link zur Referenz: DB2 Information Center - CREATE DATABASE 10

11 Tabellenbereichsverwaltung

12 SMS Tabellenbereich SYSTEM MANAGED SPACE (SMS) besteht aus einem oder mehreren System-Containern - vom Betriebssystem verwaltet - wächst und schrumpft dynamisch - Entspricht Verzeichnis im Dateisystem Daten transparent in Dateien im Verzeichnis Tabellen an Tabellenbereich gebunden Speichernutzung gleichmäßig auf alle Container verteilt - Tabellenbereich ist voll, sobald einer der Container voll ist kein nachträgliches Hinzufügen von Containern möglich Prefetching und Caching des Dateisystems nutzbar zur Ablage von Daten, deren Größe nicht von vornherein abgeschätzt werden kann (z.b. System temporary) kein Verwaltungsaufwand 12

13 DMS Tabellenbereich DATABASE MANAGED SPACE (DMS) besteht aus einem oder mehreren Datenbank-Containern - von Datenbank verwaltet - entspricht Datei oder Gerät - Speicherplatz wird vorallokiert (feste Größe!) Effiziente Tupeladressierung möglich Tabellen können sich über mehrere Tabellenbereiche erstrecken (Table partitioning) Speichernutzung anfangs gleichmäßig auf alle Container verteilt - auffüllen größerer Container wenn kleinere voll Vergrößerung bzw. Verkleinerung und Hinzufügen bzw. Löschen von Containern möglich/notwendig (ALTER TABLESPACE) - können auch automatisch vom DBMS vergrößert werden (AUTORESIZE YES) - Standardmäßig deaktiviert hoher Verwaltungaufwand 13

14 SMS versus DMS SMS Speicherplatz durch Betriebssystem allokiert und verwaltet Speicherplatz wird bei Bedarf allokiert DMS Speicherplatz durch DB2 allokiert und verwaltet Speicherplatz wird vorallokiert nur Verzeichniscontainer nutzbar nur Datei- und Gerätecontainer nutzbar zusätzliche Container können nicht hinzugefügt werden reguläre und große Daten im selben Tabellenbereich verwaltet leichter zu erstellen und verwalten zusätzliche Container können hinzugefügt werden (ALTER TABLESPACE) reguläre und große Daten können in unterschiedlichen Tabellenbereichen verwaltet werden mehr Verwaltungsaufwand, aber bessere Kontrolle 14

15 Automatic Managed Storage AUTOMATIC MANAGED STORAGE Entscheidung, ob SMS oder DMS durch DB2-Datenbankmanager (seit Version 8.2.2) Nicht-/Nutzung wird beim Anlegen der Datenbank definiert AUTOMATIC STORAGE wenn nicht angegeben, seit 9.5 standardmäßig aktiviert TYP DESTABELLENBEREICHS BESTIMMT VERWALTUNGSSTRATEGIE CATALOG, REGULAR oder LARGE à DMS (USER SYSTEM) TEMPORARY à SMS AUTOMATISCHES HINZUFÜGEN VON NEUEN CONTAINERN Angabe eines oder mehrerer Speicherpfade - eventuell auch expliziter Datenbankpfad Speicherpfad Ort der Erstellung der Tabellenbereiche - Standard: DFTDBPATH (abfragbar per GET DBM CFG) Datenbankpfad Ort für Monitoring- und Konfigurationsdateien 15

16 DB2 Verzeichnishierarchie ANLEGEN EINERAUTOMATIC STORAGE DATENBANK Syntax - CREATE DATABASE [ON <rootpath> [DBPATH ON <path>]] Datenbankpfad - <rootpath>/<instancename>/<nodename> - /home/db2insxy/db2insxy/node0000 Pro Datenbank werden dort standardmäßig zwei Verzeichnisse angelegt - <databasename> TPCH Speicherpfad - SQL0000N SQL00001 Datenbankpfad ON Klausel kann mehrere Pfade enthalten - der erste wird als DBPATH genutzt, falls DBPATH ON nicht gegeben ist In <databasename>, ein Verzeichnis pro Tablespace - T DMS/Datei: C CAT - T SMS/Verzeichnis: C TMP - T DMS/Datei: C LRG 16

17 Informationen über Tabellenbereiche ANZEIGE ALLER TABELLENBEREICHE EINER DATENBANK LIST TABLESPACES [SHOW DETAIL] Tablespace ID = 0 Name = SYSCATSPACE Type = Database managed space Contents = All permanent data. Regular table space. ANZEIGE DER CONTAINER DIE EINEM TABELLENBEREICH ZUGEORDNET SIND LIST TABLESPACE CONTAINERS FOR <tabspace-id> [SHOW DETAIL] Container ID = 0 Name Type = /NODE0000/TPCH/T /C CAT = File 17

18 Datenbank-Design mit Tabellenbereichen GRÜNDE FÜR VERSCHIEDENE TABELLENBEREICHE Berücksichtigung unterschiedlicher Eigenschaften von regulären und Langfeld- bzw. LOB-Daten - z.b.: LOB besser in eigene Tabellenbereiche auslagern Container möglicherweise auf günstigeren Medien anlegen unterschiedliche Eigenschaften von SMS, DMS und Automatic Storage - erhöhten Administrationsaufwand auf kritische Tabellen beschränken Performanz- und Speicheroptimierung durch verschiedene Seitengrößen, EXTENTSIZE-Werte und Pufferpools - z.b.: eigenen Pufferpool für Tabellenbereich mit häufig angefragten Tabellen - z.b.: häufig gescannte Tabellen in eigenen Tabellenbereich mit großer Seitengröße, Extentsize und Prefetchsize und umgekehrt - z.b.: Tabellen mit kleinen Tupeln in Tabellenbereich mit kleiner Seitengröße - z.b.: individuelles Backup/Restore einzelner Tabellenbereiche (z.b. mit häufig geänderten Daten) anstatt der gesamten Datenbank - z.b.: Parallelität durch Verwendung verschiedener physischer Geräte 18

19 Spezifikation von Tabellenbereichen SPEZIFIKATION VON TABELLENBEREICHEN Beispiele mit Automatic Storage CREATE TABLESPACE USERSPACE3 INITIALSIZE 100 M MAXSIZE 1 G CREATE TABLESPACE USERSPACE4 INCREASESIZE 10 PERCENT MAXSIZE 2 G ERFORDERLICHE RECHTE: SYSCTRL, SYSADM 19

20 Erstellung SMS/DMS-Tabellenbereiche SMS-CONTAINER system-container ::= CREATE TABLESPACE <name> MANAGED BY SYSTEM USING ( <dir> ) DMS-CONTAINER database-container ::= container-clause ::= CREATE TABLESPACE <name> MANAGED BY DATABASE USING ([FILE DEVICE] <file> <numofpages>, ) 20

21 Tabellenbereichsparameter PARAMETER Seitengröße (PAGESIZE) - bedingt maximale Größe eines Tupels bzw. Anzahl Tupel pro Seite - Festlegung gilt für alle Tabellen im Tabellenbereich - geringe Seitengröße bei wahlfreiem Lesen und Schreiben weniger Speicher durch unerwünschte Tupel verschwenden - große Seitengröße bei Lesen vieler aufeinander folgender Tupel Anzahl E/A-Anforderungen minimieren Speicherbereichsgröße (EXTENTSIZE) - Anzahl Seiten, die in einen Behälter geschrieben werden, bevor Daten in den nächsten Behälter geschrieben werden - Auswirkung: Speicherauslastung, Leseperformanz bei Block-I/O Vorablesegröße (PREFETCHSIZE) - Anzahl Seiten die vorab angefordert werden (Guideline: Vielfaches von EXTENTSIZE, Anzahl der Container und Anzahl der physischen Devices unter den Containern) - Auswirkung: Leseperformanz bei Scans Mehr Infos: DB2 Information Center - Designing table spaces 21

22 Implikationen der Seitengröße Seitengröße Max. Zeilengröße Max. Spalten Max. Tupel pro Seite Max. Tabellenbereichsgröße regulär large regulär large 4kB 4005 B GB 2048 GB 8kB 8101 B GB 4096 GB 16kb B GB 8192 GB 32kB B GB GB w.sql.ref.doc/doc/r html (Table 7) 22

23 Pufferpools

24 DB2 Pufferpool PUFFERPOOL (BUFFERPOOL) Ausführungsort für Lese- und Schreiboperationen (Cache) wichtiger Einzelbereich bei der Optimierung jedem Tabellenbereich muss ein Pufferpool zugewiesen werden Seitengröße von Pufferpool und Tabellenbereich müssen gleich sein keine Pufferung von LOB- und Langfelddaten default: IBMDEFAULTBP PARAMETER Seitengröße (PAGESIZE) - siehe Tabellenbereiche Größe (SIZE) - Anzahl Seiten à Größe des Pufferpools 24

25 Spezifikation von Pufferpools SPEZIFIKATION VON PUFFERPOOLS ERFORDERLICHE RECHTE: SYSCTRL, SYSADM 25

26 DB2 Self-Tuning Memory SELF-TUNING MEMORY seit Version 9 verteilt verfügbaren Speicher zwischen verschiedenen Prozessen (Sperrverwaltung, Anfrageverarbeitung, usw.) der Datenbank reagiert auf Änderungen des Anfrageverhaltens passt Speicherkonfigurationsparameter und Größe des Pufferpools an, um Performanz zu optimieren betroffene Ressourcen - Pufferpools (ALTER / CREATE BUFFERPOOL) - Package Cache (PCKCACHESZ) - Speicher für Sperren (LOCKLIST) - Sortierspeicher (SORTHEAP, SHEAPTHRES_SHR) - Gesamtspeicher der Datenbank (DATABASE_MEMORY) PARAMETER GET DB CFG [ grep SELF_TUNING_MEM ] (default: ON) 26

27 Zusammenfassung TABELLENBEREICHE Logische Abstraktion zwischen Tabellen und physischer Speicherung Fünf Klassen von Tabellenbereichen Verwaltung per SMS, DMS oder Automatic Storage PUFFERPOOLS Cache der jedem Tabellenbereich zugewiesen sein muss WEITERFÜHRENDE LITERATUR Automatic storage tablespaces Types of tablespaces Designing table spaces Designing buffer pools 27