Wo ist der CONSISTENT-Parameter bei Data Pump?

Beim Einsatz von Data Pump ab 10g mag sich mancher wundern, wo der CONSISTENT-Parameter geblieben ist. Dieser Parameter stellte beim EXP-Tool die Konsistenz der Daten während des gesamten Exports sicher — kein völlig unwichtiges Feature also.

Bei Data Pump (EXPDP / IMPDP) übernehmen diese Funktion die Parameter FLASHBACK_SCN und FLASHBACK_TIME. Diese Parameter schließen sich bei Benutzung gegenseitig aus. Der Einsatz von FLASHBACK_SCN sichert die Konsistenz eines Exports zu einer bestimmten SCN, und FLASHBACK_TIME zu einem bestimmten Zeitpunkt. Üblicherweise würde man hier SYSDATE bevorzugen.

Das Ganze liest sich dann wie folgt:

#> expdp system/passwd directory=flsh dumpfile=user001_2.dmp 
  logfile=user001_2.log schemas=usr001
  flashback_time="TO_TIMESTAMP (TO_CHAR (SYSDATE, 'YYYY-MM-DD HH24:MI:SS'), 
    'YYYY-MM-DD HH24:MI:SS')"

Hierzu wird übrigens das Feature “Flashback Query” herangezogen, die FLASHBACK AREA muss hierfür nicht definiert sein. “Flashback Query” bedient sich aus dem UNDO-Tablespace.

Interessant hierzu ist der Metalink Artikel 377218.1: Expdp Message “FLASHBACK automatically enabled” Does Not Guarantee Export Consistency. Demnach wirft EXPDP die Meldung “FLASHBACK automatically enabled” aus, was aber nicht automatisch heißt, dass der gerade gestartete Export konsistent ist. Um dies zu erreichen, muß immer mit den Parametern FLASHBACK_SCN oder FLASHBACK_TIME gearbeitet werden.

Bei EXP/IMP kannte nur EXP den CONSISTENT-Parameter, bei Datapump sind es sowohl EXPDP wie auch IMPDP — schließlich kann IMPDP via Network-Link auch “exportieren”.

Datapump-Export mit NETWORK_LINK dauert lange

Im Rahmen einer Migration bin ich heute über den Bug 4513695 gestolpert: der Datapump-Export braucht unter Umständen sehr lange für das Bestimmen der Tabellen-Größen, noch bevor der eigentliche Export angefangen hat.

Genau genommen handelt es sich hier ja um den Datapump-Import, da der NETWORK_LINK-Parameter nur beim IMPDP möglich ist.

Jedenfalls scheint der IMPDP hier ewig lange festzuhängen, ohne dass sich etwas bewegen würde:

Starting "SYSTEM"."SYS_IMPORT_SCHEMA_04":  system/******** LOGFILE=imdp.log PARALLEL=4 
  REMAP_SCHEMA=scott:scott_clone SCHEMAS=scott network_link=orcl

Estimate in progress using BLOCKS method...
Processing object type SCHEMA_EXPORT/TABLE/TABLE_DATA

Und dann war’s das für lange, lange Zeit.

Die Lösung des Problems steht u.a. in Metalink Note 416238.1: Impdp With NETWORK_LINK Runs Very Slowly at Estimate Stage.
Die Lösung des Problems ist einfach:

ALTER SYSTEM SET CURSOR_SHARING='EXACT';

in der Zieltabelle ausführen und dann geht’s. Eine Übersicht, welche Datenbank welchen Parameter “verträgt”, findet man in Metalink-Note 421441.1.

Schema klonen mit Datapump

Oracle hat mit Datapump ab 10g ein neues Tool eingeführt, das die alteingesessenen, aber bewährten Tools EXP und IMP ablösen soll. Dabei ist es deutlich mächtiger, bringt aber auch einige Einschränkungen im Vergleich zur bisherigen Vorgehensweise mit sich. Doch dazu in einem späteren Artikel mehr.

Datapump kann hervorragend zum Klonen ganzer Schemata (neudeutsch auch Schemas) benutzt werden, und das sogar ohne eine Export-Datei anzulegen.

Hierzu bedient man sich der NETWORK_LINK-Funktionalität von Datapump, in dem es unter Umgehung des Filesystems die zu importierenden Daten direkt aus der Quelldatenbank saugt. Notwendig hierzu ist ein DATABASE LINK auf die Quelldatenbank. Will man ein Schema in der gleichen Datenbank klonen, legt man einfach einen Link auf die eigene Datenbank an (loopback).

Beispiel: wir möchten die Schemas SCOTT und EMILY in die Schemas SCOTT_CLONE und EMILY_CLONE klonen. Quell- und Zieldatenbank sind identisch: ORCL.

Zunächst wird der Database Link angelegt, z.B. mit

CREATE PUBLIC DATABASE LINK "TO_ORCL" CONNECT TO "SYSTEM" IDENTIFIED by "manager" USING 'orcl'

Wie der Dokumentation zu entnehmen ist, sollte für das Logfile ein Directory-Objekt vorhanden sein:

CREATE DIRECTORY "DATA_PUMP_DIR" AS '/u01/oracle/admin/ORCL/dpdump'

Dann startet man den IMport, denn der EXport wird bei Verwendung des Network-Modus impliziert:

impdp system network_link=to_orcl logfile=cloning.log
remap_schema='SCOTT':'SCOTT_CLONE','EMILY':'ELIMY_CLONE' schemas=SCOTT,EMILY

Dies ist ein Beispiel mit zwei zu klonenden Schemas, das funktioniert natürlich auch mit einem oder auch drei equivalent.

Wichtig ist, dass man SCHEMAS=… angibt, sonst kopiert Datapump die gesamte Datenbank (was nicht funktionieren würde), und remappt dabei die angegebenen Schemas.

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.

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/