Oracle
 sql >> Base de Dados >  >> RDS >> Oracle

Como reverter o patch após falha na fase de transição no R12.2


Pode haver um cenário  quando  fase de transição falhou. É possível voltar ao estado anterior de cutover (reverter o patch), se o banco de dados flashback estiver ativado no banco de dados ou se tivermos feito backup completo antes do cutover

Eu estaria explicando isso com relação ao Database Flashback para reverter o patch

Estou assumindo aqui que temos Flashback habilitado no banco de dados. Podemos confirmar isso usando o comando
SQL>select FLASHBACK_ON from v$database;
FLASHBACK_ON
------------
Yes

Você pode aprender mais sobre o banco de dados Flashback nos links abaixo

Flashback Oracle Database
Como fazer Flashback quando temos dataguard

É recomendável que a fase de transição do patch on-line seja programada para um momento em que haja poucas transações on-line e o processamento em lote seja mínimo. Você deve confirmar que as solicitações simultâneas críticas não estão sendo executadas durante a transição. Você também deve considerar colocar as solicitações simultâneas agendadas em espera antes de executar o cutover, caso contrário, a fase de cutover aguardará a conclusão do programa e você perderá os dados da transação em caso de flashback

Vejamos o Caso do Problema

Caso 1

Você está executando um ciclo de Patching Online:
$ adop phase=prepare
$ adop phase=apply patches=99999999
$ adop phase=finalize
$ adop phase=cutover

A transição falha e você precisa voltar ao estado do sistema antes de executar a fase de transição.

Se você não tivesse executado a fase de transição, você poderia reverter o processo de aplicação de patch executando a fase de anulação de adoção. No entanto, isso não é possível uma vez que o cutover tenha sido executado.

Há duas partes principais para reverter o patch:
(1) Restauração do banco de dados :O banco de dados Flashback é o método mais rápido para reverter as alterações do banco de dados e voltar ao ponto no tempo. Também podemos usar a técnica de restauração de banco de dados, mas isso consome muito tempo

Flashback do banco de dados
a). Primeiro, desligue o banco de dados e, em seguida, inicie-o no estado de montagem:
SQL>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>startup mount
ORACLE instance started.

b).Restaure o flashback para o tempo especificado.
SQL>flashback database to time to_data(<time before teh cutover>;
Flashback complete.

c).Inicie o banco de dados no modo somente leitura:
SQL>alter database open read only;
Database altered.

Check all looks as expected.

d). Desligue o banco de dados, inicie-o no estado de montagem e abra-o com a opção resetlogs:
SQL>shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>startup mount
ORACLE instance started.
Database mounted.
SQL>alter database open resetlogs;
Database altered.


2) Restauração do sistema de arquivos :Dependendo de quando a transição falhou, você também pode precisar restaurar os sistemas de arquivos da camada do aplicativo

Restaurando os sistemas de arquivos

A necessidade de executar esta etapa é condicional, dependendo se a transição falhou antes que os sistemas de arquivos fossem alternados. Você pode identificar qual desses casos se aplica consultando os logs de cutover em $NE_BASE/EBSapps/log/adop//cutover_ / para seu ID de sessão atual.

Caso 1 – Se as mensagens de log indicarem que a transição falhou antes que os sistemas de arquivos fossem alternados, faça um encerramento limpo de todos os serviços que estão em execução. Em seguida, reinicie todos os serviços usando o script de inicialização normal,

Caso 2 – Se as mensagens de log indicarem que a transição falhou após a troca dos sistemas de arquivos, siga a etapa abaixo para retornar os sistemas de arquivos.

(a) Encerre os serviços iniciados a partir do novo sistema de arquivos de execução

1.Forneça o ambiente no novo sistema de arquivos de execução.
2.De $ADMIN_SCRIPTS_HOME, encerre todos os serviços (usando adstpall .sh no UNIX).

(b)Em um ambiente de vários nós, repita as duas etapas anteriores em todos os nós, deixando o nó admin até depois de todos os nós escravos.

(c) Retornar os sistemas de arquivos
Em todos os nós em que os sistemas de arquivos foram trocados, execute o seguinte comando para retornar os sistemas de arquivos:
$ perl $AD_TOP/patch/115/bin/txkADOPCutOverPhaseCtrlScript.pl \
-action=ctxupdate \
-contextfile=<full path to new run context file> \
-patchcontextfile=<full path to new patch file system context file> \
-outdir=<full path to out directory>

(d)Inicie todos os serviços do sistema de arquivos de execução antigo (usando adstrtal.sh no UNIX).
(e)Em um ambiente de vários nós, repita as duas etapas anteriores em todos os nós, começando com o nó admin e, em seguida, prosseguir para os nós escravos

Conclusão

Após a conclusão da restauração, você tem duas opções básicas para prosseguir:
(a) Anular o ciclo de correção atual, se o problema que exigiu a restauração foi causado pelos patches que você estava tentando aplicar.

Aqui estão as etapas para abortar um ciclo de patch online

Se um ciclo de correção estiver falhando e o problema não puder ser resolvido rapidamente, é possível abortar o ciclo de correção e retornar à operação de tempo de execução normal. A edição do patch será descartada.

Você pode abandonar um ciclo de patch (sem aplicar nenhum patch) executando o comando:
$ adop phase=abort

Abortar um ciclo de patch eliminará a edição do patch, mas você deve executar as fases de limpeza e fs_clone antes de iniciar um novo ciclo de patch. A limpeza deve ser uma limpeza completa.
For example:
$ adop phase=prepare
$ adop phase=apply patches=9999999
$ adop phase=abort
$ adop phase=cleanup cleanup_mode=full
$ adop phase=fs_clone

Opcionalmente, você pode combinar os comandos abort e cleanup da seguinte forma:
$ adop phase=abort,cleanup cleanup_mode=full

(b) Identifique e corrija quaisquer outros problemas no ciclo de correção atual e prossiga com a correção.