Als PDF Downloaden!

Tipps & Tricks: März 2011
Bereich:
RAC
Erstellung:
03/2011 SH
Versionsinfo:
11.2
Letzte Überarbeitung:
03/2011 SH
Parameter der tnsnames.ora im RAC Umfeld
Wird Oracle Real Application Clusters (RAC) eingesetzt müssen mehrere Aspekte beachtet werden. Unter
anderem die Konfiguration der tnsnames.ora Datei (Client-Seite). Sie kann ab der Version 11g R2 einen
geringfügig veränderten Aufbau haben, da in 11g R2 das Konzept des Single Client Access Name (SCAN)
eingeführt wurde.
Wir vergleichen hier die verschiedenen Verbindungsmöglichkeiten zusammen mit ihren Parametern und deren
Auswirkungen. Ein besonderes Augenmerk legen wir dabei auf den Transparent Application Failover (TAF).
Die tnsnames.ora Datei einer Client-Anwendung könnte bei einem RAC mit zwei Knoten (rac1a und rac1b) und
dem alten Zugriffskonzept der virtuellen IP Adressen (VIP) wie folgt aussehen:
rac1 =
(DESCRIPTION =
(ADDRESS_LIST = (LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1a-vip.muniqsoft.de)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1b-vip.muniqsoft.de)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE=SESSION)
(METHOD
1. Parameter:
Die Optionen LOAD_BALANCE und FAILOVER beziehen sich ausschließlich auf den Verbindungsaufbau.
LOAD_BALANCE
Sorgt dafür, dass die Hosts in der Adress-Liste in einer zufälligen Reihenfolge angesprochen werden. Dadurch
wird die Last gleichmäßig auf die Knoten verteilt.
FAILOVER
Sorgt dafür, dass beim Scheitern eines Verbindungsaufbaus der nächste Host in der Adress-Liste genommen
wird.
Die Optionen TYPE und METHOD beziehen sich widerum nur auf das Verhalten eines Verbindungsverlustes zur
Laufzeit. Diese Art des Failovers wird auch Transparent Application Failover (TAF) genannt.
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 1 von 7
TYPE
Gibt die Art des Failovers an. Es gibt drei verschiedene Möglichkeiten:
TYPE=SESSION
Geht die Verbindung zur Datenbank verloren wird automatisch eine neue Session zu dem anderen
angegebenen Knoten aufgebaut. Alle offenen Cursor gehen dabei verloren.
TYPE=SELECT
Geht die Verbindung zur Datenbank verloren wird automatisch eine neue Session zu dem anderen
angegebenen Knoten aufgebaut. Offene Cursor können in der neuen Session weiter abgerufen werden.
(Continue Cursor Fetching)
TYPE=none
Wenn das Feld leer gelassen wird findet kein Failover statt. Dies ist der Default-Wert und kann unter
anderem explizit dazu verwendet werden einen Failover zu verhindern.
METHOD
Gibt an, wie schnell ein Failover stattfindet.
METHOD=BASIC
Baut zum Zeitpunkt des Verbindungsproblems eine Verbindung zum Backup-Knoten auf. Dies benötigt
fast keine Ressourcen auf den Backup-Knoten.
METHOD=PRECONNECT
Baut schon beim normalen Verbinden eine zweite Backup-Verbindung mit auf. Der Failover ist zwar
schneller, benötigt jedoch auf dem Backup-Knoten zusätzliche Ressourcen.
Des Weiteren gibt es noch die Optionen RETRIES und DELAY, welche hier nur wegen der Vollständigkeit kurz
beschrieben werden.
[...]
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE=SESSION)
(METHOD=BASIC)
(RETRIES=5)
(DELAY=10)
)
RETRIES
Gibt die Anzahl der Versuche an, sich erneut zu verbinden. Wenn RETRIES definiert ist wird DELAY automatisch
auf 1 Sekunde gesetzt.
DELAY
Gibt die Anzahl der Sekunden an, die gewartet werden sollen, um sich erneut zu verbinden. Wenn DELAY
aktiviert ist wird automatisch der RETRIES-Wert auf 5 gesetzt.
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 2 von 7
2. Testaufbau:
Ziel:
Wir testen drei verschiedene Verbindungsarten (Computername, VIP, SCAN) mit jeweils allen Kombinationen der
Optionen TYPE und METHOD.
Szenario:
In unserem Beispiel betreiben wir ein RAC (11g R2) mit zwei Knoten.
Wir verwenden dazu zwei VMs (Virtuelle Maschinen):
rac1a.muniqsoft.de und rac1b.muniqsoft.de
Alle Tests werden mit SQL*Plus durchgeführt.
Ablauf:
1. SQL*Plus öffnen und als "sys" anmelden.
SQL> conn sys/sys @rac1 as sysdba
Connected.
2. Überprüfen mit welchem Knoten man verbunden ist.
SQL> select host_name from v$instance;
HOST_NAME
---------------------------------------------------------------rac1a
3. Einen Select-Befehl absetzen, der einige Zeit in Anspruch nimmt.
Dieser Befehl liefert ca. 580.000 Zeilen zurück:
SQL> select * from dba_source;
4. Während der Select läuft fahren wir die VM, mit der wir gerade verbunden sind, herunter.
5. Nun beobachten wir, wie sich die Ausgabe des noch laufenden Select-Befehls verhält.
3. Auswertung:
Fall 1:
Als HOST-Adressen wurden die Computernamen angegeben.
Unser Beispiel sieht wie folgt aus:
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 3 von 7
rac1 =
(DESCRIPTION =
(ADDRESS_LIST = (LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1a.muniqsoft.de)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1b.muniqsoft.de)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE=SESSION)
(METHOD=BASIC)
)
)
)
Fall TYPE
METHOD
Ergebnis
1
SESSION BASIC
Der Select bricht ab. Client ist nach kurzer Zeit mit dem zweiten Knoten
verbunden. Select muss neu abgesetzt werden.
2
SESSION PRECONNECT
Der Select bricht ab. Client ist sofort mit dem zweiten Knoten verbunden.
Select muss neu abgesetzt werden.
3
SELECT BASIC
Der Select unterbricht kurz und läuft dann weiter.
4
SELECT PRECONNECT Der Select unterbricht kurz und läuft dann weiter.
5
NONE
BASIC /
Der Select bricht ab. Client muss sich manuell reconnecten und den Befehl
PRECONNECT erneut ausführen.
Ein Reconnect dauert hier sehr lange (ca. 30 Sekunden), wenn der erste angegebene Knoten ausfällt. Das liegt
daran, dass so lange auf eine Antwort der angesprochenen IP gewartet wird bis ein Timeout erfolgt. Erst danach
wird versucht sich mit dem zweiten Knoten zu verbinden.
Fall 2:
Als HOST-Adressen wurden die VIP-Adressen der Knoten angegeben.
Eine Virtuelle IP Adresse (VIP) ist, im Gegensatz zur normalen IP, nicht an einen Knoten gebunden. Sie kann
automatisch auf einen anderen Knoten umziehen.
Ist beispielsweise ein Knoten nicht mehr erreichbar, so wird die VIP auf einen noch erreichbaren Knoten
umgezogen. Somit bleibt die vom Client angesprochene VIP bis auf eine kurze Unterbrechung immer erreichbar.
Unser Beispiel sieht wie folgt aus:
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 4 von 7
rac1 =
(DESCRIPTION =
(ADDRESS_LIST = (LOAD_BALANCE=ON)(FAILOVER=ON)
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1a-vip.muniqsoft.de)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1b-vip.muniqsoft.de)(PORT = 1521))
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE=SESSION)
(METHOD=BASIC)
)
)
)
Fall TYPE
METHOD
Ergebnis
1
SESSION BASIC
Der Select bricht ab. Client ist nach kurzer Zeit mit dem zweiten Knoten
verbunden. Select muss neu abgesetzt werden.
2
SESSION PRECONNECT
Der Select bricht ab. Client ist sofort mit dem zweiten Knoten verbunden.
Select muss neu abgesetzt werden.
3
SELECT BASIC
Der Select unterbricht kurz und läuft dann weiter.
4
SELECT PRECONNECT Der Select unterbricht kurz und läuft dann weiter.
5
NONE
BASIC /
Der Select bricht ab. Client muss sich manuell reconnecten und den Befehl
PRECONNECT erneut ausführen.
Ein Reconnect benötigt in diesem Fall nur noch ca. 1-3 Sekunden.
Fall 3:
Als HOST-Adresse wurde die SCAN-Adresse angegeben.
Eine SCAN-Adresse ist ein Eintrag im DNS-Server, der bis zu drei verschiedene IP Adressen auflösen kann.
Somit spricht ein Client automatisch max. drei Knoten an.
Da wir in unserem Szenario nur zwei Knoten betreiben wird ein Knoten auf zwei IP Adressen erreichbar sein. Die
Parameter FAILOVER und LOAD_BALANCE werden hier nicht benötigt, da diese nur zum Einsatz kommen, wenn
mehrere Host-Adressen angegeben sind.
Unser Beispiel sieht wie folgt aus:
rac1 =
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 5 von 7
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = rac1-scan.muniqsoft.de)(PORT = 1521)
)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = racdb)
(FAILOVER_MODE =
(TYPE=SESSION)
(METHOD=BASIC)
)
)
)
Fall TYPE
METHOD
Ergebnis
1
SESSION BASIC
Der Select unterbricht kurz und läuft dann weiter.
2
SESSION PRECONNECT
Der Select bricht ab. Client ist sofort mit dem zweiten Knoten verbunden.
Select muss neu abgesetzt werden.
3
SELECT BASIC
Der Select unterbricht kurz und läuft dann weiter.
4
SELECT PRECONNECT Der Select unterbricht kurz und läuft dann weiter.
5
NONE
BASIC /
Der Select bricht ab. Client muss sich manuell reconnecten und den
PRECONNECT Befehl erneut ausführen.
In unseren Tests kam es einmal vor, dass der Select im Fall 4 mit der Fehlermeldung "ORA-25401: can not
continue fetches" abbrach. Alle weiteren Versuche lieferten dann das Ergebnis wie in der Tabelle beschrieben.
4. Anmerkung / Fazit:
Da wir alles mit SQL*Plus getestet haben, bleibt noch anzumerken, dass es durchaus sein kann, dass sich ein
anderer Client etwas anders verhält. Insbesondere gibt es Unterschiede beim "fetchen" des offenen Cursors.
Trotzdem kann man in den Tabellen erkennen welche Parameter welches Verhalten an den Tag legen. In den
Varianten Computername und VIP waren jedoch die Parameter TYPE=SELECT und METHOD=PRECONNECT am
zuverlässigsten. Lediglich bei Verwendung der SCAN-Adresse gab es mit diesen Parametern einmal Probleme.
Des Weiteren muss man beachten, dass METHOD=PRECONNECT immer auch Ressourcen auf dem passiven
Knoten nutzt.
Das neue Feature der SCAN Adresse hat den Vorteil, dass die tnsnames.ora Datei (Clientseite) nicht geändert
werden muss, wenn das RAC z. B. um einen Knoten erweitert wird. Die Änderungen erfolgen transparent für die
Clients an den SCAN-Listenern.
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 6 von 7
Wenn Sie mehr zu diesem Thema erfahren möchten, dann besuchen Sie unsere
RAC Schulungen im März oder Ende Juni.
Muniqsoft GmbH
Schulungszentrum, Grünwalder Weg 13a, 82008 Unterhaching, Tel. 089 / 679090-40
IT-Consulting & Support, Witneystraße 1, 82008 Unterhaching, Tel. 089 / 6228 6789-0
Seite 7 von 7