terça-feira, 24 de agosto de 2010

CONHECENDO MELHOR SEU BANCO DE DADOS : Redo Log File - PART I

Olá, estou de volta, só que desta vez trago até vocês um assunto técnico, uma pequena pausa nas certificações por enquanto.

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 estes 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 FILE

Conceito: Essa estrutura localizada fisicamente em nosso Banco de Dados, é a principal responsável por tornar possivel 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 contéudo se encontram 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 , eles quem faram os chamados Roll Fowarding.


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



ENTENDENDO UM POUCO MELHOR A MECANICA DO REDO LOG FILE

Notadamente os arquivos de redo log são umas das estruturas mais importantes existentes no Banco de Dados ao meu ver. No decorrer do nosso dia-a-dia em banco de dados, damos pouca importancia as 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 nimenclaturas padrões do Oracle. Só depois de realizado o comprometimento e ou confirmação ( COMMIT) o Buffer é esfaziado , para das lugar a novas estradas, pois nossos arquivos de REDO LOG FILE trabalham de maneira ciclica entre os seus grupos que por sua vez possuem seus respectivos membros.


Via de regra nós DBA's já os determinamos na criação, mas ha a possibilidade de adicionarmos mais membros ou mais grupos posteriormente a 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 ggarantirão a recuperação até o ponto onde eles tenham gravado a informação, por essa razão se faz necessário a "multiplexação" destes arquivos em diferentes locais e de preferencia em HARDWARES distintos, porque se você mesmo que os coloque em diferentes locais , os colocar em um mesmo disco, em caso deste mesmo disco vir a corromper ou apresentar 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 Instancia Oracle, dai se dá o comportamente ciclico dos mesmos como mostra a figura que coloquei acima.


Internamente o Oracle grava nesses arquivos paralelamente, 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 caracteristica importante a cerca dos redos em RAC é que ha um parametro novo a ser passado no comando de criação, que são os THREADS , eles indicaram em qual nó sera criado aquele Relog Member.


PARTICULARIDADES A CERCA DOS REDOS.


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


Se por ventura nos estivermos trabalhando em modo ARCHIVELOG, após o Oracle fechar o arquivo de redo log que esta 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 macanismo de auto-proteção, o Oracle apenas reutiliza um membro em modo ARCHIVELOG somente depois que este foi integralmente gravado no destino e liberado para uso, essa é uma das belezas dos processos internos do Oracle que não são visiveis. E caso não haja membros suficientes disponiveis 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 eram 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 se não é seu caso crie-os com um tamanho nem muito exagerado e nem tão pequeno, algo em torno 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 Oracle em si determina que as alternancias 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?


Bem, aqui é 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 variaveis antes, tipo HA ESPAÇO SUFICIENTE ONDE ELE SERÁ CRIADO?


Feito isso proceda da seguinte forma.


Logado com um usuários com poderem 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 aqueles que trabalham com RAC, após a opção GROUP você informará o numero 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 , MAIS AGORA QUERO ADICIONAR MAIS MEMBROS, SE VIRA AI COMO FAÇO ISSO? Antes de mais nada tenha CALMA, tenha 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 então 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 deste estar sendo utilizado atualmente pela instancia, 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 LOGSWTICH's, 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 algums SWITCHS 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, são elas : 


V$LOG

V$LOG displays log file information from the control file.
Column Datatype Description
GROUP# NUMBER Log group number
THREAD# NUMBER Log thread number
SEQUENCE# NUMBER Log sequence number
BYTES NUMBER Size of the log (in bytes)
MEMBERS NUMBER Number of members in the log group
ARCHIVED VARCHAR2(3) Archive status (YES or NO)
STATUS VARCHAR2(16) Log status:
  • UNUSED - Online redo log has never been written to. This is the state of a redo log that was just added, or just after a RESETLOGS, when it is not the current redo log.
  • CURRENT - Current redo log. This implies that the redo log is active. The redo log could be open or closed.
  • ACTIVE - Log is active but is not the current log. It is needed for crash recovery. It may be in use for block recovery. It may or may not be archived.
  • CLEARING - Log is being re-created as an empty log after an ALTER DATABASE CLEAR LOGFILE statement. After the log is cleared, the status changes to UNUSED.
  • CLEARING_CURRENT - Current log is being cleared of a closed thread. The log can stay in this status if there is some failure in the switch such as an I/O error writing the new log header.
  • INACTIVE - Log is no longer needed for instance recovery. It may be in use for media recovery. It might or might not be archived.
FIRST_CHANGE# NUMBER Lowest system change number (SCN) in the log
FIRST_TIME DATE Time of the first SCN in the log






E também a :


V$LOGFILE

This view contains information about redo log files.
Column Datatype Description
GROUP# NUMBER Redo log group identifier number
STATUS VARCHAR2(7) Status of the log member:
  • INVALID - File is inaccessible
  • STALE - File's contents are incomplete
  • DELETED - File is no longer used
  • null - File is in use
TYPE VARCHAR2(7) Type of the logfile:
  • ONLINE
  • STANDBY
MEMBER VARCHAR2(513) Redo log member name
IS_RECOVERY_DEST_FILE VARCHAR2(3) Indicates whether the file was created in the flash recovery area (YES) or not (NO)




Vamos então a 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 pelo fato de ele atender as particularidades que falamos acima.




Pessoal, vou parar por aqui nossa pequena auto-descoberta, e retornarei em um próximo artigo para fecharmos esse assunto e trazer algumas problemáticas sobre os arquivos de REDO LOG.


Espero que tenham gostado até aqui e até a próxima.


Obrigado á todos!!!!