Documentazione di Oracle Cloud Infrastructure

Visualizzare le informazioni sulla finestra patch e manutenzione, impostare il livello patch

Autonomous Database utilizza finestre di manutenzione predefinite per applicare automaticamente le patch al database. È possibile visualizzare le informazioni sulla manutenzione e le patch e i dettagli per la cronologia di manutenzione di Autonomous Database.

Argomento padre: Gestione e visualizzazione delle finestre di manutenzione, opzioni di applicazione patch, richieste di lavoro e contatti cliente

Informazioni sulla manutenzione pianificata e l'applicazione di patch

Tutte le istanze di Autonomous Database vengono assegnate automaticamente a una finestra di manutenzione e istanze diverse possono avere finestre di manutenzione diverse.

Autonomous Database utilizza queste finestre di manutenzione per applicare patch all'intero stack utilizzato per eseguire il database, inclusi il software del database, il dizionario del database, i sistemi operativi, lo storage Exadata, il firmware e altro ancora.

Le patch includono correzioni di bug, correzioni della sicurezza e nuove funzionalità. Le correzioni di sicurezza critiche vengono sempre applicate non appena sono disponibili. Le patch vengono distribuite in modo uniforme in tutti i database, pertanto non è necessario tenere traccia delle patch singole. Dopo l'implementazione di una correzione per un problema, ad esempio un problema visualizzato in un database, la correzione viene distribuita in tutte le istanze di Autonomous Database.

Tutte le patch vengono sottoposte a un rigoroso processo di test e convalida che fa parte di una pipeline continua di integrazione e sviluppo. Le correzioni vengono convalidate in più fasi e ambienti prima di essere distribuite nei database a livello di patch iniziale e Sempre gratis, seguiti dai database a livello di patch regolare. Questa pipeline consente di rilevare e correggere le regressioni prima che la patch venga distribuita in tutti i database. Nell'improbabile caso in cui l'applicazione di patch introduca una regressione, Oracle dispone di processi per mitigare il problema, incluse azioni come le seguenti:

  • Rollback di un subset della patch o dell'intera patch.

  • Impostazione dei parametri del database per disabilitare la patch che ha introdotto la regressione.

  • Applicazione di una patch online per risolvere il problema senza tempi di inattività o interruzioni della connessione.


Segue la descrizione di autonomous-database-continuous-integration.eps
Descrizione dell'immagine autonomous-database-continuous-integration.eps

Il rilevamento automatico della regressione per Autonomous Database fornisce una gestione proattiva delle regressioni e consente il rilevamento, la diagnosi e la mitigazione automatizzati dei problemi. In questo modo è possibile ridurre o eliminare la necessità di analizzare manualmente i problemi e le richieste di servizio dei file. Il rilevamento automatico della regressione monitora tutti i database, sia in entrambi i database i livelli di patch Early e Regular, ma risulta particolarmente utile quando si esegue il test di un carico di lavoro su un database a livello di patch Early. Se il rilevamento automatico della regressione rileva un problema e identifica una regressione, il problema viene segnalato automaticamente con informazioni dettagliate per la diagnosi. Questo reporting automatizzato, nell'ambito del ciclo di applicazione continua delle patch di distribuzione, consente a Oracle di mitigare o risolvere il problema prima che le modifiche raggiungano i database di produzione (database normali a livello di patch). Il rilevamento automatico della regressione potrebbe non essere in grado di trovare tutti i problemi. Nei casi in cui si riscontrano problemi personalmente, è possibile inviare una richiesta di servizio.

Il rilevamento automatico della regressione include quanto segue:

  • Automatic Regression Detection monitora il database e, in caso di incidente, registra un bug per l'incidente con informazioni di diagnostica dettagliate estratte dal repository automatico del carico di lavoro.

  • Il sistema di segnalazione degli incidenti produce notifiche ai team operativi e di sviluppo di Oracle Cloud Infrastructure con Oracle Automatic Incident Monitoring.

  • I problemi vengono mitigati analizzando gli avvisi di rilevamento automatico della regressione.

  • L'apprendimento e i miglioramenti vengono apportati al rilevamento automatico della regressione su base continuativa.

