Servicename oder nicht?

Vor ein paar Wochen bin ich wieder einmal über das Problem der Namenskonvention gestolpert. In einem meiner Projekte sollte eine Cloningsoftware installiert werden. Das funktionierte soweit auch sehr gut, aber das Einbinden der ersten Datenbank schlug fehl. Die Fehlermeldung sagte, dass der Service nicht verfügbar wäre – aber meiner Ansicht nach waren alle Einträge korrekt…

Servicename

Welche unterschiedlichen Möglichkeiten haben wir, wenn wir uns remote an die Datenbank anmelden? Damit ist auch schon der erste Fehler passiert. „an die Datenbank anmelden“ stimmt nicht. Wir verbinden uns mit der Instanz, nicht mit der Datenbank. Und damit haben wir die direkte Verbindung: Wenn wir den Oracle System Identifier (SID) kennen, dann können wir uns direkt mit dieser und damit der Instanz verbinden. Das funktionierte schon mit der Version 6, und die Möglichkeit gibt es auch noch mit der Version 12. Diese Methode nutzen wir bei dem Befehl „sqlplus / as sysdba“. Über die Variable ORACLE_SID können wir uns an die Instanz mit dieser SID anmelden.
Die Benutzung der SID sollte sich aus heutiger Sicht aber auf genau diesen einen Fall beschränken. Wenn es um eine Verbindung über den Listener handelt, sollte immer ein dedizierter Service verwendet werden – und nicht die Oracle SID!
Mit der Version 9 hat Oracle Services eingeführt und bei der Erstellung einer neuen Datenbank wird automatisch mindestens ein Service angelegt, der genau so heißt, wie die Datenbank (und nicht wie die Instanz). Dieser Service sollte allerdings aus meiner Erfahrung heraus nie benutzt werden! Warum? Weil er nicht angepasst werden kann. Der entscheidende Vorteil bei der Verwendung von Services ist, dass man eigene Services definieren kann. Damit kann man den Namen der Datenbank „verstecken“, d.h. eine Anwendung, die später den Service benutzt, weiß nicht, zu welcher Datenbank dieser Service gehört. Zieht die Anwendung um, dann kann der zugehörige Service einfach mit umziehen, somit eine Vereinfachung in der Administration. Beim Real Application Clusters (RAC) kann ich dem Service außerdem weitere Merkmale, wie z.B. die Failover Parameter mitgeben oder die präferierte bzw. verfügbaren Instanzen, auf denen dieser Service laufen soll. Schließlich kann ich einen Service explizit für Wartungszwecke starten bzw. Stoppen. Damit kann ich als Administrator immer noch Remote mit „meinem“ Service auf die Datenbank zugreifen, die Anwendung mit „ihrem“ Service jedoch nicht.
Soweit so gut. In dem Projekt hatte ich einen Service für die Cloning Software angelegt und trotzdem funktionierte der Zugriff auf die Datenbank nicht – warum?
Für den Verbindungsaufbau zur Oracle Instanz gibt es bei Client-Werkzeugen unterschiedliche Möglichkeiten. Dazu gehören vor allen Dingen Easy Connect und der TNS-Alias. Der Easy-Connect besteht aus dem Hostnamen, dem Port und dem Oracle Service, z.B. in dieser Form:

SQL> sqlplus user/pwd@meinhost:1521/meinservice

Das funktioniert bei einer Single Instance Datenbank sehr gut, aber was ist mit RAC oder gar Dataguard. Hierfür stellt Oracle eine sehr komplexe Syntax zur Verfügung, z.B. in dieser Form:

SQL> sqlplus user/pwd@(DESCRIPTION =
   (ADDRESS_LIST =     
      (ADDRESS = (PROTOCOL = TCP)(HOST = beatles)(PORT = 1662))     
	  (ADDRESS = (PROTOCOL = TCP)(HOST = stones)(PORT = 1662))     
   )     
   (CONNECT_DATA =       
      (SERVER = DEDICATED)       
	  (SERVICE_NAME = JOHANNES)     
   )   
)

Sieht sicherlich nicht ganz einfach aus, daher wäre es doch schön, wenn man das verkürzen könnten. Sie wissen sicherlich, was ich damit meine: die gute, alte tnsnames.ora (gerne auch über LDAP).
Die tnsnames.ora stellt uns für die dargestellte Beschreibung (DESCRIPTION) einen Alias, z.B. „JOHANNES“ zur Verfügung. Mit diesem Alias kann ich mich jetzt scheinbar mit der Instanz verbinden. Dabei muss übrigens der Alias nicht genau so heißen, wie der Servicename.

Fazit

Damit haben wir also drei unterschiedliche „Namen“, mit denen wir uns an die Instanz anmelden können:

1. die SID: nur bei lokaler Verbindung mit sqlplus / as sysdba verwenden.
2. den Servicenamen mit Easy Connect: eignet sich hervorragend für Single Instanz Datenbanken
3. den TNS-Alias: die Nutzung eines Aliases für die komplexe Verbindung z.B. für RAC oder Dataguard Umgebungen

Mein Problem in dem Projekt hatte sich damit auch gelöst: die Cloning Anwendung wollte einen TNS-Alias haben und keinen Servicenamen.