segunda-feira, 30 de novembro de 2009

OTIMIZANDO O PROCESSO DE DUPLICATE DATABASE ( RMAN )

Olá pessoal, hoje venho aqui compatilhar com vocês uma experiencia vivida no meu dia-a-dia, recentemente estava passando por um problema onde trabalho, um processo de DUPLICATE DATABASE via RMAN estava demorando mais do que o convencional, chegando a levar mais de 5 horas para terminar, e após algumas verificações e alterações feitas no meu S.O e uma mudança em um parametro de banco consegui diminuir este tempo para 1 hora e 46 minutos, um ganho significativo, não acham? Descreverei abaixo o que eu tive que olhar e o que eu alterei para obter este ganho de performance neste processo.


CHECANDO OS PARAMETROS DE REDE


Basicamente o meu processo de duplicate depende intimamente da sua velocidade das interfaces de rede existentes no server utilizado, e em verificação feita com a ferramenta ETHTOOL encontrada no Red Hat server, só para constar essa ferramenta é uma evolução do famoso MII TOOL também utilizado na verificação de parametrizações de redes.


Pois bem, até agora tudo bem, mas o que é mais interessante é vocês me perguntarem assim : O QUE EU DEVO OLHAR NA SAIDA DESTE COMANDO? um excelente questionamento, porque senão você verá inumeras informações na tela e nada que você se enquadre nas alterações, visto que isso é um trabalho de SYSADMINS, quando garantem a performance dos servers que eles mesmo montam é claro, mas podemos encontrar aqueles que digam assim : SÓ MONTEI O QUE VOCÊ PEDIU, NISSO EU NÂO MEXI. Cruel demais ouvir isso, como se fosse necessário pedir performance, mas enfim vamos ao que interessa.


COMO FAÇO PARA VERIFICAR MINHAS CONFIG'S DAS INTERFACES DE REDE?


Com a ferramenta ETHTOOL é bem simples, basta executar o seguinte comando :


1) Abra uma janela terminal se for local, ou uma sesão PUTTY se for remota e digite:


ethtool


Veja:
[root@pelspos7b log]# ethtool eth1
Settings for eth1:
Supported ports: [ TP ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: umbg
Wake-on: d
Current message level: 0x00000007 (7)
Link detected: yes


Nota: É bem provavel que você precise de uma conta com permissões de ROOT para ver essas opções, caso você não as tenha peça para que seu SYSADMIN lhe forneça apenas a saida desta linha de comando, com ela você consegue analisar os pontos importantes.


Feito isso nós encontaremos diversas informações sobre as nossa interface de rede, tais como velocidades suportadas, modo de troca d epacotes ( HALF DUPLEX, FULL DUPLEX,etc) e o tipo de negociação feita por esta interface que pode ser do tipo AUTONEGOCIATED ou não.


O que geralmente implica a questão de sua interface de rede estar em autonegociate é que dentre as velocidades por ela suportada pode haver uma péssima opção por parte do S.O , podendo trafegar em velocidade inferior a Gigabit,o que não é lá muito recomendado em máquinas que possuem Banco de Dados Oracle, experimente ter um server assim e veja os gargalos de rede se propagarem, sem contar nas lentidões em conexões e processos, mas enfim procure sempre não deixar suas interfaces de rede configuradas para autonegociate.


Depois que acertei essa parte relacionada as interfaces de Rede, eu parti para os parametros de configuração do meu NFS, e cheguei a conclusão de que foram criados com o padrão, tendo escritas e leituras a 8k, sendo que minha base tem mais de 200 GB e utilizando 8k para ler e escrever isso em discos locais do meu outro server onde tenho o DUPLICATE , não estava lá dando muito certo.


Foi ai então que olhando configurações relacionadas na internet, e lendo alguns artigos do site da Red Hat e alguns foruns de discussão sobre o assunto resolvi alterar as configs para :


/u02/backup nfs rsize=32768,wsize=32768,intr,noatime
/u03/backup nfs rsize=32768,wsize=32768,intr,noatime
/u04/oracle/archives/SPPE nfs rsize=32768,wsize=32768,intr,noatime


Alterei todos os meus NFS existentes, colocando ao invés de 8k, 32k de leitura e escrita, caso vocês queiram ler mais sobre o assunto de como tornar seus NFS mais performaticos segue aqui um link muito bom que encontrie :


http://nfs.sourceforge.net/nfs-howto/ar01s05.html


Bem , agora chegamos a minha derradeira e ultima atuação no processo, os parametros de Banco, tendo em vista que o RMAN utiliza muito da LARGE POOL SIZE para alocações de canais no processo de RESTORE e RECOVER do RMAN, eu resolvi comparar meu ambiente principal com meu ambiente DUPLICADO e identifiquei que na minha produção haviam 160 Mb de Large Pool configurados, enquanto que na minha base de DUPLICATE eu contava apenas com miseros 32 MB, então aumentei para 100MB minha LARGE POOL para dar uma forcinha ao RMAN, para isso eu editei meu INIT.ORA da base a ser duplicada


NAME VALUE
------------------------------ ------------------------
large_pool_size 117440512

Bom, agora era só aguardar o processo de DUPLICATE iniciar em seu horário e verificar no dia seguinte a obtenção de ganhos ou não dos mesmos, veja abaixo a diferença brutal :


Ultimo LOG do processo de Duplicate :


-rw-r--r-- 1 oracle 70952 Nov 26 07:23 rman_dupdb-261109-01-00.log

contents of Memory Script:



{


Alter clone database open resetlogs;


}


executing Memory Script


database opened


Finished Duplicate Db at 26/11/2009 06:59:42


starting full resync of recovery catalog


full resync complete




Recovery Manager complete.



Ultimo LOG após alterações :


-rw-r--r-- 1 oracle 119658 Nov 30 02:44 rman_dupdb-301109-01-00.log


Veja o Trecho Final :


contents of Memory Script:
{
Alter clone database open resetlogs;
}
executing Memory Script



database opened
Finished Duplicate Db at 30/11/2009 02:44:22



Recovery Manager complete.


Obtive um ganho de mais de 4 horas no processo, e com isso melhorei a performance do processo.


Bem é isso, espero que tenham gostado desse "DIA-A-DIA" compartilhado com vocês, até a próxima.


Abraço á todos


Obs.: Este Post eu dedico a dois amigos o Rodrigo Almeida especialista em RMAN e ao Bruno Murassaki um grande DBA e excelente profissional.