Um dos horrores para uma base de dados OLTP ou para algum processamento puramente transacional, são os Redo Logs e todos os componentes de garantia de consistência.
Um dos eventos mais conhecidos é “log file sync”. Obviamente, que há diversas formas de minimizar o impacto deste evento.
Uma delas que vou aqui mostrar, é com a alteração dos parâmetros commit_logging e commit_wait.
Uma breve descrição destes parâmetros:
1) commit_nologging:
– Controla como o Oracle irá agrupar as escritas em redo (Log Writer)
– Permite os valores IMMEDIATE e BATCH
2) commit_wait:
– Permite o controle de como o Oracle descarrega as informaçoes para redo log
– Permite os valores NOWAIT, WAIT e FORCE_WAIT
Para efeito de testes, utilizei a ferramenta criado por Dominic Giles, o Swingbench, para gerar carga e poder comparar o comportamentos do evento log file sync, com os parametros alterados ou não.
Os testes 1 e 2, os valores dos parâmetros estavam conforme abaixo:
- COMMIT_LOGGING=BATCH
- COMMIT_WAIT=NOWAIT
Os testes 3 e 4, não houve alteração do default, ou seja:
- alter system reset commit_logging;
- alter system reset commit_nowait;
Segue resutado abaixo, retirado das estatisticas de BD, coletados pela ferramenta:
- 1_com_alteracao_teste.txt: <DatabaseWaitEvent name=”log file sync” noOfTimesWaited=”6″ timeWaited=”55″ percentageTimeWaited=”0.02″/>
- 2_com_alteracao_teste.txt: <DatabaseWaitEvent name=”log file sync” noOfTimesWaited=”11″ timeWaited=”61″ percentageTimeWaited=”0.02″/>
- 3_sem_alteracao_teste.txt: <DatabaseWaitEvent name=”log file sync” noOfTimesWaited=”3690″ timeWaited=”72895″ percentageTimeWaited=”21.96″/>
- 4_sem_alteracao_teste.txt: <DatabaseWaitEvent name=”log file sync” noOfTimesWaited=”3815″ timeWaited=”73244″ percentageTimeWaited=”24.29″/>
É uma redução considerável.
Em termos de transaçoes por segundo, obviamente que há uma melhoria também:
-
1_com_alteracao_teste.txt: <AverageTransactionsPerSecond>10.25</AverageTransactionsPerSecond>
-
2_com_alteracao_teste.txt: <AverageTransactionsPerSecond>10.12</AverageTransactionsPerSecond>
-
3_sem_alteracao_teste.txt: <AverageTransactionsPerSecond>8.89</AverageTransactionsPerSecond>
-
4_sem_alteracao_teste.txt: <AverageTransactionsPerSecond>8.53</AverageTransactionsPerSecond>
Deve-se ter cuidado com a utilização deste parâmetro, porque pode levar a perca de dados em caso de crash.
Fonte:
http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams033.htm#REFRN10266
http://docs.oracle.com/cd/E11882_01/server.112/e25513/initparams031.htm#REFRN10265
Categorias:Base de Dados, Oracle, Tips
Viva,
Apesar de concordar contigo em que é uma das formas de evitar a chamada “commit latency” ou seja o tempo em que após o commit da sessão (seja pelo user ou implicitamente pelo Oracle) o LGWR escreve do redo buffer no SGA para os redo files, penso que esta deve ser uma das últimos recursos a usar.
Passo a explicar.
Se tens o COMMIT_WAIT em NOWAIT significa que o um dos passos do processo do LGWR é ignorado, ou seja, a parte em que se dispende mais tempo de “commit latency”, ou seja na altura em que os buffers passam do SGA para os redologs. Acontece se tiveres um crash imediatamente após o commit e o LGWR não tiver terminado a escrita, vais perder dados e lá se vai o ACID 🙂
Quanto ao usar COMMIT_LOGGING em BATCH juntamente com NOWAIT, juntas o péssimo ao desagradável, ou seja, esperas que um conjunto de redo vectors modificados se juntem em batch e depois fazes commit. Commit esse que não vai esperar que o LGWR termine, eliminando assim “90% da commit latency”.
Resumindo, juntas um conjunto de commits que _eventualmente_ são escritos nos redologs, se tiveres sorte 🙂
Esta minha explicação é mostrada nos teus números de time waited.
Além de colocar o redo em discos distinctos, mais rápidos e blah blah, deves ter atenção ao tamanho dos teus redologs.
Abraço,
Luis Marques
Evidente, que como qualquer coisa, deve-se ter medida para aplicar configurações em um determinado sistema, e exatamente como a última frase que escrevi, que deve-se tomar cuidado com esta configuração pois pode levar a perca de dados em situação de crash.
No entanto é curioso, pois estou a escrever um post sobre ACID 🙂