Backup & Recovery · ASPICON Newsarchiv

DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen

Isabel Dahl — Thu, 20 Feb 2025 14:20:16 +0000

Home → Backup & Recovery

DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen

Verfasst von Isabel Dahl
20 Februar 2025
15:20
Backup & Recovery, Datenbank, DBA Tipp, Oracle, Praxistipp

Oracle bietet in seinen Datenbankprodukten das Feature Flashback an. Mittels Flashback ist es möglich, einzelne Daten in der Datenbank oder die komplette Datenbank zu einem früheren Zeitpunkt wiederherzustellen. Dabei werden die Daten durch logische Operationen wiederhergestellt, wie beispielsweise durch Zurückrollen von Transaktionen.

In diesem DBA Tipp beschäftigen wir uns mit den Voraussetzungen für die Nutzung von Oracle Flashback und stellen dir die verschiedenen Varianten sowie deren Einsatzgebiete vor.

Voraussetzungen für die Nutzung von Oracle Flashback

Voraussetzung für die Nutzung der Flashback-Technologie ist ein großer Undo-Tablespace, um hinreichend viele Daten für Flashbackoperationen zur Verfügung zu stellen. Da die benötigte Größe des Undo-Tablespaces sehr stark von den Änderungen in der Datenbank abhängt, bietet sich hier das Auto Extend für den Tablespace an. Die Retention Guarantee stellt dabei sicher, dass die Undo-Daten ausreichend lange im Undo-Tablespace vorgehalten werden.

Flashback-Varianten und ihre Einsatzgebiete

1. Flashback Query

Mit Flashback Query werden alle Daten zu einem spezifischen Zeitpunkt abgefragt. Es werden hier keine Datenänderungen durchgeführt. Flashback Query ist auf der geöffneten Datenbank (online) durchführbar und bereits in der Standard Edition 2 enthalten.

2. Flashback Transaction Query*

Für die Diagnose von durch User oder Anwendungen verursachten logischen Fehlern eignet sich die Flashback Transaction Query. Innerhalb eines bestimmten Zeitraums durchgeführte Transaktionen und dazugehörige Metadaten können mittels Flashback Transaction Query abgefragt und ausgegeben werden.

3. Flashback Version Query

Mit der Flashback Version Query können verschiedene Versionen einer Zeile innerhalb eines vorgegebenen Zeitraums ausgegeben werden. Dabei werden u.a. die Start- und End-SCN, die Start- und Endzeit für die Gültigkeit dieser Version, sowie die jeweilig durchgeführten Operationen (Insert, Update, Delete) ausgegeben, die zu der Version dieser Zeile führten.

4. Flashback Transaction*

Mit Flashback Transaction ist es möglich, einzelne Transaktionen zurückzurollen, so dass Daten, die durch Statements in dieser Transaktion geändert wurden, anschließend wieder im ursprünglichen Zustand vorliegen. Diese Variante führt DML-Statements aus bzw. rollt diese zurück.

5. Flashback Table – gelöschte Tabelle wiederherstellen*

Um eine gelöschte Tabelle wiederherzustellen, muss sich diese noch im ‘Recycle Bin’ befinden. Der Undo-Tablespace wird hierfür nicht benötigt und die Operation kann online durchgeführt werden. Wurde die gelöschte Tabelle aus dem ‘Recycle Bin’ gelöscht, lässt sie sich nur noch durch ein Flashback Database oder mittels Point-in-Time-Recovery wiederherstellen. Beides würde jedoch die komplette Datenbank verändern und auf einen früheren Zeitpunkt zurücksetzen.

6. Flashback Table – Tabelle zum früheren Zeitpunkt wiederherstellen*

Um Daten einer Tabelle mittels Flashback zu einem früheren Zeitpunkt wiederherstellen zu können, müssen die entsprechenden Daten noch im Undo-Tablespace vorhanden sein. Zudem dürfen zwischen dem gewünschten Wiederherstellungszeitpunkt und dem aktuellen Zeitpunkt keine DDL Statements ausgeführt worden sein, die die Struktur der Tabelle geändert haben. Ein Flashback Table wird abgebrochen, wenn während der Flashback Operation Constraints der Tabelle verletzt werden. Die Tabelle wird in diesem Fall nicht geändert. Die Operation ist online durchführbar, läßt sich jedoch nicht auf System-Tabellen anwenden.

7. Flashback Database*

Mit Flashback Database kann die Datenbank zeitlich in einen früheren Zustand versetzt werden, vergleichbar mit dem Zurückspulen eines Tonbands. Ein Restore aus dem Backup und ein Point-in-Time-Recovery führt zwar zum selben Ergebnis, braucht aber in den meisten Fällen mehr Zeit.

Für ein Flashback Database werden die sogenannten Flashback Logs benötigt, die in der Fast Recovery Area abgelegt werden. Zusätzlich kann ein Flashback Retention Target festgelegt werden, dass das obere Limit in Minuten festlegt, wie weit das Flashback Database maximal zurückgehen kann. Voraussetzung hierfür ist hinreichend viel Platz in der Fast Recovery Area, um die Menge an Flashback Logs vorhalten zu können.

Wird ein Datenfile nach dem Aktivieren des Flashback Database gelöscht, kann es mittels Flashback Database nicht wiederhergestellt werden. Für Flashback Database muss die Datenbank im Exclusive Mode sein.

8. Flashback Time Travel (vorher: Flashback Data Archive)

Daten über einen langen Zeitraum zu archivieren und dabei jede Änderung mitzuverfolgen, fällt in den Bereich des Flashback Time Travel, früher Flashback Data Archive genannt. Dabei werden Änderungen an entsprechend berücksichtigten Tabellen ‘getrackt’ und im Flashback Archive abgelegt. Mit den Flashback Queries können dann die Daten zu jedem beliebigen Zeitpunkt in der Vergangenheit – soweit er in die Retention Policy des Flashback Archive fällt – abgefragt werden. Daten die außerhalb der Retention Policy liegen, werden automatisch gelöscht.

Basic Flashback Time Travel steht bereits in der Standard Edition 2 zur Verfügung. Optimization for Flashback Time Travel benötigt die Oracle Advanced Compression Option und steht daher nur in der Enterprise Version zur Verfügung.

* Für die Nutzung ist die Enterprise Edition nötig.

Fazit

Flashback bietet viele Möglichkeiten, logisch verlorene Daten wiederherzustellen oder alte Daten anzusehen und zu vergleichen. Mit Ausnahme von Flashback Query und Flashback Time Travel (als Basic Variante) stehen jedoch alle Flashback Varianten erst in der Enterprise Edition zur Verfügung. Vorausgesetzt, es ist hinreichend Speicherplatz verfügbar, steht dann bei passender Konfiguration einem Sprung in die Vergangenheit nichts mehr im Weg.

Hier findest du weitere Infos rund um Oracle aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Mit Oracle Flashback in die Vergangenheit springen erschien zuerst auf ASPICON.

Wer hat Angst vorm nicht funktionierenden Backup?

Dirk Melzer — Wed, 30 Oct 2024 11:02:40 +0000

Home → Backup & Recovery

Wer hat Angst vorm nicht funktionierenden Backup?

Verfasst von Dirk Melzer
30 Oktober 2024
12:02
Backup & Recovery, Praxistipp

Pünktlich vor Halloween haben wir heute ein ganz besonders gruseliges Thema für dich – Backups!

Backups sind eigentlich absolute Basisarbeit, wenn es darum geht, im Rahmen des Risikomanagements einen reibungslosen Geschäftsablauf (Business Continuity) zu gewährleisten. Eine Backup-Policy ist dabei ein kritischer Bestandteil der IT-Sicherheitsstrategie jeder Organisation. Hier sind klare Standards und Verfahren für die Sicherung (Backup) und Wiederherstellung (Restore) von Daten festgelegt. Sie stellt sicher, dass geschäftskritische Informationen auch bei unvorhergesehenen Ereignissen geschützt bleiben. Sie ist demnach ein fundamentaler Bestandteil der Business Continuity Planung. Organisationen, die regelmäßig und systematisch ihre Backups testen und ihre Backup-Policy aktualisieren, sind optimal für Notfälle vorbereitet und können ihre Geschäftstätigkeit auch in Krisensituationen stabil und nachhaltig fortführen.

Diese Fragen zum Thema Backup solltest du dir stellen

