Rolling Upgrades com Oracle Data Guard 11g

Por Flávio Soares
Postado en abril 2012

Realizar upgrade de versão em banco de dados Oracle, sempre foi um desafio para ambientes 24/7, hoje isso já é uma realidade totalmente diferente graças aos produtos inovadores que a Oracle tem lançado. O Oracle Data Guard 11g é um dos produtos chaves da Oracle Maximum Availability Architecture (MAA) que permite a realização de upgrade com um tempo mínimo de parada do ambiente.

Um upgrade, por exemplo, de um banco da versão 10g para 11g requer horas com o ambiente totalmente parado. Com o Oracle Físico Data Guard 11g pode ser utilizado para executar rolling upgrades com tempos de parada próximos a zero e que reverte todo esse tempo de parada em tempo de utilização normal do banco de dados. O rolling upgrade é executado em cima de uma estrutura físico já existente do banco de dados standby e usa o banco de dados transient logical standby para que o SQL Apply suporte o mecanismo de aplicação dos dados de redo.

O rolling upgrade, de acordo com a Oracle, suporta os seguintes tipos de patchs:

• Patchset Updates (PSUs).
• Critial Patch updates (CPUs).
• Online Patching para banco de dados.
• Oracle ASM rolling upgrades.
• Patches de Oracle RAC rolling upgrades.
• Patches de CRS rolling upgrades.

Além da óbvia vantagem da economia de tempo na atualização do seu banco de dados, podemos encontrar muitos outros benefícios da utilização do rolling upgrade com Oracle Data Guard 11g, entre as quais podemos destacar:

• Pode-se recompilar os objetos inválidos depois do upgrade sem um tempo de parada da aplicação.
• É possível validar o banco de dados na nova versão, antes de entregar para produção.
• Descarta a possíbilidade de um grande período de parada do ambiente de produção.
• Depois de todo processo feito, o banco produção como o de contigência estará na nova versão desejada.

