Olá, como estão todos?

Bem, não é de
hoje que eu sempre vejo artigos excelentes espalhados por inúmeros blogs
de diversos técnicos impressionantes, falando sobre estruturação e
sobre como organizar as bases de dados de maneira eficiente e eficaz.

Pensando sobre
esses assuntos, eu trago até vocês hoje uma visita ao nosso passado,
pois vou falar um pouco sobre uma das estruturas que compõem o Banco de Dados, que é os Redo Log Files.

Vamos lá, então? Espero que apreciem.

Redo Log Files

Conceito: Essa estrutura localizada fisicamente em nosso Banco de Dados é a principal responsável por tornar possível refazermos uma determinada transação que possa ter sofrido algum tipo de
indisponibilidade, seja por falhas ou gaps causados por nosso ambiente.
Basicamente, em seu conteúdo estão as informações transacionadas
pelas seções e instruções executadas, preservando sempre a imagem antiga
do dado e a nova, pois em caso de queda da instance no processo de
instance recovery, são eles quem farão os chamados Roll Fowarding.

Vejam na figura abaixo uma ilustração acerca do esquema de funcionamento dos arquivos de redo log file:

Entendendo um pouco melhor a mecânica do Redo Log File

Na minha opinião, não há dúvida de que os
arquivos de redo log são umas das estruturas mais importantes existentes
no Banco de Dados. No decorrer do nosso dia-a-dia em banco
de dados damos pouca importância às maravilhas que se procedem nos
bastidores dos algoritmos Oracle que cercam as funcionalidades do nosso
Banco de Dados.

No caso dos nossos arquivos de redo, antes mesmo de serem gravados em disco, são geradas entradas no Buffer de redo, ou Redo Log Buffer,
para aqueles que estão mais acostumados com as nomenclaturas padrões do
Oracle. Só depois de realizado o comprometimento e/ou confirmação (commit) o Buffer é esvaziado, para dar lugar a novas estradas, pois nossos arquivos de Redo Log File trabalham de maneira cíclica entre os seus grupos, que por sua vez possuem seus respectivos membros.

Via de regra nós, DBAs, já
os determinamos na criação, mas há a possibilidade de adicionarmos mais
membros ou mais grupos posteriormente à criação do nosso Banco de
Dados.

Uma coisa muito
importante sobre a utilização dos arquivos de redos pelo nosso banco é
que, em caso de falhas, eles nos garantirão a recuperação até o ponto
onde eles tenham gravado a informação; por essa razão, se faz necessária a
“multiplexação” desses arquivos em diferentes locais e de preferência em hardwares distintos, porque mesmo que você os coloque em diferentes locais,
se os colocar em um mesmo disco, caso este disco seja corrompido ou apresente problemas seja lá de qual natureza for, que nos impeça de
ter uma leitura e escrita consistente neste hardware, fatalmente você
perderá seus arquivos de Redo e, com isso, terá algumas dores de cabeça
quanto a processos de Disaster Recover.

Criados em grupos
eles, são gravados um por vez pela Instância Oracle, daí se dá o
comportamento cíclico dos mesmos, como mostra a figura que coloquei
acima.

Internamente, o
Oracle grava nesses arquivos em paralelo, e é permitido e recomendado,
como mencionei, o espelhamento dos mesmo e, em caso de perda de um membro online, nenhum dado será perdido e seu Banco continuará a funcionar normalmente.

Nota
Importante: em caso de ambientes em Oracle Real Application Cluster (RAC), cada nó participante do cluster tem sua identidade de redo logs
individualmente criada; um grupo do nó 1 criado neste nó não poderá ser
criado no nó 2 com o mesmo nome. Uma outra característica importante dos redos em RAC é que há um parâmetro novo a ser passado no
comando de criação, que são os threads, eles indicaram em qual nó será
criado aquele Relog Member.

Particularidades dos Redos

Em um banco de dados Oracle é necessário que haja pelo menos dois
grupos de redo online, com um único membro em cada, porém recomenda-se
que sejam criados, no mínimo, três membros por grupo, espelhados de maneira
eficiente e lógica.

