CRIANDO UM 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:

orcl.__db_cache_size=34158411776orcl.__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=viORACLE_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

lilian