Documentação do Oracle Cloud Infrastructure

Aplicando Patches e Atualizando um Sistema Exadata Cloud Infrastructure Manualmente

Este tópico descreve os procedimentos para aplicação de patch e atualização de vários componentes no Exadata Cloud Service fora da automação da nuvem.

Para obter informações relacionadas à aplicação de patches e à atualização com o dbaascli, consulte "Aplicando Patch no Oracle Grid Infrastructure e em Bancos de Dados Oracle com o Utilitário dbaascli".

Observação

Para obter mais orientações sobre a continuidade dos serviços durante as operações de aplicação de patch, consulte o white paper Application Checklist for Continuous Service for MAA Solutions.

Tópicos Relacionados

Tópico principal: Aplicar Patch e Atualizar um Sistema Exadata Cloud Infrastructure

Aplicando Patches ao Software Oracle Database e Oracle Grid Infrastructure Manualmente

Para horário de verão e alguns patches, de rotina ou one-off, pode ser necessário aplicar patch manualmente no software.

Para executar a aplicação de patch de rotina do software Oracle Database e Oracle Grid Infrastructure, a Oracle recomenda que você use os recursos fornecidos pelo Oracle Exadata Database Service on Dedicated Infrastructure. No entanto, em algumas circunstâncias, pode ser necessário aplicar patches no software Oracle Database ou Oracle Grid Infrastructure manualmente:
  • Patches de Horário de Verão (DST): Como eles não podem ser aplicados de maneira incremental, os patches das definições de DST do Oracle Database não estão incluídos nos conjuntos de patches de rotina do Exadata Cloud Infrastructure. Se você precisar aplicar patches às definições de Horário de Verão do Oracle Database, faça isso manualmente. Consulte o Doc ID 412160.1 do My Oracle Support.
  • Patches Fora da Rotina ou One-off: Se você encontrar um problema que exija um patch que não está incluído em qualquer conjunto de patches de rotina, trabalhe com o Suporte Técnico da Oracle para identificar e aplicar o patch correto.

Para obter informações gerais sobre aplicação de patch no Oracle Database, consulte informações sobre atualizações e requisitos de conjuntos de patches no Guia de Upgrade do Oracle Database para sua versão.

Atualizando o Sistema Operacional do Cluster de VMs do Exadata Cloud Manualmente

Atualize os sistemas operacionais dos nós de computação do Exadata usando a ferramenta patchmgr.

Este utilitário gerencia a atualização inteira de um ou mais nós de computação remotamente, incluindo a execução das etapas de pré-reinicialização, reinicialização e pós-reinicialização. Você pode executar o utilitário de um nó de computação do Exadata ou de um servidor que não seja do Exadata e execute o Oracle Linux. O servidor no qual você executa o utilitário é conhecido como " sistema de acionamento". Você não pode usar o sistema de acionamento para atualizar ele mesmo. Portanto, se o sistema de acionamento for um dos nós de computação do Exadata em um sistema que você está atualizando, execute uma operação separada em outro sistema de acionamento para atualizar esse servidor.

Os dois seguintes cenários descrevem formas típicas de executar as atualizações:

Cenário 1: Sistema de Acionamento Não Exadata

A forma mais simples de executar a atualização do sistema Exadata é utilizar outro servidor Oracle Linux para atualizar todos os nós de computação do Exadata no sistema.

Cenário 2: Sistema de Acionamento de Nó Exadata

Você pode usar um nó de computação do Exadata para acionar as atualizações do restante dos nós de computação no sistema e, em seguida, usar um dos nós atualizados para acionar a atualização no nó original do driver do Exadata.

Por exemplo: Você está atualizando um sistema Exadata half rack que tem quatro nós de computação - node1, node2, node3 e node4. Primeiro, use node1 para acionar as atualizações do node2, node3 e node4. Em seguida, use node2 para acionar a atualização de node1.

O sistema de acionamento requer acesso via SSH do usuário raiz a cada nó de computação que o utilitário atualizará.

Tópico principal: Aplicando Patch e Atualizando um Sistema Exadata Cloud Infrastructure Manualmente

Preparação para as Atualizações do Sistema Operacional

Determine a versão mais recente do software disponível e a conectividade com o repositório yum apropriado

Cuidado:

Não instale o NetworkManager na instância do Exadata Cloud Infrastructure. A instalação desse pacote e a inicialização do sistema resultará em perda grave de acesso ao sistema.
  • Antes de começar suas atualizações, consulte Exadata Cloud Service Software Versions ( Doc ID 2333222.1) para determinar a versão de software mais recente e a versão de destino a ser usada.
  • Algumas etapas no processo de atualização exigem que você especifique um repositório YUM. O URL do repositório YUM é: 
    http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/<latest_version>/base/x86_64.

    Identificadores de região são strings de texto usadas para identificar regiões do Oracle Cloud Infrastructure (por exemplo, us-phoenix-1). Você pode encontrar uma lista completa de identificadores de região em Regiões.

    Você pode executar o seguinte comando curl para determinar a versão mais recente do repositório YUM para a região da instância do Exadata Cloud Service: 
    curl -s -X GET http://yum-<region_identifier>.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
    Este exemplo retorna a versão mais atual do repositório YUM para a região Oeste dos EUA (Phoenix): 
    curl -s -X GET http://yum-us-phoenix-1.oracle.com/repo/EngineeredSystems/exadata/dbserver/ |egrep "18.1."
<a href="18.1.4.0.0/">18.1.4.0.0/</a> 01-Mar-2018 03:36 -
  • Para aplicar atualizações do sistema operacional, a VCN do sistema deve estar configurada para permitir acesso ao repositório YUM. Para obter mais informações, consulte Opção 2: Gateway de Serviço para o Object Storage e o repositório YUM .

Para atualizar o sistema operacional em todos os nós de computação de uma instância do Exadata Cloud Infrastructure

Procedimento para atualizar todos os nós de computação usando patchmgr.

Este exemplo de procedimento presume o seguinte:

  • O sistema tem dois nós de computação, node1 e node2.
  • A versão de destino é 18.1.4.0.0.180125.3.
  • Cada um dos nós é usado como o sistema de acionamento para a atualização no outro.
  1. Obtenha os detalhes do ambiente.
    1. SSH ao node1 como root e execute o seguinte comando para determinar a versão do Exadata:
      [root@node1]# imageinfo -ver
12.2.1.1.4.171128
    2. Alterne para o usuário grid e identifique todos os cálculos no cluster.
      [root@node1]# su - grid
[grid@node1]$ olsnodes
node1
node1
  2. Configure o sistema de acionamento.
    1. Alterne para o usuário root no node1, verifique se já existe um par de chaves ssh raiz (id_rsa e id_rsa.pub). Caso contrário, gere-o.
      [root@node1 .ssh]#  ls /root/.ssh/id_rsa*
ls: cannot access /root/.ssh/id_rsa*: No such file or directory
[root@node1 .ssh]# 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.fraad1client.exadataclientne.oraclevcn.com
The key's randomart image is:
+--[ RSA 2048]----+
|o..     + .      |
|o.     o *       |
|E     . o o      |
| . .     =       |
|  o .   S =      |
|   +     = .     |
|    +   o o      |
|   . .   + .     |
|      ...        |
+-----------------+
    2. Distribua a chave pública para os nós de destino e verifique esta etapa. Neste exemplo, o único nó de destino é node2.
      [root@node1 .ssh]# scp -i ~opc/.ssh/id_rsa ~root/.ssh/id_rsa.pub opc@node2:/tmp/id_rsa.node1.pub
id_rsa.pub

[root@node2 ~]# ls -al /tmp/id_rsa.node1.pub
-rw-r--r-- 1 opc opc 442 Feb 28 03:33 /tmp/id_rsa.node1.pub
[root@node2 ~]# date
Wed Feb 28 03:33:45 UTC 2018
    3. No nó de destino (node2, neste exemplo), adicione a chave pública raiz de node1 ao arquivo authorized_keys raiz.
      [root@node2 ~]# cat /tmp/id_rsa.node1.pub >> ~root/.ssh/authorized_keys
    4. Faça download do dbserver.patch.zip como p21634633_12*_Linux-x86-64.zip no sistema de acionamento (node1, neste exemplo) e descompacte-o. Consulte dbnodeupdate.sh e dbserver.patch.zip: Updating Exadata Database Server Software using the DBNodeUpdate Utility and patchmgr (Doc ID 1553103.1) para obter informações sobre os arquivos nesse .zip.
      [root@node1 patch]# mkdir /root/patch
[root@node1 patch]# cd /root/patch
[root@node1 patch]# unzip p21634633_181400_Linux-x86-64.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
    5. Crie o arquivo dbs_group que contém a lista de nós de computação a serem atualizados. Inclua os nós listados depois de executar o comandoolsnodes na etapa 1, exceto o nó do sistema de acionamento. Neste exemplo, dbs_group deve incluir somente o node2.
      [root@node1 patch]# cd /root/patch/dbserver_patch_5.180228