Jeder weiß es und jeder macht es – soweit die Theorie. Und nun zur Praxis: Backups sind aus unserer Erfahrung nach wie vor das Thema, was am liebsten vernachlässigt wird. Einmal eingerichtet, läuft es schon irgendwie. Bis zu dem Tag, an dem es tatsächlich mal gebraucht wird. Dann steht man ganz schnell vor Fragen, wie:

Ist mein Backup eigentlich konsistent oder einfach ausgedrückt, was mache ich jetzt, wenn mein Backup genauso kaputt ist wie meine Datenbank?
Wie spiele ich jetzt am besten mein Backup zurück und auf welchem Stand ist die Datenbank dann?
Wie lange dauert das Rückspielen des Backups?

Das sind nur einige Fragen, die genau dann hochkommen, wenn man die wenigste Zeit dafür hat, diese Fragen in Ruhe zu beantworten – nämlich im Desasterfall. Dabei geht es in erster Linie nicht darum, dass das Backup-Tool nicht richtig funktioniert. Die Probleme sind hier oft hausgemacht. Denn im stressigen Arbeitsalltag gehen nun mal allzu leicht gewisse “Routineaufgaben” unter. Und ehrlicherweise stehen diese Aufgaben auch meistens nicht unbedingt auf der Lieblings-Todo-Liste. Aber es ist enorm wichtig, denn nach wie vor gilt die Devise:

NO BACKUP – NO SORRY!

Daher hier noch einmal die wichtigsten Schritte für ein funktionierendes Backup zusammengefasst:

Neben der periodischen Überprüfung der aktuellen Backup Policy gehört auch die Frage, ob ausreichend Plattenplatz für die Backups zur Verfügung steht. Denn nur so lässt sich die Backup Policy auch planmäßig umsetzen. Ist der Speicherplatz für die Backups erschöpft und es werden deshalb keine Backups mehr geschrieben, wird die Datenbank früher oder später mit einem vollen Archive-Log-Bereich stehen bleiben! Hier kann im Bedarfsfalls ein geeignetes Monitoring helfen, rechtzeitig auf Speicherengpässe hinzuweisen. Bitte beachte, dass der Backup Speicherplatz oft ein Vielfaches der Speicherkapazität der zu sichernden Datenbank benötigt. Denn hier gilt: Ein altes Backup wird erst dann gelöscht, wenn das neue Backup geschrieben wurde.

Eine der unbequemsten Fragen überhaupt ist, ob das Backup auch konsistent ist. Tatsächlich sind korrupte Backups gar nicht so selten – idealerweise natürlich auch immer dann, wenn das Backup zugleich die einzige “Verfügbarkeitsstrategie” ist. Auch hier gibt es entsprechende Monitoringmechanismen, um die Konsistenz eines Backups kontinuierlich zu überprüfen. Kleiner Praxis-Tipp: das möglicherweise ohnehin regelmäßig nötige Aktualisieren einer Testdatenbank ist stets ein guter Restoretest, wenn man sie aus dem Backup der Produktivdatenbank clont.

Wenn diese Punkte alle soweit in Ordnung sind, stellt sich letztendlich die Frage: Wie lange brauche ich, um eine Datenbank aus meinem Backup wiederherzustellen und vor allem, wie mache ich das?

Nun, die Antwort ist relativ einfach: TESTEN! Gerade bei großen Datenmengen kann die vollständige Wiederherstellung einer Datenbank mehrere Tage in Anspruch nehmen. Das ist unter “Business Continuity” Gesichtspunkten nicht wirklich hilfreich und sinnvoll. So heißt es in dem Fall: alles auf Anfang zurück und die Backup Policy respektive auch das Verfügbarkeitskonzept als Ganzes überdenken.

Deine Checkliste

Hier nochmal die Mini-Checkliste in Kurzform:

Überprüfung Backup Policy
Überprüfung Backup Consistency
Überprüfung Backup Space
Restore-Test
Periodische Wiedervorlage der Checkliste

Du benötigst Unterstützung? Wir sind gern für dich da!

Kontakt

Hier findest du weitere Posts zu Backup / Recovery aus unserem News Bereich.

Share this article

Der Beitrag Wer hat Angst vorm nicht funktionierenden Backup? erschien zuerst auf ASPICON.

DBA Tipp: Wie du dich für das richtige SQL Server Wiederherstellungsmodell entscheidest

Tobias Braun — Wed, 25 Sep 2024 08:38:26 +0000

Home → Backup & Recovery

DBA Tipp: Wie du dich für das richtige SQL Server Wiederherstellungsmodell entscheidest

Verfasst von Tobias Braun
25 September 2024
10:38
Backup & Recovery, Datenbank, DBA Tipp, Microsoft, SQL Server

Die Frage “Welches SQL Server Wiederherstellungsmodell ist das richtige für mich?” ist nicht immer so leicht zu beantworten, das erleben auch wir als Dienstleister bei unseren Kunden immer wieder. Falls du dir jetzt von diesem DBA Tipp eine einfache Antwort auf die Frage erhoffst und womöglich noch eine Pro- und Contra-Liste erwartest, solltest du vielleicht besser aufhören zu lesen. Denn – Spoiler Alarm: Es gibt kein pauschales “Besser” oder “Schlechter” der einzelnen Modelle.

Was es allerdings durchaus gibt, sind einige Überlegungen und Kernfragen, die du dir im Vorfeld unbedingt stellen solltest und die dir dabei helfen werden, künftig die richtige Wahl zu treffen. Also, falls du gewillt bist, etwas tiefer in die Materie der SQL Server Wiederherstellungsmodelle einzusteigen, um den Entscheidungsprozess künftig zu beschleunigen, ließ gern weiter.

SQL Server Wiederherstellungsmodell ist nicht gleich Sicherungsmodell!

Zu Beginn noch eine kurze Rekapitulation: Es heißt aus guten Grund “Wiederherstellungsmodell” und nicht etwa “Sicherungsmodell”. Schließlich legst du mit dem SQL Server Wiederherstellungsmodell fest, wie du im Falle einer Wiederherstellung von Tabellen und Zeilen vorgehen möchtest. Dieser Gedanke wird nicht selten vergessen, wenn man die Datensicherungsstrategie plant. Hinzu kommt, dass eine potentielle Wiederherstellung nicht erst nach Hardware-Ausfällen oder nach größeren Katastrophen notwendig wird, sondern auch (oder ganz besonders) aufgrund der “von innen ausgehenden Gefahren” (siehe Frage 5 im nächsten Abschnitt) durchgeführt werden muss.

Grundsätzlich unterscheidet man im Microsoft SQL Server Bereich drei Wiederherstellungsmodelle:

Das einfache Wiederstellungsmodell
Das vollständige Wiederherstellungsmodell
Das massenprotokollierte Wiederherstellungsmodell

Die richtigen Fragen, um das richtige SQL Server Wiederherstellungsmodell zu finden

Um sich völlig zu vergegenwärtigen, wie sich die drei möglichen Modelle von einander unterscheiden, solltest du nicht nur die klassischen Indikatoren im Blick haben, sondern auch die “stressverursachenden” Einflüsse beachten. Hier einige Beispiele dafür:

Klassische Indikatoren

Dauer der Wiederherstellung
Aufwand der Wiederherstellung (für den Admin)
Platzbedarf der Backups
Größe des Transaktionsprotokolls

Stressverursachende Einflüsse

Relevanz aktueller Daten für Fachanwender
Relevanz aktueller Daten für Entscheidungsträger
Bedeutung der Differenz zwischen aktuellen und gesicherten Daten
Möglichkeiten der (Wieder)Beschaffung nicht im Backup enthaltener Daten

Darüber hinaus sind die folgenden 5 Überlegungen geradezu essenziell, wenn du vor der Frage des sinnvollsten SQL Server Wiederherstellungsmodells für deine Datenbank stehst:

5 Fragen, die dir dabei helfen, das richtige Wiederherstellungsmodell zu finden

1. Welche Relevanz hat die Datenbank, auch im Hinblick auf die Aufrechterhaltung des Unternehmens?

Handelt es sich um eine ERP-Datenbank mit über 1000 Kunden und Lieferanten oder lediglich um ein Intranet mit mäßig brisanten Informationen?

Müssen ein Dutzend Fachanwender die verlorenen Daten erneut eingeben oder ist die Anwendung in der Lage, die fehlenden Daten aus dem alten Datenstand zur errechnen?

