Visualizza informazioni su patch e finestra di manutenzione, Imposta livello patch
Autonomous Database utilizza finestre di manutenzione predefinite per applicare automaticamente le patch al database. È possibile visualizzare le informazioni sulla manutenzione e sulle patch e visualizzare i dettagli per la cronologia della manutenzione di Autonomous Database.
- Informazioni sulla manutenzione pianificata e sull'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. - Visualizza cronologia eventi di manutenzione
È possibile visualizzare la cronologia degli eventi di manutenzione di Autonomous Database per i dettagli sugli eventi di manutenzione passati, ad esempio il titolo, lo stato, l'ora di inizio e l'ora di arresto. - Visualizza il livello di patch e i dettagli delle patch
È possibile visualizzare le informazioni sulle patch di Autonomous Database, incluso un elenco di problemi e componenti risolti. - Impostare il livello di patch
Quando si esegue il provisioning o si duplica un'istanza di Autonomous Database, è possibile 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 a livello di patch: Regular e Early. - Visualizza notifiche stato manutenzione
Nella vistaDB_NOTIFICATIONS
vengono memorizzate informazioni sulle notifiche dello stato di manutenzione per l'istanza di Autonomous Database. - Best practice 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.
Informazioni sulla manutenzione pianificata e sull'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 di 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, quindi non è necessario tenere traccia delle patch singole. Dopo aver implementato una correzione per un problema, ad esempio un problema riscontrato in un database, la correzione viene distribuita a 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 di integrazione e sviluppo continua. Le correzioni vengono convalidate in più fasi e ambienti prima di essere distribuite nei database a livello di patch Early e Always Free, seguiti dai database a livello di patch Regular. 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 sottoinsieme 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.
Rilevamento automatico delle regressioni per Autonomous Database ⁇ fornisce una gestione proattiva delle regressioni e consente il rilevamento, la diagnosi e la mitigazione automatizzati dei problemi. ⁇ Questo può ridurre o eliminare la necessità di analizzare manualmente i problemi e le richieste di servizio di file. ⁇ Rilevamento automatico delle regressioni monitora tutti i database, in entrambi i livelli di patch Early e Regular, ma è particolarmente utile quando si sottopone a test un carico di lavoro su un database di livello ⁇ Early ⁇ patch. ⁇ Se Automatic Regression Detection rileva un problema e identifica una regressione, segnala automaticamente il problema con informazioni dettagliate per diagnosticarlo. Questo reporting automatizzato, nell'ambito del ciclo di applicazione continua delle patch, consente a Oracle di mitigare o risolvere il problema prima che le modifiche raggiungano i database di produzione (Database a livello di patch). Rilevamento automatico della regressione potrebbe non essere in grado di trovare ogni problema; nei casi in cui si riscontrano problemi, è possibile presentare una richiesta di servizio.
Il rilevamento automatico della regressione include quanto segue:
-
Il rilevamento automatico della regressione monitora il database e, in caso di incidente, archivia 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 di Oracle Cloud Infrastructure Operations and Development 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.
Nella pagina Dettagli di Autonomous Database vengono visualizzati il campo Livello di patch e il campo Manutenzione successiva che include la data e l'ora della 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.

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 a livello di patch: Regular e Early. Fare clic su Modifica per gestire le impostazioni a livello di patch. Per ulteriori informazioni, vedere Impostare il livello 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. Di seguito sono riportati i valori possibili.
|
Manutenzione successiva (peer locale) |
Specifica il periodo di tempo per la successiva finestra di manutenzione pianificata per un 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. Di seguito sono riportati i valori possibili.
|
Contatti cliente |
Quando i contatti dei clienti sono impostati, Oracle invia 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 operativi e annunci. |
Note per la manutenzione pianificata e l'applicazione di patch:
-
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 è in stato arrestato durante la finestra di manutenzione, le modifiche apportate al database dalla patch vengono applicate quando si avvia il database.
-
Il database rimane disponibile durante la finestra di manutenzione. Le nuove connessioni al database avranno sempre successo. Le connessioni al database esistenti potrebbero essere 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 disconnettersi se sono in esecuzione più a lungo del tempo di rimozione dopo l'avvio dell'applicazione delle patch.
-
Per le patch dell'infrastruttura, le connessioni esistenti potrebbero disconnettersi se sono in esecuzione più a lungo del tempo di rimozione dopo l'avvio dell'applicazione delle patch.
-
Per le patch del dizionario, le connessioni esistenti potrebbero disconnettersi se bloccano gli oggetti del dizionario a cui viene applicata la patch. In caso contrario, non saranno interessate le connessioni esistenti. Ad esempio, se l'applicazione sta eseguendo una procedura nel pacchetto
DBMS_CLOUD
durante l'applicazione delle patch e è necessario applicare le patch al pacchetto, la sessione che utilizza tale pacchetto potrebbe disconnettersi.Per ulteriori informazioni, vedere SESSION_EXIT_ON_PACKAGE_STATE_ERROR.
-
-
Puoi utilizzare Oracle Cloud Infrastructure Events per ricevere una notifica quando inizia e termina la manutenzione. Per ulteriori informazioni, consulta la sezione relativa agli eventi informativi su Autonomous Database.
-
Se si desidera modificare la finestra di manutenzione assegnata in un'altra finestra di 2 ore 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 presentando una richiesta di servizio al Supporto Oracle Cloud (ovvero, è possibile presentare 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 su 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.
Per i dettagli sull'SLO a regressione zero per Autonomous Database, consulta l'obiettivo del livello di servizio a zero regressioni.
Visualizza cronologia eventi manutenzione
È possibile visualizzare la cronologia degli eventi di manutenzione di Autonomous Database per i dettagli sugli eventi di manutenzione passati, ad esempio il titolo, lo stato, l'ora di inizio e l'ora di arresto.
Eseguire i passi dei prerequisiti riportati di seguito, se necessario.
-
Apri la console di Oracle Cloud Infrastructure facendo clic su
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 della manutenzione, effettuare le operazioni riportate di seguito.
Campo | Descrizione |
---|---|
Titolo |
Il nome dell'evento di manutenzione. |
Tipo di manutenzione |
Pianificato o non pianificato. |
Componente di destinazione |
Il tipo di risorsa in cui si verifica l'evento di manutenzione: Database, Dizionario o Infrastruttura. |
Stato |
Riuscito, Non riuscito o In corso. |
Ora di inizio |
Ora di inizio manutenzione. |
Ora di fine |
Ora di fine manutenzione. |
La cronologia degli eventi di manutenzione è disponibile a partire dagli eventi di manutenzione successivi a febbraio 2021.
Visualizza livello patch e dettagli patch
Puoi visualizzare le informazioni sulle patch di Autonomous Database, inclusa una lista di problemi e componenti risolti.
Visualizza livello patch per un'istanza di Autonomous Database
Dalla pagina dei dettagli di Autonomous Database della console di Oracle Cloud Infrastructure, puoi visualizzare il livello di patch per l'istanza.
- Nella scheda Informazioni su Autonomous Database, l'area Manutenzione mostra il livello di patch dell'istanza. Le scelte sono: Regolare e Precoce.
- Per modificare il livello di patch, fare clic su Modifica.
Per ulteriori informazioni, vedere Impostare il livello patch.
La vista DBA_CLOUD_PATCH_INFO
fornisce informazioni sulle patch relative ai bug segnalati (questo è un elenco di bug segnalati da un cliente). È possibile utilizzare queste informazioni per determinare se un bug segnalato è stato corretto e per determinare la versione della patch in cui la correzione è stata applicata all'istanza di Autonomous Database. Se non sono presenti bug dei clienti in una patch, 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.
Per visualizzare le informazioni sulle patch per tutte le patch disponibili:
SELECT * FROM DBA_CLOUD_PATCH_INFO;
Note per la visualizzazione delle informazioni sulla patch:
-
La vista
DBA_CLOUD_PATCH_INFO
è disponibile per l'utente ADMIN. -
Le informazioni sulle patch e i dettagli sui problemi risolti sono disponibili da
ADBS-21.7.1.1
in poi (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 duplichi 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 a livello di patch: Regular e Early.
Quando si seleziona il livello di patch Prima, 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 la data e l'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 testare le patch imminenti prima che vengano applicate a tutti i sistemi. Oracle consiglia di selezionare il livello di patch Precedente 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 testare i tuoi 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 Prima. Per ulteriori informazioni, vedere Test dei carichi di lavoro con Oracle Real Application Testing.
L'impostazione del livello di patch è disponibile solo su un'istanza di Autonomous Database che utilizza il modello di computazione ECPU.
-
Se si esegue il provisioning di una nuova istanza, seguire le istruzioni di provisioning e selezionare il livello di patch, Regolare o Prima. Per ulteriori informazioni, vedere Eseguire il provisioning di un'istanza di Autonomous Database.
-
Se si duplica un'istanza, seguire le istruzioni per la clonazione e selezionare un livello di patch, Regolare o Prima. Per ulteriori informazioni, vedere Duplica un'istanza di Autonomous Database.
Per modificare il livello di patch per un Autonomous Database esistente, effettuare le operazioni riportate di seguito.
- Nella pagina Dettagli Autonomous Database, in Manutenzione, nel campo Livello patch fare clic su Modifica.
Nota
Il pulsante Modifica può essere disabilitato nelle seguenti circostanze:- Se il livello di patch in anticipo non è disponibile nella propria area per la versione del database.
- Se nel database è abilitato Autonomous Data Guard.
- Se il database è a livello di patch iniziale e non è possibile spostarlo a livello di patch normale. In questo caso, si consiglia di riprovare dopo la finestra di manutenzione successiva.
- Selezionare il livello di patch Regolare o Prima, quindi fare clic su Sottometti.
Il tempo necessario per modificare il livello di patch dipende dalle dimensioni del database. Durante questo periodo è possibile che venga visualizzato un breve calo della connessione.
Segnalazione di problemi di patch al Supporto Oracle
Quando si segnala un problema per un database a livello di patch precedente, il Supporto Oracle intraprende le azioni necessarie per impedire la propagazione del problema ai database a livello di patch regolare. Alcuni esempi delle possibili azioni sono:
-
La patch che ha causato il problema viene rimossa prima che vengano applicate le 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 di patch ai database a livello di patch regolare viene sospesa fino a quando non vengono intraprese azioni correttive.
In caso di problema da segnalare, inoltrare una richiesta di assistenza al Supporto Oracle Cloud o contattare il rappresentante dell'assistenza.
Oracle fornisce un obiettivo del livello di servizio pari a zero regressioni nel database di produzione. Per ulteriori informazioni, vedere Obiettivo livello di servizio zero regressioni.
Note per il livello di applicazione delle patch:
-
L'opzione per impostare il livello di patch non è disponibile in ogni area. In alcune aree viene eseguito il provisioning o la copia di tutte le istanze di Autonomous Database a livello di patch Regolare.
-
Autonomous Data Guard è disponibile solo per le istanze con livello di patch Regolare. Quando configuri un'istanza di Autonomous Database con livello di patch prima, non puoi abilitare Autonomous Data Guard.
-
Le istanze di Autonomous Database Sempre gratis non forniscono l'opzione a livello di patch Prima.
-
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 informazioni sulle notifiche dello stato di manutenzione per l'istanza di Autonomous Database.
Per visualizzare le informazioni di notifica:
Di seguito sono riportati i dettagli relativi ai valori dei campi DESCRIPTION
.
-
L'esecuzione della manutenzione è terminata: specifica che la manutenzione è stata completata. Il valore
MAINTENANCE_STATUS
mostra il valoreCOMPLETED
con gli indicatori orari di inizio e fine per la manutenzione completata inACTUAL_START_DATE
eACTUAL_END_DATE
. -
L'esecuzione della manutenzione è pianificata per l'istanza: specifica che è stata pianificata una nuova manutenzione. Il valore
MAINTENANCE_STATUS
mostra il valoreSCHEDULED
con gli indicatori orari di inizio e fine previsti per la manutenzione pianificata inEXPECTED_START_DATE
eEXPECTED_END_DATE
. -
L'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 valoreIN_PROGRESS
eACTUAL_START_DATE
memorizza l'indicatore orario di inizio.
La tabella seguente mostra le colonne e i tipi di dati DB_NOTIFICATIONS
.
Colonna | Tipo di dati | Descrizione |
---|---|---|
TYPE |
VARCHAR2(128) |
Specifica il tipo di notifica. Il valore valido è: |
TIME |
TIMESTAMP(6) WITH TIME ZONE |
Ora di aggiunta della voce di notifica. |
EXPECTED_START_DATE |
TIMESTAMP(6) WITH TIME ZONE |
Ora inizio manutenzione schedulata. |
EXPECTED_END_DATE |
TIMESTAMP(6) WITH TIME ZONE |
Ora fine manutenzione pianificata. |
ACTUAL_START_DATE |
TIMESTAMP(6) WITH TIME ZONE |
Ora inizio manutenzione effettiva. |
ACTUAL_END_DATE |
TIMESTAMP(6) WITH TIME ZONE |
Ora 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 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 |
Weblogic | 14.1.1 o versione successiva | 19.13 o versione successiva |
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 Impostare Impostare |
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: Impostare |
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.