Oracle RAC Cache Fusion - Oracle HAIP - Saiba como configurar

Oracle Cache Fusion é um dos componentes mais importante de um ambiente Oracle RAC. Como o próprio nome já indica, trata-se da fusão dos caches (buffers) de memória dos vários servidores que compõem a arquitetura de cluster da Oracle.

Cada instância possui seu próprio buffer local. Imagine que uma transação na Instância "A" precisa acessar um bloco de dados que está em uso na Instância "B". O mecanismo que possibilita que a instância "A" tenha acesso ao bloco da instância "B" é denominado CACHE FUSION. Ou seja, uma instância pode acessar um bloco de dados que se encontra no cache de outra instância via uma interconexão de alta velocidade.

Podemos agora imaginar o quanto este processo é crítico para a performance da solução Oracle RAC. Mas e se configurarmos somente uma placa de rede para executar esta tarefa e esta ficar indisponível por qualquer razão que seja. Imagine agora outra situação que é a limitação de banda da rede, geralmente limitada a 1GB, que pode ficar saturada facilmente dependendo do tipo de aplicação que está sendo rodada no ambiente.

Até pouco tempo poderíamos contornar esta limitação de banda e de disponibilidade do canal configurando o mecanismo de "BONDING". Este termo é usado para representar a junção de 2 placas de rede para aparecer como um único dispositivo com o mesmo endereço MAC. O objetivo é aumentar a largura de banda e possibilitar o contingenciamento da rede na eventual falha de um de seus componentes.

A Oracle, a partir da versão 11gR2 criou o protocolo HAIP (High Availability Internet Protocol) para substituir o bonding. A intenção da Oracle é prover melhor performance e alta disponibilidade com a configuração de até 4 placas de rede.

Como configurar o Oracle HAIP?

Vamos usar o utilitário da Oracle chamado: oifcfg

O Oracle Grid irá criar um apelido denominado IP Privado usando a sub-rede 169.254.*.* para usar no HAIP. 

Passo 1: Identifique os endereços privados de IP

[root@db01 bin]# ./oifcfg getif

eth0  192.168.1.0  global  cluster_interconnect

eth1  10.91.119.0  global  public

Passo 2: Adicione e configure uma nova interface de rede privada (eth4)

[oracle@db01 bin]$ ./oifcfg iflist

eth0  192.168.1.0

eth0  169.254.0.0

eth4  192.168.1.0

eth1  10.91.119.0

Passo 3: Use o utilitário setif para configurar a nova interface de rede com o tipo cluster interconnect.

[oracle@db01 ~]$ oifcfg setif -global eth4/192.168.1.0:cluster_interconnect

Passo 4: Pare o serviço de cluster em todos os servidores(nós do cluster):

[oracle@db01 ~]# sudo /u01/app/11.2.0/grid/bin/crsctl stop cluster -all

(usar sudo - passo 4 - ou logar como root - passo 5)

Passo 5: Inicie o serviço de cluster nos servidores
[root@db01 ~]# /u01/app/11.2.0/grid/bin/crsctl start cluster -all

Passo 6: Confira suas alterações do ambiente:

[root@coltdb01 bin]# ./oifcfg getif

eth0  192.168.1.0  global  cluster_interconnect

eth1  10.91.119.0  global  public

eth4  192.168.1.0  global  cluster_interconnect

[root@coltdb01 bin]# ./oifcfg iflist -p -n

eth0  192.168.1.0  PRIVATE  255.255.255.0

eth0  169.254.0.0  UNKNOWN  255.255.128.0

eth4  192.168.1.0  PRIVATE  255.255.255.0

eth4  169.254.128.0  UNKNOWN  255.255.128.0

eth1  10.91.119.0  PRIVATE  255.255.255.0

Oracle RAC Usar Admin-managed ou Policy-managed database?

A partir da versão 11.2 do banco de dados Oracle surgiram estes conceitos de admin-managed e policy-managed. Mas qual é a diferença entre eles?

Para simplificar, digo que quando se usa a opção admin-managed estamos assumindo o controle de recursos do banco de dados. Na opção policy-managed, deixamos o controle para o serviço de cluster RAC.

Admin-managed é a antiga forma de configurar o serviço de cluster, veja mais sobre o conceito de serviço clicando aqui.

Usando a opção policy-managed, simplificamos a vida do DBA que não mais precisa estar preocupado em gerenciar cada instância em cada servidor individualmente. Agora inserimos o conceito de conjunto (pool) de servidores para gerenciar as diversas instâncias.

