A preparação da fase de adoção é a primeira fase do ciclo de aplicação de patches online na R12.2. Adop executa muitos itens de ação na fase.Aqui está a sequência de atividades
1.Verifica se deve realizar uma limpeza, que será necessária se o usuário não conseguir invocar a limpeza após a fase de transição de um ciclo de correção online anterior .

2. Valida a configuração do sistema para garantir que o sistema esteja pronto para iniciar um ciclo de correção online.

3.Verifica se o banco de dados está preparado para aplicação de patches online :

a) Verifica se o usuário do banco de dados está habilitado para edição. Caso contrário, o adopt sai imediatamente com um erro.

b) Verifica se o serviço de patch foi criado. adop requer a existência de um serviço de banco de dados especial com a finalidade de conectar-se à edição de patch. Este serviço é criado automaticamente, mas sua existência continuada é validada em cada preparação.

c) Verifica se o gatilho de logon existe e está ativado. Se o gatilho de logon estiver ausente ou o serviço de patch não tiver sido criado, o adop tentará corrigir o problema automaticamente para que possa prosseguir. Se não puder fazê-lo, sairá com uma mensagem de erro.

d) Verifica a integridade do dicionário de dados do banco de dados. Se alguma corrupção for encontrada, o adop sai com uma errorrease 12.2.

e) Verifica se o Verificador de Nível de Código da Tecnologia E-Business Suite (ETCC) foi executado, para verificar se todos os patches necessários foram aplicados ao banco de dados.
4. Verifica a configuração do sistema em cada nó de camada de aplicativo. Várias configurações críticas são validadas para garantir que cada nó da camada de aplicativo seja registrado, configurado e pronto para aplicação de patches corretamente.

Verifica o sistema de arquivos, usando o script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl . Este script verifica o espaço do sistema de arquivos, conexões de banco de dados, senhas de aplicativos/sistema/weblogic, validação de arquivo de contexto e assim por diante
E também produz um relatório mostrando informações sobre os espaços de tabela mais importantes que são gerados. Este relatório é criado em $APPL_TOP/admin/$TWO_TASK/out.
5. Verifica a existência do “Online Patching In Progress” (ADZDPATCH) programa concorrente. Este programa impede que determinados programas simultâneos predefinidos sejam iniciados e, como tal, precisa estar ativo enquanto um ciclo de correção estiver em andamento (ou seja, enquanto existir uma edição de correção de banco de dados).

O fluxo do processo é 

a.Se o programa ADZDPATCH ainda não tiver sido solicitado para ser executado, uma solicitação será enviada.Se não existir, o erro abaixo será relatado
ERRO na linha 1:

ORA-20008:Não foi definido nenhum gerenciador simultâneo que possa executar programas simultâneos

ADZDPATCH

b.O status de ADZDPATCH é determinado. Se estiver pendente, pode estar aguardando a conclusão de um programa incompatível. Depois que a incompatibilidade for eliminada, seu status mudará para em execução e permitirá que a fase de preparação continue. Uma mensagem para este efeito é exibida para o usuário.
c.A próxima etapa depende se os gerenciadores simultâneos estão em execução:

i.Se os gerenciadores simultâneos estiverem todos inativos, a fase de preparação continua, com ADZDPATCH entrando em um status de pendente (com a prioridade mais alta) até que os gerenciadores sejam iniciados.
ii.Se os gerenciadores simultâneos estiverem parcialmente ativos, mas não houver não houver gerenciador definido que possa executar o ADZDPATCH, a fase de preparação será encerrada com um erro.
iii.Se os gerenciadores simultâneos estiverem ativos e houver um definido que possa executar o ADZDPATCH, o processamento será repetido até que o ADZDPATCH altere o status de pendente para execução. A fase de preparação continua.
ADZDPATCH é cancelado quando a fase de transição é concluída.

Se você quiser que qualquer programa personalizado não seja executado no ciclo de patches, você terá que torná-lo incompatível com este programa
6.Invoca o script TXK $AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl para sincronizar os patches que foram aplicados à execução APPL_TOP, mas não ao patch APPL_TOP. O script depende do repositório adop para patches que foram aplicados na execução do APPL_TOP, mas não no patch APPL_TOP.

it Identifique os patches que foram aplicados à execução APPL_TOP e aplique-os ao patch APPL_TOP. As seguintes etapas são executadas automaticamente:

