Datenbankadministration

Transkript

1 Friedrich-Schiller-Universität Jena Fakultät für Mathematik und Informatik Institut für Informatik Lehrstuhl für Datenbanken und Informationssysteme Prof. Dr. K. Küspert Dipl.-Math. K. Büchse Dipl.-Inf. A. Göbel Datenbankadministration Projekt 3: Backup, Recovery und Logging WS 2011/2012 Beginn: Abgabe: Besprechung: Einleitung Nachdem in den bisherigen Projekten des Administrationspraktikums der physische Entwurf von Datenbanken und die Nutzerverwaltung vorgestellt wurden, beschäftigt sich Projekt 3 mit einem weiteren zentralen Aspekt der Datenbankadministration: der Sicherung (Backup) und Wiederherstellung (Recovery) von Datenbanken. Integraler Bestandteil der Wiederherstellung von Datenbanken ist neben dem eigentlichen Backup-Image das Log, auf welches ebenfalls eingegangen wird. Eines der wichtigsten Argumente für den Einsatz von Datenbanksystemen ist der durch diese Systeme gewährleistete Schutz vor Datenverlust, verursacht durch Fehler während des Datenbankbetriebes. Die Sicherung von Datenbanken dient dabei dem Schutz vor Datenverlust im Falle eines Externspeicherfehlers (siehe Klassikation aus der Vorlesung DBS 2). Dazu muss in regelmäÿigen Abständen eine komplette oder teilweise Kopie der Datenbank auf einem externen Medium (typischerweise ein Magnetband oder eine andere Platte) erzeugt werden. Da dieser Prozess für groÿe Datenbanken sehr zeitaufwendig ist, werden diese Sicherungen allerdings nur in gröÿeren Abständen durchgeführt. Zwischen diesen Sicherungen werden die in der Datenbank vorgenommenen Änderungen in einem Log aufgezeichnet, und dieses wird ebenfalls regelmäÿig gesichert. Nach dem Auftreten eines Externspeicherfehlers kann die Datenbank dann mit Hilfe der erstellten Datenbankkopien und der gesicherten Logs in einem aktuellen transaktionskonsistenten Zustand wiederhergestellt werden. Dies gewährleistet Atomarität (vorhandene Änderungen zum Fehlerzeitpunkt oener Transaktionen werden zurückgenommen) und Dauerhaftigkeit (Persistenzgarantie für Änderungen zum Fehlerzeitpunkt erfolgreich beendeter Transaktionen) als wesentliche Aspekte der ACID- Eigenschaft (siehe Vorlesung) von Datenbanktransaktionen. Wie fast alle Datenbanksysteme bietet natürlich auch DB2 entsprechende Möglichkeiten zur Sicherung und Wiederherstellung von Datenbanken. Im vorliegenden Projekt sollen Sie mit einigen der von DB2 angebotenen Fehlerbehandlungsmechanismen vertraut gemacht werden und diese anwenden. Die für die Bearbeitung der nachstehenden Aufgaben notwendigen Informationen nden Sie im DB2 Information Center im Abschnitt Database administration Data Recovery. Hinweise Bevor Sie mit der Arbeit an dem Projekt beginnen, sollten Sie Ihre, im Projekt 2 veränderte, ADMIN- Datenbank löschen und neu erzeugen mit dem folgenden Befehl: > admin_db -f 1

