Manutenzione del servizio di Autonomous Database sull'infrastruttura Exadata dedicata

Tipi di manutenzione servizio

Oracle pianifica ed esegue diverse attività di manutenzione del servizio su Autonomous Database. Questi eventi di manutenzione variano a seconda dell'ambito e della frequenza di applicazione delle patch.

Il team Cloud Operations di Oracle monitora continuamente l'applicazione delle patch ed esegue un rollback se una patch non supera i test di integrità di base. Se è necessario un rollback, la manutenzione verrà ripianificata. Sebbene il rollback sia l'ultima opzione, il nostro obiettivo è sempre quello di fornire la soluzione più rapida per ripristinare lo stato del database in buono stato. Se una regressione viene visualizzata solo all'interno dell'applicazione, è necessario segnalarla tramite una richiesta di servizio (SR, service request). Per i problemi critici che richiedono attenzione immediata, Oracle può sviluppare e distribuire una patch singola al di fuori della pianificazione di manutenzione standard.

Patch di manutenzione trimestrale: in generale, Oracle pianifica ed esegue l'intera manutenzione della flotta in ogni trimestre.
- Le patch di manutenzione trimestrali vengono applicate a vari livelli di risorsa, ad esempio l'infrastruttura Exadata, il cluster VM Autonomous Exadata (AVMC) e l'Autonomous Container Database (ACD). La finestra di manutenzione trimestrale può essere impostata durante la creazione di queste risorse dell'infrastruttura o modificata in un secondo momento.
- È possibile consentire a Oracle di gestire la pianificazione della manutenzione oppure impostare una finestra di manutenzione specifica quando Oracle può iniziare le operazioni di manutenzione.
- Per impostazione predefinita, Oracle applica gli aggiornamenti delle release (RU) insieme a queste patch di manutenzione trimestrali. È possibile configurare per aggiornare RU in un metodo di manutenzione in sequenza o non in sequenza.
  - Il metodo Rolling aggiorna l'ACD, un nodo alla volta, senza tempi di inattività per gli Autonomous Database.
  - Il metodo Non in sequenza si arresta e aggiorna l'ACD in parallelo in tutti i nodi. Questo metodo riduce al minimo i tempi di manutenzione, ma richiede tempi di inattività completi per l'ACD e tutti gli Autonomous Database associati.
    
    Nota
    In una configurazione Autonomous Data Guard, il metodo di manutenzione non in sequenza determina tempi di inattività per gli ACD primari e in standby durante la rispettiva finestra di manutenzione fino al completamento dell'applicazione delle patch.
- È inoltre possibile includere il file del fuso orario da aggiornare insieme all'IF. Le patch di manutenzione trimestrali che includono un aggiornamento del file del fuso orario richiederebbero un tempo di inattività completo per ACD e per gli Autonomous Database associati. Il tempo di inattività dipende dalla quantità di dati sensibili al fuso orario.
- Le patch di manutenzione trimestrali senza un aggiornamento del file del fuso orario possono essere applicate in sequenza o in modalità non in sequenza, a seconda della configurazione di manutenzione dell'Autonomous Container Database (ACD).
Patch di sicurezza mensili:
- Patch di sicurezza dell'infrastruttura Exadata: Oracle pianifica ed esegue un'attività di manutenzione mensile della sicurezza dell'infrastruttura insieme alla manutenzione trimestrale. Tuttavia, queste patch di sicurezza vengono applicate solo in quei mesi con aggiornamenti di sicurezza critici, incluse le correzioni per le vulnerabilità con punteggi CVSS superiori o uguali a 7.
  - Qualsiasi infrastruttura Exadata di cui è stato eseguito il provisioning prima che Oracle pianifichi la manutenzione della sicurezza sarà idonea per la manutenzione della sicurezza.
  - Il processo mensile di manutenzione della sicurezza aggiorna i database server per correggere vulnerabilità critiche della sicurezza e problemi dei prodotti. Inoltre, aggiornano i server di storage in un'immagine software di storage Exadata che risolve le vulnerabilità di sicurezza note e i problemi del prodotto.
