Documentazione dell'infrastruttura Oracle Cloud

Configurazione del client per la disponibilità continua su Autonomous Database

Non è necessario riavviare le applicazioni per le attività di manutenzione pianificate quando si abilita Continuità di applicazione e si seguono le procedure ottimali di codifica.

Argomento padre: Usa la continuità di applicazione in Autonomous Database

Connessione mediante i servizi di database con la continuità dell'applicazione abilitata

I servizi di database Oracle garantiscono trasparenza per l'infrastruttura Autonomous Database di base.

Le operazioni di High Availability e Application Continuity si basano sull'uso dei servizi di connessione ad Autonomous Database. Per ottenere la continuità dell'applicazione, utilizzare un servizio di database quando ci si connette al database.

I nomi dei servizi di database predefiniti su Autonomous Database sono diversi, a seconda del carico di lavoro, come descritto in Nomi dei servizi di database per Autonomous Database.

Uso di procedure consigliate che supportano la rimozione

In Autonomous Database non è mai necessario riavviare gli application server quando la manutenzione pianificata segue le best practice.

Per la manutenzione pianificata, l'approccio consigliato è quello di fornire tempo per il completamento del lavoro corrente prima dell'avvio della manutenzione. In Autonomous Database questo accade automaticamente e il lavoro viene prosciugato prima di iniziare le attività di manutenzione quando si seguono le seguenti linee guida:

  • FAN con connection pool Oracle o driver Oracle
  • Test di connessione

Utilizzare il drenaggio in combinazione con la soluzione di failover scelta per le richieste non completate entro il tempo allocato per il drenaggio. La soluzione di failover tenterà di recuperare le sessioni che non sono state prosciugate nel tempo allocato.

Restituisci connessioni al connection pool

L'applicazione deve restituire la connessione al connection pool su ogni richiesta. È consigliabile che un'applicazione controlli una connessione solo per il tempo necessario. Il mantenimento di una connessione invece di restituirla al pool non viene eseguito. Un'applicazione dovrebbe quindi eseguire il check-out di una connessione e quindi eseguire immediatamente il check-in di tale connessione. Le connessioni sono quindi disponibili per l'utilizzo successivo da parte di altri thread o del thread, se necessario. Il ripristino delle connessioni a un connection pool è un suggerimento generale indipendentemente dal fatto che si utilizzi FAN per eseguire il drenaggio o dai test di connessione per eseguire il drenaggio.

Usa un connection pool Oracle

Utilizzando un connection pool basato su FAN, Oracle è la soluzione consigliata per nascondere la manutenzione pianificata. Man mano che la manutenzione procede e viene completata, le sessioni vengono spostate e ribilanciate. Non vi è alcun impatto sugli utenti quando l'applicazione utilizza un pool Oracle con FAN e restituisce le connessioni al pool tra le richieste. I pool Oracle supportati includono UCP, WebLogic GridLink, Tuxedo, OCI Session Pool e provider gestiti e non gestiti ODP.NET. Nessuna modifica dell'applicazione è necessaria per utilizzare FAN se non per assicurarsi che le connessioni vengano restituite al pool tra le richieste.

Usa UCP con un connection pool di terze parti

Se si utilizza un application server di terze parti basato su Java, il metodo più efficace per ottenere il drenaggio e il failover è sostituire l'origine dati in pool con UCP. Questo approccio è supportato da molti application server, tra cui Oracle WebLogic Server, IBM WebSphere, IBM Liberty, Apache Tomcat, Red Hat WildFly (JBoss), Spring e Hibernate e altri.

Usa test di connessione

Se non puoi utilizzare un pool Oracle con FAN, l'Autonomous Database o i driver client forniti prosciugheranno la sessione. Quando i servizi vengono riposizionati o arrestati durante la manutenzione o c'è uno switchover per un sito in standby che utilizza Autonomous Data Guard, i driver client Oracle Database e Oracle cercano luoghi sicuri in cui rilasciare le connessioni in base alle regole seguenti:

  • Test di connessione standard per la validità della connessione in caso di ricezione o restituzione da un connection pool
  • Test SQL personalizzati per la validità della connessione
  • I limiti della richiesta sono attivi e la richiesta corrente è terminata

Usa test di connessione con Autonomous Database

