Gunther Oracle APEX und Datenbank Wiki

Aufgabe:

Analyse des Oracle CMAN bzgl. Einsatzes als SQL*Net Gateway/Proxy für ältere Java Applikationen, die den Oracle TAF Standard für das automatische Failover nicht beherrschen bzw. bei denen sich die Applikations-Verantwortlichen weigern diese Standard Verhalten von Oracle unter Java einzusetzen.

Mit dem Oracle Connection Manager, der CMAN, kann das SQL*Net Protokoll über einen Rechner zwischen verschiedenem Netzwerk „geroutet“ werden.

Der CMAN ist bereits sehr lange Bestandteil der Oracle Installation, heute kann das der CMAN in der Oracle Client Installation gefunden werden.

Ursprünglich war einer der Haupteinsatz Zwecke das Routen zwischen verschiedenen Netzwerk Protokollen, zum Beispiel in einer SPX/IPX Welt nach TCP/IP.

Heute ist der CMAN sehr praktisch um Proxy Funktionalitäten zwischen verschiedenen TCP/IP Netzen zu realisieren.

Details zu CMAN unter 12c auch siehe SQL*Net Proxy und Firewall mit dem 12c CMAN, dem Oracle Connection Manager implementieren

Im Grundprinzip hat sich seit 11g nicht viel verändert, hier eine weitere Übersicht dazu für 11g ⇒https://www.pipperr.de/knowhow/cman/Oracle_Connection_Manager_CMAN_doag_sig_security_mai_2015.pdf

Oracle Connection Manager hat die folgenden neuen Featuer:

• Parameter „USE_SERVICE_AS_TNSNAMES_ALIAS“ um eine Anfrage an eine passende DB weiterzuleiten OHNE das diese sich zuvor am CMAN angemeldet hat

• REST APIs for CMCTL Commands
• GROUP syntax for rules
• BANDWIDTH in bytes per second at service level

Leider ist der Oracle Connection Manager nur zusammen mit der Oracle EE Edition verfügbar, siehe für 21c hier ⇒ https://docs.oracle.com/en/database/oracle/oracle-database/21/dblic/Licensing-Information.html

• Bündelt SQL*Net-Verbindungen
• Erweiterte Sicherheitsüberprüfungen
• Protokoll-Wandlung (TCP/IP –> SPX/IPX )
• Firewall-Architektur

Der Oracle Connection Manager wird über den cmctl gestartet, dieses Control Utility startet zuerst den Prozess cmadmin, dieser Prozess steuert den Listener und die Gateway Prozesse für das SQL*Net Routing.

Eine der Aufgaben kann es sein in einer Standby Umgebung den „Kunden“ auf die richtige, gerade aktive DB umzuleiten.

Normalerweise würde dazu TAF ⇒ Transparent Application Failover konfigurieren eingesetzt werden.

Siehe dazu auch für die Java Welt ⇒ Primary Note for Oracle JDBC High Availability Features (Doc ID 1100024.1) und 390923.1.

Hat man aber keine Einfluss mehr auf die Applikation, da diese zu alt ist oder die Maintainer der APP keine Lust mehr auf die Oracle Feature haben, müssen andere Lösungen gefunden werden.

Für eine Standby DB Umgebung können die folgenden Feature für eine Lösung eingesetzt werden:

• Datenbank (Single DB / RAC Cluster) registriert sich am CMAN
• CMAN kennt über TNS Auflösung des gewünschte Ziel
  • Client kann per SID oder per Service Name auf CMAN zugreifen, CMAN kennt das Ziel und leitet automatisch weiter

Hier ist zu beachten das wir einen dedizierten Service Namen benötigen der NUR auf der Primary Seite der Standby Umgebung auch aktiv ist! Also nicht den Default Service der DB!

Da nun von der Applikation der CMAN angesprochen wird, ist darauf zu achten hier eigenen DNS Einträge dazu zu verwenden und nicht den Hostname! So kann im Fehlerfall z.B. über DNS auf eine weiteren CMAN verwiesen werden!

Auch hat das den Vorteil das Änderungen an der Infrastruktur nicht zu dutzenden von anzupassenden lokalen Installation führt!

Ablauf:

• Basis Betriebssystem konfigurieren siehe Ein Oracle Linux 8 Basis System als Grundlagen für eine Oracle Clusterware und Datenbank Installation vorbereiten
  • Bei Bedarf den Firewall Port freischalten, falls FW aktiviert
• Installationspacket für den Oracle Client auswählen und herunterladen
  • Download hier ⇒ LINUX.X64_213000_client.zip (64-bit) (1,075,931,428 bytes) (sha256sum - 595d8b59901c68979e2ff065210916857d0c17e64b07ef0180b92c4c3519249f)

• Client Software inkl. CMAN installieren