Se por ventura nós estivermos trabalhando em modo Archivelog, depois que o Oracle fechar o arquivo de redo log que está cheio, um processo interno chamado Arch é convocado a entrar na jogada para fazer seu papel, movendo todos os
arquivos de Redo Log para os seus destinos pré-determinados.

A outra opção para trabalharmos é o modo NoArchivelog, onde é solicitado ao DBwr (Db Writer) que grave todas as alterações nos respectivos datafiles antes de reaproveitar um determinado membro de redo log.

Como forma de mecanismo de autoproteção, o Oracle apenas reutiliza um membro em modo Archivelog depois que ele for integralmente gravado no destino e liberado
para uso. Essa é uma das belezas dos processos internos do Oracle que
não são visíveis. Caso não haja membros disponíveis o suficiente para
que o Oracle trabalhe dessa forma, ocorrerá uma interrupção na Base até
que o Oracle possa gravar de maneira consistente no destino, por isso é
mais uma vez importante salientar o uso de 2 ou mais membros, para
evitar esse tipo de cenário.

Determinando tamanho de Redo e realizando manutenções

Algo sempre me
ocorreu quando eu era questionado a respeito de criar um Banco novo: na
hora de definir os tamanhos dos Redo Logs era sempre um “parto” – quanto devo colocar?

Olha, sinceramente, a menos que você conheça cada “fio de cabelo”
do que conterá seu Banco de Dados, eu sugiro que você os crie com um tamanho de uns 50M, pra uma instance
mediana creio que seja o suficiente até você acompanhar os desempenhos e
os tempos de gravação e conseguir determinar um tamanho perto do “excelente” para os seus Redo Log Files.

A própria Oracle determina que as alternâncias entre os arquivos devem compreender um tempo de 15 minutos, e se elas não satisfazerem a esse requisito você deverá aumentar seus redo logs até que alcancem esse patamar de tempo.

Como criar novos grupos de Redo?

Essa é uma tarefa de administração comum, não há nada de espetacular, porém eu mesmo já me confundi “N” vezes na hora de executar esses “benditos” comandos. Vejamos como podemos proceder para criarmos um grupo de redo novo.

Antes de mais nada, defina a localização, pois será necessário checar algumas variáveis antes, como se há espaço suficiente para ele ser criado.

Feito isso, proceda da seguinte forma:

Logado com um usuário com poderes de DBA para executar essa tarefa adminsitrativa, visto que será usado o comando ALTER DATABASE, faça :

ALTER DATABASE ADD LOGFILE [THREAD x] GROUP [numero do grupo]('path do arquivo+Nome do Arquivo de log') SIZE [tamanho em mega];

Nota:
reparem que coloquei a palavra thread, como eu havia mencionado. Para
quem trabalha com RAC, após a opção group você informará o
número do novo grupo, que vai depender de quantos você já possui no seu
banco. A questão do nome é que eles devem ser com extensão .LOG por
padrão e o tamanho fica por conta do que dissemos acima.

Surge então a pergunta:

“Ok, espertão! Criei o grupo, mas agora quero adicionar mais membros. Se vira aí, como faço isso?

Antes de mais nada, tenha calma e fé! Brincadeirinha, é uma tarefa quase tão simples quanto a acima mencionada, vejam :

ALTER DATABASE ADD LOGFILE MEMBER 'PATH+NOME DO ARQUIVO.LOG TO GROUP x;

Nota: a particularidade aqui é que nós informamos, no comando, o grupo onde
ele será criado, por razões bem óbvias. É claro, observem também a opção Add LogFile. 

Bom, já vimos como criar um Grupo, como adicionar um Membro. Que tal agora vermos como remover um redo log?

Antes de prosseguirmos, é bom que fique bem claro que você não pode proceder com a remoção do grupo que estiver como current,
pelo fato de ele  estar sendo utilizado atualmente pela instância, e causaria um certo problema remover arquivos que estão sendo gravados no
momento; portanto, opere apenas nos grupos que estiverem como inactive e unused.

Caso você precise remover o grupo que está marcado como current, proceda antes com alguns LogSwitches, para forçar o esvaziamento e a troca de Arquivos e Grupos, até que o grupo desejado esteja em um dos status determinados para a remoção segura. O comando de troca é o seguinte: 

