Se, per esempio, abbiamo un RAC da 3 nodi e volessimo che una nostra applicazione si collegasse solo ai nodi 2 e 3 del cluster, definiremmo un servizio che viene attivato solo sui nodi 2 e 3, in modo che le connessioni dirette al cluster vengano rimandate dai listener solo ai nodi su cui è attivo il servizio.
Ci sono molti altri parametri di configurazione di un servizio, tra cui le istanze verso le quali viene rediretto il servizio nel caso di indisponibilità dei nodi attivi, timeout vari e quant'altro.
È abbastanza interessante però che si possano definire i servizi anche per un database non RAC, composto da una sola istanza (esistono comunque anche i RAC single-instance).
I servizi, nel caso istanza singola, si possono creare e gestire con DBMS_SERVICE e le sue procedure CREATE_SERVICE e START_SERVICE.
CREATE_SERVICE prende come parametri il nome del servizio visto dal lato db e il nome visto dal lato listener, ovvero il famoso SERVICE_NAME all'interno dei connect descriptor dei client.
Ovviamente il connection load-balancing, e i vari metodi di failover non hanno senso, ma è possibile trarre qualche vantaggio da questa architettura.
Direi che i vantaggi possono essere un paio:
- Se creo un servizio e gli utenti di un certo gruppo/applicazione si collegano a quel servizio, posso fermarlo per manutenzione quando mi pare e impedirgli di connettersi, mentre il db rimane aperto e gli altri utenti continuano a lavorare senza problemi.
- Tramite la procedura DISCONNECT_SESSION posso disconnettere tutte e sole le sessioni collegate ad un determinato servizio con un solo comando, e a volte può essere veramente utile.
Nessun commento:
Posta un commento