Hallo,
ich hab den Beitrag zum Export gelesen und dazu ist mir auch eine Frage eingefallen.
Wenn bei Oracle der Archivelog Modus aktiviert ist und man einen export der Datenbank macht (mit der Prämisse, dass diese ziemilch groß ist und benutzt wird, also online ist - Online Backup), kann dann das Export zu einer Inkonsistenz führen?
Ich kann dazu leider keine ordentliche Antwort finden, deshalb bitte ich euch um Hilfe.
Schonmal vielen Danke im voraus!
Gruß
Alex
ich hab den Beitrag zum Export gelesen und dazu ist mir auch
eine Frage eingefallen.
Wenn bei Oracle der Archivelog Modus aktiviert ist und man
einen export der Datenbank macht (mit der Prämisse, dass diese
ziemilch groß ist und benutzt wird, also online ist - Online
Backup), kann dann das Export zu einer Inkonsistenz führen?
wenn du beim export den parameter consistent=y angiebst, kommt es zu keinen inkonsistenzen - oracle nimmt dann ggf. die daten aus dem rollback-segment (heist ab oracle 9 anders, glaube ich) um einen konsistenzen export herstellen zu können. sind deine rollbacksegmente aber zu klein, dann bekommst du eine fehlermeldung (snapshot to old).
ohne den parameter ist zwar jede tabelle in sich konsistent, es kann aber sehr wohl passieren, dass die tabellen nicht mehr zueinander passen (z.b. exportierst du die detail-tabelle mit datensätzen, bei denen der master noch nicht in der mastertabelle war).
nebenbei: im vollbetrieb mach man ohnehin kein export - bremmst die db ja nur unnötig aus…
erwin
Vielen Dank für die Antwort.
Es ist mir klar, dass es die Datenbank stark ausbremst, aber die Datenbank MUSS 24/7 laufen. Also ist ein Onine Backup die einzige mir bekannte Lösung.
Gruß
Alex
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Es ist mir klar, dass es die Datenbank stark ausbremst, aber
die Datenbank MUSS 24/7 laufen. Also ist ein Onine Backup die
einzige mir bekannte Lösung.
mal bescheidene frage: nutzt du das export etwa, um ein online-backup zu machen? ist zwar auch eine möglichkeit nur nicht unbedingt die optimale. wenn du die einzelnen tablespaces in den online-backup-modus versetzt, kannst du sie einfach wegkopieren. das geht normalerweise viel flotter als ein export. der online-backup-modus sorgt auch dafür, dass die daten konsistent bleiben.
sofern die db unbedingt 24/7 verfügbar sein soll und plattenplatz kein thema ist, würde ich vorschlagen, die db in den backup-modus zu versetzen und die datafiles auf eine andere platte zu kopieren. das sollte schön flott gehen. danach kannst du den backup-modus beenden und die kopien der dateien in aller ruhe auf band sichern (oder was auch immer du für ein sicherungsmedium verwendest).
natürlich gibt es auch profilösungen, die sich praktisch vollautomatisch und die sicherung kümmern - und es nebenbei auch schaffen, eine differenzsicherung zu machen (es werden nur die blöcke des tablespaces gesichert, die sich seit dem letzten vollbackup geändert haben). das verkürzt die backupzeit ganz erheblich. kostet aber auch eine stange geld…
erwin
Hallo,
danke! :o)
Das war genau mein Vorschlag für die Lösung, allerdings wurde es bisher einfach anders gemacht.
Ist es auch möglich den Backup-Modus per cronjob oder ähnliches automatisch zu setzen, die Daten zu kopieren und danach den Backup-Modus wieder abzuschalten? Dies sollte nach Mögilchkeit nämlich Nachts durchgeführt werden.
Der Plattenplatz spielt fast keine Rolle.
Gruß
Alex
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
Hallo Alex,
Ist es auch möglich den Backup-Modus per cronjob oder
ähnliches automatisch zu setzen, die Daten zu kopieren und
danach den Backup-Modus wieder abzuschalten? Dies sollte nach
Mögilchkeit nämlich Nachts durchgeführt werden.
Latürnich 
Das Ganze nennt sich dann auch „Hot Backup“.
Falls Du die DB auf Unix / Linux betreibst - so wie wir - dann wäre unser Vorgehen wahrscheinlich auch für Dich passend. Unser Backup wird jeden Abend durch ein Skript gestartet, was folgendes Tut:
zunächst wird ein Full-Export gezogen. Diesen halte ich für fast noch Wichtiger als ein Backup. Ein Backup ist gut, wenn es Dir ein Datenfile zerbröselt, das aber bei hochverfügbarer Hardware höchst selten vorkommt. Viel öfter ruft ein User an, der sich eine Tabelle zerschossen hat, und um die wieder herzustellen nützt Dir ein Backup gar nichts (außer Du willst beim Einspielen alle anderen User lahmlegen und ihren Datenstand zeitlich zurücksetzen) - einziges approbates Mittel dafür ist das Einspielen der Tabelle aus dem Full-Export.
Anschließend ruft das Skript sqlplus auf und startet darin eine PL/SQL-Prozedur. Diese erzeugt mir ein weiteres Skript (anhand der momentan vorhandenen Tablespaces und Datenfiles) namens „aufback.sql“.
zum Schluss wird aus Skript 1 erneut SQLPlus gestartet und das eben erzeugte aufback.sql ausgeführt.
aufback.sql sieht etwa folgendermaßen aus:
SPOOL /pfad/ins/bkdir/backup.log;
ALTER SYSTEM ARCHIVE LOG CURRENT;
PROMPT Tablespace: - Filename: - File-ID: nn - Filesize: mmmm MB
ALTER TABLESPACE BEGIN BACKUP;
!cat /oradata// | gzip -c >
ALTER TABLESPACE END BACKUP;
[…]
ALTER DATABASE BACKUP CONTROLFILE TO TRACE;
ALTER DATABASE BACKUP CONTROLFILE TO /pfad/ins/bkdir/controlfile.ora
SPOOL OFF;
Falls Dich (oder jemand anders) das entsprechende PLSQL-Package zum Erstellen des aufback.sql interessiert, kann ich es gern zur Verfügung stellen.
Gruss
Ralf