Stanno avendo una sempre maggior diffusione connessioni a "bassa" velocita' verso l'RDBMS Oracle (connessioni su seriale, in WAN, su linee ISDN, ..). In alcuni casi possono presentarsi problemi dovuti alla lentezza del mezzo trasmissivo.

Per accessi di questo tipo e' necessario un'attenta analisi dell'architettura, sono tuttavia configurabili alcuni parametri che possono migliorare la comunicazione.

L'architettura dell'applicazione deve essere studiata con attenzione.

Una tipica applicazione Client/Server con Oracle utilizza infatti pensantemente la connessione di rete presente. Per ogni statement SQL vengono infatti inviati parecchi messaggi (corrispondenti alle varie fasi di trattamento degli statement SQL: PREPARE, EXECUTE, FETCH, ...). Inoltre alcune sessioni di scambio dati possono richiedere pesanti trasferimenti.

E' pertanto importante conoscere sia la capacita' del canale trasmissivo che la latenza dello stesso.

L'utilizzo di Stored Procedures migliora notevolmente, in particolare dal punto di vista di numero di messaggi scambiati, il traffico di rete.

Hanno invece pesanti impatti sulla rete le funzioni di database distribuito con il TWO PHASE COMMIT.

Il traffico (ed in particolare il tipo di traffico) generato dalle due versioni di SQL*Net e' differente (eg. piu' describe di colonne su un singolo buffer, OOB, ..).

E' pertanto consigliato passare a v.2 su configurazioni di questo tipo (e' consigliabile comunque poiche' il supporto a v.1 avra' termine).

Nella stringa di connessione v.1 e' possibile specificare la dimensione del buffer utilizzato. Con basse velocita' puo' convenire variarne la dimensione (in diminuzione).

Possono essere modificati alcuni parametri:

• STARTUP_WAIT_TIME_listener_name che specifica il tempo di ritardo che il listener pone prima di rispondere ad una richiesta di stato.
• CONNECT_TIMEOUT_listener_name che specifica il numero di secondi che il listener attende la richiesta di connessione dopo che la connessione e' stata attivata.

Possono essere modificati i seguenti parametri:

• SQLNET.EXPIRE_TIME che specifica l'intervallo di tempo tra i probe della linea per controllarne l'eventuale caduta. Un intervallo di tempo troppo breve induce un carico di rete troppo elevato. Un valore pari a 10 o 20 (minuti) e' adatto alla maggioranza dei casi.

Debbono essere controllati con attenzione i vari parametri di configurazione del software TCP-IP. Purtroppo tale configurazione dipende dal software installato (e su PC le scelte sono parecchie) e quindi non possono essere fornite indicazioni specifiche.

Una particolare attenzione deve essere rivolta nell'utilizzo del DNS per la risoluzione degli indirizzi. Infatti la risoluzione di un indirizzo con il DNS puo' richiedere parecchio tempo (e far scattare timeout) rallentando gli accessi o bloccandoli.

Debbono essere inoltre scelti con attenzione i tipi di logging e di tracing attivi.

Su linee seriali possono essere utilizzati i protocolli SLIP e PPP; il protocollo PPP e' piu' efficiente ed e' quindi consigliato per tale motivo (oltre che per le ulteriori funzionalita' di autentificazione e sicurezza).