Backup & Recovery Parte 2 - Realizando o Backup e Restaurando o Banco de dados

No artigo anterior, foi mostrando as configurações para aumentar as chances do banco de dados ser recuperado, neste arquivo será mostrado o processo de backup e recuperação.

Backup Oracle pelo RMAN

Todo backup que o feito para o RMAN é catalogado, ou seja o Rman sabe onde estão os arquivos de backup, e no momento do Restore, o RMAN irá procurar pelos backup onde ele os criou. O catalogo do Rman é obrigatoriamente feito no ControlFile,e opcionalmente em outro banco, que seria um banco de catalogo, este artigo irar trabalhar somente com o catalogo no ControlFile.

O Rman executa uma variedade de backups, tais como Cópia de Imagem e backup Piece entre outros. O que será apresentado é backup incremental, que para poder funcionar o banco deve esta no modo archive log, como já apresentado.

Em resumo o backup incremental é composto por um backup completo do banco de dados, chamado de nível 0 e depois temos os backups incrementais, nível 1, que inclui tudo que ocorreu no banco após o último backup nível zero.

Primeiramente crie um arquivo Texto com o nome RmanLEVEL0.rman e inclua os comandos abaixo, adaptado para o local onde deseja realizar o backup, para realizar o backup nível Zero.

run { allocate channel discozero type disk format
'C:\bck_oracle\Fisico\Level0\LEV0dat%u.bkp',
' \\172.16.1.21\BCK_ORACLE\Fisico\Level0 \LEV0dat%u.bkp';
backup copies 2 incremental level = 0 (database include current controlfile);}

Depois crie outro arquivo com o nome RmanLEVEL1.rman e inclua o comando

run { allocate channel discozero type disk format
'C:\bck_oracle\Fisico\Level1\LEV1dat%u.bkp',
' \\172.16.1.21\BCK_ORACLE\Fisico\Level1 \LEV1dat%u.bkp';
backup copies 2 incremental level = 1 (database include current controlfile);}

É preciso criar outro script executável (.bat ou cmd no Windows) para chamar o Rman e invocar o arquivo de Backup. Crie no mesmo diretório onde encontra o arquivo o RmanLEVEL0.rman o arquivo “bck_fisico_Leval0.cmd”,dentro dele, coloque a instrução abaixo:

Rman target sys/@xe nocatalog @RmanLEVEL0.rman >> log_nivel_0.log

Através do agendador de tarefa do Sistema Operacional, configure o backup nível 0 a ser realizado pelo menos duas vezes na semana, e o nível 1 para fazer nos demais dias da semana.

Estes scripts instrui o Rman a criar um backup multiplexado, sendo um em disco local e outro no disco remote e sempre incluir o controlFile no backup.

NOTA: Caso ocorrá erros de privilegios ao executar o backup no disco remoto, configure o serviço do banco de dados com algum usuário de rede, conforme mostrado na 1º parte deste artigo.

Os backups multiplexado têm a grande vantagem de um ser exatamente igual ao outro, então caso tenhamos somente backups da maquina remota, por exemplo, os incrementais não dependerão de pedaços que encontra na maquina onde hospeda o banco de dados. Se os backups forem executados primeiro em um destino e depois no outros, os backups incrementais dependerão de todo o conjunto de backup.

Depois, criei mais dois arquivos para apagar os backup's obsoletos - que estão fora da janela de 7 dias, (como mostrado no artigo anterior) um para logar e chamar o arquivo que contem o comando rman que apaga e outro arquivo que contem a instrução, DELETE OBSOLETE.

run {
backup database plus archivelog;
crosscheck archivelog all;
crosscheck backup;
delete obsolete;
}

                                                Recuperação do Banco de Dados

Apesar da tarefa de restore & recover não ser uma tarefa trivial, se seguido os passos informado neste artigo a recuperação do banco de dados será perfeitamente possível e ainda em uma janela pequena de tempo.

Serão apresentadas algumas situações de falhas e quais ações são necessárias para a restauração do Banco.

Contudo, antes de apresentar é preciso especificar o que RESTARAÇÃO e RECUPERAÇÃO do banco de dados.

RESTAURAÇÃO: Consiste no processo da recriação de um ou mais arquivos que compõe o banco de dados, se for necessário a restauração de todos os arquivos, diz que se faz restauração do banco de dados. Existe situação, tal quando é preciso restaurar um backup do ControFile, é preciso restaurar o banco de dados inteiro.

RECUPERAÇÃO: Consiste no processo quando o arquivo existe, porém ele (ou mais de um arquivo) encontra-se inconsistente em relação ao ControlFile e demais arquivos que compõem o banco de dados. Dentro do ControlFile o e no cabeçalho de cada arquivo o guardo o valor SCN, um número seqüencial, que se comporta como um relógio de tempo do banco de dados. Antes de abrir o banco de dados checa se todos os arquivos têm o mesmo SCN, caso não o arquivo necessita de restauração.

Primeiramente, para realizar a recuperação do arquivo de dados, é preciso que o arquivo esteja inconsistente. Para isso desligue o banco, faça uma copia de qualquer arquivo de dados, inicie o banco de dados e desligue novamente, troque o arquivo de dados original pelo arquivo de dados copiado e inicie novamente.

Ocorrerá o erro ora-01113, dizendo que o arquivo de dados precisa de recuparação de midia ao tentar abrir o banco de dados.

ORA-01113: o arquivo 5 precisa da recuperação de mídia
ORA-01110: 5 do arquivo de dados:
'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\DADOS01.DBF'

Neste caso o Oracle, informou que qual arquivo de dados esta com problema, então basta simplemente executar o comando RECOVER e depois abrir o banco de dados.

