Service-Hotline
Support-Hotline
max. 12 Cent/Min. aus dem Festnetz der Deutschen Telekom
Email
info@remote-dba.info
Aktuelle Downloads
Interessante Information als PDF.
Oracle Outsourcing als Alternative - ASPICON Business Whitepaper, kostenlos (PDF)Auszeichnung als innovativstes Produkt in der Kategorie Outsourcing beim Innovationspreis ITK 2007Aktuelle Meldungen
Dbvisit Standby: Connect Failover auf die Standby-Datenbank
Datum 28.12.2011
Nach einem Switchover oder Failover mit Dbvisit Standby auf eine Oracle Standby-Datenbank steht der Oracle Administrator vor der Herausforderung, möglichst schnell und mit geringem Aufwand die Clients und Applikationen, die vormals die Primärdatenbank nutzten, nun auf die Standby-Datenbank zu lenken. Dbvisit Standby selbst (wie Data Guard übrigens auch) stellt dafür keine Unterstützung bereit.Grundsätzlich gibt es für diese Aufgabe zwei verschiedene Lösungsansätze
(1) Änderung des Datenbankhosts im Connect String (a) oder DNS (b)
(2) Nutzung des Transparent Application Failover (TAF)
1. Änderung des Datenbankhosts
Schauen wir uns Fall (1) anhand folgenden Beispiels an:
Hostname Primärserver: dbprod
Hostname Standbyserver: dbstandby
Servicename: orcl
Net Service Name: orcl_ha
Im Fall (1a) ändern wir nach einem Switchover/Failover den im Connect String verwendeten Hostnamen
(bzw. die IP) vom Primär- auf den Standbyserver.
Aus einem tnsnames.ora Eintrag
orcl_ha=
(description=
(address = (host = dbprod)(protocol = tcp)(port = 1521))
(connect_data = (service_name = orcl)))
würde nach dem Switchover/Failover
orcl_ha=
(description=
(address = (host = dbstandby)(protocol = tcp)(port = 1521))
(connect_data = (service_name = orcl)))
bzw. würde im Falle eines JDBC-Connects aus
jdbc:oracle:thin:@dbprod:1521/orcl
nach dem Switchover/Failoverjdbc:oracle:thin:@dbstandby:1521/orcl
Diese Lösung wäre die simpelste, wenn die Änderung nur an sehr wenigen, idealerweise nur einer Stelle vorzunehmen ist. Eine Konstellation, die man häufig bei einer zentralen tnsnames.ora für alle Clients, der Namensauflösung per Oracle Internet Directory oder Active Directory, oder einem Connect String auf dem Applikationsserver vorfindet. Entscheidender Nachteil dieser Lösung ist, sie lässt sich nur bei zentralisierter Namenskonfiguration effizient einsetzen.
Ist diese Voraussetzung nicht gegeben, kann auf Variante (1b) ausgewichen werden, die sich zur Namensauflösung des Datenbankservers eines DNS-Alias' bedient. Zusätzlich zu den Hostnamen aus obigem Beispiel definieren wir in dem Fall noch einen DNS CNAME Eintrag dbha, der anfangs als DNS Alias auf den Host dbprod verweist.
Sowohl tnsnames.ora Eintrag als auch JDBC Connect String bleiben nun bei einem Switchover/Failover unverändert auforcl_ha=
(description=
(address = (host = dbha)(protocol = tcp)(port = 1521))
(connect_data = (service_name = orcl)))
bzw.
jdbc:oracle:thin:@dbha:1521/orcl
gesetzt. Statt dessen würde lediglich der CNAME dbha umgelenkt auf den Hostnamen dbstandby. Vorteil dieser Variante ist, dass sie sowohl für zentralisierte als auch verteilte Namenskonfiguration funktioniert. Als ein großer Nachteil ist allerdings hier anzuführen, dass der Connect Failover sehr stark verzögert werden kann, da u.U. die neue DNS Konfiguration erst auf die DNS Server replizieren muss und die Name Service Caches der Clients manuell geflusht werden müssen. Das heißt, obwohl die Datenbank bereits längst wieder online ist, können sich viele Clients aufgrund der verzögerten DNS Aktualisierung noch nicht darauf verbinden.
2. Transparent Application Failover (TAF)
Sauberste und flexibelste Lösung wäre jedoch Variante (2), ein dynamischer Connection Failover. Hierbei werden beide Server, sowohl dbprod als auch dbstandby, in einen gemeinsamen Connectstring aufgenommen und zwischen beiden ein Failover definiert.
Der entsprechende tnsnames.ora Eintrag wäre dann also folgendermaßen:orcl_ha=
(description=
(address = (host = dbprod)(protocol = tcp)(port = 1521))
(address = (host = dbstandby)(protocol = tcp)(port = 1521))
(failover = yes)
(connect_data =(service_name = orcl_taf)
(failover_mode =
(type = select)
(method = basic))
))
Auch für JDBC muss nun der komplette Connectstring verwendet werden:
jdbc:oracle:thin:@(description=(address=(host=dbprod)(protocol=tcp)(port=1521))(address=(host=dbstandby)(protocol=tcp)(port=1521))(failover=yes)(connect_data=(service_name=orcl_taf)(failover_mode=(type=select)(method=basic))))
Bei dieser Variante ist es wichtig, dass der Service orcl_taf nur auf der aktuellen Primärseite aktiv ist. Falls nicht, besteht die Gefahr, dass Clientconnections fälschlicherweise auf die jeweilige Standbydatenbank gelenkt werden und den Fehler
ORA-01033: ORACLE initialization or shutdown in progress
erhalten.
Der korrekte Servicestatus kann auf verschiedene Arten, abhängig von der Infrastruktur, auf der die Datenbanken laufen, erreicht werden.
a. Mit einer stand-alone Datenbank muss der DBA den Servicename auf der Primärseite registrieren:
SQL> alter system set service_names='orcl_taf', ;
SQL> alter system register;
und vom Standbyserver abmelden
SQL> alter system set service_names= ;
SQL> alter system register;
b. Falls die Datenbank mittels Oracle Clusterware 10g oder 11g (RAC oder Cold Failover) betrieben wird, wird ein Cluster-Service definiert, um das Servicemanagement zu vereinfachen. Dies muss sowohl auf Primär-, als auch auf Standyseite geschehen:
srvctl add service -d orcl -s orcl_taf
Der DBA startet nun den Cluster-Service auf dem Primärserver
srvctl start service -d orcl -s orcl_taf
und stoppt ihn auf dem Standby-Server
srvctl stop service -d orcl -s orcl_taf -f
c. Mit einer Dbvisit Standby-Lösung, basierend auf Oracle Grid Infrastructure 11gR2 oder Oracle Restart, wäre es möglich, den Start und das Herunterfahren des Services vollständig zu automatisieren. Dies geschieht durch den neu eingeführten -l Paramter des srvctl Befehls. Sowohl auf dem Primär-, als auch auf dem Standbyserver definiert der DBA die gleichen Services und startet sie beide
srvctl add service -d orcl -s orcl_taf -l primarysrvctl start service -d orcl -s orcl_taf
Grid Infrastructure oder Restart kontrollieren die Datenbank permanent. Wenn die Rolle der Datenbank von PRIMARY zu PHYSICAL STANDBY, den Status, in den eine Dbvisit Standby gesteuerte Standbydatenbank wechselt, wird der Service automatisch heruntergefahren. Ebenso geht der Service offline, wenn eine Datenbank ausfällt und ein Failover notwendig wird. Umgekehrt wird der orcl_taf Servic automatisch gemeinsam mit der vorherigen PHYSICAL STANDBY-Datenbank hochgefahren, wenn diese die PRIMARY-Rolle einnimmt.
Gern stehen wir Ihnen bei weiteren Fragen zu diesem Thema zur Verfügung.
Weitere Informationen zu Dbvisit erhalten Sie hier.
Autor: Thilo Solbrig (Oracle Certified Master)
DBA-Tipp des Monats