• Client Software mit letzten Patch ausstatten (Stand 06.2022)
  • Patch bzw. DATABASE RELEASE UPDATE 21.6.0.0.0 (Patch)

    DATABASE RELEASE UPDATE 21.6.0.0.0 (Patch)
    p33843745_210000_Linux-x86-64.zip	876.1 MB	(918682641 bytes)
    SHA-256	E55AF80672AC89C8D0A5EE531F4B9CD9AB8232DE9A4F0B32D9FF4A7041E8AEFA

  • OPatch Patch - Patch 6880880: OPatch patch of version 12.2.0.1.29 or later = OPatch 12.2.0.1.30 for DB 21.0.0.0.0 (Apr 2022)

    p6880880_210000_Linux-x86-64.zip	
    SHA-1	132CE28CE48E74D33E5189A585026CEB7ED7DE12
    SHA-256	DF6E3AA379725E9ABFF1AB3BB840263F186A10A05CEB9AED1544E81AA08A461E

• Connection Manager konfigurieren und starten

Im Prinzip kann die Client Installation auch gleich einer Basis Oracle Installation durchgeführt werden, siehe ⇒ Eine Oracle Linux 8 Umgebung für eine Oracle Installation vorbereiten.

Oracle User auf dem System anlegen und Oracle Base Verzeichnis anlegen.

Als User root das Oracle Basisverzeichnis anlegen:

mkdir -p /opt/oracle
mkdir -p /opt/oracle/install
chown -R oracle:oinstall /opt/oracle
 
mkdir -p /opt/oraInventory
chown oracle:oinstall /opt/oraInventory/
 
dnf install gcc ksh sysstat libnsl

Client Zip nach /opt/oracle/install kopieren und prüfen:

sha256sum  LINUX.X64_213000_client.zip
595d8b59901c68979e2ff065210916857d0c17e64b07ef0180b92c4c3519249f  LINUX.X64_213000_client.zip

Als Oracle User anmelden:

mkdir -p /opt/oracle/product/21c/client_1
 
cd /opt/oracle/install
unzip LINUX.X64_213000_client.zip

Setup ausführen:

cd ./client
 
./runInstaller

Ablauf:

1. Select Installation Type ⇒ Custom
2. Specify Installation Location ⇒ Oracle Base = „/opt/oracle“ ; Oracle Home = „/opt/oracle/product/21c/client_1 > Next
3. Create Inventory ⇒ Inventory Directory “/opt/oraInventory„ ⇒ Next
4. Komponenten auswählen:
   1. SQL*Plus
   2. Oracle Connection Manager
   3. Oracle Net
   4. Oracle Listner
   5. Oracle Advanced Security
5. Perform Prerequisite Check ⇒ Bei Problem fixen ⇒ Next
6. Summary ⇒ Übersicht ⇒ „Save Response File“ ⇒ Install
7. Install Product ⇒ Details über den Lauf über „Details“
   1. Root Script ausführen als root

      /opt/oraInventory/orainstRoot.sh 
      /opt/oracle/product/21c/client_1/root.sh

8. Finish ⇒ close

Umgebung des Users einrichten:

vi .bashrc
 
export ORACLE_BASE=/opt/oracle
export ADR_BASE=${ORACLE_BASE}
export ORACLE_HOME=/opt/oracle/product/21c/client_1
 
export PATH=$ORACLE_HOME/bin:$PATH
 
. .bashrc

Nach der Installation des Clients auch gleich den letzten Patch einspielen.

Als User Oracle:

mkdir /opt/oracle/install/patch

Dateien nach /opt/oracle/install/patch kopieren.

Im ersten Schritt OPatch updaten ( OPatch 12.2.0.1.30 for DB 21.0.0.0.0 (Apr 2022) )

cd  /opt/oracle/install/patch
 
mv /opt/oracle/product/21c/client_1/OPatch /opt/oracle/product/21c/client_1/OPatch_06_2022
 
unzip p6880880_210000_Linux-x86-64.zip -d /opt/oracle/product/21c/client_1
 
 
/opt/oracle/product/21c/client_1/OPatch/opatch version 
 
 OPatch Version: 12.2.0.1.30
 OPatch succeeded.

Dann Patch einspielen:

unzip p33843745_210000_Linux-x86-64.zip
 
cd 33843745
 
export ORACLE_HOME=/opt/oracle/product/21c/client_1/
 
/opt/oracle/product/21c/client_1/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -ph ./
..
Prereq "checkConflictAgainstOHWithDetail" passed.
 
OPatch succeeded
..
#wenn alles ok
 
/opt/oracle/product/21c/client_1/OPatch/opatch apply

Exception in thread „main“ java.lang.NoClassDefFoundError: Could not initialize class oracle.sysman.oii.oiip.oiipg.OiipgPropertyLoader

