Arquivo do mês: setembro 2011

Paralelização de backup utilizando instâncias do Oracle RAC

Saudações pessoal, esse artigo tem o objetivo de mostrar como realizar o paralelismo no nível de instância para realização de backups.

Nesse caso a base possuia aproximadamente 370 Gb, o tempo de backup era de 1 hora, utilizando a técnica abaixo eu passei a realizar o backup em 30 minutos, ou seja, ganho de 100%.

Pré requisito:

Option de paralelização, encontrada na versão Enterprise do Oracle Database, e claro, nesse caso em específico, o ambiente estar em RAC.

Grant de sysdba para o usuário que for conectar remontamente na instância, nesse caso userbkp

Tnsnames configurados corretamente para cada instância, nesse caso dbprod1 (apontando para o nó1) e dbprod2 (apontando para o nó 2)

Script:

$ORACLE_HOME/bin/rman target / catalog usercatalog/******@db_catalog
run
  {
  allocate channel canal1_rman device type disk format ‘/disco1/rman/BKP_RMAN_LEVEL1_%d_%D_%M_%Y_%s_%p_%t’ maxopenfiles 8 connect ‘userbkp/****@dbprod1’;
  allocate channel canal2_rman device type disk format ‘/disco2/rman/BKP_RMAN_LEVEL1_%d_%D_%M_%Y_%s_%p_%t’ maxopenfiles 8 connect ‘userbkp/****@dbprod2’;
  allocate channel canal3_rman device type disk format ‘/disco3/rman/BKP_RMAN_LEVEL1_%d_%D_%M_%Y_%s_%p_%t’ maxopenfiles 8 connect ‘userbkp/****@dbprod1’;
  allocate channel canal4_rman device type disk format ‘/disco4/rman/BKP_RMAN_LEVEL1_%d_%D_%M_%Y_%s_%p_%t’ maxopenfiles 8 connect ‘userbkp/****@dbprod2’;
  crosscheck archivelog all;
  crosscheck backup;
  delete noprompt force obsolete;
  delete noprompt force expired backup;
  sql ‘alter system checkpoint global’;
  backup as compressed backupset incremental level 0 cumulative database;
  release channel canal1_rman;
  release channel canal2_rman;
  release channel canal3_rman;
  release channel canal4_rman;
}

 Vejam que, a novidade para nós, é o comando, connect na alocação do canal, ele recebe usuário,senha e a string do tnsnames, que deve apontar para a instância na qual queremos que trabalhe para nós.

É possível alocar todos os canais na mesma instância ? a resposta é sim, porem se eu alocar os quatro canais e uma instância só, talvez eu terei uma carga de trabalho muito alta em um nó só, e isso é ruim, não seria melhor pensar em dividir a carga ? dentre outras opções, é para isso que o RAC existe, para usufruirmos da possibilidade de balanceamento.  Essa regra vale para todos os backups ? concerteza não, caberá ao DBA definir a melhor estratégia para o seu ambiente, reforço que, o objetivo do artigo é mostrar a funcionalidade.

Outra máxima que precisamos considerar é , sempre que pensarmos em paralelismo, devemos considerar recursos físicos, basicamente processadores e discos, pensando em backups, a teoria diz que, teremos ganho se, alocarmos um canal por disco físico. Pensando em bases pequenas (penso eu as menores que 1Tb), talvez essa teoria talvez caia por terra, mas já pensou em bases com 40,50, 100 Tb ? concerteza o ganho será efetivo.

Uma forte dica para a utilização de paralelismo, tanto em backups, criação de indices online/offline, hints específicos para consultas, movimentação de tabelas, degree em objetos etc etc etc é, testar antes de implementar em produção, se não puderem testar, implementem aos poucos, coletem números, analisem ganhos, perdas, overhead,  paralelização é sério, acho sensacional, porem se mal implementada, a performance fica comprometida.

Um forte abraço, e até a próxima

 

ORA-00600: internal error code, arguments: [kcbnew_3], [5], [1], [454544], [], [], [], []

Saudações pessoal, se alguem encontar o erro acima tente a seguinte solução.

Tentem aplicar o patch off 5558244 para a respectiva versão do SO, ou recriarem o indice que pode ser encontrado

Alterando o diagwait para 13 no Oracle Database 11gR2

Saudações Pessoal !!!

Uma dica rápida sobre esse assunto, conheço um bom e velho DBA que utilizou essa alternativa, para solucionar um grave problema de eviction entre os nós do Oracle RAC Isso causava reboot de um dos nós, durante o horário comercial, depois desta alteração, não ocorreu mais eviction entre os nós do Oracle RAC,  consequentemente, não ocorreu mais reboots.

Reforçando que isso não deve ser considerado normal, é necessário investigação com os Engenheiros da Oracle, a procura da causa raiz, de problemas como o eviction.

1º – Fazer em todos os nós como:

 [root@racnode2 bin]# ./crsctl stop crs -f 

2 – Constatando que os recursos estáo desligados.

[root@racnode1 grid]# /u01/app/11.2.0/grid/bin/oprocd stop
Jan 08 16:01:12.441 | ERR | failed to connect to daemon, errno(2)
[root@racnode1 grid]# ps -ef |egrep “crsd.bin|ocssd.bin|evmd.bin|oprocd”
root      7975  7916  0 16:01 pts/1    00:00:00 egrep crsd.bin|ocssd.bin|evmd.bin|oprocd

#crsctl set css diagwait 13 -force 

3º – Fazer em todos os nós como:

[root@racnode1 bin]# set css diagwait 13 -force
[root@racnode1 bin]# set css diagwait 14 -force
[root@racnode1 bin]# set css diagwait 15 -force
[root@racnode1 bin]# set css diagwait 40 -force
[root@racnode1 bin]# set css diagwait 999 -force
[root@racnode1 bin]# set css diagwait 13 -force