DBI-2025-05-20

Hill 9: Stored Routines

Programm wird in der Datenbank abgelegt, Prozeduraler Code mit SQL
Eingabe mit Parametern und Rückgabe

Procedure Aufruf vom Anwendungsprogramm statt SQL-Anweisung
Function (User-defined): Verwendung in Ausdrücken innerhalb SQL

Vorteile:

vorkompiliert, lokaler Zugriff
verringerter Netzwerkverkehr

TSQL

Variablen, Datentypen, Flow-Control

Procedures/Functions

Trigger

Stored Procedure die nicht explizit aufgerufen wird sondern beim Eintreten von bestimmten Ereignissen
Arten:

DML
DDL
Database-Events (Logon/Logoff, Startup)

Zeitpunkt:

BEFORE
AFTER
INSTEAD OF

Betreff:

Row-Level-Trigger: Trigger wird auf jeder veränderten Zeile aufgerufen
Statement-Level-Trigger (SQL-Server): Trigger wird einmal mit allen Zeilen aufgerufen

Auch:

Nested Trigger: Trigger ruft andere Trigger auf
Recursive Trigger, Trigger ruft sich selbst auf

Anwendung:

Überwachung von Business Rules
Aktualisierung redundanter Daten
Mitschreiben von Änderungen - Audit Trails
Sicherheitsmechanismen

Das Datenbanksystem kann komplett enkapsuliert werden, alles geht über Stored Procedures und Trigger.

Cursor

Hill 11: Systemtabellen und Information Schema Views

Beschreibung der Objekte in einer Datenbank wird in Systemtabellen in der Datenbank abgelegt
Veränderung nicht über Systemtabellen möglich, dafür DDL
Information Schema Views: von der SQL-Norm, einheitlicher Zugriff auf Systemtabellen, Selbstbeschreibend

Tables, Column
Views, View Table und Column usage
Table Constraints, Key und Constraint Column Usage

Hill 12: Transaktionen

Logisch zusammengehörige Änderungen von Daten, wenn nur Teilweise sind die Daten logisch inkonsistent
Muss entweder ganz oder gar nicht durchgeführt werden, muss atomar sein.
ordnungsgemäß beendet: Commit
nicht: Rollback, Abort, Reset, Backout

Länge:

so kurz wie möglich: Systemoverhead, weniger im Fehlerfall zu wiederholen, weniger Sperre für andere
so lang wie notwendig: konsitenter Zustand

ADIC-Prinzip:

Atomicity: Unteilbarket, alles oder nichts
Consistency: Daten sind immer logisch konsistent
Isolation: Transaktionen können nicht interferieren
Durability: Nach Abschluss Recovery mögich

Hill 13: Recovery

Fehler:

Transaktionsfehler (lokaler Fehler), -> Rollback, Transaction Recovery
Systemfehler (globaler Fehler, Softcrash), Stromausfall, Fehler im Betriebssystem -> Crash Recovery
Mediumfehler, (Speicherfehler, Hardcrash), Daten sind physikalisch zerstört -> Archive Recovery

Transaction und Crash Recovery -> Backward Recovery
Archive Recovery -> Forward Recovery

Backward Recovery:

Undo-Logs, Vor jeder Änderung wird ein Before-Image gespeichert, dadurch ist der alte Wert bekannt (Standard)
Verzögertes Update, Es wird auf Kopien der Daten gearbeitet, erst wenn die Transaction fertig ist wird gespeichert

Zusätzliche Log-Infos:

Trans-Info (Anfang Ende Id)
Operation
Daten Id
Before-Image

Bei Transaction Recovery muss Log bis Beginn der Transaktion gelesen werden, bei Crash Recovery bis Anfang, es könnten immer noch Before-Images von nicht beendeter Transaktion sein, daher checkpoints im Logfile mit allen Aktiven Transaktionen

Forward Recovery:
Redo-Logs mit After Image, bis zum Nächsten Backup aufheben, können komprimiert werden, Änderungen zusammengeführt (Change Accumulation).

Backups

Full Backup
Partial: nur Änderugen
- Differential Backup: zum Letzten Full Backup
- Incremental: Zum Letzten Backup

Vorteile Differential:

sicherer, bei Datenverlust
schneller Wiederherstellen
Vorteile Incremental:
Weniger Speicherplatzverbrauch
kürzere Backupzeitern

Andere Arten:

Paralleles Backup (Striped Backup): mit mehreren Laufwerken und medien
Offline (Cold) Backup: während die Datenbank nicht läuft
Online (Hot) Backup: laufender Betrieb
- sequenziell, alle Zeilen nacheinander sichern, wenn Transaktion Daten ändern will werden sie vorgezogen und als gesichert markiert

Bei kombinierten System und Mediumfehler ist zuerst und dann Backward Recover nötig

Hill 14: Concurrency

Synchronisation paralleler Transaktionen
Probleme:

Lost Update: verlorene Änderung, eine Transaktion überschreibt andere
Inconsistent Analysis, Änderung der Daten währen durchgehen
Uncommited Dependency: Transaktion liest Daten von einer anderen die Zurückgerollt werden, Dirty Read

Serialisierbarkeit: Die Daten müssen nach einem parallelen Ablauf von Transaktionen gleich sein wie nach einem seriellem Ablauf in irgendeiner Reihenfolge

Schedule: Konkreter Ablauf von Abfragen und Änderungen von mehreren Transaktionen
z.B. r1(A); r2(A); w1(B); w2(B)
(T1 liest A, T2 liest A, T1 schreibt B, T2 schreibt B)
Anzahl an Schedules:

Serieller Schedule: Transaktionen werden hintereinander ausgeführt
Serialisierbarer (konfliktserialisierbarer) Schedule: äquivalent zu irgendeinem Seriellen Schedule ist

äquivalent heißt hier, dass in Konflikt stehende Operationen in derselben Reihenfolge aus

Präzedenzgraph: Knoten: Transaktionen, Kanten: von A nach B wenn es zwei Konfliktoperationen zwischen Transaktionen gibt. Wenn der Graph azyklisch ist, ist der Schedule konfliktserialisierbar

Sperren

Annahmen dass Konflikte entstehen, daher sperren
Optimistische Sperre: Annahme dass keine Konflikte kommen, Objekte werden erneut gelesen um Änderungen zu prüfen
Zeitstempel-Verfahren: Konflikte treten auf wenn Transaktionen versuchen jüngere Daten zu ändern, dann Neuausführung

Phasen: Two-Phase-Locking: Zuerst Sperren machen, dann wieder aufheben.
Strict-Two-Phase Locking: Alle Sperren werden erst am Ende der Transaktion aufgehoben

Sperrobjekte: Datenbank, Tabelle, Blöcke, Zeile
Vorteil fein: Parallelität, aber Mehr Aufwand

Sperrmodi: X-Lock (&mut in Rust): Exklusives, Schreibsperre Lock, nur eine Transaktion kann Lock haben
S-Lock (& in Rust): Shared Lock, Lesesperre, Andere Transaktionen können auch S-Lock sperren

Deadlock-Lösungen:

Vermeidung:
- prevention: Bei Sperranforderung Abbruch
- preclaiming: Am Anfang Sperren
- timestamping
Erkennung: Wartegraph, Beseitigung: Eine Transaktion wird zurückgesetzt