Preparing to launch Oracle Universal Installer from /tmp/OraInstall2023-09-20_11-07-18PM. Please wait ...
 
 The java.library.path system variable is missing or invalid. Please set java.library.path with a correct value and retry the operation.
 
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class oracle.sysman.oii.oiip.oiipg.OiipgPropertyLoader
	at oracle.sysman.oii.oiip.oiipg.OiipgBootstrap.isCleanMachine(OiipgBootstrap.java:487)
 

Lösung:

dnf install libnsl.x86_64

User Oracle

Die Konfiguration erfolgt über die Datei $ORACLE_HOME/network/admin/cman.ora.

Erste Start Konfiguration erstellen:

cman_gpi =
(configuration=
    (address=(protocol=tcp)(host=cman21c.pipperr.local)(port=1999))
    (parameter_list =
        (aso_authentication_filter=off)
        (connection_statistics=yes)
        (log_level=admin)
        (max_connections=256)
        (idle_timeout=0)
        (inbound_connect_timeout=10)
        (session_timeout=0)
        (outbound_connect_timeout=0)
        (max_gateway_processes=16)
        (min_gateway_processes=2)
        (remote_admin=on)
        (trace_level=off)
        (trace_timestamp=off)
        (trace_filelen=1000)
        (trace_fileno=1)
        (max_cmctl_sessions=4)
        (event_group=init_and_term,memory_ops)
        (VALID_NODE_CHECKING_REGISTRATION=OFF)
        (REGISTRATION_INVITED_NODES = 10.10.10.*)
        (USE_SERVICE_AS_TNSNAMES_ALIAS=ON)
        (USE_SID_AS_SERVICE=ON)
    )
    (rule_list=
        (rule=
            (src=*)(dst=*)(srv=*)(act=accept)
            (action_list=(aut=off)(moct=0)(mct=0)(mit=0)(conn_stats=on))
        )
        (
          rule=
            (src=cman21c)(dst=127.0.0.1)(srv=cmon)(act=accept)
        )
        (
          rule=
            (src=cman21c)(dst=*)(srv=cmon)(act=accept)
        )
        (rule=
              (src=10.10.10.1)(dst=*)(srv=GPI)(act=accept))
        )
   )
)

siehe auch siehe Support Node - Doc ID 733421.1

Das administrative Utility ist das Programm cmctl. Nach dem Start des cmctl muss sich mit dem „administer <cman_name>“ an den Connection Manager angemeldet werden.

Start:

cd $ORACLE_HOME/bin
 
./cmctl
 
 
CMCTL> administer cman_gpi
 
Current instance cman_gpi is not yet started
Connections refer to (DESCRIPTION=(address=(protocol=tcp)(host=cman21c.pipperr.local)(port=1999))).
The command completed successfully.
 
 
CMCTL:cman_gpi> startup
 
Starting Oracle Connection Manager instance cman_gpi. Please wait...
CMAN for Linux: Version 21.0.0.0.0 - Production
Status of the Instance
----------------------
Instance name             cman_gpi
Version                   CMAN for Linux: Version 21.0.0.0.0 - Production
Start date                07-JUN-2022 13:58:50
Uptime                    0 days 0 hr. 0 min. 9 sec
Num of gateways started   2
Average Load level        0
Log Level                 ADMIN
Trace Level               OFF
Instance Config file      /opt/oracle/product/21c/client_1/network/admin/cman.ora
Instance Log directory    /opt/oracle/diag/netcman/cman21c/cman_gpi/alert
Instance Trace directory  /opt/oracle/diag/netcman/cman21c/cman_gpi/trace
The command completed successfully.
 
# Parameter anzeigen
CMCTL:cman_gpi>show all
 
listener_address            | (DESCRIPTION=(address=(protocol=tcp)(host=cman21c.pipperr.local)(port=1999)))
 
...
 
Number of filtering rules currently in effect: ..
 
...

Nach dem Start kann das Logfile unter $ORACLE_BASE/diag/netcman/cman21c/cman_gpi/trace eingesehen werden.

Über die PS Liste kann auch geprüft werden ob alle Connection Manager Prozesse auch laufen:

$ ps uafx | grep cm
 
../opt/oracle/product/21c/client_2/bin/cmadmin cman_gpi -inherit
.. /opt/oracle/product/21c/client_2/bin/tnslsnr ifile=/opt/oracle/product/21c/client_2/network/admin/cman.ora cman_gpi -inherit -mode proxy
.. /opt/oracle/product/21c/client_2/bin/cmgw cmgw0 0 16 cman_gpi SNLSM:e6e08000 0
.. /opt/oracle/product/21c/client_2/bin/cmgw cmgw1 1 16 cman_gpi SNLSM:e6e08000 0

Mit der obigen Start cman.ora arbeitet der Connection Manager ohne Einschränkungen.

