Configurazione di SQL*Net v.2

Oracle SQL*Net v.2, introdotta a partire dalla versione 7.0 di Oracle, fornisce nuove funzionalita' rispetto alla versione precedente e presenta una architettura e configurazione differente.

In questo breve documento ne vengono descritte le principali modalita' di utilizzo e configurazione.

Funzionalita' fornite

SQL*Net V.2 fornisce tutte le funzionalita' di SQL*Net V.1, tra queste:

• distribuite processing: una applicazione Oracle puo' operare su una piattaforma accedendo ad una base dati attiva su un altro sistema
• distribuite database (in sola lettura): consente di utilizzare in maniera trasparente tabelle provenienti da diversi database
• DB gateway: e' possibile accedere con programmi e tool Oracle a database differenti ponendoli in connessione da Database di vendor differenti (eg. DB2 di IBM)

Sono inoltre presenti nuove interessanti funzionalita':

• distribuite database: consente di utilizzare in maniera trasparente tabelle provenienti da diversi database anche in scrittura con il supporto completo del two phase commit. Per l'utilizzo e' necessario installare il modulo Distribuite Database Option (DDO) che e' fornito con la versione Enterprise dell'RDBMS.
• multiprotocol interchange: consente di accedere in distribuite processing o distribuite database attraversando piu' reti con protocolli differenti.
• replicazione dati: sono presenti sofisticate modalita' di replicazione dati che vanno dagli snapshot (fotografie a tempo) alla possibilita' di replicazione asincrona di dati da piu' tabelle master.
• prestazioni: il protocollo v.2 e' stato ottimizzato diminuendo il numero di scambi necessari per l'esecuzione di statement SQL. In tal modo vengono avvantaggiate linee a bassa velocita' in cui la latenza e' elevata.
• sicurezza: con un'opzione separata e' possibile effettuare encryption e proteggere la comunicazione in maniera molto sofisticata.
• multithreaded server: con SQL*Net v.2 i server Oracle possono essere condivisi da piu' sessioni di applicazioni differenti.
• strumenti di management: Sono presenti nuovi pacchetti per la gestione dell'RDBMS e delle sue configurazioni in rete (eg. Enterprise manager, Network Manager, Replication Manager, ...)

L'utilizzo da parte di un utente/applicazione di SQL*Net V.2 e' molto semplice. E' infatti sufficiente specificare l'alias nella stringa di connessione.

Ad esempio:

$ sqlplus scott/tiger@sunset

In pratica rispetto alla versione precedente si utilizza semplicemente un nome logico rispetto all'indicazione di rete, indirizzo, SID, ..

Analogamente avviene per la definizione dei database link.

Ad esempio:

SQL> create database link sunset
  2  connect to scott identified by tiger
  3  using sunset;

Con l'utilizzo di database link e sinonimi e' possibile rendere completamente trasparente ad utenti/applicazioni la distribuzione dei dati.

Il passaggio da SQL*Net V.1 a SQL*Net V.2 e' fortemente consigliato.

Tra le diverse ragioni citiamo:

• e' l'unica supportata dalla versione 7.3 di Oracle e sucessive
• la nuova versione e' ormai stabile e risolve alcuni problemi presenti in tutte le versioni precedenti (eg. keepalive per trattare le cadute di linea)
• fornisce una serie di funzionalita' ulteriori alla versione precedente
• consente l'encryption dei dati (utilizzando l'opzione AdNO)

Il passaggio alla nuova versione richiede un'attenta pianificazione in particolare per quanto riguarda le configurazioni dei vari server/client.

Poiche' nella versione 7.2 di Oracle sono supportate, e possono operare contemporaneamente, le due versioni di SQL*Net e' possibile effettuare un passaggio graduale alla V2.