ALTER SYSTEM SWITCH LOGFILE;

Reparem na figura a situação dos Logs:

Vejam após alguns Switches o que ocorre com a coluna status:

Antes de darmos
prosseguimento, gostaria de falar das visões de apoio que usei para
obter essas informações sobre os arquivos de Redo Log:

• V$LOG – displays log file information from the control file.

• V$LOGFILE – This view contains information about redo log files.

Vamos então à remoção dos nossos arquivos de Redo.

A sintax para essa tarefa é:

ALTER DATABASE DROP LOGFILE MEMBER'PATH+NOME_DO_ARQUIVO.LOG';

Nota: reparem que a remoção do arquivo se deu sem problemas, pois ele atendia às particularidades que falamos acima.

Encontrei problemas de tamanho de Redo Log File. O que devo fazer?

Bem,
na nossa última abordagem sobre os arquivos de redo, nós vimos que era
possivel, criar, adicionar e remover membros de maneira segura e
eficaz.

Agora nós iremos ver que é possível também realizar tarefas de redimensionamento e também de limpeza de arquivos de redo.

Notadamente alguns de vocês já devem ter percebido que o Oracle não possibilita a realização do uso da cláusula Resize em Redo Log Files, portanto, para que possamos redimensioná-los, é
necessário que nós os recriemos, removendo-os e recriando-os com os devidos tamanhos.

Preciso limpar meus Redo Logs. Como devo fazer?

Antes de mais
nada, é preciso entender o porquê de realizar limpezas nos redos. Isso
ocorre porque, via de regra, os arquivos de redo têm problemas de
corrupção em seus conteudos, o que impossibilita que os
serviços da Oracle os descarreguem. Para solucionar esse
problema, procede-se com a limpeza. Veja como fazer:

ALTER DATABASE CLEAR LOGFILE GROUP x;

Pronto, com esse
comando você limpa seus redos, deixando-os prontos para
receberem dados novamente. Caso esses problemas de corrupção em logs se
repitam, eu sugiro que fique atento às entradas no seu alert log e
monitore, se possível, as querys mais impactantes que exercem tarefas de
DML.

Como devo monitorar meus Redo Log Files?

Excelente
questionamento, pois não é tarefa lá muito trivial ficar monitorando
determinadas áreas, o mais comum é atentarmos apenas para Tablespaces e Archives.

Para monitorarmos nossas áreas de REDO LOG, utilizaremos como fonte de informação as nossas já conhecidas visões dinâmicas, cujos nomes de algumas eu já citei (V$LOG e V$LOGFILE). Uma que eu ainda não lhes apresentei é a:

• V$LOG_HISTORY – displays log history information from the control file.

Pois bem, essa é mais uma arma de auxílio para os nossos problemas com Redo Log
Files. Como o próprio nome sugere, ela nos dá todas as informações em
formato de histórico sobre as situações dos nossos arquivos de Redo.

Erros “ORA” encontrados: o que devo fazer?

Como toda e boa
estrutura Oracle, os arquivos de Redo não estão livres de erros e podem,
sim, gerar alguns problemas falados na língua Oracle.

Língua Oracle?

É, pessoal, não estranhem, seu banco fala com você. O “dialeto” ORA-xxxx
é a maneira que o Banco de Dados tem de sinalizar quando encontra algum
problema que fuja da sua funcionalidade normal e/ou seja causado por
algo externo, que o tenha forçado a trabalhar de maneira errônea.

Vejamos abaixo alguns erros comuns relacionados a arquivos de Redo Log
Files:

1. ORA-1571 –
   Este erro nos remete a uma situação de migração mal feita, pois no caso
   do não desligamento normal do Banco para dar início ao processo de
   migração, dados relacionados à versão antiga podem se manter nos
   arquivos, ocasionando a mensagem de erro. Por isso, em tarefas de migração, proceda sempre de maneira prudente e seguindo os passos do ReadMe que vem junto com a maioria dos How-To encontrados no Oracle My Support.