Erster Test mit folgenden tnsnames.ora Eintrag:

cman_gpi_db=
  (DESCRIPTION = 
    (SOURCE_ROUTE = YES)
    (ADDRESS = 
      (PROTOCOL = TCP)(HOST = 10.10.10.96 )(PORT = 1999)
    )
    (ADDRESS = 
      (PROTOCOL = TCP)(HOST = 10.10.10.1 )(PORT = 1521)
    )
    (CONNECT_DATA = 
      (SERVICE_NAME=GPI)
    )
  )

Der Schlüssel zu diesem Eintrag ist der Parameter SOURCE_ROUTE, die Verbindung erfolgt zuerst an den CMan, der weiß dann über den zweiten ADRESS Eintrag wo hin die Verbindung geleitet werden soll.

In der einfachen Basis Konfiguration darf jeder sich mit dem Connection Manager verbinden und wird je nach tnsnames Eintrag einfach weitergeleitet.

Nach folgenden Muster können die Regeln eingestellt werden:

(RULE_LIST=
  (RULE=
    (SRC=host)
    (DST=host)
    (SRV=service_name)
    (ACT={accept|reject|drop})
    (ACTION_LIST=AUT={on|off}
    ((CONN_STATS={yes|no})(MCT=time)(MIT=time)(MOCT=time)))
  (RULE= ...))

ACTION_LIST: The rule-level parameter settings for some parameters.

Parameter:

• AUT: Oracle Database security authentication on client side.
• CONN_STATS: Log input and output statistics.
• MCT: Maximum connect time.
• MIT: Maximum idle timeout.
• MOCT: Maximum outbound connect time.

siehe auch http://docs.oracle.com/cd/E16655_01/network.121/e17611/cman.htm#NETRF337

Wenn die Default Rule angepasst wird, muss die lokale Regel für den Connection des cmctl auf den Connction Manager hinterlegt werden

(rule_list=
   (rule=
    (src=cman21c.pipperr.local)
    (dst=127.0.0.1)
    (srv=cmon)
    (act=accept)
  )
)

Beispiel:

(RULE_LIST=
        (RULE=(SRC=10.10.10.0/8) 
              (DST=10.10.10.1) 
              (SRV=GPI_DATA) 
              (ACT=accept)
        )
 )

Das Password kann nicht direkt in der „cman.ora“ hinterlegt werden, sondern wird im „cmctl“ Utiltiy gesetzt und dann verschlüsselt in der „cman.ora“ gespeichert.

cmctl
 
CMCTL> administer cman_gpi
 
CMCTL:cman_gpi> startup
 
..
TNS-04077: WARNING: No password set for the Oracle Connection Manager instance.
..
 
CMCTL:cman_gpi> set password
 
Enter Old password:
Enter New password:
Reenter New password:
The command completed successfully.
CMCTL:cman_gpi> save_passwd
The command completed successfully.
 
# Was wird erzeugt
cat cman.ora
 
#----ADDED BY CMAN 18-MAY-2015 09:29:34---
password_cman_gpi = 10D34223DA9F8D28
#-

Beim nächsten Anmelden wird nach dem Passwort gefragt

Um das ganze zu optimieren, drei User Oracle Sessions auf dem CMAN Host starten So lassen sich die Regel dann nach und nach härten und es ist schnell klar wenn es nicht so passt wie gewünscht.

Hier die Konfig bearbeiten

vi $ORACLE_HOME/network/admin/cman.ora

Hier den Log es CMAN im Tail starten

adrci
 
adrci> show homes
ADR Homes:
diag/netcman/cman21c/cman_gpi
diag/tnslsnr/cman21c/listener
 
adrci> set home diag/netcman/cman21c/cman_gpi
 
adrci> show alert -tail -f
 
...
07-JUN-2022 18:13:24 * service_update * cman * 0
..
usw.

cmctl
 
CMCTL> administer cman_gpi
 
#Registierung anzeigen
show service
#Config anzeogen
show all
show parameters
#stop
shutdown
#start
startup

Normalerweise könnten man erwarten das ein „reload“ Befehl genügt um die Konfig neu zu laden, aber nicht immer klappt das auch, besser stoppen und dann neu starten.

Je nach Aufgaben noch eine Session z.B. auf dem DB Host starten:

Von einer Datenbank kann die Registrierung am CMAN anstoßen werden mit:

-- einmal den Parameter setzen
ALTER system SET remote_listener='(ADDRESS=(PROTOCOL=tcp)(HOST=10.10.10.96)(PORT = 1999))' scope=memory;
-- bei Änderungen am CMAN erneut registieren
ALTER system register;

Treten Probleme wie verzögerter Connect auf, in einer root Session z.B. mit „tcpdump“ den Verbindungsaufbau mit „schneiden“

Als root user:

dnf install tcpdump
 
 
--
 tcpdump -i ens160 -nn -s0 -A  -v port 1999

Ab einer 19x Version ist zu beachten das wenn auf dem Windows DB Host in der sqlnet.ora der Parameter SQLNET.AUTHENTICATION_SERVICES NTS enthält, und von der Maschine über den CMAN wieder ein Connect auf die selbe Maschine durchgeführt wird es zu einem „ORA-12631: Username retrieval failed“ kommt!

Mit der Härtung des SQL*Net Protokolls (19.8 ??) wurde für NTS Autorisierung (Windows Authentifzierung mit / as sysdba über DBA Gruppe) diese Verhalten expliziert eingeführt!

Durch den weiteren SQL*Net Parameter „SQLNET.NO_NTLM=FALSE“ lässt sich diese Sicherheits-Feature wieder auf das alten Verhalten setzen!.

Im einfachsten Fall erstmal den SQLNET.AUTHENTICATION_SERVICES erstmal für den Testcase auskommentieren oder „SQLNET.NO_NTLM=FALSE“ setzen.

Siehe auch den Kerberos Artikel zu dem Thema ⇒ Kerberos für die Authentifizierung eines AD Users in der Oracle DB verwenden - Einsatz der DB Proxy User Architektur

In einer EXADATA Umgebung tritt das folgende Verhalten auf, von selben Client ist der direkte Connect über den Scan Listner der DB Umgebung schnell, beim Zugriff über den CMan mit dem selben User auf den gleichen Service / Scan Listener ist der Zugriff um ca. 10s verzögert.

Da hier immer die 10s auftauchen, ist der Verdacht das eine Namesaufläsung hier nicht so will wie es soll, siehe Support Node dazu , „Sqlnet Connection via TCP Hangs For About 10 Seconds Before Connection is Established(1071330.1)“

Test Connect Zeit mit

 time echo exit | sqlplus  gpi/xxxx@gpi_db_cman

Um das Problem einzugrenzen auf dem CMAN Server und dem Client das SQLNET Tracing aktiveren und das DNS Protokoll mit Tcpdump parallel auf dem Client und den CMAN beobachten.

Test auf CMan ob hier DNS Abfragen parallel beim Aufruf des Connects erfolgen. als root mit:

  tcpdump -i ens160 -nn -s0 -A  -v port 53

Nach dem Deaktivieren des FAN Listener Feature für SQL*Plus auf dem Klient, verbessert sich das Verhalten

Datei /opt/oracle/product/21c/client_1/network/admin/oraaccess.xml erstellen:

  <?xml version="1.0" encoding="ASCII" ?>
  <oraaccess xmlns=http://xmlns.oracle.com/oci/oraaccess xmlns:oci=http://xmlns.oracle.com/oci/oraaccess schemaLocation="http://xmlns.oracle.com/oci/oraaccess
  http://xmlns.oracle.com/oci/oraaccess.xsd">
  <default_parameters>
    <events>false</events>
  </default_parameters>
  </oraaccess>

Siehe dazu ⇒ Disable FAN events Doc ID 2179568.1

Registierung auf dem ONS auf dem RAC Server prüfen mit: User grid

# Debug ausgabe nur auf die Client Anmeldungen begrenzen
onsctl debug comp=ons[client]

Zu ONS siehe: Support:

• The ONS Daemon Explained In Oracle Clusterware/RAC Environment (Doc ID 759895.1)

Web:

• https://westzq1.github.io/oracle/2019/02/04/Application-Failover-1.html
• https://www.oracle.com/technetwork/database/options/clustering/applicationcontinuity/learnmore/fastapplicationnotification12c-2538999.pdf
• https://docs.oracle.com/en/database/oracle/oracle-database/18/jjdbc/Oracle-RAC-FAN-API.html
• https://github.com/oracle/python-cx_Oracle/issues/622
• http://db.geeksinsight.com/wp-content/uploads/2012/12/jdbc_fcf_quickstart.pdf
• https://blog.dba.bg/index.php/kkovachki/oracle_18c/oracle-12c-18c-oracle-grid-infrastructure-ons-setup-and-debug-from-local-and-remote-side

Die Parametrisierung der symmetrischen SQL*Net Protokol Verschlüsselung ( siehe ⇒ Das SQL*Net Protokoll mit einer symmetrischen Verschlüsselung wie DES / AES oder RC4 schützen findet nur auf dem Client und auf dem Server statt!

Auf dem CMAN muss dazu nichts konfiguriert werden!

siehe auch Dokument ⇒ „ORA-12564 when using native encryption settings in sqlnet.ora on CMAN server (Doc ID 1538702.1)“

Nur noch die Verbindung an den Datenbank Listener über den Connection Manager zulassen:

sqlnet.ora des Oracle DB Listeners anpassen:

#Prüfung aktivieren
TCP.VALIDNODE_CHECKING=YES

#Nur noch diese Liste von Hosts zulassen
TCP.INVITED_NODES=(10.10.10.96)

–

CMCTL:cman1> startup
TNS-04012: Unable to start Oracle Connection Manager instance.

Der TNS-04012 sagt leider wenig aus, in meine Fall war die cman.ora fehlerhaft!

Oracle Support:

• 733421.1 Troubleshooting Guide: TNS-04012: Unable to Start Oracle Connection Manager Instance

Nach dem Start des Connection Manager kann mit cmctl die Verwaltung nicht mehr durchgeführt werden.

Fehler:

CMCTL> administer cman_gpi
Current instance cman_pb is not yet started
Connections refer to (address=(protocol=tcp)(host=oradb12c01.pipperr.local)(port=1999)).
The command completed successfully.
 
CMCTL:cman_pb> show all
TNS-04011: Oracle Connection Manager instance not yet started.

Lösung:

In meiner Umgebung war die Rule bzgl. Connect auf sich selbst fehlerhaft. Wird mit Rules gearbeitet, muss eine Regel aufgenommen werden, das der locale Client mit dem Connection Manager Admin Prozess kommunizieren darf.

Regel:

(rule=(src=cman21c.pipperr.local)(dst=127.0.0.1)(srv=cmon)(act=accept))
(rule=(src=cman21c.pipperr.local)(dst=*)(srv=cmon)(act=accept))

??Warum reicht nicht nur die localhost rule?? Sehr seltsam …..

Wenn der Client nur über einen Service anfragen kann kann auch ein statisches Routing definiert werden.

Dazu stehen die Parameter USE_SID_AS_SERVICE und USE_SERVICE_AS_TNSNAMES_ALIAS zur Verfügung.

Das ist besonders in unseren Standby DB Scenario jetzt sehr hilfreich.

In der cman.ora:

Parameter:

..
   (USE_SERVICE_AS_TNSNAMES_ALIAS=ON)
   (USE_SID_AS_SERVICE=ON)
..

in der tnsnames.ora

SRV_IMPORT=
  (DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.1)(port=1521))
   (CONNECT_DATA=
      (SERVICE_NAMES=SRV_IMPORT)
   )
)