- Patch di sicurezza del cluster VM Autonomous: Oracle esegue la manutenzione mensile della sicurezza per i cluster VM Autonomous oltre agli aggiornamenti trimestrali regolari. Queste patch sono applicabili solo per le aree GOV.
  - Le patch di sicurezza mensili vengono applicate usando il metodo in sequenza.
  - Il primo mese di ogni trimestre include patch trimestrali; i due mesi seguenti includono patch di sicurezza mensili.
  - Per garantire l'applicazione delle patch, è necessario selezionare tutti e tre i mesi del trimestre e specificare una preferenza per la settimana 3 e/o la settimana 4.
Patch una tantum: Oracle genera patch una tantum per le richieste di supporto critiche inviate a My Oracle Support. Per informazioni sull'archiviazione di una richiesta di supporto, vedere Create a Service Request in My Oracle Support.
- Quando l'utente e Oracle concordano che una richiesta di servizio è fondamentale e richiede una patch singola per la risoluzione immediata, il team del servizio genera una patch singola e la rende disponibile. Le patch singole sono separate dalle patch di manutenzione pianificate.
- Se consenti a notifiche ed eventi di Oracle Cloud con una regola di ricevere notifiche relative a nuovi aggiornamenti, quando le patch una tantum diventano disponibili, Oracle invia una notifica contenente l'OCID del prodotto a cui applicare le patch. In caso contrario, è possibile trovare l'avviso di disponibilità dell'aggiornamento nel portale My Oracle Support per la richiesta di supporto inviata.
- Le patch una tantum vengono unite nel prossimo aggiornamento della release (RU) per garantire che:
  - Una soluzione unica fornita per un determinato cliente è disponibile per tutti i clienti.
  - Le versioni successive non devono applicare di nuovo patch singole.
- Se necessario, un'RU può avere più patch una tantum unite ad essa. A partire dalla release corrente, le patch singole non sono cumulative, pertanto è necessario applicarle singolarmente. Se una patch singola è troppo vicina all'aggiornamento release successiva, viene creata una versione personalizzata dell'aggiornamento release (RU) con la correzione singola per il trimestre successivo.
- Si supponga di aver pianificato una correzione singola che non viene unita all'aggiornamento release più recente e di aver scelto di applicare l'aggiornamento release successiva. Quindi, Oracle annulla la patch singola pianificata. È possibile visualizzare le esecuzioni di manutenzione annullate nella cronologia di manutenzione. Tutti i dettagli di applicazione patch singola registrati nella cronologia di manutenzione sono disponibili nei download e nei servizi di audit e log.
- Se necessario, è possibile eseguire il rollback di una patch singola tramite una richiesta di servizio.
- Il numero di patch singole disponibili per un Autonomous Container Database viene visualizzato nella relativa pagina Dettagli. Se si fa clic sul collegamento Copia accanto, vengono copiati tutti i numeri di patch singola.

Specifica quando può verificarsi la manutenzione

In generale, Oracle pianifica ed esegue l'intera manutenzione della flotta in ogni trimestre e correzioni mensili alla sicurezza dell'infrastruttura per le vulnerabilità con punteggi CVSS maggiori o uguali a 7. È possibile consentire a Oracle di gestire la pianificazione della manutenzione oppure impostare una finestra di manutenzione specifica quando Oracle può iniziare le operazioni di manutenzione.

Personalizzazione della manutenzione trimestrale

Puoi scegliere una pianificazione per la manutenzione automatica trimestrale delle risorse di Autonomous Database o lasciare che Oracle pianifichi automaticamente gli aggiornamenti. Oracle ti notifica in anticipo la data e l'ora dell'imminente manutenzione pianificata.

È possibile eseguire le operazioni riportate di seguito con la manutenzione trimestrale automatica a vari livelli di risorsa, come indicato nella tabella riportata di seguito.

