CRIANDO STANDBY DATABASE

BANCO DE DADOS STANDBY

Dia desses tivemos que migrar um banco de dados de 9i para 10g, com o tamanho aproximado de 4 TB, sob um ambiente IBM AIX 5.1.

Apesar de um pouco conturbada, a migração para 10g foi realizada com sucesso; isto até que seria um tópico interessante para um post, mas hoje eu preferi abordar outro assunto: A criação de um standby para este banco de dados.

Este é um recurso do Oracle database conhecido como Oracle Data Guard; Neste caso, foi criado um banco standby físico.

Motivos para criar um banco standby não faltam. Proteção contra erros lógicos (comparado a um standby database lógico), failover rápido, possível switch over em casos de necessidade de manutenção no servidor primário, possíbilidade de abrir o banco standby em ready-only para a geração de relatórios, entre outras coisas.

Como pré-requisitos, o banco primário deve estar em archivelog – uma vez que as alterações serão replicadas através da aplicação dos relo logs arquivados; o banco primário também deverá usar arquivo de senhas.

Que tal conhecer como funcionou a criação deste standby?

INICIANDO A CRIAÇÃO

Inicialmente, para criar o banco de dados standby, deve ser instalado o software do Oracle. Utilizamos a interface gráfica do instalador, escolhendo a opção “Install database Software only”.

Para facilitar em caso de failover, foi criada a mesma estrutura de diretório dos arquivos do banco primário no novo servidor. Isto também ajudou na cópia dos datafiles (uma vez que optamos por copiar um a um via Begin backup).

Por que Begin backup?

Neste caso, uma série de fatores nos levou à opção de copiar os datafiles um a um, mas os principais foram o tamanho do banco e sua criticidade, o que não permitiu uma parada do ambiente para uma cópia a frio.

Copiando os datafiles

Antes de inciar a cópia, é interessante anotar o número do último archive gerado (Este será o primeiro archive a ser copiado no standby)