!DESCRIPTION_LIST is not supported in the tnsnames.ora file of CMAN home!

Alternativ für eine Standby Umgebung, Adressliste angeben mit alternativen Listenern der Standby Umgebungen:

SRV_IMPORT=
  (DESCRIPTION=
  (FAILOVER=on)
  (CONNECT_TIMEOUT=1)
  (RETRY_COUNT=3)
  (ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.1)(port=1521))
  (ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.190)(port=1521))
   (CONNECT_DATA=
      (SERVICE_NAME=SRV_IMPORT)
   )
)

Das funktioniert aber nur mit den obigen Connect Timeout und Retry Count Parametern! Bei höheren Timeouts erfolgt ein „ORA-12537: TNS:connection closed“ bis der CMAN den richtigen Listener gefunden hat!

in der tnsnames.ora

CMAN_GPI_ROUTING =
  (DESCRIPTION =
    (ADDRESS = 
    (CONNECT_TIMEOUT=1)
    (RETRY_COUNT=3)
    (PROTOCOL = TCP)(HOST = 10.10.10.96)(PORT = 1999))
    (CONNECT_DATA =
      (SERVICE_NAME = SRV_IMPORT)
    )
  )  
CMAN_GPI_ROUTING_SID =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 10.10.10.96)(PORT = 1999))
    (CONNECT_DATA =
      (SID = SRV_IMPORT)
    )
  )     