Além disso, a Oracle fornece um Bourne shell script chamado physru que é disponível no My Oracle Support (http://support.oracle.com) através do documento id número: 949322.1.

Esse script foi desenvolvido pela Oracle para automatizar operações de rolling upgrades que torna extremamente fácil toda ação de upgrade. O script physru faz toda parte trabalhosa e conduz do início ao fim da atualização reduzindo assim toda complexidade do rolling upgrade.

Os pré-requisitos

Para a realização do rolling upgrade com o Oracle Data Guard 11g, alguns pré-requisitos devem ser cumpridos para o maior êxito na execução. Seguem na lista abaixo:

● O Flashback Database deve estar obrigatóriamente habilitado.
● Certifique que o banco primário está sincronizado com o banco de dados standby físico.
● Verifique os parâmetros LOG_ARCHIVE_DEST_n e veja se eles estão corretamente definidos para as realizações de switchover's.
● A configuração de Oracle Data Guard Broker deve ser desabilitado.
● Para que o Transient Logical Standby Database trabalhe perfeitamente cada linha do seu banco de dados devem ser unicamente identificadas. Veja aqui como fazer isso:
http://docs.oracle.com/cd/E11882_01/server.112/e10700/create_ls.htm#i76646.
● É necessário que as entradas estatíca de cada um dos bancos de dados (produção e standby) sejam definidos no listener.

Visão geral das execuções do script physru

Será demonstrado aqui um breve resumo de todos os passos percorrido pelo script physru para que o rolling upgrade possa ocorrer e fazer assim a atualização do banco de dados com o mínino downtime. Ao todo serão três execuções necessárias do script, segue os detalhes de cada uma delas:

- Primeira execução do script physru.

Esse é o momento de preparação do ambiente. Nessa etapa o script physru irá criar um GRP - Guaranteed Restore Points (http://docs.oracle.com/cd/E11882_01/backup.112/e10642/flashdb.htm) tanto para o banco primário como para o banco físico standby.

O script terá também a tarefa de converter o banco standby físico em um transient logical standby database.

- Segunda execução do script physru.

O banco standby nesse estágio já deve ter sido atualizado para a versão desejada através do catupgrd script ou DBUA e assim o physru fará o switchover para o standby transient logical database atualizado, o banco standby passará a ser o produção na nova versão e o banco primário original será executado o flashback atráves do GRP e logo após será convertido em um novo standby físico.

Após esses passos o script deixará o novo banco de standby (antigo produção) baixado.

- Terceira execução do script physru.

A terceira e última execução do script physru fará a sincronização de todos os dados de redo que gerou durante todos os processos anteriores.

Após tudo sincronizado (banco standby com produção) os dois bancos devem estar na nova versão deseja o physru fornecerá a opção de realizar mais um switchover para voltar o novo banco standby em modo primário, deixando o cenário exatamente antes de executar o primeiro script, porém na nova versão deseja.

Após tudo feito, o script physru ainda fará a limpeza dos Guaranteed Restore Points criados da primeira execução.

Realizando Rolling Upgrade usando um Oracle Data Guard 11g Físico Standby Database

Agora que você já conhece os conceitos de rolling upgrade com Oracle Data Guard 11g e sabe as suas vantagens, veremos a partir de agora o passo a passo de como realizar todo o processo desde a realização dos pré-requisitos até o termino da atualização do ambiente.

Estaremos realizando um upgrade da versão 11.2.0.2.0 para a 11.2.0.3.0 utilizando para isso o conceito de rolling upgrade com Oracle Físico Data Guard 11g.

Para acompanhar os testes abaixo, você deverá ter um banco de dados no qual será o banco primário e um outro banco que será o Oracle Físico Data Guard 11g do ambiente, ambos na versão 11.2.0.2. No link a seguir está a documentação oficial da Oracle para a criação de um Físico Data Guard 11g:
http://docs.oracle.com/cd/E11882_01/server.112/e25608/create_ps.htm

Além desses bancos na versão 11.2.0.2 será necessário que o binário da versão 11.2.0.3 também esteja instalado nos dois servidores.

Segue mais detalhes do nosso ambiente, para o teste de rolling upgrade com Data Guard.

Ambiente Primário (Produção)
Nome do banco de dados: prima
Nome do servidor: serverprd
Instalação do 11.2.0.2: /u01/app/oracle/product/11.2.0.2/db_home1
Instalação do 11.2.0.3: /u01/app/oracle/product/11.2.0.3/db_home1
Versão atual do banco de dados: 11.2.0.2
Versão após rolling upgrade: 11.2.0.3

Ambiente Standby (Contigência)
Nome do banco de dados: stdby
Nome do servidor: serverstd
Instalação do 11.2.0.2: /u01/app/oracle/product/11.2.0.2/db_home1
Instalação do 11.2.0.3: /u01/app/oracle/product/11.2.0.3/db_home1
Versão atual do banco de dados: 11.2.0.2
Versão após rolling upgrade: 11.2.0.3

Obs: No final do upgrade, ambos os bancos de dados (prima e stdby) estarão na versão 11.2.0.3

Realizando os pré-requisitos

- Entradas estáticas do Listener.

As entradas estáticas no listener do Oracle se faz necessárias pois isso envolve diretamento no processo do rolling upgrade. Com as entradas dos bancos primário e standby no listener permite que o script physru conecte a instância mesmo se ela estiver baixada.

Para realizar esse procedimento é necessário definir as entradas como abaixo no arquivo $ORACLE_HOME/network/admin/listener.ora e logo após fazer com que o listener seja recarregado.

[oracle@serverprd ~]$ vi $ORACLE_HOME/network/admin/listener.ora
SID_LIST_LISTENER =
(SID_LIST =
      (SID_DESC =
            (GLOBAL_DBNAME = prima)
            (ORACLE_HOME = /u01/app/oracle/product/11.2.0.2/dbhome_1)
            (SID_NAME = prima)
       )
)

[oracle@serverprd ~]$ lsnrctl reload
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 14-MAR-2012 21:13:43

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

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=serverprd)(PORT=1521)))
The command completed successfully

Os mesmos passos, devem ser feitos agora no servidor standby (serverstd), onde está nosso banco de contigência Oracle Físico Data Guard 11g.

[oracle@serverstd ~]$ vi $ORACLE_HOME/network/admin/listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = stdby)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0.2/dbhome_1)
(SID_NAME = stdby)
)
)