2 Sie arbeiten in diesem Projekt wieder ausschlieÿlich als Datenbanksystemadministrator unter Ihrem Instanzen-Login db2i??. Die Aufgaben in den einzelnen Teilen dieses Projekts müssen in der angegebenen Reihenfolge und jeweils vollständig ausgeführt werden, da sie teilweise aufeinander aufbauen. Die mit einem Stern markierten Aufgaben bzw. Teilaufgaben sind nur von Studierenden eines Diplomstudiengangs zu bearbeiten. Alle Aufgaben und Ergebnisse sind zu dokumentieren: Anfragen, Befehle, Ergebnisse und ggf. der Lösungsweg mit sämtlichen Rechnungen sind mit evtl. Erläuterungen und Begründungen abzugeben. Reduzieren Sie die DB2-Ausgaben stets auf die relevanten Teile, so sind die Ergebnismengen von SQL-Anfragen stets auf maximal 20 Tupel zu begrenzen. Notieren Sie Ihr Kennzeichen (Login) und die Namen der zugehörigen Gruppenmitglieder auf dem Deckblatt Ihrer Aufgabenlösungen. Geben Sie ihre Lösung in schriftlicher Form (geheftet oder getackert, 1- oder 2-spaltig) als auch elektronisch per an bis zur Veranstaltung am Abgabetermin ab. Teil 1 Backup und Restore Aufgabe 1 (Backup) a) Machen Sie sich mit den Optionen des BACKUP Kommandos vertraut. Erläutern Sie kurz die Bedeutung der Parameter ONLINE, WITH num-buffers BUFFERS, BUFFER buffer-size, PARALLELISM n und COMPRESS. b) Erstellen Sie eine Komplettsicherung der Datenbank ADMIN, verizieren Sie das Backup-Image und lassen Sie sich den Header des Images anzeigen. c) Unternehmen Sie nötige Schritte, um auf der Datenbank ADMIN ein kumulatives inkrementelles Backup 1 erstellen zu können; erstellen Sie es jedoch noch nicht! Dokumentieren Sie eventuell notwendige Änderungen der Datenbankkonguration. Setzen Sie anschlieÿend alle Kommentare in der Tabelle REGION auf NULL. Erstellen Sie nun ein kumulatives inkrementelles Backup. d) Löschen Sie die Tabelle CLOB_DATA. Anschlieÿend ändern Sie den Eintrag der Spalte C_MKTSEGMENT für den Kunden mit der ID 3 auf markt segm und erstellen eine inkrementelle, nicht-kumulative Sicherung 2 der Datenbank. Vergleichen Sie die Gröÿen der Backup-Images aus den Teilaufgaben b), c) und d). Warum ist das nicht-kumulative Backup-Image gröÿer als das Backup-Image aus Teilaufgabe c? Wie ändert sich die Gröÿe des Backup-Images, wenn Sie die Option COMPRESS verwenden? e) Verwenden Sie den LIST HISTORY Befehl um eine Übersicht über die Backups für die Datenbank ADMIN zu erhalten. Bitte bewahren Sie sich die 3 Backup-Images auf, da diese in Aufgabe 2 nochmals benötigt werden. Aufgabe 2 (Restore - I) Für diese Aufgabe löschen Sie bitte zuerst die Datenbank ADMIN. a) Stellen Sie die Datenbank ADMIN mit Hilfe der Backup-Images, die Sie in Aufgabe 1 angelegt haben, bis zum Zeitpunkt vor dem Löschen der Tabelle CLOB_DATA wieder her. Welche der vorherigen Änderungen sind in der Datenbank enthalten, welche nicht? Ermitteln Sie dies mittels geeigneter SQL-Anfragen. b) Restaurieren Sie die Datenbank ADMIN bis zum Zeitpunkt der letzten Sicherung und überprüfen Sie, dass alle Änderungen aus Aufgabe 1 vorhanden sind. Im Anschluss sollten Sie die Backup-Images löschen. 1 Diese Art von Sicherungen wird in der Literatur und anderen Produkten auch als inkrementelles Backup bezeichnet. 2 Diese Art von Sicherungen wird in der Literatur und anderen Produkten auch als dierentielles Backup bezeichnet. 2