a.Os patches que precisam ser aplicados ao patch APPL_TOP são identificados no banco de dados.
b.Os patches mesclados são aplicados pelo utilitário adop.
O utilitário adop identifica os patches delta a serem aplicados, e os aplica silenciosamente ao patch atual APPL_TOP. Como este procedimento requer apenas a aplicação de patches delta, requer menos tempo

Em algumas circunstâncias, o método de sincronização de estilo delta (incremental) pode falhar ao aplicar uma série de patches à edição de patch. Isso pode acontecer se o ciclo de patch anterior incluir patches que não foram aplicados corretamente e foi seguido por patches subsequentes que corrigiram o problema.

O parâmetro skipsyncerror permite especificar que você espera que quaisquer erros de sincronização na fase de preparação sejam corrigidos automaticamente na sincronização que ocorre com os patches subsequentes.

Se o valor do parâmetro for passado como 'yes', o primeiro patch a ser sincronizado será feito com o sinalizador 'autoskip' configurado.
Importante:É sua responsabilidade verificar os arquivos de log e corrigir eventuais erros no a fase de aplicação subsequente ou para confirmar que a sincronização com patches subsequentes resolveu o problema.
Um exemplo de uso desse parâmetro seria o seguinte.

a.Você executa adop phase=prepare.
b.A fase falha com um erro ao tentar sincronizar os sistemas de arquivos de execução e correção. Ou seja, a tentativa de sincronizar um patch falha, mas sabe-se que um patch subsequente corrigirá o problema.
c.Você examina os arquivos de log e conclui que os erros de sincronização serão corrigidos automaticamente na sincronização que leva coloque com os patches subsequentes.
d.Você executa o comando adop phase=prepare skipsyncerror=yes para reiniciar a fase de preparação. Desta vez, a aplicação do patch que falhou na preparação anterior será repetida com o sinalizador 'autoskip' definido.
Sincronizando personalizações

O método padrão do estilo delta (incremental) de sincronização do sistema de arquivos trata de patches oficiais, mas não sincronizará nenhuma personalização aplicada manualmente. Exemplos de ações de patch que não são sincronizadas por padrão incluem:

Compilando JSPs definidos pelo usuário

Copiando algumas bibliotecas de terceiros

Copiando e compilando programas simultâneos definidos pelo usuário

Copiando e gerando formulários definidos pelo usuário
Para incluir ações de patch personalizadas na sincronização do sistema de arquivos padrão, você deve incluir os comandos necessários no Driver de sincronização personalizado, $APPL_TOP_NE/ad/custom/adop_sync.drv . Você adicionará suas personalizações à seguinte seção do arquivo:
#Begin Customization
…
#End Customization

Todas as ações definidas neste arquivo serão executadas pelo adop automaticamente durante a fase de preparação. Esteja ciente de que existem duas categorias de comandos personalizados em adop_sync.drv:aqueles que são executados apenas uma vez e aqueles que são executados em cada sincronização do sistema de arquivos (durante a fase de preparação de adop).
Importante:O adop_sync. drv não é redefinido para seu arquivo de modelo em nenhum momento. Conseqüentemente, após o cutover (e antes da próxima fase de preparação), você deve revisar o conteúdo de adop_sync.drv e garantir que os requisitos para seus comandos personalizados continuem sendo atendidos.
7. Verifica o banco de dados quanto à existência de um patch edição e cria uma se não encontrar uma.

a)Uma edição de patch é criada no banco de dados.
b)Todos os objetos de código na edição de patch começam como ponteiros para objetos de código na edição de execução. Objetos de código na edição de patch começam como “objetos de stub” leves que apontam para as definições de objetos reais, que são herdadas de edições anteriores. Objetos de stub consomem espaço mínimo, portanto, a edição de patch do banco de dados é inicialmente muito pequena em tamanho.
c) À medida que os patches são aplicados à edição de patch, os objetos de código são atualizados (têm uma nova definição criada) nessa edição.

8.Chama o script $AD_TOP/patch/115/bin/txkADOPPreparePhaseSanityCheck.pl novamente para confirmar se a conexão do banco de dados com a edição do patch está funcionando.

Artigos relacionados

Adoção explicada na R12.2

R12.2 Resumo do ciclo de correção on-line