Série de artigos sobre Instalação do Oracle RAC:
Instalação do Oracle RAC 10g Release 2 – Parte 1: Pré-requisitos
Instalação do Oracle RAC 10g Release 2 – Parte 2: Criação da VM
Instalação do Oracle RAC 10g Release 2 – Parte 3: Instalação do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 4: Configuração do Linux
Instalação do Oracle RAC 10g Release 2 – Parte 5: Clonagem da VM
Instalação do Oracle RAC 10g Release 2 – Parte 6: Pré-instalação do RAC
Instalação do Oracle RAC 10g Release 2 – Parte 7: Instalação do Oracle Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 8: Instalação do Patchset 10.2.0.4 no Clusterware
Instalação do Oracle RAC 10g Release 2 – Parte 9: Instalação do Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 10: Instalação do Patchset 10.2.0.4 no Oracle Database
Instalação do Oracle RAC 10g Release 2 – Parte 11: Criação do Listener no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 12: Criação do ASM no Cluster
Instalação do Oracle RAC 10g Release 2 – Parte 13: Criação do Banco de Dados no Cluster
===================================
Olá pessoal!
Vimos no último artigo a criação do Banco de Dados RAC.
Veremos hoje como criar o serviço responsável pelo load balance e principalmente, o failover. Vocês verão que é uma operação bem fácil de ser feita.
Agora, executaremos o assistente para criação do serviço, o dbca. Há algumas formas de executar esse assistente:
- Localmente no servidor, através da VMWare Server Console;
- Remotamente, através de um software que simule um X-Server (existem diversas opções gratuitas na Internet);
- Remotamente, através de uma estação Linux/Unix/Mac que tenha a parte gráfica (X) habilitado.
Eu usarei a terceira opção, portanto, a partir da minha estação:
vinicius@Viniciuss-MacBook:~$ ssh -X oracle@172.23.10.11 oracle@172.23.10.11's password: /usr/bin/xauth: creating new authority file /home/oracle/.Xauthority
Testando para ver se a parte gráfica está funcionando:
[oracle@mvrac1 ~]$ xclock
O teste funcionou! Vejam:
Pronto!
Vamos executar o dbca:
[oracle@mvrac1 ~]$ dbca
O dbca detectará que a pilha de cluster está em execução, e precisamos selecionar qual será o tipo de ambiente que será configurado:
- Oracle Real Application Clusters database;
- Oracle single instance database.
Manteremos a opção Oracle Real Application Clusters database selecionada e clicaremos em Next.
Clicar no item “Services Management” e depois clicar em Next.
O DBCA exibirá a lista de bancos de dados existentes e ativos no cluster. Como só temos o banco de dados mvdb, ele será selecionado automaticamente. Clicar em Next.
A janela acima será exibida. Essa janela também aparece na criação do banco de dados. Nela, criaremos no botão Add para criar um novo serviço.
Como exemplo, estou criando um serviço chamado producao. Clicar em OK.
No item “Details for producao”, temos 3 opções disponíveis para as instâncias de banco de dados:
- Not used: o serviço nunca utilizará a instância de banco de dados, ou seja, nunca haverá conexões feitas àquela instância utilizando esse serviço de banco de dados;
- Preferred: o serviço SEMPRE utilizará a instância de banco de dados, ou seja, no caso de um cluster de 2 nós, se as 2 instâncias estiverem como “Preferred”, haverá o Load Balance entre as 2 instâncias;
- Available: o serviço SOMENTE utilizará a instância de banco dados em caso de falha na instância que estiver definida como PREFERRED. Ou seja, se a instância mvdb1 estiver como Preferred, e a instância mvdb2 estiver como Available, as conexões só serão feitas na instância mvdb2 se a instância mvdb1 estiver indisponível.
Como queremos que aconteça o Load Balance entre as 2 instâncias, as 2 instâncias deverão ser preenchidas como Preferred.
Agora configuraremos a parte do serviço responsável pelo failover. Chamamos isso de TAF (Transparent Application Failover).
No item “TAF Policy” temos 3 opções:
- None: não haverá failover para o serviço.;
- Basic: ocorrerá o failover básico para o serviço, ou seja, se o usuário estiver conectado na instância mvdb1 executando uma query e a instância ficar indisponível, o usuário será levado para a instância mvdb2;
- Pre-connect: quando o usuário se conectar pelo serviço na instância mvdb1, automaticamente será criada uma conexão (pré-conexão) na instância mvdb2, isso torna o failover mais rápido, já que haverá uma conexão existente na segunda instância, no entanto, em contra-partida, essa sessão na segunda instância consumirá uma fatia da memória no servidor.
Utilizaremos a política “Basic”.
Clicar em Finish.
A janela acima solicitará confirmação para a criação do serviço no banco de dados mvdb. Clicar em OK.
Uma janela com o progresso da criação do serviço será exibida. Aguardar.
A janela acima será exibida questionando se o DBA deseja realizar mais alguma operação. Clicar em No.
Vamos verificar se os recursos do cluster foram alterados?
Para verificar o status dos recursos do cluster:
[oracle@mvrac1 ~]$ crsstat HA Resource Target State ----------- ------ ----- ora.mvdb.db ONLINE ONLINE on mvrac1 ora.mvdb.mvdb1.inst ONLINE ONLINE on mvrac1 ora.mvdb.mvdb2.inst ONLINE ONLINE on mvrac2 ora.mvdb.producao.cs ONLINE ONLINE on mvrac1 ora.mvdb.producao.mvdb1.srv ONLINE ONLINE on mvrac1 ora.mvdb.producao.mvdb2.srv ONLINE ONLINE on mvrac2 ora.mvrac1.ASM1.asm ONLINE ONLINE on mvrac1 ora.mvrac1.LISTENER_MVRAC1.lsnr ONLINE ONLINE on mvrac1 ora.mvrac1.gsd ONLINE ONLINE on mvrac1 ora.mvrac1.ons ONLINE ONLINE on mvrac1 ora.mvrac1.vip ONLINE ONLINE on mvrac1 ora.mvrac2.ASM2.asm ONLINE ONLINE on mvrac2 ora.mvrac2.LISTENER_MVRAC2.lsnr ONLINE ONLINE on mvrac2 ora.mvrac2.gsd ONLINE ONLINE on mvrac2 ora.mvrac2.ons ONLINE ONLINE on mvrac2 ora.mvrac2.vip ONLINE ONLINE on mvrac2
Pronto!
Podemos ver que foi registrado no cluster uma serviço de banco de dados para cada nó, além de um recurso com o final .cs, representando o serviço clusterizado (cluster service).
Agora vamos realizar os testes com o serviço.
Porém, para que o failover aconteça com sucesso, a Oracle recomenda que os hostnames públicos, além dos hostnames referentes aos endereços VIP estejam registrados no DNS e/ou no arquivo hosts dos usuários. Como estou usando uma estação de trabalho baseada em Unix, o arquivo é o /etc/hosts, no caso do Windows, é C:\WINDOWS\SYSTEM32\DRIVERS\ETC\HOSTS. As seguintes linhas precisam ser adicionadas:
172.23.10.21 mvrac1-vip mvrac1-vip.viniciusdba.com.br 172.23.10.22 mvrac2-vip mvrac2-vip.viniciusdba.com.br 172.23.10.11 mvrac1 mvrac1.viniciusdba.com.br 172.23.10.12 mvrac2 mvrac2.viniciusdba.com.br
Outro ponto importantíssimo para que o failover aconteça com sucesso, a entrada do TNSNAMES.ORA deve estar correta. Dentro do próprio servidor, há o TNSNAMES.ORA correto:
PRODUCAO =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = mvrac1-vip.viniciusdba.com.br)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = mvrac2-vip.viniciusdba.com.br)(PORT = 1521))
(LOAD_BALANCE = yes)
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = producao)
(FAILOVER_MODE =
(TYPE = SELECT)
(METHOD = BASIC)
(RETRIES = 180)
(DELAY = 5)
)
)
)
Observem que o TNSNAMES aponta para os 2 endereços VIP, ou seja, mesmo que um servidor fique indisponível, o IP VIP que estava nele, irá para o outro servidor.
Além disso, o ambiente pode retornar o erro ORA-12545 ao tentar se conectar pelo serviço criado recentemente.
A correção deste erro é definir o parâmetro LOCAL_LISTENER para que cada nó tenha somente o VIP local associado ao parâmetro. Vejamos:
SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=mvrac1-vip)(PORT=1521)))' scope=both sid='mvdb1'; System altered. SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=mvrac2-vip)(PORT=1521)))' scope=both sid='mvdb2'; System altered.
Agora sim podemos testar:
sqlplus system/oracle@producao
SQL*Plus: Release 10.2.0.4.0 - Production on Thu Feb 25 00:06:27 2010
Copyright (c) 1982, 2007, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Release 10.2.0.4.0 - Production
With the Real Application Clusters option
SQL> @taf
INST# INST_NAME HOST USERNAME TYPE METHOD FAILED OVER
------ ---------- ---------------------------- ---------- ---------- ---------- -----------
2 mvdb2 mvrac2.viniciusdba.com.br SYSTEM SELECT BASIC NO
O script taf.sql contém as seguintes linhas:
set linesize 100
col INST# format 99999
col INST_NAME format a10
col HOST format a28
col USERNAME format a10
col TYPE format a10
col METHOD format a10
col "FAILED OVER" format a11
select
INSTANCE_NUMBER INST#,INSTANCE_NAME INST_NAME,HOST_NAME HOST,
USERNAME, FAILOVER_TYPE TYPE, FAILOVER_METHOD METHOD,
FAILED_OVER "FAILED OVER"
from
V$SESSION a, V$INSTANCE b
where
USERNAME = (select SYS_CONTEXT ('USERENV', 'SESSION_USER') from DUAL)
and
SID = (select SYS_CONTEXT ('USERENV', 'SID') from DUAL)
;
De acordo com a saída do script, estamos na instância mvdb2, vamos fazer uma nova conexão para verificar o funcionamento do Load Balance:
SQL> connect system/oracle@producao
Connected.
SQL> @taf
INST# INST_NAME HOST USERNAME TYPE METHOD FAILED OVER
------ ---------- ---------------------------- ---------- ---------- ---------- -----------
1 mvdb1 mvrac1.viniciusdba.com.br SYSTEM SELECT BASIC NO
Funcionou!
Agora, vamos fazer um teste de failover.
Vamos executar como teste, um script que traga muitas linhas como resultado, o script é o query.sql:
select a.*, b.*, c.* from dba_objects a, dba_objects b, dba_objects c;
Como podem ver, faremos um produto cartesiano. Pois bem, a ideia é a seguinte:
- Já estamos conectados na instância mvdb1;
- Executaremos nessa instância, o script query.sql;
- Enquanto a query é executada, baixaremos a instância mvdb1 com a opção abort;
- A sessão do usuário SYSTEM deverá ser levada para o servidor mvdb2 e a query continuar o fetch do lugar onde parou, isso, sem o usuário perceber;
- Executaremos o script taf.sql para verificar se ocorreu o failover.
Vamos lá?
Vamos deixar o comando do shutdown abort pronto para ser processado (vai faltar só pressionar [ENTER]). Com o usuário oracle, em qualquer servidor (mvrac1 ou mvrac2):
srvctl stop instance -d mvdb -i mvdb1 -o abort
Assim que a query voltar a processar, cancele o processamento. Se estiver usando o SQL*Plus no Windows, clique em Arquivo / Cancelar, e em seguida, execute o script taf.sql. Caso esteja usando o SQL*Plus em ambiente Unix/Linux, pressione [CTRL] + [C] e, em seguida, execute o script taf.sql. Vejam o resultado:
SQL> @taf
INST# INST_NAME HOST USERNAME TYPE METHOD FAILED OVER
------ ---------- ---------------------------- ---------- ---------- ---------- -----------
2 mvdb2 mvrac2.viniciusdba.com.br SYSTEM SELECT BASIC YES
Observem que agora minha sessão está na instância mvdb2 e a coluna FAILED OVER foi alterada para YES.
Vamos ver um vídeo disso funcionando?
Para ver o vídeo, você precisa ter o Quicktime instalado no seu computador. Baixe ele aqui (é gratuito).
No próximo artigo veremos como configurar o Enterprise Manager.
Um abraço!
Vinicius
12 Comments
Deixe um comentário
Bom dia mano… está cada vez melhor este post…. to acompanhando todos eles…. valew pelo paterial…. está de 1ª qualidade viu…
Abraços….
Ribas
Olá Ribas,
Obrigado! São palavras como as suas que me incetivam a continuar firme com o blog!
Abraços
Vinicius
Good dispatch and this mail helped me alot in my college assignement. Thank you for your information.
Boa tarde Vinícius, poderia me ajudar ?? Quando digitei o SQL> @taf, retornou a mensagem abaixo. O que pode estar ocorrendo?? Segui os passos certinho.
SP2-0310: unable to open file “taf.sql”
Desde já agradeço
Sérgio
Olá Sérgio,
Você se conectou ao banco de dados pelo SQL*Plus?
Se sim, após a conexão, clique em arquivo/abrir, escolha o arquivo taf.sql e em seguida execute o script digitando: @taf
Abraços
Vinicius
Olá Vinucius,
Aprendi muito sobre RAC com o teu blog. mal posso esperar pelos topicos de adicionar e remover nós.
No artigo foi configurado o LOCAL_LISTENER, mas não o REMOTE_LISTENER, como o rac funcionou perfeitamente, ficou a dúvida de pra que serve o remote, li muita coisa na net, mas nada conclusivo. Se tu puderes explicar o uso do REMOTE_LISTENER, desde já agradeço.
Olá Sandro,
Tudo bem?
Fico contente que eu tenha transmitido alguma mensagem útil pelo blog! 🙂
O parâmetro REMOTE_LISTENER é utilizado para especificar todos os listeners que fazem parte do cluster onde o registro de failover e load balance (além das instâncias) poderão se registrar. Geralmente esse parâmetro é apontado para um valor que está especificado dentro do TNSNAMES para facilitar o gerenciamento.
Abraços
Vinicius
Olá Vinicius,
Estive pesquisando mais sobre o REMOTE_LISTENER, e ele é responsável pelo balance side-server, e me parece que ele usa a utilização de cpu como críterio de escolha entre qual nó será criado a sessão, mesmo eu forçando o ip no tnsnames.
Pela tua experiência, vale a pela utilizá-lo ou apenas o balance side-client através do sorteio dos nós?
Vinicius, parabéns pelo blog. aprendi muito.
a minha dúvida é em relação a pós-failover, o que acontece com as conexões que foram migradas para o outro nó após a recuperação do que falhou? elas ficam lá? ou retornam?
é preciso algum procedimento para balancear novamente o rac após failover?
Nilton,
As conexões ficarão no servidor para onde foram movidas.
Não tem como rebalancear um RAC (mesmo sem failover), isso é, transferir as sessões de um servidor para o outro.
Neste caso, o conselho é solicitar ao usuário sair e logar novamente.
Caso seja um ambiente de 3 camadas, basta um restart no pool de conexões do application server…
Abraços!
Vinicius
Meu amigo, eu refiz o teste agora com SYSTEM (antes estava fazendo com o SYS) e agora deu certo!
Demorei tanto em responder que você deu seus pulos e conseguiu fazer tudo!
Parabéns!!!
Desculpe-me pela demora!
Abraço!