Weitere Themen in Arbeit.

RAC unterstütuzt die folgenden Loadbalancing-Mechanismen:

• Client-side Loadbalancing
  Die Verteilung erfolgt durch den Oracle Client ( z.b. tnsnames.ora).
• Server-side Loadbalancing
  Die Listener Prozesse der Knsoten tauschen regelmäßig Informationen aus und hängen die Verbindungen zum Client um. Die Konfiguration über die REMOTE_LISTENER Konfiguration.
  Es ist eine Connection-Count (round-robin-Verteilung) oder workload-basiert Verteilung der Sessions möglich.

Wichtig ist die Verwendung der VIP Interface Namen, diese sollten sauber im Netz aufgelößt werden können!
Mit LOAD_BALANCE = yes wird SQL*Net angewiesen zufällig einen der Einträge in der ADDRESS_LIST zu verwenden.

Eintrag in TNSNames.ora:

MYDB  =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = RACmydb1VIP)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = RACmydb12VIP)(PORT = 1521))
      (ADDRESS = (PROTOCOL = TCP)(HOST = RACmydb13VIP)(PORT = 1521))
      (LOAD_BALANCE = yes)
    )
    (CONNECT_DATA =
      (SERVICE_NAME = opera)
    )
  )
 )

Die Listener kommunizieren untereinander über den Auslastungsgrad

Szenario: Ein Node der Datenbank soll neu gestartet werden. Die Anwender sollen sich in den Tagen zuvor nicht mehr an diesen Knoten anmelden, damit sowenig Störungen wie möglich durch bereits angemeldete Sessions entstehen.

Ablauf:

1. Clients: Anpassen der TNSNames der Clients (Adresseintrag des Knotens löschen)
2. DB Knoten: Remote Listener Eintrag auf dem Knoten, der neu gestartet werden soll, entfernen.
   Damit wird der Knoten wird aus dem Load Balacing genommen.
   mit „alter system set REMOTE_LISTENER='' scope=memory sid='node2';“
3. Client: SQL*Plus Session ca. 20/30 mal starten um den Effekt zuprüfen!
4. DB Knoten: Knoten vor dem Reboot mit „srvctl stop instance -d mydb -i node2“ stoppen
5. Clients: Nach dem Reboot Client TNSNames wieder anpassen