Applica patch e aggiorna un sistema Oracle Exadata Database Service on Cloud@Customer

Impara ad aggiornare e applicare patch al sistema Oracle Exadata Database Service on Cloud@Customer

Esegui aggiornamenti manutenzione gestita dall'utente

La gestione di un sistema Oracle Exadata Database Service on Cloud@Customer sicuro nel miglior ordine di lavoro richiede l'esecuzione periodica delle attività seguenti:
  • Applicazione di patch al software Oracle Grid Infrastructure e Oracle Database sulle virtual machine del cluster VM. Per informazioni e istruzioni, vedere Applicazione di patch e aggiornamento di un sistema Exadata Cloud@Customer.
  • Aggiornamento del sistema operativo sulle virtual machine del cluster VM. Per informazioni e istruzioni, vedere Updating Guest VM Operating System e Oracle Clusterware Configuration and Administration.

Applicazione di patch e aggiornamento di un sistema Oracle Exadata Database Service on Cloud@Customer

Scopri come eseguire le operazioni di applicazione delle patch sulle virtual machine e sulle home del database Exadata utilizzando la console, l'API o l'interfaccia CLI.

Per informazioni e istruzioni sull'applicazione di patch al sistema mediante la utility dbaascli, vedere Patching and Updating an Oracle Exadata Database Service on Cloud@Customer System Manually.

Per ulteriori informazioni ed esempi per l'applicazione di patch trimestrali del database su Exadata Cloud@Customer, fare riferimento alla nota di My Oracle Support: Come applicare la patch trimestrale del database su Exadata Cloud Service ed Exadata Cloud at Customer Gen 2 (ID documento 2701789.1).

Per ulteriori indicazioni su come ottenere un servizio continuo durante le operazioni di applicazione delle patch, consulta il white paper Application Checklist for Continuous Service for MAA Solutions.

Applicazione di patch e aggiornamento dei cluster VM e delle home del database

Scopri come eseguire le operazioni di applicazione delle patch su VM Cluster Grid Infrastructure (GI) e sulle home del database utilizzando la console o l'API

Informazioni sull'applicazione di patch e sull'aggiornamento delle home GI e del database del cluster VM

L'applicazione di patch a un cluster VM aggiorna i componenti in ognuno dei guest VM nel cluster VM. L'applicazione di patch al cluster VM aggiorna Grid Infrastructure (GI) e l'applicazione di patch alla home del database per aggiornare il software Oracle Database condiviso dai database nella home specifica.

Per ulteriori informazioni sulle patch disponibili, vedere la nota di My Oracle Support https://support.oracle.com/epmos/faces/DocContentDisplay?id=2333222.1.

Tenere conto delle procedure consigliate illustrate di seguito.
  • Poiché l'applicazione di patch a un sistema richiede un reboot, pianificare l'esecuzione delle operazioni in un momento in cui l'impatto avrà un impatto minimo sugli utenti.
  • Oracle consiglia di eseguire il backup dei database prima di applicare le patch. Per informazioni sul backup dei database, vedere Gestione del backup e del recupero del database in Exadata Database Service on Cloud@Customer.
  • Oracle consiglia che la versione RU di Oracle Grid Infrastructure non superi i 6 mesi dalla versione RU del database più recente. Quando si aggiorna la versione del database, è necessario aggiornare anche la versione GI, se possibile.
  • Per applicare le patch a un database a una versione diversa dalla versione del database della home corrente, spostare il database in una home del database che esegue la versione di destinazione. Vedere Utilizzo della console per spostare un database in un'altra home.
Prerequisiti per l'applicazione di patch e l'aggiornamento di un sistema Oracle Exadata Database Service on Cloud@Customer

Controlla e applica le patch cloud più recenti scaricate e rese disponibili da Oracle sull'host CPS.

verificare che sussistano le seguenti condizioni per evitare errori di applicazione delle patch:
  • La directory /u01 nel file system host del database dispone di almeno 15 GB di spazio libero per l'esecuzione dei processi di applicazione delle patch.
  • Oracle Clusterware è attivo e in esecuzione sul cluster VM.
  • Tutti i nodi del cluster VM sono attivi e in esecuzione.
Uso della console per l'applicazione di patch e l'aggiornamento delle home GI e del database del cluster VM

Scopri come utilizzare la console per visualizzare la cronologia delle operazioni delle patch sul cluster VM e sulle home del database, applicare le patch e monitorare lo stato delle operazioni delle patch.

Oracle consiglia di utilizzare l'azione di controllo preliminare per assicurarsi che il cluster VM o la home del database abbia soddisfatto i requisiti per la patch che si desidera applicare.

Uso della console per eseguire gli aggiornamenti di Grid Infrastructure

Impara ad applicare gli aggiornamenti di Grid Infrastructure a un cluster VM.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
    I cluster VM sono selezionati per impostazione predefinita.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul cluster VM sul quale si desidera eseguire un'operazione di patch.
  4. Nella pagina Dettagli cluster VM risultante fare clic su Aggiornamenti.
  5. Rivedere la lista delle patch disponibili per il cluster VM.

    Le immagini software di Oracle Grid Infrastructure sono immagini software di Oracle Grid Infrastructure generalmente disponibili che è possibile utilizzare per applicare patch al cluster. Le immagini Oracle che possono essere utilizzate per l'applicazione delle patch hanno il tipo di aggiornamento "Patch".

    Le immagini software di Grid Infrastructure personalizzate sono l'immagine software di Grid Infrastructure creata in anticipo.

    Utilizzare il selettore Seleziona un compartimento per specificare il compartimento che contiene l'immagine software del database.

    Utilizzare il filtro Area per accedere alle immagini software create in un'area diversa.

  6. Fare clic sull'icona Azioni (tre punti) per la patch a cui si è interessati, quindi fare clic su una delle seguenti azioni:
    • Controllo preliminare: verificare la presenza di prerequisiti per assicurarsi che la patch possa essere applicata correttamente. Oracle consiglia di eseguire questa operazione prima di applicare una patch. Il controllo preliminare non influisce sulla disponibilità del cluster, ma tutto rimane operativo.
    • Applica aggiornamento di Grid Infrastructure: applica la patch selezionata.
  7. Confermare quando richiesto.

L'elenco delle patch visualizza lo stato dell'operazione. Durante l'esecuzione del controllo preliminare, lo stato della patch mostra Checking. Durante l'applicazione di una patch, lo stato della patch mostra Applying e lo stato del cluster VM mostra Updating. Durante l'applicazione della patch, le operazioni del ciclo di vita sul cluster VM e sulle relative risorse sono temporaneamente non disponibili. Se l'applicazione delle patch viene completata correttamente, lo stato della patch viene modificato in Applied e lo stato del cluster VM viene modificato in Available. Per visualizzare ulteriori dettagli su una singola operazione di patch, fare clic su Cronologia aggiornamenti. L'applicazione delle patch a Grid Infrastructure viene eseguita in sequenza, nodo per nodo e le risorse del cluster verranno arrestate e riavviate su ogni nodo.

Utilizzo della console per eseguire l'operazione di aggiornamento su una home del database