Personalizzare le preferenze e la pianificazione di manutenzione automatica. È possibile impostare queste preferenze durante il provisioning delle risorse di Autonomous Database o modificarle in un secondo momento.
Visualizzare e modificare la pianificazione in qualsiasi momento prima dell'inizio della manutenzione pianificata. Le modifiche apportate alla manutenzione pianificata per i trimestri successivi non influiscono sulla pianificazione per il trimestre corrente.
Visualizzare gli eventi di manutenzione precedenti.

Risorsa infrastruttura	Note e ulteriori riferimenti
Infrastruttura Exadata (EI)	Modificare la pianificazione della manutenzione di una risorsa dell'infrastruttura Exadata. Sono disponibili varie opzioni per personalizzare la pianificazione della manutenzione, come spiegato in Impostazioni nella pianificazione della manutenzione personalizzabili. Visualizzare e gestire la manutenzione pianificata di una risorsa dell'infrastruttura Exadata Visualizza manutenzione precedente di una risorsa dell'infrastruttura Exadata
Cluster VM Autonomous Exadata (AVMC)	Modificare la pianificazione di manutenzione di un cluster VM Autonomous Exadata. Sono disponibili varie opzioni per personalizzare la pianificazione della manutenzione, come illustrato in Impostazioni nella pianificazione della manutenzione personalizzabili. Visualizzare e gestire la manutenzione pianificata di un cluster VM Autonomous Exadata Visualizzare la manutenzione precedente di un cluster VM Autonomous Exadata Nota Le risorse AVMC di cui è stato eseguito il provisioning sulle risorse dell'infrastruttura Exadata in Oracle Cloud prima dell'avvio delle più funzioni di database autonomi VM ereditano la pianificazione della manutenzione dall'infrastruttura Exadata associata.
Autonomous Container Database (ACD)	Aggiornare le preferenze di manutenzione di Autonomous Container Database mostra come aggiornare le seguenti preferenze: Metodo di manutenzione per gli aggiornamenti automatici (in sequenza o non in sequenza). È inoltre possibile includere il file time-zone da aggiornare insieme all'RU. Nota In una configurazione Autonomous Data Guard, il metodo di manutenzione non in sequenza determina tempi di inattività per gli ACD primari e in standby durante la rispettiva finestra di manutenzione fino al completamento dell'applicazione delle patch. Versione di manutenzione per gli aggiornamenti automatici (RU successiva o RU più recente). Pianificazione di manutenzione automatica per l'ACD. Sono disponibili varie opzioni per personalizzare la pianificazione della manutenzione, come illustrato in Impostazioni nella pianificazione della manutenzione personalizzabili. Nota Non è possibile definire una pianificazione personalizzata per un ACD in standby in una configurazione Autonomous Data Guard. Tuttavia, puoi impostare il numero di giorni durante i quali la manutenzione ACD in standby verrà pianificata prima della manutenzione ACD primaria perché le patch ACD in standby vengono sempre applicate prima dell'ACD primario. È inoltre possibile pianificare una manutenzione su richiesta per aggiornare l'aggiornamento dell'aggiornamento release (RU) insieme al file del fuso orario o solo al file del fuso orario per un ACD. Per istruzioni, vedere Programmazione di un aggiornamento di manutenzione trimestrale. Nota Solo in caso di aggiornamenti dei file del fuso orario su richiesta, le patch all'ACD in standby verranno applicate 3 giorni prima dell'ACD primario negli ACD abilitati per Autonomous Data Guard. Visualizzare e gestire la manutenzione pianificata di un Autonomous Container Database Visualizza la manutenzione precedente di un Autonomous Container Database

Suggerimento

Oracle consiglia di impostare una finestra di manutenzione per tutte le risorse dell'infrastruttura elencate sopra in modo da:

Impedire che si verifichino operazioni di manutenzione a volte che potrebbero interrompere le normali operazioni del database.
Applica patch alle risorse dell'infrastruttura in modo sfalsato. Lo sfalsamento degli eventi di manutenzione per diverse risorse dell'infrastruttura è una best practice che può aiutarti a verificare la patch su un set di risorse prima di applicarne un'altra. Ad esempio, quando si utilizzano Autonomous Container Database diversi per lo sviluppo e il test e si desidera verificare le patch nell'ambiente di sviluppo prima di applicarle alla produzione, è possibile personalizzarne le pianificazioni di manutenzione in modo che tutte le patch ACD di sviluppo vengano applicate prima delle ACD di produzione.

