close

Anmelden

Neues Passwort anfordern?

Anmeldung mit OpenID

1. Nennen Sie die wichtigsten Services eines - Roggeweck

EinbettenHerunterladen
1. Nennen Sie die wichtigsten Services eines Datenbanksystems. Wie würden Sie die
grundsätzliche Entscheidung treffen, ob in einem Projekt ein Datenbanksystem oder
eine andere Form der Datenhaltung eingesetzt wird?
Services eines DBS:
Wesentliche Services für die Entscheidungsfindung:
- Verwaltung konkurrierender Zugriffe
- Datensicherheit und Datenschutz
- Möglichkeit der Datenmanipulation auf hohem Niveau
- Verwaltung der Datenintegrität
Weitere Argumente:
- Infrastruktur / Kosten für DBS, Ausbildung und Administration
2. Erläutern Sie den Parameter PCTFREE für Tabellen (Oracle). Gehen Sie davon aus,
dass eine Tabelle folgende Spalten hat:
- col1 char(10) primary key
- col2 char(20) not null
- col3 char(20) with null
col3 wird beim insert nicht gefüllt, aber im Rahmen von Änderungen nachgepflegt.
Wie würden Sie für diese Tabelle PCTFREE definieren? Begründen Sie Ihre
Entscheidung.
PCTFREE ist der Prozentsatz, zu dem in einem Block einer Tabelle Raum für Updates
gelassen wird. (Beim Insert werden Blöcke nicht über das durch PCTFREE definierte
Maß gefüllt.) PCTFREE sollte so gewählt werden, dass der Freiraum in den Blöcken
für das Wachstum von Zeilen ausreichend ist und die Migration verhindert wird.
Im vorliegenden Beispiel kann eine Zeile um bis zu 40% wachsen, so dass PCTFREE
auf den Wert 40 gesetzt werden sollte (defensive Strategie!).
3. Begründen Sie die Aussage: Zur Sicherstellung von Atomizität und Dauerhaftigkeit
von Transaktionen verwendet ein Datenbanksystem Logging. Erläutern Sie in diesem
Zusammenhang den Begriff „Write Ahead Logging“.
Atomizität heißt letztendlich Fähigkeit zum Rollback, dazu muß die Ausgangssituation
jeder Änderung (before images) persistent gespeichert werden, und zwar, bevor die
Änderung in die Datenbank geschrieben wird (=> Write Ahead Logging).
Dauerhaftigkeit heißt, dass auch nach einem Ausfall des DBMS bestätigte
Transaktionen in der DB festgeschrieben werden (und offene Transaktionen
zurückgerollt werden) können. Dazu müssen vor der Rückmeldung des commit die
Änderungen (bzw. after images) und das Commit persistent gespeichert werden.
4. Mehrere Transaktionen führen massive Änderungen in einer Tabelle durch, die aus
fachlichen Gründen nicht in der gleichen Reihenfolge durchgeführt werden können.
Was können Sie tun, um Deadlocks zu vermeiden? Warum sind Deadlocks in diesem
Kontext (Update – Update Konflikte) besonders problematisch?
Für Update – Update Konflikte bieten sich generell drei Vorgehensmodelle an:
- kurze Transaktionen
- konsistente Zugriffspfade
- Table Locks (als letzte Lösung)
Da lange Transaktionen mit inkonsistenten Zugriffspfaden fachlich notwendig sind,
sollte mit Table Locks gearbeitet werden.
Deadlocks in dem betrachteten Kontext sind besonders problematisch, weil der
Rollback einer Transaktion nach massiven Änderungen eine erhebliche
Ressourcenverschwendung darstellt und die Gefahr besteht, dass sich Deadlocks
wiederholen.
5. Gegeben sei eine Fakten Tabelle mit Kundenumsatzdaten; die Spalten der Tabelle sind
-
Tag
Kunden Id
Produkt Id
Anzahl Bestellpositionen
Umsatz (Summe über Verkaufspreis)
Diese Tabelle wird fortgeschrieben aus den Tabellen Auftrag und Auftragsposition mit
den Spalten
-
Auftragsnummer (Primary Key)
Kunden Id (Foreign Key)
Auftragsdatum
Rechnungsnummer
Rechnungsdatum
Auftragsstatus
Bemerkungen zum Auftrag
bzw.
-
Auftragsnummer (Foreign Key, Primary Key Column 1)
Positionsnummer (Primary Key Column 2)
Produkt Id
Anzahl
Einzelpreis
Mit dem SQL Statement
Select a.Auftragsdatum, a.KundenId, ap.ProduktId,
sum(ap.Anzahl), sum (ap.Anzahl*ap.Einzelpreis)
From Auftrag a, Auftragsposition ap
Where a.Auftragsnummer = ap.Auftragsnummer
And a.Rechnungsdatum = Tagesdatum
Group by a.Auftragsdatum, a.KundenId, ap.ProduktId
werden täglich die benötigten Daten aus diesen Tabellen extrahiert. Pro Werktag gibt
es ca. 10000 Aufträge (von fast ebenso vielen Kunden) mit jeweils ca. 100
Auftragspositionen. Die Aufträge sind i.a. nach 5 Werktagen erledigt
(Rechnungsstellung), nach einem weiteren Monat werden die Daten dann aus den
Tabellen entfernt.
Entwerfen Sie ein physisches Datendesign (Partitionierung und Indexdesign) für die
Tabellen Auftrag und Auftragsposition, das diese Abfrage unterstützt. Sie dürfen in
der Tabelle Auftragsposition maximal eine redundante Spalte mitführen.
Extra:
Die Faktentabelle enthält die Daten für die jeweils letzten 4 Jahre (ca. 250 Werktage
pro Jahr). Auswertungen sollen möglich sein nach den Dimensionen Zeit (Tag, Monat
und Jahr), Kunde (Kunden Id, Ort und Region) und Produkt (Produkt Id,
Produktgruppe). Sämtliche Kombinationen sollen möglich sein. Es gibt 10 Mio.
Kunden in 1000 Orten und 10 Regionen (gleichverteilt), 1000 Produkte in 10
Produktgruppen (gleichverteilt). Welches physische Datendesign (basierend auf
materialisierten Sichten, Partitions- und Indexdesign) schlagen Sie vor, wenn mehr als
40 Partitionen pro Tabelle nicht erwünscht sind und maximal 3 materialisierte Sichten
(inklusive der Fakten Tabelle) verwendet werden sollen?
Da in der operativen DB Daten für ca. 25 (Werk-)Tage verwaltet werden, für das o.g.
SQL Statement aber alle Tage bis auf einen (Auftragsdatum vor 5 Tagen) nur wenige
Treffer zu bearbeiten sind, bietet sich eine Partitionierung der Auftragstabelle nach
Auftragsdatum (25 Partitionen) an; um die wenigen Treffer in den 24 Partitionen
herauszufiltern, sollte ein Index auf Rechnungsdatum gelegt werden.
Für die o.g. Abfrage bringt die Partitionierung aber nur etwas, wenn auch die
Auftragspositionstabelle nach Auftragsdatum partitioniert ist. Da die Partitionierung
einer Tabelle nach einer virtuellen Spalte i.a. nicht unterstützt wird, bietet es sich an,
die Spalte Auftragsdatum (konstant!) in der Tabelle Auftragsposition mitzuführen und
danach zu partitionieren.
Damit reduziert sich die Komplexität der Verarbeitung auf 1 Partition, also 10000
Aufträge mit 1 Mio. Auftragspositionen, so dass sich eine sequentielle Verarbeitung
anbietet (Hash Join / pipelined grouping). Für die anderen 24 Partitionen ist aufgrund
der geringen Treffermenge (an Aufträgen) ein nested loop join mit anschließender
Gruppierung einer kleinen Datenmenge okay.
Extra (falls das verwendete DBS die Partitionierungstechniken nicht unterstützt, muß
manuell partitioniert werden!):
Partitionierung nach Zeit bietet sich schon wegen der Archivierung der Daten an,
aufgrund der Restriktion, dass maximal 40 Partitionien zu verwenden sind, nach Jahr
=> 4 Partitionen. (Die Partitionierung nach Monat würde somit das Kontingent
übersteigen, als Alternative bietet sich ein Clustered Index nach der Zeit an.) Dann
bleiben 10 Partitionen nach Region oder Produktgruppe.
Da ein Kunde im Schnitt 1 Auftrag mit 100 Positionen tätigt, ist davon auszugehen,
dass die Aggregation (Monat, Kunde, Produkt) nicht wesentlich weniger Einträge hat
als die Basistabelle, sich also nicht lohnt. Die Aggregation (Tag, Ort, Produkt) hat
zwischen 1 Mio. und 1 Mrd. Einträgen, abhängig davon ist zu entscheiden, ob sich die
Aggregation lohnt, die Aggregation (Tag, Kunde, Produktgruppe) hat zwischen 10
Mio. und 100 Mio. Einträgen, so dass sich diese Aggregation lohnt. Falls die
Aggregation (Tag, Ort, Produkt) nicht materialisiert wird, ist die Materialisierung der
Aggregation (Tag, Ort, Produktgruppe) vorzuschlagen.
Bleibt die Frage, ob die Partitionierung nach Region oder Produktgruppe vorzuziehen
ist:
Die Reduktion des Datenvolumens ist gleich und somit kein Entscheidungskriterium.
Die Partitionierung nach Produktgruppe ist hilfreich bei der Materialisierung der
Aggregation (Tag, Kunde, Produktgruppe), da die Partitionierung der Faktentabelle
übernommen werden kann und damit die Parallelverarbeitung effizienter wird; ferner
ist sie hilfreich für den Drill Down Produktgruppe => Produkt.
Die Partitionierung nach Region ist hilfreich für den Drill Down Region => Ort und
bedingt für den Drill Down Ort => Kunde. Falls die Aggregation (Tag, Ort, Produkt)
materialisiert wird, ist die Partitionierung der Faktentabelle nach Region hilfreich, da
sie übernommen werden kann.
6. Diskutieren Sie die Vor- und Nachteile redundanter Datenhaltung unter der
Voraussetzung, dass die Redundanzen synchron, also innerhalb einer Transaktion mit
den Änderungen der Basisdaten, zu pflegen sind.
Vorteile:
- Verbesserte Performance für lesende Zugriffe (lokal / verteilt)
- Verfügbarkeit (verteilt)
Nachteile:
- Aufwand für Verwaltung der Redundanz (lokal / verteilt)
- Längere Transaktionen => schlechtere Concurrency, insbesondere wenn
mehrere Tabellen beteiligt sind (lokal / verteilt)
- Verteilte schreibende Transaktionen können nur dann erfolgreich beendet
werden, wenn das System vollständig verfügbar ist. (verteilt)
7. Beschreiben Sie die grundlegende Vorgehensweise bei der Modellierung verteilter
Datenbanken. Wo liegen die besonderen Herausforderungen im Vergleich zur
Modellierung zentraler Datenbanken.
Referenzmodell:
- globales Schema
- Fragmentierungsschema (horizontal / vertikal)
- Allokationsschema (inklusive Entscheidung über Dispersion / Replikation)
- Lokale Schemata
Besondere Herausforderungen:
- Erstellung des Fragmentierungs- und Allokationsschemas unter den Aspekten
Verfügbarkeit, Lokalität des Zugriffs, Lastverteilung und Skalierbarkeit,
Berücksichtigung der wesentlich komplexeren Administration
8. Erläutern Sie, wie man mit einem sequentiell lesenden Cursor (prinzipiell) arbeitet.
Welche anderen Cursor Typen kennen Sie? (Falls Sie JDBC bevorzugen, können Sie
den Begriff Cursor durch ResultSet ersetzen.)
Prinzipielles Verarbeitungsschema:
- open (Abfrage wird gestartet)
- fetch (Lesen der nächsten Ergebniszeile)
- close (Ressourcenfreigabe)
Sonstige Cursortypen:
- scroll cursor (erlaubt Direktzugriff auf die Zeilen der Ergebnismenge)
- (in)sensitive cursor (arbeitet auf (einer Kopie) der Ergebnismenge)
- update cursor (erlaubt Löschen und Ändern der aktuellen Zeile via Cursor)
- hold cursor (wird nicht automatisch beim commit geschlossen)
Document
Kategorie
Internet
Seitenansichten
8
Dateigröße
17 KB
Tags
1/--Seiten
melden