Oracle Net - trivadis.com

Oracle Net – Übersicht mit Tiefgang
Konrad Häfeli. Technology Manager Infrastructure. Januar 2010
1.
Schlüsselworte
Oracle Net Services, Oracle Net, SQL Net, Database Service, TAF, FAN, SDU, RTT
2.
Einleitung
Oracle Net, eine Komponente der Oracle Net Services, als Bindeglied und Entkopplungs-schicht
zwischen Applikationen und Datenbanken ermöglicht die Umsetzung von Client/Server resp.
Three Tier Architekturen. Es ist die Grundlage für die Verteilung der Belastungen auf
verschiedene physische oder auch logische Server. Die (Rückwärts-) Kompatibilität der
verschiedenen Versionen hat bis auf ein paar kleinere Vorkommnisse, wenn man sich an die
Grundfunktionalität gehalten hat, wenig Probleme bereitet. Meistens werden die Konfigurationen
via Files (sqlnet.ora, tnsnames.ora, listener.ora) gemacht, sodass diese relativ einfach kopiert und
auf die jeweiligen Bedürfnisse angepasst werden können.
Was war nun aber meine Motivation einen Vortrag über dies eigentlich nicht so prickelnde
Thema zu schreiben? Der Mensch wir aus Erfahrung klug… In einem MAA Projekt wurde die
scheinbar klare Konfiguration des Applikationszugriffs auf den hochverfügbaren
Datenbankservices (RAC abgesichert mit Dataguard) auf die Probe gestellt und gefährdete durch
Probleme die Endabnahme des Systems.
3.
Übersicht
Für die Verbindung eines Clients mit dem Server braucht Oracle Net die Information auf welchen
Server, über welchen Port auf welchen Service zugegriffen werden soll. Meistens geschieht das
mit dem TCP Protokoll und wird in einem sogenannten Verbindungsdeskriptor definiert. Dieser
definiert somit die physische Lokation des angegebenen Datenbankservices:
(DESCRIPTION =
(ADDRESS =
(PROTOCOL = TCP)
(HOST = pyrrha09)
(PORT = 1521)
)
(CONNECT_DATA =
(SERVICE_NAME = TECH11.ttc.trivadis.com )
)
)
Diese Deskriptoren werden meistens mit einem Alias versehen und in Repositories abgelegt
welche entsprechend der Naming-Methode unterschiedlich ausgeprägt sind.