[oracle@serverstd ~]$ lsnrctl reload
LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 14-MAR-2012 21:13:43

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

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=serverstd)(PORT=1521)))
The command completed successfully

- Desabilitando o Oracle Data Guard Broker.

É necessário também que o Oracle Data Guard Broker esteja desabilitado. Para isso execute o seguinte comando no banco de dados prima e stdby, caso o seu Data Guard Broker esteja configurado.

alter system set dg_broker_start=false;

Lembrando apenas, que é possível reinstalar o Data Guard Broker após o rolling upgrade.

- Habilite o Flashback Database.

Como o Data Guard Rolling Upgrade é envolvido diretamente com a tecnologia flashback, assim o banco de dados primário e standby devem estar com o Flashback Database ativo. Segue os passos necessários.

Vamos primeiro aqui, ativar o Flashback Database no banco primário, que no nosso caso é o banco prima.

SYS@prima> alter database flashback on;

Agora que nosso banco primário está com o Flashback Database habilitado, vamos fazer o mesmo procedimento no banco standby (stdby). Como o banco stdby é um Oracle Físico Data Guard, devemos primeiro desabilitar managed recovery operations antes de habilitar o Flashback Database, observe:

SYS@stdby> alter database recover managed standby database cancel;
SYS@stdby> alter database flashback on;
SYS@stdby> alter database recover managed standby database disconnect;

Feito esses passos o banco de contigência stdby estará com o Flashback Database Habilitado.

Lembrando apenas que para ativar o Flashback Database, a fast recovery area deve estar habilitada.

- Linhas unicamente identificadas.

Como o Oracle utiliza a chave primária e/ou um único índice para lógicamente identificar e modificar as linhas no standby é preciso com que cada linha do seu banco seja possível de ser identificada unicamente.

Mais porque cada linha do banco tem que ser unicamente identificada? Como o banco de standby é sempre restaurado (restore) de um cópia do banco de produção (backup), assim os ROWIDs que contém o registro de identificação de cada linha do banco de dados não pode ser usado já que eles não correspondem mais ao banco de origem devido ao restore feito. Com isso o Oracle utiliza a chave primária e/ou um índice único para encontrar as linhas necessárias para ser modificada no banco standby.

Para mais detalhes veja na própria documentação:

http://docs.oracle.com/cd/E11882_01/server.112/e10700/create_ls.htm#i77026

- Baixe o Bourne Script Shell physru.

Como explicado anteriormente, o script physru foi criado para facilitar o processo de Rolling Upgrade com Oracle Data Guard 11g. Este shell pode ser baixado diretamente pelo My Oracle Support Note 949322.1.

Executando para o Rolling Upgrade.

Com o physru no servidor de standby (serverstd), vamos dar a permissão de execução no script.

[oracle@serverstd ~]$ chmod +x physru

O script physru deverá ser executado três vezes ao todo, como já mencionado, todas essas execuções devem ser feitas na máquina de standby, no nosso caso a máquina serverstd, sempre da mesma forma.

A sintaxe para a execução do physru consiste dos seguintes parâmetros:

1ª parâmetro = <username> Deve ser utilizado o usuário sys.
2ª parâmetro = <primary_tns> O serviço de TNS do banco primário.
3ª parâmetro = <standby_tns> O serviço de TNS do banco standby.
4ª parâmetro = <primary_name> O db_unique_name do banco primário.
5ª parâmetro = <standby_name> O db_unique_name do banco standby.
6ª parâmetro = <upgrade_version> A versão do banco de dados destino.

No nosso caso, aplicaremos o script seguinte maneira:

physru sys tns_prima tns_stdby prima stdby 11.2.0.3.0

Onde:

- O usuário utilizado será o sys.
- O TNS para a conexão do banco prima será o tns_prima.
- O TNS para a conexão do banco stdby será o tns_stdby.
- O db_unique_name do banco prima será o prima.
- O db_unique_name do banco stdby será o stdby.
- A versão desejada para o upgrade é a 11.2.0.3.0

Vamos então a primeira execução do script. Acompanhe os logs:

