News
DBA-Tipp: Database Links und die DB Domain

Die Information ist ein schnelllebiges Gut. Jeden Tag werden wir mit hunderten Informationen zugemüllt. Deshalb sind wir bestrebt uns auf das Wesentliche zu konzentrieren und nur substantiell nachhaltige Informationen bereitzustellen.

Icon Unternehmen

Mit Database Links hat man die Möglichkeit, auf einfachem Weg transparent auf entfernte Oracle Datenbanken zuzugreifen. Sie bieten dem Anwender ein logisches Datenbank-Objekt, welches auf Ebene des Betriebssystems eine klassische Client-Verbindung zur Zieldatenbank realisiert. Bei der Bezeichnung von Database Links spielt der Datenbank-Parameter DB_DOMAIN eine wesentliche Rolle. Der Parameter ist ursprünglich dafür gedacht, Datenbanken gleichen Namens in verteilten Infrastrukturen logisch unterscheiden zu können. Beim Erstellen einer Datenbank mit dem Database Configuration Assistant (DBCA) wird der Wert des Parameters vom globalen Datenbanknamen abgeleitet. Analog zum Konzept von Domainnamen im Netzwerk lautet das Schema für den Global Database Name "name.domain". Fälschlicherweise führt dies oft dazu, dass die DB Domäne mit der Domäne im Netzwerk gleichgesetzt wird. Dies stellt den Sinn des Global Database Name aber spätestens dann in Frage, wenn in einer DNS Domäne mehr als eine Datenbank mit dem gleichen Namen existiert. Für den DBA bietet sich mit dem DB_UNIQUE_NAME in dem Fall weiterhin die Möglichkeit, logisch zwischen beiden Datenbanken unterscheiden zu können. Ist der Parameter DB_DOMAIN beim Erstellen der Datenbank gesetzt, wird dessen Wert beim Erstellen von Database Links stillschweigend automatisch an den gewählten Namen angehängt, insofern der Namenszusatz weggelassen wird.

Gleiches gilt fortan für die Qualifizierung von Database Links, der Domainname muss beim Zugriff auf den Link also nicht mit angegeben werden, wie in folgendem Beispiel zu sehen ist:

SQL> show parameter db_domain

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------
db_domain                            string      example.org
SQL> create database link foo connect to fibu identified by secret using 'sandbox';

Database link created.

SQL> select DB_LINK from dba_db_links;

DB_LINK
------------------------------------------------------------
FOO.EXAMPLE.ORG

SQL> select count(*) from user_tables@foo;

  COUNT(*)
----------
       164

SQL> create database link foo.world connect to fibu identified by secret using 'sandbox';

Database link created.

SQL> select DB_LINK from user_db_links;

DB_LINK
------------------------------------------------------------
FOO.EXAMPLE.ORG
FOO.WORLD

SQL>

Der triviale Ansatz, den Datenbankparameter DB_DOMAIN zurückzusetzen, ist an dieser Stelle nicht zielführend, da der globale Datenbank-Name von der Änderung nicht betroffen ist. Der globale Datenbank-Name wiederum lässt sich ändern, jedoch muss in dem Fall auch immer eine Domain vergeben werden. Es wäre im vorliegenden Beispiel also nicht möglich, den globalen Datenbank-Namen nachträglich auf SANDBOX zu ändern. Abgesehen davon sind die Auswirkungen einer solchen Änderung weitläufiger, zumal davon alle existierenden Database Links betroffen wären.

SQL> show parameter db_domain

NAME                                 TYPE        VALUE
------------------------------------ ----------- -----------
db_domain                            string
SQL> select property_value from database_properties where property_name='GLOBAL_DB_NAME';

PROPERTY_VALUE
------------------------------------------------------------
SANDBOX.EXAMPLE.ORG

SQL>

Wie im ersten Listing ersichtlich, kann dem Problem der Namensgebung einfach dadurch begegnet werden, dass der Domainname beim Erstellen mit angegeben wird. Die Domain des globalen Datenbank-Namens wird dabei ignoriert.