SQL> recover datafile 5;
Recuperaçãode mídia concluída.
SQL> alter database open;

Banco de dados alterado.

Pronto, seu banco de dados já está disponível, parece simples não? E é, quando você já preparou tudo antes da falha acontecer. Mas o que aconteceu aqui? É preciso entender o que ocorreu. Lembre o SCN que é um numero sequencial interno do Oracle que funciona como um relogio. Pois bem, o arquivo 5 do datafile estava dessincronizado com restante do banco de dados.

Para ilustração, suponha que o banco de dados esteja com valor igual a 10 o scn, quando foi desligado pela primeira fez foi para 11, neste instante o arquivo 5 foi copiado. Feito isso, o banco de dados foi iniciado, SCN foi para 12, então o banco foi desligado novamente, SCN foi para 13. O arquivo de dados 5 foi trocado pela cópia (que esta com SCN igual a 11) , ao tentar abrir o banco de dados checou o valor do SCN de todos os arquivos que compoem o banco de dados, e com isso conclui que o arquivo 5 precisa de recuperação de mídia.

Como toda operação que ocorre no banco de dados, o Oracle grava no Log de Redo Online e também em algum arquivo do S.O. O Oracle usou o conteúdo do Archive, caso necessario, e o conteúdo do Log de Redo Online para atualizar as operações no datafile 5 e como consequencia, colocar o SCN deste arquivo como 13, podendo então este banco ser aberto.

Agora, será feito a RESTAURAÇÃO de algum arquivo de dados, para isso, desligue o servidor e apague algum arquivo de dados do Oracle e tente iniciar o banco, irar aparecer uma mensagem de erro.

Banco de dados montado.
ORA-01157: não é possível identificar/bloquear arquivo de dados 5 - consulte arquivo de análise BWR
ORA-01110: 5 do arquivo de dados:
'C:\ORACLEXE\APP\ORACLE\ORADATA\XE\DADOS01.DBF'

Agora o Oracle após montar a instância, ele procurou todos os arquivos de dados que o controlfile disse que existe, e como o arquivo não existe, apareceu o erro. Este erro pode acontecer por exemplo se os datafiles estão em vários discos e ocorre algum crash em um dos disco.

Basta executar o banco RESTORE e depois RECOVER no RMAN e então abrir o banco de dados.

C:\>rman target sys/senha nocatalog
RMAN> restore datafile 5;
Iniciando restore em 06/02/12
......
RMAN> recover datafile 5;
RMAN> sql "alter database open";

Ao executar o Restore, o banco de dados usou o último backup físico nível zero para recriar o arquivo de dados, como este arquivo vai estar descincronizado com o banco, execute o restore, depois abrar o banco.
Note que o Oracle recriou arquivo no mesmo diretorio que ele espera que o arquivo existia, mas se este arquivo esta em algum disco que esta indisponivel?

Para simular isso, desligue o banco de dados e altere o arquivo para diretorio do S.O e depois tente iniciar.

SQL> shutdown immediate
Banco de dados fechado.
Banco de dados desmontado.
InstÔncia ORACLE desativada.

Copie algum arquivo de dados para outro diretorio e depois inicie o banco de dados no esta mount.

SQL> startup mount;
InstÔncia ORACLE iniciada.
Total System Global Area 795127808 bytes
Fixed Size 1386496 bytes
Variable Size 499124224 bytes
Database Buffers 289406976 bytes
Redo Buffers 5210112 bytes
Banco de dados montado.

Renome o arquivo, informando o novo local do datafile.

SQL> ALTER DATABASE RENAME FILE
to 'C:\Particular\DADOS01.DBF';
Banco de dados alterado.

Desligue o banco, depois apague o diretorio, ou renomei - o que acha melhor - e então tente abrir, a mesangem erro irar aparecer ORA-01157.

Ao simplesmente executar o comando restore irar aparecer um erro, sinalizando que o oracle não consegue criar o arquivo porque o diretorio que este esta tentando fazer a restauração não existe.

RMAN> restore datafile 5;
Iniciando restore em 06/02/12
.....
ORA-19504: falha ao criar arquivo "C:\PARTICULAR\DADOS01.DBF"
ORA-27040: erro ao criar arquivo, não foi possível criar o arquivo
OSD-04002: não foi possível abrir arquivo
O/S-Error: (OS 3) O sistema não pode encontrar o caminho especificado.
failover para backup anterior
.....

Como o diretorio onde estava o Data File não esta disponivel, será preciso dizer ao Oracle para usar algum diretorio disponivel. Para isso use o comando SET NEWNAME e depois o restore.

run {set newname for datafile 5 to 'C:\oraclexe\app\oracle\oradata\XE\dados01.dbf';
restore datafile 5;}

executando comando: SET NEWNAME
Iniciando restore em 06/02/12
....
Finalizado restore em 06/02/12

Depois informe ao CONTROLFILE o ludar onde esta o arquivo de Dados Restaurado.

SQL> ALTER DATABASE RENAME FILE 'C:\Particular\DADOS01.DBF' to 'C:\oraclexe\app\
oracle\oradata\XE\dados01.dbf';
Banco de dados alterado.

Faça a recuperação do arquivo recem criado.
SQL> recover datafile 5;
Recuperação de mídia concluída.

Então abra o Banco de dados.

SQL> alter database open;
Banco de dados alterado.

Agora, será feito o exercicio, onde precisaremos restaurar o banco de dados inteiro. Pode ser que alguem deliberadamente apagou todos os arquivos do banco de dados ou em um outro cenário, onde o Oracle foi instado no c:\ , mas todos os arquivos do banco esta em outro disco, unidade d:\, por exemplo.

