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!!! |
Últimos Artigos
- Serviços de Upgrade e Migração
- Recuperação de datafiles e tablespaces
- Oracle Real Application Cluster(RAC)
- Oracle Data Guard
- Monitorando Tablespace Temporária
- Monitorando o progresso do RMAN
- Monitorando a utilização da tablespace de UNDO
- Linux
- Habilitando Archived Logs
- Cursores abertos por uma determinada sessão
Habilitando Archived Logs
|