La pagina Dettagli di Autonomous Database mostra i campi Livello di patch e Manutenzione successiva che includono la data e l'ora per la finestra di manutenzione imminente. La data viene aggiornata automaticamente quando viene pianificata la finestra di manutenzione successiva. Il collegamento Visualizza cronologia fornisce dettagli sulla manutenzione passata. Il campo Componente di destinazione mostra il componente da aggiornare nella finestra di manutenzione successiva.

Segue la descrizione di adb_patch_level.png
Descrizione dell'immagine adb_patch_level.png

Quando Autonomous Data Guard è abilitato, la console mostra anche le informazioni di manutenzione per un database di standby locale.

L'area Manutenzione include le informazioni riportate di seguito.

Campo di gestione descrizione;

Livello patch

Mostra il livello di patch per l'istanza. Sono disponibili due opzioni per il livello di patch: Regular e Early. Fare clic su Modifica per gestire le impostazioni del livello di patch.

Per ulteriori informazioni, vedere Impostazione del livello di patch.

Manutenzione successiva

Specifica il periodo di tempo per la successiva finestra di manutenzione pianificata. Fare clic su Visualizza cronologia per visualizzare i dettagli sulla manutenzione passata.

Per ulteriori informazioni, vedere Visualizza cronologia eventi di manutenzione.

Componente di destinazione

Elenca i componenti di destinazione per la finestra di manutenzione imminente. I valori possibili sono:

  • Database: quando la patch si applica alla home e agli eseguibili del database.

  • Dizionario: quando la patch si applica al dizionario dati e a Oracle APEX.

  • Infrastruttura: quando la patch si applica all'hardware Exadata o a Grid Infrastructure.

Manutenzione successiva (peer locale)

Specifica il periodo di tempo per la successiva finestra di manutenzione pianificata per uno standby Autonomous Data Guard locale. Fare clic su Visualizza cronologia per visualizzare i dettagli sulla manutenzione passata.

Componente di destinazione (peer locale)

Elenca i componenti di destinazione per la finestra di manutenzione imminente in Autonomous Data Guard. I valori possibili sono:

  • Database: quando la patch si applica alla home e agli eseguibili del database.

  • Dizionario: quando la patch si applica al dizionario dati e a Oracle APEX.

  • Infrastruttura: quando la patch si applica all'hardware Exadata o a Grid Infrastructure.

Contatti cliente

Quando i contatti del cliente sono impostati, Oracle invia le notifiche agli indirizzi di posta elettronica specificati per i problemi relativi al servizio Autonomous Database.

Per ulteriori informazioni, vedere Visualizzazione e gestione dei contatti dei clienti per problemi e annunci operativi.

