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
- Eseguire aggiornamenti per la manutenzione gestita dall'utente
- 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. - Applicazione manuale di patch e aggiornamento di un sistema Oracle Exadata Database Service on Cloud@Customer
In questo argomento vengono descritte le procedure per l'applicazione di patch e l'aggiornamento di 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 condbaascli
, fare riferimento a "Applicazione di patch ai database Oracle Grid Infrastructure e Oracle mediante dbaascli". - 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 essi, è possibile utilizzare la procedura riportata di seguito per risolvere i conflitti e procedere con l'upgrade.
Argomento padre: guide esplicative
Esegui aggiornamenti manutenzione gestita dall'utente
- 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.
Argomenti correlati
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
Informazioni su 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 - Aggiornamento del sistema operativo della VM guest
Scopri come 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. - 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 di Oracle Exadata Database Service on Cloud@Customer utilizzando la console o l'API di Oracle Cloud Infrastructure. - Aggiornamento dei database Oracle
Scopri come eseguire l'upgrade di un'istanza di database Exadata a Oracle Database 19c e Oracle Database 23ai utilizzando la console e l'API.
Argomenti correlati
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
- Prerequisiti per l'applicazione di patch e l'aggiornamento di un Oracle Exadata Database Service on Cloud@Customer System
Verificare e applicare le patch cloud più recenti scaricate e rese disponibili da Oracle sull'host CPS. - Uso della console per l'applicazione di patch e l'aggiornamento delle home GI e del database del cluster VM
Informazioni su come utilizzare la console per visualizzare la cronologia delle operazioni delle patch nel cluster VM e nelle home del database, applicare le patch e monitorare lo stato delle operazioni delle patch. - Utilizzo dell'interfaccia API per l'applicazione di patch e l'aggiornamento delle home del cluster VM e del database
Utilizzare varie funzioni API per facilitare la gestione dell'applicazione di patch a un sistema Oracle Exadata Database Service on Cloud@Customer.
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.
- 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.
- 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.
- Utilizzo della console per eseguire gli aggiornamenti di Grid Infrastructure
Verrà descritto come applicare gli aggiornamenti di Grid Infrastructure a un cluster VM. - Uso della console per eseguire l'operazione di aggiornamento su una home del database
Apprendere come applicare le patch in una home del database. - Utilizzo della console per visualizzare la cronologia degli aggiornamenti
Ogni voce della cronologia degli aggiornamenti rappresenta un tentativo di operazione di patch 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. - Uso 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.
Uso della console per eseguire gli aggiornamenti di Grid Infrastructure
Impara ad applicare gli aggiornamenti di Grid Infrastructure a un cluster VM.
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.
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
Informazioni su come visualizzare la cronologia delle patch applicate a un cluster VM. - Uso 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.
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.
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.
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.
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".
Argomenti correlati
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): - Utilizzo della console per aggiornare il sistema operativo della VM guest
Per aggiornare il sistema operativo della VM guest con la console, essere pronti a fornire i valori per i campi richiesti. - 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 richiesti. - Utilizzo dell'API per aggiornare il sistema operativo delle VM guest
Analizzare l'elenco delle chiamate API per aggiornare il sistema operativo delle VM guest.
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):
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.
Argomento padre: Aggiornamento del sistema operativo della VM guest
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.
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.
Argomento padre: Aggiornamento del sistema operativo della VM guest
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.
Argomento padre: Aggiornamento del sistema operativo della VM guest
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.
ListVmClusterUpdates
GetVmClusterUpdate
ListVmClusterUpdateHistoryEntries
GetVmClusterUpdateHistoryEntry
UpdateVmCluster
Per l'elenco completo delle interfacce API, vedere API del servizio di database.
Argomenti correlati
Argomento padre: Aggiornamento del sistema operativo della VM guest
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'upgrade 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. - 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. - Utilizzo dell'API per gestire l'upgrade di Oracle Grid Infrastructure
Esamina la lista delle chiamate API per gestire l'upgrade di Oracle Grid Infrastructure.
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)
Argomenti correlati
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 aggiornare Oracle Grid Infrastructure di un cluster VM
- 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
Al momento, l'aggiornamento di Grid Infrastructure da 19c a 23ai non è supportato per i cluster VM a nodo singolo.
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.
ListVmClusterUpdates
GetVmClusterUpdate
ListVmClusterUpdateHistoryEntries
GetVmClusterUpdateHistoryEntry
UpdateVmCluster
Per l'elenco completo delle interfacce API, vedere API del servizio di database.
Argomenti correlati
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 l'upgrade di un'istanza di Oracle Database Exadata Cloud@Customer. - Informazioni sull'upgrade di un Oracle Database
Prima di aggiornare il database, acquisire familiarità con le procedure riportate di seguito per preparare il database all'upgrade. - Modalità di esecuzione dell'operazione di aggiornamento da parte del servizio di database
Familiarizzare le operazioni eseguite dal servizio di database durante il processo di aggiornamento. - Ripristino di un aggiornamento di Oracle Database non riuscito
Se l'upgrade non viene completato correttamente, è possibile eseguire un rollback. - Dopo l'upgrade di un Oracle Database
Dopo un upgrade riuscito, tieni presente quanto segue: - Utilizzo della console per gestire l'upgrade di Oracle Database
Oracle consiglia di utilizzare l'azione di controllo preliminare per assicurarsi che il database soddisfi i requisiti per l'operazione di upgrade. - Utilizzo dell'interfaccia API per l'upgrade dei database Oracle
Esaminare la lista delle chiamate API per l'upgrade dei database Oracle.
Argomenti correlati
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.
- 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.
Argomenti correlati
Argomento padre: aggiornamento dei database Oracle
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).
Argomenti correlati
Argomento padre: aggiornamento dei database Oracle
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.
Argomento padre: aggiornamento dei database Oracle
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.
Argomenti correlati
Argomento padre: aggiornamento dei database Oracle
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
parametro che riflette la nuova versione del software Oracle Database. Per ulteriori informazioni, vedere Che cos'è la compatibilità di Oracle Database?.COMPATIBLE
- 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.
Argomenti correlati
Argomento padre: aggiornamento dei database Oracle
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 o l'upgrade di Oracle Database
- Uso della console per eseguire il rollback di un aggiornamento del database non riuscito
- Uso della console per visualizzare la cronologia di aggiornamento di un database
Argomento padre: aggiornamento dei database Oracle
Uso della console per eseguire il controllo preliminare dell'upgrade di Oracle Database o l'upgrade
Argomento padre: Utilizzo della console per gestire l'upgrade di Oracle Database
Uso della console per eseguire il rollback di un aggiornamento del database non riuscito
Argomento padre: Utilizzo della console per gestire l'upgrade di Oracle Database
Utilizzo della console per visualizzare la cronologia di aggiornamento di un database
Argomento padre: Utilizzo della console per gestire l'upgrade di Oracle Database
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.
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".
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 manualmente le patch al software. - Aggiornamento manuale del sistema operativo della VM guest
Ulteriori informazioni sugli strumenti e sulle tecniche Exadata standard che è possibile utilizzare per aggiornare i componenti del sistema operativo nelle VM guest di Oracle Exadata Database Service on Cloud@Customer.
Argomenti correlati
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.
- 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 per 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. - 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 Virtual Machine (VM) del server di database, utilizzare lo strumentopatchmgr
. - Installazione di ulteriori pacchetti del sistema operativo
Esaminare queste linee guida prima di installare ulteriori pacchetti del sistema operativo per Oracle Exadata Database Service on Cloud@Customer.
Argomenti correlati
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.
Argomenti correlati
Argomento padre: aggiornamento manuale del sistema operativo della VM guest
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
.
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
enode4
. In primo luogo, è possibile utilizzarenode1
per eseguire gli aggiornamenti dinode2
,node3
enode4
. Quindi, è possibile utilizzarenode2
per eseguire l'aggiornamento dinode1
.
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
enode2
. - 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.
- Raccogliere i dettagli dell'ambiente.
- Utilizzando SSH, connettersi a node1 come utente
opc
.Per istruzioni dettagliate, vedere Connessione a un nodo di calcolo con SSH.
- Avviare una shell del comando utente
root
.sudo su -
- 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
- Passare all'utente
grid
e identificare tutti i nodi nel cluster.su - grid
olsnodes
Ad esempio:olsnodes node1 node2
- Utilizzando SSH, connettersi a node1 come utente
- Configurare il sistema di guida.
- Tornare all'utente
root
innode1
e verificare se esiste una coppia di chiavi SSH (id_rsa
eid_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 | | . . + . | | ... | +-----------------+
- 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
- Nel nodo di destinazione (
node2
nell'esempio), aggiungere la chiave pubblica radice dinode1
al fileauthorized_keys
radice.cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
- 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
edbserver.patch.zip
: Aggiornamento del software Exadata Database Server mediante la utilityDBNodeUpdate
epatchmgr
: ID documento My Oracle Support 1553103.1. - 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
unzipdbserver.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 - Nella directory che contiene la utility
patchmgr
, creare il filedbs_group
che contiene la lista delle virtual machine da aggiornare. Includere i nodi elencati dopo aver eseguito il comandoolsnodes
nel passo 1, ad eccezione del sistema di guida. In questo esempio,dbs_group
contiene solonode2
.cd
/root/patch/18.1.4.0.0.180125.3/dbserver_patch_5.180228
cat dbs_group node2
- Tornare all'utente
- 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). - 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).
- 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
ooracle-ofed-release-guest
. Questi due RPM vengono gestiti automaticamente durante il processo di aggiornamento.
- Se si sta aggiornando il sistema dalla versione 12.1.2.3.4.170111 e i risultati del controllo preliminare includono
- 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)
- 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
- 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 aggiornarenode1
. - Come
root
In ogni virtual machine, eseguire il comandouptrack-install
per installare gli aggiornamentiksplice
disponibili.uptrack-install --all -y
uptrack-install --all -y
Argomenti correlati
Argomento padre: aggiornamento manuale del sistema operativo della VM guest
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.
Argomenti correlati
Argomento padre: aggiornamento manuale del sistema operativo della VM guest
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.
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 localerepo:package.rpm
: riferimento a un pacchetto in un repository YUM esistente
- 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.
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