Olá, meus caros!

Recentemente passei por um problema na empresa onde trabalho e achei um tema interessante para se abordar aqui no blog. Resumidamente a situação foi a seguinte: um dos servidores de banco de dados foi inesperadamente desligado, e quando a máquina foi ligada, no momento em que tentávamos “levantar” uma instância, não foi possível pois um dos arquivos de redo log estava corrompido. Foi uma situação muito tensa, pois era uma base importante para o negócio da empresa. Não vou entrar no detalhe do que aconteceu, tampouco falar da solução, mas motivado pelo problema ocorrido vou falar hoje um pouco sobre redo log file e archive.

Bom, pessoal...

Para começar, acho de extrema importância conhecermos algumas estruturas do banco. São elas: log buffer, log writer e archiver. Basicamente, o primeiro (log buffer) é uma área de memória pequena onde são gravadas instruções de desfazer uma alteração (comando DML) disparada contra a base, antes de essa instrução ser gravada no disco (no redo log file). Eu escrevi algo sobre essa estrutura com um pouco mais de riqueza no artigo: [Hard Parse]Parte 01 - Execução de comandos DML. O log writer é o processo de background responsável pela gravação do conteúdo do log buffer no redo log file. O archiver também é um processo de background, porém sua existência está condicionada a uma configuração da instância (ARCHIVELOG). O archiver copia o conteúdo dos arquivos de redo log (que são arquivos cíclicos e reutilizáveis – falarei melhor sobre isso) em arquivos chamados de archives (ou redo log arquivado). Cada uma dessas estruturas podem ser alvo de bastante discussão e conteúdo, que não focarei nesse post, mas é importante que entendamos ao menos o básico para não nos atrapalharmos mais adiante em outras explicações.

Redo Log File

Esse arquivo é uma cadeia contínua e cronológica de cada vetor de alteração (“instruções” para desfazer um DML de alteração – insert, update, delete). Uma utilidade de fácil entendimento desses arquivos é na recuperação de uma base após um problema que necessite “voltar” o backup. Para que não haja perda de trabalho até o momento do crash ou erro, os arquivos de redo log podem ser aplicados ao backup para refazer o trabalho, adiantando-os no tempo até o momento em que o dano ocorreu.

John Watson afirma que o redo log pode ser dividido em dois tipos: redo log online e o redo log arquivado (os archives).

Cada banco de dados deve ter por definição pelo menos dois redo log online. Arquivos de redo log compõe um grupo de arquivo, e são conhecidos como membros. Um banco de dados requer ao menos dois grupos com pelo menos um membro para funcionar. Para um melhor desempenho, podem ser criados mais de dois grupos, e para uma maior segurança, deve-se criar mais de um membro por grupo (caso opte por essa configuração não é necessário se preocupar com desempenho ou sincronismo, pois o processo responsável irá gravar em todos os membros de forma paralela mantendo-os idênticos). A razão do requisito mínimo para o banco Oracle funcionar ser um mínimo de dois grupos é devido à situação de que enquanto um dos grupos (o de status current) está recebendo as alterações (através de comando do processo de background Log Writer – LGWR), o outro está sendo “arquivado” (pelo processo de background Archiver – ARCn), ou seja, está sendo gerado um Archive a partir de um Redo Log File com status inactive. Um passo a passo do processo pode ser o seguinte: ao tempo em que as sessões dos usuários atualizam registros (no buffer cache), elas também gravam vetores de alterações mínimos no redo log buffer, e o LGWR continuamente grava os dados desse buffer para os arquivos que compõem o grupo de arquivos de redo log atual (com status current). Por serem de tamanhos limitados, os redo log se alternam quando estiverem completamente cheios, tornando o outro grupo o atual. Se o banco de dados estiver configurado para gerar Archive (o que é uma segurança para que não haja perda de dados), os processos ARCn arquivarão (ou copiarão) os membros do redo log file que compõe o primeiro grupo. Quando o segundo grupo é totalmente preenchido, o LGWR mudará de volta para o primeiro (setará seu status como current) e irá sobrescrever seu conteúdo (que já foi arquivado), ao mesmo tempo, o ARCn começará a arquivar o segundo grupo (de status inactive). Basicamente é dessa forma que se dá esse processo, de forma cíclica (alternância de log) e reutilizando os membros dos grupos de redo log file.

