Contando e controlando, tudo que é bom deve ser na medida certa…

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.

Sobre raul andrade

DBA e Instrutor Oracle, apaixonado pela minha família e por ensinar.
Esta entrada foi publicada em DBA Oracle. Adicione o link permanente aos seus favoritos.

Deixe uma resposta