select max(sequence#)  
from v$log_history;

Após anotar o n. do archive, foi iniciada a cópia dos mais de 600 datafiles do banco.

Mas, não pense que fiquei olhando a cópia de datafile por datafile… foi feito um script que colocava cada tablespace em Begin backup, copiava os datafiles com scp, e colocava novamente a tablespace em end backup. Veja um pedaço do script:

alter tablespace users begin backup; 
ho scp -r -C   \oracle\oradata\orcl\tblusers01.dbf 192.168.1.10:\oracle\oradata\orcl\ 
ho scp -r -C   \oracle\oradata\orcl\tblusers02.dbf 192.168.1.10:\oracle\oradata\orcl\ 
alter tablespace users   end backup;

Lembrando que, para não ficar tendo que inserir senha toda hora, é possível criar uma chave pública entre os dois servidores, como expliquei em um dos meus posts (ver post).

Para saber quais são os datafiles do banco de dados, consulte a view dba_data_files:

select file_name 
from   dba_data_files order by tablespace_name;

Durante a cópia, o alert.log deve ser acompanhado, verificando se as tablespaces estão ficando em Begin backup / end backup corretamente.

Para ver as alterações do alert em tempo real, utilize o comando tail -f. Veja um exemplo de comando:

tail -f alert_ORCL.log

Também dá para acompanhar as alterações das tablespaces através da seguinte consulta:

select df.tablespace_name, df.file_id 
from   dba_data_files   df,  
          v$backup b 
where df.file_id =   b.file# 
and b.status =   'ACTIVE';

Também copiei os tempfiles e os redos log files, os quais foram localizados através das consultas abaixo:

select file_name 
from   dba_temp_files; 

select member 
from   v$log_member;

Standby Controlfile

Ao final da cópia dos arquivos, criei no banco primário um controlfile especial: o standby controlfile.

alter database create standby controlfile as '/home/oracle/migracao10g/orclstd.ctl'

Este controlfile foi copiado para o servidor secundário, com o cuidado de criar duas cópias e renomeá-las.

Copiando os archives

Neste ponto, foi a hora de copiar todos os archives gerados para o destino. Estes archives são importantes para o recover dos datafiles copiados em Begin backup, e para abrir o banco em read only.

Parâmetros da instância

Para um banco reconhecer o outro, haver a replicação dos archives e ativar os processos de background necessários, é necessário adicionar alguns parâmetros.

No banco de produção, foram ativados o log_archive_dest_2, log_archive_dest_state_2, standby_file_management, fal_server e fal_client . Todos estes parâmetros podem ser ativados com ALTER SYSTEM .

Uma observação importante é o valor do parâmetro log_archive_dest_2: ele deve estar de acordo com o alias utilizado para o banco standby no tnsnames do servidor, como no exemplo abaixo:

Também devem ser ajustados tais parâmetros no standby. Porém, eu fiz diferente: Primeiro, criei um pfile a partir do spfile da produção, e editei este arquivo. Depois, copiei o mesmo para o servidor standby.

Para criar um pfile:

create pfile='/home/oracle/migracao10g/initorcl.ora' from spfile;

Veja um exemplo de pfile para um banco standby:

rcl.__db_cache_size=34158411776
orcl.__java_pool_size=83886080 
orcl.__large_pool_size=33554432 
orcl.__shared_pool_size=3238002688 
orcl.__streams_pool_size=50331648 
aq_tm_processes=1 
archive_lag_target=60 
background_dump_dest='/oracle/admin/orcl/10g/bdump' 
compatible='10.2.0.4.0' 
control_file_record_keep_time=7 
control_files='/oracle/syst/u01/oradata/orcl/control01.ctl',                
'/oracle/syst/u01/oradata/orcl/control02.ctl',                
'/oracle/syst/u01/oradata/orcl/control03.ctl' 
core_dump_dest='/oracle/admin/orcl/10g/cdump' 
cursor_sharing='EXACT' 
db_block_size=8192 
db_cache_size=0 
db_domain='' 
db_file_multiblock_read_count=16 
db_files=2048 db_name='orcl' 
db_writer_processes=5 
dispatchers='(PROTOCOL=TCP)   (SERVICE=orclXDB)' 
dml_locks=3892 
fal_client='ORCLSTD' 
fal_server='ORCL' 
fast_start_mttr_target=300 
filesystemio_options='asynch' 
hash_area_size=1048576 
instance_name='orcl' 
java_pool_size=0 
job_queue_processes=18 
large_pool_size=0 
log_archive_dest_1='LOCATION=/oracle/arch/u01/orcl/archive/' 
log_archive_format='orcl_%t_%s_%r.arc' 
log_archive_max_processes=1 
log_buffer=10048576 
log_file_name_convert='/oracle/redo/u01/oradata/orcl/',                        
'/oracle/redo/u01/oradata/orcl/',                       
'/oracle/redo/u01/oradata/orcl/',                        
'/oracle/redo/u01/oradata/orcl/',  
open_cursors=2000 
optimizer_dynamic_sampling=2 
optimizer_features_enable='10.2.0.4' 
optimizer_index_caching=25 
optimizer_index_cost_adj=10 
pga_aggregate_target=7G 
processes=1200 
query_rewrite_enabled='TRUE' 
recovery_parallelism=16 
recyclebin='OFF' 
remote_login_passwordfile='EXCLUSIVE' 
service_names='ORCL' 
session_cached_cursors=200 
session_max_open_files=20 
sessions=1200 
sga_max_size=35G 
sga_target=35G 
shared_pool_reserved_size=124151398 
shared_pool_size=0 
skip_unusable_indexes=TRUE 
sort_area_size=1048576 
standby_archive_dest='/oracle/arch/u01/orcl/archive/' 
standby_file_management='MANUAL' 
star_transformation_enabled='FALSE' 
streams_pool_size=50331648 
transactions=973 
undo_management='AUTO' 
undo_retention=5400 
undo_tablespace='UNDOTBS2' 
user_dump_dest='/oracle/admin/orcl/10g/udump'

Arquivo de senhas

Outro item importantíssimo é a cópia (ou criação) do arquivo de senhas. Geralmente, ele está no diretório $ORACLE_HOME/dbs, e tem o nome orapw<nome_instancia> (por exemplo, orapworcl). Lembrando que a senha do sys no banco standby deve ser a mesma do banco primário.

Para criar um arquivo de senhas:

orapwd file=<caminho/arquivo>  password=<senha do sys> entries=10

exemplo:

orapwd file=/oracle/10g/dbs/orapworcl  password=change_on_install entries=10

Importante: o parâmetro remote_login_passwordfile deve ter valor exclusive ou shared.

Configurando as variáveis de ambiente

Para ajustar as variáveis de ambiente e outras configurações do usuário Oracle, ajustei o arquivo .profile (geralmente fica dentro do diretório /home do usuário).

Exemplo de arquivo .profile

EDITOR=vi
ORACLE_BASE=/oracle 
ORACLE_HOME=$ORACLE_BASE/10g 
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data 
ORACLE_SID=orcl 
LIBPATH=$ORACLE_HOME/lib:/usr/lib 
PATH=$PATH:$ORACLE_HOME/bin:/usr/bin:/etc:/usr/bin/X11:/usr/local/bin export 
PATH ORACLE_BASE ORACLE_HOME PATH ORA_NLS33 ORACLE_SID LIBPATH EDITOR

Também foi ajustado o arquivo /etc/oratab, como no exemplo abaixo:

Subindo o banco de dados

Com todos estes procedimentos, foi possível subir a instância, utilizando o pfile criado:

sqlplus "/as sysdba" 
startup nomount pfile=/home/oracle/migracao10g/initorcl.ora

É importante acompanhar, em sessão paralela, o alert.log do banco: caso haja algum erro, através dele é possível ver detalhes do problema, e eventuais arquivos de trace gerados.

Com a instância no ar, foi criado um spfile, e ela restartada em mount.

Veja exemplo de comandos:

create spfile from pfile='/home/oracle/migracao10g/initorcl.ora'; 
shutdown immediate startup mount

Redo Aply

Para iniciar a recuperação do banco, através da aplicação dos archives no banco de dados, utilizamos o comando abaixo:

RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Este comando inicia o processo de background MRP (Managed Standby Recovery) em background, e é possível verificar no alert.log do banco o processo.

É interessante notar não ser preciso subir o standby com o comando “mount standby”: O Oracle 10g verifica o tipo do controlfile ao montar o banco; se o controlfile for de standby, automaticamente o banco é montado como standby.

Todos os archives copiados via SCP foram recuperados no banco. Após esta recuperação, ele começará automaticamente a recuperar os archives copiados via RFS do servidor primário; quando não há mais archives novos, a seguinte mensagem é exibida:

Ou seja, o banco está esperando o próximo archive, vindo da produção, para aplicar no standby.

Neste momento, é possível abrir o banco para consultas (read only)

Comandos:

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; 
ALTER DATABASE OPEN READ ONLY;

Veja como fica o alert:

Verificando se os bancos estão sincronizados

Para verificar se os bancos primário e secundário estão sincronizados, verifique se o último archive gerado na produção foi o último replicado no secundário, através do alert.log de ambos.

Outra forma é consultando a view v$log_history nos dois bancos:

select max(sequence#) from v$log_history;
 
...

Bem, depois de tanto tempo sem postar nada, espero que seja útil!

Até mais,

Lílian

Para saber mais:

Na internet:

• Oracle Database 11g Editions
• Introduction to Oracle Data Guard

Livro:

• Oracle database 10g High Availability with RAC, flashback & Data Guard