È possibile aggiungere, eliminare, abilitare o disabilitare i test di connessione per Autonomous Database.

Utilizzare la vista DBA_CONNECTION_TESTS per visualizzare i test di connessione disponibili.

Ad esempio:

SQL> EXECUTE 
   dbms_app_cont_admin.add_sql_connection_test('SELECT COUNT(1) FROM DUAL');
SQL> EXECUTE 
   dbms_app_cont_admin.enable_connection_test(dbms_app_cont_admin.sql_test, 
                                             'SELECT COUNT(1) FROM DUAL');
SQL> SELECT * FROM DBA_CONNECTION_TESTS;

Configurare lo stesso test di connessione abilitato nel database nel connection pool o nell'Application Server. Configurare inoltre lo svuotamento e l'eliminazione del pool in caso di errore del test di connessione almeno due volte la dimensione massima del pool o MAXINT.

Usa test di connessione con driver Java sottile

Se si desidera utilizzare i test di connessione locali al driver e non è possibile utilizzare il supporto FAN completo di UCP:

  • Abilita validate-on-borrow=true
  • Impostare le proprietà del sistema Java:
    • -Doracle.jdbc.fanEnabled=true
    • -Doracle.jdbc.defaultConnectionValidation=SOCKET

E poi utilizzare uno dei seguenti test:

  • java.sql.Connection.isValid(int timeout)
  • oracle.jdbc.OracleConnection.pingDatabase()
  • oracle.jdbc.OracleConnection.pingDatabase(int timeout)
  • Un HINT all'inizio dell'istruzione SQL di test:
    • /*+ CLIENT_CONNECTION_VALIDATION */

Usa test di connessione con il driver OCI

Se si desidera utilizzare direttamente il driver OCI, utilizzare OCI_ATTR_SERVER_STATUS. Questo è l'unico metodo che è una modifica del codice. Nel codice, controlla l'handle del server quando prendi in prestito e restituisci le connessioni per vedere se la sessione è disconnessa. Durante la manutenzione, il valore di OCI_ATTR_SERVER_STATUS viene impostato su OCI_SERVER_NOT_CONNECTED. Quando si utilizza il pool di sessioni OCI, questo controllo della connessione viene eseguito automaticamente.

L'esempio di codice riportato di seguito mostra come utilizzare OCI_ATTR_SERVER_STATUS. 

ub4 serverStatus = 0OCIAttrGet((dvoid *)srvhp,
          OCI_HTYPE_SERVER,             
        (dvoid *)&serverStatus, (ub4 *)0, OCI_ATTR_SERVER_STATUS,
      errhp);if (serverStatus ==
        OCI_SERVER_NORMAL)printf("Connection is
        up.\n");else if (serverStatus ==
        OCI_SERVER_NOT_CONNECTED) printf("Connection is down.\n");

Passi per l'utilizzo della continuità di applicazione

Per utilizzare la continuità di applicazione, effettuare le operazioni riportate di seguito.

  • Come prerequisito, abilitare e configurare Application Continuity o Transparent Application Continuity (TAC) per il servizio di database su Autonomous Database. Per ulteriori informazioni, vedere Configura continuità di applicazione in Autonomous Database.

  • Oracle consiglia di utilizzare i driver client più recenti. I driver client Oracle Database 19c e versioni successive forniscono supporto completo per Application Continuity (AC) e per Transparent Application Continuity (TAC). Utilizzare uno dei driver client supportati seguenti:

    • Driver di ripetizione JDBC Oracle 19c o versione successiva. Questa è una funzione driver JDBC fornita con Oracle Database 19c per Application Continuity

    • Oracle Universal Connection Pool (UCP) 19c o versione successiva con il driver di ripetizione JDBC Oracle 19c o versione successiva

    • Oracle Weblogic Server 12c con Active GridLink o Application Server JDBC di terze parti che utilizzano UCP con il driver di ripetizione JDBC Oracle 19c o versione successiva

    • Connection pool Java o applicazioni Java standalone che utilizzano il driver di ripetizione JDBC Oracle 19c o versioni successive

    • Oracle Call Interface Session Pool 19c o versione successiva.SQL*Plus 19c (19.8) o versione successiva

    • ODP.NET driver in pool non gestito 19c o versione successiva ("Pooling=true" predefinito nella versione 12.2 e successive)

    • Applicazioni basate su Oracle Call Interface che utilizzano il driver OCI 19c o versioni successive