[oracle@serverstd ~]$ ./physru sys tns_prima tns_stdby prima stdby 11.2.0.3.0
Please enter the sysdba password:
### Initialize script to either start over or resume execution
Mar 14 21:28:30 2012 [0-1] Identifying rdbms software version
Mar 14 21:28:30 2012 [0-1] database prima is at version 11.2.0.2.0
Mar 14 21:28:31 2012 [0-1] database stdby is at version 11.2.0.2.0

[…]
WARN: 
     Objects have been identified on the primary database which will not be
     replicated on the transient logical standby. The complete list of
     objects and their associated unsupported datatypes can be found in the    
     dba_logstdby_unsupported view. For convenience, this script has written
     the contents of this view to a file - physru_unsupported.log.
     
     Various options exist to deal with these objects such as:
       - disabling applications that modify these objects
       - manually resolving these objects after the upgrade
       - extending support to these objects (see metalink note: 559353.1)

     If you need time to review these options, you should enter 'n' to exit
     the script. Otherwise, you should enter 'y' to continue with the
     rolling upgrade.

Are you ready to proceed with the rolling upgrade? (y/n): y

Observe que o script identificou que os bancos prima e stdby estão na versão 11.2.0.2.0 e também nos relata que foram encontrados alguns objetos que não serão replicados no transient logical standby, pois não suporta determinados tipos de dados. Aceite que você está pronto para o procedimento com um y e veja a continuação do processo.

Mar 14 21:34:32 2012 [2-1] continuing
Mar 14 21:34:33 2012 [2-2] starting media recovery on stdby
Mar 14 21:34:39 2012 [2-2] confirming media recovery is running
Mar 14 21:34:39 2012 [2-2] waiting for v$dataguard_stats view to initialize
Mar 14 21:34:43 2012 [2-2] waiting for apply lag on stdby to fall below 30 seconds
Mar 14 21:35:21 2012 [2-2] current apply lag: 258
Mar 14 21:35:51 2012 [2-2] apply lag is now less than 30 seconds
Mar 14 21:35:51 2012 [2-2] stopping media recovery on stdby
Mar 14 21:35:52 2012 [2-2] executing dbms_logstdby.build on database prima
Mar 14 21:36:32 2012 [2-2] converting physical standby into transient logical
standby
Mar 14 21:36:58 2012 [2-3] opening database stdby
Mar 14 21:37:22 2012 [2-4] configuring transient logical standby parameters for
rolling upgrade
Mar 14 21:37:24 2012 [2-4] starting logical standby on database stdby
Mar 14 21:37:43 2012 [2-4] waiting until logminer dictionary has fully loaded
Mar 14 21:42:47 2012 [2-4] dictionary load 03% complete
Mar 14 21:42:58 2012 [2-4] dictionary load 30% complete
Mar 14 21:43:08 2012 [2-4] dictionary load 50% complete
Mar 14 21:46:49 2012 [2-4] dictionary load 85% complete
Mar 14 21:47:10 2012 [2-4] dictionary load is complete
Mar 14 21:47:11 2012 [2-4] waiting for v$dataguard_stats view to initialize
Mar 14 21:47:26 2012 [2-4] waiting for apply lag on stdby to fall below 30 seconds
Mar 14 21:47:27 2012 [2-4] apply lag is now less than 30 seconds

NOTE: 
     Database stdby is now ready to be upgraded. This script has left the
     database open in case you want to perform any further tasks before
     upgrading the database. Once the upgrade is complete, the database must
     opened in READ WRITE mode before this script can be called to resume the
     rolling upgrade.
     
NOTE: 
     If stdby was previously a RAC database that was disabled, it may be
     reverted back to a RAC database upon completion of the rdbms upgrade.
     This can be accomplished by performing the following steps:

        1) On instance stdby, set the cluster_database parameter to TRUE.
        eg: SQL> alter system set cluster_database=true scope=spfile;

        2) Shutdown instance stdby.
        eg: SQL> shutdown abort;

        3) Startup and open all instances for database stdby.
        eg: srvctl start database -d stdby

Agora nosso standby físico foi convertido em um banco transient logical standby e está pronto para ser atualizado, como mostra no log acima. Antes de continuar, vamos confirmar se nosso banco standby realmente foi transformado.

Conecte no banco stdby e use a seguinte consulta:

SYS@stdby> select db_unique_name, database_role from v$database;

