Blog Flávio Soares
Oracle, Database, Data Guard, RAC, Performance, Exadata, ASM, Goldengate, Troubleshooting
April 26, 2013
…
Vamos para a última parte da série sobre a criação do Oracle Data Guard com o Virtualbox. No final desse post, teremos o nosso banco orcl sendo replicado para o banco stdby através do Oracle Data Guard 11g.
Configurando o database standby
1. Mudanças no initstdby.ora no standby
Para quem não se lembra o arquivo de inicialização initstdby.ora, foi criado no servidor bancodg (servidor primário) no passo 6 da parte 5 dessa serie, e foi movido para o servidor standdg (servidor standby) no passo 9 da mesma parte 5.
Vamos editar o arquivo initstdby.ora para acrescentarmos alguns parâmetros necessários do Oracle Data Guard.
Para isso, conecte na máquina de standby standdg e faça as alterações como abaixo, observe que os parâmetros em verde, são os parâmetros necessários para o Data Guard.
[oracle@standdg ~]$ hostname standdg.oracle.com [oracle@standdg ~]$ cd $ORACLE_BASE/backup/rman [oracle@standdg rman]$ ls -l total 1208568 -rw-r----- 1 oracle oinstall 59481600 Apr 10 23:10 ARCH_ORCL_5_1_05o6ou7v_1_1.bkp -rw-r----- 1 oracle oinstall 32740864 Apr 10 23:10 ARCH_ORCL_6_1_06o6ou7v_1_1.bkp -rw-r----- 1 oracle oinstall 703807488 Apr 10 23:11 ORCL_1_1_01o6ou56_1_1.bkp -rw-r----- 1 oracle oinstall 420593664 Apr 10 23:11 ORCL_2_1_02o6ou56_1_1.bkp -rw-r----- 1 oracle oinstall 9797632 Apr 10 23:11 ORCL_3_1_03o6ou69_1_1.bkp -rw-r----- 1 oracle oinstall 98304 Apr 10 23:11 ORCL_4_1_04o6ou6g_1_1.bkp -rw-r----- 1 oracle oinstall 9797632 Apr 10 23:10 control_ORCL_07o6ou86_1_1.bkp -rw-r--r-- 1 oracle oinstall 1388 Apr 10 23:10 initstdby.ora [oracle@standdg rman]$ vi initstdby.ora *.audit_file_dest='/u01/app/oracle/admin/stdby/adump' *.compatible='11.2.0.0.0' *.control_files='/u01/app/oracle/oradata/stdby/control01.ctl','/u01/app/oracle/oradata/stdby/control02.ctl' *.db_block_size=8192 *.diagnostic_dest='/u01/app/oracle' *.log_archive_format='orcl_%t_%s_%r.arc' *.open_cursors=300 *.pga_aggregate_target=616562688 *.sga_target=1849688064 *.undo_tablespace='UNDOTBS1' *.db_name=orcl *.db_unique_name=stdby *.db_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/stdby' *.log_file_name_convert='/u01/app/oracle/oradata/orcl','/u01/app/oracle/oradata/stdby' *.log_archive_config='DG_CONFIG=(orcl,stdby)' *.log_archive_dest_1='LOCATION=/u01/app/oracle/archive/stdby VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stdby' *.log_archive_dest_2='SERVICE=orcl LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=orcl' *.log_archive_dest_state_1='ENABLE' *.fal_client='stdby' *.fal_server='orcl' *.remote_login_passwordfile='EXCLUSIVE' *.standby_file_management=auto
Quase todos os parâmetros alterados no banco primário (orcl) na parte 5 foram agora alterados no banco standby, com exceção dos parâmetros db_unique_name, remote_login_passwordfile e standby file_management que vou explicar cada um deles agora:
DB_UNIQUE_NAME: Especifica o nome global único para o banco de dados. Como estamos fazendo um restore RMAN através de um banco chamado ORCL, precisamos definir esse parâmetro para informar que o banco chamado orcl (db_name) terá o seu nome global de stdby (db_unique_name), com isso é possível ter o mesmo banco orcl restaurado e alterado para o nome stdby.
REMOTE_LOGIN_PASSWORDFILE: Específica a maneira como o Oracle lê o arquivo de password file:
- shared: Um ou mais databases pode usar o password file.
- exclusive: O password file pode ser usado por um ou mais databases.
- none: Com essa configuração, o Oracle irá ignorar qualquer passowrdfile.
Para uma configuração Oracle Data Guard, é necessário que o password file esteja configurado como shared ou exclusive.
STANDBY_FILE_MANAGEMENT: Com esse parâmetro habilitado, qualquer operação de adicionar ou remover arquivos do sistema operacional como por exemplo datafile ou redolog, eles serão automaticamente replicados para o standby. Resumindo: qualquer arquivo do Oracle criado no Data Guard, também será criado no Data Guard.
2. Definir o tnsnames.ora
Assim como fizemos na máquina bancodg (servidor primário), temos que configurar da mesma maneira no servidor standdg.
[oracle@standdg rman]$ vi /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = bancodg.oracle.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
STDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standdg.oracle.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stdby)
)
)
Feita as configurações, vamos aos teste de conexão através do tnsping:
[oracle@standdg rman]$ tnsping orcl TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 10-APR-2013 23:48:05 Copyright (c) 1997, 2011, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = bancodg.oracle.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl))) OK (10 msec) [oracle@standdg rman]$ tnsping stdby TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 10-APR-2013 23:48:11 Copyright (c) 1997, 2011, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standdg.oracle.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = stdby))) OK (0 msec)
3. Criando os diretórios necessários para o banco stdby
Para iniciar a instância STDBY, precisamos dos seguintes diretórios criados:
[oracle@standdg ~]$ mkdir -p /u01/app/oracle/admin/stdby/adump [oracle@standdg ~]$ mkdir -p /u01/app/oracle/oradata/stdby/ [oracle@standdg ~]$ mkdir -p /u01/app/oracle/archive/stdby
4. Iniciando a instância stdby
Segue agora os passos necessários para iniciar a instância STDBY em estado nomount. Primeiro, vamos criar o spfile através do arquivo pfile “/u01/app/oracle/backup/rman/initstdby.ora”.
[oracle@standdg~]$ echo $ORACLE_SID stdby [oracle@standdg~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 10 23:02:21 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> create spfile from pfile='/u01/app/oracle/backup/rman/initstdby.ora'; File created. SQL> startup nomount ORACLE instance started. Total System Global Area 1853947904 bytes Fixed Size 2229384 bytes Variable Size 452987768 bytes Database Buffers 1392508928 bytes Redo Buffers 6221824 bytes
5. Realizando o restore através do comando duplicate:
Com todas as configurações acima realizadas, vamos agora a restauração do banco orcl para o standby stdby. A restauração será feita através do comando duplicate do RMAN, para isso precisamos estar conectados em ambos os bancos de dados (orcl e stdby), isso é feito da seguinte maneira:
$ rman target sys/oracle@orcl auxiliary /
Onde:
target -> Representa o nosso banco de dados destino, que no caso é o banco orcl (database primário). A conexão será feita com o usuário com o usuário sys e senha oracle através do TNSNAME orcl.
auxiliary -> Representa o banco na máquina que estamos conectado, que no caso é a instância stdby, definido pela variável de ambiente ORACLE_SID. A conexão será feita pelo sistema operacinal “/”.
[oracle@standdg ~]$ rman target sys/oracle@orcl auxiliary / Recovery Manager: Release 11.2.0.3.0 - Production on Wed Apr 10 23:57:16 2013 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: ORCL (DBID=1334188681) connected to auxiliary database: ORCL (not mounted) RMAN> duplicate target database for standby; Starting Duplicate Db at 11-APR-13 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=111 device type=DISK contents of Memory Script: { restore clone standby controlfile; } executing Memory Script Starting restore at 11-APR-13 using channel ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: restoring control file channel ORA_AUX_DISK_1: reading from backup piece /u01/app/oracle/backup/rman/control_ORCL_07o6ou86_1_1.bkp channel ORA_AUX_DISK_1: piece handle=/u01/app/oracle/backup/rman/control_ORCL_07o6ou86_1_1.bkp tag=TAG20130410T225358 channel ORA_AUX_DISK_1: restored backup piece 1 channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01 output file name=/u01/app/oracle/oradata/stdby/control01.ctl output file name=/u01/app/oracle/oradata/stdby/control02.ctl Finished restore at 11-APR-13 contents of Memory Script: { sql clone 'alter database mount standby database'; } executing Memory Script sql statement: alter database mount standby database contents of Memory Script: { set newname for tempfile 1 to "/u01/app/oracle/oradata/stdby/temp01.dbf"; switch clone tempfile all; set newname for datafile 1 to "/u01/app/oracle/oradata/stdby/system01.dbf"; set newname for datafile 2 to "/u01/app/oracle/oradata/stdby/sysaux01.dbf"; set newname for datafile 3 to "/u01/app/oracle/oradata/stdby/undotbs01.dbf"; set newname for datafile 4 to "/u01/app/oracle/oradata/stdby/users01.dbf"; set newname for datafile 5 to "/u01/app/oracle/oradata/stdby/example01.dbf"; restore clone database ; } executing Memory Script executing command: SET NEWNAME renamed tempfile 1 to /u01/app/oracle/oradata/stdby/temp01.dbf in control file executing command: SET NEWNAME executing command: SET NEWNAME executing command: SET NEWNAME executing command: SET NEWNAME executing command: SET NEWNAME Starting restore at 11-APR-13 using channel ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set channel ORA_AUX_DISK_1: restoring datafile 00002 to /u01/app/oracle/oradata/stdby/sysaux01.dbf channel ORA_AUX_DISK_1: restoring datafile 00003 to /u01/app/oracle/oradata/stdby/undotbs01.dbf channel ORA_AUX_DISK_1: restoring datafile 00004 to /u01/app/oracle/oradata/stdby/users01.dbf channel ORA_AUX_DISK_1: reading from backup piece /u01/app/oracle/backup/rman/ORCL_2_1_02o6ou56_1_1.bkp channel ORA_AUX_DISK_1: piece handle=/u01/app/oracle/backup/rman/ORCL_2_1_02o6ou56_1_1.bkp tag=TAG20130410T225222 channel ORA_AUX_DISK_1: restored backup piece 1 channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:25 channel ORA_AUX_DISK_1: starting datafile backup set restore channel ORA_AUX_DISK_1: specifying datafile(s) to restore from backup set channel ORA_AUX_DISK_1: restoring datafile 00001 to /u01/app/oracle/oradata/stdby/system01.dbf channel ORA_AUX_DISK_1: restoring datafile 00005 to /u01/app/oracle/oradata/stdby/example01.dbf channel ORA_AUX_DISK_1: reading from backup piece /u01/app/oracle/backup/rman/ORCL_1_1_01o6ou56_1_1.bkp channel ORA_AUX_DISK_1: piece handle=/u01/app/oracle/backup/rman/ORCL_1_1_01o6ou56_1_1.bkp tag=TAG20130410T225222 channel ORA_AUX_DISK_1: restored backup piece 1 channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:55 Finished restore at 11-APR-13 contents of Memory Script: { switch clone datafile all; } executing Memory Script datafile 1 switched to datafile copy input datafile copy RECID=2 STAMP=812419999 file name=/u01/app/oracle/oradata/stdby/system01.dbf datafile 2 switched to datafile copy input datafile copy RECID=3 STAMP=812419999 file name=/u01/app/oracle/oradata/stdby/sysaux01.dbf datafile 3 switched to datafile copy input datafile copy RECID=4 STAMP=812419999 file name=/u01/app/oracle/oradata/stdby/undotbs01.dbf datafile 4 switched to datafile copy input datafile copy RECID=5 STAMP=812419999 file name=/u01/app/oracle/oradata/stdby/users01.dbf datafile 5 switched to datafile copy input datafile copy RECID=6 STAMP=812419999 file name=/u01/app/oracle/oradata/stdby/example01.dbf Finished Duplicate Db at 11-APR-13 RMAN>
Restore finalizado com sucesso.
Vamos realmente conferir se o banco stdby restaurado está no modo STANDBY:
SQL> select name, db_unique_name, database_role from v$database; NAME DB_UNIQUE_NAME DATABASE_ROLE --------- ------------------------------ ---------------- ORCL stdby PHYSICAL STANDBY
Confirmado, nosso banco stdby está definido como PHYSICAL STANDBY.
6. Habilitando o segundo destino de archive no database primário
Com a restauração completa do banco de dados STDBY, temos agora que informar ao database primário (orcl) para começar a enviar os logs das alterações feitas para o banco stdby. Isso é feito de acordo com o parâmetro log_archive_dest_state_2:
SQL> show parameter instance_name NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ instance_name string orcl SQL> alter system set log_archive_dest_state_2=enable; System altered.
Com esse parâmetro habilitado, sinaliza para o Oracle para gerar os logs de acordo com o que está configurado no parâmetro log_archive_dest_2. Agora, através desse segundo destino de archive habilitado, todas as alterações feitas no orcl será automaticamente enviada para o banco stdby (database standby).
7. Habilitando o início do Oracle Data Guard
Com os logs chegando no banco standby, vamos informar ao Oracle Data Guard no banco stdby, para que comece a trabalhar com esses logs que estão vindo do banco orcl,
Ao executar os comandos abaixo, estamos solicitando para que o Data Guard inicie os processos background para automáticamente restaurar os logs recebidos.
Veja:
SQL> show parameter instance_name NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ instance_name string stdby SQL> alter database recover managed standby database disconnect; Database altered. SQL>
Feito isso, temos o nosso Data Guard pronto e habilitado.
7. Verificando a sincronia do Data Guard
Até aqui temos o nosso Data Guard funcionando, precisamos agora certificar que ele está funcionando garantindo assim a sincronia da replicação. Para isso, temos que checar se o destino de log 1 está na mesma sequência do destino de log 2, ou seja, cada sequência gerada no destino 1 (destino do banco orcl) deverá gerar a mesma sequência no destino 2 (destino do banco stdby), garantindo assim que ambas estão sincronizadas.
Essa forma de monitorar, funciona apenas para o tipo do Data Guard que estamos criando, o tipo ASYNC. Existe a forma SYNC, que muda a forma de como monitorar também, mais isso fica para um próximo post, por enquanto basta saber que o Data Guard ASYNC deve gerar a mesma sequência no destino 1 como no destino 2.
Uma das formas de verificar isso, é através da view v$archived_log, como mostro abaixo:
(Obs: A consulta deve ser realizada no banco orcl)
SQL> select
2 thread#,
3 dest_id,
4 sequence#,
5 first_time,
6 next_time
7 from v$archived_log
8 where resetlogs_change# = (select resetlogs_change# from v$database)
9* order by thread#, sequence#, dest_id;
THREAD# DEST_ID SEQUENCE# FIRST_TIME NEXT_TIME
---------- ---------- ---------- ------------------- -------------------
1 1 3 03-02-2013 10:14:05 10-04-2013 21:51:01
1 1 4 10-04-2013 21:51:01 10-04-2013 22:01:11
1 1 5 10-04-2013 22:01:11 10-04-2013 22:53:49
1 2 5 10-04-2013 22:01:11 10-04-2013 22:53:49
1 1 6 10-04-2013 22:53:49 10-04-2013 23:58:46
1 2 6 10-04-2013 22:53:49 10-04-2013 23:58:46
1 1 7 10-04-2013 23:58:46 11-04-2013 00:02:31
1 2 7 10-04-2013 23:58:46 11-04-2013 00:02:31
1 1 8 11-04-2013 00:02:31 11-04-2013 00:07:34
1 2 8 11-04-2013 00:02:31 11-04-2013 00:07:34
1 1 9 11-04-2013 00:07:34 11-04-2013 00:11:01
1 2 9 11-04-2013 00:07:34 11-04-2013 00:11:01
1 1 10 11-04-2013 00:11:01 11-04-2013 00:11:02
1 2 10 11-04-2013 00:11:01 11-04-2013 00:11:02
1 1 11 11-04-2013 00:11:02 11-04-2013 00:12:03
1 2 11 11-04-2013 00:11:02 11-04-2013 00:12:03
1 1 12 11-04-2013 00:12:03 11-04-2013 00:15:46
1 2 12 11-04-2013 00:12:03 11-04-2013 00:15:46
Observe que a partir da sequência 5, o Oracle está gerando a mesma sequência tanto no destino 1 como no destino 2. Isso se repete até o sequência 12, que é a última sequência gerada para o banco orcl.
Para confirmar a sincronização, podemos forçar a geração de uma nova sequência:
SQL> alter system switch logfile;
Feito isso, checamos novamente com a consulta acima, para verificar se a sequência 13 foi gerada no destino 1 e destino 2.
THREAD# DEST_ID SEQUENCE# FIRST_TIME NEXT_TIME
---------- ---------- ---------- ------------------- -------------------
1 1 3 03-02-2013 10:14:05 10-04-2013 21:51:01
1 1 4 10-04-2013 21:51:01 10-04-2013 22:01:11
1 1 5 10-04-2013 22:01:11 10-04-2013 22:53:49
1 2 5 10-04-2013 22:01:11 10-04-2013 22:53:49
1 1 6 10-04-2013 22:53:49 10-04-2013 23:58:46
1 2 6 10-04-2013 22:53:49 10-04-2013 23:58:46
1 1 7 10-04-2013 23:58:46 11-04-2013 00:02:31
1 2 7 10-04-2013 23:58:46 11-04-2013 00:02:31
1 1 8 11-04-2013 00:02:31 11-04-2013 00:07:34
1 2 8 11-04-2013 00:02:31 11-04-2013 00:07:34
1 1 9 11-04-2013 00:07:34 11-04-2013 00:11:01
1 2 9 11-04-2013 00:07:34 11-04-2013 00:11:01
1 1 10 11-04-2013 00:11:01 11-04-2013 00:11:02
1 2 10 11-04-2013 00:11:01 11-04-2013 00:11:02
1 1 11 11-04-2013 00:11:02 11-04-2013 00:12:03
1 2 11 11-04-2013 00:11:02 11-04-2013 00:12:03
1 1 12 11-04-2013 00:12:03 11-04-2013 00:15:46
1 2 12 11-04-2013 00:12:03 11-04-2013 00:15:46
1 1 13 11-04-2013 00:15:46 11-04-2013 00:17:59
1 2 13 11-04-2013 00:15:46 11-04-2013 00:17:59
Veja que a sequência 13 foi gerada em ambos os destino.
Após um novo switch de redo, veja como ficou a sequência 14:
THREAD# DEST_ID SEQUENCE# FIRST_TIME NEXT_TIME
---------- ---------- ---------- ------------------- -------------------
1 1 3 03-02-2013 10:14:05 10-04-2013 21:51:01
1 1 4 10-04-2013 21:51:01 10-04-2013 22:01:11
1 1 5 10-04-2013 22:01:11 10-04-2013 22:53:49
1 2 5 10-04-2013 22:01:11 10-04-2013 22:53:49
1 1 6 10-04-2013 22:53:49 10-04-2013 23:58:46
1 2 6 10-04-2013 22:53:49 10-04-2013 23:58:46
1 1 7 10-04-2013 23:58:46 11-04-2013 00:02:31
1 2 7 10-04-2013 23:58:46 11-04-2013 00:02:31
1 1 8 11-04-2013 00:02:31 11-04-2013 00:07:34
1 2 8 11-04-2013 00:02:31 11-04-2013 00:07:34
1 1 9 11-04-2013 00:07:34 11-04-2013 00:11:01
1 2 9 11-04-2013 00:07:34 11-04-2013 00:11:01
1 1 10 11-04-2013 00:11:01 11-04-2013 00:11:02
1 2 10 11-04-2013 00:11:01 11-04-2013 00:11:02
1 1 11 11-04-2013 00:11:02 11-04-2013 00:12:03
1 2 11 11-04-2013 00:11:02 11-04-2013 00:12:03
1 1 12 11-04-2013 00:12:03 11-04-2013 00:15:46
1 2 12 11-04-2013 00:12:03 11-04-2013 00:15:46
1 1 13 11-04-2013 00:15:46 11-04-2013 00:17:59
1 2 13 11-04-2013 00:15:46 11-04-2013 00:17:59
1 1 14 11-04-2013 00:17:59 11-04-2013 00:23:23
1 2 14 11-04-2013 00:17:59 11-04-2013 00:23:23
Isso confirma que nosso Data Guard está perfeitamente sincronizado.
Uma outra forma muito importante de verificar a sincronia do seu Data Guard é através do arquivo de log do seu banco de dados, veja no banco orcl a seguinte mensagem:
LNS: Standby redo logfile selected for thread 1 sequence 14 for destination LOG_ARCHIVE_DEST_2
Isso confirma que o processo LNS do banco ORCL, capturou a sequência 14 da tread 1 e enviou para o destino LOG_ARCHIVE_DEST_2. Confira abaixo:
Thu Apr 11 00:17:59 2013 Thread 1 advanced to log sequence 14 (LGWR switch) Current log# 2 seq# 14 mem# 0: /u01/app/oracle/oradata/orcl/redo02.log Thu Apr 11 00:17:59 2013 Archived Log entry 20 added for thread 1 sequence 13 ID 0x4f860f89 dest 1: Thu Apr 11 00:17:59 2013 LNS: Standby redo logfile selected for thread 1 sequence 14 for destination LOG_ARCHIVE_DEST_2
Com o envio da sequência 14, confirmada pelo alert log do banco orcl, temos no alert log do banco stdby que o processo RFS capturou a sequência 14 aplicou com sucesso no banco STDBY.
Thu Apr 11 00:17:58 2013 RFS[4]: Selected log 5 for thread 1 sequence 14 dbid 1334188681 branch 806407947 Thu Apr 11 00:17:58 2013 Archived Log entry 9 added for thread 1 sequence 14 ID 0x4f860f89 dest 1: Thu Apr 11 00:18:01 2013 Media Recovery Log /u01/app/oracle/archive/stdby/orcl_1_14_806407947.arc Media Recovery Waiting for thread 1 sequence 15
Próximos passos
Além da criação, vimos também como certificar a sincronia do Oracle Data Guard.
É claro que essa foi uma instalação básica e mostra de forma simplória o que o Data Guard faz, acredito que a partir disso fica muito mais fácil entender os conceitos complexos da ferramenta, além de conseguir aprofundar no tema.
Para quem quer aprender um pouco mais sobre o Oracle Data Guard, recomendo que para os próximos passos inicie o estudo sobre as outras formas de configurar o Data Guard, como por exemplo a SYNC, Snapshot Data Guard e Active DataGuard. É muito importante também aprender os outros tipos de proteção (Maximum Availability. Maximum Performance e Maximum Protection) entender o que o Redo Transport Services pode ajudar na melhoria do seu Data Guard, assim como aprender a administrar melhor o seu DG. Um outro passo muito importante é aprender a administrar o Data Guard pelo Oracle Oracle Data Guard Broker, que ajuda muito na execuções de switchover e switchback do seu Data Guard.
Qualquer dúvida postem um comentário, ficarei feliz em poder ajudar.
Um abraço!
April 11, 2013
…
Na parte anterior desta série, fizemos a criação do banco que representará o banco de dados primário o seu database de produção, aquele que queremos que os dados sejam protegidos.
Tanto no banco primário como no de contingência, para que o Oracle Data Guard 11g possa ser implementado, as configurações devem se estender em ambos os bancos. Hoje, nesta quinta parte vamos realizar as configurações do banco primário, deixando as configurações do banco standby para o próximo artigo.
Configurando o database primário
1. Habilitando o ARCHIVELOG Mode.
Nosso primeiro passo será configurar o banco de dados primário para archivelog mode. A maioria das features de Oracle HA (High Availability) requer que habilitemos o modo ARCHIVELOG no banco de dados. Ao habilitar esse modo, mudamos o comportamento do redo log para não mais ser sobrescrito e passará a arquivar todos os dados de log gerados pelos arquivos redo log do banco de dados. Você pode obter mais informações aqui:
Para você pode checar o modo de arquivamento do se o seu banco, através da seguinte consulta:
SQL> SELECT LOG_MODE FROM V$DATABASE; LOG_MODE ------------ NOARCHIVELOG
Antes de ativar o arquivamento do banco de dados, vamos certificar o status do nosso listener e do próprio banco de dados.
[oracle@bancodg ~]$ lsnrctl start
LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 10-APR-2013 21:41:53
Copyright (c) 1991, 2011, Oracle. All rights reserved.
Starting /u01/app/oracle/product/11.2.0/dbhome_1/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 11.2.0.3.0 - Production
System parameter file is /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Log messages written to /u01/app/oracle/diag/tnslsnr/bancodg/listener/alert/log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=bancodg.oracle.com)(PORT=1521)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=bancodg.oracle.com)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date 10-APR-2013 21:41:55
Uptime 0 days 0 hr. 0 min. 20 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/listener.ora
Listener Log File /u01/app/oracle/diag/tnslsnr/bancodg/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=bancodg.oracle.com)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
The listener supports no services
The command completed successfully
[oracle@bancodg ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 10 21:32:37 2013
Copyright (c) 1982, 2011, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup
ORACLE instance started.
Total System Global Area 1853947904 bytes
Fixed Size 2229384 bytes
Variable Size 452987768 bytes
Database Buffers 1392508928 bytes
Redo Buffers 6221824 bytes
Database mounted.
Database opened.
SQL>
Com o database primário iniciado, vamos criar o diretório para onde os archives logs gerados pelo banco será salvo.
SQL> !mkdir -p /u01/app/oracle/archive/orcl
Precisamos agora, definir o formato que será gravado o nosso arquivo de log no disco e a sua localização, temos para isso dois parâmetros: o log_archive_format e log_archive_dest_1. Pode-se definir vários destinos distintos de archives, através dos parâmetros log_archive_dest_2, log_archive_dest_3, log_archive_dest_4 e etc … Por enquanto, vamos apenas definir um único destino, que será o próprio disco local do servidor onde encontra-se o database primário.
SQL> alter system set log_archive_format='orcl_%t_%s_%r.arc' scope=spfile; System altered. SQL> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/archive/orcl' scope=spfile; System altered.
Com todas as configurações feitas, vamos agora ativar o modo de ARCHIVELOG. Para que isso é necessário baixar e subir a instância do banco Oracle.
SQL> shut immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 1853947904 bytes Fixed Size 2229384 bytes Variable Size 452987768 bytes Database Buffers 1392508928 bytes Redo Buffers 6221824 bytes Database mounted. SQL> alter database archivelog; Database altered. SQL> alter database open; Database altered. SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination /u01/app/oracle/archive/orcl Oldest online log sequence 1 Next log sequence to archive 3 Current log sequence 3
2. Habilitando o FORCE LOGGING modo
Quando é habilitado a modo de FORCE LOGGING no banco de dados Oracle, todas as mudanças que ocorrem no banco de dados são gerados logs, exceto para as tabelas e tablespaces temporários. Isso é fundamental para o Oracle Dataguard, pois assegura que toda transação efetivada (commit) pode ser capturada através dos arquivos de log do Oracle (redo ou archive).
Podemos ativar o modo de FORCE LOGGING da seguinte maneira:
SQL> alter database force logging; Database altered. SQL> select force_logging from v$database; FOR --- YES
3. Criando os arquivos de Standby Redo Log.
O Oracle Data Guard pode recuperar e aplicar mais dados do Standby Redo Log do que no convencional Redo Log, por isso a criação de SRL se faz necessária quando estamos montando um Oracle Data Guard.
Com a formula seguinte, é possível determinar o número apropriado dos SRL:
(maximum number of logfiles for each thread + 1) * maximum number of threads
Para o nosso caso: (3 + 1) * 1 = 4
É necessário também que o tamanho do SRL seja exatamente igual ao do Redo Log presente no seu banco, que no nosso ambiente é 50M.
Vamos então adicionar os 4 SRL para o database primário:
SQL> alter database add standby logfile group 4 '/u01/app/oracle/oradata/orcl/redo_st04.log' size 50M;
Database altered.
SQL> alter database add standby logfile group 5 '/u01/app/oracle/oradata/orcl/redo_st05.log' size 50M;
Database altered.
SQL> alter database add standby logfile group 6 '/u01/app/oracle/oradata/orcl/redo_st06.log' size 50M;
Database altered.
SQL> alter database add standby logfile group 7 '/u01/app/oracle/oradata/orcl/redo_st07.log' size 50M;
Database altered.
SQL> select group#, sequence#, archived, status from v$standby_log;
GROUP# SEQUENCE# ARC STATUS
---------- ---------- --- ----------
4 0 YES UNASSIGNED
5 0 YES UNASSIGNED
6 0 YES UNASSIGNED
7 0 YES UNASSIGNED
Você pode conferir os SRL no seu banco de dados, através da view V$standby_log, como fizemos acima.
4. Modificando os parâmetros de inicialização
Para uma configuração simples de Oracle Data Guard, basicamente precisamos mudar os 8 parâmetros de inicialização abaixo:
SQL> alter system set LOG_ARCHIVE_CONFIG='DG_CONFIG=(orcl,stdby)'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_1='LOCATION=/u01/app/oracle/archive/orcl VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=orcl'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_2='SERVICE=stdby LGWR ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=stdby'; System altered. SQL> alter system set LOG_ARCHIVE_DEST_STATE_1=ENABLE; System altered. SQL> alter system set FAL_SERVER=stdby; System altered. SQL> alter system set FAL_CLIENT=orcl; System altered. SQL> alter system set DB_FILE_NAME_CONVERT='/u01/app/oracle/oradata/stdby','/u01/app/oracle/oradata/orcl' scope=spfile; System altered. SQL> alter system set LOG_FILE_NAME_CONVERT='/u01/app/oracle/oradata/stdby','/u01/app/oracle/oradata/orcl' scope=spfile; System altered.
Segue a explicação de cada um deles:
LOG_ARCHIVE_CONFIG: Habita ou desabilita o comportamento de enviar as mensagens do redo log para o destino. Com a opção DG_CONFIG, podemos definir um range de até 9 destinos, definindo através do DB_UNIQUE_NAME de cada um deles.
LOG_ARCHIVE_DEST_1: Especifica o caminho do primeiro destino de archive do banco de dados. No nosso caso ele será gravado no caminho “/u01/app/oracle/archive/orcl” do servidor do banco primário. A opção VALID_FOR define como será gravado os dados, veja mais detalhes aqui: http://docs.oracle.com/cd/B28359_01/server.111/b28294/log_arch_dest_param.htm#i83986
LOG_ARCHIVE_DEST_2: Esse parâmetro, defini o segundo destino de archive. Nesse parâmetro que concentra a mágica do Oracle Dataguard, diferente com o que fizemos no primeiro destino (LOG_ARCHIVE_DEST_1), vamos fazer com que o segundo destino de archive do banco primário seja gravado no primeiro destino de archive do banco standby. Veja que é exatamente o que definimos nesse parâmetro, pedidos para o LGWR escrever os dados de log através do serviço chamado “stdby” para o banco de dados “stdby”
LOG_ARCHIVE_DEST_STATE_1: Com esse parâmetro, apenas definimos que o primeiro destino de archive está habitado. Por enquanto o segundo destino de archive (LOG_ARCHIVE_DEST_STATE_2) que levará os dados de log para o Data Guard, matemos desativado.
FAL_SERVER e FAL_CLIENT: São parâmetros de inicialização usados para o FAL (fetch archive log), ou seja é utilizado para a detecção e resolução dos destinos do Data Guard. Basicamente, o no banco primário o FAL_SERVER será o TNS service name do banco standby e vice-versa.
DB_FILE_NAME_CONVERT: Ele não é mandatório para o Data Guard, na verdade sua função não é nem para o Data Guard, ele é apenas utilizado no momento do recovery. Esse parâmetro como o nome diz converte o nome do datafile e tempfile do primário database para o correspondente caminho no standby database, é utíl muito útil no momento do recover, pois assim podemos renomear os datafiles facilmente. No nosso caso, vamos converter todos os datafiles que estão no caminho “/u01/app/oracle/oradata/orcl” no primário database para o novo caminho “/u01/app/oracle/oradata/stdby” no standby database.
LOG_FILE_NAME_CONVERT: O parâmetro LOG_FILE_NAME_CONVERT faz exatamente o que o DB_FILE_NAME_CONVERT faz, porém apenas com redo logs.
5. Backup do banco primário
Com todas as configurações feitas, precisamos agora realizar um backup do banco primário. O backup será feito através do RMAN no seguinte caminho: “/u01/app/oracle/backup/rman”
Siga os passos abaixo:
[oracle@bancodg ~]$ mkdir -p /u01/app/oracle/backup/rman
[oracle@bancodg ~]$ rman target /
Recovery Manager: Release 11.2.0.3.0 - Production on Wed Apr 10 22:32:36 2013
Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved.
connected to target database: ORCL (DBID=1334188681)
RMAN> run {
2> allocate channel c1 type disk;
3> allocate channel c2 type disk;
4> backup database format '/u01/app/oracle/backup/rman/%d_%s_%p_%U.bkp';
5> backup archivelog all format '/u01/app/oracle/backup/rman/ARCH_%d_%s_%p_%U.bkp';
6> backup current controlfile for standby format '/u01/app/oracle/backup/rman/control_%d_%U.bkp';
7> }
using target database control file instead of recovery catalog
allocated channel: c1
channel c1: SID=9 device type=DISK
allocated channel: c2
channel c2: SID=20 device type=DISK
Starting backup at 10-APR-13
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
input datafile file number=00001 name=/u01/app/oracle/oradata/orcl/system01.dbf
input datafile file number=00005 name=/u01/app/oracle/oradata/orcl/example01.dbf
channel c1: starting piece 1 at 10-APR-13
channel c2: starting full datafile backup set
channel c2: specifying datafile(s) in backup set
input datafile file number=00002 name=/u01/app/oracle/oradata/orcl/sysaux01.dbf
input datafile file number=00003 name=/u01/app/oracle/oradata/orcl/undotbs01.dbf
input datafile file number=00004 name=/u01/app/oracle/oradata/orcl/users01.dbf
channel c2: starting piece 1 at 10-APR-13
channel c2: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/ORCL_2_1_02o6ou56_1_1.bkp tag=TAG20130410T225222 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:35
channel c2: starting full datafile backup set
channel c2: specifying datafile(s) in backup set
including current control file in backup set
channel c2: starting piece 1 at 10-APR-13
channel c2: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/ORCL_3_1_03o6ou69_1_1.bkp tag=TAG20130410T225222 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:03
channel c2: starting full datafile backup set
channel c2: specifying datafile(s) in backup set
including current SPFILE in backup set
channel c2: starting piece 1 at 10-APR-13
channel c2: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/ORCL_4_1_04o6ou6g_1_1.bkp tag=TAG20130410T225222 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:03
channel c1: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/ORCL_1_1_01o6ou56_1_1.bkp tag=TAG20130410T225222 comment=NONE
channel c1: backup set complete, elapsed time: 00:01:27
Finished backup at 10-APR-13
Starting backup at 10-APR-13
current log archived
channel c1: starting archived log backup set
channel c1: specifying archived log(s) in backup set
input archived log thread=1 sequence=3 RECID=1 STAMP=812411465
input archived log thread=1 sequence=4 RECID=2 STAMP=812412072
channel c1: starting piece 1 at 10-APR-13
channel c2: starting archived log backup set
channel c2: specifying archived log(s) in backup set
input archived log thread=1 sequence=5 RECID=3 STAMP=812415231
channel c2: starting piece 1 at 10-APR-13
channel c1: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/ARCH_ORCL_5_1_05o6ou7v_1_1.bkp tag=TAG20130410T225351 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:07
channel c2: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/ARCH_ORCL_6_1_06o6ou7v_1_1.bkp tag=TAG20130410T225351 comment=NONE
channel c2: backup set complete, elapsed time: 00:00:07
Finished backup at 10-APR-13
Starting backup at 10-APR-13
channel c1: starting full datafile backup set
channel c1: specifying datafile(s) in backup set
including standby control file in backup set
channel c1: starting piece 1 at 10-APR-13
channel c1: finished piece 1 at 10-APR-13
piece handle=/u01/app/oracle/backup/rman/control_ORCL_07o6ou86_1_1.bkp tag=TAG20130410T225358 comment=NONE
channel c1: backup set complete, elapsed time: 00:00:01
Finished backup at 10-APR-13
released channel: c1
released channel: c2
RMAN>
6. Criando uma cópia do arquivo de inicialização
Vamos criar uma cópia do arquivo de inicialização do nosso banco primário, a cópia será feita no mesmo caminho do backup que acabamos de fazer, isso porque iremos mover toda essa pasta para o servidor do banco standby. Segue:
[oracle@bancodg ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Wed Apr 10 23:02:21 2013 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> create pfile='/u01/app/oracle/backup/rman/initstdby.ora' from spfile; File created.
7. Copia do password file
Será necessário também que uma cópia do passord file do banco primário esteja no servidor contigência com o nome do banco standby.
[oracle@bancodg dbs]$ cd $ORACLE_HOME/dbs [oracle@bancodg dbs]$ scp orapworcl standdg:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwstdby oracle@standdg's password: orapworcl 100% 1536 1.5KB/s 00:00
8. Criando os serviços TNS
O Oracle Data Guard é totalmente configurado para ser executado em cima do Oracle NET. Toda sua comunicação com os bancos de standby é feito através do serviços configurados no TNS.
No nosso caso, assim como foi configurado os parâmetros no passo 4 acima, precisamor ter os serviços “orcl” e “stdby” em ambas as máquinas.
Segue:
[oracle@bancodg ~]$ cd $ORACLE_HOME/network/admin
[oracle@bancodg admin]$ vi tnsnames.ora
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/11.2.0/dbhome_1/network/admin/tnsnames.ora
# Generated by Oracle configuration tools.
ORCL =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = bancodg.oracle.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)
STDBY =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = standdg.oracle.com)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = stdby)
)
)
Com a configuração realizada, vamos para um teste simples, primeiro no serviço orcl depois no stdby.
[oracle@bancodg admin]$ tnsping orcl TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 10-APR-2013 23:06:33 Copyright (c) 1997, 2011, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = bancodg.oracle.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl))) [oracle@bancodg admin]$ tnsping stdby TNS Ping Utility for Linux: Version 11.2.0.3.0 - Production on 10-APR-2013 23:06:33 Copyright (c) 1997, 2011, Oracle. All rights reserved. Used parameter files: Used TNSNAMES adapter to resolve the alias Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = standdg.oracle.com)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = stdby)))
Caso você receba o erro TNS-12541: TNS:no listener, você provavelmente esqueceu de subir o listener no servidor standby.
9. Movendo os arquivos para o standby
Temos agora o nosso banco primário todo configurado e pronto para iniciar o standby, precisamos apenas mover o backup e o arquivo de inicialização que estão no nosso servidor primário para o banco standby.
[oracle@bancodg ~]$ cd $ORACLE_BASE/backup/rman [oracle@bancodg rman]$ ls -ltr total 1208568 -rw-r----- 1 oracle oinstall 420593664 Apr 10 22:52 ORCL_2_1_02o6ou56_1_1.bkp -rw-r----- 1 oracle oinstall 9797632 Apr 10 22:53 ORCL_3_1_03o6ou69_1_1.bkp -rw-r----- 1 oracle oinstall 98304 Apr 10 22:53 ORCL_4_1_04o6ou6g_1_1.bkp -rw-r----- 1 oracle oinstall 703807488 Apr 10 22:53 ORCL_1_1_01o6ou56_1_1.bkp -rw-r----- 1 oracle oinstall 59481600 Apr 10 22:53 ARCH_ORCL_5_1_05o6ou7v_1_1.bkp -rw-r----- 1 oracle oinstall 32740864 Apr 10 22:53 ARCH_ORCL_6_1_06o6ou7v_1_1.bkp -rw-r----- 1 oracle oinstall 9797632 Apr 10 22:53 control_ORCL_07o6ou86_1_1.bkp -rw-r--r-- 1 oracle oinstall 1388 Apr 10 23:02 initstdby.ora
Para que a restauração seja mais fácil, sem a necessidade de catalogar os backup, vamos criar o mesmo diretório no servidor standby
[oracle@bancodg rman]$ ssh oracle@standdg mkdir -p /u01/app/oracle/backup/rman oracle@standdg's password:
Com o diretório criado, vamos apenas mover todos os arquivos da pasta /u01/app/oracle/backup/rman para o servidor standby.
[oracle@bancodg rman]$ pwd /u01/app/oracle/backup/rman [oracle@bancodg rman]$ scp * standdg:`pwd` oracle@standdg's password: ARCH_ORCL_5_1_05o6ou7v_1_1.bkp 100% 57MB 28.4MB/s 00:02 ARCH_ORCL_6_1_06o6ou7v_1_1.bkp 100% 31MB 31.2MB/s 00:01 control_ORCL_07o6ou86_1_1.bkp 100% 9568KB 9.3MB/s 00:00 initstdby.ora 100% 1388 1.4KB/s 00:00 ORCL_1_1_01o6ou56_1_1.bkp 100% 671MB 22.4MB/s 00:30 ORCL_2_1_02o6ou56_1_1.bkp 100% 401MB 26.7MB/s 00:15 ORCL_3_1_03o6ou69_1_1.bkp 100% 9568KB 9.3MB/s 00:01 ORCL_4_1_04o6ou6g_1_1.bkp 100% 96KB 96.0KB/s 00:00
Essa parte termina aqui. Na parte 6 (próxima parte), iremos configurar o database standby, terminando assim a criação do Oracle Dataguard 11g.
Até lá …
February 15, 2013
…
Na parte 2 vimos como configurar e instalar o software do Oracle Database 11g.
Como é necessário duas máquinas virtuais para o nosso teste com Oracle Data Guard 11g, iremos então clonar literalmente a máquina DB Primary para a máquina a nova máquina virtual chamada DB Dataguard. Essa ação é muito fácil de ser feita com o VirtualBox, apenas com alguns cliques temos nossa máquina clonada.
Após a clonagem, teremos os seguintes ambientes para os testes de Dataguard:
Clonando a VM
Para clonar a VM DB Primary, siga os passos abaixos:
Clique na opção Clone … para abrir o assistente de configuração da nova máquina virtual.
Defina o nome como DB Dataguard.
Escolha a opção Full clone para iniciar a clonagem da VM.
Nesse ponto temos duas máquinas virtuais, uma chamada DB Primary que é nosso banco de dados produção e a VM DB Dataguard que é o Oracle Dataguard do banco de dados da máquina DB Primary.
Vamos iniciar a máquina DB Dataguard para iniciarmos as configurações nessa máquina.
Com a máquina ligada, clique em Administration depois Network.
Clique no botão EDIT para a interface eth0.
Defina o IP 20.0.0.20 para o endereço ip da interface.
Confirme a operação.
Agora na aba DNS mude o hostname para standdg.oracle.com
Agora precismos ativar a interface, para isso clique no botão Activate.
Agora, precisamos alterar o arquivo host da máquina, para isso, vamos conectar na máquina de Dataguard e mudar o arquivo de configuração /etc/hosts
FlavioSoares:VirtualBox VMs flaviosoares$ ssh root@20.0.0.20 The authenticity of host '20.0.0.20 (20.0.0.20)' can't be established. RSA key fingerprint is 66:86:82:d1:f4:72:1a:a0:55:c3:b2:65:f8:64:1f:17. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '20.0.0.20' (RSA) to the list of known hosts. root@20.0.0.20's password: Last login: Thu Jan 31 23:37:17 2013 [root@standdg ~]#
[root@standdg ~]# vi /etc/hosts
# Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 20.0.0.10 bancodg.oracle.com bancodg 20.0.0.20 standdg.oracle.com standdg [root@standdg ~]# [root@standdg ~]# hostname standdg.oracle.com [root@standdg ~]# hostname -i 20.0.0.20
Por último, precisamos mudar a variável de ambiente ORACLE_SID, para o banco que será o nosso Dataguard que no nosso caso chama-se stdby para o banco de Dataguard:
[oracle@standdg ~]$ cat ~/.bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1
export ORACLE_SID=stdby
export PATH=$ORACLE_HOME/bin:$PATH
Teste de conectividade entre as VMs
Para iniciar os testes de conectividade das máquinas, inicie a VM DB Primary.
Com a máquina DB Primary ligada, conecte e realizar os testes abaixos.
FlavioSoares:VirtualBox VMs flaviosoares$ ssh root@20.0.0.10 root@20.0.0.10's password: Last login: Thu Jan 31 23:59:23 2013 from 20.0.0.1 [root@bancodg ~]# cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 20.0.0.10 bancodg.oracle.com bancodg 20.0.0.20 standdg.oracle.com standdg
[root@bancodg ~]# hostname
bancodg.oracle.com [root@bancodg ~]# ping standdg PING standdg.oracle.com (20.0.0.20) 56(84) bytes of data. 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=1 ttl=64 time=1.30 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=2 ttl=64 time=0.237 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=3 ttl=64 time=0.404 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=4 ttl=64 time=0.358 ms --- standdg.oracle.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3002ms rtt min/avg/max/mdev = 0.237/0.577/1.309/0.427 ms [root@bancodg ~]# ping standdg.oracle.com PING standdg.oracle.com (20.0.0.20) 56(84) bytes of data. 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=1 ttl=64 time=0.247 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=2 ttl=64 time=0.340 ms 64 bytes from standdg.oracle.com (20.0.0.20): icmp_seq=3 ttl=64 time=1.00 ms --- standdg.oracle.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 0.247/0.529/1.001/0.336 ms
Agora faça o teste inverso, da máquina virtual DB Dataguard faça o seguinte:
[root@standdg ~]# hostname standdg.oracle.com [root@standdg ~]# ping bancodg PING bancodg.oracle.com (20.0.0.10) 56(84) bytes of data. 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=1 ttl=64 time=0.181 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=2 ttl=64 time=0.363 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=3 ttl=64 time=0.278 ms --- bancodg.oracle.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.181/0.274/0.363/0.074 ms [root@standdg ~]# ping bancodg.oracle.com PING bancodg.oracle.com (20.0.0.10) 56(84) bytes of data. 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=1 ttl=64 time=0.134 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=2 ttl=64 time=0.247 ms 64 bytes from bancodg.oracle.com (20.0.0.10): icmp_seq=3 ttl=64 time=0.379 ms --- bancodg.oracle.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.134/0.253/0.379/0.100 ms
Criando o LISTENER
Aproveitando que as duas VMs estão ligadas e seus host atualizados, vamos aproveitar e criar o listener nelas. Para isso conecte com o usuário oracle em cada uma das máquina e realize os passos abaixo:
Execute o comando netca
Acima está apenas os passos da máquina DB Primary (bancodg), é necessário realizar os mesmos passos para a máquina DB Dataguard (standdg).
January 30, 2013
…
Na primeira parte da nossa série, foi criada a máquina virtual chamada de “DB Primary”, ela será nosso Primary Database (está lembrado?). Temos somente o Oracle Linux instalado nessa máquina, precisamos hoje criar as configurações do pré-requisitos e instalarmos o Oracle Database 11g nessa máquina.
Após essa máquina virtual está totalmente configurada e instalada, iremos criar um clone desse disco para a criação do Dataguard Database, mais isso faremos juntos na parte 3.
Hoje nossa missão é realizar os pré requisitos e instalar o Oracle Database 11gR2, para isso tenha em mãos o binário de instalação do Oracle 11g R2. Vou utilizar aqui a versão 11.2.0.3, porém fica a seu critério que release 11g R2 utilizar.
Com a máquina virtual ligada, clique no disco vazio que fica na barra de status da VM (veja o marco em vermelho).
Após ter clicado, irá mostrar os discos ISO disponíveis, provavelmente o Oracle Linux estará, caso não esteja selecione através da opção “Choose a virtual CD/DVD disk file …”
Feito isso, você verá a ISO do Oracle Linux sendo montada como um CDROM na máquina Virtual:
Veja que a ISO está apontando para o diretório /media/Enterprise Linux dvd 20100405.
[root@bancodg ~]# df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 19G 3.0G 15G 17% / tmpfs 502M 0 502M 0% /dev/shm /dev/hda 3.4G 3.4G 0 100% /media/Enterprise Linux dvd 20100405
Entre no diretório da ISO.
[root@bancodg ~]# cd /media/Enterprise\ Linux\ dvd\ 20100405/Server/ [root@bancodg Server]#
É necessário agora realizar a instalação dos pacotes rpm Linux. Seja abaixo a instalação de cada um deles.
[root@bancodg Server]# rpm -ivh binutils-2.17.50.0.6-14.el5.x86_64.rpm warning: binutils-2.17.50.0.6-14.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package binutils-2.17.50.0.6-14.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh compat-libstdc++-33-3.2.3-61.x86_64.rpm warning: compat-libstdc++-33-3.2.3-61.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package compat-libstdc++-33-3.2.3-61.x86_64 is already installed [root@bancodg Server]# rpm -ivh compat-libstdc++-33-3.2.3-61.i386.rpm warning: compat-libstdc++-33-3.2.3-61.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package compat-libstdc++-33-3.2.3-61.i386 is already installed [root@bancodg Server]# rpm -ivh elfutils-libelf-0.137-3.el5.x86_64.rpm warning: elfutils-libelf-0.137-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package elfutils-libelf-0.137-3.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-2.5-49.x86_64.rpm warning: glibc-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-2.5-49.i686.rpm warning: glibc-2.5-49.i686.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-2.5-49.i686 is already installed [root@bancodg Server]# rpm -ivh glibc-common-2.5-49.x86_64.rpm warning: glibc-common-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-common-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh ksh-20100202-1.el5.x86_64.rpm warning: ksh-20100202-1.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package ksh-20100202-1.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libaio-0.3.106-5.x86_64.rpm warning: libaio-0.3.106-5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libaio-0.3.106-5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libaio-0.3.106-5.i386.rpm warning: libaio-0.3.106-5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libaio-0.3.106-5.i386 is already installed [root@bancodg Server]# rpm -ivh libgcc-4.1.2-48.el5.x86_64.rpm warning: libgcc-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libgcc-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libgcc-4.1.2-48.el5.i386.rpm warning: libgcc-4.1.2-48.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libgcc-4.1.2-48.el5.i386 is already installed [root@bancodg Server]# rpm -ivh libstdc++-4.1.2-48.el5.x86_64.rpm warning: libstdc++-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libstdc++-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libstdc++-4.1.2-48.el5.i386.rpm warning: libstdc++-4.1.2-48.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libstdc++-4.1.2-48.el5.i386 is already installed [root@bancodg Server]# rpm -ivh make-3.81-3.el5.x86_64.rpm warning: make-3.81-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package make-3.81-3.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh unixODBC-2.2.11-7.1.x86_64.rpm warning: unixODBC-2.2.11-7.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC ########################################### [100%] [root@bancodg Server]# rpm -ivh unixODBC-2.2.11-7.1.i386.rpm warning: unixODBC-2.2.11-7.1.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC ########################################### [100%] [root@bancodg Server]# rpm -ivh unixODBC-devel-2.2.11-7.1.x86_64.rpm warning: unixODBC-devel-2.2.11-7.1.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC-devel ########################################### [100%] [root@bancodg Server]# rpm -ivh unixODBC-devel-2.2.11-7.1.i386.rpm warning: unixODBC-devel-2.2.11-7.1.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] 1:unixODBC-devel ########################################### [100%] [root@bancodg Server]# rpm -ivh elfutils-libelf-devel-static-0.137-3.el5.x86_64.rpm warning: elfutils-libelf-devel-static-0.137-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package elfutils-libelf-devel-static-0.137-3.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh gcc-4.1.2-48.el5.x86_64.rpm warning: gcc-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package gcc-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh gcc-c++-4.1.2-48.el5.x86_64.rpm warning: gcc-c++-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package gcc-c++-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-devel-2.5-49.x86_64.rpm warning: glibc-devel-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-devel-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh glibc-devel-2.5-49.i386.rpm warning: glibc-devel-2.5-49.i386.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-devel-2.5-49.i386 is already installed [root@bancodg Server]# rpm -ivh glibc-headers-2.5-49.x86_64.rpm warning: glibc-headers-2.5-49.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package glibc-headers-2.5-49.x86_64 is already installed [root@bancodg Server]# rpm -ivh kernel-headers-2.6.18-194.el5.x86_64.rpm warning: kernel-headers-2.6.18-194.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package kernel-headers-2.6.18-194.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libgomp-4.4.0-6.el5.x86_64.rpm warning: libgomp-4.4.0-6.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libgomp-4.4.0-6.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh libstdc++-devel-4.1.2-48.el5.x86_64.rpm warning: libstdc++-devel-4.1.2-48.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package libstdc++-devel-4.1.2-48.el5.x86_64 is already installed [root@bancodg Server]# rpm -ivh sysstat-7.0.2-3.el5.x86_64.rpm warning: sysstat-7.0.2-3.el5.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159 Preparing... ########################################### [100%] package sysstat-7.0.2-3.el5.x86_64 is already installed
Com todos os pacotes instalados, vamos as configurações de kernel do sistema operacional. Faça as seguintes operações:
[root@bancodg ~]# vi /etc/sysctl.conf
#Oracle Settings
kernel.shmmni = 4096
kernel.sem = 250 32000 100 128
fs.file-max = 6815744
fs.aio-max-nr = 1048576
net.ipv4.ip_local_port_range = 9000 65500
net.core.rmem_default = 262144
net.core.rmem_max = 4194304
net.core.wmem_default = 262144
net.core.wmem_max = 1048576
Para ativa-lós execute o sysctl como abaixo:
[root@bancodg ~]# sysctl -p
Hora de configurar os limits do Oracle, para isso adicione as seguintes linhas no arquivo /etc/security/limits.conf
[root@bancodg ~]# vi /etc/security/limits.conf
#Oracle Settings
oracle soft nproc 2047
oracle hard nproc 16384
oracle soft nofile 1024
oracle hard nofile 65536
oracle soft stack 10240
Edite também as limites do arquivo /etc/profile.
[root@bancodg ~]# vi /etc/profile
if [ $USER = "oracle" ]; then
if [ $SHELL = "/bin/ksh" ]; then
ulimit -u 16384
ulimit -n 65536
else
ulimit -u 16384 -n 65536
fi
fi
Configure agora o arquivo /etc/pam.d/login com a linha abaixo:
[root@bancodg ~]# vi /etc/pam.d/login
session required pam_limits.so
Pronto, limites e demais configurações feitas. Vamos a validação do host que é muito importante para um ambiente DataGuard.
[root@bancodg ~]# vi /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
20.0.0.10 bancodg.oracle.com bancodg
Checando o hostname:
[root@bancodg ~]# hostname bancodg.oracle.com [root@bancodg ~]# hostname -i 20.0.0.10
Com as configurações acima, vamos agora criar o usuário oracle:
[root@bancodg ~]# groupadd oinstall [root@bancodg ~]# groupadd dba [root@bancodg ~]# useradd -g oinstall -G dba oracle
Altere a senha do usuário também:
[root@bancodg ~]# passwd oracle Changing password for user oracle. New UNIX password: oracle BAD PASSWORD: it is based on a dictionary word Retype new UNIX password: oracle passwd: all authentication tokens updated successfully.
Vamos agora a criação do diretório. Faça os seguintes comandos:
[root@bancodg ~]# mkdir -p /u01/app/oracle [root@bancodg ~]# chown -R oracle:oinstall /u01/
Pronto! As configurações todas ok.
Precisamos agora transferir o binário do Oracle para a máquina virtual. Caso você estiver em um ambiente windows, você pode utilizar o winscp. No meu caso vou utilizar o utilitário scp.
$ scp p10404530_112030_Linux-x86-64_1of7.zip p10404530_112030_Linux-x86-64_2of7.zip oracle@20.0.0.10:/u01/app/oracle/. oracle@20.0.0.10's password: *********** p10404530_112030_Linux-x86-64_1of7.zip 100% 01:28 ETA p10404530_112030_Linux-x86-64_2of7.zip 100% 01:45 ETA
Antes de instalar, precisamos é claro, descompactar os arquivos de instalação na máquina virtual.
Acesse novamente a VM do VirtualBox, e entre no caminho /u01/app/oracle (ou onde você deixou os binários) e utilize o unzip para descompactar os arquivos. Faça primeiro no arquivo 1 depois no arquivo 2, como abaixo:
[oracle@bancodg ~]$ cd /u01/app/oracle/ [oracle@bancodg oracle]$ ll total 2444440 -rwxr-xr-x 1 oracle oinstall 1358454646 Jan 16 22:44 p10404530_112030_Linux-x86-64_1of7.zip -rwxr-xr-x 1 oracle oinstall 1142195302 Jan 16 22:45 p10404530_112030_Linux-x86-64_2of7.zip [oracle@bancodg oracle]$ unzip p10404530_112030_Linux-x86-64_1of7.zip ... inflating: database/stage/properties/oracle.server_PE.properties inflating: database/stage/properties/sshConnectivity-usage.txt inflating: database/stage/properties/oracle.server_Custom.properties inflating: database/stage/properties/sPaths.properties inflating: database/stage/properties/ssh_system.properties inflating: database/stage/properties/oracle.server_SE.properties inflating: database/stage/properties/userPaths.properties inflating: database/welcome.html inflating: database/readme.html [oracle@bancodg oracle]$ unzip p10404530_112030_Linux-x86-64_2of7.zip ... inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup10.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup11.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup7.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup5.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup3.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup1.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup13.jar inflating: database/stage/Components/oracle.sysman.console.db/11.2.0.3.0/1/DataFiles/filegroup2.jar
Feito os passos acima, uma pasta chamada “database” será criada no atual diretório. Ela contém os binários de instalação do software Oracle Database 11gR2.
Vamos então para esse diretório, que no meu caso é o /u01/app/oracle/database:
LEMBRE-SE VOCÊ DEVE ESTAR COM O USUÁRIO ORACLE CONECTADO NA MÁQUINA VIRTUAL
Dispare o runInstaller, como na Imagem acima.
O runInstaller irá abrir uma janela de utilitário de passo a passo de instalação do software. Seguiremos os passos:
Primeiro, desmarque a opção de receber updates via My Oracle Support.
Um aviso será mostrado, pode ignora-ló e continue.
Por ser um ambiente totalmente feito para teste, vamos novamente ignorar os updates. Para isso clique em Skip software updates
Aqui, temos que selecionar o tipo da instalação. Vamos por enquanto somente instalar somente o software Oracle Database 11gR2.
Selecione opção Enterprise. Lembrando para usar o Oracle Dataguard, é obrigatório e imprescindível que a versão seja Enterprise Edition. Por isso ATENÇÃO, selecione a versão ENTERPRISE EDITION para essa instalação.
Define aqui a localização das variáveis ORACLE BASE e ORACLE_HOME.
Nesse momento é realizado um checklist completo do ambiente Oracle sobre as possíveis falhas de pré requisitos. No nosso caso, ele informou somente a falta de memória. Por ser um ambiente criado somente com a finalidade de estudo, podemos deixar a memória da máquina baixa (por motivos óbvios), porém em ambientes de produção nunca ignore tais erros.
Aqui é informado um resume de todas as configurações selecionadas.
Início da instalação …
É informado agora, para rodarmos dois scripts com o usuário root. Simplesmente assim: conecte como root e execute os dois.
[root@bancodg ~]# whoami root [root@bancodg ~]# /u01/app/oraInventory/orainstRoot.sh Changing permissions of /u01/app/oraInventory. Adding read,write permissions for group. Removing read,write,execute permissions for world. Changing groupname of /u01/app/oraInventory to oinstall. The execution of the script is complete.
Agora o segundo
[root@bancodg ~]# whoami
root
[root@bancodg ~]# /u01/app/oracle/product/11.2.0/dbhome_1/root.sh
Performing root user operation for Oracle 11g
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /u01/app/oracle/product/11.2.0/dbhome_1
Enter the full pathname of the local bin directory: [/usr/local/bin]:
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Creating /etc/oratab file...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Finished product-specific root actions.
Fim da instalação
Com a conclusão da parte 2, temos a máquina virtual criada com o Oracle Database e todos os pré-requisitos feitos.
Vamos somente agora, adicionar as variáveis de ambiente da máquina DB Primary. Com o usuário oracle conectado, edite o arquivo ˜/.bash_profile e adicione as seguintes linhas:
[oracle@bancodg ~]$ vi ~/.bash_profile # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=$PATH:$HOME/bin export PATH export ORACLE_BASE=/u01/app/oracle export ORACLE_HOME=$ORACLE_BASE/product/11.2.0/dbhome_1 export ORACLE_SID=orcl export PATH=$ORACLE_HOME/bin:$PATH [oracle@bancodg ~]$
Agora ative as variáveis com o comando:
[oracle@bancodg ~]$ . ~/bash_profile
Na próxima parte, estarei realizando a cópia dessa VM ponta, para poder criar a máquina em um outro projeto.
November 26, 2012
…
Esse é o primeiro post de uma série inteira que está por vir, explicando passo a passo a instalação e configuração do Oracle Data Guard 11g utilizando o VirtualBox.
O Oracle Data Guard faz parte do Oracle Database High Availability, ou seja, estamos falando de alta disponibilidade (HA). Diferentemente do Oracle RAC o Data Guard trabalha exclusivamente com os dados do seu banco, dados esses que são o bem mais crítico do negócio de uma empresa. O Data Guard é uma solução de proteção a dados como também, a disponibilidade deles, que cria e mantém um ou mais bancos de contingência (standby) sendo possível assim, recuperar de um completo desastre.
Não gosto de chamar o Oracle Dataguard simplesmente de um banco de standby, por que ele vai além disso as opções de configuração e otimização levam ele a um grau muito acima do que um simples banco de contingência. (veja mais sobre ele aqui)
Em uma configuração Data Guard, sempre terá o banco de dados primário e um ou mais bancos de standby, este por sua vez só será ativo quando houver problemas no banco primário, ou por qualquer outro motivo que precisamos utiliza-ló, como por exemplo uma manutenção no servidor onde o banco de dados primário encontra-se.
Sempre que um banco standby for ativado (switchover) ele é automáticamente “transformado” no banco primário e o banco primário passa a ser o standby. Podemos também realizar a volta (switchback) em que o banco standby atual (antigo primário) volta a ser o banco de dados produção e o atual primário (antigo standby) torna a ser o o banco de contigencia novamente.
Seja o modelo de uma configuração básica do Dataguard.
A partir do 11g, existe três tipos de Data Guard:
- Physical database : É a cópia física perfeitamente identica do seu banco primário. Realmente é um clone feito bloco a bloco mantendo toda a estrutura de diretório, schemas, objetos e etc … Ele é mantido sincronizado através do Redo Apply.
- Logical database: Ele contém a mesma estrutura lógica (tabelas, objetos, indexes etc …) porém a sua organização física e estrutural pode ser diferente. Ele é mantido sincronizado através do SQL Apply.
- Snapshot database: Ele é um banco de contingência que é possível realizar qualquer movimentação de dados e ainda assim ele se mantém sincronizado, ou seja ele permite que qualquer sessão altere qualquer informação no banco enquanto ele se mantém sincronizado. Na verdade, enquanto o banco está aberto para utilização, ele represa os archives que são aplicados assim que voltamos o banco no modo standby.
Estaremos vendo aqui os três tipos de Data Guard, passando pelo Physical depois Logical e em seguida o Snapshot.
Vamos também aprender sobre o Oracle Data Broker, que automatiza (E MUITO) as operações de manutenção e monitoramento do Data Guard Oracle.
Caso queiram tirar alguma dúvida sobre Data Guard por favor deixe um comentário, no possível … estarei ajudando 
Pré-Requisitos:
Vou começar esse artigo passando desde a criação da máquina virtual, então você que não está familiarizado com a instalação do Oracle no Linux, fique despreocupado que vamos ver tudo aqui.
Para poder acompanhar vamos precisar:
- Virtual Box instalado na máquina
- Software Oracle 11g R2 (não é preciso o release 11.2.0.3).
- ISO do Oracle Linux 5.x (ou similares). Você pode fazer o download gratuito aqui, basta apenas se cadastrar
Vamos precisar de duas VM rodando na máquina, por isso recomendo que sua máquina tenha no mínimo 4G de RAM, vamos criar as máquina com 1G cada uma. Caso você não tenha 4G de RAM na sua máquina não tem problema, crie suas máquinas virtuais com menos RAM, porém as coisas irão ficar um pouco mais lentas.
Configurando o VirtualBox
Com o VirtualBox instalado, vamos realizar as configurações de Network.
Ao abrir as preferencias do VirtualBox a tela abaixo irá ser mostrada:
Clique na aba Network, e adicione mais um adaptador de rede clicando no ícone de “+” no canto direto da tela.
Adicione as seguintes configurações de IP nessa nova placa de rede.
Certifique-se que não existe nenhuma configuração de DHCP, como mostra abaixo:
Criação da máquina Virtual (DB Primary).
Com as configurações necessárias feitas, vamos agora a criação da VM onde será o nosso Database Primary. Com o VirtualBox aberto clique no botão New.
Como a versão da minha ISO do Oracle Linux é x86-64, a versão minha selecionada foi o Oracle Linux 64bits. Caso a versão da sua ISO for x86 selecione a opção 32bits.
Selecione a quantidade de memória desejada.
Aqui temos nossa VM criada, vamos a algumas configurações necessárias. Por isso, selecione a VM DB Primary e clique na opção Settings.
Na aba System, remova o Floppy disk no Boot:
Clique na opção Processor, e caso você deseje, adicione mais um processador a máquina virtual.
Vá a Aba Storage, para adicionarmos a ISO de instalação do Oracle Linux.
Selecione o disco vázio na Controladora IDE, remova clicando no icone “-”.
Clique no icone +, e selecione a ISO do Oracle Linux.
Agora a última configuração, vá a aba Network e defina o adaptador como Host-only Adapter e selecione o adaptador vboxnet1.
Instalação do Oracle Linux
Agora sim, vamos a instalação do Linux. Inicie a máquina virtual.
Vamos cancelar essa etapa de checagem dos discos. Selecione o Skip e continue.
Aqui será mostrado uma mensagem de que estaremos iniciando a configuração de disco. Selecione em Yes e continue.
Selecione a opção Create custom layout, e continue.
Vamos agora, definir o layout do disco. Como o disco foi criado com 20G, estarei configurando da seguinte maneira:
- Swap: 1G
- Partição / com 19G.
Fique a vontade para configurar da maneira que desejar. Clique no botão New.
Defina o Swap.
Clique no botão New novamente e defina a partição / como ext3 e clique na opção Fill to maximum allowable size.
Na próxima tela, apenas continue.
Vamos agora a configuração da rede. Selecione o adaptador eth0 e clique no botão Edit.
Aqui estarei definindo o IP: 20.0.0.10 com o Netmask: 255.255.0.0
Com o adaptador configurado, vamos definir um hostname para o Linux instalado. Após deixar como a figura abaixo clique em Next.
Selecione o TimeZone de SP:
Defina agora a senha do usuário root, que aqui vou colocar como oracle.
Vamos agora uma das partes mais importantes, a definição dos pacotes. Selecione a opção Customize now e clique em Next.
Em Desktop Enviroments, deixe as opções como está. Clique em no item Applications.
Deixe as opções como na imagem abaixo:
Agora em Development, deixe as opções novamente iguais. Clique no item X Software Development e clique em Optional packages.
Selecione o pacote libxp-devel para ser instalado e clique em Close.
Agora vamos para o Server, e deixe iguais as opções de instalação.
Vá para a opção Base System agora e deixa como as opções da figura abaixo. Depois de feito, selecione a opção System Tools e clique na opção Optional packages e selecione o pacote sysstat para ser instalado.
Depois de feito, clique em Next.
Iniciando a instalação.
Com a instalação concluida, vamos reiniciar a máquina.
Desabilite as opções de Firewall.
Não vamos criar nenhum usuário agora, clique em Next e depois em Continue.
Instalação do Guest Additions VirtualBox
Com o nosso Linux instalado, vamos instalar o Guest Additions do VirtualBox que nada mais é que um otimizador da VM. Com a VM ligada vamos logar na máquina com o usuário root.
Após de logado, clique no item Install Guest Additions.
Um disco será criado e adicionado na máquina Virtual como mostra a figura abaixo.
Abra um terminal e vá para o diretório /media/VBOXADDITIONS … e execute o script VBoxLinuxAdditions.run
Temos agora a máquina virtual necessária para instalarmos o Oracle Database 11g. Na nossa próxima parte dessa série estaremos então instalando o Oracle Database 11g.
Um abraço, espero que tenham gostado da idéia e continuem acompanhando. Qualquer dúvida post um comentário ..
October 17, 2012
O erro ORA-00845 é disparado sempre no startup de uma instância Oracle 11g, falhando com a seguinte mensagem de erro:
ORA-845: MEMORY_TARGET not supported on this system
O parâmetro MEMORY_TARGET define o tamanho a área que o Automatic Memory Management (AMM) irá poder trabalhar. O AMM permite o banco de dados Oracle realizar a redução e aumento das áreas SGA ou PGA como necessário, fazendo assim um tuning online do seu banco de dados.
Como esse artigo não se destina a explicar o que é AMM, você pode conferir mais detalhes na própria documentação Oracle: http://docs.oracle.com/cd/E11882_01/server.112/e25494/memory003.htm
O erro ORA-845 acontece quando você define um valor para o MEMORY_TARGET além do que o sistema consegue gerênciar. Vamos a um exemplo para ficar mais fácil
Em uma máquina de teste, tenho 5G de memória RAM:
[oracle@oracle11g ~]$ grep MemTotal /proc/meminfo MemTotal: 5079856 kB
Meu banco de dados, está com o MEMORY_TARGET para 1984M (quase 2G).
[oracle@oracle11g ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.2.0 Production on Tue Oct 16 23:13:59 2012 Copyright (c) 1982, 2010, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> show parameter memory NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ hi_shared_memory_address integer 0 memory_max_target big integer 1984M memory_target big integer 1984M shared_memory_address integer 0
Uma outra informação importante (você vai entender logo mais), o meu espaço em disco:
[oracle@oracle11g ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 19G 9.0G 8.5G 52% / tmpfs 2.5G 1.2G 1.3G 48% /dev/shm
Quero agora aumentar 500M da minha AMM, vamo mudarentão o parâmetro MEMORY_TARGET para 2500M:
SQL> alter system set memory_max_target=2500M scope=spfile; System altered. SQL> alter system set memory_target=2500M scope=spfile; System altered. SQL> shut immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> SQL> startup ORA-00845: MEMORY_TARGET not supported on this system SQL>
A primeira vez que vi o erro não consegui entender muito bem do que se tratava. Já que tenho memória livre de sobra, como pode 500M interferir no startup da minha instância?
Tudo ficou ainda mais confuso, quando li uma note no site do supporte da Oracle:
ORA-00845 When Starting Up An 11g Instance With AMM Configured. [ID 460506.1]
A nota diz claramente que o valor do parâmetro memory_target está relacionado com o tamanho da partição /dev/shm, e que para resolver o problema tenho que aumentar a partição /dev/shm para um valor maior:
# mount -t tmpfs shmfs -o size=7G /dev/shm
Feito isso minha instância subiu sem problema algum.
Ok … Perfeito, tudo funcionando …
Porém …
Surge agora o objetivo desse post, explicar o que o AMM tem q ver com a partição /dev/shm?!
A dúvida inicial era, por onde começar?
Bom … Existe um utilitário chamado sysresv sobre o diretório $ORACLE_HOME/bin para obter status da instância. Algumas vezes quando uma instância Oracle é abortada ou simplesmente um crash acontece, existe alguns “semaphores” ou “shared memory” que continuam ativados mesmo sem a instância no ar. Quando esses lixos (vamos dizer assim) ficam na memória a instância não consegui iniciar.
Para resolver esse problema a partir do 8i, a Oracle começou a fornecer o sysresv como um utilitário que limpa shared memory e sempahores além de visualizar processos IPC alocados, que é o que queremos. Mais detalhes veja a nota: Semaphores and Shared Memory – An Overview [ID 153961.1]
Em nosso ambiente:
[oracle@oracle11g ~]$ sysresv IPC Resources for ORACLE_SID "dbtst" : Shared Memory: ID KEY 3506180 0x3c8e282c Semaphores: ID KEY 688129 0x00fadcd4 Oracle Instance alive for sid "dbtst"
Ok, já temos a informação do Oracle que contém somente um segmento de memory shared definida pelo ID: 3506180
E no Linux? Como ele pode me falar?
No Linux assim como no Unix, é possível de obter detalhes das shared memories através do comando ipcs:
[oracle@oracle11g ~]$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 3080192 root 644 80 2 0x00000000 3112961 root 644 16384 2 0x00000000 3145730 root 644 280 2 0x3c8e282c 3506180 oracle 660 4096 0
Opa! Uma informação importante, o segmento 0x3c8e282c está sendo utilizado … porém existe somente um segmento de 4k (4096 bytes), valor muito pequeno comparado com outras versões.
Na versão 9i por exemplo esse valor é bem maior bem maior veja:
[oracle@oracle9i ~]$ ipcs -m ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x90129508 65537 oracle 640 337641472 9
Com isso, percebemos que o segmento de memória do 11g, tornou-se muito menor em relação as outras versões. Mais isso nos leva a uma pergunta: Porque ele mudou isso?
A unica conclusão que cheguei foi que ele precisava desalocar e alocar rapidamente (função do AMM) e com segmentos menores isso se torna mais rápido. Precisava confirmar isso, e iniciei uma busca de como obter mais detalhes como tamanho e endereço dos segmentos de memória.
Em busca disso encontrei a resposta no “mapeamento dos segmentos de memória” que é visualizada através do comando pmap.
oracle@oracle11g ~]$ pmap `pgrep -f lgwr` 5601: ora_lgwr_dbtst 0000000000400000 180232K r-x-- /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle 000000000b602000 1820K rwx-- /u01/app/oracle/product/11.2.0/dbhome_1/bin/oracle 000000000b7c9000 300K rwx-- [ anon ] 000000000d775000 276K rwx-- [ anon ] 0000000060000000 4K r-xs- /dev/shm/ora_dbtst_3506180_0 0000000060001000 16380K rwxs- /dev/shm/ora_dbtst_3506180_0 0000000061000000 16384K rwxs- /dev/shm/ora_dbtst_3506180_1 0000000062000000 16384K rwxs- /dev/shm/ora_dbtst_3506180_2 ... 00000000da000000 16384K rwxs- /dev/shm/ora_dbtst_3506180_122 00000000db000000 16384K rwxs- /dev/shm/ora_dbtst_3506180_123 00000000dc000000 16384K rwxs- /dev/shm/ora_dbtst_3506180_124 00000000dd000000 16384K rwxs- /dev/shm/ora_dbtst_3506180_125 00007f962c052000 1088K rwx-- /dev/zero 00007f962c162000 1088K rwx-- /dev/zero 00007f962c272000 1920K rwx-- /dev/zero 00007f962c452000 1088K rwx-- /dev/zero 00007f962c562000 1088K rwx-- /dev/zero ... 00007f962cfe0000 128K rwx-- /dev/zero 00007f962d000000 8K rwx-- /dev/zero 00007f962d142000 40K r-x-- /lib64/libnss_files-2.5.so 00007f962d14c000 2044K ----- /lib64/libnss_files-2.5.so 00007f962d34b000 4K r-x-- /lib64/libnss_files-2.5.so 00007f962d34c000 4K rwx-- /lib64/libnss_files-2.5.so 00007f962e062000 2048K ----- /lib64/libdl-2.5.so (deleted) 00007f962e262000 4K r-x-- /lib64/libdl-2.5.so (deleted) 00007f962e263000 4K rwx-- /lib64/libdl-2.5.so (deleted) ... 00007f962feec000 4K rwx-- /lib64/ld-2.5.so (deleted) 00007fff02cdf000 84K rwx-- [ stack ] 00007fff02d8d000 4K r-x-- [ anon ] ffffffffff600000 4K r-x-- [ anon ]
A saída do comando pmap para o processo LGWR mostra que o Oracle usa o /dev/shm para o compartilhamento de memória. De fato, os arquivos realmente existem na partição /dev/shm
oracle@oracle11g ~]$ ls -ltr /dev/shm/ total 1210004 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_125 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_107 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_108 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_109 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_110 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_105 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_104 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_106 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_9 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_8 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_7 ... -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_13 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_12 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_11 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_10 -rw-r----- 1 oracle oinstall 0 Oct 16 23:38 ora_dbtst_3506180_1 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:38 ora_dbtst_3506180_116 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:43 ora_dbtst_3506180_92 -rw-r----- 1 oracle oinstall 16777216 Oct 16 23:43 ora_dbtst_3506180_87 .. -rw-r----- 1 oracle oinstall 16777216 Oct 17 00:14 ora_dbtst_3506180_120 -rw-r----- 1 oracle oinstall 16777216 Oct 17 00:14 ora_dbtst_3506180_0 -rw-r----- 1 oracle oinstall 16777216 Oct 17 00:14 ora_dbtst_3506180_124
Existem aí vários arquivos de 16M de tamanho, o que responde nossa primeira dúvida. O Oracle utiliza desses pequenos arquivos para armazenar os dados de segmentos compartilhados, isso é feito devida a implementação POSIX onde tudo, inclusive um “segmento de memória compartilhada” é um arquivo.
A grande sacada do AMM é permitir deslocar memória compartilhada da SGA para a memória privada da PGA e com esses pequenos segmentos de 16M torna a operação rápida e tudo isso acontece na partição /dev/shm.
Na medida que aumento ou diminuo o tamanho da PGA através do parâmetro PGA_AGGREGATE_TARGET, os arquivos dentro da partição /dev/shm vão se movimentando de acordo com o valor passado, mostrando assim o deslocamento das memórias compartilhadas e privadas.
Um outro exemplo interessante acontece quando eu baixo a instância:
SQL> shut immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options [oracle@oracle11g ~]$ ll /dev/shm/ total 0
Como era de imaginar, nenhum arquivo existe mais na /dev/shm
Ficou mais claro agora, porque do erro ORA-00845?
October 10, 2012
Hoje procurando pelo download do Oracle Goldengate 11g, eis que sem querer descubro que um novo release foi liberado para Linux x86-64:
