Theorie

Question 1

XML

Answer 1

eXtensible Markup Language

• Auszeichnungssprache
• strukturierte Darstellung von Daten zum Austausch zwischen verschiedenen Instanzen (“gemeinsame Sprache”)

Question 2

Syntax

Answer 2

hierarchisch angeordnet
Wurzelelement; Element mit Inhalt;
Attribut aus Attributname und Attributwert

Question 3

Wohlgeformtheit eines XML-Dokuments

Answer 3

• öffnende und schließende Tags (Kurzschreibweise)
• korrekte Verschachtelung
• genau ein Wurzelelement

–> nur prinzipiell verarbeitbar, nicht zwangsläufig für Einsatzzweck richtig strukturiert

Question 4

Validität eines XML-Dokments

Answer 4

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)

Question 5

DTD

Answer 5

• Häufigkeit: ?: 0-1; +: >1; *:>0

- Attribute: #IMPLIED: optional; #REQUIRED: verpflichtend

Question 6

Kritik an DTD

Answer 6

• kein XML

- nicht ausdrucksstark genug z.B. keine Spezifizierung von Datentypen der Attribute möglich

Question 7

Garantie an den Anwender (bzgl. Transaktionen)

Answer 7

• 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

Question 8

Recovery und Vorsorge

Answer 8

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

Question 9

Sicherer Datenbankbetrieb

Answer 9

• 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

Question 10

Metadaten

Answer 10

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

Question 11

Datenbankpuffer

Answer 11

• 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

Question 11

Datenbankpuffer

Answer 11

• 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

Question 12

Before- und After-Image

Answer 12

• Before-Image: zu ändernde Daten, bis Transaktionsende gespeichert
• After-Image: geänderte Daten, bis zur nächsten Sicherung gespeichert

Question 13

einfacher TA-Betrieb

Answer 13

• 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.

Question 14

moderner TA-Betrieb

Answer 14

• asynchrones Schreiben der Daten in die Datenbank um Überlastungen zu verhindern
• Pufferung: Minimierung des I/O-Verkehrs, Konsistenz der Daten abhängig von Logfiles

Question 15

Concurrency

Answer 15

• 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

Question 16

Concurrency Strategien

Answer 16

• optimistisch: bei Transaktionsende wird auf parallele Zugriffe überprüft und ggf. zurückgesetzt und neu gestartet
• bei geringer Kollisionswahrscheinlichkeit
• Ri

Question 16

Concurrency Strategie optimistisch

Answer 16

• 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

Question 17

Concurrency Strategien: pessimistisch

Answer 17

• 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

Question 18

Sperrgranulate

Answer 18

• 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

Question 19

Sperrmechanismen

Answer 19

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