Impostazioni nella pianificazione manutenzione personalizzabili

Puoi scegliere i seguenti dettagli dalla console di Oracle Cloud Infrastructure durante la definizione di una pianificazione personalizzata per una qualsiasi delle risorse dell'infrastruttura di cui sopra.

Mesi consentiti: è necessario selezionare almeno un mese al trimestre, nonché scegliere di saltare l'applicazione delle patch per un trimestre. Impossibile ignorare l'applicazione delle patch per due trimestri consecutivi.

Nota
Quando si sceglie di saltare, è necessario selezionare almeno un mese da tale trimestre. Questa operazione funge da fallback nel caso in cui la manutenzione non si sia verificata nel precedente trimestre non ignorato. In questo scenario, Oracle eseguirà automaticamente la manutenzione nel mese selezionato, anche se si sceglie di saltare per tale trimestre.
Settimana (o Settimane) entro i mesi selezionati: le settimane iniziano il 1°, 8°, 15° e 22° giorno del mese e hanno una durata di 7 giorni. Le settimane iniziano e terminano in base alle date del calendario, non ai giorni della settimana. La manutenzione non può essere pianificata per la quinta settimana di mesi che contengono più di 28 giorni. Se non si specifica una settimana del mese, Oracle assegnerà automaticamente una settimana.
Giorno (o giorni) della settimana selezionata:

Se non si specifica un giorno della settimana, Oracle eseguirà l'aggiornamento di manutenzione in un giorno assegnato automaticamente.

Man mano che le settimane iniziano e finiscono in base alle date del calendario e non ai giorni della settimana, devi prestare maggiore attenzione durante la scelta dei giorni se desideri garantire una sequenza specifica nell'applicazione delle patch all'infrastruttura Exadata (EI). Ad esempio, osservare i due mesi indicati di seguito:

Descrizione dell'immagine dayofweek.png

Descrizione dell'immagine dayofweek2.png
Per settembre 2023, la settimana 1 inizia di venerdì e termina di giovedì. Quindi, il suo primo sabato arriva un giorno prima della sua prima domenica. Tuttavia, la settimana 1 di ottobre 2023 inizia di domenica e termina di sabato. Di conseguenza, il suo primo sabato viene cinque giorni dopo la prima domenica.

Si supponga di voler applicare le patch a tutte le risorse dell'infrastruttura Exadata prima di applicare le patch agli Autonomous Container Database (ACD) per mantenere una sequenza specifica per la manutenzione. Pianificazione della manutenzione della risorsa dell'infrastruttura Exadata nella settimana 1 di sabato e dei relativi ACD nella settimana 1 di domenica, supponendo che la settimana 1 di domenica venga sempre un giorno dopo la settimana 1 di sabato può funzionare per alcuni mesi, ad esempio settembre 2023, ma non per altri, come ottobre 2023. Se si desidera implementare una sequenza specifica per l'applicazione delle patch, è preferibile spaziarle entro una settimana. In questo caso, è possibile pianificare la risorsa dell'infrastruttura Exadata nella settimana 1 di sabato e i relativi ACD nella settimana 2 di domenica. In questo modo, la risorsa dell'infrastruttura Exadata verrà sempre verificata prima di applicare le patch ai relativi ACD.
Finestra 4 ore (o Windows) quando è possibile avviare le operazioni di manutenzione.
Periodo buffer tra manutenzione primaria e in standby: numero di giorni tra la manutenzione ACD in standby e la manutenzione ACD primaria, ovvero quanti giorni prima dell'esecuzione della manutenzione nel container database primario deve essere eseguita la manutenzione nel container database in standby. È possibile scegliere qualsiasi valore da 1 a 7 giorni.