Note per la manutenzione e l'applicazione di patch pianificate:

  • Il team operativo di Autonomous Database non accede mai ai dati a meno che non si conceda esplicitamente l'autorizzazione tramite una richiesta di servizio per una durata specificata.

  • Se il database si trova in stato arrestato durante la finestra di manutenzione, le modifiche apportate al database dalla patch vengono applicate all'avvio del database.

  • Il database rimane disponibile durante la finestra di manutenzione. Le nuove connessioni al database avranno sempre successo. È possibile che le connessioni al database esistenti vengano disconnesse brevemente, a seconda del componente a cui viene applicata la patch. Tuttavia, è possibile riconnettersi immediatamente e continuare a utilizzare il database:

    • Per le patch del database, le connessioni esistenti potrebbero essere disconnesse se sono in esecuzione per un periodo superiore al tempo di rimozione dopo l'avvio dell'applicazione delle patch.

    • Per le patch dell'infrastruttura, le connessioni esistenti potrebbero essere disconnesse se sono in esecuzione per un periodo superiore al tempo di rimozione dopo l'avvio dell'applicazione delle patch.

    • Per le patch del dizionario, è possibile che le connessioni esistenti vengano disconnesse se contengono blocchi sugli oggetti del dizionario a cui viene applicata la patch. In caso contrario, le connessioni esistenti non verranno interessate. Ad esempio, se l'applicazione esegue una procedura nel package DBMS_CLOUD durante l'applicazione delle patch e il package deve essere sottoposto a patch, è possibile che la sessione che utilizza tale package venga disconnessa.

      Per ulteriori informazioni, vedere SESSION_EXIT_ON_PACKAGE_STATE_ERROR.

  • Puoi utilizzare Oracle Cloud Infrastructure Events per ricevere una notifica all'inizio e alla fine della manutenzione. Per ulteriori informazioni, consulta gli eventi di informazioni su Autonomous Database.

  • Se si desidera modificare la finestra di manutenzione assegnata in una finestra di 2 ore diversa il sabato o la domenica nel fuso orario locale dell'area, inviare una richiesta di servizio al Supporto Oracle Cloud.

    Se si desidera un periodo di tempo specifico per la finestra di manutenzione il sabato o la domenica nel fuso orario locale dell'area, è possibile richiedere il periodo di tempo con la stessa richiesta di servizio. Se si richiede un periodo di tempo specifico per la finestra di manutenzione, la modifica può essere apportata solo se il periodo di tempo richiesto è disponibile per il database.

  • Se lo storage allocato del database è di 384 TB, è possibile scegliere una finestra personalizzata di 2 ore inoltrando una richiesta di servizio al Supporto Oracle Cloud (ovvero è possibile inviare una richiesta di servizio per richiedere un giorno e un periodo di tempo specifici il sabato o la domenica nel fuso orario locale dell'area per la finestra di manutenzione).

Vedere Test dei carichi di lavoro rispetto a una patch imminente per informazioni sull'acquisizione di un carico di lavoro da un database di produzione e sulla ripetizione del carico di lavoro su una copia aggiornabile a livello di patch iniziale di destinazione.

Vedere Obiettivo livello di servizio zero-regressione per i dettagli sull'SLO a zero-regressione per Autonomous Database.

Visualizza cronologia eventi di manutenzione

È possibile visualizzare la cronologia degli eventi di manutenzione di Autonomous Database per i dettagli sugli eventi di manutenzione precedenti, ad esempio il titolo, lo stato, l'ora di inizio e l'ora di arresto.

Se necessario, eseguire i seguenti prerequisiti:

  • Apri la console di Oracle Cloud Infrastructure facendo clic su icona di navigazione accanto a Cloud.

  • Nel menu di navigazione a sinistra di Oracle Cloud Infrastructure fai clic su Oracle Database, quindi su Autonomous Database.

  • Nella pagina Autonomous Databases selezionare un Autonomous Database dai collegamenti nella colonna Nome visualizzato.

Per visualizzare la cronologia di manutenzione, effettuare le operazioni riportate di seguito.

  1. Nella pagina Dettagli di Autonomous Database, in Manutenzione successiva, fare clic su Visualizza cronologia.
  2. La console di Oracle Cloud Infrastructure visualizza la pagina Cronologia manutenzione.
  3. (Facoltativo) Utilizzare il selettore Cerca e filtra per filtrare gli eventi in base allo stato.

    Ad esempio, se si seleziona Riuscito, la pagina Cronologia manutenzione mostra solo gli eventi di manutenzione con lo stato Riuscito.

La pagina Cronologia manutenzione mostra i dettagli di ciascun evento di manutenzione, inclusi i seguenti:
Campo descrizione;

Qualifica

Il nome dell'evento di manutenzione.

Tipo di manutenzione

Pianificati o non pianificati.

Componente di destinazione

 Il tipo di risorsa su cui si verifica l'evento di manutenzione: database, dizionario o infrastruttura.

Stato

Operazione riuscita, non riuscita o in corso.

Ora di avvio

Ora di inizio manutenzione.

Ora di fine

Ora di fine manutenzione.
Nota

La cronologia degli eventi di manutenzione è disponibile a partire dagli eventi di manutenzione successivi a febbraio 2021.

Visualizza dettagli patch

È possibile visualizzare le informazioni sulle patch di Autonomous Database, inclusa una lista di problemi e componenti risolti.

La vista DBA_CLOUD_PATCH_INFO fornisce informazioni sulle patch relative ai bug segnalati (bug segnalati da un cliente). È possibile utilizzare queste informazioni per determinare se un bug segnalato è stato corretto e la versione della patch in cui la correzione è stata applicata all'istanza di Autonomous Database. Se in una patch non sono presenti bug del cliente, DBA_CLOUD_PATCH_INFO non include righe per tale patch.

Per visualizzare le informazioni sulle patch per una patch specifica, effettuare le operazioni riportate di seguito.

  1. Selezionare la patch di Autonomous Database che si desidera visualizzare. La pagina Cronologia manutenzione nella console di Oracle Cloud Infrastructure mostra la lista delle patch sotto Titolo.
  2. Per la patch selezionata, eseguire una query sulla vista DBA_CLOUD_PATCH_INFO.

    Ad esempio, per la patch ADBS-21.7.1.1, utilizzare la query seguente: 

    SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-21.7.1.1';
  3. Per un problema di interesse, eseguire una query sulla vista per ottenere i dettagli per il problema:
    SELECT * FROM DBA_CLOUD_PATCH_INFO WHERE PATCH_VERSION = 'ADBS-21.7.1.1' and BUG_NUM = bug_number;

Per visualizzare le informazioni sulle patch per tutte le patch disponibili:

SELECT * FROM DBA_CLOUD_PATCH_INFO;

Note per la visualizzazione delle informazioni sulle patch:

  • La vista DBA_CLOUD_PATCH_INFO è disponibile per l'utente ADMIN.

  • Le informazioni sulle patch e i dettagli sui problemi risolti sono disponibili a partire da ADBS-21.7.1.1 (a partire da luglio 2021).

  • La vista DBA_CLOUD_PATCH_INFO contiene le colonne riportate di seguito. 

    BUG_NUM, BUG_TITLE, COMPONENT_NAME, PATCH_VERSION

Per informazioni dettagliate sulle patch applicate durante la manutenzione, vedere Visualizza notifiche sullo stato di manutenzione.

Imposta livello patch

Quando esegui il provisioning o la copia di un'istanza di Autonomous Database, puoi selezionare un livello di patch da applicare alle patch imminenti. È inoltre possibile modificare il livello di patch dopo il provisioning di un'istanza di Autonomous Database. Sono disponibili due opzioni per il livello di patch: Regular e Early.

Quando si seleziona il livello di patch In anticipo, le patch vengono applicate per l'istanza di Autonomous Database una settimana prima della patch pianificata Regolare. Il campo Manutenzione successiva nella console di Oracle Cloud Infrastructure riflette una data e un'ora della finestra di manutenzione in base al livello di patch.

Il livello di patch predefinito per il provisioning di un'istanza di Autonomous Database è Regolare. Il livello di patch predefinito per la duplicazione è il livello di patch specificato per il database di origine.

Il provisioning o la clonazione di un'istanza e l'impostazione del livello di patch su In anticipo consentono di utilizzare e sottoporre a test le patch imminenti prima che vengano applicate a tutti i sistemi. Oracle consiglia di selezionare il livello di patch In anticipo per i database di sviluppo e test se si desidera eseguire il test delle patch imminenti prima che le patch raggiungano la produzione. Puoi anche eseguire il test dei carichi di lavoro utilizzando Oracle Real Application Testing per acquisire un carico di lavoro su un sistema di produzione e riprodurlo con il livello di patch all'inizio. Per ulteriori informazioni, vedere Test dei carichi di lavoro con Oracle Real Application Testing.

Nota

L'impostazione del livello di patch è disponibile solo su un'istanza di Autonomous Database che utilizza il modello di computazione ECPU.
Per impostare il livello di patch durante il provisioning o la duplicazione di un'istanza, effettuare le operazioni riportate di seguito.

Per modificare il livello di patch per un Autonomous Database esistente, effettuare le operazioni riportate di seguito.

  1. Nella pagina Dettagli Autonomous Database, in Manutenzione, nel campo Livello patch fare clic su Modifica.
    Nota

    Il pulsante Modifica può essere disabilitato nei seguenti casi:
    • Se il livello di patch iniziale non è disponibile nella propria area per la versione del database.
    • Se nel database è abilitato Autonomous Data Guard.
    • Se il database si trova al livello di patch iniziale e non è possibile spostarlo al livello di patch normale. In questo caso, è necessario riprovare dopo la finestra di manutenzione successiva.
  2. Selezionare il livello di patch, Regular o Early, quindi fare clic su Submit.

    Il tempo necessario per modificare il livello di patch dipende dalla dimensione del database. Durante questo periodo è possibile che si verifichino brevi cali di connessione.

Generazione di report sui problemi delle patch al supporto Oracle

Quando si segnala un problema per un database a livello di patch in anticipo, il Supporto Oracle esegue le azioni necessarie per impedire la propagazione del problema ai database a livello di patch Normale. Alcuni esempi delle possibili azioni sono:

  • La patch che ha causato il problema viene rimossa prima dell'applicazione delle patch ai normali database a livello di patch.

  • La patch che ha causato il problema viene disabilitata utilizzando i parametri del database quando viene applicata ai normali database a livello di patch.

  • L'applicazione delle patch ai database regolari a livello di patch viene sospesa fino a quando non vengono intraprese azioni correttive.

In caso di problemi da segnalare, inoltrare una richiesta di assistenza all'indirizzo Oracle Cloud Support o contattare il rappresentante dell'assistenza.

Oracle fornisce un obiettivo a livello di servizio pari a zero regressioni nel database di produzione. Per ulteriori informazioni, vedere Obiettivo livello di servizio a nessuna regressione.

Note per il livello di applicazione delle patch:

  • L'opzione per impostare il livello di patch non è disponibile in ogni area. In alcune aree tutte le istanze di Autonomous Database vengono sottoposte a provisioning o clonate a livello di patch Regolare.

  • Autonomous Data Guard è disponibile solo per le istanze con livello di patch Regolare. Quando si configura un'istanza di Autonomous Database con il livello di patch In anticipo, non è possibile abilitare Autonomous Data Guard.

  • Le istanze di Autonomous Database Sempre gratis non forniscono l'opzione a livello di patch In anticipo.

  • Quando il livello di patch di un'istanza di Autonomous Database di origine è Regolare, nelle aree che supportano il livello di patch In anticipo è possibile impostare il livello di patch di una copia su In anticipo.

Visualizza notifiche stato manutenzione

La vista DB_NOTIFICATIONS memorizza le informazioni sulle notifiche dello stato di manutenzione per l'istanza di Autonomous Database.

Per mostrare informazioni sulla notifica, procedere come segue.

  1. Connettersi all'istanza di Autonomous Database.
  2. Utilizzare la query seguente per visualizzare le informazioni sulla manutenzione (applicazione di patch).
    SELECT * FROM DB_NOTIFICATIONS WHERE TYPE = 'MAINTENANCE';

Di seguito vengono fornite informazioni dettagliate sui valori dei campi DESCRIPTION.

  • Esecuzione della manutenzione terminata: specifica che la manutenzione è stata completata. Il valore MAINTENANCE_STATUS mostra il valore COMPLETED con gli indicatori orari di inizio e fine per la manutenzione completata in ACTUAL_START_DATE e ACTUAL_END_DATE.

  • L'esecuzione della manutenzione è pianificata per l'istanza: specifica che è stata pianificata una nuova manutenzione. Il valore MAINTENANCE_STATUS mostra il valore SCHEDULED con gli indicatori orari di inizio e fine previsti per la manutenzione pianificata in EXPECTED_START_DATE e EXPECTED_END_DATE.

  • Esecuzione della manutenzione iniziata: specifica che la manutenzione è in corso e fornisce l'indicatore orario di inizio per la manutenzione attiva. Il valore MAINTENANCE_STATUS mostra il valore IN_PROGRESS e ACTUAL_START_DATE memorizza l'indicatore orario di inizio.

Nella tabella seguente vengono visualizzate le colonne e i tipi di dati DB_NOTIFICATIONS.

A colonne Tipo di dati descrizione;
TYPE VARCHAR2(128)

Specifica il tipo di notifica.

Il valore valido è: MAINTENANCE.

TIME TIMESTAMP(6) WITH TIME ZONE

Ora di aggiunta della voce di notifica.
EXPECTED_START_DATE TIMESTAMP(6) WITH TIME ZONE

Ora di inizio della manutenzione pianificata.
EXPECTED_END_DATE TIMESTAMP(6) WITH TIME ZONE

Ora di fine manutenzione pianificata.
ACTUAL_START_DATE TIMESTAMP(6) WITH TIME ZONE

Ora di inizio manutenzione effettiva.
ACTUAL_END_DATE TIMESTAMP(6) WITH TIME ZONE

Ora di fine manutenzione effettiva.
MAINTENANCE_PRODUCT VARCHAR2(128)

Prodotto/componente per il quale è pianificata/in corso la manutenzione.
MAINTENANCE_STATUS VARCHAR2(128)

Stato corrente della manutenzione.
DESCRIPTION VARCHAR2(128)

Dettagli del messaggio di notifica.
PATCH_ID VARCHAR2(128)

Versione patch.

Procedure consigliate per gestire la disponibilità delle applicazioni durante le finestre di manutenzione

Fornisce informazioni sulle procedure ottimali per mantenere la disponibilità delle applicazioni e ridurre al minimo le interruzioni delle applicazioni durante una finestra di manutenzione pianificata.

Le patch di Autonomous Database vengono applicate durante una finestra di manutenzione pianificata come patch in sequenza. Utilizzando le patch in sequenza, l'istanza di Autonomous Database viene resa disponibile sui nuovi nodi del cluster prima che l'applicazione delle patch inizi sui nodi originali in cui era in esecuzione. Una volta che il database è disponibile sui nuovi nodi del cluster, tutte le nuove connessioni vengono indirizzate ai nuovi nodi. Ciò significa che il database rimane in linea e disponibile durante la manutenzione e che le nuove richieste di connessione al database avranno esito positivo durante la finestra di manutenzione.

Le connessioni al database esistenti sui nodi originali sono soggette a drenaggio per 5 minutiFoot 1. Durante il periodo di drenaggio il database attende che il client rilasci le connessioni esistenti. Dopo il periodo di drenaggio, se sono rimaste connessioni al database sui nodi originali, le connessioni rimanenti vengono disconnesse e viene avviata l'applicazione delle patch. Le procedure ottimali riportate di seguito consentono di garantire che le connessioni al database vengano prosciugate durante il periodo di drenaggio e riconnesse ai nuovi nodi, in modo che le applicazioni non vedano interruzioni durante una finestra di manutenzione.

Utilizzare un connection pool e ripristinare le connessioni al pool

Si consiglia di utilizzare un connection pool per nascondere la manutenzione pianificata dall'applicazione. L'esecuzione di un'applicazione durante la finestra di manutenzione non ha alcun impatto su un'applicazione quando l'applicazione esegue le operazioni riportate di seguito.

  • Utilizza un connection pool con le impostazioni consigliate.
  • Esegue il check-out di una connessione dal connection pool.
  • Utilizza la connessione per meno tempo di scarico (5 minuti).
  • Restituisce la connessione al connection pool.

La procedura consigliata per un'applicazione che utilizza un connection pool consiste nel seguire questi passi. L'applicazione esegue il check-out di una connessione, utilizza la connessione per l'elaborazione del database, quindi rilascia la connessione al connection pool immediatamente al termine del lavoro (ciò rende la connessione disponibile per l'uso da parte di altri thread).

