segunda-feira, 15 de agosto de 2011

Oracle SCAN (11gR2) – Um estranho no ninho?


Durante a configuração do Oracle RAC, na versão 11gR2, a Oracle criou um novo dispositivo na infra-estrutura do RAC, chamado SCAN, nesse artigo descreveremos as particularidades desse dispositivo.

O que é o Oracle SCAN?

É  o nome do dispositivo único para acessos dos usuários Oracle ao banco de dados, esse dispositivo comporta-se como uma máquina virtual para conectar todas as estações de trabalho ao cluster (RAC).

O recurso SCAN é uma nova "camada" de rede (Oracle), com alta disponibilidade que permite alterar as características do seu cluster “RAC” (permitindo adicionar ou remover nós) sem a necessidade de fazer alterações de configuração em seus clientes - utilizando conceitos de GRID.

O SCAN IP e VIP têm objetivos diferentes, portanto, trabalham em conjunto.

O IP VIP oferece alta disponibilidade na camada do cluster (SERVERs).

O IP SCAN oferece alta disponibilidade na camada dos clientes (CLIENTs).

Não importa se estamos adicionando ou removendo nós em um cluster ou se os nós estão ativos ou inativos, IP SCAN está sempre disponível para os clientes (gerenciando conexões “failover”).

Como o SCAN trabalha?

Quando uma estação de trabalho envia uma solicitação, o “listener” escuta a solicitação num endereço IP SCAN (um endereço IP destacado para atender a solicitação das estações) então a solicitação conecta ao bando de dados.  Todos os serviços no cluster são registrados no “listener” SCAN, as respostas ao endereço SCAN são realizadas no nó do cluster que esteja menos sobrecarregado.  A estação estabelece conexão com o serviço através do “listener” no nó onde o serviço é oferecido. Todas essas ações ocorrem de forma transparente para o usuário, sem qualquer configuração explícita.

Diagrama de conexão



Requisitos para configurar SCAN?

O Oracle SCAN é um nome de domínio registrado com pelo menos um e até três endereços IP, quer no serviço de nomes de domínio (DNS) ou o Grid Naming Service (GNS), apenas DNS pode resolver mais de um endereço IP com mesmo “hostname”.  Isso é possível porque só tem recurso de DNS – Roudin-Robim.
Endereços SCAN VIP devem estar na mesma sub-rede como endereços IP virtuais e endereços IP públicos.

Por padrão, o nome usado como o SCAN é também o nome do cluster e deve ser globalmente único em toda a empresa.  Nome SCAN deve ser de pelo menos um caractere de comprimento e não mais de 15 caracteres de comprimento, deve ser alfanumérico - não pode começar com um numeral e podem conter hífens (-).

É possível usar arquivos HOSTS para resolver SCAN?

Tecnicamente funciona porque a Oracle exige que o “hostname” virtual possa ser resolvido e usando o arquivo de “HOSTS” isso é possível.

IMPORTANTE !!  Use o arquivo de “host” APENAS se você estiver criando um ambiente de teste ou se não vai usar o recurso SCAN.

RECOMENDAÇÃO: NUNCA use o arquivo “HOSTS” para resolver SCAN no ambiente de produção. Esse procedimento poderá causar problemas no ambiente produtivo.

A Oracle recomenda, a não configuração dos endereços SCAN VIP no arquivo de “hosts”. Mas pode-se utilizar o arquivo “hosts” para resolver o nome SCAN, para obter apenas um endereço IP SCAN.
O arquivo “HOSTS” não resolverá mais de uma entrada para o mesmo “host”, somente a primeira inscrição será resolvida.

Requisitos para configurar clientes para utilizarem SCAN?

É recomendada a configuração de um servidor de DNS .

Deve sempre usar o nome do “host” (por exemplo, node1 -vip ) não utilizar o endereço IP (por exemplo,  192.168.0.5).

Isto é necessário porque o Oracle tenta conectar utilizando o “hostname” (não o endereço de IP) configurado (LOCAL /REMOTAMENTE) no “listener” no banco de dados.

O cliente deve resolver e acessar o “hostname” e portas, usando os seguintes critérios:

  • O nome da máquina virtual do SCAN (por exemplo, servidor -scan )
  • A porta do SCAN deve estar aberta (embora possa parecer óbvio, esse é um requisito mínimo, que às vezes não é considerado).
  • Todos os “hostnames” do Virtual IP do RAC devem estar configurados (por exemplo, node1 -vip,  node2 -vip e assim por diante). Isso será necessário porque a conexão é estabelecida pelo VIP não por SCAN IP.
  • A porta do “listener” local deve estar aberta. 