La selezione del periodo del buffer è applicabile solo ad Autonomous Container Database che è il database primario in una configurazione Autonomous Data Guard.
Lead time: numero minimo di settimane prima dell'evento di manutenzione a cui si desidera ricevere un messaggio di notifica. Il lead time garantisce che un aggiornamento di manutenzione appena rilasciato sia pianificato per tenere conto del periodo minimo richiesto di notifica avanzata.
Il lead time non è applicabile per la manutenzione delle risorse di Autonomous Container Database.
È possibile ripristinare le impostazioni predefinite selezionando Ripristina impostazioni predefinite.

Personalizzazione della manutenzione mensile della sicurezza dell'infrastruttura

La manutenzione mensile della sicurezza dell'infrastruttura, se necessario, è pianificata per essere applicata durante una finestra di 21 giorni che inizia tra il 18 e il 21 di ogni mese e verrà eseguita fino al 9 e al 12 del mese successivo. Si riceverà una notifica della pianificazione proposta almeno 7 giorni prima dell'inizio della finestra di manutenzione mensile ed è possibile ripianificare la manutenzione mensile fino a un'altra data nella finestra, se lo si desidera.

Le patch di sicurezza mensili possono essere ripianificate a un'altra ora all'interno della finestra di manutenzione, ma non possono essere saltate o ripianificate oltre la finestra di 21 giorni. È possibile rischedulare la manutenzione di sicurezza mensile durante la rischedulazione della manutenzione trimestrale a condizione di mantenere la manutenzione mensile entro la finestra di manutenzione corrente.

Non vi è alcun impatto sugli Autonomous Database o sulle applicazioni ad essi connesse durante l'attività mensile di applicazione delle patch di sicurezza dell'infrastruttura. Gli aggiornamenti ai database server vengono applicati online tramite la tecnologia Ksplice e gli aggiornamenti agli storage server vengono applicati in sequenza.

Tuttavia, durante l'aggiornamento dell'infrastruttura del servizio, Oracle potrebbe bloccare alcune operazioni, tra cui il ridimensionamento della memoria e dello storage, l'applicazione di patch al sistema operativo e a Grid Infrastructure (inclusi i controlli preliminari) e l'espansione elastica dei server di calcolo e storage. Pianificare di differire queste operazioni fino al completamento degli aggiornamenti. L'applicazione degli aggiornamenti di sicurezza richiede circa 15 minuti per ogni host DB server, più 60 minuti per ogni server di storage, a seconda dell'attività di I/O. Se si tenta un'operazione interessata, la console invierà una notifica degli aggiornamenti di sicurezza in corso. Non viene aggiornato alcun software nelle VM guest.

Personalizzazione delle patch singole

La vista Manutenzione della console di Oracle Cloud consente di modificare l'ora di inizio pianificata o di scegliere di installare immediatamente la patch singola. Per impostazione predefinita, Oracle pianifica l'applicazione di una patch singola entro 72 ore dalla disponibilità della patch. Se non viene eseguita alcuna azione per modificare la pianificazione, la patch viene applicata automaticamente. È possibile ripianificare le patch singole solo nel trimestre corrente. Tuttavia, non è possibile saltare del tutto una patch singola.

Specificare il tipo di patch da applicare

Una delle operazioni di manutenzione standard consiste nell'applicare le patch del software del database agli Autonomous Container Database e, per estensione, agli Autonomous Database creati in essi. Per impostazione predefinita, Oracle applica gli aggiornamenti delle release (RU). È possibile configurare il tipo di manutenzione su RU successiva per aggiornare Autonomous Container Database all'aggiornamento della release successiva oppure su RU più recente per aggiornare Autonomous Container Database all'aggiornamento della release più recente nella finestra di manutenzione successiva. Di conseguenza, Oracle utilizzerà un tipo di immagine che soddisfi le tue preferenze quando disponibile. Quando si desidera, è sempre possibile modificare una determinata patch pianificata in una versione diversa.

Per istruzioni dettagliate, vedere Aggiorna preferenze di manutenzione di Autonomous Container Database.

Visualizza e gestisci manutenzione già pianificata

Una volta pianificata un'attività di manutenzione in base alla finestra di manutenzione impostata, è possibile gestire la tempistica effettiva dell'attività, anche al punto di modificare la versione della patch, applicare immediatamente la patch o saltare l'attività.