Quando il periodo di svuotamento inizia, il connection pool gestisce il ripristino delle connessioni disponibili nel connection pool in modo che le nuove connessioni si connettano ai nuovi nodi disponibili. Quando un'applicazione esegue il check-out di una nuova connessione, non viene visualizzata alcuna interruzione (le nuove connessioni utilizzano i nuovi nodi). Tuttavia, se una connessione viene estratta prima dell'inizio della manutenzione o durante il tempo di scarico ed esegue un'elaborazione che continua per più del tempo di scarico, la connessione verrà disconnessa. In questo caso, per evitare interruzioni, è possibile arrestare tali operazioni con tempi di esecuzione lunghi prima dell'avvio della manutenzione e riavviarle al termine della manutenzione. Per sapere quando interrompere e quando riavviare le operazioni a lungo termine è possibile iscriversi agli eventi, come spiegato nella sezione seguente, "Iscriviti agli eventi informativi".

La tabella seguente mostra alcuni tipi di connection pool comuni e le versioni e le impostazioni consigliate.

Connection pool Versione Versione del driver Oracle JDBC Impostazioni consigliate
Universal Connection Pool (UCP) 23ai 23ai Utilizzare le impostazioni predefinite.
Universal Connection Pool (UCP) 19.12 o versione successiva 19.13 o versione successiva ValidateConnectionOnBorrow=true

