Blog 
Flashback Query – Teil 3

In meinem letzten Blog über Flashback-Query „Flashback Query – Teil 2“ musste ich zugeben, dass es mit der Oracle Database Standard Edition nicht so funktioniert hat wie erwartet. Also was, wenn wir die Enterprise Edition verwenden?

Dies ist ein ähnliches Beispiel mit dem gleichen Flashback-Data-Archive und der gleichen Tabelle aber mit der Oracle Enterprise Edition 12.1.0.2 mit dem PSU160419 vom April 2016.

 1

Wie man sieht, werden die Tabellen zum Flashback-Archive hinzugefügt und jetzt will ich die Spalte CHANGEDATE in die Tabelle „STATUS“ einfügen.

2

… keine Fehlermeldung! Alles funktioniert.

Großartig: Die Schemaowner oder Anwender werden nicht einmal bemerken, dass Flashback-Data-Archive aktiviert worden ist, egal welche Änderungen sie machen.

3

4

Für das Beispiel zeigt das Query, dass die neue Spalte mit dem Standardwert des aktuellen Datums eingefügt wurde.

5

Im Flashback-Archive können wir sehen, dass die zugehörige Flashback-Tabelle eingefügt wurde, da sowohl die Flashback-Tablespace- als auch die Total-Space-Spalte gültige Werte enthalten.

6

Wenn wir in den Schema-Browser schauen, sehen wir, dass die Tabelle SYS_FBA_HIST_93296 als partitionierte Tabelle erstellt wurde (das gleiche gilt für die Standard Edition), aber sie ist leer.

Das haben wir erwartet. Wenn man eine Spalte zu einer Tabelle hinzufügt, gibt es keinen „alten“ Wert oder früheres Abbild, das gespeichert wird.

7

Aber was passiert, wenn wir die Spalte löschen?

8

In diesem Fall wird der gesamte Tabelleninhalt ins Flashback-Archive geschrieben. Wenn man also Flashback-Archive benutzt, sollte man besser keine Spalten löschen oder größere Änderungen an Tabellen zu machen, solange man die Flashback-Archive-Tabelle nicht zuerst löscht.

Leider gelang es mir nicht den Inhalt der Tabelle in Toad aufzulisten. Ich vermute, der Link von der Originaltabelle „STATUS“ zur Flashback-Tabelle „SYS_FBA_HIST_93296“ ist fehlerhaft.

9

Fazit

Flashback-Data-Archive ist ein großartiges Feature, das hilft Anwendungsentwicklungen zu vereinfachen. Trotzdem muss man sich des Rattenschwanzes bewusst sein, der daran hängt. Aber trotz des Bugs in der Standard Edition, würde ich einen Versuch wagen. Einer meiner Kunden hatte das folgende Problem mit seiner Planung:

Der Scheduler verwendet eine Oracle Datenbank als Backend. Für jeden neuen Job wird ein Eintrag in die zugehörige Tabelle gemacht. Das ist ansich nichts besonderes. Aber Änderungen im Job führen zu einem Update der Zeile und noch problematischer: Nachdem der Job erfolgreich abgeschlossen ist, wird die Zeile wieder gelöscht! Also hat der Kunde keine Ahnung, ob ein Job erfolgreich abgeschlossen wurde oder niemals gelaufen ist! Da er keinen Zugang zu den Sourcen hat, haben wir Flashback-Data-Archive benutzt um einen Log der Job-Tätigkeiten zu schreiben. Jetzt haben wir nicht nur die Informationen über den Abschluss des Jobs, sondern auch über jeden Status dazwischen.

Keine Kommentare zu “Flashback Query – Teil 3

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Was kann CarajanDB für Sie tun?