Introdução

No post “Script oop_listener_helper.sh – Atualizando o LISTENER Durante o Out-Of-Place Patching” eu apresentei um exemplo de como o script oop_listener_helper pode ser usado no cenário de Out-Of-Place patching com Autoupgrade, com foco em ambientes Standalone (sem Grid Infrastructure).

Agora eu trago uma abordagem com uma sugestão do Rodrigo Jorge usando o recurso do AutoUpgrade que permite executar scripts automaticamente como uma ação de “Pré” ou “Pós” no deploy. Para isso, basta adicionar o parâmetro before_action ou after_action no arquivo de configuração da ferramenta. Você pode ver os detalhes dessas opções aqui na documentação.

O script

Neste post eu demonstro como usar a opção after_action para executar o script oop_listener_helper automaticamente após a fase de DEPLOY do AutoUpgrade. Para tornar isso viável sem ter que ficar editando o script com valores literaris a cada execução, eu criei um script auxiliar chamado autoupgrade_oop_listener_helper.

# is expected that Autoupgrade tool exports the root log directory as first path in the ORACLE_PATH variable.
AU_DB_DIR=$(echo "$ORACLE_PATH" | awk -F ":" '{print $1}')

# find the latest JOB created by Autoupgrade in the log dir
AU_DB_DIR_JOB=$(ls -d $AU_DB_DIR/[0-9]* | grep -v temp | sort -n | tail -1)

# get the full path of config file used by Autoupgrade tool
AU_DB_CONFIG=$AU_DB_DIR_JOB/patching/autoupgrade.cfg

# get the source and target home path from the config file
AU_DB_SOURCE_HOME=$(grep "source_home" $AU_DB_CONFIG | awk -F "=" '{print $2}')
AU_DB_TARGET_HOME=$(grep "target_home" $AU_DB_CONFIG | awk -F "=" '{print $2}')

# run the oop_listener_helper script with the source and target home defined in Autoupgrade config file
SCRIPT_DIR=$(dirname "$0")
$SCRIPT_DIR/oop_listener_helper.sh -sourcehome $AU_DB_SOURCE_HOME -desthome $AU_DB_TARGET_HOME -listener_home $AU_DB_TARGET_HOME -move

Basicamente o que esse script faz é achar o arquivo de configuração usado pela execução atual do Autoupgrade, capturar os caminhos informados como “source_home” e “target_home”, e por fim executar o script oop_listener_helper com a opção -move, passando os respectivos caminhos de Oracle Home.

Demo

0) Verificando o processo do Listener antes do teste (usando OH 19.22):

[oracle@lab06 ~]$ ps -ef | grep tns
oracle   14940     1  0 16:18 ?        00:00:00 /u01/app/oracle/product/19.22.0.0/dbhome_1/bin/tnslsnr LISTENER -inherit

1) No diretório usado para executar o Autoupgrade, crie um subdiretório useraction:

mkdir -p ~/autopatching/useraction

2) Crie os scripts oop_listener_helper.sh e autoupgrade_oop_listener_helper.sh, e conceda permissão de execução em ambos:

cd ~/autopatching/useraction
wget "https://github.com/maiconcarneiro/blog-dibiei/blob/main/autoupgrade_oop_listener_helper.sh"
wget "https://github.com/maiconcarneiro/blog-dibiei/blob/main/oop_listener_helper.sh"
chmod +x *oop_listener_helper.sh

A estrutura deve ficar similar a essa:

[oracle@lab06 autopatching]$ ls -l
total 5928
-rw-r--r-- 1 oracle oinstall 6065447 Dec  3 15:39 autoupgrade.jar
-rw-r--r-- 1 oracle oinstall     317 Dec  5 16:54 DB06A.cfg
drwx------ 2 oracle oinstall      90 Dec  3 15:41 keystore
drwxr-xr-x 2 oracle oinstall      78 Dec  5 17:01 useraction
[oracle@lab06 autopatching]$
[oracle@lab06 autopatching]$ ls -l useraction/
total 8
-rwxr-xr-x 1 oracle oinstall 1307 Dec  5 15:48 autoupgrade_oop_listener_helper.sh
-rwxr-xr-x 1 oracle oinstall 3527 Dec  5 15:49 oop_listener_helper.sh

3) No arquivo “.cfg”, inclua a opção after_action apontando para o script autoupgrade_oop_listener_helper.sh, conforme a linha 8 do exemplo abaixo:

[oracle@lab06 autopatching]$ cat DB06A.cfg
global.keystore=/home/oracle/autoupgrade-patching/keystore
patch1.source_home=/u01/app/oracle/product/19.22.0.0/dbhome_1
patch1.target_home=/u01/app/oracle/product/19.25.0.0/dbhome_1
patch1.sid=DB06A
patch1.folder=/u01/medias
patch1.patch=RECOMMENDED
patch1.after_action=useraction/autoupgrade_oop_listener_helper.sh

4) Agora basta executar o DEPLOY e aguardar a conclusão:

[oracle@lab06 autopatching]$ java -jar autoupgrade.jar -patch -config DB06A.cfg -mode deploy
No parameter 'global.global_log_dir' found in config file, using /u01/app/oracle/cfgtoollogs/autoupgrade_patching
AutoUpgrade Patching 24.8.241119 launched with default internal options
Processing config file ...
Loading AutoUpgrade Patching keystore
AutoUpgrade Patching keystore was successfully loaded

Connected to MOS - Searching for specified patches
...
...
...
patch> Job 111 completed
------------------- Final Summary --------------------
Number of databases            [ 1 ]

Jobs finished                  [1]
Jobs failed                    [0]
Jobs restored                  [0]
Jobs pending                   [0]

---- Drop GRP at your convenience once you consider it is no longer needed ----
Drop GRP from DB06A: drop restore point AU_PATCHING_9212_DB06A1922000


Please check the summary report at:
/u01/app/oracle/cfgtoollogs/autoupgrade_patching/cfgtoollogs/patch/auto/status/status.html
/u01/app/oracle/cfgtoollogs/autoupgrade_patching/cfgtoollogs/patch/auto/status/status.log

5) Você pode consultar o arquivo status.log no resumo acima e confirmar que a fase POSTACTIONS apresenta o status SUCCESS:

[oracle@lab06 autopatching]$ tail -13 /u01/app/oracle/cfgtoollogs/autoupgrade_patching/cfgtoollogs/patch/auto/status/status.log
------------------------------------------
[Stage Name]    POSTFIXUPS
[Status]        SUCCESS
[Start Time]    2024-12-05 16:59:26
[Duration]      0:00:11
[Log Directory] /u01/app/oracle/cfgtoollogs/autoupgrade_patching/DB06A/111/postfixups
[Detail]        /u01/app/oracle/cfgtoollogs/autoupgrade_patching/DB06A/111/postfixups/postfixups.html
------------------------------------------
[Stage Name]    POSTACTIONS
[Status]        SUCCESS
[Start Time]    2024-12-05 16:59:37
[Duration]      0:00:00
------------------------------------------

6) Essa fase não apresenta um caminho de log, mas ela tem um. Para achar ele, basta pegar o caminho apresentado na fase anterior até o número do JOB, e acessar o subdiretório “postaction”:

[oracle@lab06 autopatching]$ ls -lrt /u01/app/oracle/cfgtoollogs/autoupgrade_patching/DB06A/111/postaction/
total 8
-rw-r----- 1 oracle oinstall 1084 Dec  5 16:59 postactions.log
-rw-r----- 1 oracle oinstall 1854 Dec  5 16:59 action_stdout.log

7) No arquivo “action_stdout.log” podemos ver a saída da execução do script:

[oracle@lab06 autopatching]$ cat /u01/app/oracle/cfgtoollogs/autoupgrade_patching/DB06A/111/postaction/action_stdout.log
stdout starts

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 05-DEC-2024 16:59:37

Copyright (c) 1991, 2023, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lab06.dibiei.com)(PORT=1521)))
The command completed successfully

LSNRCTL for Linux: Version 19.0.0.0.0 - Production on 05-DEC-2024 16:59:37

Copyright (c) 1991, 2024, Oracle.  All rights reserved.

Starting /u01/app/oracle/product/19.25.0.0/dbhome_1/bin/tnslsnr: please wait...

TNSLSNR for Linux: Version 19.0.0.0.0 - Production
System parameter file is /u01/app/oracle/product/19.25.0.0/dbhome_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/lab06/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lab06.dibiei.com)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1522)))

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=lab06.dibiei.com)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 19.0.0.0.0 - Production
Start Date                05-DEC-2024 16:59:37
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/19.25.0.0/dbhome_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/diag/tnslsnr/lab06/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=lab06.dibiei.com)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1522)))
Services Summary...
Service "DB06A_test" has 1 instance(s).
  Instance "DB06A", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
Completed.

8) Verificando o processo do Listener depois do patch (usando OH 19.25):

[oracle@lab06 autopatching]$ ps -ef | grep tns
oracle     997     1  0 16:59 ?        00:00:00 /u01/app/oracle/product/19.25.0.0/dbhome_1/bin/tnslsnr LISTENER -inherit

Restrições

Essa abordagem não deve usar usada em um servidor com Grid infrastrcuture onde o Listener roda no home do Grid (o normal). Para esse tipo de ambiente, o Listener será movido automaticamente pelo processo de patch do Grid. O foco dessa abordagem é especificamente ambientes em que tem apenas o RDBMS software instalado, com o Database e Listener compartilhando o mesmo binário.

Conclusão

Com o exemplo demonstrado neste post, você deve conseguir aumentar o nível de automação ao aplicar patch usando a feature “One-Button Patching” do Autoupgrade em ambientes Standalone, uma vez que você poderá ter a instância RDBMS e o Listener executando no novo Oracle Home com apenas uma linha de comando.

Leave a Reply

Discover more from Blog do Dibiei

Subscribe now to keep reading and get access to the full archive.

Continue reading