3 Aufgabe 3 (Restore - II*) Das DB2-Kommando RESTORE kann auch verwendet werden, um die physische Lokation der Container von Tablespaces zu ändern. Solche Änderungen können notwendig oder erwünscht sein, wenn neue Hardware angeschat wird oder aus irgendeinem Grunde ein Container nicht mehr zur Verfügung steht und somit ein normales Restore nicht mehr durchgeführt werden kann. a) Ermitteln Sie, bei welchen Tablespaces der Datenbank ADMIN die dynamische Speicherverwaltung aktiviert ist. Ermitteln Sie die Anzahl der benötigten Seiten und die verwendete Seitengröÿe der Tablespaces, welche keine dynamische Speicherverwaltung besitzen. Erstellen Sie eine Komplettsicherung der Datenbank und löschen Sie anschlieÿend die Datenbank. b) Die Daten in jedem Tablespace mit dynamischer Speicherverwaltung sollen nun durch die Verwendung des Kommandos RESTORE auf jeweils zwei Container auf verschiedenen Platten verteilt werden. Wie bereits in Projekt 1 simulieren wie die Platten durch die Verzeichnisse /disk1 und /disk2. Lassen Sie sich nach dem Ende des Wiederherstellungsprozesses (und dem eventuell notwendigen Roll-forward) die Lage aller Container anzeigen. c) Löschen Sie erneut die Datenbank ADMIN und nutzen nun das Kommando RESTORE, um alle Tablespaces auf die Verzeichnisse /disk1 und /disk2 zu verteilen. Die Container der Tablespaces ohne dynamische Speicherverwaltung sollen in den Verzeichnissen jeweils TBSx genannt werden, wobei x für die ID des Tablespace einzusetzen ist. Verwenden Sie ausreichend groÿe Containergröÿen. Lassen Sie sich nach dem Ende des Wiederherstellungsprozesses (und dem eventuell notwendigen Roll-forward) die Lage aller Container anzeigen. d) Können Sie RESTORE auch dazu verwenden, die Daten einer (oder mehrerer) Tabelle in einen anderen Tablespace zu legen? Teil 2 Behandlung von Transaktionsfehlern Aufgabe 4 (Transaktionsfehler*) Nutzen Sie für diese Aufgabe das Programm ta_fehler, welches im Verzeichnis db2i00/bin/ liegt. Den Sourcecode nden Sie in db2i00/src/. a) Führen Sie das Programm ta_fehler aus. Was stellen Sie fest? Beschreiben Sie den Fehler und seine Ursachen. b) Setzen Sie den Datenbankkongurationsparameter LOCKTIMEOUT auf den Wert 2. Wie ändert sich nun das Verhalten von ta_fehler? Setzen Sie den Wert wieder zurück auf -1. c) Beim Ausführen von ta_fehler vergehen mehrere Sekunden zwischen dem Erscheinen der Ausgabe done und dem Zeitpunkt, zu welchem DB2 den Fehler erkennt. Welcher Kongurationsparameter beeinusst diese Wartezeit? Setzen Sie den Parameter auf einen niedrigeren oder höheren Wert. Beachten Sie, dass die Datenbank neu gestartet werden muss (durch Trennen aller Verbindungen und ggf. DEACTIVATE DATABASE), damit die Änderung eektiv wird. Beobachten Sie das geänderte Laufzeitverhalten von ta_fehler nachdem die Ausgabe done erscheint. Setzen Sie den Wert wieder zurück auf seinen Default. d) Welche anderen Möglichkeiten sehen Sie, um die in den vorherigen Teilaufgaben aufgetretenen Fehler zu beseitigen? Nennen Sie zwei Möglichkeiten. 3