Non esiste una versione SQL*Net V.2 per MS-DOS (e' tuttavia disponibile nei diversi ambienti MS-Windows).

Per la configurazione sono disponibili diversi ambienti e strumenti forniti da Oracle che facilitano l'operativa (eg. SQL*Net Easy Configuration). In alcuni casi e per alcuni parametri e' comunque necessaria una modifica manuale dei file di configurazione.

L'utilizzo di tali strumenti non e' descritto in questo documento.

La configurazione sul client consente di definire la corrispondenza tra alias e servizi Oracle. Il file da configurare e' tnsnames.ora e' relativo a tutti i protocolli di rete e, generalmente, risiede in $ORACLE_HOME/network/admin.

Ad esempio:

#
# Filename: tnsnames.ora
# Modified by mail@meo.bogliolo.name on 1 Jan 1997
#
sunset = 
    (DESCRIPTION = 
        (ADDRESS_LIST = 
            (ADDRESS = 
                (COMMUNITY = company.com) 
                (PROTOCOL = TCP) 
                (Host = smile) 
                (Port = 1521) 
            ) 
        )
        (CONNECT_DATA = 
            (SID = demodb)
        )
    )

Nella configurazione d'esempio si fa riferimento ad un listener sulla macchina smile in ascolto sulla porta TCP-IP 1521. Nelle configurazioni tipiche vengono riportate tutte le possibili connessioni a database aziendali.

Il file TNSNAMES.ORA e' necessario anche sulle macchine tipicamente intese come server se da esse si vuole accedere all'esterno (eg. come nel caso di utilizzo DBLINK).
Se non si e' definita l'entry nel file tnsnames.ora e' anche possibile utilizzare l'indirizzo completo da linea di comando (ma naturalmente e' un po' scomodo):
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(Host=smile.company.com)(Port=1521)))(CONNECT_DATA=(SID=demodb)))

Su PC la configurazione e' molto semplice utilizzando il tool SQL*Net Easy Conf.