Imparare ad applicare le patch in una home del database.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
    I cluster VM sono selezionati per impostazione predefinita.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul cluster VM in cui si trova la home del database.
  4. Fare clic su Home database.
  5. Nella lista delle home del database, fare clic sulla home del database in cui si desidera eseguire un'operazione di patch.
  6. Fare clic su Aggiornamenti.
  7. Rivedere la lista delle patch disponibili per la home del database.

    Le immagini software di Oracle Database sono immagini software di Oracle Database generalmente disponibili che è possibile utilizzare per aggiornare il database. Le immagini Oracle che possono essere utilizzate per l'applicazione delle patch hanno il tipo di aggiornamento "Patch".

    Le immagini software del database personalizzato sono l'immagine software del database creata in anticipo.

    Utilizzare il selettore Seleziona un compartimento per specificare il compartimento che contiene l'immagine software del database.

    Utilizzare il filtro Area per accedere alle immagini software create in un'area diversa.

  8. Fare clic sull'icona Azioni (tre punti) per la patch a cui si è interessati, quindi fare clic su una delle seguenti azioni:
    • Controllo preliminare: verificare la presenza di prerequisiti per assicurarsi che la patch possa essere applicata correttamente. Oracle consiglia di eseguire questa operazione prima di applicare una patch. Il controllo preliminare non causa alcun impatto sulla disponibilità del cluster, tutto rimane operativo.
    • Applica aggiornamento database: applica la patch selezionata.
  9. Confermare quando richiesto.

L'elenco delle patch visualizza lo stato dell'operazione. Durante l'esecuzione del controllo preliminare, lo stato della patch mostra Checking. Durante l'applicazione di una patch, lo stato della patch mostra Applying, lo stato della home del database e dei database in essa contenuti viene visualizzato come Updating e le operazioni del ciclo di vita sul cluster VM e sulle relative risorse sono temporaneamente non disponibili. Le patch vengono applicate alla home del database in sequenza, nodo per nodo e ogni database nella home viene arrestato e quindi riavviato. Ciò può comportare un'interruzione temporanea del servizio. Se l'applicazione delle patch viene completata correttamente, lo stato della patch viene modificato in Applied e lo stato della home del database viene modificato in Available. Per visualizzare ulteriori dettagli su una singola operazione di patch, fare clic su Cronologia aggiornamenti.

Utilizzo della console per visualizzare la cronologia degli aggiornamenti

Ogni voce della cronologia degli aggiornamenti rappresenta un'operazione di patch tentata e indica se l'operazione è riuscita o meno. È possibile riprovare a eseguire un'operazione di patch non riuscita. La ripetizione di un'operazione determina la creazione di una nuova voce nella cronologia delle patch.

Le viste della cronologia degli aggiornamenti nella console non mostrano le patch applicate utilizzando strumenti della riga di comando quali dbaascli.

Uso della console per visualizzare la cronologia degli aggiornamenti di un cluster VM

Scopri come visualizzare la cronologia delle patch applicate a un cluster VM.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
    I cluster VM sono selezionati per impostazione predefinita.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul cluster VM a cui si è interessati.
  4. Fare clic su Aggiorna cronologia.

Viene visualizzata la cronologia delle operazioni delle patch per il cluster VM specificato, insieme alla cronologia delle operazioni delle patch nelle home del database.

Utilizzo della console per visualizzare la cronologia degli aggiornamenti di una home del database

Informazioni su come visualizzare la cronologia delle patch applicate in una home del database.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
    I cluster VM sono selezionati per impostazione predefinita.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul cluster VM in cui si trova la home del database.
  4. Fare clic su Home database.
    Viene visualizzata una lista di home del database.
  5. Nella lista di home del database, fare clic sulla home del database a cui si è interessati.
  6. Fare clic su Aggiorna cronologia.

Viene visualizzata la cronologia delle operazioni patch per la home del database specificata, insieme alla cronologia delle operazioni patch nel cluster VM a cui appartiene.

Utilizzo della console per spostare un database in un'altra home

È possibile aggiornare la versione di un database cluster VM spostandolo in una home del database in cui è in esecuzione la versione di Oracle Database a cui si è interessati.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
    I cluster VM sono selezionati per impostazione predefinita.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul cluster VM in cui si trova il database che si desidera spostare.
  4. Fare clic su Home database.
  5. Nella lista di home del database, fare clic sulla home del database a cui si è interessati.
  6. Fare clic su Database.
  7. Nell'elenco dei database, fare clic sul database a cui si è interessati.
  8. Fare clic su Azioni, quindi selezionare Sposta database.
  9. Selezionare la home database di destinazione.
  10. Fare clic su Sposta.
    Il database verrà arrestato nella home corrente, quindi riavviato nella home di destinazione.
  11. Confermare l'operazione di spostamento.

Il database viene spostato in sequenza. L'istanza di database verrà arrestata, nodo per nodo, nella home corrente e quindi riavviata nella home di destinazione. Durante lo spostamento del database, gli stati Home database e Database vengono visualizzati come Updating. La posizione della home del database, mostrata in Versione database, viene visualizzata come Moving Database. Al termine dell'operazione, la home del database viene aggiornata con la home corrente. Datapatch viene eseguito automaticamente durante lo spostamento del database per completare le azioni SQL successive alla patch per tutte le patch, incluse quelle singole, nella nuova home del database. Se l'operazione di spostamento del database non riesce, lo stato del database viene visualizzato come Failed e il campo Home database fornisce informazioni sul motivo dell'errore.

Uso dell'API per l'applicazione di patch e l'aggiornamento delle home del cluster VM e del database

Utilizza varie funzioni API per gestire l'applicazione di patch a un sistema Oracle Exadata Database Service on Cloud@Customer.

Per informazioni sull'uso dell'API e delle richieste di firma, vedere "API REST" e "Credenziali di sicurezza". Per informazioni sugli SDK, vedere "Software Development Kits and Command Line Interface".

Utilizzare queste operazioni API per gestire i cluster VM, le home del database e i database di applicazione delle patch.

Cluster VM:

  • UpdateVmCluster

Home database:

  • CreateDbHome
  • UpdateDbHome
  • DeleteDbHome

Database:

  • CreateDatabase
  • UpdateDatabase
  • DeleteDatabase

Utilizzare UpdateVMCluster per applicare le patch a Oracle Grid Infrastructure nel cluster VM. Utilizzare UpdateDbHome per applicare le patch al software del database della home del database. Utilizzare UpdateDatabase per spostare un database in una home del database diversa, aggiornando in tal modo il database alla stessa versione della home del database di destinazione.

Per la lista completa delle API per il servizio di database, vedere "Database Service API".

Aggiornamento del sistema operativo VM guest

Impara ad aggiornare l'immagine del sistema operativo sui nodi cluster VM Oracle Exadata Database Service on Cloud@Customer in modo automatico dalla console e dalle API OCI.

Questa funzione automatizzata semplifica e velocizza l'applicazione delle patch ai cluster VM, rende l'applicazione delle patch meno soggetta a errori ed elimina la necessità di utilizzare Patch Manager.

Quando si applica una patch, il sistema esegue un'operazione di controllo preliminare per assicurarsi che il cluster VM Exadata Cloud@Customer, il sistema di database o la home del database soddisfi i requisiti per tale patch. Se il controllo preliminare non riesce, la patch non viene applicata e il sistema visualizza un messaggio indicante che la patch non può essere applicata perché il controllo preliminare non è riuscito. È disponibile anche un'operazione di controllo preliminare distinta che è possibile eseguire prima dell'aggiornamento pianificato.

Versioni software supportate e limitazioni di aggiornamento

Requisiti minimi per l'aggiornamento all'immagine Exadata release 23.1.0.0.0 (immagine basata su Oracle Linux 8):

Nota

