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.

dbca_create_service_blank

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