4 Teil 3 Logging Die Aufgabe aus Teil 2 sollte Ihnen verdeutlichen, wie wichtig es ist, gegen unerwartete Fehler gewappnet zu sein. In diesem Aufgabenteil liegt der Fokus nun auf den Mechanismen, mit denen sichergestellt wird, dass keine Daten durch Transaktions- und Systemfehler verloren gehen. Das Logging garantiert die Dauerhaftigkeit (durability) der bekannten ACID-Eigenschaften für Transaktionen. Eine detaillierte Erläuterung zu den Modi für das Logging in DB2 nden Sie im Abschnitt zum Thema High availability and recovery im Tutorium zur DBA-Zertierung von DB2 V9: Aufgabe 5 Setzen Sie die Kongurationseinstellungen des Datenbankmanagers und der Datenbank ADMIN zurück. Erarbeiten Sie sich mit Hilfe des DB2 Information Centers die Kongurationsparameter für die Datenbankprotokollierung und deren Bedeutung und ermitteln Sie die bei Ihnen vorliegende Konguration der Datenbank ADMIN und des Datenbankmanagers. Ergänzen Sie dazu die vorgegebene Tabelle. Bitte geben Sie in der Spalte Bedeutung mit eigenen Worten (eine Kopie oder simple Übersetzung der Dokumentation reichen hier nicht) und in verständlicher Weise die Verwendung der Parameter wieder. Parameter Wert Default Wertebereich Bedeutung... Folgende Parameter sind zu beachten: LOGFILSIZ, LOGPRIMARY, LOGSECOND, Path to log files, NEWLOGPATH, LOGARCHMETH1, LOGARCHMETH2, MAX_LOG, NUM_LOG_SPAN und REC_HIS_RETENTN. Aufgabe 6 (Externspeicherfehler und Log-Protokollierung) a) Überprüfen Sie, ob für die Datenbank ADMIN Umlaufprotokollierung (Circular Logging) aktiviert ist. Aktivieren Sie diese gegebenenfalls. b) Erhöhen Sie, aufgrund mehrerer Einzahlungen, den Kontostand des Kunden mit der ID 28 um $100. c) Führen Sie ein Backup der gesamten Datenbank durch. d) Ermitteln Sie den Kontostand des Kunden mit der ID 379 und erhöhen Sie dessen Kontostand ebenfalls um $100. Überprüfen Sie die korrekte Ausführung der Kontostandserhöhungen durch eine geeignete SQL-Anfrage. e) Jetzt tritt ein Externspeicherfehler auf. Da wir wollen, dass uns die Platten der iibm04 noch lange erhalten bleiben, werden wir keine Platten physisch zerstören, sondern diesen Fehler simulieren. Dazu löschen Sie bitte den die Nutzerdaten enthaltenden Tablespace USERSPACE1 Ihrer Datenbank ADMIN. Sie können das entsprechende Verzeichnis mit Hilfe der Spalte CONTAINER_NAME der Tabellenfunktion MON_GET_CONTAINER ermitteln. Löschen Sie das ermittelte Verzeichnis und die darin bendlichen Dateien mit den UNIX-Befehlen rm und rmdir. Überprüfen Sie anschlieÿend, ob Sie danach noch auf die Datenbank zugreifen und Datensätze selektieren können, indem Sie die SQL-Anfrage aus der Teilaufgabe d) erneut ausführen. Was passiert und was könnte die Ursache hierfür sein? Versuchen Sie, sich alle Datensätze der Tabelle SUPPLIER anzeigen zu lassen und erläutern Sie das Resultat. Beenden Sie die Verbindung und stoppen Sie Ihre Instanz. Starten Sie sie erneut, stellen Sie eine Verbindung zur Datenbank her und lassen Sie sich erneut den Inhalt der Tabelle SUPPLIER anzeigen. Nennen und begründen Sie kurz das Resultat. f) Was können Sie jetzt tun, um die Datenbank wiederherzustellen? Führen Sie eine geeignete Wiederherstellung der Datenbank aus und dokumentieren Sie die durchgeführten Schritte. 4

