Oracle

Oracle

Posts 1-9 of 9
  • Roland Kletzing
    Roland Kletzing
    The company name is only visible to registered members.
    Archivelogs & Backups
    Hallo,

    ich habe eine (evtl. ganz interessante Frage) die mir leider bislang noch niemand zur Zufriedenheit beantworten konnte.

    Also, folgende Situation:

    1. Um eine Oracle DB online konsistent sichern zu können muss sie im Archivelog Modus laufen.
    2. Neben der Sicherung der DB (z.B. mit RMAN) ist für eine konsistente Sicherung auch (angeblich) eine Sicherung ALLER Archivlogs nötig

    Das kann ich insofern nachvollziehen, wenn man rückwirkend mit der letzten Sicherung eine "Point in Time" Recovery durchführen möchte. Ich bin selbst kein Oracle Admin, aber als Storage/VM/Backup-Admin würde ich das "CDP -Continuous Data Protection" nennen, ich kann also aus dem Backup die Datenbank komplett wiederherstellen und dann mithilfe der Archivelogs jeden beliebigen Zustand "X" wieder "anfahren" da in den Archivelogs ja quasi das Backlog aller Änderungen enthalten ist.

    Jetzt nehmen wir mal eine grössere Entwicklungsumgebung mit komplexen Diensten in der man auch Backup implementieren möchte. Ein Shutdown und Cold-Backup ist ungünstig da zu viel dranhängt was man dann alles mit beenden müsste und nach dem Backup wieder anstarten müsste - mit der Gefahr daß am nächsten Tag ein Dienst nicht sauber hochgekommen ist und die Telefone heissklingeln weil die Entwickler nicht arbeiten können.Ausserdem findet man damit in der Entwicklung garantiert keine Memleaks ;) Also vorzugsweise auch Online-Backup in der Entwicklungsumgebung.....

    So - jetzt kommt der Punkt:
    Wenn ich eine Entwicklungsumgebung sichere dann reicht es vollkommen eine Datenbank "Stand 22:00 Uhr Backuptime vom Vortag" wiederherzustellen.

    Wozu brauche ich dann 24 Stunden Archivelogs und warum dafür Plattenplatz verschwenden, insbesondere dann wenn den ganzen Tag wie Hölle auf der Datenbank rumgerödelt wird? Da kann eine 10GB DB doch mal locker das X-Fache Menge an Platz fürs Archivelog einnehmen.

    Kann man denn nicht einfach automatisiert die Archivelogs zeitnah wieder "wegschmeissen", kurz vor dem Backup mit dem Wegschmeissen aufhören, dann die DB und "ein bisschen" Archivelogs sichern (damit der Stand konsistent ist) und danach weiter fleissig rund um die Uhr die Archivelogs wegschmeissen?

    Mir konnte noch keiner plausibel darlegen warum das mit dem Wegschmeissen der Archivelogs kein gangbarer Weg ist bzw. wie man das "Problem" dieser in Entwicklungsumgebungen unverhältnismässig grossen zu sichernden Datenmenge löst bzw. den zusätzlichen Platzbedarf für die Archivelogs umgeht. Ich will Backup, ja, aber ich will kein Backup mit "Contiuous Data Protection".

    Ich mein - ich kann doch ein RMAN Full-Backup machen inkl. aller Archivelogs - und danach ist es erlaubt alle Archivelogs wegzuschmeissen - und wenn ich danach noch ein RMAN Full-Backup mache habe ich immer noch ein Full-Backup, nur halt mit dem Unterschied daß ich nicht mehr zu bestimmten Punkten zurückfahren kann. Da muss es doch einen legalen Weg geben wie man direkt zu solch einem (weitestgehend) Archivelog-freien Full-Backup kommt?

    Vielleicht kennt sich jemand damit etwas besser aus und kann dazu was sagen ? Habe das jetzt schon mit 3 DBAs diskutiert und die lassen sich auf nix anderes ein und wollen für jedes Full-Backup auch immer alle Archivelogs mitgesichert haben......und ich sehe nicht ein im Wesentlichen "Changelog" zu sichern und so viel Plattenplatz für Archivelogs bereitzustellen.

    Grüsse
    Roland
    This post was modified on 14 Apr 2011 at 10:27 pm.
    • 14 Apr 2011, 10:08 pm
  • Jörg Sobottka
    Jörg Sobottka
    The company name is only visible to registered members.
    Re: Archivelogs & Backups
    Hallo Herr Kletzing,

    Roland Kletzing schrieb:
    Hallo,
    1. Um eine Oracle DB online konsistent sichern zu können muss sie im Archivelog Modus laufen.     Ja, dem ist so.

    2. Neben der Sicherung der DB (z.B. mit RMAN) ist für eine konsistente Sicherung auch (angeblich) eine Sicherung ALLER Archivlogs nötig Jein - nicht unbedingt. Welche archive logs Sie benötigen um eine Datenbank beim recover wieder konsistent zu bekommen, hängt von der (mehrfach in einer Datenbank abgelegten) SCN Nummer ab.... Grundsätzlich gilt: Die kleinste in einer Datenbank vorkommende SCN muss in einem archivierten Redo (oder online redo) vorliegen (Ausnahmen z.B. bei Read Only Tablespaces). Alle Änderungen, die in einem Datafile ab dem Zeitpunkt des Startes des Backups vorgenommen werden, müssen später aus einem archive log appliziert werden können. Sie können damit aber niemals einen Stand erreichen, der VOR dem Start des letzten Backups und NACH dem Ende des vorletzten Backups liegt (bzw. entsprechend zu den Vortagen nach Anzahl vorgehaltener Backups).

    Das kann ich insofern nachvollziehen, wenn man rückwirkend mit der letzten Sicherung eine "Point in Time" Recovery durchführen möchte. Ich bin selbst kein Oracle Admin, aber als Storage/VM/Backup-Admin würde ich das "CDP -Continuous Data Protection" nennen, ich kann also aus dem Backup die Datenbank komplett wiederherstellen und dann mithilfe der Archivelogs jeden beliebigen Zustand "X" wieder "anfahren" da in den Archivelogs ja quasi das Backlog aller Änderungen enthalten ist.
    Auch hier haben Sie meine Zustimmung.

    Memleaks ;) Also vorzugsweise auch Online-Backup in der Entwicklungsumgebung.....
    Was grundsätzlich auch keine schlechte Idee ist.

    So - jetzt kommt der Punkt:
    Wenn ich eine Entwicklungsumgebung sichere dann reicht es vollkommen eine Datenbank "Stand 22:00 Uhr Backuptime vom Vortag" wiederherzustellen. Wozu brauche ich dann 24 Stunden Archivelogs und warum dafür Plattenplatz verschwenden, insbesondere dann wenn den ganzen Tag wie Hölle auf der Datenbank rumgerödelt wird? Da kann eine 10GB DB doch mal locker das X-Fache Menge an Platz fürs Archivelog einnehmen.
    Das brauchen Sie in diesem Falle wirklich nicht unbedingt. Wichtig für Sie ist einfach nur zu wissen, dass Sie alle archivierten Redo Logs benötigen, die vom Start des Backups (bzw. dem niedrigsten SCN-Stand) bis zum Ende (und vielleicht etwas darüber hinaus) angefallen sind... Das heraus zu finden ist aber automatisiert nicht ganz so einfach....

    Kann man denn nicht einfach automatisiert die Archivelogs zeitnah wieder "wegschmeissen", kurz vor dem Backup mit dem Wegschmeissen aufhören, dann die DB und "ein bisschen" Archivelogs sichern (damit der Stand konsistent ist) und danach weiter fleissig rund um die Uhr die Archivelogs wegschmeissen? Jein - es gäbe sicherlich eine Möglichkeit, dies mit mehr oder weniger schönen Skripten zu machen. Wir machen so etwas bei Kunden, bei denen wir automatisiert per Skripts Datenbanken clonen - auch dort will man natürlich nicht alle archivierten RedoLogs auf die neue Clone-Umgebung übertragen - sondern einfach z.B. auf ein CMD klicken und der Rest passiert dann im Hintergrund... Dort laufen dann 3-4 (RMAN-) Skripte ab, die teileweise auf vorhandene Backups, teilweise auf noch nicht gebackupte archive logs zugreifen und in denen automatisch SCN-Nummern eingetragen werden, etc., aber wie gesagt, es ist nicht ganz so einfach.
    Eventuell gäbe es in Ihrem Fall die Möglichkeit, mit einem etwas einfacheren Skript zu arbeiten - ich hab da was im Hinterkopf - aber leider habe ich derzeit keine Möglichkeit, zu testen ob sich die Datenbank bei dieser Vorgehensweise dann wirklich recovern lässt...

    Anders ausgedrückt: Was kostet heute Speicherplatz noch und was kosten ein paar Tage Consulting, Testen der Wiederherstellbarkeit (!!!), Sonderbehandlung wegen speziellen Skripten, etc.... Bei jeder Datenbankversionsänderung etc. haben Sie wieder was extra, das angefasst oder zumindest getestet werden muss.

    Viele Grüsse
    Jörg Sobottka
    Installation, Migration, Performance Tuning, High Availability, Remote Monitoring
    • 15 Apr 2011, 11:32 am
  • Heimo Dullnig
    Heimo Dullnig
    The company name is only visible to registered members.
    Re^2: Archivelogs & Backups
    Hallo,
    im wesentlichen erledigt folgendes rman-script die Aufgabe:

    run {
    delete archivelog all;
    backup CHECK LOGICAL FULL database plus archivelog delete all input;
    }

    Schöne Grüße
    Heimo Dullnig
    • 15 Apr 2011, 12:49 pm
  • Post visible to registered members
  • Jörg Sobottka
    Jörg Sobottka
    The company name is only visible to registered members.
    Re^3: Archivelogs & Backups
    Heimo Dullnig schrieb:

    im wesentlichen erledigt folgendes rman-script die Aufgabe:
     
    run {
    delete archivelog all;
    backup CHECK LOGICAL FULL database plus archivelog delete all input;
    }
    Wenn, dann "delete NOPROMPT archivelog all;", soviel Zeit muss sein ;-)

    Aaaaaaaaaaaaaaaaaaber das ist natürlich dann gefährlich, wenn das darauf folgende Backup nicht stattfindet bzw. nicht erfolgreich zu Ende geht. Dann steht man mit ziemlich heruntergelassenen Hosen da.

    Besser nur das Backupen, was es braucht und DANACH erst löschen...
    Deshalb sollte man wohl eher damit arbeiten:
    BACKUP ARCHIVELOG FROM SCN ...


    Viele Grüsse
    Jörg Sobottka
    Installation, Migration, Performance Tuning, High Availability, Remote Monitoring
    • 15 Apr 2011, 1:08 pm
  • Roland Kletzing
    Roland Kletzing
    The company name is only visible to registered members.
    Re^4: Archivelogs & Backups
    Hallo!
    vielen dank schonmal für die ausführlichen Antworten!

    >Sie können damit aber niemals einen Stand erreichen, der VOR dem Start des letzten Backups und NACH
    dem Ende des vorletzten Backups liegt (bzw. entsprechend zu den Vortagen nach Anzahl vorgehaltener
    >Backups).
    Das will ich ja auch garnicht. Das kann ich schliesslich bei einem Fileserver der nur jede Nacht gesichert wird auch nicht - genausowenig kann ich das bei einer Oracle DB die garnicht im Archivelog Modus läuft, oder?
    Ich will einfach einmal am Tag einen gesicherten Stand der Datenbank haben auf dem man wieder aufsetzen kann. Wann genau etwas kaputtgegangen ist kann einem ein Entwickler ja meist eh nicht sagen. Da heisst es immer nur "gestern gings noch". ;)

    im wesentlichen erledigt folgendes rman-script die Aufgabe:
     
    run {
    delete archivelog all;
    backup CHECK LOGICAL FULL database plus archivelog delete all input;
    }
     
    Wenn, dann "delete NOPROMPT archivelog all;", soviel Zeit muss sein ;-)
    Das hört sich für mich als Oracle Laie erstmal plausibel an....


    Aaaaaaaaaaaaaaaaaaber das ist natürlich dann gefährlich, wenn das darauf folgende Backup nicht stattfindet bzw. nicht erfolgreich zu Ende geht. Dann steht man mit ziemlich heruntergelassenen Hosen da.
    Das verstehe ich jetzt nicht so ganz - was heisst das denn jetzt konkret wenn das Backup nicht erfolgreich ist ?
    Wo ist hier das Problem?
    Dann hat man halt mal kein erfolgreiches Backup von der Testumgebung und das Backup läuft dann halt am nächsten Tag wieder korrekt durch - wenn da MAL ein Backup in die Hose geht, ist das bei einer Test/Entwicklungsumgebung nicht so tragisch. Dann spiele ich beim Recover halt nicht das Backup vom Vortag sondern vom Vor-Vortag zurück.... !?
    Kann das evtl. sein daß der typische Oracle DBA "Continuous Data Protection" und damit das "Zurückfahren auf Stand X um 13:42" als das "Mass aller Dinge" betrachtet, wenn es um das Thema Backup geht ?

    Grüsse
    Roland
    This post was modified on 15 Apr 2011 at 02:31 pm.
    • 15 Apr 2011, 2:24 pm
  • Jörg Sobottka
    Jörg Sobottka
    The company name is only visible to registered members.
    Re^5: Archivelogs & Backups
    Hallo Herr Kletzing,

    Ich will einfach einmal am Tag einen gesicherten Stand der Datenbank haben auf dem man wieder aufsetzen kann. Wann genau etwas kaputtgegangen ist kann einem ein Entwickler ja meist eh nicht sagen. Da heisst es immer nur "gestern gings noch". ;)
    Das verstehe ich jetzt nicht so ganz - was heisst das denn jetzt konkret wenn das Backup nicht erfolgreich ist ?
    Wo ist hier das Problem?
    Dann hat man halt mal kein erfolgreiches Backup von der Testumgebung und das Backup läuft dann halt am nächsten Tag wieder korrekt durch - wenn da MAL ein Backup in die Hose geht, ist das bei einer Test/Entwicklungsumgebung nicht so tragisch. Dann spiele ich beim Recover halt nicht das Backup vom Vortag sondern vom Vor-Vortag zurück.... !?
    Wie viele Vor-Vortage möchten Sie in Ihrer Backupstrategie denn vorhalten? Welche Retention Policy setzen Sie ein? Wer verspricht Ihnen, dass am nächsten Tag das Backup wieder läuft? Wenn Sie dann ein paar Tage kein Backup haben kann das schon wieder kritisch werden, wenn Sie alle archivierten Redos schon gelöscht haben. Im anderen Fall, nehmen Sie schnell nen Backup und ziehen das anhand der archivierten Redos einfach auf die letzte Nacht hoch. So wie ich verstanden habe, geht es ja nicht um den belegten Storage für die archivierten Redos, sondern um die Grösse der Backups???

    Da wir selbst ISV sind weiss ich, wie unsere Entwickler schreien, wenn das, was auf der DB entwickelt und noch nicht im SourceCodeRepository eingecheckt ist, verloren geht - von daher machen wir uns lieber 2 Gedanken mehr.

    Man kann viele Dinge vernachlässigen - aber IMMER sollte man sich BEWUSST in einem dokumentierten Konzept mit Erläuterung der jeweiligen Vor- und Nachteile entscheiden. Datensicherheit ist nunmal das höchste Gut für einen DBA - von daher gebe ich Ihnen schon recht, dass das kein DBA wirklich gerne in so einer Reihenfolge macht.

    Viele Grüsse
    Jörg Sobottka
    Installation, Migration, Performance Tuning, High Availability, Remote Monitoring
    • 15 Apr 2011, 3:21 pm
  • Patrick Waehlan
    Patrick Waehlan
    The company name is only visible to registered members.
    Re: Archivelogs & Backups
    Hallo,
    ich wollte auch nochmal meinen Senf dazugeben:
    (habe den Beitrag hier erst heute gefunden - frohes neues :-) )

    Ja, der archivelogmode ist eine Krücke, aber ohne ihn gibt's kein onlinebackup.

    Was ich mache, wenn es sich um eine DB handelt, die nicht so kritisch ist:
    Jeder Tablespace TS wird so erstellt/modifiziert, dass das logging AUS ist - das reduziert die Datenmenge.
    Ggf. muss man das dem Entwickler auch mitteilen, wenn dieser TS dropp&neu erstellt.

    Beim nächtlichen Backup wird dann der Rest aufgeräumt.

    Wenn es eine DB ist, die man auch problemlos herunterfahren und sichern kann, würde ich den drecklogmode einfach ausschalten.
    This post was modified on 03 Jan 2012 at 01:07 pm.
    • 03 Jan 2012, 1:02 pm
  • Johannes Ahrends
    Johannes Ahrends    Premium Member   Group moderator
    The company name is only visible to registered members.
    Re^2: Archivelogs & Backups
    Und noch ein paar Anmerkungen:
    1. wenn Sie eine Oracle 10g oder 11g Version verwenden, würde ich Ihnen empfehlen, einfach die DB_RECOVERY_FILE_DEST und DB_RECOVERY_FILE_DEST_SIZE zu setzen. Die Destination ist das Verzeichnis, in das sie ihr backup und ihre archivierten Redologdateien laufen lassen. Mit der Size geben Sie die maximale Größe an. Diese muss größer sein als das zweimal Backup und die archivierten Redologs, die Sie bahalten wollen.
    Der Vorteil dieses Verfahrens ist, dass der RMAN und der Archivprozess selbst für das Löschen nicht mehr benötigter Dateien sorgen.
    2. Das CONSISTENT=Y beim Export ist irreführend, da es sich nur um Konsistenzen handelt, die über Primary und Foreign Key Constraints definiert wurden, es geht nicht um die Konsistenz der Anwendung.
    3. Beim Export / Import und auch über Data Pump müssten Sie nach einem Fehler erst einmal die Datenbank im "Rohzustand" wieder herstellen, bevor Sie importieren können. Das dauert ...
    4. Wenn ein Tablespace auf NOLOGGING steht, bedeutet das nur, dass Bulk Operationen (wie INSERT APPEND, CTAS) nicht geloggt werden und auch nur dann, wenn die Tabellen auch mit diesem Parameter erstellt wurden.
    5. Wenn die Dateien zu groß sind, dann verwenden Sie doch einfach eine Komprimierung. Bei der Oracle Enterprise Edition ist eine Basiskomprimierung dabei (vorsicht, ist beim Restore ziemlich langsam).
    • 03 Jan 2012, 2:34 pm