Como se precaver da perda de dados ocasionada por uma falha de disco
Antes de começarmos a explorar sobre os dois modos que o banco de dados Oracle pode operar, você terá uma breve descrição, sem entrar em muitos detalhes, sobre o que é o arquivo de redo log online e para que ele serve.
Bom, o registro de redo online, também conhecido como grupo de redo (refazer), é um conjunto de no mínimo dois ou mais arquivos que tem como função primária registrar todas as alterações feitas no banco de dados, incluindo as alterações com e sem commit. As entradas de redo são armazenadas temporariamente nos buffers de registro de redo (Redo Log Buffer) da SGA (System Global Area) onde o processo de segundo plano log writer (LGWR) grava essas entradas seqüencialmente em um arquivo de registro de redo online.
Estas gravações do buffer de redo para os arquivos ocorrem nas seguintes cinco situações: (1) a cada 3 segundos, (2) quando 1/3 do buffer estiver cheio, (3) quando o comando commit for emitido, (4) quando as entradas de redo no buffer atingir 1 MB, (5) antes do processo de segundo plano DBWn gravar as alterações do cache de banco de dados nos datafiles. Os arquivos de redo log online são utilizados de forma cíclica, por exemplo, se dois arquivos constituem o registro de redo online, o primeiro arquivo é preenchido, o segundo arquivo é preenchido, o primeiro arquivo é reutilizado e preenchido, o segundo arquivo é reutilizado e preenchido e assim por diante.
Cada vez que um arquivo é preenchido, ele recebe um número de seqüência de registro para identificar o conjunto de entradas de redo. As informações de um arquivo de redo log online são usadas apenas para proteger e recuperar o banco de dados em caso de uma falha de instância que evite que os dados em memória sejam gravados nos datafiles. Assim, caso uma falha evite que os dados modificados em memória (comitados) sejam gravados permanentemente nos datafiles, as alterações perdidas possam ser obtidas dos arquivos de redo log online através de um processo de recuperação (recover).
Em resumo, comitar uma transação significa apenas a garantia de sua recuperação, em caso de falha, e não a gravação dos dados diretamente nos datafiles como muitos pensam. Esta é a 4ª propriedade dentre as conhecidas sobre segurança e integridade dos dados (ACID) que trata da DURABILIDADE e persistência das atualizações confirmadas, mesmo que haja falhas no sistema.
Modos de Operação do Oracle
Um banco de dados Oracle pode ser operado nos modos ARCHIVELOG, também conhecido como modo de arquivamento, ou NOARCHIVELOG onde não há arquivamento. Mas, o que significa isso? Bem, no modo NOARCHIVELOG, os registros de redo online não são arquivados (copiados) e o processo de segundo plano log writer process (LGWR) recicla os registros de redo online, sobregravando os grupos de registro de redo preenchidos. Quando o banco de dados é operado no modo ARCHIVELOG, o Oracle arquiva (realiza uma cópia do arquivo) os registros de redo log online antes que o processo de segundo plano log writer os reutilize.
Qual é a vantagem em operar o banco de dados no modo de arquivamento?
Em primeiro lugar, o modo ARCHIVELOG permite que você recupere o banco de dados completamente até o ponto no tempo em que a falha ocorreu. Digamos que você use o modo NOARCHIVELOG e feche o banco de dados todas as noites às 20:00 horas, para fazer um backup frio completo (Cold Backup Offline), sendo que essa é a única opção de backup físico para um banco de dados no modo NOARCHIVELOG. Na manhã seguinte, os usuários fazem o logon no banco de dados às 08:00 para executar as transações.
Imagine que o banco de dados armazene informações de um sistema de reservas de passagens aéreas. Se uma corrupção nos arquivos de dados do tablespace SYSTEM afetou o banco de dados às 17:00 horas, por exemplo, suas opções se limitam a restaurar completamente o cold backup da noite anterior. Nesse cenário, você perde todas as transações feitas no banco de dados das 08:00 às 17:00, o que o leva o DBA a usar o cold backup da noite anterior (isso assumindo que você tenha um bom backup da noite anterior). Se este backup não estiver bom (digamos que o backup está corrompido ou a instância abortou em vez de fechar normalmente como deveria, ou até mesmo, você esqueceu de fechar o banco de dados antes de realizar a cópia, o que invalida o backup), então você perde mais transações ainda até o ponto no tempo do último backup bom disponível.
Agora, imagine a situação do administrador do banco de dados na hora em que ele tiver que informar aos usuários ou até mesmo, ao seu superior, que todos os dados informados no dia foram perdidos. Vamos supor que isto signifique a perda das informações de reservas de 300 passageiros. Um desastre total!
Esse foi o cenário do modo sem arquivamento. Agora vamos ver outro cenário, no qual tudo é igual ao primeiro, exceto pelo fato do banco de dados estar operando no modo ARCHIVELOG. Às 17:00 horas, o arquivo de dados do tablespace SYSTEM é corrompido e a instância dá pane. Você pode restaurar os arquivos de dados do tablespace SYSTEM a partir do backup da noite anterior e depois recuperar os arquivos de dados aplicando os registros de redo arquivados (archive logs). Nesse caso, você pode recuperar o banco de dados totalmente até o ponto no tempo da falha. Mas, e se o backup da noite anterior não estiver bom? Não tem problema. Desde que você tenha um bom backup e todos os registros de redo log arquivados do ponto no tempo em que o último backup foi feito, você pode recuperar totalmente o banco de dados, restaurando o datafile perdido do último backup bom e aplicar todos os arquivos de redo log arquivados.
Em segundo lugar, o uso do modo de arquivamento permite muito mais flexibilidade nas escolhas das opções de recuperação. Você pode optar por recuperar todo o banco de dados até um ponto anterior no tempo, digamos, imediatamente antes de um DBA trainee ter dropado o tablespace USERS. Você também pode executar uma recuperação point-in-time para recuperar um objeto específico, digamos, uma tabela muito importante que foi dropada acidentalmente, ou até mesmo uma alteração errônea (update, delete) que foi confirmada (commit) em uma tabela com um milhão de registros.
No caso de um banco de alta disponibilidade que deve estar disponível para acesso o tempo todo (ou quase isso), o modo ARCHIVELOG é a única opção razoável porque possibilita a realização de backups online (hot backups) enquanto o banco de dados está disponível para os usuários, e permite executar a recuperação online em alguns cenários de recuperação.
Concluindo, o uso do modo ARCHIVELOG permite que você lide com os vários cenários diferentes dando-lhe maior flexibilidade e mais opções para executar a recuperação do banco de dados. Entretanto, operações administrativas adicionais do administrador do banco de dados são necessárias para manter os arquivos de redo log arquivados protegidos e sempre disponíveis.
Em algumas situações especiais, porém, você pode preferir usar o modo NOARCHIVELOG, na qual o banco de dados pode ser recuperado completamente da falha de instância, mas não da falha de disco. Elas incluiriam as circunstâncias em que o banco de dados no qual a perda de dados seria tolerado, ou onde os dados poderiam ser facilmente recriados. Um exemplo disso poderia ser um banco de dados de teste usado por uma equipe de suporte, ou até mesmo um banco de dados usado para desenvolvimento de sistemas. Da mesma forma, o banco de dados pode ter backup apenas enquanto ele estiver completamente fechado. Como nenhum registro de redo arquivado é criado, nenhum trabalho extra é requerido pelo administrador do banco de dados para a recuperação em caso de falha.
O Analisador de Registro LOGMINER
Embora o Oracle 10g tenha a tecnologia de FLASHBACK na qual usa logs de flashback para permitir ao DBA a capacidade de recuperar versões de objetos de schemas e dados históricos do passado, uma outra vantagem de se operar o banco de dados no modo de arquivamento, é a de ter a possibilidade de se utilizar uma ferramenta relacional que permite ler, analisar, e interpretar não só os registros de redo log online, mas também, os arquivos de redo log arquivados usando a SQL. A análise dos arquivos de registro de redo com o LOGMINER pode ser usada para:
- Controlar os conjuntos específicos de alterações baseadas na transação, usuário, tabela, tempo e assim por diante. Você pode determinar quem modificou um objeto do banco de dados e como eram os dados do objeto antes e depois da modificação. A habilidade de controlar e fazer auditoria das alterações de banco de dados de volta à sua origem, e desfazer as alterações fornece a segurança e o controle de dados.
- Destacar quando uma modificação incorreta foi introduzida no banco de dados. Isso permite a recuperação lógica no nível de aplicativo, em vez de executá-la no nível de banco de dados.
- Fornecer informações suplementares para o ajuste e planejamento da capacidade. Você também pode executar a análise histórica para determinar as tendências e os padrões de acesso aos dados.
- Recuperar as informações críticas para depurar aplicativos complexos.