Im Falle von Migrationen und Konsolidierungsmaßnahmen von Datenbanken können aus dem Zusammenhang aber durchaus Konflikte entstehen. Insbesondere, wenn der DBA keinen Einfluss auf die Anwendungsschemata hat, aus welchen auf die betroffenen Database Links zugegriffen wird oder aber aus supporttechnischer Sicht eine Modifikation der Anwendung nicht in Frage kommt. Die Tatsache, dass der Zugriff auf Database Links auch ohne Angabe der Domain funktioniert - vorausgesetzt sie ist identisch mit der DB Domain -, hat mitunter zur Folge, dass auf Seiten der Applikation SQL und PL/SQL Konstrukte existieren, in denen Database Links nicht vollständig qualifiziert adressiert werden. Werden die betroffenen Schemata nunmehr in eine andere Datenbank importiert, deren DB Domain einen anderen Wert als in der Quelldatenbank hat, werden alle Objekte, die auf den Database Link ohne Angabe der Domain zugreifen, invalid. Das Problem wäre unkompliziert zu lösen, wenn Database Links wie andere Datenbankobjekte einfach umbenannt oder neu angelegt werden könnten. Dies ist jedoch nicht der Fall. Ein Database Link kann nicht umbenannt werden. Auch ein Remapping beim Import mit Datapump ist für Database Links nicht implementiert. Darüber hinaus ist ein Database Link, der nicht als public deklariert ist, nur für seinen Besitzer sichtbar. Das heißt um den Link neu anlegen zu können, muss er im Kontext des Applikationsschemas gelöscht und wiedererstellt werden.

Sind die Zugangsdaten des Nutzers, dem der Link gehört, nicht bekannt, bieten sich einem ungeachtet dessen mehrere Möglichkeiten den Link neu anzulegen.

Ein Workaround besteht darin, eine Prozedur im Schema des Nutzers anzulegen, in welcher der Link gelöscht und neu erstellt wird. Diese Variante macht sich die Tatsache zu Nutze, dass PL/SQL Prozeduren immer im Kontext des jeweiligen Schemas ausgeführt werden:

SQL> select owner, db_link from dba_db_links where owner='FIBU';

OWNER                          DB_LINK
------------------------------ ---------------------------
FIBU                           FOO.WORLD

SQL> create procedure "FIBU"."20140324_RECREATE_DB_LINK" as
    begin                                           
    execute immediate 'drop database link foo.world';                   
    execute immediate 'create database link foo connect to fibu identified by secret using ''sandbox''';;
    end;                                                                                                           
    /    
Procedure created.

SQL>
SQL> execute  "FIBU"."20140324_RECREATE_DB_LINK";

PL/SQL procedure successfully completed.

SQL> select owner, db_link from dba_db_links where owner='FIBU';

OWNER                          DB_LINK
------------------------------ ---------------------------
FIBU                           FOO.EXAMPLE.ORG

SQL> drop procedure "FIBU"."20140324_RECREATE_DB_LINK";

Procedure dropped.

SQL>

Die elegantere Lösung nutzt die Proxy-Authentifizierung der Datenbank. Dabei handelt es sich um ein relativ unbekanntes, aber umso praktischeres Feature der Oracle Datenbank, einem Nutzer zu erlauben, sich als ein anderer Nutzer als Proxy anzumelden. Es ist damit in etwa mit dem sudo Mechanismus in Linux Betriebssystemen vergleichbar. Im folgenden Beispiel wird dem Nutzer SYSTEM ermöglicht, sich mit dem Schema FIBU als Proxy anzumelden. Anschließend wird der Datenbank-Link im Schema FIBU erstellt.

SQL> alter user fibu grant connect through system;

User altered.

SQL> connect system[fibu]/system_password
Connected.
SQL> show user
USER is "FIBU
SQL> create database link foo connect to fibu identified by secret using 'sandbox';

Database link created.

SQL> connect system/system_password
SQL> show user
USER is "SYSTEM"
SQL> alter user fibu revoke connect through system;

User altered.

SQL>

Mitunter kann es auch erforderlich sein, sowohl den alten Database Link zu belassen als auch einen weiteren Database Link mit der neuen Domain als Namenszusatz zu erstellen. Dies ist genau dann der Fall, wenn von Seiten der Anwendung sowohl der vollständig qualifizierte Bezeichner als auch die Kurzform des Database Links Verwendung findet.