Archivelog Mode no Oracle

[rotulo-mentoring/]

[lead-mentoring] Algumas estratégias são necessárias para garantir a máxima recuperabilidade do banco de dados Oracle em caso de falha, seja ela de instância ou mesmo de hardware. Uma dessas estratégias é assegurar que o banco opere em Archivelog Mode de forma que todas as alterações efetuadas nele possam ser reproduzidas em um momento de recuperação da instância do banco. Essa técnica permite também a execução de rotinas de backup quente, que garante que não haja paradas de banco de dados sequer para efetuar o backup. Nesse contexto, este artigo apresenta como devemos proceder para criar uma solução de recuperação de dados utilizando o Archivelog Mode no Oracle. [/lead-mentoring]

A estrutura de Redo Log é uma das principais quando se trata em recuperação de dados. É composta por dois ou mais arquivos externos ao banco de dados (os Redo Log files), que armazenam toda e qualquer alteração efetuada no banco de dados. O conjunto de Redo Log files está associado a uma única instância de banco de dados para protegê-lo em caso de falha da instância.

O conjunto de Redo Logs também é conhecido como Redo Thread e, quando descrevemos um ambiente standalone, ou seja, onde há apenas uma instância acessando o banco de dados, haverá apenas uma thread. No entanto, ao considerarmos um ambiente RAC (Real Application Cluster), teremos duas ou mais instâncias acessando o mesmo banco de dados e, para evitar problemas de contenção nos arquivos e consequentes problemas de performance, haverá uma thread para cada instância, ou seja, um conjunto de Redo Log files para cada instância do ambiente RAC.

Mas afinal, o que é armazenado nos Redo Logs? Todas as alterações executadas no banco de dados, tanto DMLs (Data Manipulation Language – insert, update, delete) quanto DDLs (Data Definition Language – create, alter etc.), são armazenadas no arquivo de Redo Log. Não se trata do bloco de dados ou dos valores alterados nas tabelas, mas de uma entrada de Redo Log, ou seja, o registro do que foi alterado no banco de dados. Esse contém informações que permitem ao DBA reconstruir as alterações que tenham sido efetuadas no banco, porém foram perdidas em caso de falha da instância. Ao recuperar um banco de dados utilizando os Redo Logs, o banco de dados “lê” as entradas de Redo Log e as executa, reconstruindo assim as alterações que não haviam sido persistidas no data file, trazendo o banco para o momento consistente mais próximo do crash.

Todos os registros de Redo Log são armazenados primeiramente em memória, em uma região da SGA (System Global Area) conhecida como Redo Log buffer, de maneira circular. Em determinados momentos, o processo em segundo plano chamado LDWR (Log Writer) “escreve” esses registros no Redo Log file. Mesmo antes de uma transação ter sido efetivada (commit), o registro referente a ela é armazenado no Redo Log e caso não seja efetivada ou haja uma queda de instância antes do commit, no momento da recuperação um rollback será executado para garantir a consistência dos dados. Vale salientar também que o usuário somente receberá a mensagem de confirmação de um commit após o banco de dados se assegurar de que a informação referente à transação já se encontra no Redo Log file e não somente no Redo Log buffer.

É necessário, no mínimo, dois arquivos para formar o Redo Log, ou seja, dois Redo Log files, pois precisa-se garantir que um dos arquivos esteja sempre disponível para gravações enquanto o outro esteja sendo arquivado (caso o banco de dados esteja operando em Archivelog Mode).

Da mesma forma que o Redo Log buffer, o processo LGWR escreve as informações nos Redo Log files de maneira circular, ou seja, quando o Redo Log file corrente é completamente preenchido (todos possuem um tamanho, por exemplo, 100MB) o LGWR inicia a gravação no próximo Redo Log file disponível. Quando o último Redo Log file é preenchido completamente, o LGRW retorna para o primeiro "