Dettagli manutenzione pianificata

Per ogni evento di manutenzione pianificato di Exadata Infrastructure, Autonomous Exadata VM Cluster o Autonomous Container Database, la pagina Manutenzione della risorsa elenca i dettagli riportati di seguito.

Stato dell'evento
Tipo di evento, settimanale, trimestrale, mensile o annuale
OCID dell'evento
L'ora e la data di inizio schedulate dell'evento
Metodo di manutenzione dell'evento In sequenza su non in sequenza. Viene visualizzata solo per una risorsa dell'infrastruttura Exadata.
La versione della patch da applicare all'evento. Viene visualizzata solo per una risorsa di Autonomous Container Database.

Operazioni di gestione su una manutenzione pianificata

Per ogni evento di manutenzione elencato in una pagina di manutenzione delle risorse dell'infrastruttura, è possibile eseguire le operazioni di gestione riportate di seguito, a condizione che l'evento non sia già in corso.

Ripianificare l'ora e la data di inizio dell'evento in un'ora successiva del trimestre. Specificare la nuova data e ora di inizio nella finestra Modifica ora di inizio manutenzione.
Avviare immediatamente l'evento di manutenzione facendo clic su Applica patch ora.

Nota
L'opzione Applica patch ora non è disponibile per un Autonomous Database abilitato con Autonomous Data Guard. Come soluzione alternativa, è possibile modificare l'ora di manutenzione pianificata per iniziare nel periodo di 4 ore disponibile più vicino. Assicurarsi che venga applicata una patch al database di standby prima del database primario con un periodo di buffer compreso tra 1 e 7 giorni.
Saltare un evento di manutenzione pianificata di Autonomous Container Database.

Nota
Non è possibile saltare due eventi di manutenzione consecutivi. Dopo aver saltato un evento di manutenzione, non è possibile saltare il successivo evento di manutenzione programmata immediata; è possibile saltare gli eventi di manutenzione solo per due trimestri alternativi in un anno.
Selezionare una versione patch diversa da applicare. Quando si seleziona una versione, tenere presente:
- Selezionare una versione successiva alla versione corrente di Autonomous Container Database.
- La lista delle versioni disponibili può contenere sia gli aggiornamenti di release (RU) che la revisione degli aggiornamenti di release (RUR). È possibile scegliere uno dei due tipi, indipendentemente dal tipo di manutenzione configurato per l'Autonomous Container Database. La selezione di un tipo diverso nella lista Versione non modifica il tipo configurato per l'Autonomous Container Database.
Aggiornare il metodo di manutenzione dell'infrastruttura Exadata da In sequenza a Non in sequenza e viceversa.

Per una guida dettagliata, vedere:

Accodamento automatico degli eventi di manutenzione

Eventi di manutenzione trimestrali di diverse risorse di Autonomous Database

Se scegli una pianificazione di manutenzione personalizzata per qualsiasi risorsa dell'infrastruttura, Oracle rispetta la tua preferenza durante la pianificazione degli eventi di manutenzione. Tuttavia, se la pianificazione personalizzata crea sovrapposizioni con altre risorse dell'infrastruttura, Oracle serializza automaticamente in modo che gli eventi di manutenzione vengano eseguiti in questa sequenza con un certo intervallo di tempo tra loro: infrastruttura Exadata, cluster VM Autonomous Exadata e Autonomous Container Database.

Esempio: si supponga che un evento di manutenzione delle risorse dell'infrastruttura Exadata e un evento di manutenzione di Autonomous Container Database vengano pianificati per l'avvio simultaneo. In questo caso, viene avviato l'evento di manutenzione delle risorse dell'infrastruttura Exadata e l'evento di manutenzione di Autonomous Container Database viene inserito nella coda e inizia subito dopo l'evento di manutenzione delle risorse dell'infrastruttura Exadata.

Eventi di manutenzione trimestrali e patch di sicurezza dell'infrastruttura mensili