Para simular o primeiro cenario desligue a base de dados, então exclua todos os datafile e o(s) controlfile(s) do banco de dados. Neste cenario ao tentar iniciar a instancia, será apresentado o erro: Ora-00205, o que significa que o banco nem consegui ser montado, porque o ControlFile não foi excluido.

SQL> startup
Instância ORACLE iniciada.
Total System Global Area  795127808 bytes
Fixed Size                  1386496 bytes
Variable Size             499124224 bytes
Database Buffers          289406976 bytes
Redo Buffers                5210112 bytes
ORA-00205: erro na identificação do arquivo de controle, verifique o log de
alertas para obter mais informações.

Como as informações dos backup's estão no controlfile, antes de executar o Restore/Recover, será preciso Restaurar o ControlFile. Será preciso saber onde estão o seus backup, para informar ao Oracle a sua localização.

Como todo script de backup tem a instrução de incluir o ControlFile em seus backup, existirá dois arquivos para cada backup executado, um com o Backup de todos o DataFile e outro do ControlFile. Como o ControlFile é pequeno, o backup dele também será pequeno em relação aos datafile.

RMAN> restore controlfile from 'C:\Backup\LEV0DATE06N2KN55.BKP';
Iniciando restore em 07/02/12
....
Finalizado restore em 07/02/12

Com o ControlFile resturado, monte o banco de dados e faça a restauração dos DataFiles do Banco de dados, depois a recuperação e abra o banco de dados.

RMAN> sql "alter database mount";

RMAN> restore database;
Iniciando restore em 07/02/12
...
Finalizado restore em 07/02/12

RMAN> recover database;
Iniciando recover em 07/02/12
....
Finalizado recover em 07/02/12

RMAN> sql "alter database open resetlogs";


Feito isso, o Banco de Dados já foi restaurado e pronto para uso. Neste cenario, os diretorios originais do ControlFile e DataFile existia, contudo se eles não estiverem disponiveis, por exemplo, o Oracle foi instado no c:\ , mas todos os arquivos do banco esta em outro disco, unidade d:\, e este disco perdeu.

Para simular isto, desligue novamente a base e depois apague todos os arquivos de dados e renomei a basta onde estão seus arquivos. No caso, foi excluidos todos os arquivos e depois a pasta XE, onde se encontrava todos os arquivos do banco de dados foi renomeado para XENEW.

C:\oraclexe\app\oracle\oradata\XE para C:\oraclexe\app\oracle\oradata\XENEW

No SQLPLUS tente iniciar a instância, ocorrerá o erro ORA-00205, então pelo Rman, tente restaurar o ControlFile. Então ocorrerá erro ORA-27040.

RMAN> restore controlfile from 'C:\Backup\LEV0DATE06N2KN55.BKP';
Iniciando restore em 07/02/12
....
ORA-27040: erro ao criar arquivo, não foi possível criar o arquivo
OSD-04002: não á possível abrir arquivo
O/S-Error: (OS 3) O sistema não pode encontrar o caminho especificado.
RMAN>

Este erro ocorreu, porque o Oracle tentou criar o ControlFile no diretorio de origem, onde o mesmo não esta disponivel, com isso será preciso intruir o Oracle há criar o ControlFile em outro diretorio, para crie um arquivo INIT.ORA a partir do SPFILE do Oracle, pois o SPFILE tem todos os parametros atualizado.

 SQL> create pfile='c:\backup\init.ora' from spfile;

Abra o arquivo e altere o parametro ControlFile para algum diretorio disponivel, desligue o banco de dados, inicie o banco no estado nomount com o pfile, crie um no spfile de depois execute o recover pelo Rman.

 SQL> shutdown immediate;
ORA-01507: banco de dados não montado
Instância ORACLE desativada.

SQL> startup nomount pfile='c:\backup\init.ora';
Instância ORACLE iniciada.
Total System Global Area  795127808 bytes
Fixed Size                  1386496 bytes
Variable Size             499124224 bytes
Database Buffers          289406976 bytes
Redo Buffers                5210112 bytes
SQL> create spfile from pfile='c:\backup\init.ora';

RMAN> restore controlfile from 'C:\Backup\LEV0DATE06N2KN55.BKP';
Iniciando restore em 07/02/12
...
nome do arquivo de saída=C:\ORACLEXE\APP\ORACLE\ORADATA\XENEW\CONTROL.DBF
Finalizado restore em 07/02/12
RMAN>

Neste momento pode alterar o local de arquivo por arquivo, como ilustado anteriormento, ou simplemente instruir o RMAN a restaurar todos os DataFile para um diretorio comum, para isso faça:

SQL> alter system set DB_CREATE_FILE_DEST='C:\oraclexe\app\oracle\oradata\XENEW'

RMAN> run {set newname for datafile 1 to NEW;
           set newname for datafile 2 to NEW;
           set newname for datafile 3 to NEW;
           set newname for datafile 4 to NEW;
           set newname for datafile 5 to NEW;
           restore database;
           switch datafile all;}
executando comando: SET NEWNAME
....
canal ORA_DISK_1: restaurando o arquivo de dados 00001 em C:\ORACLEXE\APP\ORACLE
\ORADATA\XENEW\XE\DATAFILE\O1_MF_SYSTEM_%U_.DBF
...
canal ORA_DISK_1: restaurando o arquivo de dados 00005 em C:\ORACLEXE\APP\ORACLE
\ORADATA\XENEW\XE\DATAFILE\O1_MF_DADOS_%U_.DBF
....
Finalizado restore em 07/02/12

