Typisches RMAN-Backup-Script

Heute stellen wir ein typisches RMAN-Backup-Script vor, dass man in einer 10g-Umgebung zur vollständigen Datenbanksicherung benutzen kann. Zunächst meldet man sich beim RMAN an (ORACLE_SID ist gesetzt):

rman target /

Hier wird das Controlfile als Katalog benutzt, kein Katalog-Repository. Die aktuellen Einstellungen lässt man sich mit

RMAN> show all;

ausgeben.

Wir ändern die grundlegenden Einstellungen:

RMAN> configure channel device type disk format ‘z:\backup\rman_%d_t%t_s%s_p%p’;
=> Bestimmt das Zielverzeichnis für die Sicherung und den Aufbau der Dateinamen.

RMAN> configure controlfile autobackup format for device type disk to ‘z:\backup\%F’;
=> Bestimmt das Zielverzeichnis für das Controlfile-Autobackup. %F ist die DBID und sollte im Namen vorkommen.

RMAN> configure controlfile autobackup on;
=> Das automatische Backup des Controlfiles wird eingeschaltet.

RMAN> configure retention policy to redundancy 2;
=> Es werden 2 Backup-Sätze aufbewahrt.

RMAN> configure backup optimization on;
=> Es werden nur neue Archivelogs gesichert, nicht immer alle.

Mit diesem Script starten wir das Backup:

RMAN> run {
backup database plus archivelog delete all input;
backup current controlfile;
backup spfile;
}

Zunächst werden alle Datendateien gesichert. Dann wird das aktuelle Logfile archiviert, die Archivelogs gesichert, das dann aktuelle Logfile ebenfalls archiviert und auch gesichert. (Diesen ganzen Vorgang steuert ab 10g das ‘plus archivelog’-Statement.) Zu guter Letzt werden die gesicherten Archivelogs aus dem Quellverzeichnis (z.B. der Flash Recovery Area) gelöscht.

Das “backup current controlfile” benötigt man eigentlich nicht, wenn “autobackup controlfile” aktiviert ist, aber doppelt genäht hält einfach besser. Außerdem ist man als DBA grundsätzlich mißtrauisch.

Am Ende wird das SPFILE gesichert, was natürlich nur Sinn macht, wenn die Datenbank auch mit einem SPFILE gestartet wurde.

Überprüfen kann man das Backup z.B. mit

RMAN> report need backup;

Hier darf es kein Ergebnis geben, sofern das Kommando zeitnah nach dem Backup ausgeführt wird.

RMAN> list backup summary;

…listet alle Backups auf.

RMAN> restore database validate;

…prüft, ob die Datenbank im Fehlerfall wieder vollständig zurückgeholt werden könnte.

Achtung: RMAN sichert unter Windows nicht auf Netzlaufwerken und/oder in UNC-Pfaden. Ein Backup muss auf eine lokale Platte stattfinden, anschließend kann z.B. mit ROBOCOPY das lokale Backup-Verzeichnis mit einem Pfad im Netzwerk abgeglichen werden.

Tablespace-Belegungshistorie

Wer wissen möchte, wie sich seine Tablespaces in den letzten Wochen speicherplatzmäßig entwickelt haben, kann dies ganz einfach durch ein einfaches Query herausfinden, ohne dazu teure Zusatztools bemühen zu müssen:

select ts.name “Tablespace”,
vor_4_wochen.full “FULL%_4_WEEKS_AGO”,
letzte_woche.full “FULL%_LAST_WEEK”,
heute.full “FULL%_TODAY”
from (select tsu.tablespace_id,
round(
tsu.tablespace_usedsize/tsu.tablespace_maxsize*100,0) as
full
from wrh$_tablespace_space_usage tsu
where to_date(substr(tsu.rtime,1,13),’MM/DD/YYYY
HH24′)=to_date(to_char(trunc(sysdate),’MM/DD/YYYY
HH24′),’MM/DD/YYYY HH24′)
) heute,
(select tsu.tablespace_id,
round(
tsu.tablespace_usedsize/tsu.tablespace_maxsize*100,0) as
full
from wrh$_tablespace_space_usage tsu
where to_date(substr(tsu.rtime,1,13),’MM/DD/YYYY
HH24′)=to_date(to_char(trunc(sysdate-7),’MM/DD/YYYY
HH24′),’MM/DD/YYYY HH24′)
) letzte_woche,
(select tsu.tablespace_id,
round(
tsu.tablespace_usedsize/tsu.tablespace_maxsize*100,0) as
full
from wrh$_tablespace_space_usage tsu
where to_date(substr(tsu.rtime,1,13),’MM/DD/YYYY
HH24′)=to_date(to_char(trunc(sysdate-28),’MM/DD/YYYY
HH24′),’MM/DD/YYYY HH24′)
) vor_4_wochen,
v$tablespace ts
where ts.ts# = heute.tablespace_id
and ts.ts# = letzte_woche.tablespace_id
and ts.ts# = vor_4_wochen.tablespace_id
order by 4 desc;

Wichtig ist, dass die Datenhaltungszeit der ADDM-Statistiken > 28 Tage eingestellt ist und dass die Statistiken stündlich (alle 60 Minuten) gesammelt werden. Ansonsten liefert das Script eine leere Menge zurück.

E-Mail-Versand in Triggern

Aus dem Sekretariat kam folgende Anforderung: ändert sich die Spalte einer bestimmten Tabelle auf einen bestimmten Wert, soll eine E-Mail mit Informationen dieser Transaktion versendet werden.

Die Herangehensweise ist klar: ein On-Update-Trigger ruft UTL_MAIL (oder UTL_SMTP vor 10g) auf und versendet die E-Mail. Dieser Lösungsweg ist aber nur dann akzeptabel, wenn sichergestellt ist, dass der Benutzer diese Transaktion nicht mehr rückgängig machen kann, z.B. wenn die Applikation kein Rollback zulässt.

Wenn nämlich ein Rollback erfolgt, hat die Spalte wieder ihren ursprünglichen Wert, der Versand der E-Mail ist allerdings bereits erfolgt und kann nicht mehr rückgängig gemacht werden.

Tom “AskTom” Kyte beschreibt im Oracle Magazine und in seinem Blog eine Vorgehensweise, die dieses Verhalten verhindert:

Die Idee ist, dass man statt des E-Mail-Versandes einen Eintrag in die Queue von DMBS_JOBS vornimmt, die sich um den Versand der Post kümmert. Der Insert in die Job-Queue ist ja auch eine Transaktion, wird also nur vorgenommen, wenn die ursprüngliche Transaktion (die, die den Trigger auslöst) commited wird. Im Detail funktioniert das so:

SQL> create table do_ddl (job number primary key, stmt varchar2(4000));
Table created.

Diese Tabelle beinhaltet die Jobnummern und die Statements, die im jeweiligen Job ausgeführt werden sollen. In unserem Fall z.B. UTL_MAIL.SEND (…).

Anschließend liegen wir eine Stored Procedure an, die die Jobtabelle ausliest und die dort hinterlegten Statements ausführt:

SQL> create or replace procedure do_ddl_safely (p_job in number) is
2   l_rec do_ddl%rowtype;
3   begin
4     select * into l_rec from do_ddl where job = p_job;
5     execute immediate l_rec.stmt;
6   end;
7   /
Procedure created.

Im Trigger schließlich wird der Job in der Queue angelegt:

SQL> declare
2   l_job number;
3   begin
4     dbms_job.submit (l_job, 'do_ddl_safely (JOB);' );
5     insert into do_ddl (job, stmt) values (l_job, 'begin utl_mail.send (...) end;');
6   end;
7   /

Was passiert also?

