Parameter der tnsnames.ora im RAC Umfeld

01.
März
2011
Veröffentlicht von: Stefan Hartsberger

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.

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.

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.

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

 

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:

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 / PRECONNECT

Der Select bricht ab. Client muss sich manuell reconnecten und den Befehl 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:

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 / PRECONNECT

Der Select bricht ab. Client muss sich manuell reconnecten und den Befehl 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 =
  (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 / PRECONNECT

Der Select bricht ab. Client muss sich manuell reconnecten und den 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. 

 

Wenn Sie mehr zu diesem Thema erfahren möchten, dann besuchen Sie unsere 
RAC Schulungen im März oder Ende Juni.

RAC

Jede Menge Know-how für Sie!

In unserer Know-How Datenbank finden Sie mehr als 300 ausführliche Beiträge zu den Oracle-Themen wie DBA, SQL, PL/SQL, APEX und vielem mehr.
Hier erhalten Sie Antworten auf Ihre Fragen.