2. ORA-1184 – Bem tranquilo, aqui é apenas uma mensagem de alerta (warning), informando que você está tentando adicionar um arquivo que já existe. Corrija a nomenclatura para um nome não existente e execute a tarefa novamente.
3. ORA-0301 – Neste caso temos erros mais apurados, que poderão ser encontrados em detalhes na forma dos Trace Files, isso faz com que seja necessário que analisemos este trace, pois as causas podem ser inúmeras.
4. ORA-17610
   – Esta mensagem aparecerá sempre que você tentar criar um redo sem
   definir para ele um tamanho qualquer, vale salientar que em caso de uso
   de OMF, não será encontrado este erro.
5. ORA-1185 – Aqui você deve atentar ao parametro MaxLogFiles, pois este erro aparece quando se atinge o número máximo de arquivos de Redo Log no seu Banco de Dados.
6. ORA-1566 – Se você informar o mesmo nome de Redo na instrução de Drop, dará de cara com este erro. Neste caso, remova apenas a entrada duplicada e prossiga.
7. ORA-1900 – Mais uma mensagem do tipo Alerta. Acontece quando nos esquecemos de escrever logfile (junto) e escrevemos log file (separado) na hora de exercer as tarefas de administração de Redo Logs. Este erro é para nos lembrar de que a escrita está errada.
8. ORA-0344 – Um erro tipicamente relacionado a problemas de localização, ou de limpeza de Redo Log, aparece muito em operações de ResetLogs e Clear LogFile. Cheque se os diretórios destino estão todos normais, com espaço e permissões de gravação.
9. ORA-0357
   – Aqui esbarramos em um problema de quantidade de membros por
   grupo. Esta mensagem nos informa que excedemos o número de membros por
   grupo, então devemos diminuir esse número e executar a
   tarefa novamente.
10. ORA-0359 – Se você tentar remover um grupo de Redo que não exista, vai se deparar com este erro especifico.
11. ORA-0360 – Aqui temos o mesmo problema apontado acima, mas, no caso, é quando tentamos remover um membro que não existe.
12. ORA-0361 – Se você tentou remover o último membro de um dos grupos e isso resultou neste erro, aborte a tarefa e remova o grupo todo.

Situações envolvendo Redo Logs. Como fazer para “driblar esses problemas?

Vejamos algumas situações onde nossos arquivos de Redo são acessados,
lidos ou somente mencionados.

1. Acabei de iniciar minha instância, onde meus arquivos de redo entram nesta história? Qualquer modificação feita na sua instância após este fato será gravada no seu arquivo de Redo arquivados.
2. Meu tempo de recover está muito alto, o que eu posso fazer para diminuir isso? Uma das coisas a serem feitas é reduzir o tamanho dos Redo Log Files.
3. Os redos do meu grupo x foram corrompido, o que devo fazer
   para poder voltar ao normal? Meu arquivamento está parado? Proceda com o comando de limpeza ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP x.
4. Estava fazendo uma análise no meu Banco de Dados e identifiquei uma contenção nos meus redo log files, o que posso fazer? Cheque antes se os seus arquivos não estão em um mesmo disco físico. Caso sua resposta seja positiva, proceda com a separação deles e depois
   aumente seu parametro de Redo Log Buffer.
5. Tive
   uma falha em um dos meus discos que estava em Mirror, e este disco
   tinha Bad Blocks; isso ocasionou a perda de um Membro de Redo, o que vai
   ocorrer com a minha instância? Nada, neste caso sua instância não é afetada.
6. Onde entra o papel dos meus Redo Logs quando minha instância é aberta? Todos seus arquivos de Redo são lidos e abertos para isso.
7. Como faço para habilitar ou desabilitar o arquivamento dos meus Redo Logs? Coloque sua instância em estado de Mount.
8. Perdi um dos meus membros. Se eu checar o status dele na V$LOGFILE, qual será a resposta encontrada? Estará com o flag de Invalid.
9. Sofri
   uma queda de energia no meu ambiente e percebi que na hora do recover
   necessitei do meu redo, de que maneira ele me ajudou? O processo de checkpoint irá verificar o final do seu redo log file e
   proceder com o instance recover e aplicação de seu conteudo através do
   SMON.

Bem, pessoal, era isso que tinha para dividir com vocês sobre Redo Log Files. Espero que tenham apreciado e que tenham se divertido tanto quanto eu.

Abraço a todos!