4Dados Consultoria & Suporte

Oracle Partner Network

Habilitando Archived Logs

Nesse artigo falaremos sobre um assunto muito importante, os ARCHIVED LOGS.

Compreenderemos sua utilidade, como habilitá-lo e daremos alguns exemplos de como eles podem ser úteis.

Vocês lembram dos REDO LOGS? Vamos relembrar?

A maioria dos SGDB”s possuem um mecanismo de log, que armazena todas as alterações realizadas no base de dados, como por ex: insert”s, update”s, delete”s, create table. Esses eventos vão preenchendo esses arquivos de log.

No Oracle, por default, são criados 3 grupos de redologs, cada grupo com 1 membro.

A consulta abaixo, mostra a existência de 3 grupos, cada grupo com um membro.

Esta outra consulta, mostra quem são esse membros, e onde eles estão armazenados.

A utilização desses REDO LOGS é cíclica, significa dizer que, quando um REDO LOG estiver cheio, o Oracle utilizará o seguinte. No exemplo acima o GROUP 3 está CURRENT. Como ele é o último, quando estiver cheio, o banco voltará a utilizar o GROUP 1, e simplemente irá sobrescrever, se efetuar nenhuma cópia do arquivo de log INACTIVE.

Os archives se, quando configurados, fazem com que o Oracle realize uma cópia para que possa ser utilizada posteriormente em operações de BACKUP e RECOVER antes de sobrescever o REDOLOG.

No exemplo acima, a base de dados está no modo NO ARCHIVE , e a localização default de arquivamento está %ORACLE_HOME%\RDMS .

O parâmetro LOG_ARCHIVE_FORMAT é utilizado para formatar o filename do archive, normalmente o formato ARC%S_%R.%T é suficiente.

Iremos então mudar o lugar do armazenamento e em seguida habilitar archive log. Podemos ter até 10 locais diferentes de armazenamento.

Para alterar o modo para ARCHIVE LOG, devemos colocar a base de dados em modo EXCLUSIVE, utilizando o comando STARTUP MOUNT EXCLUSIVE .

Em seguida, utilizando o comando ALTER DATABASE ARCHIVELOG , vamos habilitar o arquivamento dos logs.

O comando ARCHIVE LOG LIST , agora mostra a base em modo ARCHIVE.

Se quiser confirmar a correta configuração, utilize o comando ALTER SYSTEM SWITCH LOGFILE, para forçar o arquivamento do log.

Em versões anteriores a 10g, era necessário setar o parâmetro LOG_ARCHIVE_START para TRUE .

Agora que habilitamos o ARCHIVE, vamos entender como ele pode nos ajudar a manter o ambiente.

Imagine um ambiente que funciona 8(horas)x(5)dias, quem em hipotese alguma poder existir a perca de informações, quando muito, aceita-se a perca de 30 minutos.

Se sua base está em modo NO ARCHIVE, e seu HD foi para o espaço, logo no final do dia, a única coisa que te resta, é fazer o restore FULL do último backup, e torcer para que ele esteja consistente. Imaginando que vc fez o backup na noite anterior, você vai perder ALÉM DO EMPREGO, 1 dia de movimento.

Com o ARCHIVE e um pouco de sorte, perderia apenas os REDOLOGS que não haviam sido arquivados ainda.

Por isso, aconselha-se a não colocar os archives no mesmo device da base de dados (CONTROLFILES, REDOLOGS, DATAFILES), além de que esse processo gera uma carga de I/O adicional.

Até o próximo artigo!!!