Otimizando o tamanho do Redo Log

Publicado: março 7, 2016 em Uncategorized

Bem, para começar vamos primeiro entender melhor o que é o Redo Log. O Redo Log é o arquivo de banco de dados que armazena todas as alterações realizadas no banco, essas informações são essenciais para restaurar o banco de dados em caso de falhas. Por isso, a extrema importância desses arquivos.

Para retirar os dados do log buffer (estrutura de memória), o Oracle realiza o flush dessa estrutura nos seguintes cenários:
– A cada 3 segundos.
– A cada commit.
– Quando está 1/3 cheio.
– Quando está com 1 MB de dados.

Para realizar essa ação, ele utiliza o processo de background LGWR. Ele, por sua vez, escreve no grupos de redo log existentes de maneira cíclica. Ou seja, quando termina de escrever no último grupo de redo log, ele voltará para o primeiro grupo, sobrescrevendo os dados existente no mesmo. Como demonstrado na figura abaixo.
Screen Shot 03-07-16 at 01.30 PM.PNG

Cada mudança entre um grupo de redo log e outro é chamado de Log Switch e gera um Archived Log, que é simplesmente um backup do redo log, caso o banco esteja em modo ARCHIVELOG. Como recomendação, é esperado que o Log Switch aconteça no intervalo de 15 a 30 minutos. Caso o intervalo entre um Log Switch e outro esteja menor do que o recomendado, é necessário que seja avaliado dois pontos:
1) O tamanho do Redo Log.
2) Se estão ocorrendo mais transações do que o esperado.

Como a segunda opção implica numa melhoria na Aplicação e não é de responsabilidade do DBA(ou, pelo menos, não deveria), vamos abordar a primeira opção, pois iremos realizar a alteração de tamanho dos Redo Logs para ajuste do intervalo de Log Switch.

Primeiro vamos verificar em que frequência está acontecendo o Log Switch. Podemos ver tanto pelo Alert.log, como por views que a Oracle fornece. Eu utilizo a seguinte query para verificar quantos archived logs foram gerados por hora:

SELECT TO_CHAR (COMPLETION_TIME, ‘DD/MM/YYYY’) DAY,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’00’, 1, NULL))
“00-01”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’01’, 1, NULL))
“01-02”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’02’, 1, NULL))
“02-03”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’03’, 1, NULL))
“03-04”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’04’, 1, NULL))
“04-05”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’05’, 1, NULL))
“05-06”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’06’, 1, NULL))
“06-07”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’07’, 1, NULL))
“07-08”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’08’, 1, NULL))
“08-09”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’09’, 1, NULL))
“09-10”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’10’, 1, NULL))
“10-11”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’11’, 1, NULL))
“11-12”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’12’, 1, NULL))
“12-13”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’13’, 1, NULL))
“13-14”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’14’, 1, NULL))
“14-15”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’15’, 1, NULL))
“15-16”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’16’, 1, NULL))
“16-17”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’17’, 1, NULL))
“17-18”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’18’, 1, NULL))
“18-19”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’19’, 1, NULL))
“19-20”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’20’, 1, NULL))
“20-21”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’21’, 1, NULL))
“21-22”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’22’, 1, NULL))
“22-23”,
SUM (DECODE (TO_CHAR (COMPLETION_TIME, ‘HH24′), ’23’, 1, NULL))
“23-00”,
COUNT (*) TOTAL
FROM V$ARCHIVED_LOG
WHERE ARCHIVED=’YES’
GROUP BY TO_CHAR (COMPLETION_TIME, ‘DD/MM/YYYY’)
ORDER BY TO_DATE (DAY, ‘DD/MM/YYYY’);

Caso seja verificada  uma geração de mais de 6 archived logs por hora, significa que há uma geração acima do esperado.

Agora vamos realizar o aumento dos arquivos de Redo Log de modo online:

1) Verificar o tamanho e caminho atual dos Redo Logs.
Screen Shot 03-07-16 at 02.57 PM.PNG
Screen Shot 03-07-16 at 02.59 PM.PNG
2) Adicionar novos grupos de Redo logs com o tamanho de 200MB.
Screen Shot 03-07-16 at 03.13 PM.PNG
Observação: Foi repetido esse comando para os grupos 5 e 6.

3) Verificar localização e tamanho dos grupos criados.
Screen Shot 03-07-16 at 03.16 PM
Observação: Por utilizar o OMF, o banco cria os redo logs multiplexados no caminhos informados nos parâmetros DB_CREATE_FILE_DESTDB_RECOVERY_FILE_DEST.

4) Verificar qual Redo Log está em uso, pois só é possível excluir os grupos que estão com STATUS de INACTIVE ou UNUSED.
Screen Shot 03-07-16 at 03.20 PM

5) Limpar os Redo Logs que ainda estão em modo ACTIVE. Para realizar essa ação, deve ser executado um Checkpoint manual.
Screen Shot 03-07-16 at 03.22 PM 001.PNG
Observação: Como podemos verificar, o STATUS do grupo 3 foi alterado para INACTIVE.

6) Excluir os antigos grupos de Redo Log.
Screen Shot 03-07-16 at 03.26 PM.PNG

Com isso, terminamos a otimização do tamanho dos Redo Logs do banco.

Links:
Master Note: Troubleshooting Redo Logs and Archiving (Doc ID 1507157.1)
Creating Redo Log Groups and Members

Dropping Redo Log Groups and Members

 

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s