Scenario	Coda
Quando viene pianificata un'attività di manutenzione trimestrale all'interno di 24hours di una patch di sicurezza dell'infrastruttura mensile.	La manutenzione mensile pianificata verrà saltata e applicata immediatamente dopo la manutenzione trimestrale.
Quando viene pianificata un'attività di manutenzione trimestrale contemporaneamente a una patch di sicurezza mensile dell'infrastruttura.	La manutenzione trimestrale verrà eseguita per prima e la patch di sicurezza mensile verrà applicata immediatamente dopo il completamento della manutenzione trimestrale.
Quando una patch di sicurezza mensile dell'infrastruttura è pianificata per iniziare con 0-24 ore di anticipo rispetto alla manutenzione trimestrale.	La manutenzione mensile pianificata rimarrà in attesa e verrà eseguita immediatamente dopo la manutenzione trimestrale. Se la manutenzione trimestrale viene successivamente ripianificata, la manutenzione di sicurezza mensile inizierà immediatamente. Oracle consiglia pertanto di pianificare la manutenzione trimestrale e mensile allo stesso tempo. Di conseguenza, se si ripianifica l'evento di manutenzione trimestrale all'ultimo momento, l'attività di manutenzione mensile verrà eseguita all'ora pianificata al momento della modifica della pianificazione.
Quando viene pianificata una manutenzione trimestrale al di fuori della finestra di 24 ore della manutenzione per la sicurezza nello stesso mese.	Sarà necessaria una finestra di manutenzione per la manutenzione trimestrale e una finestra di manutenzione per la manutenzione della sicurezza. Nota È possibile ripianificarla in qualsiasi momento prima della manutenzione mensile pianificata dell'infrastruttura Exadata. Gli storage server verranno aggiornati una sola volta se si pianifica la manutenzione di sicurezza mensile almeno 25 ore prima della manutenzione trimestrale nel mese in cui è stata pianificata la manutenzione di sicurezza sia trimestrale che mensile.

Visualizza eventi di manutenzione precedenti

È possibile visualizzare la manutenzione passata di un'infrastruttura Exadata, di un cluster VM Autonomous Exadata o di una risorsa Autonomous Container Database dalla pagina Dettagli.

Per una guida dettagliata, vedere:

Monitora eventi manutenzione servizio

È possibile monitorare gli eventi di manutenzione delle risorse dell'infrastruttura Autonomous Database utilizzando i servizi Eventi e Notifiche. I servizi Events and Notifications ti consentono di ricevere notifiche tramite posta elettronica quando si verificano eventi di manutenzione sulle risorse Exadata Infrastructure, Autonomous Exadata VM Cluster e Autonomous Container Database.

Per ogni risorsa dell'infrastruttura vengono generati quattro eventi di manutenzione diversi, come indicato di seguito.

Manutenzione pianificata
Promemoria manutenzione
Per le risorse AVMC (Autonomous Exadata VM Cluster) e ACD (Autonomous Container Database), la notifica di promemoria per la manutenzione viene inviata 1 settimana prima dell'esecuzione effettiva della manutenzione. Per le risorse dell'infrastruttura Exadata, la notifica di promemoria viene rilasciata tra 1 e 4 settimane prima dell'esecuzione della manutenzione, a seconda delle preferenze impostate.
Inizio della manutenzione
Fine manutenzione

Per la lista completa degli eventi generati per ciascuna risorsa dell'infrastruttura, consulta la sezione relativa agli eventi per Autonomous Database sull'infrastruttura Exadata dedicata.

È possibile eseguire la sottoscrizione a uno qualsiasi di questi eventi di manutenzione per una risorsa dell'infrastruttura eseguendo i task di alto livello riportati di seguito.

Creare un argomento del servizio di notifica.
Aggiungere una sottoscrizione e-mail all'argomento.
Aggiungere una regola del servizio eventi per inviare eventi di manutenzione all'argomento del servizio notifiche.

Esempio - Notifiche: e-mail per eventi di manutenzione

Per una guida dettagliata con un esempio, vedere Esempio di notifiche: e-mail per eventi di manutenzione.