É importante saber que é possível adicionar ou excluir redo log files (inclusive com tamanhos diferentes dos demais) a qualquer momento, sem a necessidade de reiniciar a instância.

Para criar um novo grupo de redo log file, podemos usar o comando abaixo:
ALTER DATABASE ADD LOGFILE ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

Ou criar um novo grupo especificando o seu número:
ALTER DATABASE ADD LOGFILE GROUP 10 ('/oracle/dbs/log1c.rdo', '/oracle/dbs/log2c.rdo') SIZE 4M;

E para adicionar um membro a um grupo, podemos utilizar o comando
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2b.rdo' TO GROUP 2;

Ou de uma forma alternativa de identificar um grupo, que é identificando seus membros, conforme exemplo abaixo:
ALTER DATABASE ADD LOGFILE MEMBER '/oracle/dbs/log2c.rdo' TO ('/oracle/dbs/log2a.rdo', '/oracle/dbs/log2b.rdo');

Para excluir um grupo do redo log file, segundo a Oracle, existem três restrições. São elas:
 - É necessário que a mais de dois grupos de redo log file, para após a exclusão ainda existirem o mínimo aceitável pelo banco de dados Oracle (conforme explicado anteriormente);
 - Só é possível excluir grupos de redo log com status inactive. Para excluir o grupo atual (current), é necessário primeiro alternar o log para torná-lo inactive.
 - Tenha certeza que o redo log file foi arquivado (se estiver no modo archive) antes de excluí-lo. Na view V$LOG é possível verificar se já ocorreu o arquivamento.

O comando da exclusão é o seguinte:
ALTER DATABASE DROP LOGFILE GROUP 3;

Para excluir um membro, deve-se atender aos requisitos citados para o grupo pois seguem as mesmas restrições. a Sintaxe é a seguinte:
ALTER DATABASE DROP LOGFILE MEMBER '/oracle/dbs/log3c.rdo';

Para forçar que o banco alterne o grupo de redo log atual, podemos utilizar o comando:
ALTER SYSTEM SWITCH LOGFILE;

Archive

Vamos falar um pouco sobre o tal redo log file arquivado, ou archive.

O banco Oracle garante que sua instância nunca fique corrompida, por meio dos redo log files, porém para garantir que não haja perda de dados após uma falha, é necessário ter um registro de todas as alterações aplicadas ao banco de dados desde o último backup. Por default, um banco de dados é criado em modo NOARCHIVELOG, o que significa que os redo log files são sobrescritos sem que tenha ocorrido o arquivamento dos seus dados. Quando alteramos o banco para o modo ARCHIVELOG, a Oracle afirma que é impossível que ocorra perda de dados (desde que os archives gerados após o último backup estejam disponíveis. Nesse modo, um novo processo de background (na verdade são quatro processos por default) será iniciado automaticamente: o Archiver (ARCn), isso nas versões do Oracle a partir do 10G.

É importante saber que a transição do modo NOARCHIVELOG para ARCHIVELOG (ou o contrário) só pode ser feita enquanto o banco está no modo mount após um shutdown e deve ser feito por um usuário com privilégio SYSDBA. Também é necessário fazer a configuração nos parâmetros de inicialização que controlam os nomes e os locais dos archives.

Para habilitar o modo ARCHIVELOG, podemos usar os comandos abaixo:
SQLPLUS /NOLOG
CONNECT / AS SYSDBA
ALTER SYSTEM SET LOG_ARCHIVE_DEST_1=’LOCATION=/oracle/dbs/archives’ SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
ALTER DATABASE ARCHIVELOG;
ALTER DATABASE OPEN;

Bom pessoal…

Por hoje é isso!

Espero ter ajudado no entendimento sobre o redo log file do Oracle e o Archive.

Grande abraço a todos e até a próxima.

Referências:

Oracle® Database Administrator's Guide - 11g Release 1 (11.1) - Creating Redo Log Groups and Members. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo003.htm. Acessado em 03/05/2013.

Oracle® Database Administrator's Guide - 11g Release 1 (11.1) - Dropping Redo Log Groups and Members. Disponível em: http://docs.oracle.com/cd/B28359_01/server.111/b28310/onlineredo005.htm. Acessado em 03/05/2013.

WATSON, JOHN – OCA Oracle Database 11g – Administração I – Guia do Exame 1z0-052. Editora: BOOKMAN.