Questi sono solo i requisiti minimi. Se si desidera aggiornare Grid Infrastructure e/o Oracle Database per soddisfare i requisiti di Exadata 23.1, si consiglia di eseguire l'aggiornamento alle versioni più recenti disponibili di Grid Infrastructure e Oracle Database e non al minimo.
  • Exadata Image (Guest OS): immagine Exadata release 22.1.0 (maggio 2022) o 21.2.10 (marzo 2022). I sistemi che eseguono versioni precedenti alla 21.2.10 dovranno prima eseguire l'aggiornamento alla 22.1.0 (maggio 2022) o alla 21.2.10 (marzo 2022) prima di eseguire l'aggiornamento alla 23.1.0.0.0. Ciò vale sia per gli storage server che per i database server.
    • Oltre ad eseguire aggiornamenti di versioni secondarie alle immagini del cluster VM Exadata, è possibile eseguire l'aggiornamento a una nuova versione principale se la versione attualmente installata è la 19.2 o successiva. Ad esempio, se il cluster VM si trova nella versione 20, è possibile aggiornarlo alla versione 21.
    • Le ultime 4 (da N a N-3) o più versioni secondarie di ogni versione principale delle immagini del cluster VM sono disponibili tramite la console da applicare.
  • Oracle Grid Infrastructure: la release 23.1.0.0.0 dell'immagine Exadata supporta le seguenti versioni minime o più recenti di Oracle Grid Infrastructure.
    • Release 19c: versione 19.15, aggiornamento della release di aprile 2022 (RU) e più recente (predefinito)
    • Release 21c: versione 21.6, aggiornamento della release di aprile 2022 (RU) e versioni successive
  • Oracle Database: Exadata System Software 23.1 supporta le seguenti versioni minime o più recenti per le nuove installazioni di database.
    • Release 19c: versione 19.15, aggiornamento della release di aprile 2022 (RU) e più recente (predefinito)
    • Ulteriori versioni di database supportate nell'ambito dell'approvazione dell'eccezione Market Driven Support o Quarterly Updates:
      • Release 12.2.0.1, aggiornamento della release (RU) 12.2.0.1.220118 (gen 2022)
      • Release 12.1.0.2, patch bundle 12.1.0.2.220719 (luglio 2022) - richiede la patch 30159782
      • Release 11.2.0.4, patch bundle 11.2.0.4.210119 (gen 2021) - richiede la patch 30159782, la patch 33991024
  • Se l'avvio di un'operazione di manutenzione dell'infrastruttura Exadata è pianificato entro le prossime 24 ore, la funzione di aggiornamento dell'immagine Exadata non è disponibile.
  • Una volta eseguito l'upgrade del cluster VM a Exadata Database Service Guest VM OS 23.1, sarà possibile aggiungere una nuova VM o un nuovo database server a questo cluster VM se l'infrastruttura Exadata Cloud@Customer esegue un software Exadata System versione 22.1.16 e successive.
    Nota

    L'upgrade a Exadata System Software 23.1 per l'infrastruttura Exadata Cloud@Customer sarà disponibile con il ciclo di aggiornamento di febbraio 2024.
Uso della console per aggiornare il sistema operativo della VM guest

Per aggiornare il sistema operativo della VM guest con la console, prepararsi a fornire i valori per i campi obbligatori.

Nota

Una volta eseguito l'upgrade del cluster VM a Exadata Database Service Guest VM OS 23.1, sarà possibile aggiungere una nuova VM o un nuovo database server a questo cluster VM se l'infrastruttura Exadata Cloud@Customer esegue un software del sistema Exadata versione 22.1.16 e successive.

L'upgrade a Exadata System Software 23.1 per l'infrastruttura Exadata Cloud@Customer sarà disponibile con il ciclo di aggiornamento di febbraio 2024.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM cloud, fare clic sul nome del cluster a cui applicare le patch per visualizzare i dettagli del cluster.
  4. Fare clic su Aggiornamenti (OS).
  5. Rivedere l'elenco degli aggiornamenti software disponibili e individuare la patch del sistema operativo che si sta applicando.
  6. Fare clic sull'icona Azioni (tre punti) alla fine della riga che elenca la patch a cui si è interessati, quindi fare clic su una delle seguenti azioni:
    • Esegui controllo preliminare. Il controllo preliminare controlla i prerequisiti per garantire che la patch possa essere applicata correttamente. Oracle consiglia di eseguire l'operazione di controllo preliminare prima di applicare una patch. Il motivo è che le cose possono cambiare in un database in qualsiasi momento, e il controllo preliminare eseguito poco prima di eseguire una patch potrebbe trovare errori che il controllo preliminare precedente non ha trovato.
      Nota

      Se il controllo preliminare non riesce, nella finestra di dialogo Applica aggiornamento immagine del sistema operativo Exadata viene visualizzato un messaggio che informa che l'ultimo controllo preliminare non è riuscito. Oracle consiglia di eseguire di nuovo il controllo preliminare. Fare clic sull'icona Azioni (tre punti) alla fine della riga che elenca la patch del sistema operativo per visualizzare la finestra di dialogo.
    • Applica aggiornamento immagine del sistema operativo Exadata. Questo collegamento visualizza la finestra di dialogo Applica aggiornamento immagine Exadata utilizzata per applicare la patch. La finestra di dialogo mostra il nome del sistema di database a cui si sta applicando la patch, la versione corrente del database e la nuova versione del database dopo l'applicazione della patch. Per avviare il processo, fare clic su Applica aggiornamento immagine del sistema operativo Exadata.
    • Copia OCID. Copia l'ID Oracle Cloud. Questa opzione può essere utilizzata durante la risoluzione dei problemi di una patch o per fornire al supporto quando viene contattato.
      Nota

      Durante l'esecuzione della patch:
      • L'opzione Esegui controllo preliminare e applica aggiornamento immagine sistema operativo non è disponibile. Una volta completata la patch, queste azioni saranno nuovamente disponibili.
      • Se la manutenzione dell'infrastruttura Exadata contenente questo cluster VM è pianificata in conflitto con l'operazione di applicazione delle patch, la patch non riesce e il sistema visualizza un messaggio che ne spiega il motivo. Una volta completata la manutenzione dell'infrastruttura, eseguire di nuovo l'operazione di patch.
  7. Confermare quando richiesto.
Uso della console per eseguire il rollback o riprovare l'aggiornamento del sistema operativo della VM guest non riuscito

Per aggiornare il sistema operativo della VM guest con la console, prepararsi a fornire i valori per i campi obbligatori.

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul nome del cluster a cui applicare le patch per visualizzare i dettagli del cluster.

    Se l'applicazione dell'aggiornamento non è riuscita, nella pagina Dettagli cluster VM viene visualizzato un banner con le opzioni Rollback e Riprova applicazione.

    Scegliere un'opzione appropriata.

    1. Fare clic su Riprova applica.

      Viene visualizzata la finestra di dialogo Apply Exadata OS Image Update con le opzioni Apply Exadata Image Update e Run Precheck.

      Scegliere un'opzione appropriata.

      (or)

    2. Fare clic su Richiama.

      Viene visualizzata la finestra di dialogo Conferma operazione di rollback.

      Fare clic su Richiama per confermare.

  4. È inoltre possibile applicare l'aggiornamento dell'immagine Exadata dalla pagina Aggiornamenti (OS).
Utilizzo dell'API per aggiornare il sistema operativo della VM guest

Rivedere la lista di chiamate API per aggiornare il sistema operativo della VM guest.

Per informazioni sull'uso dell'API e delle richieste di firma, vedere API REST e Credenziali di sicurezza. Per informazioni sugli SDK, vedere Software Development Kits and Command Line Interface.

Utilizzare le seguenti operazioni API per eseguire l'upgrade di Oracle Grid Infrastructure in un cluster VM e visualizzare la cronologia degli aggiornamenti del cluster:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

Per l'elenco completo delle interfacce API, vedere API del servizio di database.

Aggiornamento di Oracle Grid Infrastructure su un cluster VM di Oracle Exadata Database Service on Cloud@Customer

Scopri come eseguire l'upgrade di Oracle Grid Infrastructure su un cluster VM Oracle Exadata Database Service on Cloud@Customer utilizzando la console o l'API di Oracle Cloud Infrastructure.

L'upgrade consente di eseguire il provisioning delle home Oracle Database e dei database che utilizzano il software Oracle Database più recente.

Informazioni sull'aggiornamento di Oracle Grid Infrastructure

