Architektur moderner Datenbankbetriebssysteme

Architektur moderner Datenbanksysteme
•
Datenbank-Architektur
•
•
•
Software-Architektur
Datenbank-Prozesse
Data Dictionary
DBS1 2004
D B-Architektur
Seite 1
Klöditz
Hochschule Anhalt (FH)
Oracle-Datenbank-Architektur
Physische Struktur
•
beliebig viele DB-Files auf beliebige Plattenlaufwerke verteilt;
enthalten alle DB-Objekte wie Datenstrukturen, prozedurale
Objekte, Zugriffsstrukturen, Daten
•
mindestens zwei REDO-Log-Files; protokollieren und speichern
alle Datenänderungen; dienen zur Wiederherstellung der
Datenbank bei Systemausfällen
mindestens zwei Control-Files; enthalten die Grundstrukturen
und Grundinformationen über eine Oracle-Datenbank (Zeitpunkt
der Erstellung, Namen aller DB-Files, Namen aller REDO-Files
und deren Sequenznummern, Zeitpunkt des letzten Checkpoints
und zugehörige REDO-Files, ...)
•
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 2
Oracle-Datenbank-Architektur
Physische Struktur
F6
F1
F2
F4
F3
F5
Datenbank-Files
Online-REDO-Log-Files
Control-Files
DBS1 2004
D B-Architektur
Seite 3
Klöditz
Hochschule Anhalt (FH)
Oracle-Datenbank-Architektur
Logische Struktur der DB-Files
•
DB-Files werden Tablespaces zugeordnet
•
je Datenbank existiert mind. ein Tablespace (Tablespace
SYSTEM), der beim Installieren mit der Datenbank eingerichtet
wird, weitere können angelegt werden
alle DB -Objekte werden einem Tablespace zugeordnet
Einrichtung nur mit DBA-Rechten möglich
•
•
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 4
Oracle-Datenbank-Architektur
Logische Struktur der DB-Files
F4
Physische Sicht der DB-Files
F5
F6
F3
F1
F2
Logische Sicht
Tablespace SYSTEM
Tablespace A
F2
Tablespace B
F6
F1
F4
F3
F5
DBS1 2004
D B-Architektur
Seite 5
Klöditz
Hochschule Anhalt (FH)
Oracle-Datenbank einrichten
•
löscht alle Daten in den angegebenen Datenbankfiles, um sie
für die neue Nutzung vorzubereiten; für eine existierende
Datenbank mit Datenverlust verbunden
•
Einrichtung nur mit DBA-Rechten möglich
create database [database]
[controlfile reuse]
[logfile filespec [, filespec] ...]
[maxlogfiles integer]
[datafile filespec [, filespec] ...]
[maxdatafiles integer]
[maxinstances integer]
[archivelog | noarchivelog]
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 6
Oracle-Datenbank einrichten
database
filespec
size integer [k|m]
reuse
controlfile reuse
maxinstances
exclusive
•
Name der Datenbank
Spezifikation eines Datenbankfiles der Form
‘filename’ [size integer [k|m]] [reuse]
Größe der Datenbank in K- bzw. MByte
spezifiziert, ob exist. Files wiederbenutzt
(überschrieben) werden sollen
exist. Control-Files werden überschrieben
Anzahl Instanzen, die gleichzeitig auf die
Datenbank zugreifen können (1-255)
nur eine Instanz kann zugreifen
Änderungen einzelner Einstellungen mit alter database möglich
DBS1 2004
D B-Architektur
Seite 7
Klöditz
Hochschule Anhalt (FH)
Oracle-Tablespace einrichten
create tablespace tablespace
datafile filespec [, filespec] ...
[default storage storage]
[online | offline]
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 8
Oracle-Tablespace einrichten
tablespace
filespec
size integer [k|m]]
reuse
storage
online | offline
•
Name des Tablespace
Spezifikation eines Files, das den
Tablespace enthält, in der Form
‘filename’ [size integer [k|m]] [reuse]
Größe der Datenbank in K- bzw. MByte
spezifiziert, ob exist. Files wiederbenutzt
(überschrieben) werden sollen
Standard-Parameter für alle im Tablespace
eingerichteten Objekte, z.B. (initial
10k next 50k minextents 1
maxextents 999 pctincrease 10)
macht den Tablespace unmittelbar zugreifbar
Änderungen möglich mit alter tablespace, drop tablespace, ...
DBS1 2004
D B-Architektur
Seite 9
Klöditz
Hochschule Anhalt (FH)
Oracle-Tablespace-Struktur
•
Objekttypen bzw. Segmentarten in einem Tablespace:
–
–
–
–
•
•
Tabellen (Datensegmente)
Indices (Indexsegmente)
Rollback-Segmente
temporäre Segmente
je Tabelle, Index, Rollback-Segment genau ein Segment im
betr. Tablespace; temporäre Segmente werden von Oracle
angelegt
Zuordnung zum Tablespace hängt ab von
– Tablespace des Objekt-Eigentümers
– Eigentümer Optionen
– Optionen des create-Befehls für das Objekt
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 10
Oracle-Tablespace-Struktur
Datenbank-Files
D
create table
create index
I
create
rollback segment
R
wird vom Oracle-DBMS
bei Bedarf erzeugt
(temporär)
T
DBS1 2004
D B-Architektur
Seite 11
Klöditz
Hochschule Anhalt (FH)
Oracle-Segment-Ausprägung
•
Segment besteht aus extents
(= Speicherbereiche bestimmbarer Größe)
•
Unterscheidung zwischen Anfangsextent (initial extent)
und Folgeextents (next)
Folgeextents können zusätzlich mit einem Wachstumsfaktor
versehen werden (pctincrease)
Extent enthält Oracle-Datenblöcke von meist 2 Kbyte
Angabe der Speicherungsparameter bei create / alter u.a. für
•
•
•
–
–
–
–
tablespace
table
index
rollback segment
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 12
Oracle-Segment-Ausprägung
•
Beispiel:
storage (
initial
next
minextents
maxextents
pctincrease
freelist
20 MB,
10 MB,
3,
80,
15,
3
)
•
Kontrolle der Tablespaces und der Tables
durch view auf das Data-Dictionary:
select * from user_tablespaces;
select * from user_tables;
DBS1 2004
D B-Architektur
Seite 13
Klöditz
Hochschule Anhalt (FH)
Oracle-Datenbank-Blockstruktur
•
kleinste Einheiten der Datenbank sind Blöcke; werden in den
Extents der Segmente gespeichert
•
Konfiguration der Datenblöcke über pctfree, pctused, initrans,
maxtrans
DB-BlockKopf
Freibereich für
sich vergrößernde
Datensätze
pctfree
DB-Block
Insert-Bereich
(Schlupf)
minimaler
Füllgrad
pctused
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 14
Oracle-Datenbank-Blockstruktur
•
DB-Block-Kopf enthält Verwaltungsinformationen
(row directory, transaction directory)
•
Datenbereich in pctfree und pctused geteilt;
wichtig wegen varchar2-Daten (pctfree) und möglichst
gleichmäßigem Füllungsgrad aller Blöcke (pctused)
DBS1 2004
D B-Architektur
Seite 15
Klöditz
Hochschule Anhalt (FH)
Oracle-Datensatz-Struktur
•
kleinste logische Datenbankeinheit; besteht aus Datensatz-Kopf
und Datensatz-Rumpf
•
•
Datensatz-Kopf: min. 3, max. 5 Bytes
Datensatz-Rumpf: Daten gemäß create table-Anweisung
einschl. der Spaltenlänge, jedoch nicht zwingend in der dort
angegebenen Reihenfolge (LONG und LONG ROW immer am
Ende)
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 16
Oracle-Datensatz-Struktur
Spaltenlänge
1 oder 3 Byte
Daten der Spalte
variabel (VARCHAR2) Spaltenlänge
fest (CHAR)
1 oder 3 Byte
Datensatz-Kopf
Anzahl der Spalten
1 Byte
Datensatz-Kopf
2 Bytes
Daten der Spalte
variabel (VARCHAR2)
fest (CHAR)
Daten der einzelnen Spalten
Kettadresse für Sätze
> Blockgröße (Byte)
Cluster-Schlüssel
(optional) 1 Byte
DBS1 2004
D B-Architektur
Seite 17
Klöditz
Hochschule Anhalt (FH)
Oracle-Datenbank-Architektur
ER-Diagramm
Tablespace
ORACLEDatenbank
Klöditz
Hochschule Anhalt (FH)
File
Segment
Data
Tabelle
Index
Index
Rollback
Extent
temporär
DB-Block
DBS1 2004
D B-Architektur
Seite 18
Oracle-Datenbank-Architektur
Zusammenfassung
•
Views auf das Data Dictionary:
dba_data_files
dba_tablespaces
dba_freespaces
dba_quota
user_extents
(all_extents)
(dba_extents)
user_tables
zeigt alle DB-Files und deren Status
zeigt alle Tablespaces und deren Status
zeigt den freien Platz innerhalb der
Tablespaces
zeigt die Tablespace-Quotas aller Benutzer
zeigt die Extents aller Tabellen und Indices
eines Benutzers (bzw. aller Tabellen / Indices),
auf die Benutzer Zugriff hat, bzw. der
gesamten Datenbank
zeigt alle Tabellen eines Benutzers
DBS1 2004
D B-Architektur
Seite 19
Klöditz
Hochschule Anhalt (FH)
Oracle-Software-Architektur
Anwendungsprozesse
ORACLE-Datenbankbetriebssystem
ORACLE-Datenbank
DBWR
DBC
A
C
H
E
LGWR
ARCH
SMON
PMON
CHKP
Shared und Dedicated
ORACLE-Server-Prozesse
Klöditz
Hochschule Anhalt (FH)
ORACLE-Instanz mit DB-Cache (SGA)
und Hintergrundprozessen
DBS1 2004
D B-Architektur
Seite 20
Oracle-Software-Architektur
•
Datenbanksystem besteht aus
– ORACLE-Instanz und
– mehreren zu dieser gehörenden Server-Prozessen
•
ORACLE-Instanz besteht aus
– Datenbank-Cache (Shared Global Area SGA) und
– einer Reihe von Hintergrundprozessen
•
ORACLE-Server-Prozesse (i.d.R. mehrere gleichzeitig aktiv)
übernehmen z.B.
–
–
–
–
Parsen von SQL-Befehlen,
Ausführen von SQL-Befehlen,
Lesen von DB-Blöcken aus DB-Files in den DB-Cache,
...
DBS1 2004
D B-Architektur
Seite 21
Klöditz
Hochschule Anhalt (FH)
Oracle-Prozess-Struktur
ORACLE -Datenbank -Server
DB-Cache
R
E
D
O
DB-Block Puffer
1
4
DBWR
1
2
3
LGWR
4
PMON
Shared
SQL -Pool
3
4
SMON
2
ARCH
4
5
5
4'
Datenbank-Files
Klöditz
Hochschule Anhalt (FH)
Redo-Log -Files
archivierte
Redo-Log -Files
DBS1 2004
D B-Architektur
Seite 22
Oracle-Prozesse
Database-Write-Prozess (DBWR)
•
•
schreibt im DB-Cache geänderte DB-Blöcke auf die DB-Files
zurück
wird ausgelöst, wenn
– alle DB-Blöcke im DB-Cache belegt sind und Speicherplatz im DBCache benötigt wird (Blöcke, die am wenigsten benutzt werden,
werden zuerst zurückgeschrieben)
– Anzahl der modifizierten Blöcke im Cache zu groß ist
– er zu lange durch kein externes Ereignis aktiviert wurde (DBWRTimeout etwa alle 3 s)
– ein Checkpoint erreicht wurde (alle Änderungen werden zurückgeschrieben, File-Header von DB-Files, Control-Files und RedoLog-Files werden aktualisiert; DB befindet sich in definiertem
Zustand)
•
bei Aktivierung stets Synchronisation mit dem LGWR-Prozess
nötig
DBS1 2004
D B-Architektur
Seite 23
Klöditz
Hochschule Anhalt (FH)
Oracle-Prozesse
Redo-Log-Writer-Prozess (LGWR)
•
Rückschreiben von Änderungen erfolgt in ORACLE nicht
synchron mit commit, sondern “irgendwann“ asynchron
•
DB-Änderungen werden deshalb zusätzlich im Redo-Log-Puffer
protokolliert (alte + neue Werte)
LGWR schreibt Redo-Log-Puffer auf das Redo-Log-File, wenn
•
– Redo-Log-Puffer zu 80% gefüllt ist
– ein Benutzerprozess ein Transaktionsende signalisiert
– der DBWR-Prozess einen Schreibvorgang signalisiert (LGWR
schreibt vorher)
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 24
Oracle-Prozesse
Redo-Log-Writer-Prozess (LGWR)
•
bei Transaktionsende (durch commit ausgelöst) wird dem
Benutzerprozess nach Abschluss des Schreibvorganges eine
commit-Ende-Meldung übermittelt, die gewährleistet,dass
– alle abgeschlossenen Transaktionen im Redo-Log-File permanent
gemacht sind (Sicherheit)
– alle modifizierten DB-Blöcke möglichst lange im DB-Cache im
Hauptspeicher bleiben können (Performance)
– alle Transaktionen zum Transaktionsende (commit) sehr schnell die
commit-Ende-Bestätigung erhalten, da max. ein Redo-Log-Puffer
auf die Platte geschrieben werden muss (Performance)
DBS1 2004
D B-Architektur
Seite 25
Klöditz
Hochschule Anhalt (FH)
Oracle-Prozesse
Redo-Log-Writer-Prozess (LGWR)
•
bei Checkpoint hat LGWR zusätzlich folgende Aufgaben:
– alle modifizierten DB-Blöcke des DB-Cache markieren und so für
das Rückschreiben durch DBWR vorbereiten
– alle File-Header bezügl. Checkpoint aktualisieren
– den aktuellen Redo-Log-Puffer auf das Redo-Log-File schreiben
– dem DBWR-Prozess den Checkpoint signalisieren, der dann alle
markierten DB-Blöcke auf die DB-Files zurückschreibt
•
bei stark belasteten DB-Systemen optional für CheckpointErstellung eigener Prozess (CHKP)
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 26
Oracle-Prozesse
Transaktionsablauf
Prozeß
insert into
<tabelle>
update <tabelle>
delete from
<tabelle>
commit
ORACLE -DB -Cache
LGWR
DBB
L
O
C
K
P
U
F
F
E
R
R
E
D
O
DBWR
schreibt asynchron
modifizierte DB-Blöcke
vorausgegangener und
eventuell aktueller
Transaktionen zurück
auf die DB-Files
Nach dem commit
wird der Redo- Log-Puffer
auf das Redo-Log-File
geschrieben
if ok then weiter
Redo-Log-Files
DB-Files
Zeit
DBS1 2004
D B-Architektur
Seite 27
Klöditz
Hochschule Anhalt (FH)
Oracle-Prozesse
Prozessmonitor (PMON)
•
überprüft in periodischen Abständen, ob
– Benutzerprozesse vom Systemmanager gestoppt werden müssen
– ein Programm infolge “Absturzes“ nicht zu einem regulären Ende
gekommen ist und Datenbank-Ressourcen sperrt
•
hebt alle solchen Sperren auf, setzt die von dieser Transaktion
schon ausgeführten Änderungen zurück
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 28
Oracle-Prozesse
Systemmonitor (SMON)
•
prüft beim Starten der Datenbank, ob es noch offene
Transaktionen bzw. noch nicht zurückgeschriebene Änderungen
gibt
•
Ursache z.B. nicht ordnungsgemäßes Ende der DB-Arbeit bei
– Schließen der Datenbank durch den DB-Administrator (shutdown
immediate oder abort)
– Zusammenbruch des DBMS oder des Betriebssystems
– Hardware-Fehler, Stromausfall
•
übernimmt dann das Recovery automatisch; alle vollständigen
Transaktionen werden mit Hilfe der Redo-Log-Files in die DBFiles geschrieben, alle unvollständigen Transaktionen werden
zurückgesetzt
DBS1 2004
D B-Architektur
Seite 29
Klöditz
Hochschule Anhalt (FH)
Oracle-Prozesse
Archivierprozess (ARCH)
•
optionaler Hintergrundprozess
•
wenn DB im ARCHIVE LOG-Modus gestartet, kann sie mit Hilfe
der Redo-Log-Files rekonstruiert werden
ARCH kopiert Redo-Log-Files auf anderes Speichermedium,
aktualisiert die Control-Files
•
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 30
Oracle-Datenbank-Cache
DB-Blockpuffer
•
vom Anwenderprogramm angeforderte DB-Blöcke werden in
DB-Cache gelesen, dort verarbeitet und dem Benutzerprozess
zur Verfügung gestellt
•
im DB-Cache befindliche Blöcke können von mehreren
Prozessen genutzt werden (gutes Tuning = neun logische
Reads im DB-Cache auf ein physisches Read von der Platte)
DB-Blöcke unterliegen last-recently-used-Algorithmus (LRU);
am längsten nicht benutzte Blöcke werden zuerst
zurückgeschrieben, wenn nötig
•
DBS1 2004
D B-Architektur
Seite 31
Klöditz
Hochschule Anhalt (FH)
Oracle-Datenbank-Cache
•
Shared Pool
– geparste SQL-Befehle, compilierte Funktionen, Prozeduren, DataDictionary-Informationen und DB-Trigger werden vorgehalten
(shared SQL-Bereich für öffentliche Nutzung)
– privater SQL-Bereich für sitzungsorientierte private Informationen
– unterliegen ebenfalls LRU-Algorithmus
•
Instance-Informationen
– Eintragung gesperrter Ressourcen, Reihenfolge für Abarbeitung
einer Warteschlange, aktive Transaktionen mit Statusinformation,
...
•
DB-Cache-Parameter werden in init.ora gesetzt
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 32
Oracle-Data Dictionary
•
Inhaltsorientierte Betrachtung der Oracle-Datenbank
Benutzer
D
A
T
A
D
I
C
T
I
O
N
A
R
Y
DB-Resourcen, Tabellen, Indices, ...
Benutzer 1
Benutzer 2
Benutzer 3
Benutzer n
DBS1 2004
D B-Architektur
Seite 33
Klöditz
Hochschule Anhalt (FH)
Oracle-Data Dictionary
•
Oracle-Datenbank besteht aus
– Data-Dictionary, in dem alle Daten gespeichert werden, die für das
ordnungsgemäße Funktionieren der DB verantwortlich sind
= Datenbasis für die Verwaltung der DB-Objekte
– beliebig vielen Benutzern mit unterschiedlichen Privilegien
– Datenbank-Objekten wie Tabellen, Views , Indices, Prozeduren,
DB-Trigger, ...
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 34
Oracle-Data Dictionary
•
Data-Dictionary
– besteht aus Systemtabellen, auf die mit SQL zugegriffen werden
kann
– interne Ebene = eigentliche Tabellen; kein Zugriff für normale
Nutzer
– externe Ebene = views auf die Systemtabellen
DBS1 2004
D B-Architektur
Seite 35
Klöditz
Hochschule Anhalt (FH)
Oracle-Data Dictionary
•
Data-Dictionary-Tabellen
– bei Erstellung einer Datenbank werden automatisch die Benutzer
SYS, SYSTEM und PUBLIC angelegt
– SYS ist Eigentümer aller Data-Dictionary-Tabellen (interne Ebene)
und aller Data-Dictionary-Views (externe Ebene)
= höchstprivilegierter Nutzer
– SYSTEM ist Eigentümer von DB-Tabellen für Oracle-Werkzeuge
(Oracle*Forms, Oracle*Report, ...); ist Standard-DBA jedes OracleSystems und kann für alle DBA-Funktionen benutzt werden
– PUBLIC ist ein Dummy-Nutzer, der alle Nutzer eines OracleSystems repräsentiert; Rechte an PUBLIC stehen allen Nutzern der
Datenbank zur Verfügung
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 36
Oracle-Data Dictionary
•
Data-Dictionary-Inhalt
–
–
–
–
–
–
–
–
Benutzer und deren Privilegien
Tabellen und deren Spaltenbezeichnungen und Datentypen
Statistiken über die Tabellen und Indices
Index-Informationen
Zugriffberechtigungen auf Tabellen
Profil-Informationen und die Zuordnung zu den Benutzern
Freiplatzverwaltung
...
DBS1 2004
D B-Architektur
Seite 37
Klöditz
Hochschule Anhalt (FH)
Oracle-Data Dictionary
•
Nutzung des Data Dictionary
für die Ausführung einer SQL-Anweisung
OracleData-Dictionary
select * from
mitarbeiter
where gehalt>4500;
1. Prüfung
ok ?
- existiert die Tabelle 'mitarbeiter' ?
- hat der Nutzer Zugriffsrechte darauf ?
- gibt es eine Spalte 'gehalt' ?
- was bedeutet '*' ?
- gibt es einen Index auf 'gehalt' ?
- gibt es statistische Informationen ?
- ...
Oracle-Benutzerdaten
2. Ausführung
3. Ergebnis
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 38
Oracle-Data Dictionary-Views
•
Sichten existieren jeweils in drei Gruppen, auf die mit dem
jeweiligen Präfix mit SQL zugegriffen werden kann:
– USER enthält alle DB-Objekte, deren Eigentümer der Nutzer ist
• z.B.: select * from user_tables
– ALL enthält alle DB-Objekte, auf die der Nutzer Zugriff hat
• z.B.: select * from all_tables
– DBA enthält alle DB-Objekte, für die DBA-Rechte nötig sind =
Gesamtsicht auf die Datenbank
• z.B.: select * from dba_tables
DBS1 2004
D B-Architektur
Seite 39
Klöditz
Hochschule Anhalt (FH)
Oracle-Data Dictionary-Views
•
Weitere Views
– tab_columns
– indexes
– views
•
Implementierung des Data-Dictionary
– erfolgt bei Initialisierung der Datenbank mit Hilfe des Files sql.bsq
für das interne Data-Dictionary, mit catalog.sql für das externe
Klöditz
Hochschule Anhalt (FH)
DBS1 2004
D B-Architektur
Seite 40