Restituisci connessioni al connection pool

L'applicazione deve restituire la connessione al connection pool Oracle su ogni richiesta. La procedura consigliata per l'utilizzo delle applicazioni consiste nel check-out (in sospeso) delle connessioni solo per il tempo necessario, quindi eseguire il check-in al pool al termine delle azioni correnti. Ciò è importante per le migliori prestazioni delle applicazioni in fase di esecuzione, per il ribilanciamento del lavoro in fase di runtime e durante gli eventi di manutenzione e failover. Questa pratica è importante anche per il drenaggio.

Quando si utilizza un connection pool Oracle, ad esempio Universal Connection Pool (UCP) o OCI Session Pool, o ODP.Net Unmanaged Provider o quando si utilizza WebLogic Active GridLink, seguendo questa procedura vengono incorporati i limiti della richiesta utilizzati da Application Continuity per identificare le posizioni sicure per riprendere e terminare l'acquisizione. È necessario per la continuità di applicazione ed è consigliato per la continuità di applicazione trasparente.

La continuità di applicazione trasparente, inoltre, rileva i limiti delle richieste se un pool non è in uso o se la ripetizione è disabilitata. Le condizioni per la scoperta di un confine sono:

  • Nessuna transazione aperta
  • I cursori vengono restituiti alla cache delle istruzioni o annullati
  • Non esiste alcuno stato di sessione non ripristinabile (fare riferimento allo stato di sessione pulita tra le richieste in questo documento)

Abilita i mutabili utilizzati 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 delle funzioni mutabili è fornito per SYSDATE, SYSTIMESTAMP, SYS_GUID e la sequenza.NEXTVAL. Se i valori originali non vengono mantenuti e vengono restituiti valori diversi all'applicazione durante la ripetizione, la ripetizione viene rifiutata.

Se sono necessari elementi modificabili per PL/SQL, eseguire il problema GRANT KEEP in base alle esigenze.

Ad esempio:

SQL> GRANT KEEP DATE TIME to adb_user;
SQL> GRANT KEEP SYSGUID to adb_user;
SQL> GRANT KEEP SEQUENCE mySequence to adb_user on mysequence.myobject;

Effetti del collegamento

Quando una richiesta di database include una chiamata esterna come l'invio di MAIL o il trasferimento di un file, questo viene definito un effetto collaterale.

Gli effetti collaterali sono azioni esterne, non si annullano. Quando si verifica la ripetizione, c'è una scelta su se gli effetti collaterali devono essere riprodotti. Molte applicazioni scelgono di ripetere gli effetti collaterali come le scritture contabili e l'invio di posta come esecuzioni duplicate non causano problemi. Per Continuità di applicazione gli effetti collaterali vengono ripetuti a meno che la richiesta o la chiamata utente non sia esplicitamente disabilitata per la ripetizione. Viceversa, poiché la continuità di applicazione trasparente è attiva per impostazione predefinita, il TAC non riproduce gli effetti collaterali. L'acquisizione è disabilitata e riabilita al successivo limite implicito creato da TAC.

Best practice per gli sviluppatori per la disponibilità continua

Segui queste best practice per programmare la disponibilità continua su Autonomous Database.

Restituisci connessioni al connection pool

La procedura più importante per gli sviluppatori consiste nel restituire le connessioni al connection pool alla fine di ogni richiesta. Ciò è importante per le migliori prestazioni delle applicazioni in fase di esecuzione, per il drenaggio del lavoro e per il ribilanciamento del lavoro in fase di runtime e durante la manutenzione e per la gestione degli eventi di failover. Alcune applicazioni hanno una falsa idea che trattenere le connessioni migliori le prestazioni. Tenere una connessione non esegue né ridimensiona.

Cleanup stato sessione tra richieste

È consigliabile pulire lo stato della sessione tra le richieste del database.

