Codice per disponibilità continua

Le tue applicazioni raggiungono una disponibilità continua quando la manutenzione pianificata, le interruzioni non pianificate e gli squilibri di carico del database sono nascosti dall'applicazione. Una combinazione di best practice applicative, configurazione semplice e Oracle Autonomous Database garantisce la disponibilità continua delle tue applicazioni.

L'approccio migliore per nascondere le attività di manutenzione pianificata dalle applicazioni è quello di svuotare il lavoro in modo trasparente da ogni posizione del carico di lavoro del database prima della finestra di manutenzione per tale posizione del carico di lavoro. I connection pool e i livelli medi di Oracle, inclusi il server WebLogic, Oracle Universal Connection Pool (UCP), il pool di sessioni OCI e il provider non gestito ODP.NET, sono a conoscenza della funzionalità FAN (Fast Application Notification) e pertanto ricevono una notifica prima che i servizi di database vengano pianificati per lo spostamento in modo da consentire un'interruzione normale del lavoro prima della manutenzione. La notifica FAN attiva automaticamente la chiusura delle connessioni inattive, l'apertura di nuove connessioni nella nuova posizione del servizio e consente un tempo configurabile per il completamento del lavoro attivo nella posizione del servizio di prossima chiusura. I principali mid-tiers JDBC di terze parti, come IBM WebSphere, consentono lo stesso funzionamento quando sono configurati con UCP. Per le applicazioni basate su JDBC che non possono utilizzare UCP, Oracle fornisce soluzioni utilizzando driver Oracle e test di connessione.

Per nascondere le indisponibilità non pianificate derivanti da un componente o da un errore di comunicazione, Oracle fornisce:

Notifica. Il FAN è il primo passo per nascondere le interruzioni. FAN invia una notifica ai client e li interrompe dall'attesa di rete corrente quando si verifica un'interruzione. Ciò evita lo stallo delle applicazioni per lunghe attese di rete. È importante sottolineare che FAN richiama anche il ribilanciamento delle sessioni quando i servizi sono nuovamente disponibili.
Recupero. Dopo che il client è stato avvisato, TAC (Transparent Application Continuity) o AC (Application Continuity) ristabiliscono una connessione a una nuova posizione del carico di lavoro (un'altra istanza del database nella configurazione RAC (Real Application Clusters) che esegue il database) e, se possibile, riproduce il lavoro in esecuzione (non impegnato). Ripetendo il lavoro in volo sulla nuova posizione, l'applicazione può in genere continuare l'esecuzione senza sapere che si è verificato un errore.

Il TAC o l'AC vengono eseguiti anche durante la manutenzione pianificata per le sessioni che non vengono eliminate (completare l'operazione corrente del database) durante l'intervallo di rimozione allocato.

Argomenti correlati

Elenco di controllo della configurazione dell'applicazione

L'applicazione viene resa continuamente disponibile seguendo le seguenti linee guida:

Connessione mediante i servizi di database
Configura stringa di connessione per High Availability
Utilizzare FAN (Fast Application Notification)
Usa procedure consigliate per consentire rimozione
Abilitare la continuità di applicazione trasparente (TAC, Transparent Application Continuity) o la continuità di applicazione (AC, Application Continuity)

Suggerimento

Consulta il white paper sulla disponibilità continua delle applicazioni su ATP-Direct per informazioni sulle best practice per l'implementazione della disponibilità continua per le applicazioni che utilizzano un Autonomous Database.

Connessione mediante i servizi di database

I servizi di database garantiscono trasparenza per l'infrastruttura sottostante: FAN, dati di connessione, TAC (Transparent Application Continuity), AC (Application Continuity), switchover, gruppi di consumatori e molte altre funzionalità e operazioni sono basate sull'uso dei servizi.