1. Der Trigger legt einen Job an und schreibt das Statement mit der Jobnummer in die Tabelle DO_DDL.
2. Da für die ursprüngliche Transaktion noch kein Commit vorliegt, wird weder das DBMS_JOB.SUBMIT noch der Insert in die Tabelle wirklich ausgeführt.
3. Beim Rollback wird die ursprüngliche Transaktion (das Ändern des Spaltenwertes) sowie Schritt 1 rückgängig gemacht
   oder
   beim Commit wird die Änderung in der Spalte festgeschrieben, der Job wird erstellt und die Tabelle DO_DDL befüllt.
4. Der Job wird kurzzeitig nach dem Commit ausgeführt und die E-Mail wird versendet.

Diese Vorgehensweise ist natürlich nicht nur auf den Versand von E-Mails beschränkt, sondern eignet sich hervorragend, um ganz allgemein DDL in Triggern auszuführen.

Denn wie schreibt Mr. Kyte so schön:

Whenever you are tempted to do something nontransactional in a trigger, think 500 times more about it and then always decide againt it. It can lead only to really bad things.

Data Recovery Advisor in 11g

Seit Oracle 11g gibt es ja einige neue Backup- und Recovery-Features, unter anderem auch den Data Recovery Advisor.

Dieser neue Assistent soll Fehler ermitteln, klassifizieren, darstellen und auch lösen. In bunten Oracle-Bildchen sieht das dann so aus:

(Quelle: Oracle)

Wir haben den Ratschlaggeber Advisor mit einer kleinen Aufgabe auf die Probe gestellt: man nehme eine x-beliebige Oracle-Datendatei, zerstückele sie ein bisschen und warte, was passiert.

Zunächst die Ausgangslage: wir suchen uns die Datei EXAMPLE01.DBF aus, die zum Beispielschema der Datenbank gehört. Der Benutzer HR greift mit seinen Objekten auf diese Datei zu.

Wir öffnen die Datei mit dem VI und löschen mitten in der Datei wahllos zwei Zeilen (Kommando “dd”). Dann speichern wir die nun logisch korrupte Datei mit “wq!” ab.

Der nächste Screenshot zeigt, dass sich die Größe der veränderten EXAMPLE01.DBF vom Ausgangszustand unterscheidet.

Als Benutzer HR führen wir nun ganz unbedarft im SQL*Plus-Statement aus, das potenziell die von uns zerstörten Daten betrifft.

Und tatsächlich — wir haben auf Anhieb die kaputte Stelle getroffen und werden als Anwender sofort über den Schadensfall informiert. Falls wir wissend sind und genügend Rechte haben, können wir noch ein

analyze <Tabelle> validate structure;

ausführen und Oracle die Struktur der Tabelle prüfen lassen. Auch hier bekommen wir eine Fehlermeldung. (Falls der Anwender den Analyze-Befehl nicht ausführen kann, sollte der DBA auf diese Weise die Integrität der Tabelle überprüfen.) Nun ist es also höchste Zeit, den DBA anzurufen.

Dieser versucht sich ggf. mit dem DBVERIFY-Utility einen Überblick über die Lage zu verschaffen.

Im Enterprise Manager wird mittlerweile auch schon vor einem “kritischen Vorfall” gewarnt.

Die Fehlerbeschreibung ist eindeutig: EXMAPLE01.DBF ist defekt und somit sind einige Objekte im Example-Tablespace nicht verfügbar.

Der Recovery-Advisor bietet sogleich seine Hilfe an.

Die Empfehlung wird anhand des RMAN-Skripes dargestellt, das der Advisor zur Lösung des Problems ausführen möchte, so man ihn denn lässt: Hier soll die Datei EXAMPLE01.DBF aus dem vorhandenen RMAN-Backup wiederhergestellt und dann mittels der Archive-Log-Dateien auf den Stand vor dem Crash aktualisiert werden.

Gibt man dem Advisor freie Fahrt, legt er das RMAN-Skript als Job an und macht sich sogleich an die Arbeit…

Während der Laufzeit des Jobs hat man eine Übersicht über die einzelnen Schritte:

…und fertig!

Das ausgeführte Skript liest sich dann wie folgt:

RMAN-Report (PDF)