Quando você define um serviço como admin-managed será preciso definir também quais instâncias irão suportar este serviço. A instância escolhida é denominada PREFERRED. Também podem ser definidas instâncias chamadas AVAILABLE que podem vir a suportar o serviço em caso de falha da principal (PREFERRED).

Quando você define um serviço como policy-managed significa dizer que um conjunto de servidores (server pool) irá atender a este serviço. Nesta modalidade ainda podemos ter uma política uniforme (uniform policy) ou simples (singleton). Na política uniform o serviço será atendido por todas as instâncias do pool de servidores. Na opção singleton o RAC escolhe a instância do pool que irá atender ao serviço, em caso de falha desta, o serviço migra (failover) para elege uma instância disponível.

Então, qual opção usar?

Caso você tenha um amplo conhecimento do que roda no seu ambiente e tem tempo para ficar administrando recurso use admin-managed.

Mas a minha opção é usar a policy-managed, com política uniforme, pois deixamos no automático com melhor escalabilidade. Adicionamos novos servidores ou removemos conforme a necessidade e deixamos para o RAC decidir qual  nó o serviço irá rodar.

Você conhece uma situação comum que se recomende o uso do serviço admin-managed?

Alert! Onde foi parar o alert log no 11g?

De acordo com a nota metalink - 438148,1, começando com a versão 11g, o arquivo de log de alerta - alert log file - agora é escrito também no formato XML. O local padrão de ambos arquivos fica na ADR (repositório de diagnóstico automático - traduzido).

O ADR é definido usando o parâmetro de inicialização DIAGNOSTIC_DEST. Se este parâmetro for omitido, o local padrão será </u01/app/oracle/diag/rdbms/.../...>.

Em resumo, sua localização segue o padrão: ADR: ADR_BASE / diag / product_type / product_id / instance_id

Além disso, dentro do diretório home ADR estão os seguintes subdiretórios:
 
Alert - O alert.log no formato XML.
Trace- alert.log e traces files
cdump - Core Dump

O alert.log formatado em XML terá a nomencaltura "log.xml"

Quer simplificar ainda mais??

Execute a consulta abaixo no  seu banco de dados:

SQL>  show parameter background

e o resultado será...

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
background_core_dump                 string      partial
background_dump_dest                 string      /oracle/app/oracle/diag/rdbms/PROD/PROD/trace 

Quando fazer Rebuild de um índice - index rebuild

Depois de sofrer um pouco com a indisponibilidade do sistema devido a árdua tarefa de fazer rebuilds em índices no banco de dados Oracle, decidi escrever sobre este assunto.

Afinal, qual é a frequência que devemos fazer index rebuild?

É de importância fundamental fazer a reconstrução dos índices de uma tabela... para manter o dba ocupado!

Isso mesmo. Na imensa maioria das vezes, fazer index rebuild somente piora a situação. Vejam os motivos para evitar esta desnecessária perda de tempo (do DBA) e de performance (do Banco de Dados):

1) Os espaços entre linhas deletadas nos índices são reaproveitados através de novos inserts na tabela;
2) Uma tabela com várias linhas deletadas apresenta fragmentação também no índice. Mas para resolver o problema devemos primeiro fazer o rebuild da tabela;
3) Um rebuild numa tabela cria um rebuild implícito nos seus índices;

E tem mais:

O processo de rebuild consome muito recurso na geração de estatísticas
•Estas estatistics resultam em problema de  locking nas tabelas
•Index rebuilds geram uma enorme quantidade de overheads no Redo log
•Index rebuilds (feitos online) exigem locks que impactam na performance (resolvido na versão 11g)
•A performance do banco pode piorar após a execução de index rebuilds
•Index rebuilds podem gerar o erro ORA-123 em queries longas

Sobre a constante tarefa de fazer rebuild em índices, vejam o que os experts em Oracle tem a dizer:

A grande maioria dos índices não requerem rebuilds. Os principais mitos sobre index rebuild são:
•Índice do tipo B-tree indexes ao longo do tempo ficam desbalanceados
•Linhas deletadas dentro dos índices não são aproveitadas
•Se um índice passa de 3 níveis ele fica ineficiente
•Se um índice tem um fator de clusterização ruim ele precisa sofrer rebuild
•Para se ter excelente performance os índices precisam ser regularmente reconstruídos





Quem quiser saber mais (e dar umas risadas) leia no link abaixo uma explicação bem humorada no site asktom.oracle.com (em inglês):

Outras referências:

When Should You Rebuild an Index?

How to predict Index blevel and when to rebuild

Index-internals: Rebuilding the Truth

ORA-12640, ORA-21561: Falha na geração do OID

Erro ORA-12640 ou ORA-21561? Você já teve este problema no seu site?