arquivo de dados 1 alternado para a cópia do arquivo de dados
cópia do arquivo de dados de entrada RECID=6 STAMP=774622994 file name=C:\ORACLE
XE\APP\ORACLE\ORADATA\XENEW\XE\DATAFILE\O1_MF_SYSTEM_7M2H67KV_.DBF
.....
RMAN>

Com estes comandos o Rman criou novos DataFiles dentro do caminho indicado e o comando switch datafile all,  realiza a troca dos nomes antigos pelos novos criados, com isso não será necessário executar o comando ALTER DATABASE RENAME FILE.

Agora basta fazer a recuperação do banco de dados e depois abrir-lo com ResetLog's.

RMAN> recover database;
Iniciando recover em 07/02/12
...
Finalizado recover em 07/02/12

RMAN> sql "alter database open resetlogs";

Pronto, banco de dados disponivel para os usuarios.


                                                           Conciderações

Este artigo é apenas uma parte da vasta opções de Backup e Recover do banco de dados Oracle. Em demais artigos irei mostrar outras opções de Recover, como por exemplo a Recuperação Incompleta e a recuperação em outras maquinas, tanto util para situações de extrema necessidade como simplemente criar um banco de dados de teste.

Backup & Recovery Parte 1 - Configurando o Banco Recuperação

De todas as tarefas que um DBA precisa fazer, o Recover é a principal delas, ao contrario que muita gente pensa ser o Backup. O Backup nada mais do que uma tarefa para se chegar no Recover. Quando um banco de dados falhar, o DBA estará sob enorme pressão para recuperá-lo o mais rapidamente possível, contudo nenhuma DBA sofrerá pressão para fazer Backup. É fundamental estar preparado, não será nada bom ficar procurando as soluções nos manuais antes de tomar as medidas adequadas. Devido a isso a formula é estudar, conhecer o banco de dados e depois: Praticar, praticar e praticar.

Esta série de artigos visa mostrar o processo de Backup e Recover usando o RMAN em backups incrementais. O ambiente mostrado é em Windows com Oracle 10g, mas totalmente adaptável para Linux, com backup’s baseados em discos (levando em consideração do preço dos discos e a capacidade de armazenamento, atende muito bem a muitas empresas), nesta primeira parte será mostrado conceitos básicos e a configuração para preparar o banco para recuperação.

Antes de mostrar como faz backup no Oracle, será apresentado uma compreensão de como funciona o Oracle, e isto é muito importante, pois no momento em que precisar fazer o Recover e as coisas não irem bem, ter o conhecimento de como funciona o mecanismo Oracle irá ajudar e muito neste processo.

SGBD Oracle

O Oracle é composto basicamente por duas partes:

      ·         Instância Oracle
      ·         Banco de Dados Oracle

Instância Oracle

A instância é a estrutura de memória e os processos Oracle que se encontram na memória principal, obviamente uma instância existe quando a maquina está ligada, pois os dados da memória principal são voláteis.

A instância é composta por duas áreas de memória o SGA e o PGA, sendo que o 1º é uma área de memória publica e é dividida em varias outras pequenas áreas como cache de consulta ou estrutura de tabela e pacote para otimização dos processos Oracle, enquanto a segunda é uma área privada onde guarda os valores de variáveis e processos de cada sessão.

Banco de Dados

O Oracle database é composto por três tipos de arquivos que encontra-se no sistema operacional

*ControlFile

*DataFile

*LogRedo

Para saber a localização destes arquivos, basta executarem algumas consultas no dicionário de dados do Oracle.

ControlFile: O ControlFile é um arquivo pequeno, mas muito importante, pois nele contem todas as informações necessária para montar uma instancia Oracle, ou seja nele contem a informação como nome do Banco de dados, os arquivos do banco de dados e qual o valor atual do SCN, além disse as informações do backup estarão nele, e caso este arquivo corrompa é necessário restaurar o banco de dados inteiro, por isso é crucial temos backup dele.

DataFile : O DataFile é onde são armazenados as informações do banco de dados. Tanto os dados dos usuários como os dados interno do Oracle - dicionário de dados - são armazenados nestes arquivos.

RedoLog : Log de redo é um conjunto de arquivos que guardas as últimas operações de um banco de dados Oracle, no mínimo é preciso ter 2 arquivos desse, e as operações ocorrem de modo síncrono, ou seja guarda as informações no 1º arquivo depois no 2º, quando termina o Oracle sobrescreve o 1º arquivo. Quando ocorre algum uma falha, para recuperar a consistência do banco de dados ele usa o Log de Redo. Porém se por algum motivo for preciso restaurar um o algum arquivo ou o mesmo o banco de dados inteiro, será preciso usar os logRedo e/ou os Log que foram sobre-escrito, mas guardo em algum local no disco, o chamado archive, que será explicado mais para frente.

Operação na Database

Toda operação que ocorre no banco de dados, a operação é registrada a nível de instância em uma área da memória chamada Redo Log Buffer e de tempo em tempo o conteúdo deste Buffer é aplicado no arquivo ativo do Redo log. Também quando ocorre um commit o Oracle obrigatoriamente aplica o que está no Buffer no RedoLog.

Isso significa que o Oracle não grava de imediato nos DataFiles as operações do banco. Outro processo que é responsável de transferir o conteúdo do RedoLog para o DataFile. O algoritmo de gravação do Buffer paraRedoLog é extremamente rápido, ao passo que do RedoLog para DataFile é "preguiçoso". Nunca os dados que estão gravados no RedoLog são sobre-escrito antes de serem replicados para os DataFiles e opcionalmente (obrigatoriamente em produção) para algum local no disco - o chamado archive.

