Theorie Flashcards
XML
eXtensible Markup Language
- Auszeichnungssprache
- strukturierte Darstellung von Daten zum Austausch zwischen verschiedenen Instanzen (“gemeinsame Sprache”)
Syntax
hierarchisch angeordnet
Wurzelelement; Element mit Inhalt;
Attribut aus Attributname und Attributwert
Wohlgeformtheit eines XML-Dokuments
- öffnende und schließende Tags (Kurzschreibweise)
- korrekte Verschachtelung
- genau ein Wurzelelement
–> nur prinzipiell verarbeitbar, nicht zwangsläufig für Einsatzzweck richtig strukturiert
Validität eines XML-Dokments
Def.: Wohlgeformtheit + richtige Struktur für Einsatzzweck
- Document Type Definition (DTD): älter, selbst kein XML
- XML Schema Definition (XSD): neuer, selbst in XML formuliert (kennt Datentypen)
DTD
- Häufigkeit: ?: 0-1; +: >1; *:>0
- Attribute: #IMPLIED: optional; #REQUIRED: verpflichtend
Kritik an DTD
- kein XML
- nicht ausdrucksstark genug z.B. keine Spezifizierung von Datentypen der Attribute möglich
Garantie an den Anwender (bzgl. Transaktionen)
- Atomarität: Zurücksetzung einer fehlerhaften (unvollständigen) Transaktion
- Konsistenz: Schlüssigkeit und Korrektheit einer Datenbank in sich
- Isolation: Unabhängigkeit einer Transaktion von parallel laufenden Transaktionen
- Dauerhaftigkeit : Persistenz aller Daten einer abgeschlossenen Transaktion
- -> ACID
Recovery und Vorsorge
Wiederherstellung von Daten im Fehlerfall (HW oder SW)
- HW: nur zertifizierte Rechner und speziell ausgelegte Geräte
- SW: Abstimmung von SW-Komponenten
- Sicherung: Protokollierung jeder Änderung in einer Logdatei, tägliche Differenzsicherung, wöchentliche Komplettsicherung und sichere Aufbewahrung
Sicherer Datenbankbetrieb
- Datenbank und Logdaten auf externen nichtflüchtigen Medien
- Datenbank-Puffer im Arbeitsspeicher (Performance)
- Zugriff auf Datenbank nur, wenn Daten nicht im Puffer
- Schreiben im Datenbank-Puffer
- asynchrone Aktualisierung
Metadaten
Informationen zu und Zustände über eine Datenbank
- Informationen zu laufenden Transaktionen
- Zustände zu Synchronisationsmechanismen
- Aktualität und Gültigkeit der Daten im Datenbankpuffer
- Zustand der aktuellen Logdaten
Datenbankpuffer
- großer Teil des Arbeitsspeichers, bis zu 1 TB bei großen Datenbanken
- Bearbeitung der Daten im Puffer für weniger I/Os
- Speicherung der Änderungen in Logfiles
Datenbankpuffer
- großer Teil des Arbeitsspeichers, bis zu 1 TB bei großen Datenbanken
- Bearbeitung der Daten im Puffer für weniger I/Os
- Speicherung der Änderungen in Logfiles
Before- und After-Image
- Before-Image: zu ändernde Daten, bis Transaktionsende gespeichert
- After-Image: geänderte Daten, bis zur nächsten Sicherung gespeichert
einfacher TA-Betrieb
- Lesen der Daten: von Datenbank falls nicht bereits im Puffer
- Merken der
zu ändernden Daten in der Logdatei (Before
Image) - Ändern der Daten: Ändern (Update, Delete, Insert) der Daten im Arbeitsspeicher, Sperren
dieser Einträge für andere Benutzer - Merken der
geänderten Daten in der Logdatei (After Image)
. . . Obige vier Schritte können sich innerhalb einer Transaktion mehrmals
wiederholen
- Transaktionsende
mit COMMIT
Transaktionsende in der Logdatei vermerken. Sperren freigeben.
Schreiben aller Änderungen in die Datenbank. - Transaktionsende
mit Rollback
Rücksetzen der Metadaten der Transaktion. Geänderte Daten im
Arbeitsspeicher mittels Before-Images restaurieren. Sperren freigeben.
moderner TA-Betrieb
- asynchrones Schreiben der Daten in die Datenbank um Überlastungen zu verhindern
- Pufferung: Minimierung des I/O-Verkehrs, Konsistenz der Daten abhängig von Logfiles
Concurrency
- Parallelbetrieb in Datenbanken: Jede Transaktion läuft so ab,
als sei sie allein im System - 3 Herausforderungen: verlorengegangene Änderungen bei Gleichzeitigkeit, Abhängigkeit von nicht abgeschlossenen Transaktionen (Lesen von Daten, die mittels Rollback zurückgesetzt werden), Inkonsistenz (fehlerhafte Daten bei gleichzeitigen Transaktionen
Concurrency Strategien
- optimistisch: bei Transaktionsende wird auf parallele Zugriffe überprüft und ggf. zurückgesetzt und neu gestartet
- bei geringer Kollisionswahrscheinlichkeit
- Ri
Concurrency Strategie optimistisch
- optimistisch: bei Transaktionsende wird auf parallele Zugriffe überprüft und ggf. zurückgesetzt und neu gestartet
- bei geringer Kollisionswahrscheinlichkeit
- Risiko: permanente Neustarts durch gegenseitiges Aufschaukeln
Concurrency Strategien: pessimistisch
- Alle von einer Transaktion angefassten Daten sind für andere
Transaktionen gesperrt, Freigabe der Sperre am Transaktionsende - Risiko:
Einschränkung der Parallelität, hoher Aufwand für Sperrmechanismen
Sperrgranulate
- Datenbanksperre: kein Parallelbetrieb, nur Einzelplatzbetrieb
- Tabellensperren: relativ flexibel, bei geringer Parallelität
- Tupelsperren: alle wichtigen Datenbanken, Standard in größeren Datenbanken
- > Problem bei großen Datenbanken sehr viele Locks, daher Lockpool mit Poolverwaltung und bedarfsgerechter Einrichtung
- Eintragsperren: sehr sehr aufwändig, kaum implementiert
Sperrmechanismen
Sperrmechanismen werden mit Locks realisiert
Grundidee zu Locks in Datenbanken:
Zu jeder Relation existiert ein Lock
Eine Transaktion holt vor jedem Zugriff auf eine Relation
automatisch den Lock dieser Relation
Ist der Lock von einer anderen Transaktion belegt, so wartet
die Transaktion in einer Warteschlange, bis sie nach der
Freigabe des Locks an der Reihe ist
Bei Transaktionsende werden alle gehaltenen Locks freigegeben