[root@node1 dbserver_patch_5.180228]# cat dbs_group
node2
  3. Execute uma operação de pré-verificação de aplicação de patch.
    Observação

    você deve executar a operação de pré-verificação com a opção -nomodify_at_prereq para evitar qualquer alteração no sistema que possa impactar o backup a ser feito na próxima etapa. Caso contrário, o backup pode não conseguir fazer rollback do sistema para seu estado original, se necessário. 
    patchmgr -dbnodes dbs_group -precheck -yum_repo <yum_repository> -target_version <target_version> -nomodify_at_prereq
    A saída deve ser parecida com o seguinte exemplo: 
    [root@node1 dbserver_patch_5.180228]# ./patchmgr -dbnodes dbs_group -precheck -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -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. Faça backup do sistema atual.
    Observação

    Este é o estágio apropriado para fazer o backup, antes que sejam feitas modificações no sistema. 
    patchmgr -dbnodes dbs_group -backup -yum_repo <yum_repository> -target_version <target_version>  -allow_active_network_mounts
    A saída deve ser parecida com o seguinte exemplo: 
    [root@node1 dbserver_patch_5.180228]#  ./patchmgr -dbnodes dbs_group -backup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -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. Remova todos os RPMs personalizados dos nós de computação de destino que serão atualizados. Os RPMs personalizados são reportados nos resultados da pré-verificação. Eles incluem RPMs instalados manualmente depois que o sistema foi provisionado.
    • Se você estiver atualizando o sistema da versão 12.1.2.3.4.170111, e os resultados da pré-verificação incluírem krb5-workstation-1.10.3-57.el6.x86_64, remova-o. (Este item é considerado um RPM personalizado para essa versão.)
    • Não remova exadata-sun-vm-computenode-exact nem oracle-ofed-release-guest. Esses dois RPMs são tratados automaticamente durante o processo de atualização.
  6. Execute o comando nohup para fazer a atualização.
    nohup patchmgr -dbnodes dbs_group -upgrade -nobackup -yum_repo <yum_repository> -target_version <target_version> -allow_active_network_mounts &
    A saída deve ser parecida com o seguinte exemplo:
    [root@node1 dbserver_patch_5.180228]# nohup ./patchmgr -dbnodes dbs_group -upgrade -nobackup  -yum_repo  http://yum-phx.oracle.com/repo/EngineeredSystems/exadata/dbserver/18.1.4.0.0/base/x86_64 -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. Após a conclusão da operação de atualização, verifique a versão do kernel no nó de computação que foi atualizado.
    [root@node2 ~]# imageinfo -ver
18.1.4.0.0.180125.3
  8. Se o sistema de acionamento for um nó de computação que precisa ser atualizado (como neste exemplo), repita as etapas 2 a 7 desse procedimento usando um nó de computação atualizado como o sistema de acionamento para atualizar o nó de computação restante. Neste exemplo de atualização, você usaria o node2 para atualizar o node1.
  9. Em cada nó de computação, execute o comando uptrack-install como raiz para instalar as atualizações disponíveis do ksplice.
    uptrack-install --all -y

Instalando Pacotes Adicionais de Sistema Operacional

Verifique essas diretrizes antes de instalar pacotes adicionais de sistema operacional no Oracle Exadata Database Service on Dedicated Infrastructure.

É permitido instalar e atualizar pacotes de sistemas operacionais no Oracle Exadata Database Service on Dedicated Infrastructure, desde que você não modifique o kernel ou os pacotes específicos do InfiniBand. No entanto, o suporte técnico da Oracle, incluindo instalação, teste, certificação e resolução de erro, não se aplica a qualquer software que não seja da Oracle que você instale.

Além disso, lembre-se de que, se você adicionar ou atualizar pacotes separados de uma atualização de software do Oracle Exadata, essas adições ou atualizações de pacotes poderão apresentar problemas quando você aplicar uma atualização de software do Oracle Exadata. Podem ocorrer problemas porque pacotes de software adicionais incluem novas dependências que podem interromper uma atualização do Oracle Exadata. Por esse motivo, a Oracle recomenda minimizar a personalização.

Se você instalar pacotes adicionais, a Oracle recomenda que tenha scripts para automatizar a remoção e a reinstalação desses pacotes. Após uma atualização do Oracle Exadata, se você instalar pacotes adicionais, verifique se os pacotes adicionais ainda são compatíveis e se ainda precisa desses pacotes.

Para obter mais informações, consulte o Oracle Exadata Database Machine Maintenance Guide.

Atualizando o Conjunto de Ferramentas em uma Instância do Exadata Cloud Infrastructure

O conjunto de ferramentas específico da nuvem é usado nas VMs Convidadas do Exadata Cloud Infrastructure para operações locais, incluindo comandos dbaascli.

O conjunto de ferramentas da nuvem é atualizado automaticamente pela Oracle quando novas releases são disponibilizadas. Se necessário, você pode seguir as etapas em Atualizando o Conjunto de Ferramentas da Nuvem com o Utilitário dbaascli para garantir que tenha a versão mais recente do conjunto de ferramentas na nuvem em todas as máquinas virtuais do cluster de VMs