O commit e a performanceOlá DBA, seguidor, amigo, inimigo, fã e afins… Hoje é um dia muito especial muito muito mesmo… Depois de 10 dias de frio e chuva ele resolveu aparecer… VIVA O SOL!!!!
Tá bom! Não estou ficando louco, é que com tanto frio e chuva acho que meus neurônios começaram a criar limo. É, você das regiões Norte e Nordeste deve está rindo da minha cara agora né?
Mas tenho certeza que o pessoal do Sul vai me dar plena razão.
E sou sincero em dizer que eu acho que sou movido à luz solar, portando sem sol parece que fico meio… … sem carga na bateria.
Bem, vamos deixar o controle de clima pra lá e vamos falar de um assunto bastante interessante hoje.
Para falar do assunto de hoje vamos dar um breve review no assunto do último post onde eu falei a respeito dos redologs. Lembro que eu falei que a quantidade de commits influencia diretamente na quantidade de switches do logfile.
Ok! Hoje vou comentar sobre algo bem simples que muitas vezes deixamos de fazer e pode ocorrer um problema grande, a falta de commits.
Sim! Pouco commit também pode ser um problema. Então como tudo na vida devemos ter a medida certa de utilização.
Tem um exemplo que sempre gosto de ressaltar que é aquele exemplo de um arquivo rodando com infinitas inserções de linhas (ou updates).
Você programa a carga, coloca o script pra rodar inserindo vários milhares de linhas, porém coloca apenas um commit no final.
Ok! Nesse momento poderemos estar iniciando dois problemas:
1- Caso o processo demore 10 horas e por algum motivo quando estava processando a 9:50 minutos cai a conexão, já era… Você perdeu todo o trabalho.
2- Como já comentei certo post, certa vez, enquanto não fazemos o commit os dados ficam armazenados nos segmentos de UNDO(ou rollback) que residem no tablespace de UNDO.
Sendo assim, enquanto não é procedido o commit o espaço não pode ser liberado para reaproveitamento e poderá ocorrer o erro: SNAPSHOT TOO OLD e abortar o processo.
Pois bem! Até agora só falei do problema mas não dei nenhuma sugestão de como proceder o acerto.
Bem ele é simples demais, basta editar o arquivo e colocar um commit a cada espaço de linhas. Como sugestão deixo a idéia de utilizar sempre a mesma quantidade de linhas, exemplo:
Para uma insert com 100.000 linhas um commit a cada 10.000 linhas.
E além do mais tenho uma dica super legal a este respeito, vai lá:
Você será capaz de monitorar a quantidade de inserts que já ocorreram atravez do count dos commits com a query abaixo:
SELECT a.SID,
DECODE(b.CLASS,
1, ‘User’,
2, ‘Redo’,
4, ‘Enqueue’,
8, ‘Cache’,
16, ‘OS’,
32, ‘ParallelServer’,
64, ‘SQL’,
128, ‘Debug’,
72, ‘SQL & Cache’,
40, ‘ParallelServer
& Cache’ ) CLASS,
b.NAME, a.VALUE
FROM v$sesstat a, v$statname b
WHERE (a.statistic# = b.statistic#) AND SID = ‘&SID’ — colocar o SID da sessão que está efetuando o processo.
AND NAME = ‘user commits’;
É meu amigo! Posso te dizer que esta query é muito útil, eu utilizei ela hoje mesmo para um processo envolvendo 36 commits a cada 10.000 linhas.
Com isso estaremos evitando problemas: Bloqueio de UNDO, controle de switches da sessão.
Com isso evita-se também a idéia de um commit por linha o que seria também prejudicial devido a quantidade de alternância de redolog gerado.
Pois bem, lembra quando falei acima que devemos ter a medida certa para tudo e como dizem: tudo que é bom se for demais enjoa??? Eu só não concordo quando o assunto é pudim de leite.. hehehehe
Mas esta é outra história…
Espero que tenham curtido nosso post de hoje, e que continuem sempre acompanhando o blog.
Grande abraço, e foco na meta!
Estou aceitando sugestões de assuntos para posts futuros.
