Um pouco de teoria envolvendo performance

Os Redolog OnlineOla DBA! Buenas! Como estamos nesta sexta-feira enchuvarada… Hehehe nunca ouviu esta palavra né? Pensa comigo: Uma manhã bonita de sol como chamamos? Manhã ensolarada… Logo… hehehehe…

Hoje vou comentar a respeito de algo bem trivial para DBAs experientes, conhecedores da matéria. Porém como o Blog é dedicado a todos os níveis de conhecimento, resolvi comentar a respeito de um “cara” muito importante no ambiente Oracle, os Redologs online.
Vem do próprio nome dele a sua função RE-DO refazer. Sim! Esta é a função deste nobre arquivo do banco de dados.

Pertencente ao grupo de arquivos físicos do  banco de dados, o redolog online tem a incumbência de armazenar a forma, a “receita” de como refazer alguma alteração caso tenhamos algum problema.
Talvez esteja querendo me perguntar: “Mas como assim????”
Vamos a explicação:
Imagine que você tenha um update sendo feito no seu SQLDEVELOPER, de repente o banco de dados por algum motivo de falha de energia cai, não dando tempo para que sejam gravadas as transações por completo. Quando o banco de dados for reiniciado, ele estará de forma inconsistente e precisará ser feito o processo de recover. Este é feito automaticamente pelo processo de background chamado System Monitor ou apenas SMON para os íntimos.
Durante o recover o SMON utilizará dados dos redologs online para trazer todas as transações que estavam no banco no momento, estando elas comitadas ou não. SIM!!! Não escrevi errado. Durante a primeira etapa do processo de recover são trazidas todas as transações, este processo se chama rollforward; depois em uma segunda etapa é feito o rollback de tudo que não havia sido comitado. Este processo utiliza-se dos dados de undo.

O arquivo denominado redolog online traz os dados  que foram primeiramente gerados em um local da memória chamado redolog buffer. Ele é gravado para garantir integridade em alguns momentos como:

• Quando o buffer estiver 1/3 cheio;
• A cada 3 segundos;
• No commit;
• Antes do DBW  proceder alguma gravação de datafiles

O responsável pela gravação é um outro carinha chamado de Log Writer ou LGWR.

Processando a gravação do arquivo:
Um item bem interessante é como ocorre o processo de gravação do arquivo.
O redolog online sempre trabalha por grupo e devemos ter pelo menos 2 grupos de redolog e em cada grupo pelo menos um membro, ou seja, cada membro é um arquivo. Eles sendo do mesmo grupo serão iguais. Isso é feito por questão de segurança e se chama de multiplexação ou redundância.
O processo de gravação é sempre cíclico, ou seja, segue um determinado ciclo.
Então imaginemos um redolog onde temos 3 grupos com um membro cada um. Estes membros tem o tamanho de 50MB cada.
Falar em gravação cíclica significa que ele grava dados do redolog buffer em um dos grupos até que ele se encha por completo, ou seja, até que tenhamos 50MB gravados. Logo após ele passa o processo de gravação para o próximo grupo e assim sucessivamente.
Quando o último grupo termina ele volta para o primeiro novamente.
Este processo de alternância de redolog chamamos de switch do log file.
Em performance temos diversos eventos de espera ligados a gravação do redolog. Isso é fácil de entender quando lembramos que se trata de gravação física, logo envolve I/O em disco principalmente.

O que podemos fazer para minimizar o impacto?
Diversos estudos já foram feitos, análises diversas e chegamos a um número expressivo. Este número irá dizer não o tamanho exato que deverá ter o seu arquivo de redolog, mas sim a quantidade ideal de switchs (alternância de membros) em uma hora.
Pelos estudos feitos pela Oracle, os quais já tive o prazer de comprovar, uma média considerada boa é quatro switches por hora, ou seja mais ou menos um a cada quinze minutos.
Nesta hora você deve estar se fazendo 2 perguntas, as quais irei responder de imediato:

1. Como descubro a quantidade de switches feitos por hora?
   R: Uma forma bem simples e rápida e analisando o alert.log. Lá ele demonstra os horários das alternâncias (switches), basta ver os horários e quantos foram feitos em uma hora.
   Outra forma é utilizar a query abaixo:

   select thread#,to_char(first_time,’DD-MON-YYYY’)creation_date,       to_char(first_time,’HH24:MI:SS’)time,sequence#,first_change# lowest_SCN_in_log,next_change#highest_SCN_in_log,recid ontrolfile_record_id,       stamp controlfile_record_stamp
   from   v$log_history
   order by sequence#;

2. O que faço para modificar a quantidade de switches?
   R: Ok, você conseguiu descobrir que estamos tendo muita alternância de redolog isso na verdade pode ter dois culpados: a) muitas transações fazendo diversos commits, b) redologs muito pequenos para suportarem a quantidade de transações ocorrendo.
   Hummm… Então a correção seria simples, basta ir até aos usuários e dizer que eles deve fazer menos transações. Pronto resolvido!
   Pode rir! Sei que essa foi a piada do ano! Mas acredite, eu já ouvi isso de um desenvolvedor uma vez: “A aplicação é boa a culpa é da empresa que faz muitas vendas por dia…” Acredite! É real! EU JÁ OUVI ISSO!!!
   Ok, mas não podemos fazer isso, vamos então a solução real do problema. Se temos muitas gravações, digo se o volume é grande e o redolog é pequeno demais, o que causa as alternâncias, vamos aumentá-lo. Pronto! Simples assim!
   Calma! Aumentar, quanto? Como? Agora entra outra análise: Qual o tamanho ideal?
   Para isso eu tenho uma query que demonstra um valor sugerido bem interessante:
   SELECT
   (SELECT ROUND(AVG(BYTES)/1024/1024, 2) FROM V$LOG) AS “Redo size (MB)”,ROUND((20/AVERAGE_PERIOD) * (SELECT AVG(BYTES)
   FROM V$LOG)/1024/1024, 2) AS “Recommended Size (MB)”
   FROM (SELECT AVG((NEXT_TIME – FIRST_TIME) *24*60) AS AVERAGE_PERIOD
   FROM V$ARCHIVED_LOG
   WHERE FIRST_TIME > SYSDATE -7
   AND TO_CHAR(FIRST_TIME, ‘HH24:MI’) BETWEEN ‘17:00‘ AND ‘20:00‘);Com a query acima, basta alterar os itens em vermelho para os períodos desejados. No exemplo acima está para analisar os últimos sete dias das 17:00 às 20:00.
   
   Procedendo a alteração
   De posse da informação do tamanho que você deseja colocar, vamos aos passos necessários. Porém primeiramente aqui cabe uma informação interessante, não existe comando alter para modificar o tamanho, o processo consiste em criar novos com o tamanho desejado depois dropar os antigos.Então vamos lá
   a) Primeiramente descobrir onde estão os redologs fisicamente.
   select * from v$logfile;b) Acrescentar novos com o tamanho desejado (supondo 500MB).
   alter database add logfile group 1 (‘uo1/oracle/oradata/orcl/redo03.log’) SIZE 500M;Caso eu utilize Oracle OMF e ASM não preciso colocar o endereço e nome do arquivo o próprio Oracle fará isso pra mim:
   alter database add logfile group 1 ( ‘+DATA’) SIZE 500M;
   
   c) Dropar o redolog que não queremos mais utilizar.
   Para isso precisamos que ele esteja no estado inativo. Verificamos isso com a query:
   select * from v$log;
   Em seguida, caso algum dos que queremos dropar esteja sendo utilizado forçaremos um switch com o comando:
   alter system switch logfile;
   Depois basta dropá-los com o comando:
   alter database drop logfile ‘uo1/oracle/oradata/orcl/redo02.log’

    

   Feito isso basta acompanhar pelos scripts ou pelo alertlog mesmo para verificar se realmente melhoraram as taxas.
   Ufa! Terminamos por hoje.
   Espero que tenham curtido, aproveitem bem a sexta-feira e  a partir da semana que vem pelo menos dois posts semanais.

   GRANDE ABRAÇO GENTE E FOCO NA META!!!!