Documentazione di Oracle Cloud Infrastructure

Configurazione client per la disponibilità continua su Autonomous Database

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

Argomento padre: usa la continuità di applicazione su Autonomous Database

Connessione mediante i servizi di database con continuità di applicazione abilitata

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

Le operazioni di alta disponibilità e continuità delle applicazioni si basano sull'uso dei servizi di connessione di 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 in Autonomous Database sono diversi, a seconda del carico di lavoro, come descritto nella sezione Nomi dei servizi di database per Autonomous Database.

Usa 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 prevede il completamento del lavoro corrente prima dell'avvio della manutenzione. In Autonomous Database ciò si verifica automaticamente e il lavoro viene esaurito prima di avviare le attività di manutenzione quando si seguono le seguenti linee guida:

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

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

Restituire le connessioni al connection pool

L'applicazione deve restituire la connessione al connection pool su ogni richiesta. È consigliabile che un'applicazione esegua il check-out di 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 il check-in di tale connessione immediatamente il lavoro è completato. Le connessioni sono quindi disponibili per l'utilizzo successivo da parte di altri thread o del thread quando necessario di nuovo. La restituzione delle connessioni a un connection pool è una raccomandazione generale, indipendentemente dal fatto che si utilizzi FAN per il drenaggio o i test di connessione per il drenaggio.

Usa un connection pool Oracle

Utilizzando un connection pool FAN, Oracle è la soluzione consigliata per nascondere la manutenzione pianificata. Man mano che la manutenzione procede e si completa, le sessioni vengono spostate e ribilanciate. 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. I pool Oracle supportati includono i provider UCP, WebLogic GridLink, Tuxedo, OCI Session Pool e ODP.NET gestiti e non gestiti. Non sono necessarie modifiche all'applicazione 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 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. 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 connessione

Se non è possibile utilizzare un pool Oracle con FAN, la sessione verrà eliminata dai driver client Autonomous Database o forniti. Quando i servizi vengono riposizionati o arrestati durante la manutenzione o viene eseguito lo switchover a un sito in standby utilizzando Autonomous Data Guard, i driver client Oracle Database e Oracle cercano posizioni sicure per rilasciare le connessioni in base alle regole riportate di seguito.

  • Test di connessione standard per la validità della connessione al momento del prestito o della 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. Inoltre, configurare lo svuotamento e l'eliminazione del pool in caso di errore del test di connessione ad almeno due volte la dimensione massima del pool o MAXINT.

Usa test di connessione con driver Java sottile

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

  • Abilita validate-on-borrow=true
  • Impostare le proprietà di 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 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, controllare l'handle del server quando si prendono in prestito e si restituiscono 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 seguente 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, eseguire le operazioni riportate di seguito.

  • Come prerequisito, abilita e configura la continuità di applicazione o la continuità di applicazione trasparente (TAC) per il tuo 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 in seguito forniscono supporto completo per la continuità di applicazione (AC) e per la continuità di applicazione trasparente (TAC). Utilizzare uno dei seguenti driver client supportati:

    • Driver di ripetizione Oracle JDBC 19c o versione successiva. Funzione del driver JDBC fornita con Oracle Database 19c per la continuità di applicazione

    • Oracle Universal Connection Pool (UCP) 19c o versione successiva con Oracle JDBC Replay Driver 19c o versione successiva

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

    • Connection pool Java o applicazioni Java standalone utilizzando il driver Oracle JDBC Replay Driver 19c o versione successiva

    • Pool di sessioni Oracle Call Interface 19c o versioni successive. SQL*Plus 19c (19.8) o versioni successive

    • ODP.NET, driver non gestito 19c o versioni successive ("Pooling=true" predefinito in 12.2 e versioni successive)

    • Applicazioni basate su Oracle Call Interface che utilizzano il driver OCI 19c o versione successiva

Restituire le connessioni al connection pool

L'applicazione deve restituire la connessione al connection pool Oracle su ogni richiesta. La procedura consigliata per l'uso dell'applicazione consiste nel check-out (prestare) le connessioni solo per il tempo necessario, quindi nel check-in al pool al termine delle azioni correnti. Ciò è importante per le migliori prestazioni dell'applicazione in runtime, per il ribilanciamento del lavoro in 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, questa procedura incorpora i limiti delle richieste utilizzati da Continuità applicazione 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 quando la ripetizione è disabilitata. Le condizioni per scoprire 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 a Clean Session State tra le richieste in questo documento)

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

Se sono necessarie mutabili per PL/SQL, eseguire 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, ad esempio l'invio di MAIL o il trasferimento di un file, viene definito un effetto collaterale.

Gli effetti collaterali sono azioni esterne, non eseguono il rollback. 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 poiché le esecuzioni duplicate non causano problemi. Per la continuità di applicazione, gli effetti collaterali vengono ripetuti a meno che la richiesta o la chiamata utente non sia esplicitamente disabilitata per la ripetizione. Al contrario, poiché la continuità di applicazione trasparente è attiva per impostazione predefinita, il TAC non riproduce gli effetti collaterali. L'acquisizione è disabilitata e riabilita il limite implicito successivo creato da TAC.

Best practice per gli sviluppatori per la disponibilità continua

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

Restituire le 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 dell'applicazione in runtime, per il drenaggio del lavoro e per il ribilanciamento del lavoro in runtime e durante la manutenzione e per la gestione di eventi di failover. Alcune applicazioni hanno una falsa idea che mantenere le connessioni migliori le prestazioni. Tenere una connessione non esegue né ridimensiona.

Stato sessione cleanup 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 impostati in tale sessione rimangono attivi a meno che non venga eseguita un'azione per cancellarli. Se l'applicazione sta impostando lo stato, è consigliabile riportare i cursori nella cache delle istruzioni e cancellare lo stato della sessione correlata all'applicazione per evitare perdite a riutilizzi successivi di tale sessione del database. La pulizia dello stato della sessione assicura che TAC possa individuare i limiti.

Per pulire automaticamente lo stato tra le richieste con Oracle Database 23ai, impostare l'attributo di servizio RESET_STATE=LEVEL1. In questo modo si eviterà la perdita di stato e il recupero dai cursori mediante l'utilizzo 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 restituendole alla cache delle istruzioni.

Se la tua 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 evita COMMIT in caso di 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'interruzione o un timeout. PL/SQL non rientra. Una volta eseguito un commit in PL/SQL, il blocco PL/SQL non può essere risottomesso. Le applicazioni devono annullare la selezione del commit non valido in quanto i dati potrebbero essere stati letti oppure utilizzare una tecnica di checkpoint e riavvio per i batch. 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 la continuità di applicazione trasparente (TAC), la continuità di applicazione (AC) e TAF Select Plus. Se l'applicazione utilizza COMMIT incorporato in PLSQL, AUTOCOMMIT o COMMIT ON SUCCESS, potrebbe non essere possibile ripetere la chiamata per i casi in cui la chiamata inclusa in 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 durante la ripetizione. Se non è possibile ripristinare gli stessi dati, Continuità di applicazione non accetterà la ripetizione. Quando un SELECT utilizza l'ordine ORDER BY o GROUP BY viene preservato. In Autonomous Database l'ottimizzatore di query utilizza più spesso lo stesso percorso di accesso, il che può aiutare nello stesso ordinamento dei risultati. Continuità di applicazione utilizza anche una clausola AS OF per restituire gli stessi risultati della query, dove è consentito AS OF.

Considerazioni su SQL*Plus

SQL*Plus è spesso il nostro strumento per provare le cose. Naturalmente SQL*Plus 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 segue:

  1. FAN è sempre abilitato per SQL*Plus. Utilizzare la stringa di connessione consigliata per la configurazione automatica degli endpoint ONS.

  2. Quando si utilizza SQL*plus la chiave è ridurre al minimo gli arrotondamenti al 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 una grande dimensione di array. Ad esempio (impostare arraysize 1000). Evitare di abilitare serveroutput poiché questo crea uno stato di sessione non ripristinabile.