Um fato a ser percebido é que a gravação no RedoLog representa um gargalo de desempenho do Oracle, ele é um funil, nunca um commit será mais rápido do que o processo de escrita do Buffer para o RedoLog. E se necessário o banco trava até os processos responsáveis por replicar o conteúdo do RedoLog nos datafiles e arquivar o conteúdo no disco. Este é um ponto a ser avaliado em questão de performance do banco de dados Oracle.

Entendo o que é Backup Oracle

Um banco de dados pode guardar uma enorme quantidade de dados e por isso são feitos backups do banco de dados. Os backups são cópias de segurança, que deverão ser usados caso ocorra alguma falha no software ou hardware que venha a gerar inconsistência da informação.

O SGBD Oracle oferece uma variedade de procedimentos e opções de backup que ajudam a proteger um banco. Quando adequadamente implementada, essas opções permitirão que se faça a recuperação da base de dados.

O Banco de dados Oracle oferece backups lógicos, backups físicos e os backups incrementais. Estes são os tipos de backup que o Oracle faz independente da plataforma (Sistema Operacional) que estiver rodando.

Um backup lógico envolve a leitura de um conjunto de registro do banco de dados e a gravação deste em um arquivo. Este tipo de backup geralmente não é a primeira opção para a restauração de um banco de dado. Contudo é ideal quando se deseja recuperar objeto(s) especifico a nível lógico, como tabelas, views entre outros.

O backup físico envolve a cópia dos arquivos que constituem o banco de dados Oracle. Em geral é a opção mais usada, pois caso ocorra uma falha em apenas um dos arquivos de dados do banco é possível fazer uma restauração e a recuperação apenas deste arquivo, gerando assim menos tempo de indisponibilidade do SGBD. É possível fazer backup's a nível de Sistema Operacional com os comandos cp ou copy, contudo este tipo de backup só é considerado consistente com o banco desligado normalmente. Entretanto o RMAN é a ferramenta mais usada para realizar este tipo de backup, e em conjunto o modo archive é perfeitamente recuperável um banco mesmo tendo backup's inconsistente feito com o banco aberto e disponível para os usuários.

O backup incremental também é um backup físico. Consiste em fazer um backup das transações que ocorreram após o ultimo backup completo, opção disponível quando o banco esta no modo archive que os backups sendo feito pelo Rman.

Protegendo um Banco de Dados Oracle

                                                Multiplexação do ControlFile e LOG de Redo

Como um ControlFile é muito importante a primeira ação a ser feita é a Multiplexação dele. Para isso é preciso desligar o banco de dados.

Multiplexação é a processo de espelhamento, muito usado em disco, o chamado RAID, este processo é feito via hardware, mas neste caso a multiplexação é feito via o software do Oracle e é uma solução para quem não tem como adquirir espelhamento em discos com RAID.

Realize a consulta ”select name from v$controlfile” para saber a localização do ControlFile.

Depois baixe o serviço do Oracle. Logado com SYS execute - shutdown immediate depois faça a copia do arquivo ControlFile.

Feito isso, cola o arquivo em algum diretório, neste exemplo foi criado o diretório “c:\oracle\espelhoControlFile”  e incluir três copias do arquivo. É importante saber que todos os controlfiles devem ter nomes distintos e que o Oracle somente usa um dos arquivos, mas cada alteração feita no controlfile é refletida nos arquivos espelhos. O ideal é que cada copia fique em discos diferentes, mas mesmo que tenha apenas um disco na maquina é aconselhado a criação das copias do controlfile e pelo menos em diretórios diferente como neste exemplo.

É preciso informar ao Oracle a localização dos espelhos do controlFile, para isto acesse  o arquivo de texto INIT.ORA que por padrão fica localizado em “C:\oraclexe\app\oracle\product\10.2.0\server\config\scripts” e alterar o parâmetro Control_file.

Inclua a localização de todos os arquivos, sendo que o 1º e o controlfile que será usado e os demais serão espelhos.

Feito isso inicie o serviço do Oracle indicando o arquivo de parâmetro, para isso execute no SQLPLUS

Startup pfile= C:\oraclexe\app\oracle\product\10.2.0\server\config\scripts\init.ora

Depois disso realize a consulta do controlfile para ver que o banco de dados já tem ciência da copia dos controlfile. Para não precisar subir o banco pelo arquivo init.ora, recrie o SPFILE a partir do pfile.

Se preferir pode alterar o parâmetro pelo SPFILE e depois desligar o banco de dados, copiar os novos controlfile e depois iniciar o banco de dados:

alter system set control_files =
'c:\oraclexe\oradata\XE\control.dbf’,
 'c:\oracle\EspelhoControlFile\control01.ctl',
'c:\oracle\EspelhoControlFile\control02.ctl',
'c:\oracle\EspelhoControlFile\control03.ctl',
 scope = spfile;

 Outro tipo de arquivo que suporta o recurso de multiplexação é o LOG de Redo. Como dito anteriormente o LOG de REDO grava todas as ultimas ações realizada no banco de dados e por isso é importância para recuperação de instância. No mínimo existe dois grupo de LOG de REDO com um membro.

Ao realizar o SQL “select * from v$logfile”, percebe que o Oracle XE vem de fábrica com a configuração mínima, e totalmente insegura, ou seja apenas dois grupos e um arquivo por grupo. Para multiplexar, adicionando membros aos grupos, pasta executar o comando abaixo.

 alter database add logfile member 'C:\ORACLE\ONLINELOG\MEMBRO02.log' to group 1;
 alter database add logfile member 'C:\ORACLE\ONLINELOG\MEMBRO02.log' to group 2;