Fazit: In unserem einfachen Testszenario leistet der Advisor gute Arbeit. Man muss sich nicht um RMAN-Skripte kümmern, hat jederzeit den Überblick und konzentriert sich auf das Wesentliche. Wie sich der Advisor bei komplexeren Problemen verhält, bleibt auszutesten. Allerdings darf man nicht die eierlegende Wollmilchsau erwarten, denn Oracle setzt dem Advisor relativ enge Grenzen:

A. Physical corruption such as block checksum failures and invalid block header field values
B. I/O failures such as hardware errors and operating system driver failures
C. Inconsistencies such as a datafile that is older than other database files
D. Failures on standby databases

Für diese Fälle wird er sich gut eignen, nimmt dem DBA aber nicht die verantwortungsvolle Planung und Administration eines sicheren Backup- und Recovery-Konzeptes ab.

Nachdenklich ;-)

Mal wieder falsche Abfrageergebnisse in 11g

“Wrong results can occur from subquery unnesting if there is aPL/SQL function in a subquery with no columns as an argument(ie: all constants).

Workaround: Disable subquery unnesting in that subquery.“

Bug 6192202 vom 04.06.2008, Metalink Note 6192202.8

Platten-Geschwindigkeit messen, Teil 2

In einem der letzten Artikel haben wir beschrieben, wie mittels des DBMS_RESOURCE_MANAGER-Packages in einer installierten 11g-Instanz die Festplatten-Performance zu messen ist.

Allerdings stellt sich nicht selten die Frage, ob eine spezifische vorhandene Konfiguration überhaupt für den Einsatz einer Oracle-Datenbank geeignet ist. Bevor man nun Oracle installieren und mehr oder weniger umständlich Workload simulieren muss, kann man Ähnliches auch auf einem “nackten” System ohne installiertes Oracle-RDBMS tun — mit dem Oracle ORION-Tool.

Eine erste Einführung zu dem Thema findet man hier:
http://www.dbasupport.com/oracle/ora10g/disk_IO_03.shtml

Direkt mit ORION starten lässt sich hier:
http://www.oracle.com/technology/software/tech/orion/index.html

Reports

Heute möchte ich Euch ein Script vorstellen, das Reports produziert, die ich selten sah.

Zum Ausprobieren einfach nach http://idevelopment.info, genau, Jeff Hunter ist der Verfasser des Scripts.

Achja, der Name des Scripts, gibt es für 8i, 9i, 10g und 11g folgt noch:

Snapshot Database – (Producing DBA Reports in HTML)

Das habe ich jetzt von Copy & Paste, aber der Report ist schließlich auch groß

Sollten Fragen aufkommen, bezüglich, wer hilft mir bei der Analyse des Reports? Sischer, Sischer,……. wir

Platten-I/O-Geschwindigkeit messen in 11g

Von unserem geschätzten Kollegen Dr. Peter Alteheld kam heute folgende interessante Info:

Durch Aufruf von DBMS_RESOURCE_MANAGER.CALIBRATE_IO bekommt man in 11g heraus:

• wieviele single block-Lesezugriffe pro Sekunde von Platte durchgeführt werden können
• wieviele MByte pro Sekunde von Platte bei 1MByte-Zugriffen geholt werden können
• die Latenzzeit – also die Zeit zwischen Absenden der Plattenleseanforderung und Rücksenden der Daten – in Millisekunden

So kann man gut überprüfen, wie gut das drunterliegende Plattensystem ist – insbesondere auch bei Vergleichen zwischen Produktions- und Testsystemen. Die Software soll wohl einer Variante des Clarion-Tools entsprechen.

In 10g konnte man innerhalb der Datenbank ja nur per Sammeln von Systemstatistiken solche Daten erheben, die aber dann immer gleich in die Optimizerentscheidungen einflossen.

Doris

Ich stelle Euch Doris vor.

Doris wird Euch behilflich sein, ein Oracle Environment aufzubauen. Frauen und IT klappt verdammt gut, in diesem Fall

http://dizwell.com/2008/05/01/doris-redux/