Aggiungere oracle.jdbc.defaultConnectionValidation=LOCAL alle proprietà di connessione del driver JDBC.

Weblogic 14.1.1 o versione successiva 19.13 o versione successiva

test-connections-on reserve=true

test-table-name=SQL ISVALID

seconds-to-trust-an-idle-pool-connection=0

Applicare la patch per il bug 35731335. Per ulteriori informazioni, vedere Patch 35731335.

Hikari 6.0.0 o versione successiva 19.21 o versione successiva

Impostare com.zaxxer.hikari.aliveBypassWindowMs su -1.

Impostare oracle.jdbc.defaultConnectionValidation su SOCKET nelle proprietà JDBC.

Impostare com.zaxxer.hikari.enableRequestBoundaries su true.

Tomcat 9.0, 10.0, or 11.0 Qualsiasi versione

Se si utilizza Tomcat con UCP, seguire le raccomandazioni di UCP sopra riportate.

Se si utilizza Tomcat con il driver JDBC, chiamare qualsiasi API di drenaggio Oracle JDBC: isValid(), isUsable(), pingDatabase() o endRequest().

Impostare oracle.jdbc.defaultConnectionValidation su SOCKET nelle proprietà JDBC.

Utilizzare i test di connessione sul driver JDBC se non è possibile utilizzare un connection pool