Stehen diverse produktionskritische Systeme und Anlagen still oder wird der Ausfall der Datenbank für bis zu 48 Stunden gar nicht bemerkt?

2. Welche Änderungen finden in den Tabellen/Zeilen statt?

Handelt es sich um eine 24/7‑Datenbank, die immer unter Last steht oder erfolgen nur sporadische Änderungen?

Werden Datensätze gleichmäßig (also ohne erkennbare Pause) geändert oder erfolgt der hauptsächliche Schreibzugriff nur in der Kernarbeitszeit?

Sind die fehlenden Daten (nach einer Wiederherstellung) komplett verloren oder kann eine Fachanwendung eine geringe Menge an Daten erneut in die Datenbank einfügen?

3. Wie viel Zeit ist nötig, um den aktuellsten Stand der Datensicherung einzuspielen?

Wie lange dauert eine komplette Wiederherstellung?

Ist die Dauer des Wiederherstellungsprozesses relevant für den Geschäftsbetrieb?

4. Sind externe Datensicherungslösungen daran beteiligt?

Wird ein Drittanbieterprodukt (wie beispielsweise Veeam) zur Datenbanksicherung verwendet oder kommen nur klassische SQL Server Agent Jobs zum Einsatz?

Wird der Host virtuell betrieben und per Snapshot gesichert? Wie oft werden die Snapshots angefertigt?

5. Mit welchen internen Fallstricken ist möglicherweise zu rechnen?

Kommt es ab und zu vor, dass die Programm-Updates der Fachanwendungen eine unangenehme Auswirkung auf die Datenbank haben?

Neigen Fachanwender dazu, Daten unbeabsichtigt zu löschen oder zu verändern?

Einfaches vs. vollständiges SQL Server Wiederherstellungsmodell

Hast du dir nun ein Bild von der Relevanz deiner Datenbanken gemacht, so fällt es wesentlich leichter, die Wiederherstellungsmodelle (man könnte auch sagen “Strategien zur Wiederherstellung”) für jede einzelne Datenbank festzulegen.

Da die Unterschiede zwischen dem massenprotokollierten und dem vollständigen Modell zu vernachlässigen sind, fassen wir diese beiden Modelle in der weiteren Betrachtung zusammen. Damit unterscheiden wir im Folgenden lediglich zwischen dem einfachen und dem vollständigen Wiederherstellungsmodell:

Das einfache SQL Server Wiederherstellungsmodell

Kann nur verwendet werden, um eine ganze Datenbank auf den Zeitpunkt eines vergangenen Komplett-Backups wiederherzustellen.
Ermöglicht komplette und differentielle Datenbank-Backups.
Ermöglicht keinerlei Transaktionsprotokoll-Backups.
Sorgt für ein eher kleines Transaktionsprotokoll.

Das vollständige SQL Server Wiederherstellungsmodell

Kann verwendet werden, um eine Datenbank auf den Zeitpunkt eines vergangenen Komplett-Backups und darauf aufbauender Transaktionsprotokoll-Backups wiederherzustellen.
Ermöglicht komplette und differentielle Datenbank-Backups.
Ermöglicht und erfordert zusätzlich auch Transaktionsprotokoll-Backups.
Sorgt meist für ein mittelgroßes Transaktionsprotokoll.

Zwischenfazit

Auf die jeweils erste Eigenschaft kommt es bei der Entscheidung an. Denn während man unter Verwendung des einfachen Wiederherstellungsmodells eine Datenbank nur auf den Datenstand zum exakten Zeitpunkt der Komplettsicherung zurückspielen kann, ist bei Verwendung des vollständigen Wiederherstellungsmodells nahezu jeder Zeitpunkt nach der Komplettsicherung möglich. Und eben genau darauf sollte deine Überlegung abzielen: Der Anspruch an die gezielte Wiederherstellbarkeit einzelner Datensätze. Denn wenn die Änderungen einzelner Aktionen in den Tabellen “ungeschehen gemacht” werden sollen, dann scheidet das einfache Wiederherstellungsmodell aus.

Fazit

Das SQL Server Wiederherstellungsmodell entscheidet maßgeblich darüber, wie granular eine Wiederherstellung durchgeführt werden kann.

Kannst du mit einem theoretischen Datenverlust leben, der sich vom Zeitpunkt des letzten Komplett-Backups bis zum Ausfall ergibt? Dann kann das einfache Wiederherstellungsmodell genügen.

Suchst du nach einem Weg, den theoretischen Datenverlust so weit wie möglich zu minimieren, indem du die Zeit zwischen zwei Komplett-Backups mit diversen kleineren Backups überbrückst? Dann bleibt nur das vollständige Wiederherstellungsmodell übrig.

Die Entscheidung für oder gegen ein bestimmtes Wiederherstellungsmodell wird also durch die maximal tolerierbare Menge an verlorenen Daten bestimmt. Als Faustregel gilt, dass mit steigender Anforderung an einen möglichst hohen/aktuellen Datenstand, die Entscheidung auf das vollständige Wiederherstellungsmodell hinausläuft. Bedenke jedoch, dass auch das vollständige Modell und sehr häufige Transaktionsprotokoll-Backups bei produktionskritischen Datenbanken kein Ersatz für eine Hochverfügbarkeitslösung darstellt.

Solltest du trotz der genannten Überlegungen nicht sicher sein, welches
SQL Server Wiederherstellungsmodell für welche deiner Datenbanken das richtige ist,
ruf uns gern an oder schreibe uns.

Kontakt

Hier findest du weitere Infos zum Thema » Microsoft SQL Server aus unserem News & Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Wie du dich für das richtige SQL Server Wiederherstellungsmodell entscheidest erschien zuerst auf ASPICON.

DBA Tipp: Drei Punkte Plan, um den DBMS_SCHEDULER für Backups zu nutzen

The hidden DBA — Mon, 24 Jun 2024 06:18:00 +0000

Home → Backup & Recovery

DBA Tipp: Drei Punkte Plan, um den DBMS_SCHEDULER für Backups zu nutzen

Verfasst von The hidden DBA
24 Juni 2024
08:18
Backup & Recovery, Datenbank, Hidden Feature, Oracle, Oracle Database, Oracle Datenbank 12c /18c /19c /21c, Oracle Datenbank 23ai

Die Einrichtung von Datenbank-Backups mit RMAN ist einfach. Aber welchen Scheduler nutzt man im besten Fall? Alle Betriebssysteme, seien es Windows mit den “Geplanten Tasks” oder Linux mit dem “crontab”-System bieten hierfür eine Lösung: den “DBMS_SCHEDULER”.

Der DBMS_SCHEDULER ist ein Paket in Oracle Database (seit Version 12.1), mit dem du Aufgaben planen und automatisieren kannst. Er bietet eine Reihe von Funktionen zum Erstellen, Verwalten und Ausführen von Jobs, die aus PL/SQL-Prozeduren, Skripten oder externen Programmen bestehen können.

Wie du den DBMS_SCHEDULER für deine Backups nutzt

Die Vorteile des Tools sind klar:

Planung von Aufgaben:
Du kannst Jobs so planen, dass sie zu bestimmten Zeiten oder in Intervallen ausgeführt werden, etwa täglich, wöchentlich oder monatlich.
Automatisierung von Aufgaben:
Du kannst Aufgaben automatisieren, die sonst manuell ausgeführt werden müssten, wie eben beispielsweise Datensicherungen, aber auch die Bereinigung von Daten oder das Senden von Berichten.
Verbesserte Zuverlässigkeit:
Der DBMS_SCHEDULER kann fehlgeschlagene Jobs neu starten.
Erhöhte Effizienz:
Der DBMS_SCHEDULER kann dazu beitragen, die Effizienz deiner Datenbank zu verbessern, indem er zeitaufwändige Aufgaben automatisiert und die Arbeitslast auf dem System verteilt.

Aber wie kannst du nun den DBMS_SCHEDULER für deine Backups nutzen? Wir haben einen Drei Punkte Plan für dich zusammengestellt:

1. Credentials anlegen

    begin
       -- create the credential for operating system access
       dbms_credential.create_credential(credential_name => 'OS_CREDENTIAL',
                                         username        => 'oracle',
                                         password        => 'oracle',
                                         enabled         => true,
                                         comments        => 'OS credentials for backup jobs');

       -- create credential to provide RMAN with database access
       dbms_credential.create_credential(credential_name => 'DB_CREDENTIAL',
                                         username        => 'sys',
                                         password        => 'oracle',
                                         database_role   => 'sysdba',
                                         enabled         => true,
                                         comments        => 'DB credentials for backup jobs');
       end;
       /