5 g) In welchem Stand bendet sich die Datenbank jetzt, d.h. welche Änderungen sind enthalten und welche nicht (Anfrage)? Begründen Sie Ihre Antwort. h) Sie haben aus den festgestellten Problemen gelernt Setzen Sie den Parameter LOGARCHMETH1 auf LOGRETAIN und führen Sie ggf. notwendige Aktionen aus. Wiederholen Sie die Aktionen ab Teilaufgabe c) mit der nun veränderten Konguration. Was passiert jetzt in den einzelnen Schritten? Stellen Sie die Unterschiede im Vergleich zur Aufgabe 6 dar und erläutern Sie diese. Aufgabe 7 (Logischer Fehler*) a) Löschen Sie die Telefonnummern der Kunden mit den IDs 189 und 2378, indem Sie sie auf NULL setzen. b) Löschen Sie die Tabelle REGION unter Verwendung des SQL-Befehls DROP TABLE. c) Setzen Sie die Adresse des Lieferanten (Tabelle SUPPLIER) mit der ID 16 auf Ernst-Abbe-Platz 1. d) Das Löschen der Tabelle REGION stellt sich jetzt im Nachhinein als (logischer) Fehler heraus. Was können Sie als Datenbankadministrator tun, um diesen Fehler rückgängig zu machen? Führen Sie eine geeignete Fehlerbehandlung durch und dokumentieren Sie die ausgeführten Aktionen. Hinweis: Ein Wiederholen aller ausgeführten Anweisungen wird nicht als geeignete Fehlerbehandlung akzeptiert, da dies in einer realen Datenbankanwendungsumgebung viel zu aufwendig wäre. Beheben Sie den Fehler mit Hilfe von vorhandenen Recovery-Mechanismen, welche Ihnen DB2 zur Verfügung stellt. e) Welche Änderungen sind im Anschluss an die Recovery in der Datenbank enthalten und welche nicht? Welche Vorsorgemaÿnahmen können Sie mit Recovery-Mechanismen des Datenbanksystems treen, damit zukünftige (irrtümliche) DROP TABLE-Anweisungen komplikationsloser zurückgenommen werden können. Dokumentieren Sie analog zu den Teilaufgaben a) bis d) ein solches Szenario. Aufgabe 8 (Probleme bei der Log-Protokollierung I) Setzen Sie vor der Bearbeitung der Aufgabe die Datenbank ADMIN durch Löschen und erneutes Anlegen auf ihren Ausgangszustand zurück (admin_db -f). Verringern Sie die zu verwendende Gröÿe der Protokolldateien auf 4 Seiten und die Anzahl der Protokolldateien auf 3 primäre sowie 4 sekundäre. Die Protokolldateien sollen im Verzeichnis /logs/ gespeichert werden. a) Kopieren Sie sich den Quelltext für das Programm buchungen von db2i00/src/ in ein lokales Verzeichnis und übersetzen Sie das Programm 3. Mit diesem Programm können Sie eine beliebige Anzahl an Datensätzen in die Tabelle ORDERS einfügen. b) Fügen Sie nun 700 Datensätze mittels buchungen in die Tabelle ORDERS ein. Was passiert? Wie können Sie das aufgetretene Problem lösen? Beschreiben und testen Sie mindestens drei verschiedene Lösungsansätze. Hinweis: Die verschiedenen Möglichkeiten zur Vergröÿerung des Speichers für Logs (Gröÿe und/oder Anzahl der Log-Dateien) zählen nur als ein Ansatz und nicht jeder Parameter oder jede Kombination zählt als ein neuer. c) Zeigen Sie durch eine geeignete SQL-Anfrage, dass es Ihnen gelungen ist, die vom Programm durchzuführenden Änderungen in die Datenbank einzubringen. Aufgabe 9 (Probleme bei der Log-Protokollierung II*) Setzen Sie vor der Bearbeitung der Aufgabe die Datenbank ADMIN durch Löschen und erneutes Anlegen auf ihren Ausgangszustand zurück (admin_db -f). Verringern Sie wiederum die zu verwendende Gröÿe der Protokolldateien auf 4 Seiten und die Anzahl der Protokolldateien auf 3 primäre sowie 4 sekundäre. Die Protokolldateien sollen im Verzeichnis /logs/ gespeichert werden. a) Starten Sie das Programm buchungen mehrfach hintereinander (z.b. 10 Versuche), wobei Sie jeweils einen einzelnen Datensatz einfügen. Ermitteln Sie nach jedem Versuch die Anzahl der angelegten 3 Den nötigen C-Compiler cc nden Sie in /usr/vac/bin/. 5

