Logo Oracle Deutschland   DBA Community  -  Juli 2012
Daten versionieren mit Oracle Database Workspace Manager
von Heinz-Wilhelm Fabry, ORACLE Deutschland B.V. & Co. KG

Wie können extrem lange Transaktionen durchgeführt werden, also Transaktionen, die Datensätze über Stunden oder Tage exklusiv sperren, ohne dass diese langen Transaktionen 'normale' Transaktionen auf diesen Datensätzen behindern? Solche langen Transakionen sind zum Beispiel im Spatial Umfeld keine Seltenheit.

Wie können unterschiedliche historische Zustände von Produktionsdaten online zeitlich unbegrenzt vorgehalten werden? Die UNDO Daten, die das gesamte Änderungsvolumen einer Datenbank vorhalten, gewährleisten in der Regel nur einen zeitlich sehr limitierten Zugriff auf 'ältere' Daten. Und die Technologie der database archives, auch bekannt unter dem Namen Total Recall, erlaubt einerseits keine Änderungen an den älteren Daten und steht andererseits ausschließlich in der Enterprise Edition der Datenbank zur Verfügung.

Wie kann man die aktuellsten Produktionsdaten für WHAT-IF-Analysen verändern und währenddessen andere Benutzer ungestört auf den Originaldaten weiterarbeiten lassen? Ein SET TRANSACTION READ ONLY erlaubt keinerlei Änderungen und ist ebenfalls begrenzt auf die 'Reichweite' der UNDO Informationen. Zwar könnte man für derartige Analysen eine Datenbankkopie aus dem Backup aufbauen oder eine Standby Lösung implementieren, aber das ist doch eher aufwändig.

Es gibt eine verblüffend einfache Antwort auf diese scheinbar komplizierten Fragen. Sie heisst Oracle Database Workspace Manager oder kurz Workspace Manager (WM). Der WM ist ein Feature der Datenbank seit Oracle9i, das sowohl in der Standard als auch in der Enterprise Edition zur Verfügung steht. Anders als in den ersten Versionen ist er längst auch Bestandteil jeder Installation. Um so erstaunlicher ist es, dass so wenige Kunden ihn kennen. Dieser Artikel soll dazu beitragen, das zu ändern.

Vorbemerkungen

Dieser Artikel richtet sich in erster Linie an die oder den DBA. Diese/r sollte über die grunsätzlichen Möglichkeiten und die 'Mechanik' des WM informiert sein, auch um zum Beispiel bei Bedarfsberechnungen für den Speicherplatz oder ähnlichen DBA Aufgaben richtige Entscheidungen treffen zu können. Deshalb muss in Ansätzen darauf eingegangen werden, wie man mit dem Workspace Manager arbeitet. Primäre Zielgruppe des WM ist allerdings die Anwendungsentwicklung - wie vielleicht auch am Titel des Handbuchs des WM deutlich wird: Oracle Database Workspace Manager Developer's Guide.

Bei genauerem Hinsehen ist der WM ein Werkzeug zum Erstellen und Verwalten zusammengehöriger Versionen von Datensätzen in einer Tabelle oder in mehreren Tabellen. Die zusammengehörigen Datensätze einer Version nennt man Workspace. Indem man auf SESSION Ebene angibt, in welchem Workspace - also mit welcher Version - man arbeiten möchte, sieht und manipuliert man dann nur die angegebene Version der Daten. Workspaces können verworfen oder nach bestimmten Regeln zusammengeführt werden. Konflikte, die beim Zusammenführen auftreten, können nach festen Regeln oder auch nach Einzelfallentscheidungen aufgelöst werden.

WM im Enterprise Manager Database Control Alle Möglichkeiten, die der WM zur Verfügung stellt, sind in Form von Prozeduren und Funktionen implementiert, die in dem Package DBMS_WM zusammengefasst sind. Die Ausführungsberechtigung für das Package ist an den Benutzer PUBLIC erteilt. Zusätzlich ist ein PUBLIC SYNONYM eingerichtet, so dass jeder Eigentümer einer Tabelle diese problemlos mit dem Workspace Manager zur Versionierung einrichten kann. Eine Tabelle, die nicht zum eigenen Schema gehört, kann man nur dann mit dem WM nutzen, wenn man das Privileg WM_ADMIN_ROLE besitzt. Das Privileg ist zum Beispiel in der Rolle DBA enthalten.

Der WM kann sowohl graphisch über den Enterprise Manager (EM) als auch über die Kommandozeile eingesetzt werden. Der Screenshot links zeigt den Einstieg in den WM unter dem Reiter SCHEMA. Im vorliegenden Artikel wird das Arbeiten über die Kommandozeile vorgezogen, weil es wahrscheinlich für das initiale Verständnis angemessener ist. Um dieses Verständnis weiter zu erleichtern, wird auch wieder mit den bekannten Tabellen des Schema SCOTT gearbeitet.