2. Backup – Datenbank Full

    begin
       dbms_scheduler.create_job(        job_name        => 'DAILY_BACKUP_FULL',
                                         job_type        => 'BACKUP_SCRIPT',
                                         job_action      => 'run { backup check logical database plus archivelog not
                                                            backed up;' ||
                                                            'delete noprompt archivelog until time ''sysdate-1'';' ||
                                                            'delete noprompt obsolete; }',
                                         start_date      => trunc(sysdate),
                                         repeat_interval => 'freq=daily;byhour=23;byminute=00;bysecond=0',
                                         credential_name => 'OS_CREDENTIAL',
                                         enabled         => false,
                                         auto_drop       => false,
                                         comments        => 'backup job database full (daily execution)');
       -- add the db credential to the job.
       -- this can't be done in the create_job call
       dbms_scheduler.set_attribute(     name            => 'DAILY_BACKUP_FULL',
                                         attribute       => 'CONNECT_CREDENTIAL_NAME',
                                         value           => 'DB_CREDENTIAL');
       -- after enabling the job, backups are made according to the schedule
       dbms_scheduler.enable(            name            => 'DAILY_BACKUP_FULL');
     end;
     /

3. Logging und Fehlersuche

set linesize 10000
 col job_name format a40
 col schedule_name format a40
 col schedule_type format a40
 select job_name, start_date, next_run_date,LAST_START_DATE,LAST_RUN_DURATION from dba_scheduler_jobs where schedule_type like 'CALENDAR' and job_name like 'DAILY%';
 select job_name, enabled from DBA_SCHEDULER_JOBS where job_name like 'DAILY%';

 select session_key, to_char(start_time, 'DD-MON-YYYY HH24:MI:SS') START_TIME from v$rman_backup_job_details where status!='COMPLETED' order by start_time;
 select output from v$rman_output where session_key=;

Fazit

Zusammenfassend lässt sich sagen, dass der DBMS_SCHEDULER ein leistungsstarkes Tool für die Automatisierung von Datenbank-Backups und anderen zeitkritischen Aufgaben sein kann. Unabhängig von der Aufgabenverwaltung eines Betriebssystems ist es somit möglich, Backups sorgenfrei laufen zu lassen und damit die Datensicherheit und ‑verfügbarkeit in deiner Umgebung zu verbessern.

Leider gibt es eine Einschränkung: Eine physische Standby-Datenbank hat kein aktives Scheduler-System. Will man hierbei Backups ressourcenschonend von der Datenbankkopie laufen lassen, muss man von Skripten und der systemeigenen Aufgabenplanung Gebrauch machen.

Hier findest du weitere Features und Infos aus der Welt von Oracle aus unserem News & Insights Bereich. Wichtige Lizenzierungsinfos rund um RMAN Repository und Oracle Secure Backup findest du auf unserer Datenbank-Lizenzen-Seite.

Share this article

Der Beitrag DBA Tipp: Drei Punkte Plan, um den DBMS_SCHEDULER für Backups zu nutzen erschien zuerst auf ASPICON.

DBA Tipp: Backupkomprimierung des Microsoft SQL Servers zur Verkleinerung der Backups

Jens Böttcher — Fri, 16 Jun 2023 13:52:48 +0000

Home → Backup & Recovery

DBA Tipp: Backupkomprimierung des Microsoft SQL Servers zur Verkleinerung der Backups

Verfasst von Jens Böttcher
16 Juni 2023
15:52
Backup & Recovery, Datenbank, DBA Tipp, Microsoft, SQL Server

Durch den Ausfall einer Platte mit Datenbankdateien oder durch das unbeabsichtigte Löschen/Überschreiben von Daten bzw. Tabellen kann es schnell zu Datenverlust kommen. Regelmäßige Datenbank Backups gehören daher zu den wichtigsten Maßnahmen um zu verhindern, dass unternehmenskritische Informationen verloren gehen. Backups großer Datenbanken können jedoch das vorgesehene Zeitfenster oder den zur Verfügung stehenden Speicherplatz schnell sprengen. Eine Komprimierung der Backups ist daher empfehlenswert, wenn du diese mit möglichst geringem Zeitaufwand durchführen möchtest und/oder der zur Verfügung stehende Speicherplatz begrenzt ist.

Im Folgenden haben wir ein paar Tipps für dich, was du bei der Backupkomprimierung des Microsoft SQL Servers beachten solltest und mit welcher Abfrage du das Einsparpotential ermitteln kannst.

Der Microsoft SQL Server bietet bereits seit der Version 2008 die Möglichkeit einer Backupkomprimierung an. Während anfangs die Enterprise Edition benötigt wurde, ist diese Funktion seit der Version 2008 R2 auch in der Standard Edition enthalten.

Alternativ kann für große Tabellen oder Indizes auch die Tabellenkomprimierung verwendet werden, um den Speicherbedarf der Datenbank und schlussendlich der Backups zu senken. Bis zum SQL Server 2016 RTM war hierfür die Enterprise Edition obligatorisch. Seit dem SQL Server 2016 SP1 wird die Tabellenkomprimierung auch in der Standard Edition unterstützt.

Um die Backupkomprimierung in der Instanz standardmäßig zu verwenden, muss lediglich der Haken bei „Compress Backup“ unter „Database Settings“ in den Eigenschaften der Instanz gesetzt werden.

Als weitere Möglichkeit kann die Sicherung auch für jedes Backup einzeln konfiguriert werden. Dafür wird einfach die gewünschte Option im Dropdown „Set backup compression“ im Assistenten „Back Up Database“ unter „Backup Options“ ausgewählt.

Das Einsparpotential kannst du über die folgende Abfrage ermitteln:

SELECT bset.database_name
  , CASE bset.type  
      WHEN 'D' THEN 'Database' 
      WHEN 'L' THEN 'Log' 
      WHEN 'I' THEN 'Differential' 
   END AS backup_type
  , CONVERT(DATETIME2(0), bset.backup_start_date)
    AS backup_start_date
  , CONVERT(DATETIME2(0), bset.backup_finish_date)
    AS backup_finish_date
  , DATEDIFF (s, bset.backup_start_date, bset.backup_finish_date)
    AS 'Time To Backup (sec)'
  , ROUND(CONVERT(FLOAT, bset.compressed_backup_size/1024/1024), 2)
    AS 'Compr. Size (MB)'
  , ROUND(CONVERT(FLOAT, bset.backup_size/1024/1024), 2)
    AS 'Uncompr. Size (MB)'
  , FORMAT(CONVERT (FLOAT, bset.compressed_backup_size) /
           CONVERT (FLOAT, bset.backup_size), 'P')
    AS 'Compr. Ratio'
FROM msdb.dbo.backupset AS bset
WHERE database_name = 'AdventureWorks2019'
ORDER BY 
   bset.database_name, 
   bset.backup_finish_date;

Es erscheint nachfolgende Ausgabe:

Falls eine zu sichernde Datenbank allerdings mittels Transparent Data Encryption (TDE) verschlüsselt wurde, wird der Speicherplatz, durch die Backupkomprimierung, bis einschließlich SQL-Server 2014, nicht gesenkt.

Erst ab SQL Server 2016 wird die Komprimierung der Backups von TDE-verschlüsselten Datenbanken unterstützt. Dabei ist zu beachten, dass, bis einschließlich SQL Server 2019 CU4, der Parameter MAXTRANSFERSIZE auf einen Wert größer 65536 gesetzt werden muss. Dieser kann wie über T‑SQL wie folgt gesetzt werden:

BACKUP DATABASE [AdventureWorks2012]
  TO  DISK = N'\\BackupSrv\MSSQL\AW_compressed.bak' 
    WITH
      COMPRESSION,
      MAXTRANSFERSIZE = 65537

Fazit

Eine Komprimierung der Backups ist in vielen Fällen lohnenswert, besonders wenn der zur Verfügung stehende Speicherplatz begrenzt ist. Unabhängig davon sollten Backupgröße und ‑dauer regelmäßig mittels Monitoring überprüft werden. So lassen sich etwaige Probleme – wie z.B. das Volllaufen der Platte oder des Shares – vermeiden.

Du hast Fragen zum Thema Backupkomprimierung oder dem Durchführen von Backups allgemein? Melde dich einfach bei uns. Gern schauen wir gemeinsam mit dir über deine Datenbankinfrastruktur, um Optimierungsmöglichkeiten zu eruieren.