As mesmas recomendações do controlfile são válidas para o LOG de REDO, se tiver mais de um disco, coloque cada membro em disco separado.

Cada membro serão identicos, assim caso no momento do recover a chance de perder dados minimiza, pois terá vários arquivos que contém as ultimas alteração de dados.

                                                         Trabalhar no Modo Archive

Archive log mode ou Modo de Registro de Arquivamento é um do recurso que cópia o conteúdo do LOG de REDO para outro destino antes deste ser sobrescrito por novas entradas de dados.  Pode-se gravar em até 10 destinos diferente, talvez seja um excesso, mas pelo menos 2 destino um local e outro remoto é primordial para recuperação do banco de dados.

Para conseguir realizar operações fora dos discos locais, é preciso mudar o serviço Oracle no Windows. Por padrão, no Windows o serviço Oracle roda com privilégios de usuário administrador da maquina local, com isso qualquer tentativa de backup e/ou Arquivamento do LOG de REDO fora da maquina local, ocasionará erro de privilégios. Logo, no serviço do Oracle e do Listener altere o Log On de Conta Local para uma conta de Rede.

Feito isso configure o Banco de Dados para modo Achive e dois destinos, um local outro remoto:

1-Conecte com SQL*Plus com usuário SYS com privilegio de SYSDBA.

SQL> connect / as sysdba

2-Sete dois diretório de destino. Note que é necessário incluir uma barra no final do nome do diretório.

           SQL> alter system set log_archive_dest_1='location=C:\bck_oracle\Archive\' scope=spfile;

           SQL> alter system set log_archive_dest_2='location=\\172.16.1.21\particularTI\Alessandro\bck_oracle\ARCH' scope=spfile;

3-Depois desligue, inicie no modo mount, coloque no modo archive e abra o banco.

SQL> shutdown immediate;

SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;

Para confirmar que o banco esta no modo ArchiveLog execute as query abaixos:

SQL> select log_mode from v$database;
SQL> select archiver from v$instance;

 Neste momento o Oracle está instruído para nunca sobrescrever os LOG de REDO antes de enviar o conteúdo deste para os dois destinos, isso significa que se o Oracle não conseguir arquivar o LOG de REDO ele irá parar até que resolva o problema que não permite a gravação.

Dois problemas já podem ser mapeados e ajustados aqui para evitá-los. O primeiro consiste em a área de archive encontra-se cheio e o segundo que a rede (ou a maquina remota) encontra-se indisponível.

Para evitar o primeiro problema, é preciso instruir o Oracle que apague os backup’s obsoletos. Para isso logue no rman no prompet de comando:

Rman target sys nocatalog

RMAN> configure retention policy to recovery window of 7 days;

Neste caso o Oracle guardará os backup’s e os archive necessário para restaurar o banco que qualquer tempo dentro da janela de 7 dias. O que não estiver nesta situação e considerado backup obsoleto.

Para evitar o segundo problema execute no SQL PLUS:

   SQL> alter system set log_archive_min_succeed_dest=1 scope=spfile;

 Isso irá instruir o Oracle poder sobrescrever o LOG de REDO caso apenas um destino esteja gravando, neste caso o destino local.

                                                               Conciderações

Nesta primeira parte, foi mostrado para preparar o banco de dados para a recuperação, isto é muito importante, pois em alguns casos, será decisivo se o banco de dados terá ou não recuperação. Com a multiplexção de arquivos importante como o ControlFile e o LogRedo Online, e o o processo archive, que grava em discos todo o conteúdo do  LogRedo Online, antes de sobreescrever a informação, aumenta muito a garantia que não ocorrá perdas de dados.

Na próxima parte, será apresentado a realização de backup's pelo Rman e depois alguns cenários onde será feito a restauração do banco de dados.

Transação Autônoma

Toda transação dentro do contexto de Sistema Gerenciador de Banco de Dados (SGBD) trabalha com o conceito de Atomicidade, ou seja, a transação é indivisível. Isso significa que, ou ela ocorre inteira ou não ocorre. A linguagem de programação PL/SQL da Oracle possui uma extensão não muito conhecida, Transação Autônoma, mas bem interessante e que pode ser muito útil para resolver alguns casos. Este artigo detalha a explicação teórica deste recurso, para tanto será apresentado um exemplo real de como este recurso resolveu o problema e por fim serão demonstrados alguns casos nos quais não se deve aplicar este recurso.

Fundamentação Teórica

Uma Transação Autônoma é uma transação que é inicializada por outra transação, e opera de modo independente da transação que a invocou. A transação autônoma sempre deve terminar antes de devolver o controle do processo para transação que a invocou. E se a transação autônoma terminar com commit os dados serão gravados no banco de dados ainda que e a transação principal falhe e realize um rollback.

Os programas que usam transação autônoma, também são conhecidos como programas cujo escopo opera sobre transações múltiplas. Isso aumenta a complexidade dos programas, o que implica em ter sempre certeza dos benefícios e conhecer os riscos de se trabalhar com múltiplas transações.

Os objetos seqüências do Oracle se comportam como uma transação autônoma. Ao chamar o método nextval de uma seqüência, a mesma sempre irá para o próximo valor independente do sucesso ou fracasso da transação que chamou o nextval.

Deve ficar claro que uma transação autônoma não sabe nada da transação que a invocou, então atualizações feitas dentro de um contexto de transação não serão visíveis pela transação autônoma. Caso uma transação faça inserção em um registro, e logo depois invoque uma transação autônoma e esta tente consultar o novo registro, a exceção no_data_found será lançada. Pois o novo registro está disponível apenas para primeira transação até que seja aplicado o commit na mesma.