Se non è possibile utilizzare un connection pool, i driver client Oracle 19.13 (o versioni successive) possono eliminare le connessioni in modo che l'applicazione non visualizzi interruzioni. Per assicurarsi che le connessioni vengano scaricate correttamente, è possibile chiamare qualsiasi API di drenaggio JDBC Oracle: isValid(), isUsable(), pingDatabase() o endRequest().

Iscriviti agli eventi informativi

Se nell'applicazione sono presenti operazioni di database con tempi di esecuzione lunghi che durano più di 5 minuti, il pool o il driver JDBC non possono eliminare le connessioni, in quanto non verranno rilasciate prima del termine del tempo di rimozione. Per operazioni con tempi di esecuzione così lunghi, per evitare interruzioni, non è consigliabile avviare i processi e i job durante o poco prima di una finestra di manutenzione.

Autonomous Database pubblica gli eventi informativi nel servizio OCI Events per ricevere notifiche sulle finestre di manutenzione, inclusi questi eventi informativi (con la manutenzione della categoria di eventi):

  • Quando è pianificata una nuova finestra di manutenzione
  • 24 ore prima dell'inizio dell'applicazione delle patch
  • 60 minuti prima dell'avvio dell'applicazione delle patch
  • All'avvio dell'applicazione delle patch
  • Al termine dell'applicazione delle patch