Hier findest du weitere interessante Posts zu den Themen Microsoft und Backup aus unserem News und Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Backupkomprimierung des Microsoft SQL Servers zur Verkleinerung der Backups erschien zuerst auf ASPICON.

DBA Tipp: Zeitgesteuerte Aufgaben im MS SQL Server ohne SQL Server Agent auslösen

Tobias Braun — Tue, 11 Oct 2022 06:11:10 +0000

Home → Backup & Recovery

DBA Tipp: Zeitgesteuerte Aufgaben im MS SQL Server ohne SQL Server Agent auslösen

Verfasst von Tobias Braun
11 Oktober 2022
08:11
Backup & Recovery, Datenbank, DBA Tipp, Microsoft, SQL Server

Wenn für Routineaufgaben zeitgesteuerte Vorgänge im Hintergrund ausgelöst werden sollen kommt im Normalfall der SQL Server Agent zum Einsatz. Beispiele hierfür sind Backups oder Datenbankpflege (Index-Erneuerung). Was passiert aber außerhalb des Normalfalles, wenn der SQL Server Agent aus irgendeinem Grund nicht zur Verfügung steht?

Mögliche Szenarien hierfür können sein:

Der SQL Server Agent startet nicht und eine Reparaturinstallation ist nicht unmittelbar möglich.
Die T‑SQL-Befehle sind in hohem Maße abhängig von den Rückgabewerten oder Ergebnissen anderer Programme.
Ein Vorgang soll in leicht abgewandelter Form auf verschiedenen Datenbank-Servern (Hosts) durchgeführt werden.
Bei Verwendung eines SQL Server Express, oder auch eines SQL Server Express LocalDB.
Eine Ad-Hoc-Lösung auf Hosts, welche nicht aus der Ferne administriert werden können und auch kein SSMS installiert haben.

Unserer Erfahrung nach ist der wohl häufigste Fall eine Umgebung, in der verschiedene Schritte auf einem SQL Server Express automatisiert werden müssen. Daher wird das Thema auch anhand einer kleinen und schlichten Sicherungslösung demonstriert.

Die erläuterte Lösung wurde bewusst simpel gehalten, um in erster Linie das grundlegenden Prinzip zu veranschaulichen. Im Praxiseinsatz empfiehlt es sich, die einzelnen Kommandos nicht als lange Parameter anzugeben, sondern stattdessen Skripte zu verwenden. In einem echten Szenario würde es darauf hinauslaufen, dass die SQLCmd.exe nicht direkt, sondern innerhalb eines Windows-Befehlsskripts (.Cmd) gestartet wird. Außerdem erhöht es den Komfort spürbar, wenn man auch die T‑SQL-Befehle in einem kurzen SQL-Skript unterbringt, welches von der SQLCmd.exe ausgelesen wird. Dazu dient der Parameter -i gefolgt vom Pfad-/Dateinamen der SQL-Skriptdatei.

Zu beachten sind zudem folgende zwei Voraussetzungen hinsichtlich des Benutzerkontos welches verwendet wird, um das Dienstprogramm zu starten.

Auf dem Server, der den Task ausführt (sprich: die SQLCmd.exe startet) muss das Benutzerkonto über die Berechtigung “Als Stapelverarbeitungsauftrag anmelden” verfügen. Darauf weißt der Aufgabenplaner beim Anlegen der Aufgabe auch hin.
Im SQL Server, der die Befehle bearbeitet, muss zu jenem Benutzerkonto eine Anmeldung (Login) auf Instanzebene angelegt sein, das der Serverrolle “serveradmin” angehört.

Außerdem häufen sich mit der Zeit entsprechend viele Sicherungen an, da die gesicherten Transaktionsprotokolle ja nicht überschrieben werden (im Gegensatz zu den Vollsicherungen.) Doch dieses Problem ist nicht Bestandteil dieses DBA Tipps.

Windows Task Scheduler als Lösung

Wie können also Aktionen zur Verwaltung von Routineaufgaben ausgeführt werden, außer von Hand? Die Lösung ist naheliegender, als man vielleicht denkt. Denn obwohl der Aufgabenplaner (englisch “Task Scheduler”) bereits im Windows Server 2008 eine Art Generalüberholung bekam, findet er im Allgemeinen wenig Beachtung. Für die zeitgesteuerte Ausführung von wiederkehrenden Aufgaben eines SQL Servers ist er jedoch gut geeignet, da im Alltag die meisten solcher Aufgaben simple T‑SQL-Statements sind. Und genau die kann man auch anders absetzen, wie sich gleich zeigt.

Mit Hilfe von zwei kleinen Dienstprogrammen im Lieferumfang des SQL Serves können SQL-Befehle per Kommandozeile zum SQL Server geschickt werden. Nämlich die SQLCmd.exe sowie deren PowerShell-Variante invoke-SQLCmd. Beides sind Werkzeuge, um T‑SQL-Befehle abzusetzen, welche dann vom SQL Server wie gewohnt verarbeitet werden.

Die SQLCmd.exe kennt viele Parameter, doch die wichtigsten sind:

-S für die Angabe der SQL-Serverinstanz
-d für die Angabe der zu verwendenden Datenbank
-U für den Benutzernamen (bei SQL-Logins im gemischten Modus)
-P für das dazugehörigen Kennwort

und entweder …

-Q für das/die SQL-Statements als direkter Parameter

oder …

-i für eine Textdatei mit SQL-Statements, welche eingelesen wird.

Ausgerüstet mit diesem Werkzeug kann man sich eine schlichte aber funktionale Lösung schaffen, um sowohl Datenbanken als auch Transaktionsprotokolle eines SQL Servers zu sichern – ohne den SQL Server Agent zu verwenden.

Vorgehensweise am Beispiel eines Backups

Wenn man sich bewusst macht, dass die Vollsicherung einer Datenbank nichts weiter benötigt, als ein …

BACKUP DATABASE … TO DISK … WITH …

… versteht man schnell, dass es nur darauf ankommt, einen solchen Befehl irgendwie an den SQL Server abzusetzen. Und genau da setzt das genannte Dienstprogramm an. Denn wenn man die dafür nötigen Paramter angibt, kann man durch …

SQLCmd.exe   -S ExampleServer\MSSQL   -Q "BACKUP DATABASE [ExampleDB] TO DISK = '\\FilesServer\Share\ExampleBackup.bak' WITH NAME='Full-Backup-of-ExampleDB', CHECKSUM;"

… im Grunde das Gleiche erreichen, was auch ein “echter” SQL Server Agent Job tun würde.

Anmerkung für SSMS-Benutzer

Hierdurch wird sehr gut deutlich, dass eine Datenbank-Sicherung keine “interne Aktion” des SQL Server Agents ist, sondern lediglich eine SQL-Anweisung. Besonders den Fans von Wartungsplänen sei an ’s Herz gelegt, sich dies einmal klar zu machen.

Es spricht also nichts dagegen, wenn der Windows Aufgabenplaner diesen Programmaufruf (mitsamt Parametern) übernimmt. Natürlich muss man bei einer solchen Lösung einige zusätzliche Details beachten. Dazu bitte den Hinweis am Ende beachten.

Teil 1 – Komplettsicherung

Da die T‑SQL-Logik in diesem Beispiel ausgesprochen simpel ist, werden die Dateinamen der Backup-Container nicht dynamisch generiert. Daher muß dieser Aspekt durch den Taskplaner abgedeckt werden.
Will man beispielsweise nach jedem Werktag ein Vollbackup anfertigen lassen, so richtet man kurzerhand fünf Vorgänge ein, welche jeweils ein individuelles Vollbackup auslösen.

Einrichtung – exemplarisch dargestellt für einen Vorgang

Name und Beschreibung sind zwar nicht weiter von Bedeutung, sollten jedoch möglichst sinnvoll gewählt sein.

Die Einstellung zur erzwungenen Beendigung des Tasks ist optional und kann auch an die realen Verhältnisse angepasst werden. Normalerweise sollte jedoch auch ein Vollbackup in circa vier Stunden abgeschlossen sein.

Die Aktion besteht im Aufruf des Programms mit individuellen Parametern. Diese sind aufgrund ihrer Länge nachfolgend noch einmal vollständig abgebildet.

Wenn alle fünf Sicherungen (ergo: Vorgänge) korrekt vorbereitet wurden, sollte es so …