Tabellen für die Versionierung vorbereiten

Der Benutzer SCOTT bereitet seine Tabelle EMP mit folgendem Aufruf für die Versionierung vor:
EXECUTE DBMS_WM.EnableVersioning(Table_Name => 'emp');
Statt eines Tabellennamens oder einer Liste von Tabellennamen kann auch eine Oracle Spatial Topologie angegeben werden. Soll der angegebene Name auf eine Topologie verweisen, wird dazu der Parameter IsTopology der Prozedur EnableVersioning auf TRUE gesetzt.

Es passiert nun folgendes:
  • Die Tabelle EMP wird umbenannt zu EMP_LT, wobei wohl davon ausgegangen werden kann, dass LT für long transaction steht. Die Tabelle bleibt in dem Tablespace, in dem sie ursprünglich angelegt wurde. Auch alle zukünftigen Versionen der Datensätze der Tabelle bleiben in dieser Tabelle und auch in dem ursprünglichen Tablespace.
  • Der Tabelle EMP_LT werden zusätzliche Spalten hinzugefügt, die mit Verwaltungsinformationen für die Versionierung gefüllt werden können: VERSION ist die Row-Version-Id, NEXTVER ist die Next-Row-Version-Id, DELSTATUS ist der Delete-Status, LTLOCK ist der Lock-Status.
  • Es wird eine View angelegt, die den Namen der ursprünglichen Tabelle EMP erhält. Damit wird eine Modifikation aller Anwendungen unnötig, die auf die ursprüngliche Tabelle lesend zugreifen.
  • Auf der View EMP werden INSTEAD-OF-Trigger angelegt, die alle DML-Aktionen so modifizieren, dass sie auf der umbenannten Tabelle - EMP_LT - ausgeführt werden. Damit wird eine Modifikation aller Anwendungen unnötig, die auf die ursprüngliche Tabelle EMP schreibend zugreifen.
Über den zusätzlichen Paramter Hist beim Aufruf der Prozedur EnableVersioning würde festgelegt, dass eine weitere Tabelle angelegt wird, in der Informationen über die Veränderungen abgelegt werden, die innerhalb eines Workspace an der Tabelle EMP durchgeführt werden. Die Tabelle mit den Informationen über die Veränderungen würde EMP_HIST heissen.

Workspace anlegen

Nachdem die Tabelle EMP zur Versionierung vorbereitet ist, wird nun ein Workspace angelegt. Das Workspace wird immer unterhalb des Workspace angelegt, in dem sich der Anwender gerade befindet. WICHTIG: Damit ist impliziert, dass man also auch Hierarchien von Workspaces anlegen kann! Dazu ergänzend der Hinweis, dass das oberste Workspace immer LIVE heisst, und dass es dieses Workspace LIVE in jeder Datenbank gibt. Das Anlegen des neuen Workspace, hier unterhalb des Workspace LIVE, geschieht mit folgendem Befehl
EXECUTE DBMS_WM.CreateWorkspace('dbacommunity');
Bei der Schreibweise des Namens des Workspace wird die Gross- und Kleinschreibung berücksichtigt.

In einem Workspace arbeiten

Man arbeitet in einem Workspace, indem man sich zunächst in ihn hinein 'bewegt'. Das geschieht durch das Aufrufen einer Prozedur, nämlich
EXECUTE DBMS_WM.GotoWorkspace('dbacommunity');
Im Rahmen einer Anwendung kann man natürlich Navigationsmöglichkeiten zwischen Workspaces anbieten. Oder man kann durch einfache Logon Trigger für Anwendungen völlig transparent festlegen, in welchem Workspace gearbeitet wird.
EXECUTE DBMS_WM.GotoWorkspace('LIVE');
Ist unklar, in welchem Workspace man sich befindet, kann man sich mit der Funktion GetWorkspace darüber informieren.
SELECT DBMS_WM.GetWorkspace FROM dual;
Arbeiten mit dem WM Egal in welchem Workspace man sich befindet, man arbeitet ganz normal, ohne jede besondere Syntax und völlig transparent mit den Tabellen- oder Topologiedaten des Workspace. Das Bild links illustriert dies an einem Beispiel.

Der Benutzer (hier SCOTT) befindet sich im Workspace LIVE.

Dort selektiert er den Namen und das Gehalt des Benutzers SMITH aus der Tabelle EMP,



ändert dann das Gehalt auf den Wert 42,



schreibt die Änderung mit COMMIT fest und


lässt sich den geänderten Wert nochmals anzeigen.



Dann wechselt er in das Workspace dbacommunity.



Das Ergebnis des SELECT auf die Tabelle DUAL bestätigt den erfolgreichen Wechsel.


Als nächstes selektiert SCOTT den Namen und das Gehalt des Benutzers SMITH. Da in dem Workspace dbacommunity das Gehalt nicht geändert wurde, steht hier noch der Wert zur Verfügung, der zum Zeitpunkt des Anlegens des Workspace galt (800).