6 Log-Dateien. Ist das Ergebnis überraschend? Begründen Sie. Hinweis: Stellen Sie sicher, dass auÿer über buchungen keine weiteren Verbindungen zu Ihrer AD- MIN-Datenbank bestehen. Dazu können Sie das DB2 Kommando LIST APPLICATIONS verwenden. b) Schreiben Sie ein einfaches Programm, genannt own, in C oder Java, welches eine lang laufende Transaktion simuliert. Solche Transaktionen, die über mehrere Stunden oder Tage laufen, kommen in neuen Datenbankanwendungsgebieten, wie Workowmanagementsystemen oder CAD- Systemen, häuger vor. Die von Ihnen zu simulierende Transaktion soll zunächst eine Änderung in irgendeiner der Tabellen der Datenbank ADMIN (nicht jedoch auf der Tabelle ORDERS) ausführen und danach beliebig lange laufen, d.h. nicht terminieren und dabei auch keine weiteren Änderungen auf der Datenbank ausführen. Legen Sie den Programm-Quelltext der Lösung bei. c) Starten Sie Ihr Programm own und danach mehrfach (z.b. 15 mal) das Programm buchungen, wobei buchungen jeweils 20 Datensatze einfügen soll. Ermitteln Sie nach jedem Versuch die Anzahl der angelegten Log-Dateien. Was passiert und warum? Welche Lösungsmöglichkeiten gibt es für eventuell aufgetretene Probleme? Aufgabe 10 (Archivierung von Protokolldateien) Setzen Sie vor der Bearbeitung der Aufgabe die Datenbank ADMIN durch Löschen und erneutes Anlegen auf ihren Ausgangszustand zurück (admin_db -f). Verringern Sie ein letztes Mal die zu verwendende Gröÿe der Protokolldateien auf 4 Seiten und die Anzahl der Protokolldateien auf 3 primäre sowie 4 sekundäre. Die Protokolldateien sollen im Verzeichnis /logs/ gespeichert werden. Log-Dateien werden in der Regel separat auf eine schnelle Platte gespeichert. Aufgrund deren beschränkter Speicherkapazität ergibt sich oft die Notwendigkeit, abgeschlossene Log-Dateien, die für den laufenden Betrieb nicht mehr benötigt werden, an anderer Stelle zu archivieren, um Sie dort für Recovery-Zwecke zur Verfügung zu halten. Dies kann in DB2 je nach Wert des Parameters LOGARCHMETH1 manuell durch den Administrator initiiert oder beispielsweise durch ein sogenanntes User Exit-Programm automatisiert werden. Der User Exit wird, nachdem er installiert und DB2 bekannt gemacht wurde, von DB2 aufgerufen, sobald eine Log-Datei voll und abgeschlossen ist. In der vorliegenden Aufgabe sollen Sie einen solchen User Exit für die Datenbank ADMIN erproben und deren Log-Dateien auf einer simulierten Archivplatte (als Unterverzeichnis) archivieren. Detaillierte Informationen zum User Exit nden Sie im DB2 Information Center unter Database administration High availability Administering and maintaining a highly available solution Log le management. a) Machen Sie sich mit dem Beispiel-Quelltext für ein User Exit-Programm db2uext2.cdisk vertraut. Sie nden diesen unter /sqllib/samples/c/. Modizieren Sie diesen so, dass das Verzeichnis /logarchiv/ als Archivplatte für Ihre ADMIN-Datenbank benutzt wird, indem Sie den in den Quelltextkommentaren gegebenen Hinweisen folgen. b) Kompilieren und installieren Sie diesen User Exit für Ihre Instanz. Beachten Sie, dass der User Exit auch in der Konguration aktiviert werden muss. Sichern Sie anschlieÿend Ihre Datenbank. Stellen Sie jetzt und nach jeder der folgenden Teilaufgaben fest, welche Log-Dateien sich im Pfad für die aktuellen Logdateien (Datenbankkongurationsparameter Path to log les) und welche sich auf der Archivplatte benden. c) Ermitteln Sie die Tupelanzahl der Tabelle ORDERS und beenden die Transaktion erfolgreich (COMMIT). d) Fügen Sie mit dem Programm buchungen 100 Tupel in die Tabelle ORDERS ein. e) Fügen Sie wie in Teilaufgabe d) weitere 100 Tupel ein. f) Angenommen ein Fehlerfall sei eingetreten. Stellen Sie unter Zuhilfenahme der in Aufgabe 10b erstellten Datenbanksicherung und den archivierten Protokolldateien einen möglichst aktuellen Datenbankzustand wieder her. Wieviele Tupel sind jetzt in ORDERS enthalten? Wurden die archivierten Log-Dateien bei der Recovery benutzt? g) Erörtern Sie mindestens zwei Vor- und zwei Nachteile beim Einsatz eines User Exit-Programms. 6