… beziehungsweise so …

…aussehen.

Anmerkung

Der ein oder andere Server-Administrator mag hier einwenden, dass man auch jene fünf Einzelaufgaben zusammenfassen könnte. Das stimmt natürlich, allerdings ist der gezeigte Weg auch nur ein Bespiel und soll leicht verständlich sein. Außerdem kann man so die Sicherungs-Zeitpunkte individuell konfigurieren – etwa falls zur gleichen Zeit ein anderer Vorgang stattfindet und die Datenbank-Sicherung mit ein bis zwei Stunden Verschiebung starten soll.

Teil 2 – Transaktionsprotokoll-Sicherungen

Bleibt noch das Backup des Transaktionsprotokolls. Doch auch das ist keine Kunst – nur etwas aufwändiger, da hierbei die Dateinamen dynamisch zur Laufzeit generiert werden sollten. Sonst würde bei jedem neuen Backup das vorherige Backup überschrieben. Zwar ist dies keine Bedingung für ein erfolgreiches Backup, allerdings will man im Echtbetrieb sicherlich nicht nur ein Backup des Transaktionsprotokolls aufheben.

Um also diesen Aspekt abzubilden genügt eine kleine Änderung am T‑SQL-Befehl (sprich: der Teil hinter dem ‑Q-Parameter), sowie ein anderer Zeitplan. Im Regelfall werden Transaktionsprotokolle drei bis vier Mal stündlich gesichert.

Einrichtung

Diese Angaben dienen nur der Übersichtlichkeit.

Beim Auslöser (Trigger) muß diesmal auch eine Wiederholung gesetzt werden.

Auch hier ist der komplette Befehl im Bild nicht erkennbar und dafür im folgenden Bild in seiner vollen Länge dargestellt.

Fertig eingerichtet sollte man Folgendes sehen:

Kurze Erläuterung:

Der T‑SQL-Befehl macht nichts Anderes, als die aktuelle Systemzeit in einen ganzzahligen Wert zu konvertieren. Diese Zahl wird anschließend als Teil des Dateinamens verwendet, der für die jeweilige Backupdatei vorgesehen ist.

der Verzeichnisname	der Dateiame
`\\FileServer\Share\`	`ExampleDB1-###############.trn`
der komplette Pfad einer .trn-Backupdatei

Dabei gilt: “#” steht für variable Anteile.

Fazit

Auch wenn es vielleicht auf den ersten Blick so aussehen mag, aber der SQL Server Agent erledigt die Aufgaben nicht selbst. Er schaut auf die Uhr, setzt die Dinge in Gang, protokolliert die einzelnen Schritte sorgfältig und verschickt auf Wunsch E‑Mails über die Ergebnisse. Kurz: Er ist ein komfortabler Verwalter der einzelnen Aufgaben, aber die Arbeit machen andere. Entweder die SQL Server Engine direkt oder externe Programme, welche bereits im Windows vorhanden bzw. installiert sind.

Wie die vorgestellte Lösung zeigt, ist man jedoch nicht auf den SQL Server Agent angewiesen, falls man bestimmte Vorgänge im SQL Server auslösen will. Natürlich wird niemand bestreiten, dass die Verwendung des SQL Server Agents wann immer es geht vorzuziehen ist. Allerdings gibt es im Alltag auch hin und wieder Anwendungsfälle, in denen man tatsächlich auf eine Alternative angewiesen ist. In einem weiteren DBA Tipp wird das hier gezeigte Beispiel erneut aufgegriffen und dann durch den Einsatz anderer Werkzeuge/Technologien realisiert sowie ergänzt.

Du hast verschiedene Anwendungen, die aus unterschiedlichen Gründen Vorgänge in deinen MS SQL Servern auslösen müssen, weißt jedoch nicht wie?

Ruf uns unter +49.371.909515–100 an. Unsere Spezialisten helfen dir gern weiter.

Hier findest du weitere interessante DBA Tipps oder Posts zum Thema SQL Server aus unserem News und Insights Bereich.

Share this article

Der Beitrag DBA Tipp: Zeitgesteuerte Aufgaben im MS SQL Server ohne SQL Server Agent auslösen erschien zuerst auf ASPICON.

DataPump-Export/Import vs. RMAN-Backup

Jens Böttcher — Wed, 02 Feb 2022 13:44:19 +0000

Home → Backup & Recovery

DataPump-Export/Import vs. RMAN-Backup

Verfasst von Jens Böttcher
02 Februar 2022
14:44
Backup & Recovery, DBA Tipp, Oracle Database, Oracle Datenbank 12c /18c /19c /21c

Das Thema “Backup” ist eine absolute IT-Grundlage. Unabhängig davon wie hochverfügbar eine Infrastruktur ausgelegt ist, sollte die Erstellung von Datensicherungen grundsätzlich kein Gegenstand einer Diskussion sein. Die Ausgestaltung der Backups (Häufigkeit, Ablage, Tests, etc.) unterliegt natürlich den jeweiligen Anforderungen des Geschäftsbetriebes.

Doch Backup ist eben nicht gleich Backup. Das wird schnell klar, wenn man sich verschiedene Anwendungsszenarien für die Wiederherstellung von Daten(banken) anschaut. Insbesondere im Bereich der Oracle Datenbanken scheiden sich hier die Geister. In nicht wenigen Fällen ist man der Meinung, dass die Erstellung von “Exports mit DataPump” eine ausreichende Datensicherung darstellen.

Aber ist ein DataPump-Export wirklich die optimale Backup-Strategie? Wir möchten dazu einen kurzen Vergleich zwischen DataPump-Exports und den mittels Oracle Recovery Manager erstellten RMAN-Backups anstellen. Dazu werden im Folgenden die Möglichkeiten beider Varianten angerissen und bewertet.

DataPump-Export/Import

Beim DataPump-Export werden sogenannte Dumpfiles angelegt. Diese beinhalten die logischen Elemente einer Oracle Datenbank. Hierzu zählen beispielsweise Tabellen, Trigger, Constraints, sowie Metadaten und Steuerinformationen. Für den Export können verschiedene Modi verwendet werden, wie beispielsweise:

die komplette Oracle Datenbank (full=yes),
einzelne Tablespaces (tablespaces=ts1,ts2,ts3),
einzelne Schemata (schemas=s1,s2,s3), oder
einzelne Tabellen (tables=t1,t2,t3)

Ein weiterer, spezieller Modus ist der “Transportable Tablespace Mode”, welcher allerdings nur in der Oracle Datenbank Enterprise Edition zur Verfügung steht.

Es ist möglich, die Daten konsistent zu exportieren (flashback_scn=xyz / flashback_time=), so dass alle Datensätze innerhalb eines Dumps einen zueinander passenden Stand haben.

Ohne das spezielle Recht DATAPUMP_EXP_FULL_DATABASE kann der exportierende Benutzer allerdings lediglich sein eigenes Schema, respektive Elemente daraus exportieren. Er braucht daher zwingend das Recht, schreibend auf das Export-Verzeichnis (Default: DATA_PUMP_DIR) zuzugreifen. Für einen Import wird das entsprechende Leserecht benötigt. Wird zusätzlich ein Logfile beim Import geschrieben, ist auch das Schreibrecht auf das Import-Verzeichnis erforderlich.

Sofern nun die folgenden Parameter nicht anders gesetzt werden, gelten die hier angegebenen Werte:

directory=DATA_PUMP_DIR
dumpfile=expdat.dmp
logfile=export.log

Beim Anlegen eines DataPump-Exports ist mindestens anzugeben, was exportiert werden soll. In unserem Beispiel ist es das Schema “SCOTT”:

Prompt #> expdp schemas=scott

Es ist ebenfalls möglich, ganze Schemata zu exportieren und gleichzeitig bestimmte, namentlich aufgeführte Objekte oder ganze Objekttypen dabei auszuschließen (alternativ nur spezifische Objekte/Objekttypen exportieren mit include=):

Prompt #> expdp schemas=scott exclude=view,trigger
Prompt #> expdp schemas=scott include=table,constraint

Der DataPump-Import arbeitet ähnlich wie der Export. Er lädt den kompletten Dump, schließt Teile davon aus (exclude=) oder importiert ausschließlich spezifizierte Objekte/Objekttypen (include=). Für den Import von Objekten, die nicht zum eigenen Schema gehören, wird hier das DATAPUMP_IMP_FULL_DATABASE Recht benötigt.