Das funktioniert auch mit der JDBC Syntax "host:port//service" bzw „host:port:SID“, das heißt so können auch Java Clients umgeleitet werden die keine TNSNAMES.ora „vertragen“.

Über den Remote Listener Parameter kann eine Datenbank sich auch an einem entfernten Listener registrieren.

Diese Feature konnte in der Vergangenheit auch missbraucht werden und ist daher per Default deaktiviert ( cman Parameter (VALID_NODE_CHECKING_REGISTRATION=ON | OFF)!

Um es ohne jede weiter Prüfung wieder zu aktiveren muss der Parameter auf ON stehen.

Problem: Listener(VNCR option 1) rejected Registration request from destination

adrci> show alert
 
..
2: diag/netcman/cman21c/cman_gpi
..
Please select option: 2
 
 
Listener(VNCR option 1) rejected Registration request from destination 10.10.10.1
07-JUN-2022 17:50:28 * service_register_NSGR * 1182

Hier fehlt uns noch eine Berechtigung wie VALID_NODE_CHECKING_REGISTRATION=ON um die Registrierung zu erlauben.

Damit aber der CMAN nicht wieder missbräuchlich verwendet wird, sollte die IP Adresse eingeschränkt werden mit dem Parameter ( REGISTRATION_INVITED_NODES = 10.10.10.*) nur auf die DB's die es auch dürfen sollen, mit ( REGISTRATION_EXCLUDED_NODES = 192.*) auf die Hosts die ausgeschlossen werden sollen.

Siehe auch:

• Valid Node Checking for Registration parameter in Connection Manager ( VNCR in CMAN ) (Doc ID 2259948.1)

In der Single Target DB anmelden und Remote Listener testweise setzen

ALTER system SET remote_listener='(ADDRESS=(PROTOCOL=tcp)(HOST=10.10.10.96)(PORT = 1999))' scope=memory;
-- neu anmelden mit:
ALTER system register;

Wenn es funktioniert mit scope=both aus persistent setzen!

In einer Oracle RAC Cluster Konfiguration mit Scan Listener muss ein TNS Eintrag für den Remote Listener Parameter erstellt werden, in dem alle Scan Listener IP Adressen UND der Oracle Connection Manager aufgeführt ist.

Siehe auch Doc ID 1375897.1

 
 
SELECT TYPE, VALUE FROM v$listener_network WHERE TYPE='REMOTE LISTENER';
 
TYPE
----------------------------------------------------------------
VALUE
----------------------------------------------------------------------------------------------------------------------------------
REMOTE LISTENER
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.200)(PORT=1521)))
 