DB_UNIQUE_NAME                  DATABASE_ROLE
------------------------        ----------------
stdby                           LOGICAL STANDBY

Feito a checagem podemos continuar. Baixe o banco stdby para o início do upgrade.

SYS@stdby> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

Nesse passo copiaremos os arquivos necessários de um ORACLE HOME para outro. Para isso desconecte do SQL*Plus e cópie os arquivos password file, spfile, tnsnames do home 11.2.0.2 para o 11.2.0.3, tanto na servidor serverprd como no serverstd.

No servidor serverprd:

[oracle@serverprd ~]$ cd /u01/app/oracle/product/
[oracle@serverprd product]$ cp 11.2.0.2/dbhome_1/dbs/orapwprima 11.2.0.3/dbhome_1/
dbs/.
[oracle@serverprd product]$ cp 11.2.0.2/dbhome_1/dbs/spfileprima.ora 11.2.0.3/
dbhome_1/dbs/.
[oracle@serverprd product]$ cp 11.2.0.2/dbhome_1/network/admin/*.ora 11.2.0.3/
dbhome_1/network/admin/.

Agora no servidor serverstd:

[oracle@serverstd ~]$ cd /u01/app/oracle/product/
[oracle@serverstd product]$ cp 11.2.0.2/dbhome_1/dbs/orapwstdby 11.2.0.3/dbhome_1/
dbs/.
[oracle@serverstd product]$ cp 11.2.0.2/dbhome_1/dbs/spfilestdby.ora 11.2.0.3/
dbhome_1/dbs/.
[oracle@serverstd product]$ cp 11.2.0.2/dbhome_1/network/admin/*.ora 11.2.0.3/
dbhome_1/network/admin/.

Conectamos no SQL*Plus e iniciamos o banco stdby em modo startup upgrade. O início do processo de atualização da versão do banco é feito com o script catupgrd. Veja que subimos o banco com os binários da versão 11.2.0.3.0.

[oracle@serverstd ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0.3/dbhome_1
[oracle@serverstd ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@serverstd ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Wed Mar 14 21:50:26 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SYS@stdby> startup upgrade
ORACLE instance started.

Total System Global Area 835104768 bytes
Fixed Size 2232960 bytes
Variable Size 704646528 bytes
Database Buffers 121634816 bytes
Redo Buffers 6590464 bytes
Database mounted.
Database opened.
SYS@stdby> @?/rdbms/admin/catupgrd
[...]
SQL> DOC
DOC>#######################################################################
DOC>#######################################################################
DOC>
DOC> The above sql script is the final step of the upgrade. Please
DOC> review any errors in the spool log file. If there are any errors in
DOC> the spool file, consult the Oracle Database Upgrade Guide for
DOC> troubleshooting recommendations.
DOC>
DOC> Next restart for normal operation, and then run utlrp.sql to
DOC> recompile any invalid application objects.
DOC>
DOC> If the source database had an older time zone version prior to
DOC> upgrade, then please run the DBMS_DST package. DBMS_DST will upgrade
DOC> TIMESTAMP WITH TIME ZONE data to use the latest time zone file shipped
DOC> with Oracle.
DOC>
DOC>#######################################################################
DOC>#######################################################################
DOC>#
SQL>
SQL> Rem Set errorlogging off
SQL> SET ERRORLOGGING OFF;
SQL>
SQL> REM END OF CATUPGRD.SQL
SQL>
SQL> REM bug 12337546 - Exit current sqlplus session at end of catupgrd.sql.
SQL> REM This forces user to start a new sqlplus session in order
SQL> REM to connect to the upgraded db.
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit
Production
With the Data Mining option

[oracle@serverstd ~]$

Com o término do script o próprio arquivo de upgrade do banco de dados (catupgrd) irá baixar o banco. Devemos então subir e recompilar os objetos inválidos através do utilitário utlrp.

[oracle@serverstd ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Thu Mar 14 21:52:34 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SYS@stdby> startup
ORACLE instance started.

Total System Global Area 835104768 bytes
Fixed Size 2232960 bytes
Variable Size 788532608 bytes
Database Buffers 37748736 bytes
Redo Buffers 6590464 bytes
Database mounted.
Database opened.

SYS@stdby> @?/rdbms/admin/utlrp

TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP UTLRP_BGN 2012-03-14 21:54:09

DOC> The following PL/SQL block invokes UTL_RECOMP to recompile invalid
DOC> objects in the database. Recompilation time is proportional to the
DOC> number of invalid objects in the database, so this command may take
DOC> a long time to execute on a database with a large number of invalid
DOC> objects.

[...]
PL/SQL procedure successfully completed.

Function dropped.

PL/SQL procedure successfully completed.

Primeira fase do script physru acaba de ser finalizada e já vamos iniciar a segunda. Esse é o passo da transação dos bancos e o único momento de parada do ambiente, é agora que o banco standby (stdby) da versão 11.2.0.3 tornará o banco produção (primary database) e o banco atual produção (prima) passará a ser o standby na versão 11.2.0.2

Resumindo:

- O banco stdby será o novo produção na nova versão 11.2.0.3.0.
- O banco prima, atual produção, tornará o novo banco de standby.

Veja como ficará o cenário do nosso ambiente, após o termino da segunda execução do script physru.

Vamos a mais uma execução do script physru exatamente da mesma maneira como da primeira vez. Observe que o script reconhece que o banco de dados stdby já está na nova versão 11.2.0.3.0. Veja:

[oracle@serverstd ~]$ ./physru sys tns_prima tns_stdby prima stdby 11.2.0.3.0
Please enter the sysdba password:
### Initialize script to either start over or resume execution
Mar 14 22:09:25 2012 [0-1] Identifying rdbms software version
Mar 14 22:09:25 2012 [0-1] database prima is at version 11.2.0.2.0
Mar 14 22:09:26 2012 [0-1] database stdby is at version 11.2.0.3.0
Mar 14 22:09:27 2012 [0-1] verifying flashback database is enabled at prima and
stdby
Mar 14 22:09:27 2012 [0-1] verifying available flashback restore points
Mar 14 22:09:27 2012 [0-1] verifying DG Broker is disabled
Mar 14 22:09:27 2012 [0-1] looking up prior execution history
Mar 14 22:09:27 2012 [0-1] last completed stage [2-4] using script version 0001
Mar 14 22:09:27 2012 [0-1] resuming execution of script

### Stage 3: Validate upgraded transient logical standby
Mar 14 22:09:27 2012 [3-1] database stdby is no longer in OPEN MIGRATE mode
Mar 14 22:09:27 2012 [3-1] database stdby is at version 11.2.0.3.0

### Stage 4: Switch the transient logical standby to be the new primary
Mar 14 22:09:28 2012 [4-1] waiting for stdby to catch up (this could take a while)
Mar 14 22:09:29 2012 [4-1] starting logical standby on database stdby
Mar 14 22:09:38 2012 [4-1] waiting for v$dataguard_stats view to initialize
Mar 14 22:09:38 2012 [4-1] waiting for apply lag on stdby to fall below 30 seconds
Mar 14 22:10:12 2012 [4-1] current apply lag: 87006
Mar 14 22:10:42 2012 [4-1] current apply lag: 72634
Mar 14 22:11:12 2012 [4-1] current apply lag: 60550
Mar 14 22:11:42 2012 [4-1] apply lag is now less than 30 seconds
Mar 14 22:11:42 2012 [4-2] switching prima to become a logical standby
Mar 14 22:11:55 2012 [4-2] prima is now a logical standby
Mar 14 22:11:55 2012 [4-3] waiting for standby stdby to process end-of-redo from
primary
Mar 14 22:11:55 2012 [4-4] switching stdby to become the new primary
Mar 14 22:12:22 2012 [4-4] stdby is now the new primary

### Stage 5: Flashback former primary to pre-upgrade restore point and convert to
physical
Mar 14 22:12:22 2012 [5-1] shutting down database prima
Mar 14 22:12:50 2012 [5-1] mounting database prima

Mar 14 22:27:55 2012 [5-2] flashing back database prima to restore point
PRU_0000_0001
Mar 14 22:28:16 2012 [5-3] converting prima into physical standby
Mar 14 22:28:17 2012 [5-4] shutting down database prima

NOTE: Database prima has been shutdown, and is now ready to be started
using the newer version Oracle binary. This script requires the
database to be mounted (on all active instances, if RAC) before calling
this script to resume the rolling upgrade.

O switchover do banco produção para o stdby foi o único momento de parada do banco de dados que em meu ambiente de teste, uma máquina desktop comum que não merece ser comparada aos grandes servidores hoje existentes, levou cerca de 20 segundos de parada.

Com a segunda execução do script physru o banco de dados produção passa ser o nosso banco de standby e agora com a terceira e última execução do script, vamos atualizar o banco produção antigo (prima) para a versão 11.2.0.3.0 assim como está o banco atual produção stdby, ou seja vamos deixar os dois bancos do nosso ambiente na mesma versão.

Na máquina serverprd(antigo produção) subiremos o banco de dados prima (atual standby) no binário 11.2.0.3.0.

[oracle@serverprd ~]$ export ORACLE_HOME=/u01/app/oracle/product/11.2.0.3/dbhome_1
[oracle@serverprd ~]$ export PATH=$ORACLE_HOME/bin:$PATH
[oracle@serverprd ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Mar 14 22:42:27 2012

Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to an idle instance.

SYS@prima> startup mount
ORACLE instance started.

Total System Global Area 835104768 bytes
Fixed Size 2232960 bytes
Variable Size 528485760 bytes
Database Buffers 297795584 bytes
Redo Buffers 6590464 bytes
Database mounted.

SYS@prima> select db_unique_name, database_role from v$database;

DB_UNIQUE_NAME                  DATABASE_ROLE
-------------------------       ----------------
prima                           PHYSICAL STANDBY

Observe o resultado da última consulta que nosso banco prima passa a tornar-se um banco PHYSICAL STANDBY.

Voltemos na máquina serverstd e iniciamos novamente a execução do script physru, exatamente da mesma maneira como das outras vezes. Veja que o script reconhece agora os dois banco na versão 11.2.0.3.0.

[oracle@serverstd ~]$ ./physru sys tns_prima tns_stdby prima stdby 11.2.0.3.0
Please enter the sysdba password:
### Initialize script to either start over or resume execution
Mar 14 22:44:30 2012 [0-1] Identifying rdbms software version
Mar 14 22:44:30 2012 [0-1] database prima is at version 11.2.0.3.0
Mar 14 22:44:30 2012 [0-1] database stdby is at version 11.2.0.3.0
Mar 14 22:44:30 2012 [0-1] verifying flashback database is enabled at prima and
stdby
Mar 14 22:44:30 2012 [0-1] verifying available flashback restore points
Mar 14 22:44:31 2012 [0-1] verifying DG Broker is disabled
Mar 14 22:44:31 2012 [0-1] looking up prior execution history
Mar 14 22:44:31 2012 [0-1] last completed stage [5-4] using script version 0001
Mar 14 22:44:31 2012 [0-1] resuming execution of script

### Stage 6: Run media recovery through upgrade redo
Mar 14 22:44:31 2012 [6-1] upgrade redo region identified as scn range [1059703,
1797547]
Mar 14 22:44:31 2012 [6-1] starting media recovery on prima
Mar 14 22:44:39 2012 [6-1] confirming media recovery is running
Mar 14 22:44:39 2012 [6-1] waiting for media recovery to initialize
v$recovery_progress
Mar 14 22:45:14 2012 [6-1] monitoring media recovery's progress
Mar 14 22:45:15 2012 [6-2] last applied scn 1038224 is approaching upgrade redo
start scn 1059703
Mar 14 22:49:02 2012 [6-2] last applied scn 1044600 is approaching upgrade redo
start scn 1059703
Mar 14 22:49:22 2012 [6-2] last applied scn 1045996 is approaching upgrade redo
start scn 1059703
start scn 1059703
Mar 14 22:51:10 2012 [6-2] last applied scn 1054456 is approaching upgrade redo
start scn 1059703
Mar 14 22:53:12 2012 [6-3] recovery of upgrade redo at 01% - estimated complete at
Mar 16 09:00:05
Mar 14 22:54:43 2012 [6-3] recovery of upgrade redo at 02% - estimated complete
[...]
Mar 14 22:50:59 2012 [6-3] recovery of upgrade redo at 97% - estimated complete at
Mar 14 22:52:55
Mar 14 22:51:59 2012 [6-3] recovery of upgrade redo at 98% - estimated complete at
Mar 14 22:53:15
Mar 14 22:52:44 2012 [6-3] recovery of upgrade redo at 99% - estimated complete at
Mar 14 22:53:10
Mar 14 22:53:00 2012 [6-4] media recovery has finished recovering through upgrade

### Stage 7: Switch back to the original roles prior to the rolling upgrade
NOTE: At this point, you have the option to perform a switchover
      which will restore prima back to a primary database and
      stdby back to a physical standby database. If you answer 'n'
      to the question below, prima will remain a physical standby
      database and stdby will remain a primary database.

Do you want to perform a switchover? (y/n):

O script nos fornece a possibilidade de voltar o ambiente como estava antes, o banco prima como sendo o produção e o stdby como o banco standby. Esse passo não é obrigatório, caso for selecionado você terá mais um tempo de downtime no ambiente para fazer novamente o switchover entre os bancos de dados.

Somente para fins de teste iremos voltar o ambiente como antes. Para isso responda y a pergunta.

Mar 14 22:54:53 2012 [7-1] continuing
Mar 14 22:55:01 2012 [7-2] waiting for v$dataguard_stats view to initialize
Mar 14 22:54:02 2012 [7-2] waiting for apply lag on prima to fall below 30 seconds
Mar 14 22:54:03 2012 [7-2] apply lag is now less than 30 seconds
Mar 14 22:54:03 2012 [7-3] switching stdby to become a physical standby
Mar 14 22:54:13 2012 [7-3] stdby is now a physical standby
Mar 14 22:54:13 2012 [7-3] shutting down database stdby
Mar 14 22:54:16 2012 [7-3] mounting database stdby
Mar 14 22:54:41 2012 [7-4] waiting for standby prima to process end-of-redo from
primary
Mar 14 22:54:44 2012 [7-5] switching prima to become the new primary
Mar 14 22:54:46 2012 [7-5] prima is now the new primary
Mar 14 22:54:46 2012 [7-5] opening database prima
Mar 14 22:55:22 2012 [7-6] starting media recovery on stdby
Mar 14 22:55:29 2012 [7-6] confirming media recovery is running

### Stage 8: Statistics
script start time:                                        14-Mar-12 21:28:50
script finish time:                                       14-Mar-12 22:55:31
total script execution time:                                    +00 02:37:41
wait time for user upgrade:                                     +00 02:05:37
active script execution time:                                   +00 01:32:04
transient logical creation start time:                    14-Mar-12 21:17:11
transient logical creation finish time:                   14-Mar-12 21:20:08
primary to logical switchover start time:                 14-Mar-12 22:39:01
logical to primary switchover finish time:                14-Mar-12 22:39:23
primary services offline for:                                   +00 00:00:22
total time former primary in physical role:                     +00 00:50:50
time to reach upgrade redo:                                     +00 00:00:57
time to recover upgrade redo:                                   +00 00:05:31
primary to physical switchover start time:                14-Mar-12 22:51:02
physical to primary switchover finish time:               14-Mar-12 22:51:30
primary services offline for:                                   +00 00:00:28

SUCCESS: The physical rolling upgrade is complete
[oracle@serverstd ~]$

E no final da execução do script algumas ótimas estatísticas para análise de todo o processo de upgrade. A mais interessante com certeza a “primary services offline for” que mostra o tempo que o banco esteve baixado devido ao switchover entre os bancos, perceba que o tempo foi muito pouco, tanto na primeira como na segunda execução.

Aqui está o ambiente como se encontra agora depois das três execuções do script. Observe que os dois bancos estão na versão 11.2.0.3.0, tudo isso feito com um downtime extremamente pequeno comparado a complexidade do processo.



Aviso: Este artigo deve ser usado somente para fins de teste, não para ambientes de produção.


Flávio Soares é um consultor DBA Oracle há mais de 5 anos, certificado OCP e OCE RAC. Especialista em administração, recuperação, alta disponibilidade e replicação de dados com soluções Oracle. Flávio disponibiliza frequentes informações para a comunidade Oracle através do seu blog http://flaviosoares.com