Una nota sulla nuova versione di SQL*Net Net80. Viene ora utilizzato il Global Database Name al posto del SID per indicare l'istanza cui connettersi. Connettendosi quindi ad un listener in v8 la sintassi e':

        (CONNECT_DATA = 
            (SERVICE_NAME = demodb)

La configurazione sul server richiede la definizione delle caratteristiche del listener. Il listener e' il programma che ascolta le richieste di connessione che provengono dalla rete ed attiva le risorse corrispondenti.

A differenza di SQL*Net v.1, il listener e' multiprotocollo e puo' ricevere quindi connessioni da sorgenti diverse (anche locali).

LISTENER=
    (ADDRESS_LIST=
        (ADDRESS=
            (PROTOCOL=ipc)
            (KEY=dbdemo)
        )
        (ADDRESS=
            (PROTOCOL=TCP)
            (HOST = sunset)
            (PORT = 1521)
        )
    )

SID_LIST_LISTENER=
    (SID_LIST=
        (SID_DESC=
            (SID_NAME=dbdemo)
            (ORACLE_HOME=/usr/oracle)
        )
    )

STARTUP_WAIT_TIME_LISTENER = 5
CONNECT_TIMEOUT_LISTENER = 60
TRACE_LEVEL_LISTENER = OFF
PASSWORD_LISTENER =

Sul listener vengono riportati gli estremi per le connessioni a tutte le istanze servite dal sistema.

Poiche' la porta socket viene esplicitamente indicata nelle configurazioni (sia client che server) non e' generalmente necessario configurare il file /etc/services.

Sono possibili diverse configurazioni particolari i cui elementi principali vengono riportati nel seguito.

In caso di configurazioni piu' complesse puo' essere necessario configurare anche i file TNSNAMES.ORA, TNSNAV.ORA, SQLNET.ORA, PROTOCOL.ORA ed INITX.ORA.

La configurazione in MTS (MultiThreaded Server) offre notevoli vantaggi prestazionali nel caso di numero elevato di utenti. Maggiori elementi si trovano descritti nello specifico documento Utilizzo di Oracle Multithreaded Server.

E' possibile creare un'entry nel file tnsnames.ora che effettua la connessione al RDBMS Oracle locale via PIPE. Tale connessione e' notevolmente efficiente (per gli accessi locali). Ad esempio:

sunsetb = 
    (DESCRIPTION = 
        (ADDRESS_LIST = 
            (ADDRESS = 
                (PROTOCOL = beq) 
                (PROGRAM = /usr/oracle/bin/oracle) 
                (ARGV0 = oracle_BEQ_sunset) 
                (ARGS = '(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))') 
            ) 
        )
        (CONNECT_DATA = 
            (SID = demodb)
        )
    )

E' possibile far operare una macchina come "gateway SQL*Net" di comunicazione tra due reti con protocolli differenti. In tal modo client su una rete possono operare su server attivi su reti con protocolli differenti oppure utilizzare meccanismi di proxing necessari per operare con firewall. Il nome del prodotto e' cambiato a seconda delle versioni di Oracle (Oracle Multiprotocol Interchange, Connection Manager) ma le caratteristiche e funzionalita' sono simili.

In questo caso la configurazione della macchina "gateway" avviene agendo sul file cman.ora.

E' possibile configurare in load balancing due, o piu', istanze Oracle. In tale configurazione si ha un solo listener che distribuisce richieste di accesso su piu' istanze (queste istanze possono essere diverse istanze di un Paralled DB, accessi a database in sola lettura o, anche, istanze aggiornate con la Advanced Replication). Per la configurazione e' possibile utilizzare la il MTS e fare riferimento allo stesso listener in entrambe le istanze.

E' possibile utilizzare piu' listener che servano la stessa istanza Oracle e fare in modo che i client accedano in load balancing sui diversi listener. Debbono essere attivati piu' listener (eventualmente su piattaforme differenti) ed il file TNSNAMES.ORA dei client deve far riferimento ad entrambi per lo stesso servizio. In questo caso e' possibile accedere alla stessa istanza mediante, ad esempio, protocolli di rete differenti.

E' infine possibile avere una relazione di molti a molti tra listener ed istanze. I casi in cui si effettuano tali configurazioni sono dovuti a situazioni realmente complesse e particolari o a paranoie di utenti/DBA.

LOG_DIRECTORY_CLIENT = /dev/null
LOG_FILE_CLIENT = /dev/null

rem File: AUTOEXEC.BAT
rem Oracle SQL*Net Password Encryption Forcing
set ORA_ENCRYPT_LOGIN=TRUE

Sintassi precedente (utilizza il SID):

sales= 
(description= 
  (address=(protocol=tcp)(host=sales-sun1)(port=1521))
  (connect_data=
     (sid=sales))


Sintassi Net 8 (utilizza il SERVICE_NAME):

sales= 
(description= 
  (address=(protocol=tcp)(host=sales-sun1)(port=1521))
  (connect_data=
     (service_name=sales.us.acme.com))

Puo' essere utile la seguente tabella:

	SQL*Net V1	SQL*Net V2	NetX
Default port	1525/tcp	1521/tcp	1521/tcp
Start command	tcpctl start	lsnrctl start	lsnrctl start
Stop command	tcpctl stop	lsnrctl stop	lsnrctl stop
Connect string	protocol:host:sid eg. T:SRV1:DB1	Specified in TNSNAMES.ORA	Specified in TNSNAMES.ORA
Config files	/etc/oratab	tnsnames.ora, sqlnet.ora & listener.ora	tnsnames.ora, sqlnet.ora & listener.ora
Env variable	LOCAL=	TWO_TASK=	TWO_TASK=

NetX utilizza protocolli di autenticazione che nel tempo sono cambiati e, in generale, non permette l'accesso al DB se la differenza di versioni tra client e server e' superiore a 2 restituendo l'errore ORA-28040 o ORA-3134.
E' tuttavia possibile aggirare tale limite agendo sulla variabile SQLNET.ALLOWED_LOGON_VERSION_SERVER. I valori possibili sono:

• 12a Oracle Database 12c authentication protocols (strongest protection)
• 12 critical patch updates CPUOct2012 e successivi a Oracle Database 11gauthentication protocols (default dalla versione Oracle 12.2)
• 11 Oracle Database 11g authentication protocols (default in Oracle 12.1)
• 10 Oracle Database 10g authentication protocols
• 8 Oracle9i authentication protocol

Argomenti distinti, ma che presentano aspetti architetturali di interesse, sono:

• Oracle JDBC Drivers
• Utilizzo dell'opzione di Parallel DB
• Utilizzo dell'opzione Parallel Query in Oracle v.7.X
• Applicazioni multithreaded in Oracle v.7.3