No ambiente Windows, estávamos enfrentando um erro que impedia novas conexões no banco de dados. O erro era ORA-12640: "Authentication adapter initialization failed" - Falha na autenticação.

Nosso ambiente é complexo e com um eleavado número de conexões.

Após alguma pesquisa, descobri que bastava substituir o parâmetro SQLNET.AUTHENTICATION_SERVICES, no arquivo SQLNET.ORA, de NTS para NONE. Pronto! Nunca mais eu veria este erro, certo?

Na verdade eu troquei 6 por meia dúzia. Depois dessa mudança passei a receber o erro ORA-21561: Falha na geração do OID. Como resolver esta situação?

Veja as dicas abaixo:

Causa: O problema ocorre devido a um aumento no volume de conexões no banco de dados. O Windows estava com um valor baixo para o parâmetro SharedSection heap.

Solução:
1) Altere o parâmetro no arquivo sqlnet.ora no servidor do banco de dados

• SQLNET.AUTHENTICATION_SERVICES=NONE

2) No servidor de aplicação vá para: Iniciar (Start) do Windows entre em executar (RUN) digite:

• regedit 

3) No editor da registry do Windows vá para:

• \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems\

4) Clique com o botão direito na chave "windows" e altere o valor:
De:

• %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Para:

•  %SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,1024 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16

Este terceiro valor do parâmetro SharedSection que estava em 512 representa o desktop heap para cada estação que conecta ao windows. No nosso caso o valor 1024 resolveu o problema, mas você deve fazer testes e ajustar conforme sua necessidade.
  Veja mais sobre o parâmetro SharedSection no site da Microsoft:
http://support.microsoft.com/kb/184802 


Sucesso!


Luis Adelson.

Como Acessar um Banco de Dados Sem Senha

É possível acessar um banco de dados sem a password do esquema?

Podemos simplesmente alterar a senha do esquema. Contudo, podem existir aplicativos associados àquela antiga senha. Neste caso, você irá habilitar-se ao esquema temporariamente, executar a atividade que precisa e logo em seguida retornar a senha antiga.

Na sequência abaixo coloco dois exemplos de como fazer este procedimento.

SQL> CONNECT / as sysdba
Connected.

SQL> SELECT password FROM dba_users WHERE  username='SCOTT';
PASSWORD
--------------- ---------------
F894844C34402B67

SQL> ALTER USER scott IDENTIFIED BY anything;
User altered.

SQL> CONNECT scott/anything
Connected.

OK, we're in. Let's quickly change the password back before anybody notices.

SQL> ALTER USER scott IDENTIFIED BY VALUES 'F894844C34402B67';
User altered. 

Uma forma mais simples é usa a query que irá gerar o SQL do comando para retornar a senha antiga:

Script:

SQL> SELECT 'ALTER USER '||USERNAME||' IDENTIFIED BY VALUES '''||PASSWORD||''';'
  FROM DBA_USERS, GLOBAL_NAME
 where username in ('USR_PGEPLANO');

 

SQL> ALTER USER scott IDENTIFIED BY VALUES 'F894844C34402B67'; 

Para descontrair...

Sucesso!

Luis Adelson 

Como habilitar ARCHIVE no Oracle RAC

1. Entre em um dos nós (por exemplo: racnode1) e desabilite a opção de cluster da instância, isto é, altere o atributo cluster_database para FALSE:
   
   

   $ sqlplus "/ as sysdba" SQL> alter system set cluster_database=false scope=spfile sid='racdb1';

2. Tire todo mundo do ar (Shutdown all instances):
   
   

   $ srvctl stop database -d racdb

3. Volte novamente a sua instância que você alterou o atributo de cluster e inicie o banco em MOUNT:
   
   

   $ sqlplus "/ as sysdba" SQL> startup mount

4. Agora habilite o modo archive:
   
   

   SQL> alter database archivelog;

5. Volte novamente o atributo de cluster para verdadeiro:
   

   SQL> alter system set cluster_database=true scope=spfile sid='racdb1';

6. Tire a instância do ar:
   
   

   SQL> shutdown immediate

7. Agora pode por tudo no ar usando o comando srvctl:
   
   

   $ srvctl start database -d racdb

8. Se o serviço estiver fora do ar, use o comando srvctl para por novamente ativo:
   
   

   $ srvctl start service -d racdb

   
   
9. Entre na instância local e veja se o banco está em modo archive:
   
   
   

   $ sqlplus "/ as sysdba" SQL> archive log list Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 83 Next log sequence to archive 84 Current log sequence 84

Após estes procedimentos, cada instância do RAC poderá arquivar seus redologs!


Abraços e Sucesso!


Luis Adelson