L'upgrade di Oracle Grid Infrastructure (GI) in un cluster VM implica l'upgrade di tutti i nodi di calcolo nell'istanza. L'aggiornamento viene eseguito in sequenza e viene eseguito un solo nodo alla volta.

  • Oracle consiglia di eseguire un controllo preliminare dell'upgrade per identificare e risolvere eventuali problemi che potrebbero impedire un upgrade riuscito.
  • È possibile monitorare lo stato di avanzamento dell'operazione di aggiornamento visualizzando le richieste di lavoro associate.
  • Se è pianificata un'operazione di manutenzione dell'infrastruttura Exadata per l'avvio entro le prossime 24 ore, la funzione di upgrade GI non è disponibile.
  • Durante l'upgrade, non è possibile eseguire altre operazioni di gestione, ad esempio l'avvio, l'arresto o il riavvio dei nodi, il ridimensionamento della CPU, il provisioning o la gestione delle home o dei database, il ripristino di un database o la modifica delle impostazioni IORM. Le seguenti operazioni Data Guard non sono consentite nel cluster VM sottoposto a un upgrade GI:
    • Abilita Data Guard
    • Switchover
    • Failover al database utilizzando il cluster VM (è possibile eseguire un'operazione di failover per lo standby su un altro cluster VM)
Utilizzo della console per gestire l'upgrade di Oracle Grid Infrastructure

È possibile utilizzare la console per eseguire un controllo preliminare prima di eseguire l'upgrade di Oracle Grid Infrastructure (GI) ed eseguire l'operazione di upgrade GI.

Uso della console per controllare preventivamente il cluster VM prima dell'upgrade

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM cloud, fare clic sul nome del cluster a cui applicare le patch per visualizzare i dettagli del cluster.
  4. Fare clic su Aggiornamenti.
  5. Fare clic sull'icona Azioni (tre punti) alla fine della riga che elenca l'upgrade di Oracle Grid Infrastructure (GI), quindi fare clic su Esegui controllo preliminare.
  6. Nella finestra di dialogo Conferma confermare di voler eseguire l'aggiornamento per avviare l'operazione di controllo preliminare.
Uso della console per aggiornare Oracle Grid Infrastructure di un cluster VM

Nota

  • Quando si prevede di eseguire l'upgrade di Grid Infrastructure a 23ai, assicurarsi che per ogni gruppo di dischi ASM, compatible.rdbms abbia un valore impostato su 19.0.0.0 e versioni successive.
  • Requisiti minimi per l'upgrade di Grid Infrastructure da 19c a 23ai:
    • VM Exadata Guest su cui è in esecuzione il software del sistema Exadata 23.1.8
    • Infrastruttura Exadata in cui è in esecuzione il software di sistema Exadata 23.1.x
Nota

Al momento, l'aggiornamento di Grid Infrastructure da 19c a 23ai non è supportato per i cluster VM a nodo singolo.
  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM cloud, fare clic sul nome del cluster a cui applicare le patch per visualizzare i dettagli del cluster.
  4. Fare clic su Aggiornamenti.
  5. Fare clic sull'icona Azioni (tre punti) alla fine della riga che elenca l'aggiornamento di Oracle Grid Infrastructure (GI), quindi fare clic su Aggiorna Grid Infrastructure.
  6. Nella finestra di dialogo Aggiorna Grid Infrastructure, confermare che si desidera aggiornare GI facendo clic su Aggiorna Grid Infrastructure.

    Se non si è ancora eseguito un controllo preliminare, è possibile fare clic su Esegui controllo preliminare in questa finestra di dialogo per controllare preventivamente il cluster VM cloud prima dell'upgrade.

Utilizzo dell'API per gestire l'upgrade di Oracle Grid Infrastructure

Rivedere la lista di chiamate API per gestire l'upgrade di Oracle Grid Infrastructure.

Per informazioni sull'uso dell'API e delle richieste di firma, vedere API REST e Credenziali di sicurezza. Per informazioni sugli SDK, vedere Software Development Kits and Command Line Interface.

Utilizzare le seguenti operazioni API per eseguire l'upgrade di Oracle Grid Infrastructure in un cluster VM e visualizzare la cronologia degli aggiornamenti del cluster:
  • ListVmClusterUpdates
  • GetVmClusterUpdate
  • ListVmClusterUpdateHistoryEntries
  • GetVmClusterUpdateHistoryEntry
  • UpdateVmCluster

Per l'elenco completo delle interfacce API, vedere API del servizio di database.

Aggiornamento dei database Oracle

Impara a eseguire l'upgrade di un'istanza di database Exadata a Oracle Database 19c e Oracle Database 23ai utilizzando la console e l'API.

L'upgrade viene eseguito spostando il database Exadata in una home del database che utilizza la versione del software di destinazione. Per le sequenze temporali di rilascio e supporto software di Oracle Database, vedere Pianificazione della release delle release correnti del database (ID documento 742060.1).

Prerequisiti per l'upgrade dei database Oracle

Rivedere la lista dei prerequisiti per eseguire l'upgrade di un'istanza di Oracle Database Exadata Cloud@Customer.

  • Per eseguire l'upgrade a 19c, Oracle Linux 7 è il requisito minimo e per eseguire l'upgrade a 23ai, Oracle Linux 8 è il requisito minimo. Per istruzioni sull'aggiornamento manuale del sistema operativo, vedere Come aggiornare il software del sistema Exadata (DomU) a 19 da 18 in Exadata Cloud Service in OCI.
  • Oracle Grid Infrastructure può avere la versione 19c o 23ai per Oracle Database 19c. Tuttavia, Oracle Grid Infrastructure deve avere la versione 23ai per Oracle Database 23ai. Per istruzioni sull'uso della console o dell'API di Oracle Cloud Infrastructure per aggiornare Grid Infrastructure, vedere Aggiornamento di Exadata Grid Infrastructure. Se le patch sono disponibili per Grid Infrastructure, Oracle consiglia di applicarle prima di eseguire un upgrade del database.
  • È necessario disporre di una Oracle Database home disponibile che utilizzi le quattro versioni più recenti di Oracle Database 19c o Oracle Database 23ai disponibili in Oracle Cloud Infrastructure. Per informazioni sulla creazione di una home del database, vedere Uso della console per creare la home di Oracle Database in Exadata Cloud@Customer. È possibile utilizzare immagini software pubblicate da Oracle o un'immagine software di database personalizzata in base ai requisiti di applicazione delle patch per creare home del database.
  • È necessario assicurarsi che tutti i pluggable database nel container database da aggiornare possano essere aperti. I pluggable database che non possono essere aperti dal sistema durante l'aggiornamento possono causare un errore di aggiornamento.
Per eseguire l'upgrade, è necessario configurare il database Oracle con le seguenti impostazioni:
  • Il database deve essere in modalità archivio log.
  • Il flashback del database deve essere abilitato.

Per ulteriori informazioni su queste impostazioni, consultare la documentazione di Oracle Database relativa alla versione della release del database in uso.

Informazioni sull'upgrade di Oracle Database

Prima di aggiornare il database, acquisire familiarità con le seguenti procedure per prepararlo all'aggiornamento.

  • Gli aggiornamenti del database comportano tempi di inattività del database. Tienilo a mente quando pianifichi l'aggiornamento.
  • Oracle consiglia di eseguire il backup del database e il test della nuova versione software in un sistema di test o in una versione duplicata del database prima di eseguire l'upgrade di un database di produzione. Per informazioni sulla creazione di un backup manuale su richiesta, vedere Creazione di un backup su richiesta mediante la utility bkup_api.
  • Oracle consiglia di eseguire un'operazione di controllo preliminare dell'upgrade per il database prima di tentare un upgrade in modo da poter individuare eventuali problemi che richiedono una mitigazione prima dell'ora in cui si prevede di eseguire l'upgrade. L'operazione di controllo preliminare non influisce sulla disponibilità del database e può essere eseguita in qualsiasi momento.
  • Se i database utilizzano Data Guard, puoi prima eseguire l'upgrade del database primario o del database in standby.
  • Impossibile eseguire un'operazione di aggiornamento mentre è in corso un'operazione di backup automatico. Prima di eseguire l'upgrade, Oracle consiglia di disabilitare i backup automatici ed eseguire un backup manuale. Per ulteriori informazioni, vedere Creazione di un backup su richiesta mediante la utility bkup_api e Personalizzazione della configurazione di backup automatico.
  • Dopo l'aggiornamento, non è possibile utilizzare i backup automatici eseguiti prima dell'aggiornamento per ripristinare il database in un point-in-time precedente.
  • Se si aggiorna un database che utilizza il software della versione 11.2, la versione 19c risultante sarà un database non di tipo container (non CDB).
Modalità di esecuzione dell'operazione di aggiornamento da parte del servizio di database

Acquisire familiarità con le attività del servizio di database durante il processo di upgrade.

  • Esegue un controllo preliminare automatico. Ciò consente al sistema di identificare i problemi che richiedono una mitigazione e di interrompere l'operazione di aggiornamento.
  • Imposta un punto di ripristino garantito, che consente di eseguire un flashback in caso di errore dell'aggiornamento.
  • Sposta il database in una Oracle Database home specificata dall'utente che utilizza la versione del software di destinazione desiderata.
  • Esegue il software DBUA (Database Upgrade Assistant) per eseguire l'aggiornamento.
Rollback di un aggiornamento di Oracle Database non riuscito

Se l'upgrade non viene completato correttamente, è possibile eseguire un rollback.

I dettagli relativi all'errore vengono visualizzati nella pagina Dettagli database della console, che consente di analizzare e risolvere i problemi che causano l'errore.

Un rollback ripristina lo stato del database precedente all'upgrade. Tutte le modifiche apportate al database durante e dopo l'upgrade verranno perse. L'opzione di rollback viene fornita in un messaggio di avvio visualizzato nella pagina dei dettagli del database di un database in seguito a un'operazione di aggiornamento non riuscita. Per ulteriori informazioni, vedere Utilizzo della console per eseguire il rollback di un aggiornamento del database non riuscito.

Dopo l'upgrade di Oracle Database

Dopo un aggiornamento riuscito, tenere presente quanto riportato di seguito.

  • Verificare che i backup automatici siano abilitati per il database se sono stati disabilitati prima dell'aggiornamento. Per ulteriori informazioni, vedere Personalizzazione della configurazione di backup automatico.
  • Modifica Oracle Database
    COMPATIBLE
    parametro che riflette la nuova versione del software Oracle Database. Per ulteriori informazioni, vedere Che cos'è la compatibilità di Oracle Database?.
  • Se il database utilizza un file database_name.env, assicurarsi che le variabili nel file siano state aggiornate in modo da puntare alla home del database 19c. Queste variabili devono essere aggiornate automaticamente durante il processo di aggiornamento.
  • Se si sta eseguendo l'upgrade di un database non di tipo container a Oracle Database versione 19c, è possibile convertire il database in pluggable database dopo la conversione. Per istruzioni sulla conversione del database in pluggable database, vedere Come convertire un database non CDB in PDB (ID documento 2288024.1).
  • Se la vecchia home del database è vuota e non verrà riutilizzata, è possibile rimuoverla. Per ulteriori informazioni, vedere Utilizzo della console per eliminare una home di Oracle Database.
Uso della console per gestire l'upgrade di Oracle Database

Oracle consiglia di utilizzare l'azione di controllo preliminare per assicurarsi che il database abbia soddisfatto i requisiti per l'operazione di upgrade.

Uso della console per eseguire il controllo preliminare dell'upgrade di Oracle Database o l'upgrade

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul nome del cluster VM che contiene il database da aggiornare.
  4. Nella lista dei database nella pagina Dettagli cluster VM, fare clic sul nome del database che si desidera aggiornare per visualizzare la pagina Dettagli database.
  5. Fare clic sul menu Azioni, quindi selezionare Aggiorna.
  6. Nella finestra di dialogo Aggiorna database selezionare quanto riportato di seguito.
    • Versione di Oracle Database: il selettore a discesa elenca solo le versioni di Oracle Database compatibili con un upgrade della versione software corrente utilizzata dal database. La versione del software di destinazione deve essere successiva alla versione corrente del database.
    • Home database di destinazione: selezionare una home database per il database. La lista di home del database è limitata alle home che utilizzano le versioni più recenti del software Oracle Database 19c. Lo spostamento del database nella nuova home del database comporta l'upgrade del database alla versione della release principale e al livello di applicazione delle patch della nuova home del database.

  7. Fare clic su una delle opzioni riportate di seguito.
    • Esegui controllo preliminare: questa opzione avvia un controllo preliminare dell'upgrade per identificare eventuali problemi del database che richiedono una mitigazione prima di eseguire un upgrade.
    • Aggiorna database: questa opzione avvia l'operazione di aggiornamento. Oracle consiglia di eseguire un upgrade solo dopo aver eseguito un controllo preliminare riuscito sul database.
Uso della console per eseguire il rollback di un aggiornamento del database non riuscito

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul nome del cluster VM che contiene il database con l'upgrade non riuscito.
  4. Trovare il database di cui non è stato eseguito l'upgrade e fare clic sul nome per visualizzarne i dettagli.
  5. Il database deve visualizzare un banner nella parte superiore della pagina dei dettagli che includa un pulsante Rollback e i dettagli sui problemi che hanno causato l'errore dell'aggiornamento.
  6. Fare clic su Rollback.
  7. Nella finestra di dialogo Conferma rollback confermare che si desidera avviare un rollback alla versione precedente di Oracle Database.
Utilizzo della console per visualizzare la cronologia di aggiornamento di un database

  1. Aprire il menu di navigazione. In Oracle Database, fare clic su Exadata Database Service on Cloud@Customer.
  2. Scegliere il compartimento.
    Viene visualizzata una lista di cluster VM per il compartimento scelto.
  3. Nella lista dei cluster VM, fare clic sul nome del cluster VM che contiene il database da aggiornare
  4. Nella lista dei database della pagina Dettagli cluster VM fare clic sul nome del database per il quale si desidera visualizzare la cronologia di upgrade.
  5. Nella pagina Dettagli database, fare clic su Cronologia aggiornamenti.
Utilizzo dell'API per eseguire l'upgrade dei database Oracle

Rivedere la lista di chiamate API per l'upgrade dei database Oracle.

Per informazioni sull'uso dell'API e delle richieste di firma, vedere API REST e Credenziali di sicurezza. Per informazioni sugli SDK, vedere Software Development Kits and Command Line Interface.

Utilizzare le seguenti API per gestire gli aggiornamenti del database:
  • getDatabaseUpgradeHistoryEntry
  • ListDatabaseUpgradeHistoryEntries
  • UpgradeDatabase

Per l'elenco completo delle interfacce API, vedere API del servizio di database.

Applicazione manuale di patch e aggiornamento di un sistema Oracle Exadata Database Service on Cloud@Customer

Questo argomento descrive le procedure per applicare patch e aggiornare vari componenti in Oracle Exadata Database Service on Cloud@Customer al di fuori dell'automazione cloud. Per informazioni relative all'applicazione di patch e all'aggiornamento con dbaascli, fare riferimento a "Applicazione di patch ai database Oracle Grid Infrastructure e Oracle mediante dbaascli".

Nota

Per ulteriori indicazioni su come ottenere un servizio continuo durante le operazioni di applicazione delle patch, consultare il white paper Application Checklist for Continuous Service for MAA Solutions.

Aggiornamento manuale del software

Per l'ora legale e alcune patch di routine o una tantum può essere necessario applicare le patch manualmente al software.

Per eseguire l'applicazione di patch di routine del software Oracle Database e Oracle Grid Infrastructure, Oracle consiglia di utilizzare le funzionalità fornite da Oracle Exadata Database Service on Cloud@Customer. Tuttavia, in alcune circostanze, può essere necessario applicare manualmente le patch al software Oracle Database o Oracle Grid Infrastructure:
  • Applicazione delle patch DST (Daylight Savings Time): poiché non possono essere applicate in sequenza, le patch per le definizioni DST di Oracle Database non vengono incluse nei set di patch di routine per Exadata Database Service on Cloud@Customer. Se è necessario applicare le patch alle definizioni DST di Oracle Database, è necessario farlo manualmente. Vedere l'ID documento My Oracle Support 412160.1.
  • Applicazione di patch non di routine o singole: se si verifica un problema che richiede una patch non inclusa in alcun set di patch di routine, utilizzare Oracle Support Services per identificare e applicare la patch appropriata.

Per informazioni generali sull'applicazione di patch a Oracle Database, vedere le informazioni sugli aggiornamenti e i requisiti dei set di patch nella Guida all'aggiornamento di Oracle Database per la release in uso.

Aggiornamento manuale del sistema operativo della VM guest

Scopri gli strumenti e le tecniche Exadata standard che puoi utilizzare per aggiornare i componenti del sistema operativo nelle VM guest di Oracle Exadata Database Service on Cloud@Customer.

L'utente è responsabile della gestione di patch e aggiornamenti dell'ambiente del sistema operativo nelle VM (Database Server Virtual Machine). Per ulteriori informazioni, consultare la sezione relativa all'aggiornamento dei server Exadata Database Machine nella guida di manutenzione di Oracle Exadata Database Machine.

Preparazione di un aggiornamento del sistema operativo

Per prepararsi a un aggiornamento del sistema operativo per Oracle Exadata Database Service on Cloud@Customer, consultare questa lista di controllo dei task.

Prima di aggiornare il sistema operativo, eseguire ognuna delle attività di preparazione riportate di seguito.

Determinare l'aggiornamento software più recente. Prima di iniziare un aggiornamento, per determinare il software più recente da utilizzare, vedere la nota 2333222.1 di Exadata Cloud Service Software Versions in My Oracle Support.

Aggiornamento del sistema operativo su tutte le Virtual Machine di un sistema Oracle Exadata Database Service on Cloud@Customer

Per aggiornare il sistema operativo sulle VM (Database Server Virtual Machine), utilizzare lo strumento patchmgr.

Nota

I clienti che non dispongono del privilegio per il download delle patch di My Oracle Support possono ottenere la utility di aggiornamento patchmgr Exadata e le recenti release del software di sistema Exadata utilizzando la utility Exadata Cloud@Customer Gen 2 exadata_updates.sh. Per ulteriori informazioni, vedere My Oracle Support, Doc 2730739.1.

La utility patchmgr gestisce da remoto l'intero aggiornamento di una o più virtual machine, incluse le fasi di pre-riavvio, riavvio e post-riavvio di un sistema Oracle Exadata Database Service on Cloud@Customer.

Puoi eseguire la utility da una delle tue virtual machine Oracle Exadata Database Service on Cloud@Customer o da un altro server su cui è in esecuzione Oracle Linux. Il server su cui si esegue la utility è noto come sistema di unità. Non è possibile utilizzare il sistema di guida per aggiornarsi. Pertanto, se il sistema di guida è una delle virtual machine in un cluster VM che si sta aggiornando, è necessario eseguire la utility patchmgr più volte. Gli scenari riportati di seguito descrivono le modalità tipiche di esecuzione degli aggiornamenti.

  • Sistema di gestione non Exadata

    Il modo più semplice per eseguire l'aggiornamento del sistema consiste nell'utilizzare un server Oracle Linux separato per aggiornare tutte le virtual machine in un'unica operazione.

  • Sistema di gestione delle virtual machine Exadata

    È possibile utilizzare una virtual machine per eseguire gli aggiornamenti per il resto delle virtual machine nel cluster VM. Quindi, è possibile utilizzare uno dei nodi aggiornati per guidare l'aggiornamento sul sistema di guida originale. Ad esempio, si consiglia di aggiornare un sistema half rack con quattro virtual machine: node1, node2, node3 e node4. In primo luogo, è possibile utilizzare node1 per eseguire gli aggiornamenti di node2, node3 e node4. Quindi, è possibile utilizzare node2 per eseguire l'aggiornamento di node1.

Il sistema di gestione richiede l'accesso SSH utente root a ogni virtual machine aggiornata.

La procedura seguente si basa su un esempio che presuppone quanto segue:

  • Il sistema dispone di due virtual machine, node1 e node2.
  • La versione del software Exadata di destinazione è 18.1.4.0.0.180125.3.
  • Ogni nodo viene utilizzato come sistema di guida per aggiornare l'altro nodo.
  1. Raccogliere i dettagli dell'ambiente.
    1. Utilizzando SSH, connettersi a node1 come utente opc.

      Per istruzioni dettagliate, vedere Connessione a un nodo di calcolo con SSH.

    2. Avviare una shell del comando utente root.
      sudo su -
    3. Eseguire il comando riportato di seguito per determinare la versione corrente del software Exadata.
      imageinfo -ver
      Ad esempio:
      # imageinfo -ver 19.2.13.0.0.200428
    4. Passare all'utente grid e identificare tutti i nodi nel cluster.
      su - grid
      olsnodes
      Ad esempio:
      olsnodes
      node1
      node2
  2. Configurare il sistema di guida.
    1. Tornare all'utente root in node1 e verificare se esiste una coppia di chiavi SSH (id_rsa e id_rsa.pub). In caso contrario, generarlo.
      ls /root/.ssh/id_rsa*
      ls: cannot access /root/.ssh/id_rsa*: No such file or directory
      
      ssh-keygen -t rsa
      Generating public/private rsa key pair.
      Enter file in which to save the key (/root/.ssh/id_rsa):
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      Your identification has been saved in /root/.ssh/id_rsa.
      Your public key has been saved in /root/.ssh/id_rsa.pub.
      The key fingerprint is:
      93:47:b0:83:75:f2:3e:e6:23:b3:0a:06:ed:00:20:a5 root@node1.example.com
      The key's randomart image is:
      +--[ RSA 2048]----+
      |o..     + .      |
      |o.     o *       |
      |E     . o o      |
      | . .     =       |
      |  o .   S =      |
      |   +     = .     |
      |    +   o o      |
      |   . .   + .     |
      |      ...        |
      +-----------------+
    2. Distribuire la chiave pubblica sui nodi di destinazione e verificare questo passo. Nell'esempio, l'unico nodo di destinazione è node2.
      scp -i ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
      ls -al /tmp/id_rsa.node1.pub
      -rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
      date
      Wed Feb 28 03:33:45 UTC 2018
    3. Nel nodo di destinazione (node2 nell'esempio), aggiungere la chiave pubblica radice di node1 al file authorized_keys radice.
      cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Scaricare patchmgr in /root/patch sul sistema di guida (node1 in questo esempio).

      È possibile scaricare il bundle patchmgr dal Supporto Oracle utilizzando My Oracle Support Patch ID 21634633. Per installare qualsiasi release del software del sistema Exadata, ottenere sempre la utility di aggiornamento patchmgr Exadata più recente disponibile.

      Per ulteriori informazioni, vedere anche dbnodeupdate.sh e dbserver.patch.zip: Aggiornamento del software Exadata Database Server mediante la utility DBNodeUpdate e patchmgr: ID documento My Oracle Support 1553103.1.

    5. Estrarre il bundle patchmgr.

      A seconda della versione scaricata, il nome del file ZIP può essere diverso.

      cd /root/patch/18.1.4.0.0.180125.3
      unzip dbserver.patch.zip
      Archive:  p21634633_181400_Linux-x86-64.zip   creating: dbserver_patch_5.180228.2/
      creating: dbserver_patch_5.180228.2/ibdiagtools/
      inflating: dbserver_patch_5.180228.2/ibdiagtools/cable_check.pl
      inflating: dbserver_patch_5.180228.2/ibdiagtools/setup-ssh
      inflating: dbserver_patch_5.180228.2/ibdiagtools/VERSION_FILE
      extracting: dbserver_patch_5.180228.2/ibdiagtools/xmonib.sh
      inflating: dbserver_patch_5.180228.2/ibdiagtools/monitord
      inflating: dbserver_patch_5.180228.2/ibdiagtools/checkbadlinks.pl
      creating: dbserver_patch_5.180228.2/ibdiagtools/topologies/
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/VerifyTopologyUtility.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/verifylib.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Node.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Rack.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Group.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topologies/Switch.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/topology-zfs
      inflating: dbserver_patch_5.180228.2/ibdiagtools/dcli
      creating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteScriptGenerator.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/CommonUtils.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/SolarisAdapter.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/LinuxAdapter.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteLauncher.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/remoteConfig.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/spawnProc.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/runDiagnostics.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/netcheck/OSAdapter.pm
      inflating: dbserver_patch_5.180228.2/ibdiagtools/SampleOutputs.txt
      inflating: dbserver_patch_5.180228.2/ibdiagtools/infinicheck
      inflating: dbserver_patch_5.180228.2/ibdiagtools/ibping_test
      inflating: dbserver_patch_5.180228.2/ibdiagtools/tar_ibdiagtools
      inflating: dbserver_patch_5.180228.2/ibdiagtools/verify-topology
      inflating: dbserver_patch_5.180228.2/installfw_exadata_ssh
      creating: dbserver_patch_5.180228.2/linux.db.rpms/
      inflating: dbserver_patch_5.180228.2/md5sum_files.lst
      inflating: dbserver_patch_5.180228.2/patchmgr
      inflating: dbserver_patch_5.180228.2/xcp
      inflating: dbserver_patch_5.180228.2/ExadataSendNotification.pm
      inflating: dbserver_patch_5.180228.2/ExadataImageNotification.pl
      inflating: dbserver_patch_5.180228.2/kernelupgrade_oldbios.sh
      inflating: dbserver_patch_5.180228.2/cellboot_usb_pci_path
      inflating: dbserver_patch_5.180228.2/exadata.img.env
      inflating: dbserver_patch_5.180228.2/README.txt
      inflating: dbserver_patch_5.180228.2/exadataLogger.pm
      inflating: dbserver_patch_5.180228.2/patch_bug_26678971
      inflating: dbserver_patch_5.180228.2/dcli
      inflating: dbserver_patch_5.180228.2/patchReport.py
      extracting: dbserver_patch_5.180228.2/dbnodeupdate.zip
      creating: dbserver_patch_5.180228.2/plugins/
      inflating: dbserver_patch_5.180228.2/plugins/010-check_17854520.sh
      inflating: dbserver_patch_5.180228.2/plugins/020-check_22468216.sh
      inflating: dbserver_patch_5.180228.2/plugins/040-check_22896791.sh
      inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_bash
      inflating: dbserver_patch_5.180228.2/plugins/050-check_22651315.sh
      inflating: dbserver_patch_5.180228.2/plugins/005-check_22909764.sh
      inflating: dbserver_patch_5.180228.2/plugins/000-check_dummy_perl
      inflating: dbserver_patch_5.180228.2/plugins/030-check_24625612.sh
      inflating: dbserver_patch_5.180228.2/patchmgr_functions
      inflating: dbserver_patch_5.180228.2/exadata.img.hw
      inflating: dbserver_patch_5.180228.2/libxcp.so.1
      inflating: dbserver_patch_5.180228.2/imageLogger
      inflating: dbserver_patch_5.180228.2/ExaXMLNode.pm
      inflating: dbserver_patch_5.180228.2/fwverify
    6. Nella directory che contiene la utility patchmgr, creare il file dbs_group che contiene la lista delle virtual machine da aggiornare. Includere i nodi elencati dopo aver eseguito il comando olsnodes nel passo 1, ad eccezione del sistema di guida. In questo esempio, dbs_group contiene solo node2.
      cd /root/patch/18.1.4.0.0.180125.3/dbserver_patch_5.180228
      cat dbs_group
      node2
  3. Eseguire un'operazione di controllo preliminare dell'applicazione delle patch.
    ./patchmgr -dbnodes dbs_group -precheck -iso_repo zipped_iso_file -target_version target-version -nomodify_at_prereq
    Nota

    Eseguire l'operazione di controllo preliminare con l'opzione -nomodify_at_prereq per evitare modifiche al sistema che potrebbero influire sul backup eseguito nel passo successivo. In caso contrario, il backup potrebbe non essere in grado di ripristinare lo stato originale del sistema, se necessario.

    L'output deve essere simile al seguente esempio:

    ./patchmgr -dbnodes dbs_group -precheck -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -nomodify_at_prereq
     
    ************************************************************************************************************
    NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
    NOTE
    WARNING Do not interrupt the patchmgr session.
    WARNING Do not resize the screen. It may disturb the screen layout.
    WARNING Do not reboot database nodes during update or rollback.
    WARNING Do not open logfiles in write mode and do not try to alter them.
    ************************************************************************************************************
    2018-02-28 21:22:45 +0000        :Working: DO: Initiate precheck on 1 node(s)
    2018-02-28 21:24:57 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:26:15 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:26:47 +0000        :Working: DO: dbnodeupdate.sh running a precheck on node(s).
    2018-02-28 21:28:23 +0000        :SUCCESS: DONE: Initiate precheck on node(s).
  4. Eseguire il backup del sistema corrente.
    ./patchmgr -dbnodes dbs_group -backup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts
    Nota

    Prima di apportare eventuali modifiche al sistema, assicurarsi di eseguire il backup in questo momento.

    L'output deve essere simile al seguente esempio:

    ./patchmgr -dbnodes dbs_group -backup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts
     
    ************************************************************************************************************
    NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
    NOTE
    WARNING Do not interrupt the patchmgr session.
    WARNING Do not resize the screen. It may disturb the screen layout.
    WARNING Do not reboot database nodes during update or rollback.
    WARNING Do not open logfiles in write mode and do not try to alter them.
    ************************************************************************************************************
    2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on 1 node(s).
    2018-02-28 21:29:00 +0000        :Working: DO: Initiate backup on node(s)
    2018-02-28 21:29:01 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:30:18 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:30:51 +0000        :Working: DO: dbnodeupdate.sh running a backup on node(s).
    2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on node(s).
    2018-02-28 21:35:50 +0000        :SUCCESS: DONE: Initiate backup on 1 node(s).
  5. Rimuovere tutti gli RPM personalizzati dalle virtual machine di destinazione. Gli RPM personalizzati vengono riportati nei risultati del controllo preliminare. Sono inclusi gli RPM installati manualmente dopo il provisioning del sistema.
    • Se si sta aggiornando il sistema dalla versione 12.1.2.3.4.170111 e i risultati del controllo preliminare includono krb5-workstation-1.10.3-57.el6.x86_64, rimuovere il sistema. Questo articolo è considerato un RPM personalizzato per questa versione.
    • Non rimuovere exadata-sun-vm-computenode-exact o oracle-ofed-release-guest. Questi due RPM vengono gestiti automaticamente durante il processo di aggiornamento.
  6. Eseguire l'aggiornamento. Per garantire che il processo di aggiornamento non venga interrotto, utilizzare il comando nohup. Ad esempio:
    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo zipped_iso_file -target_version target-version -allow_active_network_mounts &

    L'output deve essere simile al seguente esempio:

    nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup -iso_repo /root/patch/18.1.4.0.0.180125.3/exadata_ol6_18.1.4.0.0.180125.3_Linux-x86-64.zip -target_version 18.1.4.0.0.180125.3 -allow_active_network_mounts &
     
    ************************************************************************************************************
    NOTE    patchmgr release: 5.180228 (always check MOS 1553103.1 for the latest release of dbserver.patch.zip)
    NOTE
    NOTE    Database nodes will reboot during the update process.
    NOTE
    WARNING Do not interrupt the patchmgr session.
    WARNING Do not resize the screen. It may disturb the screen layout.
    WARNING Do not reboot database nodes during update or rollback.
    WARNING Do not open logfiles in write mode and do not try to alter them.
    *********************************************************************************************************
    2018-02-28 21:36:26 +0000        :Working: DO: Initiate prepare steps on node(s).
    2018-02-28 21:36:26 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:37:44 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:38:43 +0000        :SUCCESS: DONE: Initiate prepare steps on node(s).
    2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on 1 node(s).
    2018-02-28 21:38:43 +0000        :Working: DO: Initiate update on node(s)
    2018-02-28 21:38:49 +0000        :Working: DO: Get information about any required OS upgrades from node(s).
    2018-02-28 21:38:59 +0000        :SUCCESS: DONE: Get information about any required OS upgrades from node(s).
    2018-02-28 21:38:59 +0000        :Working: DO: dbnodeupdate.sh running an update step on all nodes.
    2018-02-28 21:48:41 +0000        :INFO   : node2 is ready to reboot.
    2018-02-28 21:48:41 +0000        :SUCCESS: DONE: dbnodeupdate.sh running an update step on all nodes.
    2018-02-28 21:48:41 +0000        :Working: DO: Initiate reboot on node(s)
    2018-02-28 21:48:57 +0000        :SUCCESS: DONE: Initiate reboot on node(s)
    2018-02-28 21:48:57 +0000        :Working: DO: Waiting to ensure node2 is down before reboot.
    2018-02-28 21:56:18 +0000        :Working: DO: Initiate prepare steps on node(s).
    2018-02-28 21:56:19 +0000        :Working: DO: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:57:37 +0000        :SUCCESS: DONE: Check free space and verify SSH equivalence for the root user to node2
    2018-02-28 21:57:42 +0000        :SEEMS ALREADY UP TO DATE: node2
    2018-02-28 21:57:43 +0000        :SUCCESS: DONE: Initiate update on node(s)
  7. Al termine dell'operazione di aggiornamento, verificare la versione del software Exadata sulla virtual machine aggiornata.
    imageinfo -ver
    18.1.4.0.0.180125.3
  8. Ripetere i passaggi da 2 a 7 di questa procedura utilizzando la macchina virtuale aggiornata come sistema di guida per aggiornare la macchina virtuale rimanente. In questo aggiornamento di esempio, è ora possibile utilizzare node2 per aggiornare node1.
  9. Come root In ogni virtual machine, eseguire il comando uptrack-install per installare gli aggiornamenti ksplice disponibili.
    uptrack-install --all -y
    uptrack-install --all -y
Installazione di pacchetti aggiuntivi del sistema operativo

Rivedere queste linee guida prima di installare pacchetti di sistema operativo aggiuntivi per Oracle Exadata Database Service on Cloud@Customer.

Si è autorizzati a installare e aggiornare i pacchetti del sistema operativo in Oracle Exadata Database Service on Cloud@Customer a condizione che non vengano modificati i pacchetti specifici del kernel o InfiniBand. Tuttavia, il supporto tecnico Oracle, inclusi installazione, test, certificazione e risoluzione degli errori, non si applica ai software non Oracle installati.

Tenere inoltre presente che se si aggiungono o si aggiornano pacchetti separati da un aggiornamento del software Oracle Exadata, tali aggiunte o aggiornamenti di pacchetti possono presentare problemi quando si applica un aggiornamento del software Oracle Exadata. Si possono verificare problemi perché pacchetti software aggiuntivi aggiungono nuove dipendenze che possono interrompere un aggiornamento di Oracle Exadata. Per questo motivo, Oracle consiglia di ridurre al minimo la personalizzazione.

Se si installano pacchetti aggiuntivi, Oracle consiglia di disporre di script che automatizzino la rimozione e la reinstallazione di tali pacchetti. Dopo un aggiornamento di Oracle Exadata, se si installano pacchetti aggiuntivi, verificare che i pacchetti aggiuntivi siano ancora compatibili e che siano ancora necessari.

Per ulteriori informazioni, fare riferimento alla guida di manutenzione di Oracle Exadata Database Machine.

Risoluzione dei problemi di dipendenza associati a pacchetti software non Exadata aggiuntivi per l'upgrade DOMU

Se sono stati installati pacchetti software non Exadata oltre quelli forniti da Oracle e il controllo preliminare non riesce durante un upgrade DOMU a causa di conflitti tra gli RPM installati da Oracle e tra questi, è possibile utilizzare la procedura riportata di seguito per risolvere i conflitti e procedere con l'upgrade.

Per gli aggiornamenti che non modificano la versione principale di Oracle Linux, questa funzionalità integrata consente di aggiornare ulteriori pacchetti software non Exadata nell'ambito dell'aggiornamento del database server Exadata. Semplifica la gestione dei problemi di dipendenza dei pacchetti che possono verificarsi quando tali pacchetti software non Exadata sono presenti nel sistema.

È possibile eseguire un controllo preliminare iterativo per identificare e risolvere i problemi di dipendenza associati ai package software non Exadata aggiuntivi. Una volta compresi gli aggiornamenti richiesti, puoi eseguire in tutta sicurezza l'aggiornamento del database server Exadata e aggiornare i pacchetti aggiuntivi in un'unica operazione coordinata.

Assicurarsi che il file di configurazione esista sul server di destinazione per attivare l'impostazione di un repository YUM temporaneo per i package software non Exadata.

  • Posizione file: /etc/exadata/additional-packages.txt
  • Proprietà e autorizzazioni: questo file deve essere di proprietà e modificabile solo dall'utente root.

Se il file esiste, viene utilizzato per raccogliere informazioni sui pacchetti software non Exadata necessari e per impostare e abilitare un repository YUM temporaneo. Se il file non è presente, non viene configurato alcun repository.

È inoltre possibile creare un collegamento simbolico in /etc/exadata/additional-packages.txt che punta a un file di configurazione che si trova altrove, in genere su un'attivazione condivisa.

Formato file

Il file deve contenere una lista di pacchetti software non Exadata, con ogni voce su una nuova riga. I formati supportati includono:

  • http(s)://path/to/package.rpm: URL completo del file RPM
  • /full/path/to/package.rpm: percorso assoluto di un file RPM locale
  • repo:package.rpm: riferimento a un pacchetto in un repository YUM esistente
Nota

  • Se si utilizza il formato repo:, assicurarsi che il repository di riferimento sia definito nella configurazione YUM del server di destinazione.
  • I file locali possono trovarsi in directory locali standard, installazioni NFS o installazioni ACFS.
Esempio: additional-packages.txt

/u01/elfutils-debuginfod-client-0.190-2.el8.x86_64.rpm
/u01/elfutils-libelf-devel-0.190-2.el8.x86_64.rpm
/u01/keyutils-libs-devel-1.5.10-9.0.1.el8.x86_64.rpm
https://example.com/packages/krb5-devel-1.18.2-28.0.1.el8_10.x86_64.rpm
https://example.com/packages/memstrack-0.2.5-2.el8.x86_64.rpm
/u01/pigz-2.4-4.el8.x86_64.rpm
/u01/sssd-nfs-idmap-2.9.4-3.0.1.el8_10.x86_64.rpm
https://example.com/packages/timedatex-0.5-3.el8.x86_64.rpm
https://example.com/packages/zlib-devel-1.2.11-25.el8.x86_64.rpm