Dentro da PL/SQL, o comportamento padrão é que os procedimentos participem de uma mesma transação, ou seja, se o procedimento "A" chamar o procedimento "B" ambos participarão da mesma sessão de transação. Logo para o sucesso da transação, os dois procedimentos devem ser executados com êxito.

Para que o procedimento "B" mude este comportamento deve ser usado o Pragma AUTONOMOUS_TRANSACTION, que sinaliza para o compilador que o procedimento “B” não irá participar da transação do procedimento “A”. O procedimento “B” operará sobre o escopo de uma nova transação, que é a transação autônoma, e antes do procedimento “B” devolver o controle para o procedimento “A”, ele deve terminar a transação.

A sintaxe é a seguinte:

create or replace procedure proc_au is

Pragma Autonomous_Transaction;

begin

<<>>

Commit;

end;

Devido a essa característica, a transação autônoma é muito usada para geração de log's. Pois para rastrear o que causou a falha em uma transação é preciso reconstruir o que a transação fez. Entretanto, se os log’s foram gerados dentro do contexto da transação que falhou, o rollback irá desfazer tudo que a transação fez inclusive os log’s. Por isso o ideal é que os log's sejam gerados a partir de uma transação autônoma.

Para criação do Log, é preciso a criação de uma tabela, que armazenará os erros decorrentes nos processos de negocio.

CREATE TABLE Log_Error

( error_id number(9) CONSTRAINT PK_error PRIMARY KEY,

processo_nome varchar2(255),

error_code number(9),

sqlerror_message varchar2(2000) ,

user_error varchar2(30),

date_error date);

create sequence SEGLog_Error start with 1

increment by 1 nocache;

Após a criação da tabela, a inserção nesta tabela do log de erro deve ser feita por um procedimento autônomo.

create procedure InsereLog(p_processo_nome Log_Error. processo_nome%type) is

Pragma Autonomous_Transaction;

v_sqlcode number;

v_sqlerrm varchar2(4000);

begin

v_sqlerrm := sqlerrm;

v_sqlcode := sqlcode;

insert into Log_Error (error_id, processo_nome, error_code, sqlerror_message, user_error, date_error)

values (seglog_error.nextval, p_processo_nome, v_sqlcode, v_sqlerrm, user,sysdate);

Commit;

end InsereLog;

/

Então esta procedure pode ser invocada dentro do controle de manipulação de exceção de um bloco PL/SQL, podendo tanto ser um bloco declarado (um objeto compilado no banco de dados) ou um bloco anônimo.

No exemplo que se segue, um bloco PL/SQL anônimo tenta executar uma transação que insere NULL em uma tabela que aceita NULL e depois tenta inserir NULL para uma tabela que não aceita NULL, ocorrendo o erro “ORA-01400” no segundo insert.

Create table TabAceitaNULL

(CampoNULL number null);

Create table TabNaoAceitaNULL

(CampoNaoNULL number not null);

begin

insert into TabAceitaNULL (CampoNULL) values (NULL);

insert into TabNaoAceitaNULL (CampoNaoNULL) values (NULL);

exception

when OTHERS then

InsereLog(‘Erro ao inserir nas tabelas TabAceitaNULL e TabNaoAceitaNULL’);

raise;

end;

/

Ao executar o bloco anônimo supracitado, a transação falhará na segunda instrução insert, ocorrerá então um rollback, que desfará tanto o segundo como o primeiro insert. Contudo o LOG não será desfeito, pois não participou da transação principal na qual ocorreu o erro.

Ao realizar consulta sobre as tabelas TabAceitaNULL e TabNaoAceitaNULL estarão vazias, e ao consultar a tabela Log_Error é possível ver os log’s dos erros.

Outro ponto a ser comentado é que comumente, os desenvolvedores utilizam procedimentos para realizar atualizações no banco de dados, e as funções ficam limitadas a consultas ou cálculos. Isso porque os procedimentos eram a única forma de aplicar alterações no banco de dados. A partir da versão Oracle 10g funções podem realizar alterações no banco de dados e sendo elas autônomas ou não.

Contudo as funções não autônomas que realizam operações dentro do banco de dados ainda não poderão ser chamadas a partir de uma instrução de SELECT, caso isso seja feito irá ocorrer o erro “ORA-14552”. Contudo se a função abrir uma transação autônoma, ela poderá ser usada em instrução SELECT. Este comportamento é exatamente igual aos objetos seqüências.

Cenário do problema e resolução

Empresas que tem um grande volume de boletos a serem pagos pelos clientes usam a troca de informações de cobrança em rede bancaria. E seus sistemas devem gerar boletos para que os clientes possam pagar o título na rede bancaria. Estes boletos devem conter o "nosso número", informação que a rede bancaria usa para identificar quais boletos foram liquidados.

Em geral o “nosso número”, que os estabelecimentos bancários usam, é um número dentro de uma faixa numérica. O valor da faixa numérica pode variar de banco para banco, além disso, existe o digito verificador que é baseado no calculo do Módulo 11 e entre outros detalhes. Contudo apenas para simplificar e a titulo de ilustração, a faixa numérica seria do número 1 a 9999999 pelo banco "A".

Então em uma empresa que possui várias filiais, cada filial tem a sua carteira de cobrança e por sua vez gera os boletos. Para cada boleto gerado, o "nosso numero" tem que ter o valor numérico igual ao do boleto antecessor acrescido de um, então o analista criou uma tabela para guardar o valor atual da carteira de cobrança:

create table carteira_cobranca

( codbanco integer not null,

codcedente integer not null,

nossonumero integer not null);

Cada linha da tabela seria uma carteira de cobrança que guarda o código do banco, o código cedente e o valor atual do “nosso número”, o analista pensou assim para não precisar criar seqüências no Oracle. Isso porque toda vez que se cria uma carteira nova, uma nova seqüência precisaria ser criada, solicitando ao DBA a criação da mesma.

Se uma empresa tem, por exemplo, 50 filiais e trabalha com 5 bancos diferentes então teríamos 250 carteiras. E se esta empresa desejasse trabalhar com algum outro banco, mais 50 carteiras de cobrança seriam necessárias. Este fato inviabiliza a manutenção (uma vez que é faixa numérica e o nosso numero precisa ser reiniciado) e a nomeação das seqüências.

Uma vez criada a tabela, em seqüência cria-se uma função PL/SQL que retorna o nosso numero, um código simplificado segue abaixo:

create function nosso_numero(p_codbanco in carteira_cobranca.codbanco%type,

p_codcedente in carteira_cobranca.codcedente%type)

return number is

v_nossonumero carteira_cobranca.nossonumero%type;

begin

-- Altera o nosso numero e retorna o sequencial...

update carteira_cobranca c

set c.nossonumero = nossonumero + 1

where c.codbanco = p_codbanco

and c.codcedente = p_codcedente

returning c.nossonumero into v_nossonumero;

return v_nossonumero;
end;

/

Vale lembrar que em um sistema real, essa função precisaria checar se o nosso número não chegou ao valor máximo disponível da faixa, e reiniciar a contagem, mas isso foi suprimido, pois o foco deste artigo é o bloqueio que ocorre da instrução UPDATE.

O problema surge quando o departamento financeiro precisa gerar um lote de boletos para uma determinada carteira, e então enquanto não terminar o processamento do lote com um Commit ou Rollback, os operadores de frente de caixa não conseguem gerar novos boletos desta mesma carteira. Devido ao bloqueio que ocorre na função nosso_numero que impede alterações no registro da carteira de cobrança.

Este é o comportamento padrão no controle de concorrência de banco de dados, para que o banco de dados garanta o I do ACID, que é o Isolamento de transações, o SGBD usa o recurso de bloqueio sobre a linha alterada e as transações ocorrem seqüenciais sobre esta linha. Primeiro é executada uma transação e só depois do termino da primeira é executada a segunda.

E é exatamente nestas situações que a transação autônoma pode ser uma excelente ferramenta. O bloqueio na tabela carteira cobrança iria somente ocorrer dentro da função nosso_numero e não dentro da transação de geração em lote dos boletos.

A função seria reescrita da forma abaixo:

create or replace function nosso_numero(p_codbanco in carteira_cobranca.codbanco%type,

p_codcedente in carteira_cobranca.codcedente%type)

return number is
Pragma Autonomous_Transaction;

v_nossonumero carteira_cobranca.nossonumero%type;

begin

-- Altera o nosso numero e retorna o sequencial...

update carteira_cobranca c

set c.nossonumero = nossonumero + 1

where c.codbanco = p_codbanco

and c.codcedente = p_codcedente

returning c.nossonumero into v_nossonumero;

commit;

return v_nossonumero;
end;

/

Nesse exemplo se o departamento financeiro fosse gerar um lote com 1000 boletos e após gerar uns 5 boletos, sendo o último com o nosso número igual a 150 e neste instante algum operador do caixa gerasse um boleto, então o operador de caixa iria gerar o boleto com nosso número 151 e o 6 boleto gerado pelo lote do departamento financeiro iria gerar o nosso número 152. Com isso teríamos o comportamento bem parecido com os objetos seqüência do Oracle, melhorando assim o controle de concorrência e evitando bloqueios (locks).

Quando não usar uma transação Autônoma

Como explicado uma transação Autônoma, é uma transação que não participa da transação do procedimento que a invocou. Em um bom projeto de software uma grande tarefa tem suas responsabilidades divididas por vários objetos e seus métodos.

Fazendo uma co-relação que classes de objetos sendo pacotes do PLSQL e os métodos sendo funções e procedimentos, então em uma grande tarefa, vários procedimentos de vários pacotes poderiam ser invocados para realizar essa tarefa que por sua vez é atômica.

Considere o caso de um livro-razão contábil. Em termos contábeis, é impossível fazer este processamento parte em um período e parte em outro, de modo que o processamento em bloco a cada fim do mês é uma transação de negócio indivisível. Caso algum procedimento/função for autônoma ela irar gravar sua operação no banco de dados mesmo se a tarefa como um todo falhar. Então teríamos uma inconsistência de informação.

Outra situação na qual não se deve usar transação Autônoma é em trigger para resolver problema de tabela mutante. Em fóruns o consenso é que o problema seja resolvido adicionando o Pragma Autonomous_Transaction .

Usar este pragma em trigger também quebra o conceito de atomicidade da transação, pois todo operação feita dentro da trigger também irá ser gravado no banco de dados mesmo se a transação como um todo falhe.

Considerações finais

Toda ferramenta antes de ser usada deve ser conhecida, a transação autônoma não é exceção a esta regra. A Transação autônoma pode resolver problemas reais, contudo se usada de forma indiscriminada pode causar problemas.

Neste artigo, foi apresentado até um certo nível de detalhe do comportamento de transação autônoma, contudo detalhes mais profundos sobre o assunto e exemplos sobre este recurso, podem ser encontrados no livro “Oracle Database 11g PL/SQL Programming”.