Nun ändert SCOTT das Gehalt auf 888,


schreibt die Änderung mit COMMIT fest und



selektiert zur Überprüfung den neuen Wert.
Es wäre übrigens durchaus möglich, innerhalb des Workspace mit SAVEPOINTs und ROLLBACKs zu arbeiten. Diese Befehle werden allerdings in WM eigene Prozedur-Varianten eingebettet - zum Beispiel in DBMS_WM.CreateSavepoint oder in DBMS_WM.RollbackToSP.

Daten aus unterschiedlichen Workspaces zusammenführen

Selbstverständlich sind Workspaces - mit Ausnahme des Workspace LIVE - zu löschen. Die Prozedur DBMS_WM.RemoveWorkspace löscht einen Workspace und alle dazugehörigen Datensatzversionen. Auch die Versionierungsinfrastruktur der versionierten Objekte kann gelöscht werden. Dies passiert mit der Prozedur DBMS_WM.DisableVersioning.

Interessanter ist allerdings sicherlich die Frage, wie man Daten aus unterschiedlichen Workspaces zusammenführt. Fügt man Daten aus einem hierarchisch übergeordneten Workspace (parent) in ein untergeordnetes Workspace (child) ein, so bezeichnet man dies als REFRESH. Das Refresh kann auch kontinuierlich erfolgen, das heisst, dass jede Änderung aus dem parent sofort in das child übernommen wird. Will man den umgekehrten Weg gehen, also die Daten aus dem child in das parent Workspace übernehmen, so bezeichnet man dies als MERGE. Ein Merge der beiden Workspaces LIVE und dbacommunity würde mit folgendem Aufruf angestossen:
EXECUTE DBMS_WM.MergeWorkspace(workspace =>'dbacommunity');
Bei beiden Operationen, also sowohl beim Refresh als auch beim Merge, können - ähnlich wie im Replikationsumfeld - Konflikte auftreten. Ein Konflikt existiert zum Beispiel, wenn ein Datensatz in einem Workspace gelöscht wurde und in dem betroffenen anderen Workspace dieser Datensatz noch existiert.

Konflikte werden nicht durch das RDBMS gelöst, sondern müssen durch den Anwender gelöst werden. Natürlich kann dies gegebenenfalls unter Zuhilfename von Routinen geschehen, die der Anwendungsentwickler hinterlegt hat. Dabei ist das Anstoßen einer Refresh- oder Merge-Operation der erste Schritt. Dieser Schritt scheitert, sofern Konflikte vorhanden sind. Das Scheitern veranlasst allerdings, dass eine sogenannte Konflikttabelle angelegt wird, die immer tabellenname_CONF heisst. Dort werden Informationen zum Konflikt abgelegt. Zur Lösung der Konflikte sind einige einfache Schritte nötig, mit denen schliesslich festgelegt wird, ob der Wert des parent oder der des child Workspace übernommen wird oder ob alternativ das gelten soll, was im Workspace LIVE verzeichnet ist.

Workspaces überwachen

Es gibt eine ganze Reihe von Data Dictionary Views, die zur Überwachung von Workspaces dienen. Allein die Gruppe der USER_ Views umfasst nahezu 20 Views. Wichtig für den DBA sind sicher die Views DBA_WORKSPACES, DBA_WORKSPACE_SESSIONS und ALL_REMOVED_WORKSPACES. Die Auflistung aller statischen Data Dictionary Views zum WM befindet sich im oben angesprochenen Handbuch zum WM, dort im 5. Kapitel.

Weitere Informationen

Das oben bereits genannte Handbuch ist sicherlich die zentrale Informationssammlung für alles, was im Zusammenhang mit dem WM an Fragen auftauchen kann. Wem dies für eine eigene anfängliche Beschäftigung zu detailliert ist, der sei auf die WM Seite auf oracle.com verwiesen.

Wer sich speziell aus dem Blickwinkel der Anwendungsentwicklung näher für den WM interessiert, dem seien die beiden Artikel Eine Tabelle - mehrere unabhängige Arbeitsbereiche und dem darauf aufbauenden Folgeartikel im Rahmen der APEX Community empfohlen. Auch das Support Dokument mit der Doc ID 181465.1 auf MOS stellt anhand eines Beispiels vor, wie man mit dem WM arbeitet.

Ausserdem gibt es unter der Doc ID 156963.1 ein FAQ zum WM sowie eine eigene Einführung zum Workspace Manager unter der Doc ID 156574.1.

Man könnte übrigens durchaus auf den Gedanken kommen, den WM auch für das Upgrade von Anwendungen einzusetzen. Allerdings bietet Oracle dazu eine spezielle Technologie an, die unter dem Namen Edition Based Redefinition (EBR) seit der Datenbankversion 11.2 zur Verfügung steht und die das unterbrechungsfreie Upgrade von Anwendungen ermöglicht.


Zurück zur Community-Seite