REMOTE LISTENER
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.210)(PORT=1521)))
 
REMOTE LISTENER
(DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.220)(PORT=1521)))
 
 
SYS@GPIDB1-racdb01>SHOW parameter remote_listener
 
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
remote_listener                      string      rac01cluster.pipperr.local:152
                                                 1
 
-- umstellen auf TNS Alias!

REMOTE_LIST =
   (DESCRIPTION =
     (ADDRESS_LIST=
       (ADDRESS=(PROTOCOL = TCP)(HOST = 10.10.10.220)(PORT = 1521))
       (ADDRESS=(PROTOCOL = TCP)(HOST = 10.10.10.210)(PORT = 1521))
       (ADDRESS=(PROTOCOL = TCP)(HOST = 10.10.10.200)(PORT = 1521))
       (ADDRESS=(PROTOCOL = TCP)(HOST = 10.10.10.96 )(PORT = 1999))
     )
    )

ALTER system SET remote_listener=REMOTE_LIST scope=memory sid='*';
 
SYS@GPIDB1-racdb01>SELECT TYPE, VALUE FROM v$listener_network WHERE TYPE='REMOTE LISTENER';
 
TYPE
----------------------------------------------------------------
VALUE
----------------------------------------------------------------------------------------------------------------------------------
REMOTE LISTENER
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.200)(PORT=1521)))
 
REMOTE LISTENER
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.210)(PORT=1521)))
 
REMOTE LISTENER
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.220)(PORT=1521)))
 
REMOTE LISTENER
(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.10.10.96)(PORT=1999)))

Im Cman Log:

2022-06-07 22:37:47.888000 +02:00
Dynamic address is already listened on (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=cman21c.pipperr.local)(PORT=1999)))
07-JUN-2022 22:37:47 * (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.10.190)(PORT=31363)) * service_register * GPIDB1 * 0
Dynamic address is already listened on (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=cman21c.pipperr.local)(PORT=1999)))
07-JUN-2022 22:37:47 * (ADDRESS=(PROTOCOL=tcp)(HOST=10.10.10.194)(PORT=15514)) * service_register * GPIDB2 * 0

! der zu der DB Maschine sich verbinden soll !

cman_gpi_db=
  (DESCRIPTION = 
   (ADDRESS = 
      (PROTOCOL = TCP)(HOST=cman21c.pipperr.local)(PORT = 1999)
    )    
    (CONNECT_DATA = 
      (SERVICE_NAME=GPI)
    )
  )

Test mit tnsping und sqlplus.

Siehe dazu auch:

• Force Connections to a Specific Database Service When two Identical Services are Registered to CMAN (Doc ID 1455068.1) - wird über eine Rule abgewickelt

TestCase:

• Auf CMAN Host für den 1999 Port das Mitschneiden des SQL*Net Protokolls einschalten

   tcpdump -i ens160 -nn -s0 -A  -v port 1999

• Auf dem Client PC mit SQL*Plus an der DB Anmelden und z.B. ein Passwort ändern

  ALTER USER xxxx IDENTIFIED BY hugo;

• Im Trace nach dem „alter user“ suchen

  ..
  10:58:02.471303 IP (tos 0x0, ttl 128, id 9835, offset 0, flags [DF], proto TCP (6), length 439)
      10.10.10.1.63187 > 10.10.10.96.1999: Flags [P.], cksum 0x30d3 (correct), seq 3852:4251, ack 2441, win 4104, length 399
  E...&k@....a
  ................."alter user xxxx identified by hugo.........
  10:58:02.477553 IP (tos 0x0, ttl 64, id 12805, offset 0, flags [DF], proto TCP (6), length 51)
  ..

  Und siehe das da ist auch das Passwort!