Procedimento para a realização da verificação da conexão:

# Testes com os hosts definidos

nslookup host-scan
ping -c node1-vip
ping -c node2-vip
ping -c host-scan
tnsping node1-vip
tnsping node2-vip
tnsping host-scan

# Primeiro teste utilizando o endereco VIP

sqlplus scott/tiger@node1-vip:1521/orcl
sqlplus scott/tiger@node2-vip:1521/orcl

# Testando somente o endereco SCAN

sqlplus scott/tiger@host-scan:1521/orcl


Por que não configurar apenas um endereço de IP para o Oracle SCAN?

Configurando apenas um endereço IP para o Oracle SCAN, as conexões não serão distribuídas, transformando-se num gargalo. Com um alto volume de conexões e somente um endereço de IP configurado, começará a haver um “overhead” nas solicitações de conexão, diminuindo o tempo de resposta e apresentando sobrecarga nos processos de “load-balance e failover”.

Com três endereços de IP definidos para o SCAN, o usuário vai simplesmente mudar para o próximo endereço disponível e obter uma conexão.  Com apenas um endereço SCAN, o usuário receberá uma mensagem de erro, indicando que não existe “listener” disponível para conexão ( NO LISTENER).

O tempo do “failover” também será prejudicado com apenas um endereço de SCAN, haverá tentativas de conexão sem sucesso.

Como registro do “listener” pelo banco de dados (através do processo PMON) só é realizado a cada 60 segundos.  Então, se o “listener” estiver no ar (após o “failover”), mas o serviço não tiver sido registrado, os usuários receberão uma mensagem de erro (NO SERVICE).

Embora muito improvável de acontecer, porque o RAC tenta evitar isso, com apenas um endereço de IP definido para o SCAN, o resultado seria uma indisponibilidade completa do cluster.  Já com três endereços de SCANs definidos,  a vulnerabilidade será evitada.

Por que não usar VIP ou Público?

Para utilizar o conceito de GRID é preciso configurar o recurso SCAN, para permitir que o RAC se auto gerencie e torne as conexões do cluster transparentes para os usuários.

Para adicionar ou remover um nó, utilizando somente os endereços de VIP ou Público seria necessário modificar as conexões de todos os usuários ativos no banco de dados. Isso faz uma grande diferença quando se tem muitos usuários.

Utilizando o SCAN, pode-se remover ou adicionar um nó automaticamente.

Os  “listeners”  locais ainda são necessários?

Sim, é necessário configurar “listeners” independentes.  Os “listeners” SCAN não são substitutos para os “listeners” dos nós (como dito anteriormente).

Quando um novo conjunto de processos do cluster (RAC) é chamado, os “listeners” realizam a verificação, executando os três endereços IPs configurados, passando para todos os nós do cluster.  Para configurações com mais três nós, independentemente do número de nós, haverá no máximo três “listeners” SCAN.  O banco de dados registra o “listener” através do parâmetro SCAN “listener” remoto no arquivo de configuração “init.ora” ou no  “spfile”.  Se qualquer um dos processos de cluster (RAC) falhar, os processos serão automaticamente reiniciados num novo nó.

Pode-se utilizar o método antigo (VIP) para a conexão do cliente?

Os clientes podem continuar a acessar o cluster da mesma forma como com versões anteriores.  Os endereços VIPs ainda são usados ​​internamente, e ainda podem ser usados para conexões.  Mas a Oracle recomenda que os clientes acessem o cluster utilizando o SCAN.  Usuários utilizando o SCAN também podem acessar o cluster usando EZCONNECT.

É obrigatório o uso SCAN?

É recomendável usar o SCAN a menos que haja motivo comercial forte impedindo-o de ser utilizado. O SCAN é uma parte fundamental da infra-estrutura de grade 11gR2.



Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com

segunda-feira, 1 de agosto de 2011

Corrigindo segmentos de UNDO corrompidos

Já a algum tempo os segmentos de rollback foram substituídos pelos segmentos de UNDO esse novo dispositivo tornou-se automaticamente dimensionado e gerenciado. No entanto, o que acontece quando um UNDO se corrompe? 

No "ALERT.LOG" poderão ser encontradas mensagens de erros semelhantes a essa:

Errors in file /oracle/admin/test/bdump/test2_smon_21466.trc:
ORA-00600: internal error code, arguments: [6006], [1], [], [], [], [], [], []
SMON: mark undo segment 29 as needs recovery


ORACLE Instance test2 (pid = 11) - Error 600 encountered while recovering 
transaction (29, 42) on object 36.

Mas, o que você pode fazer sobre isso?

Ao tentar alterar o segmento de UNDO utilizando o comando "ALTER ROLLBACK SEGMENT" o comando irá apresentar mensagens de erros, indicando que esse dispositivo não pode ser alterado.

Abaixo, segue um procedimento para a correção deste problema:

1.  Primeiro deve-se criar uma nova tablespace de UNDO, deve-se usar:

    CONNECT / AS SYSDBA
    CREATE UNDO TABLESPACE UNDOTBS2 DATAFILE '/u02/oracle/oradata/test/undotbs2.dbf' SIZE 500M;

2.  Verificar o problema que está ocorrendo no segmento de UNDO.

    SELECT SEGMENT_NAME, STATUS
      FROM DBA_ROLLBACK_SEGS;

    NOTA: O segmento de UNDO que apresentar o valor "Needs Recovery", na coluna "STATUS",
               é o segmento de UNDO com problema.

3.  Aponte o banco de dados para a nova tablespace de UNDO (criado no item 1), usar:

    ALTER SYSTEM SET UNDO_TABLESPACE=UNDOTBS2 SCOPE=BOTH;  

    IMPORTANTE:  Se não estiver utilizando o "spfile", pode-se omitir o comando "SCOPE". Se estiver
                            utilizando o "spfile" deverá criar um novo pfile, seguindo os passos abaixo:

    CONNECT / AS SYSDBA
    CREATE PFILE='/u01/oracle/admin/test/pfile/inittest.ora' FROM SPFILE;

4.  Editar o arquivo "init.ora" (pfile) e adicionar as entradas abaixo:
 
    *._offline_rollback_segments="_SYSSMU29$"
    *._corrupted_rollback_segments="_SYSSMU29$"

    IMPORTANTE: O segmento de UNDO (_SYSSMU29$) é apresentado como um exemplo neste artigo,
                           deve-se utilizar o nome do segmento de UNDO que está apresentando problemas na
                           base de dados.

5.  Realizar um "restart" na base de dados "shutdown e startup". Preferencialmente usa a opção
     (SHUTDOWN IMMEDIATE, evite usar a opção ABORT).
   
6.  "Startar" o banco utilizando o "init.ora" usar o comando abaixo:

    STARTUP PFILE='/u01/oacle/admin/test/pfile=inittest.ora';

7.  Verificar novamente o problema que está ocorrendo no segmento de UNDO, usar:

    SELECT SEGMENT_NAME, STATUS
      FROM DBA_ROLLBACK_SEGS;

8.  Alterar a tablespace de UNDO antiga para OFFLINE, usar:

    ALTER TABLESPACE UNDOTBS1 OFFLINE;

9.  Remover a tablespace de UNDO antiga, usar:

    DROP TABLESPACE UNDOTBS1 INCLUDING CONTENTS AND DATAFILES;

10. Baixar o banco de dados,, usar:

    SHUTDOWN IMMEDIATE;

11. Editar o "init.ora", eliminar os parâmetros utilizados para a correção do UNDO que apresentavam
      problemas (parâmetros "_offline_rollback_segments=" e "_corrupted_rollback_segments=").

12. Restartar o banco de dados usando o "init.ora"

13. Criar um "spfile" a partir do "init.ora", usar:

    CREATE SPFILE FROM PFILE='/u01/oracle/admin/test/pfile/inittest.ora';

Uma vez que o passo 13 for executado os segmentos de UNDO deverão ser recriados automaticamente e não apresentarão mais erros. No entanto, é aconselhável fazer um backup completo e depois reconstruir os segmentos de UNDO, usando uma exportação e importação. Uma vez que um segmento de UNDO foi removido, poderiam existir algumas transações ativas, durante a corrupção, podendo deixar o banco de dados inconsistente, pois alguma transação pode não ter sido totalmente aplicada no banco.

Para informações adicionais sobre o corrupção de segmentos de UNDO, consute a Nota: 1.088.018.1 - Handling Oracle Database Corruption Issues, no Oracle Metalink. E veja também como corrigir a corrupção de LOGs no UNDO (ORA-00375), com a opção "_undo_log_corruption".



Rubens Oliveira
DBA Oracle Consultor
olivert.dba@consultant.com