Quando un'applicazione restituisce una connessione al connection pool, i cursori con stato FETCH e lo stato della sessione impostato in tale sessione rimangono attivi, a meno che non venga eseguita un'azione per cancellarli. Se l'applicazione sta impostando lo stato, è consigliabile ripristinare i cursori nella cache delle istruzioni e cancellare lo stato della sessione correlata all'applicazione per evitare che la perdita venga riutilizzata in seguito in tale sessione del database. La pulizia dello stato della sessione consente al TAC di individuare i limiti.

Per eseguire automaticamente il cleanup dello stato tra le richieste con Oracle Database 23ai, impostare l'attributo di servizio RESET_STATE=LEVEL1. Questa operazione eviterà la perdita di stato e il recupero dai cursori mediante l'uso successivo del connection pool.

Se si utilizza Oracle Database 19c, utilizzare DBMS_SESSION.RESET_PACKAGE per cancellare le variabili globali PL/SQL, utilizzare TRUNCATE per cancellare le tabelle temporanee, SYS_CONTEXT.CLEAR_CONTEXT per cancellare il contesto e annullare i cursori restituendoli alla cache delle istruzioni.

Se l'applicazione è senza conservazione dello stato, ad esempio REST, APEX, Microservice e la maggior parte delle applicazioni Web, è consigliabile utilizzare RESET_STATE.

Non incorporare COMMIT in PL/SQL ed evitare COMMIT al successo e COMMIT automatico

Si consiglia di utilizzare un commit di livello superiore (OCOMMIT, COMMIT() o OCITransCommit). Se l'applicazione utilizza COMMIT incorporato in PL/SQL, AUTOCOMMIT o COMMIT ON SUCCESS, potrebbe non essere possibile eseguire il ripristino dopo un'indisponibilità o un timeout. PL/SQL non è reentrant. Una volta eseguito un commit in PL/SQL, il blocco PL/SQL non può essere risottomesso. Le applicazioni devono annullare la selezione del commit che non è valido in quanto i dati potrebbero essere stati letti oppure utilizzare in batch una tecnica di checkpoint e riavvio. Quando si utilizza AUTOCOMMIT o COMMIT ON SUCCESS, l'output viene perso.

Se l'applicazione utilizza un commit di livello superiore, è disponibile il supporto completo per Transparent Application Continuity (TAC), Application Continuity (AC) e TAF Select Plus. Se l'applicazione utilizza COMMIT incorporato in PLSQL o AUTOCOMMIT o COMMIT ON SUCCESS, potrebbe non essere possibile riprodurre i casi in cui la chiamata, incluso COMMIT, non è stata eseguita fino al completamento.

Usa ORDER BY o GROUP BY nelle query

La continuità di applicazione garantisce che l'applicazione visualizzi gli stessi dati alla ripetizione. Se non è possibile ripristinare gli stessi dati, Application Continuity non accetterà la ripetizione. Quando un ordine SELECT utilizza ORDER BY o GROUP BY viene conservato. In Autonomous Database l'ottimizzatore di query utilizza più spesso lo stesso percorso di accesso, il che può aiutare a ordinare i risultati nello stesso ordine. La continuità di applicazione utilizza anche una clausola AS OF per restituire gli stessi risultati della query in cui è consentito AS OF.

Considerazioni per SQL*Plus

SQL*Plus è spesso il nostro strumento per provare le cose. SQL*Plus ovviamente non riflette la nostra applicazione effettiva che verrà utilizzata in produzione, quindi è sempre meglio utilizzare la vera suite di test delle applicazioni per testare il tuo piano di failover e misurare la tua protezione. SQL*Plus non è un'applicazione in pool, pertanto non dispone di limiti di richiesta espliciti. Alcune applicazioni utilizzano SQL*Plus, ad esempio per i report. Per utilizzare SQL*Plus con failover, controllare quanto riportato di seguito.

  1. FAN è sempre abilitato per SQL*Plus. Utilizzare la stringa di connessione consigliata che configura automaticamente gli endpoint ONS.

  2. Quando si utilizza SQL*plus, la chiave è ridurre al minimo i round-trip nel database: https://blogs.oracle.com/opal/sqlplus-12201-adds-new-performance-features

  3. SQL*Plus è supportato per TAC a partire da Oracle Database 19c. Per ottenere risultati ottimali, impostare un array di grandi dimensioni. Ad esempio (impostare la dimensione array 1000). Evitare di abilitare serveroutput poiché questo crea uno stato di sessione non ripristinabile.