Flávio Soares
DBA Oracle
http://flaviosoares.com
http://www.oracle.com/technetwork/pt/articles/database-performance/rolling-upgrades-com-data-guard-11g1576838-ptb.html
Rolling Upgrades com Oracle Data Guard 11g
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
Banco de dados: prima
Versão: 11.2.0.2
Servidor: serverprd
Banco de dados: stdby
Versão: 11.2.0.2
Servidor: serverstd
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
-----------------------------stdby
DATABASE_ROLE
---------------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>
DOC>
DOC>
DOC>
DOC>
The following PL/SQL block invokes UTL_RECOMP to recompile invalid
objects in the database. Recompilation time is proportional to the
number of invalid objects in the database, so this command may take
a long time to execute on a database with a large number of invalid
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.
banco : stdby
versão: 11.2.0.3.0
servidor: serverstd
banco : prima
versão: 11.2.0.2.0
servidor: serverprd
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
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
restore
point
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
Mar
Mar
Mar
Mar
14
14
14
14
14
22:51:59 2012 [6-3] recovery of upgrade redo at 98% - estimated complete at
22:53:15
22:52:44 2012 [6-3] recovery of upgrade redo at 99% - estimated complete at
22:53:10
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:
script finish time:
total script execution time:
wait time for user upgrade:
active script execution time:
transient logical creation start time:
transient logical creation finish time:
primary to logical switchover start time:
logical to primary switchover finish time:
primary services offline for:
total time former primary in physical role:
time to reach upgrade redo:
time to recover upgrade redo:
primary to physical switchover start time:
physical to primary switchover finish time:
primary services offline for:
14-Mar-12
14-Mar-12
+00
+00
+00
14-Mar-12
14-Mar-12
14-Mar-12
14-Mar-12
+00
+00
+00
+00
14-Mar-12
14-Mar-12
+00
21:28:50
22:55:31
02:37:41
02:05:37
01:32:04
21:17:11
21:20:08
22:39:01
22:39:23
00:00:22
00:50:50
00:00:57
00:05:31
22:51:02
22:51:30
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.
banco : prima
versão: 11.2.0.3.0
servidor: serverprd
banco : stdby
versão: 11.2.0.3.0
servidor: serverstb