Blog Johannes

Blog Johannes

johannes blog ohne logo

Blog Johannes

Flashback PDB mit Version 12.1.0.2

Veröffentlicht: 24. Februar 2017
Geschrieben von Johannes Ahrends

Flashback Pluggable Database

Oracle 12.2 steht in den Startlöchern und damit die Funktionalität des Flashback Pluggable Database. Allerdings wird es wohl noch etwas dauern, bis es die 12.2 in die Produktion schafft und außerdem brauchen wir noch Erfahrung damit, was es heißt, dass jede PDB ein UNDO-Tablespace bekommt. Denn das ist die Voraussetzung für das Flashback Pluggable Database. Aber es geht auch schon mit der Version 12.1.0.2 - und zwar dann, wenn es sich um eine Data Guard Konfiguration handelt. Interessant ist diese Konfiguration auch deshalb, weil es nach der Prozedur zwei Pluggable Databases gibt. Das Original und die Kopie auf dem älteren Stand.

Weiterlesen: Flashback PDB mit Version 12.1.0.2
 

PDB Cloning mit DataGuard

Veröffentlicht: 30. Januar 2017
Geschrieben von Johannes Ahrends

Die Herausforderung

Beim Einsatz von Multitenant Database in einer Data Guard Umgebung gibt es einige Besonderheiten. Nachfolgend wird an einem Beispiel erklärt, wie man eine PDB aus einer existierenden heraus erstellt und dabei die Data Guard Seite wieder synchronisiert. In diesem Beispiel wird Oracle 12 Release 1 (12.1.0.2) und Data Guard ohne Real Time Apply (also kein Active Data Guard) verwendet.

Weiterlesen: PDB Cloning mit DataGuard
 

Spende an die Tafel Erftstadt

Veröffentlicht: 09. Dezember 2016
Geschrieben von Johannes Ahrends

Spende an die Tafel Erftstadt

Wie wichtig es ist, anderen Menschen zu helfen, zeigt sich immer wieder an den "Tafeln" im Land. Viele ehrenamtliche Helfer sorgen dafür, dass Menschen, egal welcher Hautfarbe, Religion oder Herkunft zu Essen bekommen. CarajanDB hat in diesem Jahr die "Tafel Erftstadt" mit einer Spende in Höhe von 1000,00 Euro unterstützt. Wir bedanken uns bei allen Helfern und wünschen ein Frohes Weihnachtsfest.tafel 2016

 

Servicename oder nicht?

Veröffentlicht: 22. November 2016
Geschrieben von Johannes Ahrends

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> (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.

 

 

Multitenant im Dataguard Umfeld

Veröffentlicht: 05. Oktober 2016
Geschrieben von Johannes Ahrends

Derzeit arbeite ich in einem Projekt, in dem wir eine neue Infrastruktur mit RAC und Dataguard aufbauen. Aufgrund der Anforderungen einiger Anwendungen, z.B. die, die Anwendung zurücksetzen zu können, haben wir uns für die Multitenant Database Option und gegen eine Schemakonsolidierung entschieden.

Obwohl derzeit ein Zurücksetzen einer einzelnen PDB noch nicht unterstützt wird, können wir mit der Snapshot Standby Funktion ein Flashback auf der Standby Datenbank durchführen und aus dieser dann per Unplug / Create eine PDB auf einen bestimmten Zeitpunkt zurücksetzen.

Weiterlesen: Multitenant im Dataguard Umfeld
 

Seite 1 von 10

Johannes Ahrends

Twitter CarajanDB

CarajanDB GmbH

Siemensstr. 25  50374 Erftstadt

Fon: +49 (2235) 170 91 83

Fax: +49 (2235) 170 79 78

Mail: info@carajandb.com

 

carajan-db-logo