Local Naming
Directory Naming
Easy Connect Naming
External Naming
 tnsnames.ora File
 LDAP compliant Directory Server
 expliziter connect string
 z.B. NIS (Network Information Service)
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.12.2010 . Seite 1 / 5
4.
Verfügbarkeit
Die Verfügbarkeitsfunktionalität von Oracle Net spricht vor allem die Applikation an. Dadurch
wird der gewünschte Datenbank Service auch im Fehlerfall (Instanz, Knoten, Lokation) erreicht.
Durchsatz-Anforderungen sind hier meist nicht ausschlaggebend, sondern fehler- und möglichst
verzögerungsfreie Automatismen.
Failover:
Mehrere Adressen können in der ADDRESS_LIST angegeben werden, dann wird per default
„connect time failover“ (FAILOVER=ON) gesetzt. Es wird sequentiell die Liste durchgegangen bis
die Verbindungen hergestellt werden kann.
Loadbalance:
Bei mehreren Connect Deskriptoren (DESCRIPTION_LIST) ist loadbalancing defaultmässig
eingeschalten. Es werden „random“ die Verbindungen hergestellt um die Last zu verteilen.
Die Kombination der Parameter versucht random eine Verbindung herzustellen bis eine
funktioniert.
(DESCRIPTION =
(ADRESS_LIST =
(FAILOVER = ON)
(LOAD_BALANCE = ON)
(ADDRESS = (PROTOCOL = TCP)(HOST = pyrrha01)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = pyrrha02)(PORT = 1521))
)
(CONNECT_DATA = (SERVICE_NAME = TECH11.ttc.trivadis.com ))
)
Durch die Konfiguration des remote_listeners wir nicht nur eine zahlenmässig gleiche Verteilung
der Verbindungen gemacht (clientseitiges Loadbalancing), sondern entsprechend der Serverlast
die Connectionrequests verteilt (serverseitiges Loadbalancing) .
Transparent Application Failover (TAF) wird bevorzugt auf der Server Seite implementiert. Durch
das Setzen der FAILOVER_MODE Parameter der Datenbank Services wir ein automatisches
reconnect auf einen verfügbaren Knoten möglich. Der FAILOVER_TYPE „SESSION“ macht zwar
kein nahtloser failover von offenen Cursorn, hat aber auch keinen Overhead bei normalen SelectOperationen auf der Clientseite.
begin
DBMS_SERVICE.CREATE_SERVICE(
service_name
=> 'TECH11’,
network_name
=> 'TECH11’,
failover_method => 'BASIC',
failover_type
=> 'SESSION',
failover_retries => 180,
failover_delay
=> 1);
end;
/
Client Programme können mittels Fast Application Notification (FAN) von einem Failover
benachrichtigt werden und ohne eventuelle TCP Timeouts abzuwarten auf überlebende Knoten
oder Lokationen reconnecten. Bei OCI Clients ist das mittels Advanced Queuing Funktionalität
relativ einfach möglich. Wenn beim DB Service die Notification gesetzt ist beinhaltet die
SYS.REG$ Tabelle die nötigen Client Informationen welche z.B. vom Dataguard Broker beim
Rollentausch durch einen DB Down Event in der Alert Queue informiert werden.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.12.2010 . Seite 2 / 5
begin
DBMS_SERVICE.MODIFY_SERVICE(
service_name
=> 'TECH11.ttc.trivadis.com',
aq_ha_notifications => true);
end;
/
Sind Knoten, resp. deren IP Adressen nicht mehr verfügbar ist es sehr zeitaufwändig durch die
verschiedenen ADDRESS Konfigurationen durch zu gehen und im schlimmsten Fall jeweils ein
TCP Connect Timeout abzuwarten. Durch das Setzen von
SQLNET.OUTBOUND_CONNECT_TIMEOUT im sqlnet.ora File kann dies auf den spezifizierten
Wert (wenige Sekunden) reduziert werden.
Es kann Applikationskonfigurationen geben, vor allem bei der Integration von alten Systemen, da
helfen die neuen Failoverfunktionen nicht in jedem Fall. Wenn im Extremfall IP Adressen direkt
in der Applikation codiert sind oder z.B. eigene Applikationsconnection Pools alloziert werden,
kann es Sinn machen die IP Adresse(n) des gecrashten Knotens auf den neuen PRIMARY Knoten
zu übernehmen. Solche Funktionalität kann mit Clustern oder eigenen Scripten implementiert
werden und ist in der Regel einfacher zu implementieren als komplizierte Client-Notifikationen in
alten Applikationen einzuführen.
5.
Performance
In der Regel ist die Datentransferlast einer Applikation kein Problem für eine Oracle Net
Verbindung. Datentransfer und das Verhalten bei grossen Lasten ist aber relevant beim Einsatz
von Oracle Net Services beim Redotransport in Dataguardumgebungen. Dabei tritt die Primary
Datenbank als Client auf, der Daten über das Netz zum Standby Knoten überträgt. Die Bandbreite
für die Übertragung der Daten von und zu den Clients hängt natürlich vom physischen
Netzwerkanschluss ab der heute meinst nicht unter 1GBit/sec liegt, was einer maximalen
Datenmenge von ca. 90 MB/s entspricht (Faustregel max. 70% Auslast des Netzwerks als
Sicherheit, Division durch 8 für Bit/Byte Umrechnung). Nebst konfigurationsrelevanten
Anpassungen kommen auch physische Effekte zum tragen, die in der Auslegung der Systeme
berücksichtig werden müssen, aber nicht umgangen werden können (gemessen als RTT, round
trip time).
Massive Verbesserugen im Netzwerkdurchsatz können erzielt werden wenn die beiden sqlnet.ora
Parameter RECV_BUF_SIZE und SEND_BUF_SIZE optimiert werden. Oracle empfiehlt diese auf
das Dreifache des „Bandwidth Delay Product“ (BDP) zu setzen. Dieses berechnet sich aus der
Roh-Bandbreite des Netzwerks multipliziert mit der Round Trip Time (RTT). Diese kann z.B.
durch den Einsatz von traceroute ermittelt werden (Faustregel ist 1 ms pro 50km
Übertragunsstrecke). Für ein GB Netzwerk mit einer Millisekunde RTT ergäbe das ein BDP von
125KB, die Bufferparameter sind optimal mit Faktor 3, somit auf 375‘000 Byte zu setzen.
1’000’000’000 bps * 0.001 s / 8 b * 3 = 375’000
RECV_BUF_SIZE = 375000
SEND_BUF_SIZE = 375000
Zur Verbesserung der Netzwerkauslastung und somit der Performance kann client- und serverseitig im sqlnet.ora der Wert für die „Session Data Unit“ (SDU) gesetzt werden. Default von 8kB
kann bei hoher Last auf 32KB gesetzt werden:
DEFAULT_SDU_SIZE=32767
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.12.2010 . Seite 3 / 5
Die SDU könnte ebenfalls im connect descriptor resp. in der SID_LIST des Listeners angegeben
werden.
Damit die Datenmenge für die Übertragung reduziert wird, hat Oracle ab 11gR1
Redocompression als Dataguardproperty eingeführt. Leider findet die Komprimierung nur statt
wenn ein log Gap geschlossen wird. Dabei aber ist die Reduktion mit 80-90% markant.
6.
Neue Funktionalität 11gR2
Oracle unterstützt in der aktuellen Version Internet Protocol Version 6 (IPv6), diese adressiert das
Problem der auslaufenden IPv4 Adressen. Für die Konfiguration von Oracle Net spielt das keine
Rolle, wenn der Hostname via DNS korrekt aufgelöst wird (entweder IPv4 oder IPv6).
Oracle Restart bringt eine Hochverfügbarkeitsfunktionalität auf Basis srvctl für eine Single-Instanz
Umgebung. Durch geeignete Konfiguration wird sichergestellt, dass der Listener-Prozess wieder
gestartet wird wenn er nicht mehr läuft.
srvctl
srvctl
srvctl
srvctl
add listener -l listener1120
remove listener -l listener1120
start listener -l listener1120
stop listener -l listener1120
Connection Timeouts können nun auf Basis der Deskriptoren konfiguriert werden und
übersteuern global gesetzte in sqlnet.ora. Dies ergibt flexiblere Konfigurationen im Dataguard
Umfeld:
TRANSPORT_CONNECT_TIMEOUT spezifiziert die Wartezeit von Oracle Net für die
Etablierung einer Verbindung auf den Datenbank Server. Er übersteuert
TCP.CONNECT_TIMEOUT im sqlnet.ora.
CONNECT_TIMEOUT spezifiziert die Wartezeit von Oracle Net für die Etablierung einer
Verbindung auf die Datenbank. Er übersteuert
SQLNET.OUTBOUND_CONNECT_TIMEOUT im sqlnet.ora.
7.
CIDR
Classless Inter-Domain Routing. In CIDR notation, an IPv6 subnet is denoted by the
subnet prefix and the size in bits of the prefix (in decimal), separated by the slash (/)
character. For example, 2001:0DB8:0000:0000::/64 denotes a subnet with
addresses 2001:0DB8:000:0000:0000:0000:0000:0000 through
2001:0DB8:000:0000:FFFF:FFFF:FFFF:FFFF. The CIDR notation includes
support for IPv4 addresses. For example, 192.168.2.1/24 denotes the subnet with
addresses 192.168.2.1 through 192.168.2.255.
8.
Fazit
Im Hochverfügbarkeitsumfeld, beim Einsatz von RAC und Dataguard, spielt Oracle Net und seine
optimale Konfiguration, eine grosse Rolle zur Erreichung der Ziele. Bei nicht optimierten
Einstellungen kann nebst der Datenbank Service Verfügbarkeit auch die Datensicherheit leiden,
weil aus Performancegründen nicht die nötigen Protection-Levels gesetzt werden können. Das
Austunen lohnt sich in jedem Fall und ist durch vergleichbar einfache Mittel zu erreichen. Schon
ab Oracle 10gR2 sind die wichtigen Funktionalitäten vorhanden, mit 11gR1 und R2 sind eher
kleinere Verbesserungen eingeführt worden.
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.12.2010 . Seite 4 / 5
Viel Erfolg beim Einsatz von Trivadis-Know-how wünscht Ihnen
Konrad Häfeli
Trivadis AG
Papiermühlestrasse 73
CH-3014 Bern
Internet: www.trivadis.com
Tel:
Fax:
Mail:
+41-(0) 31-928 09 60
+41-(0) 31-928 09 64
[email protected]
[email protected] . www.trivadis.com . Info-Tel. 0800 87 482 347 . Datum 01.12.2010 . Seite 5 / 5