Blog Flávio Soares
Oracle, Database, Data Guard, RAC, Performance, Exadata, ASM, Goldengate, Troubleshooting
May 24, 2013
Quando iniciado o utilitário ggsci do Oracle GoldenGate a seguinte mensagem de erro é disparada:
$ ./ggsci ./ggsci: error while loading shared libraries: libnnz10.so: cannot open shared object file: No such file or directory
O erro acontece devida a falta de arquivos de shared libraries, ou mais conhecidos como shared objects que nada mais são do que bibliotecas compostas por muitas dependências carregadas por programas quando iniciados. No nosso caso, o utilitário do GoldenGate ggsci não consegue ser iniciado porque não encontrou a shared object chamada libnnz10.so.
Na maioria dos sistemas operacionais atuais, você pode apontar para diferentes bibliotecas de shared objects para uma particular execução do programa, no Linux por exemplo temos a variável de ambiente chamada LD_LIBRARY_PATH que define o destino onde os shared objects devem ser procuradas. Essa funcionalidade é disponÃvel para outras arquiteturas também, em alguns casos mudasse apenas o nome da variável de ambiente:
IBM AIX -> LIBPATH
HP-UX -> SHLIB_PATH
Sun Solaris -> LD_LIBRARY_PATH
HP Tru64 -> LD_LIBRARY_PATH
Para conferir as dependências dinâmicas de um determinado programa, existe o comando ldd criado por Roland McGrath que informa as shared libraries requeridas por cada programa. Com esse comando, será possÃvel entender o porque da mensagem de erro mostrada acima:
$ ldd ggsci libdl.so.2 => /lib64/libdl.so.2 (0x00000037c7800000) libgglog.so => /u01/app/oracle/gg11/libgglog.so (0x00002ac9b503a000) libggrepo.so => /u01/app/oracle/gg11/libggrepo.so (0x00002ac9b5278000) libdb-5.2.so => /u01/app/oracle/gg11/libdb-5.2.so (0x00002ac9b53d0000) libicui18n.so.38 => /u01/app/oracle/gg11/libicui18n.so.38 (0x00002ac9b566b000) libicuuc.so.38 => /u01/app/oracle/gg11/libicuuc.so.38 (0x00002ac9b59cb000) libicudata.so.38 => /u01/app/oracle/gg11/libicudata.so.38 (0x00002ac9b5d05000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037c7c00000) libxerces-c.so.28 => /u01/app/oracle/gg11/libxerces-c.so.28 (0x00002ac9b6ce1000) libantlr3c.so => /u01/app/oracle/gg11/libantlr3c.so (0x00002ac9b71f9000) libnnz10.so => not found libclntsh.so.10.1 => not found libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000037dae00000) libm.so.6 => /lib64/libm.so.6 (0x00000037c7400000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000037d6e00000) libc.so.6 => /lib64/libc.so.6 (0x00000037c7000000) /lib64/ld-linux-x86-64.so.2 (0x00000037c6c00000)
Veja que as shared objects libnnz10.so e libclntsh.so.10.1 não foram encontradas pelo comando ldd, e é justamente elas o problema de iniciar o utilitário ggsci.
Como mencionei a LD_LIBRARY_PATH no Linux, especifica um destino alternativo para as shared libraries. Em um ambiente Oracle, todas as libs necessárias para executar a maioria dos programas Oracle como sqlplus, asmcmd, dbca e etc … encontra-se na pasta chamada lib dentro do próprio Oracle Home do banco de dados. Com isso, precisamos apenas apontar a variável LD_LIBRARY_PATH para onde essas shared libraries do Oracle encontra-se:
$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib:$LD_LIBRARY_PATH $ echo LD_LIBRARY_PATH /u01/app/oracle/product/10.2.0/db_1/lib:
Com a LD_LIBRARY_PATH definida, execute o ldd para checar novamente o utilitário do ggsci e ver que agora todas as dependências foram realizadas
[oracle@oracle10g gg11]$ ldd ggsci libdl.so.2 => /lib64/libdl.so.2 (0x00000037c7800000) libgglog.so => /u01/app/oracle/gg11/libgglog.so (0x00002acde8b72000) libggrepo.so => /u01/app/oracle/gg11/libggrepo.so (0x00002acde8db0000) libdb-5.2.so => /u01/app/oracle/gg11/libdb-5.2.so (0x00002acde8f08000) libicui18n.so.38 => /u01/app/oracle/gg11/libicui18n.so.38 (0x00002acde91a3000) libicuuc.so.38 => /u01/app/oracle/gg11/libicuuc.so.38 (0x00002acde9503000) libicudata.so.38 => /u01/app/oracle/gg11/libicudata.so.38 (0x00002acde983d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00000037c7c00000) libxerces-c.so.28 => /u01/app/oracle/gg11/libxerces-c.so.28 (0x00002acdea819000) libantlr3c.so => /u01/app/oracle/gg11/libantlr3c.so (0x00002acdead31000) libnnz10.so => /u01/app/oracle/product/10.2.0/db_1/lib/libnnz10.so (0x00002acdeae47000) libclntsh.so.10.1 => /u01/app/oracle/product/10.2.0/db_1/lib/libclntsh.so.10.1 (0x00002acdeb2e8000 libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00000037dae00000) libm.so.6 => /lib64/libm.so.6 (0x00000037c7400000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00000037d6e00000) libc.so.6 => /lib64/libc.so.6 (0x00000037c7000000) /lib64/ld-linux-x86-64.so.2 (0x00000037c6c00000) libnsl.so.1 => /lib64/libnsl.so.1 (0x00000037cac00000)
Agora sim, com todas as shared objects encontradas e todas as suas dependencias resolvidas, podemos executar sem qualquer problema o comando ggsci para inicar as operações do Oracle Goldengate:
[oracle@oracle10g gg11]$ ./ggsci Oracle GoldenGate Command Interpreter for Oracle Version 11.2.1.0.6 16211226 OGGCORE_11.2.1.0.6_PLATFORMS_130418.1829_FBO Linux, x64, 64bit (optimized), Oracle 10g on Apr 18 2013 22:43:23 Copyright (C) 1995, 2013, Oracle and/or its affiliates. All rights reserved. GGSCI (oracle10g.flaviosoares.local) 1> info all Program Status Group Lag at Chkpt Time Since Chkpt MANAGER RUNNING GGSCI (oracle10g.flaviosoares.local) 2>
May 22, 2013
Essa foi uma curiosidade que descobri esses dias.
Será que consigo escrever um SQL sem qualquer espaço? Será que o compilador Oracle e tão inteligente ao ponto de entender minha consulta SQL sem qualquer espaço?
Valendo …
Quais das opções abaixo o meu SQL irá rodar sem apresentar erro?
1.select*fromdual;
2.select*from”dual”;
3.select*from”DUAL”;
Por incrÃvel que pareça se você tentar a opção 3, o seu SQL será executado normalmente:
SQL> select*fromdual;
select*fromdual
*
ERROR at line 1:
ORA-00923: FROM keyword not found where expected
SQL> select*from"dual";
select*from"dual"
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> select*from"DUAL";
D
-
X
1 row selected.
IncrÃvel né?! ..
Pelo que dá a entender, que o compilador Oracle não precisa dos espaços para entender e definir a correta sintaxe do meu comando, considerando é claro o nome real da tabela: “DUAL” com todas as letras maiúsculo.
Funciona também se você tentar com o nome da coluna, por exemplo:
SQL> select"DUMMY"from"DUAL"; D - X 1 row selected.
Interessante 
Nunca, em hipótese alguma … alguém deverá escrever uma query dessa forma em um ambiente real, isso é apenas um caso curioso sobre como o Oracle lida com os seus comandos.
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 19, 2013
Estava por esses dias aventurando novamente no photoshop, agora com menino propaganda da Oracle:
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á …
March 27, 2013
Lançado na versão Oracle 10g Release 1, o ASM passou por muitas mudanças até chegar onde chegou.
Os números abaixo além de impressionar, mostra um pouco até onde o ASM pode ir:
- Você pode ter até 63 disk group.
- Cada disk group pode ter até 10,000 ASM disks
- Cada disk group pode suportar um armazenamento de até 2TB.
- Cada diskgroup pode gerenciar até 1.000.000  (um milhão) de arquivos.
- Com a externa redundância: O tamanho máximo suportado por um datafile no Oracle ASM é de 140PB.
- Com a normal redundância: O tamanho máximo suportado por um datafile no Oracle ASM é de 42PB.
- Com a high redundância: O tamanho máximo suportado por um datafile no Oracle ASM é de 15PB.
Leram bem né?! Um datafile de 140 PB ….
March 15, 2013
…
Na parte 4 da série vamos criar o banco primário, ou seja o banco produção do nosso ambiente de teste. O banco irá se chamar orcl, conforme a planilha abaixo apresentada na parte 3.
Criando o banco primário (produção)
Com a máquina virtual DB Primary iniciada e logado com o usuário oracle, a partir do prompt digite o comando DBCA.
Apenas clique em next.
Selecione e a opção de template de banco que desejar, no meu caso vou utilizar o “General Purpose”, com esse template além da criação ser mais rápida ele já vem com várias features instaladas fazendo ideal para nosso teste.
Hora de definir o nome para o nosso banco de dados: orcl
Desabilite a opção de criar o Enterprise Manager, estaremos fazendo isso depois.
Defina aqui uma senha para os usuário sys e system. No meu caso foi definido a senha oracle.
Obviamente essa senha não é recomendada, como mostra a mensagem abaixo (nunca usar esse tipo de senha em produção!!)
Desabilite a opção de archive para que a criação seja feita mais rápida. Vamos fazer isso posteriormente.
Para fins de teste, selecione a opção de colocar os schemas de teste no banco. Isso irá criar os owner SCOTT, HR etc …
Informe aqui a quantidade de memória que será utilizada pelo Oracle. No meu caso, como minha VM é 3G vou definir 1,5G para o oracle.
Aqui é mostrado um sumário de tudo que foi escolhido no banco de dados. Confirme tudo para iniciar a criação do banco.
Aqui a conclusão da criação do banco orcl:
Na próxima parte dessa série, iremos realizar os pré-requisitos do banco orcl para a criação do DataGuard.
Qualquer dúvida, post um comentário.
Abraço!
March 13, 2013
A Oracle anunciou recentemente um novo release da prova de certificação Oracle Exadata Database Machine Administration Oracle.
Assim como a antiga, a nova versão é destinada para aqueles que possui conhecimento no Oracle Database 11g e Exadata Database Machine, a nova prova exige conhecimentos como features, configurações, manutenção, monitoramento e otimização do Oracle Machine Exadata.
Para conseguir a certificação é necessário passar na prova Oracle Exadata Database Machine X3 Administration (1Z0-027).
Para mais detalhes: Oracle Exadata Database Machine X3 Administration – 1Z0-027
February 14, 2013
No dia seguinte em que publiquei a parte 1 da série sobre segurança de banco de dados, meu amigo Gerson Vasconcelos Jr. enviou através do e-mail um trabalho que havia feito na faculdade que poderia ajudar a fazer os próximos post de segurança, e realmente .. o documento é fantástico! Tem várias notas muito bem explicadas de como configurar o Oracle para trabalhar de forma segura!
O Gerson para quem não sabe, além de ser um grande amigo e um grande DBA que essa carreira deu o privilégio de conhecer, o cara também é blogueiro, seu blog é o http://www.diaadiaoracle.com.br/ e ele escreve também no Grupo de Profissionais Oracle no blog Dia a Dia Oracle.
Como ele mesmo disse no e-mail: “Conhecimento é a única coisa que quando você divide, se multiplica!”, aqui está o trabalho e a apresentação do Gerson (claro pedi a permissão dele para divulgar):  http://flaviosoares.com/docs/security/trabalho_gerson
Entre as notas mencionadas por Gerson no trabalho, a que achei mais interessante foi sobre o parâmetro ULT_FILE_DIR, para quem não sabe esse parâmetro pode destruir seu ambiente! Caso o usuário oracle tenha privilégio, você pode criar um arquivo através do utilitário utl_file bem em cima de um arquivo crÃtico do SO, ae já sabe … adeus servidor! Mas, como contornar isso? Leia o trabalho, que lá o Gerson explica melhor!
Gersão, está devendo uma passada aqui em São Paulo para a gente tomar uma ein!  
January 12, 2013
Parte 01 – 07_DICTIONARY_ACCESSIBILITY
…
Encontrando os password default
Não é novidade nenhuma que existem várias contas de usuários padrão no banco de dados Oracle, alguns deles até são criados com privilégios administrativos.
Usuários padrão são criados no momento da criação do banco e claro,  são registrados sem uma senha e já vem bloqueado por default, exceto para SYS e SYSTEM que são contas administrativas que quando criadas através do CREATE DATABASE, se não definidas as senhas, elas devem ficar:
SYS : CHANGE_ON_INSTALL)
SYSTEM : MANAGER
Se você acha que os usuários default do Oracle é uma lista pequena, está enganado, aqui é alguns dos usuários padrão que são instalado sempre que um banco ou uma feature do banco é instalada. Por exemplo, o usuário XDB somente é instalado quando o Oracle XMLDB é instalado:
SYS SYSTEM SYSMAN OUTLN TSMSYS WKSYS SCOTT ADAMS JONES WKPROXY OLAPSYS OWBSYS CLARK BLAKE HR OE SH DEMO ANONYMOUS CSMIG CTXSYS DBSNMP DIP DMSYS DSSYS EXFSYS LBACSYS MDSYS ORACLE_OCM ORDPLUGINS ORDSYS PERFSTAT XDB MGMT_VIEW SI_INFORMTN_SCHEMA
Porém para alguns deles (quase todos), existe uma senha padrão definida, como o famoso usuário SCOTT que possuà a senha padrão definida como TIGER.
Muitos ambientes Oracle tem o usuário SCOTT criado (e provavelmente até com a senha padrão definida), o que deixa o banco de dados muito vulnerável, imagina que com uma senha padrão definida, qualquer um a qualquer momento pode acessar o seu banco, somente acessando essa conta.
Ok, mais como me livro disto? Qual é a maneira de descobrir se os usuários na lista acima está com a senha padrão habilitada?
Somente a view DBA_USERS_WITH_DEFPWD pode te responder isso …
Logado no SQL*Plus com uma conta administrativa, execute a seguinte consulta de encontra a view DBA_USERS_WITH_DEFPWD
SQL> SELECT * FROM DBA_USERS_WITH_DEFPWD; USERNAME ------------------------------ DIP OUTLN ORACLE_OCM APPQOSSYS SQL> select username, account_status from dba_users where username in (select username from dba_users_with_defpwd); USERNAME ACCOUNT_STATUS ------------------------------ -------------------------------- APPQOSSYS EXPIRED & LOCKED ORACLE_OCM EXPIRED & LOCKED DIP EXPIRED & LOCKED OUTLN OPEN
A primeira consulta, mostra que temos a lista completa dos usuários em que a senha padrão está definida. Na segunda consulta, é informado que apenas o usuário OUTLN que tem uma senha padrão está com o status da conta habilitado.
Mesma com uma conta bloqueada, deixar o usuário com uma senha padrão pode ser muito perigoso, imagina se alguém habilita uma dessas contas sem querer e não troca a senha?
Para mudar a senha não é segredo:
SQL> PASSWORD OUTLN Changing password for OUTLN New password: ********* Retype new password: ************ Password changed
São maneiras simples como essa que podem te livrar de uma dor de cabeça incrÃvel. O DBA devem estar atento a tudo, inclusive a pequenos detalhes como este. Nem quero pensar que uma conta dessas caia em mãos erradas, imagina que uma conta dessas com privilégio administrativo, o de create/drop tablespaces por exemplo, esteja com a conta habilitada e password default e algum abelhudo consegue conectar com essa conta, já penso o estrago? …
É! … você pode dar adeus ao seu banco e rezar para ter backup …