È possibile eseguire la sottoscrizione agli eventi informativi di Autonomous Database e, facoltativamente, specificare la manutenzione della categoria di eventi, ricevere notifiche e limitare le notifiche ricevute agli eventi di manutenzione. Quindi, in base alla notifica e alle regole definite, è possibile eseguire azioni per arrestare le operazioni con tempi di esecuzione lunghi e riavviarle al termine della manutenzione. Anche se le finestre di manutenzione annunciate sono di solito lunghe 2 ore, l'applicazione effettiva delle patch avviene in 5-10 minuti durante quella finestra. Utilizzando questi eventi e la conoscenza delle operazioni con tempi di esecuzione lunghi, è possibile determinare quando interrompere le operazioni con tempi di esecuzione lunghi e quando riavviarle.

Per ulteriori informazioni, vedere Usa eventi di Autonomous Database.

Gestisci stato sessione PL/SQL se l'applicazione utilizza PL/SQL

Il parametro di database SESSION_EXIT_ON_PACKAGE_STATE_ERROR specifica la gestione di un package PL/SQL con conservazione dello stato in esecuzione in una sessione. Quando un package viene modificato, ad esempio durante la manutenzione pianificata per gli oggetti forniti da Oracle, le sessioni in cui è stata creata un'istanza attiva del package ricevono il seguente errore quando tentano di eseguire il package: ORA-04068: existing state of packages has been discarded.. Tuttavia, il codice dell'applicazione che riceve l'errore ORA-4068 potrebbe non essere in grado di gestire questo errore con la logica dei nuovi tentativi.

L'impostazione di SESSION_EXIT_ON_PACKAGE_STATE_ERROR su TRUE fornisce una gestione diversa per questo caso. Quando SESSION_EXIT_ON_PACKAGE_STATE_ERROR è TRUE, invece di generare l'errore ORA-4068 quando lo stato del pacchetto viene eliminato, la sessione esce immediatamente. Questo può essere vantaggioso perché molte applicazioni possono gestire l'interruzione della sessione ristabilendo automaticamente e in modo trasparente la connessione.

Per ulteriori informazioni, vedere SESSION_EXIT_ON_PACKAGE_STATE_ERROR.


Legenda nota a piè di pagina

Nota a piè di pagina 1: Si noti che questo tempo di drenaggio può cambiare nelle versioni future.