Als User „oracle“ folgende Datei in /opt/oracle/scripts/start_connection_manager.sh anlegen.

start_connection_manager.sh

#!/bin/bash
#
 
ORACLE_USER=oracle
ORACLE_HOME=/opt/oracle/product/21c/client_1
ORACLE_CMAN_NAME=cman_gpi_db
 
#Start or stop the Oracle CMan Node
case "$1" in
    start)
        # Oracle Connection Manager start
        echo -n "Starting Oracle Connection Manager: "
        export ORACLE_HOME=$ORACLE_HOME; $ORACLE_HOME/bin/cmctl << EOScipt
administer ${ORACLE_CMAN_NAME}
startup
exit
EOScipt
        echo "OK"
        ;;
    stop)
        # Oracle Oracle Connection Manager shutdown
        echo -n "Shutdown Oracle Connection Manager: "
        export ORACLE_HOME=$ORACLE_HOME; $ORACLE_HOME/bin/cmctl << EOScipt
administer ${ORACLE_CMAN_NAME}
shutdown
exit
EOScipt
        echo "OK"
        ;;
    status)
        # status
        echo -n "Status Oracle Connection Manager: "
        export ORACLE_HOME=$ORACLE_HOME; $ORACLE_HOME/bin/cmctl << EOScipt
administer ${ORACLE_CMAN_NAME}
show all
exit
EOScipt
        ;;	    
    reload|restart)
        $0 stop
        $0 start
        ;;
    *)
        echo "Usage: $0 start|stop|restart|reload|status"
        exit 1
esac
exit 0

Start/stop Scripts anlegen als user oracle

vi /opt/oracle/scripts/startcman.sh
#!/bin/sh
/opt/oracle/scripts/start_connection_manager.sh start >> /opt/oracle/scripts/startup.log 2>&1
 
 
vi /opt/oracle/scripts/stopcman.sh
#!/bin/sh
/opt/oracle/scripts/start_connection_manager.sh stop >> /opt/oracle/scripts/shutdown.log 2>&1
 
chmod 777 stopcman.sh
 
chmod 777 startcman.sh
 
chmod 777 start_connection_manager.sh
 
#Scripte als oracle User testen!

User root

Datei “/lib/systemd/system/cman.service„ anlegen:

[Unit]
Description=The Oracle CMAN Service
After=syslog.target network.target
 
[Service]
Type=simple
RemainAfterExit=yes
User=oracle
Group=oinstall
ExecStart=/opt/oracle/scripts/startcman.sh 
ExecStop=/opt/oracle/scripts/stopcman.sh
 
[Install]
WantedBy=multi-user.target

Link anlegen:

ln -s /lib/systemd/system/cman.service /etc/systemd/system/cman.service

Reload systemd

systemctl daemon-reload

Starten und einschalten des Service:

#Starten
systemctl start cman.service
 
#Auto Start aktivieren
systemctl enable cman.service
 
#Status prüfen
 
systemctl status cman.service -l
 
 
#Stoppen
 
systemctl stop cman.service
 
#prüfen ob die Start Reichenfolge auch passt:
 
systemd-analyze critical-chain cman.service

Support

• A Guide to CMAN Configuration for 10g and Newer Releases (Doc ID 298916.1)
• Integrating Connection Manager (CMAN) into a RAC+SCAN Environment (Doc ID 1556300.1)
• ORA-12564 when using native encryption settings in sqlnet.ora on CMAN server (Doc ID 1538702.1)
• ORA-12631 While Connecting To The Database (Doc ID 986865.1)
• How to configure Connection Manager (CMAN) with Transparent Application Failover (TAF)? (Doc ID 397021.1)
• Troubleshooting Connection Manager (CMAN) (Doc ID 579660.1)

Overview

• https://docs.oracle.com/en/database/oracle/oracle-database/21/netag/configuring-oracle-connection-manager.html

CMAN Parameter

• https://docs.oracle.com/en/database/oracle/oracle-database/21/netrf/oracle-connection-manager-parameters.html

• https://www.dbarj.com.br/en/2018/01/implementing-oracle-connection-manager-high-availability/
• https://www.thegeekdiary.com/how-to-configure-client-connectivity-in-oracle-data-guard-configuration-implement-failover-procedures/
• https://frankdba.wordpress.com/2014/09/26/service-failover-with-dataguard-and-connection-manager/
• https://database-heartbeat.com/2021/02/02/oracle-connection-manager-cman-install-configure-and-connect-to-dbcs-and-autonomous-databases/