RMAN-Backup

Oracle liefert u.a. für Backups bei allen Datenbank Edition kostenlos das Werkzeug Oracle Recovery Manager (RMAN) mit. Als integriertes Tool ist der RMAN das prädestinierte Werkzeug für die Erstellung von Backups.

Mit Hilfe eines RMAN-Backups kann eine komplette Oracle Datenbank physisch gesichert werden. Es ist aber auch hier möglich, nur Teile der Oracle Datenbank zu sichern, wie einzelne Tablespace(s), Datenfile(s), das Serverparameterfile oder die Controlfile(s).

Mit einem RMAN-Full-Backup der Oracle Datenbank kann die komplette Datenbank zu einem bestimmten Zeitpunkt X wiederhergestellt werden. Ist der ARCHIVELOG MODE in der Oracle Datenbank aktiviert, kann das Backup auch online – also ohne Downtime – durchgeführt werden. Zudem ermöglicht das Backup der Archivelogs, die Oracle Datenbank zu einem beliebigen Zeitpunkt nach dem Anlegen des Full-Backups zu restoren. Voraussetzung dafür ist das Vorhandensein von Archivelogs (oder Backups davon), die nach dem Full Backup angelegt wurden.
Auch hier ist ein Minimum anzugeben, was gesichert werden soll:

RMAN> backup datafile 1;

Daneben gibt es noch eine Vielzahl von Parametern und Kommandos, mit denen die RMAN-Backups verwaltet werden können. Das folgende Kommando legt ein komprimiertes Full Backup inklusive der benötigten Archivelogs an, um die Oracle Datenbank konsistent restoren und recovern zu können:

RMAN> backup as compressed backupset database plus archivelog;

Vor- und Nachteile

Der wesentliche Unterschied zwischen beiden Sicherungsarten ist, dass der DataPump-Export die Objekte logisch sichert, während mit RMAN die Backups physisch gesichert werden.

So ist es mit DataPump-Export möglich, einzelne Objekte für die Wiederherstellung zu sichern. Hier liegt auch der klare Vorteil einer logischen Sicherung mit DataPump: die Wiederherstellung einzelner Objekte, ohne die komplette Oracle Datenbank restoren zu müssen. Will man beispielsweise nur eine Tabelle rekonstruieren, weil Daten unbeabsichtigt gelöscht wurden, so ist der Aufwand ist an dieser Stelle deutlich geringer als bei einem RMAN-Backup.

Der Vorteil der physischen Sicherung mit einem RMAN-Backup in der Geschwindigkeit der Wiederherstellung wenn alle benötigten Komponenten gesichert wurden.

RMAN:

sichert physisch
Sicherung und Wiederherstellung der gesamten Datenbank bzw. ganzer Datenfiles möglich
Wiederherstellung einfacher und schneller, wenn alle benötigten Komponenten gesichert wurden

Data-Pump:

sichert Objekte logisch
Sicherung und Wiederherstellung einzelner Objekte möglich, ohne die komplette Oracle Datenbank restoren zu müssen

Beispiel – Verlust einer kompletten Oracle Datenbank

Im Falle eines kompletten Daten(bank)verlustes, beispielsweise bei einem defekten Datenträger, ist die Wiederherstellung der Datenbank aus einem RMAN-Backup vergleichsweise einfach. Voraussetzung ist hierbei ist jedoch, dass alle benötigten Komponenten gesichert wurden, d.h. Spfile, Controlfile, Datenfiles und ggf. Archivelogs.

Als Erstes wird dazu das Spfile restored, im Anschluss daran folgt das Controlfile und zum Schluss die Datenbankfiles. Im Falle eines Online-Backups wird, mit Hilfe der gesicherten Archivelogs, abschließend ein Recovery der Datenbank durchgeführt und die Datenbank geöffnet.

Liegt nun aber lediglich ein Dump vor, muss zunächst eine leere Instanz eingerichtet werden. Das kann durchaus einige Zeit in Anspruch nehmen. Anschließend kann erst der Dump eingespielt werden. Hier liegt also auch der wesentliche Unterschied zwischen beiden Sicherungsvarianten, der im Bedarfsfall eine Menge Zeit in der Wiederherstellung kosten kann.

Fazit

Welche Sicherung verwendet wird, hängt von verschiedenen Faktoren ab. Es empfiehlt sich auf jeden Fall ein RMAN-Full-Backup, um im Desasterfall die Datenbank möglichst ohne viele Eingriffe wiederherstellen zu können. Insbesondere ist eine Wiederherstellung zu einem bestimmten Zeitpunkt nur mit RMAN-Backups, über das Anwenden der Archivelogs, möglich.

Ein DataPump-Export kann optional angelegt werden, wenn immer wieder einzelne Objekte aus diesen Dumps benötigt werden. Das kann hier eine sehr sinnvolle Ergänzung sein, reicht jedoch nach unserer Betrachtungsweise als alleiniges “Backup” nicht aus.

Im Übrigen lässt sich aus einem RMAN-Full-Backup eine Oracle Datenbank auch duplizieren, z. B. für Testzwecke.

Hier findest du weitere interessante Posts zu den Themen Oracle Datenbank oder auch Backup and Recovery aus unserem News und Insights Bereich.

Share this article

Der Beitrag DataPump-Export/Import vs. RMAN-Backup erschien zuerst auf ASPICON.

Make backup compression great again

Thilo Solbrig, Oracle Certified Master — Tue, 12 Nov 2019 08:43:00 +0000

Home → Backup & Recovery

Make backup compression great again

Verfasst von Thilo Solbrig, Oracle Certified Master
12 November 2019
09:43
Backup & Recovery, Datenbank, DBA Tipp, Oracle, Oracle Database, Oracle Enterprise Edition, Oracle Standard Edition /One /Two, RMAN

Immer wieder steht der durch das Backup benötigte Speicherplatz im Fokus der Bestrebungen wertvolle Plattenkapazitäten freizuschaufeln. Insbesondere für größere Oracle Datenbanken kommt im nächsten Schritt das Thema Backup Komprimierung auf die Agenda. Aus diesem Grund wollen wir uns heute mit eben diesem Thema beschäftigen und einmal beleuchten, was die Vor- oder auch Nachteile eine Backup Komprimierung sind.

Unter der Überschrift “make backup compression great again” beleuchtet dieser Artikel ausschließlich RMAN-Backups, die auf ein NFS-Share geschrieben werden. Eingeschränkt anwendbar wären die Schlussfolgerungen noch auf RMAN-Backups, die in lokale Filesysteme des Backupservers erfolgen.
RMAN-Backups via SBT_TAPE-Treiber sollten auf die Komprimierungsmechanismen (Hardwarekomprimierung etc.) der 3rd-Party-Sicherungslösung zurückgreifen. Sicherst du deine Datenbanken via SBT_TAPE-Treiber, richtet sich der Artikel explizit nicht an dich.

RMAN-Komprimierung pros/cons

Die Komprimierung von RMAN Backups wird gern eingesetzt bei großen Datenmengen oder einer Backup-Policy, die viele Backupdaten generiert. Der in allen Editionen der Oracle Datenbank verfügbare BASIC-Mode – hinter dem sich der BZIP2-Algorithmus verbirgt – bietet dabei akzeptable Komprimierungsraten, ist allerdings sehr langsam und CPU-intensiv. Schnellere oder besser komprimierende Algorithmen dürfen hingegen nur bei lizenzierter Advanced Compression Option (ACO) in der Oracle Enterprise Edition (EE) benutzt werden oder bedingen die Lizenzierung von Oracle Secure Backup.

Nun ist allerdings nicht davon auszugehen, dass sich viele Anwender nur wegen der Backupkomprimierung eine EE mit ACO zulegen oder ihre existierende Backuplösung auf Oracle Secure Backup umstellen. Auf der anderen Seite stehen einige nicht zu vernachlässigende Nachteile der BASIC-Compression zu Buche:

Der bzip2-Algorithmus ist sehr CPU-intensiv und belastet, der Natur der Sache geschuldet, die CPU des Datenbankservers, denn die Komprimierung findet auf dem Datenbankserver statt.
Das Hinzufügen von CPU-Leistung ist praktisch meist unmöglich, weil Limitierungen der SE2 oder Lizenzkosten der EE dem entgegen stehen.
Die Komprimierungslast kann, abgesehen von der EE, nicht über mehrere CPUs verteilt werden, da keine parallelen RMAN Backups möglich sind.
Der mit Abstand wichtigste Nachteil ist jedoch, dass der Restore von BASIC-komprimierten Backups ausgesprochen langsam ist. Er dauert in jedem Fall länger als das Backup dauerte. Man läuft damit zwangsläufig in das Risiko, bei der Wiederherstellung unternehmensrelevanter Daten wertvolle Zeit zu verlieren. Die daraus resultierenden Ausfallkosten sind um ein Vielfaches höher als die ursprüngliche Einsparung durch die Komprimierung. Schon aus diesem Grund verbieten sich daher BASIC-komprimierte Backups für Produktivumgebungen. Oracle begründet die hohe Restorezeit übrigens mit den Eigenheiten des bzip2-Algorithmus. Ob das tatsächlich stimmt oder doch eher auf eine schlechte Implementierung zurückzuführen ist, die vielleicht gar künstlich Bedarf an ACO generieren soll, dazu kann man sich grob eine eigene Meinung bilden, wenn man einfach einmal ein unkomprimiertes RMAN-Backuppiece auf OS-Ebene mit bzip2 komprimiert und wieder dekomprimiert:

$ ls -lh 48ug2ac7_1_1
-rw-r----- 1 oracle oinstall 3.8G Nov  4 21:52 48ug2ac7_1_1
$ time bzip2 -z 48ug2ac7_1_1 # compress

real    7m54.258s
user    7m43.413s
sys     0m7.063s

$ time bzip2 -d 48ug2ac7_1_1.bz2 # uncompress

real    2m19.838s
user    2m5.495s
sys     0m10.851s

Alternative

In den meisten Fällen scheint es also keine gute Lösung zu sein, mit RMAN komprimierte Backups zu erstellen. Muss man nun vernünftigerweise komplett auf die Komprimierung der RMAN-Backups verzichten? Nein. Denn die Komprimierung muss ja nicht zwingend von RMAN durchgeführt werden und sie muss auch nicht auf dem Datenbankserver stattfinden. Bei Backups über SBT_TAPE-Libraries wird ja in der Regel auch die Komprimierung der Backupsoftware oder ‑hardware genutzt. Das lässt sich genau so einfach bei RMAN-Backups auf Shares bewerkstelligen. Man sorgt einfach dafür, dass das Backupshare auf einem komprimierten Filesystem angelegt wird. Das ist für Shares auf Windowsservern (NTFS compression), auf Solaris ZFS und auch auf Linux mit dem btrfs-Filesystem möglich.

Greifen wir nochmal die Nachteile der RMAN-Komprimierung auf und betrachten sie im Lichte einer backupserverseitigen Komprimierung:

Die Backupkomprimierung belastet die CPUs des Backupservers, nicht des Datenbankservers. Check!
Das Hinzufügen von CPU-Leistung verletzt keine Oracle-Lizenz-Limitierungen und zwingt auch nicht zum Nachkauf von Oracle-Lizenzen. Wenn der Backupserver virtualisiert ist, ist das ggf nicht einmal mit einer Hardwarenachrüstung verbunden. Check!
Die Komprimierungslast wird von der Filesystemkomprimierung meist schon selbständig über mehrere CPUs verteilt. Zumindest war das bei der btrfs-Komprimierung der Fall. Check!
Der Restore selbst hoch komprimierter Backups dauert nicht mehr länger als das Backup und ist in jedem Fall um Größenordnungen schneller als das Restore eines RMAN-BASIC-komprimierten Backups. Check!
Zusätzlich stehen, je nach Filesystem, auch noch verschiedene Algorithmen kostenfrei und unabhängig von der verwendeten Datenbank Edition zur Auswahl. Je nach Bedarf kann somit ein gutes Maß zwischen Backupzeit und Komprimierungsrate gewählt werden. Check!

Zur Veranschaulichung der Unterschiede werden nachfolgend verschiedene Testläufe dargestellt, die sowohl mit den in RMAN verfügbaren Algorithmen als auch mit einem ZLIB- und LZO-komprimierten btrfs-Filesystem durchgeführt wurden. Gesichert und restored wurde jeweils die selbe Datenbank von ca. 40GB Größe auf ein per NFS angebundenes Share. Dabei sollte das Augenmerk weder auf die absoluten Backup- und Restorezeiten noch auf die absoluten Komprimierungsraten gelegt werden. Die Tests fanden in einer virtualisierten Testumgebung statt und die absoluten Ergebnisse sind daher eher mäßig. Der wesentliche Punkt sind die relativen Performanceunterschiede.

Legende	Kompressionszenario (Backup auf ein NFS-Share, das ein ext4- oder btrfs-formatiertes Filesystem präsentiert)	Backup in min	Restore in min	Größe des Backups in GB
RMAN uncomp	RMAN unkomprimiert auf unkomprimiertes ext4	00:45	00:35	3.99
RMAN basic	RMAN BASIC-Compression auf unkomprimiertes ext4	02:06	02:36	0.64
RMAN basic LO	RMAN BASIC-Compression auf unkomprimiertes ext4 (load optimized)	02:05	02:35	0.78
RMAN low	RMAN LOW-Compression auf unkomprimiertes ext4	00:15	00:25	0.90
RMAN low LO	RMAN LOW-Compression auf unkomprimiertes ext4 (load optimized)	00:35	00:26	1.13
RMAN medium	RMAN MEDIUM-Compression auf unkomprimiertes ext4	00:25	00:25	0.75
RMAN medium LO	RMAN MEDIUM-Compression auf unkomprimiertes ext4 (load optimized)	01:15	00:35	0.92
RMAN high	RMAN HIGH-Compression auf unkomprimiertes ext4	06:05	01:56	0.53
RMAN high LO	RMAN HIGH-Compression auf unkomprimiertes ext4 (load optimized)	08:17	02:26	0.66
btfrs ZLIB	RMAN unkomprimiert auf btrfs mit compress-force1=ZLIB gemountet	00:35	00:26	0.94
btrfs LZO	RMAN unkomprimiert auf btrfs mit compress-force=LZO gemountet	00:25	00:25	1.43

compress-force ist obligatorisch, da btrfs aufgrund der ersten Bytes des Backuppieces recht zuverlässig zu dem Trugschluss kommt, dass sich eine Komprimierung des gesamten Files nicht lohnt. Ohne „force“ werden die Backups dann sehr wahrscheinlich unkomprimiert abgelegt.

Spätestens in der grafischen Darstellung ist zu erkennen, dass es augenscheinlich kaum Argumente für RMAN-Komprimierung gibt. Selbst die kostenpflichtigen Algorithmen der Oracle Enterprise Edition (EE) schneiden nicht signifikant besser ab als die kostenfreien auf dem Backupserver verwendeten Algorithmen, die zudem noch für alle Editionen verwendbar sind.

Für Nutzer der Oracle Standard Edition (SE) ist zusätzlich beachtenswert, dass mit BASIC-komprimierten Backups der relative Zeitaufwand für den Restore ggü dem Backup noch deutlich höher sein wird als oben dargestellt. Die hier dokumentierten Tests wurden auf einer EE durchgeführt. RMAN führt bei EE im Gegensatz zur SE zusätzlich ein s.g. unused block compression durch. Das heißt, die EE sichert grundsätzlich keine leeren Blöcke. Die SE hingegen lässt bei der Sicherung nur Blöcke aus, die noch nie belegt waren (s.g. null compression). Fragmentierung in Extents schlägt also in der SE bei RMAN-Sicherungen zusätzlich signifikant zu Buche, während sie in der EE in dem Fall irrelvant ist. Details hierzu findet man in der MOS Note Doc ID 563427.1

Fazit

Wenn die Komprimierung von RMAN-Backups gewünscht ist und der Backupserver ein komprimierendes Filesystem über NFS präsentieren kann, wird es die mit gehörigem Abstand bessere Lösung sein, die Komprimierung vom Backupserver erledigen zu lassen, nicht vom RMAN. Bietet das Backupshare dieses Feature nicht an, sollte man auf Backupkomprimierung besser ganz verzichten. Auch wenn die Kosten für den Backupspace dann höher sind. Spätestens wenn ein Restore nötig wird, werden sich die Kosten durch den zum Teil enormen Zeitgewinn schnell amortisieren.

Hier findest du weitere News, Updates und Insights rund um das Thema “Backup und Recovery” von Datenbanken

Share this article

Der Beitrag Make backup compression great again erschien zuerst auf ASPICON.