Lembretes para aplicar as correcções da CPU Oracle

by Rackspace Technology Staff

Introdução Este blogue analisa a importância da execução de um ciclo ADOP (Application DBA Online Patching Utility) com fs_clone após a realização de quaisquer alterações ou patches tecnológicos nos diretórios home do Weblogic Server (WLS) ou do Oracle© Fusion Middleware (FMW) no seu sistema de ficheiros de patches. O blogue explora um cenário problemático e explica como lidar facilmente com questões relacionadas.

As fases do ciclo ADOP

A imagem seguinte mostra as fases do ciclo ADOP:

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Fonte da imagem

Histórico do problema

Depois de aplicar patches de atualização de caminho crítico (CPU) a uma instância do Oracle versão R12.2 em um sistema de arquivos de patch, o ADOP concluiu uma execução de ciclo completo (preparar, aplicar, finalizar, transferir e limpar). Depois de executar outro ciclo ADOP para uma atividade diferente, a instância foi clonada para outro servidor.

No entanto, ao aplicar os patches do WLS no novo ambiente clonado, o sistema encontrou um conflito. A correção apontava para uma incompatibilidade de versões do WLS.

Análise

A investigação mostrou que as correcções da CPU anteriormente aplicadas ao WLS e ao FMW Web Tier e aos diretórios domésticos comuns da Oracle não foram incluídas no sistema de ficheiros de execução e correção.Numa investigação mais aprofundada aos ficheiros de registo ADOP, reparámos que o ficheiro de preparação sincronizou o sistema de ficheiros, no entanto não conseguimos ver as alterações feitas aos diretórios Oracle\_home e FMW\_home durante o ciclo de aplicação de patches.

Dedução:

Da nossa análise, retiramos as seguintes conclusões:

1. A sincronização de ficheiros na fase de preparação é apenas para a APPL\_TOP.

Os ficheiros de registo que analisámos mostraram a propagação das alterações do sistema de ficheiros da execução    APPL\_TOP para o patch APPL\_TOP.

2. Após a aplicação dos patches do Weblogic, `fs_clone` não foi executado antes de iniciar o próximo ciclo ADOP. Assim, os novos patches não aparecem na unidade sucessiva, mesmo após a conclusão do segundo ciclo ADOP, e não estavam disponíveis na instância clonada.

Recomendação

Na fase de preparação, o sistema de ficheiros de correção é normalmente sincronizado com o sistema de ficheiros de execução através da criação de uma nova edição da base de dados. Esta é uma sincronização incremental predefinida de ficheiros que são alterados no topo da aplicação.

Para sincronizar os patches aplicados, invoquexkADOPPreparePhaseSynchronize.pl para o $APPL\_TOP do sistema de ficheiros de execução do último ciclo de patching ou invoque `fs_clone`. Neste caso, nós não chamamos a função `fs_clone`. Em vez disso, chamamos FsCloneStage e `sCloneApply para o $APPL_TOP, que é muito dessincronizado.

O método de sincronização do sistema de ficheiros é selecionado automaticamente com base no Detetor de Alterações de Configuração (`adConfigChangeDetector.pl -detectConfigChanges`)

Os diferentes métodos de sincronização de ficheiros incluem as seguintes opções:

Opção 1 - identificar os patches da base de dados que foram aplicados no último ADOP. Fundir e aplicar estes silenciosamente. Este processo demora menos tempo porque o sistema aplica apenas os patches não aplicados.

Opção 2 - Recriar ou reclonar o sistema de ficheiros de execução $APPL\_TOP para o sistema de ficheiros de correção $APPL\_TOP. Isto é extremamente dessincronizado e consome mais recursos.

Opção 3 - Utilize o software de terceiros da sua escolha (como `rsync`) para sincronizar o sistema de ficheiros.

Parâmetros transmitidos com o prepare

`Prepare` utiliza os seguintes parâmetros:

a) Utilize a opção `Skipsyncerror` na fase de preparação do ADOP para ignorar erros e   avisos como solução alternativa para erros e falhas de sincronização, que podem ocorrer se a aplicação do patch falhar num ciclo de patching anterior. O valor  predefinido de    é NO.

sintaxe : `adop phase=prepare skipsyncerror=yes`

b) Utilize a opção `sync_mode` para especificar o método a ser utilizado para sincronizar o sistema de arquivos de patch com um sistema de arquivos em execução. Sintaxe `adop phase=prepare sync_mode=(delta|patch)`

sync_mode patch - Reaplica os patches que já foram aplicados para executar o sistema de  ficheiros    (modo predefinido).    sync_mode delta - Copia todas as personalizações e alterações de ficheiros. Este modo    utiliza o comando de sincronização do ficheiro delta\_sync\_drv.txt e    é uma nova funcionalidade do `AD-TXK delta 8`.  

ADOP comando fs_clone

O comando `fs_clone` recria ou reclona todo o sistema de arquivos de correção, incluindo a definição de todas as configurações e personalizações no sistema de arquivos de correção da mesma maneira que o sistema de arquivos em execução. Fazer isso é tão intensivo em recursos quanto fazer um backup completo do sistema de arquivos em execução e, em seguida, criar um sistema de arquivos de correção.

`fs_clone` tem os seguintes comandos úteis:

  • - `adop phase=fs_clone force=yes ` - Reinicia um clone falhado desde o início
  • (predefinição=NO).
  • - `adop phase=fs_clone s_fs_backup_count=1` - Define o número de cópias de segurança do
  • sistema de ficheiros de correção a ser preservado antes de poder ser recriado a partir da execução
  • sistema de ficheiros (predefinição=0 não são efectuadas cópias de segurança).

Principais conclusões

Mesmo que a fase de preparação seja executada no início de cada ciclo de aplicação de patches, os patches da pilha de tecnologia (aplicados pelo utilitário `opatch/Smart update`) não são sincronizados na fase de preparação.

  • A preparação não sincroniza quaisquer alterações efectuadas manualmente, por exemplo:
  • Compilação de JSPs definidos pelo utilizador.
  • Cópia de bibliotecas de terceiros.
  • Cópia e compilação de programas concorrentes definidos pelo utilizador.
  • Copiar e gerar formulários definidos pelo utilizador.

É necessário adicionar as acções de correção personalizadas (como as descritas anteriormente) no controlador de sincronização personalizado, `adop_sync.drv`, na fase de preparação.

No ficheiro, `adop_sync.drv, existem as seguintes categorias de comandos:

  • Executar uma única vez
  • Executar em cada sincronização do sistema de ficheiros

Para copiar personalizações e alterações de ficheiros na fase de preparação, utilize o seguinte comando :

`ADOP phase=prepare sync_mode=(delta|patch)`

Se quaisquer patches abortados ou quaisquer patches de manutenção ou Release Update Pack (RUP) forem aplicados, `fs_clone` deve ser executado no final para recriar o sistema de arquivos de patches como uma cópia exata do sistema de arquivos em execução.

Conclusão

Sempre que forem efectuadas alterações aos componentes do Weblogic Server ou do Fusion Middleware da versão 12.2 do E-Business Suite, é imperativo que os administradores da base de dados executem `fs_clone` para garantir que o sistema de ficheiros de correção é atualizado com todas as alterações mais recentes efectuadas ao WLS ou ao FMW do sistema de ficheiros executado.

Saiba mais sobre nossos serviços AWS