Autonomous Database on Dedicated Exadata Infrastructure offre diverse coppie di servizi di database predefiniti tra cui scegliere, come descritto in Nomi predefiniti dei servizi di database per i database autonomi. Tutti forniscono FAN e drenaggio e le due coppie di elaborazione delle transazioni hanno TAC abilitato per impostazione predefinita. È disponibile un'interfaccia API per modificare le impostazioni TAC o AC per tutti i servizi predefiniti (vedere Abilita attributi servizio per failover).

Configura stringa di connessione per High Availability

Oracle consiglia la configurazione della stringa di connessione mostrata di seguito durante la connessione a Oracle Autonomous Database. Le stringhe di connessione incorporate nel file tnsnames.ora fornito da Oracle vengono configurate in questo modo. Non utilizzare Easy Connect Naming sul client perché tali connessioni non dispongono di funzionalità ad alta disponibilità.

Utilizzare questo TNS per tutti i client Oracle versione 12.2 o successiva:

alias = 
(DESCRIPTION =
(CONNECT_TIMEOUT= 120)(RETRY_COUNT=20)(RETRY_DELAY=3)(TRANSPORT_CONNECT_TIMEOUT=3)
 (ADDRESS_LIST =
   (LOAD_BALANCE=on)
   (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
 (CONNECT_DATA=(SERVICE_NAME = service-name)))

Utilizzare quanto riportato di seguito per le connessioni JDBC che utilizzano il driver Oracle versione 12.1 o precedente

alias =
(DESCRIPTION =
(CONNECT_TIMEOUT= 15)(RETRY_COUNT=20)(RETRY_DELAY=3)
(ADDRESS_LIST =
  (LOAD_BALANCE=on)
  (ADDRESS = (PROTOCOL = TCP)(HOST=scan-host)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = service-name)))

Utilizzare FAN (Fast Application Notification)

FAN fornisce una notifica immediata a un'applicazione in caso di interruzione o ripresa del servizio. Senza FAN, le applicazioni possono bloccarsi al timeout TCP/IP in seguito a errori hardware e di rete e omettere di ribilanciare quando le risorse riprendono. Tutti i pool Oracle e tutti gli Oracle Application Server utilizzano FAN. I server applicazioni JAVA di terze parti possono utilizzare UCP per abilitare FAN.

Per utilizzare FAN non sono necessarie modifiche all'applicazione. Si tratta solo di modifiche alla configurazione.

Per un servizio continuo durante la manutenzione pianificata, utilizzare FAN con:

pool Oracle o
UCP con Application Server JDBC di terze parti o
I driver client Oracle più recenti

Per un servizio continuo durante le interruzioni non pianificate, utilizzare FAN con:

continuità di applicazione trasparente o
Continuità di applicazione

Copertura FAN

Gli eventi FAN sono integrati con:

Oracle Fusion Middleware - Oracle WebLogic Server
Broker Oracle Data Guard
Connection pool o driver Oracle JDBC Universal per le interfacce thin JDBC e Oracle Call Interface (OCI)
ODP.NET Connection pool per provider non gestiti e gestiti
Oracle Tuxedo
SQL*Plus
Driver Oracle Database per linguaggi quali Python, Node.js e PHP
Global Data Services
Application Server JDBC di terze parti che utilizzano Oracle JDBC Universal Connection Pool
Listener

Per abilitare FAN nel client

Utilizzare l'alias TNS mostrato in Configura stringa di connessione per High Availability. Questa stringa di connessione viene utilizzata per configurare automaticamente la sottoscrizione a Oracle Notification Service (ONS) presso il client per la ricezione di eventi FAN quando si utilizza un driver client Oracle Database 12c o versione successiva. ONS fornisce un percorso di comunicazione sicuro tra il livello di database e il livello client che consente al client di ricevere notifiche sulla disponibilità del servizio (arresto o avvio dei componenti) e consigli sul bilanciamento del carico in runtime per un migliore posizionamento del lavoro durante il normale funzionamento.

A seconda del client, abilitare FAN nelle proprietà di configurazione dell'applicazione come indicato di seguito.

Driver thin Universal Connection Pool o JDBC (a partire dalla versione 12.2)

Impostare la proprietà FastConnectionFailoverEnabled.
WebLogic Active GridLink per Oracle

Il FAN RAC e il failover rapido della connessione sono abilitati per impostazione predefinita.
Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), applicazioni JDBC

Utilizzare Universal Connection Pool come sostituzione del connection pool.
Client ODP.Net (provider gestiti e non gestiti)

Impostare "HA events = true;pooling=true" nella stringa di connessione se si utilizza ODP.Net 12.1 o versioni precedenti.
Client OCI (Oracle Call Interface) e driver basati su OCI

I client Oracle Call Interface (OCI) senza impostazioni native possono utilizzare un file oraacces.xml e impostare events su true.

Python, Node.js e PHP hanno opzioni native. In Python e Node.js è possibile impostare una modalità eventi durante la creazione di un connection pool. In PHP, modificare php.ini aggiungere la voce oci8.events=on.
SQL*Plus

FAN è abilitato per impostazione predefinita.

I servizi di database predefiniti offrono connessioni TCPS che utilizzano l'autenticazione basata su wallet TLS. A seconda del tipo di applicazione (JDBC o Oracle Call Interface), la configurazione del wallet deve seguire regole specifiche, come descritto in Configura client per FAN, inclusi wallet facoltativi.

Usa procedure consigliate per consentire rimozione

La procedura consigliata per l'uso dell'applicazione consiste nell'eseguire il check-out delle connessioni per il tempo necessario, quindi eseguirne il check-in nel pool una volta completata l'azione corrente. Ciò è importante per ottenere buone prestazioni, per il ribilanciamento del lavoro in fase di esecuzione e durante le finestre di manutenzione per drenare il lavoro.

Oracle consiglia di utilizzare un connection pool Oracle compatibile con FAN per nascondere la manutenzione pianificata. Non vi è alcun impatto per gli utenti quando l'applicazione utilizza un pool Oracle con FAN e restituisce le connessioni al pool tra le richieste. Non è necessario apportare modifiche all'applicazione per utilizzare FAN. Quando un connection pool Oracle riceve l'evento FAN per i tempi di inattività pianificati, contrassegna tutte le connessioni nell'istanza da eliminare. Le connessioni di cui è stato eseguito il check-in vengono chiuse in modo da non essere riutilizzate. Poiché le connessioni in uso vengono restituite al pool, vengono chiuse. Ciò consente di chiudere tutte le connessioni con grazia nel tempo.

Se si utilizza un application server basato su Java di terze parti, il metodo più efficace per ottenere l'eliminazione e il failover consiste nel sostituire l'origine dati in pool con UCP. Molti Application Server supportano questo approccio, tra cui Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring, Hibernate e altri. I white paper di Oracle e di altri provider, come IBM, descrivono come utilizzare UCP con questi Application Server. L'uso di UCP come origine dati consente di utilizzare con la certificazione completa funzioni UCP quali Fast Connection Failover, Runtime Load Balancing, Application Continuity e Transparent Application Continuity.

Abilitare la continuità di applicazione trasparente (TAC, Transparent Application Continuity) o la continuità di applicazione (AC, Application Continuity)

Il TAC tiene traccia e registra in modo trasparente la sessione e lo stato transazionale in modo che una sessione del database possa essere recuperata in seguito a interruzioni recuperabili. Per impostazione predefinita, per le due coppie di elaborazione delle transazioni dei servizi di database predefiniti è abilitato TAC.

AC è personalizzabile, che consente di scegliere di riprodurre gli effetti collaterali o di aggiungere callback complessi al failover che TAC non consente. Utilizzare AC se si utilizzano i driver Oracle 12c (JDBC-thin o Oracle Call Interface), se si desidera eseguire personalizzazioni con effetti collaterali o callback oppure se si dispone di un'applicazione che utilizza uno stato, ad esempio le tabelle temporanee della durata della sessione, e non esegue il cleanup delle richieste.

Passi per l'utilizzo della continuità di applicazione trasparente

Se è necessario abilitare la continuità di applicazione trasparente nel servizio di database in uso, vedere Abilita attributi di servizio per il failover.
Utilizzare uno dei seguenti client supportati.

Oracle consiglia di utilizzare i driver client più recenti. I driver client 19c di Oracle Database e in seguito forniscono il supporto completo per TAC.
- Driver di ripetizione JDBC Oracle 18c o versione successiva. Questa è una funzione di driver JDBC fornita con Oracle Database 18c per la continuità di applicazione.
- Oracle Universal Connection Pool (UCP) 18c o versione successiva con il driver di ripetizione JDBC Oracle 18c o versione successiva.
- Oracle WebLogic Server Active GridLink o server applicazioni JDBC di terze parti che utilizzano UCP con il driver di ripetizione Oracle JDBC 18c o versione successiva.
- Connection pool Java o applicazioni Java standalone utilizzando il driver Oracle JDBC Replay 18c o versione successiva.
- Pool di sessioni di Oracle Call Interface 19c o versioni successive.
- SQL*Plus 19c (19.3) o versione successiva
- ODP.NET in pool, driver non gestito 18c o successivo (impostazione predefinita "Pooling=true" nella versione 12.2 e successive).
- Applicazioni basate su Oracle Call Interface che utilizzano il driver OCI 19c o versione successiva.
Restituire le connessioni al pool delle connessioni.

Non è necessario apportare modifiche all'applicazione per identificare i limiti delle richieste se l'applicazione utilizza le connessioni:
- dai connection pool Oracle o
- dal driver Oracle JDBC Replay 18c o successivo o
- dalle applicazioni basate su Oracle Call Interface che utilizzano 19c o versioni successive
Quando si utilizzano i connection pool, l'applicazione deve restituire la connessione al pool al completamento di ogni richiesta. Oracle consiglia che un'applicazione esegua il check-out di una connessione solo per il tempo necessario. Tenere una connessione quando non è in uso non è una buona pratica. La continuità di applicazione trasparente con i driver elencati rileva anche dove è possibile aggiungere i limiti e crea i propri limiti.
Usa FAILOVER_RESTORE

L'abilitazione della continuità di applicazione trasparente ripristina automaticamente gli stati di sessione preimpostati. Se si ritiene che siano necessari stati di sessione preimpostati oltre al set standard, è possibile registrare un'etichetta di callback o UCP per ripristinare questi stati. Se è necessario ripristinare stati di sessione complessi, ad esempio tabelle temporanee o SYS_CONTEXT, utilizzare la continuità di applicazione che offre questa flessibilità.
Abilita l'uso modificabile nell'applicazione

Le funzioni modificabili sono funzioni che possono restituire un nuovo valore ogni volta che vengono eseguite. Il supporto per mantenere i risultati originali è fornito per SYSDATE, SYSTIMESTAMP, SYS_GUID e sequence.NEXTVAL. La continuità di applicazione 19c e successive mutabili automaticamente KEEP per SQL. Se l'applicazione utilizza o è sensibile a funzioni modificabili, un DBA deve eseguire il privilegio GRANT KEEP. Quando viene concesso il privilegio KEEP, la ripetizione applica il risultato della funzione originale alla ripetizione. Ad esempio:
```
SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
```
```
SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object
```
Effetti collaterali disabilitati

Un effetto collaterale è un'azione esterna come l'invio di posta, il trasferimento di file o l'utilizzo di TCP. La continuità di applicazione trasparente rileva gli effetti collaterali e non li riproduce. Se si desidera riprodurre gli effetti collaterali, utilizzare la continuità di applicazione che consente questa flessibilità aggiuntiva.

Passi per l'utilizzo della continuità di applicazione

Se è necessario abilitare la continuità di applicazione nel servizio di database in uso, vedere Abilita attributi di servizio per il failover.
Utilizzare uno dei seguenti client supportati.
- Driver di ripetizione JDBC Oracle 12c o versione successiva. Questa è una funzione di driver JDBC fornita con Oracle Database 12c per la continuità di applicazione.
- Oracle Universal Connection Pool (UCP) 12c o versione successiva con il driver di ripetizione JDBC Oracle 12c o versione successiva.
- Oracle WebLogic Server Active GridLink e server applicazioni JDBC di terze parti che utilizzano UCP con il driver di ripetizione Oracle JDBC 12c o versione successiva.
- Connection pool Java o applicazioni Java standalone che utilizzano il driver di replica JDBC Oracle 12c o versione successiva con limiti di richiesta o origine dati in pool.
- Applicazioni e driver di lingua che utilizzano il pool di sessioni Oracle Call Interface 12c Release 2 o successiva.
- SQL*Plus 19.3 o versione successiva.
- ODP.NET in pool, driver non gestito 12c Release 2 o successiva (impostazione predefinita "Pooling=true";"Application Continuity=true" in 12.2 e versioni successive)
Restituire le connessioni al pool delle connessioni.

Non è necessario apportare modifiche all'applicazione per identificare i limiti delle richieste se l'applicazione utilizza un connection pool Oracle o un pool JDBC di terze parti che supporta i limiti delle richieste. È consigliabile utilizzare un pool Oracle e restituire le connessioni a tale pool tra le richieste. Oracle consiglia che un'applicazione esegua il check-out di una connessione solo per il tempo necessario. Tenere una connessione quando non è in uso non è una buona pratica e impedirà la manutenzione pianificata trasparente.
Usa FAILOVER_RESTORE

Gli stati più comuni vengono ripristinati automaticamente con FAILOVER_RESTORE=LEVEL1. Se l'applicazione preimposta gli stati della sessione oltre al set standard, è necessario registrare un callback o un'etichetta UCP per ripristinare questi stati. Impostare FAILOVER_RESTORE=LEVEL1 sul servizio e utilizzare:
- Callback di inizializzazione della connessione per Java o il callback TAF (più vecchio) per Oracle Call Interface o
- Etichettatura connessione Universal Connection Pool o server WebLogic
Abilita l'uso modificabile nell'applicazione

Le funzioni modificabili sono funzioni che possono restituire un nuovo valore ogni volta che vengono eseguite. Il supporto per mantenere i risultati originali è fornito per SYSDATE, SYSTIMESTAMP, SYS_GUID e sequence.NEXTVAL. La continuità di applicazione 19c e successive muta automaticamente KEEP per SQL, pertanto non è richiesta alcuna azione. Se sono necessarie mutabili per PL/SQL, un DBA deve emettere il privilegio GRANT KEEP. Quando viene concesso il privilegio KEEP, la ripetizione applica il risultato della funzione originale alla ripetizione. Ad esempio:
```
SQL> GRANT [KEEP DATE TIME | KEEP SYSGUID] … TO USER
```
```
SQL> GRANT KEEP SEQUENCE mySequence TO myUser ON sequence.object
```
Decidi se vuoi riprodurre effetti collaterali

Un effetto collaterale è un'azione esterna come l'invio di posta, il trasferimento di file o l'utilizzo di TCP. Con Continuità di applicazione, gli effetti collaterali vengono riprodotti a meno che l'applicazione non specifichi diversamente. Se una richiesta dispone di un'azione esterna che non deve essere ripetuta, tale richiesta può utilizzare una connessione per la quale non è abilitata la continuità di applicazione oppure la ripetizione può essere disabilitata per tale richiesta utilizzando l'API disableReplay() per Java o OCIRequestDisableReplay() per Oracle Call Interface. Se non si desidera riprodurre tutti gli effetti collaterali, utilizzare la continuità di applicazione trasparente.

Titolo e informazioni sul copyright

Oracle e/o relative consociate.