[firebase-br] Lentidao em Base de dados Grande

Eduardo Bahiense eduardo em icontroller.com.br
Sex Jan 22 15:39:22 -03 2010


Hummm...

Começamos a ter pistas, algo a pesquisar...

Naturalmente que pode ser. A atitude definitiva para diagnóstico é 
desativar a trigger e rodar o processo. se o tempo cair drasticamente, 
teremos a trigger para "debugar", mas vamos tentar listar a causa de um 
update ser muito lento:
1. A cláusula WHERE não está em sincronia com os índices da tabela, 
obrigando o BD a varrer todo o banco para encontrar os candidatos a 
receber o UPDATE.

2. A instrução UPDATE atinge um número excessivo de linhas.

3. A tabela que recebe o UPDATE possui utras triggers que disparam 
outros processos.

Eu verificaria logo o [1.] e veria se há um índice que corresponda à 
sequencia do WHERE. Ex:

WHERE CODIGO=:PCODIGO -> Temos um índice cujo primeiro campo é código?

Não -> Crie um e reteste

Sim -> Verifique se a seletividade deste índice está boa e se há um 
outro índice que tenha o campo CODIGO com seletividade melhor que a do 
primeiro, pois isso pode estar fazendo com que o BD escolha o índice errado.

Continuando nessa linha de investigação, o ideal seria rodar sua 
instrução e nalisar o PLAN dela para ver se ele usa índices e quais 
índices estão sendo usados.

Eduardo


Rodrigo escreveu:
> Boa tarde Eduardo, estava dando uma olhada, será que nao é nos UPDATES?
> 
> Pq a cada item que lança no pedido da retaguarda o sistema usa uma 
> trigger que atualiza o estoque
> 
> e um update que grava na tabela estoque o numero da venda realizada.
> 
> Sera que no update nao se torna lento?
> 
> Grato,
> Rodrigo
> 
> 
> 
> ----- Original Message ----- From: "Eduardo Bahiense" 
> <eduardo em icontroller.com.br>
> To: <lista em firebase.com.br>
> Sent: Friday, January 22, 2010 11:10 AM
> Subject: Re: [firebase-br] Lentidao em Base de dados Grande
> 
> 
> Rodrigo
> 
> Inserções não são, absolutamente, demoradas, a menos que:
> 1. Você tenha triggers que disparem outros processos e, estes sim, 
> demorados
> 2. Você tenha um número exagerado de índices na tabela, mas ainda assim,
> não deveria consumir 2 segundos para uma inserção. Tenho tabelas aqui
> com 6 milhões de registros sem nenhum tipo de demora em INSERTS/UPDATES
> 3. A sua intrução de INSERT contenha uma cláusula WHERE do tipo NOT
> EXISTS(SELECT ...) não balanceada com os índices, tornando a verificação
> lenta, mas não a inserção.
> 
> Observe que INSERTs não usam índices, exceto os utilizados para as
> CONSTRAINTS (PK, por exemplo) da própria tabela, que são muito
> eficientes. Assim, se você não está usando TTable, poder ser que, a cada
> inserção, você esteja atualizando a visualização do usuário com um
> SELECT * FROM TABLE sem uma cláusula WHERE que limite a quantidade de
> registros retornados. Se isso for verdade, não há nada que possa ser
> feito para melhorar a performance do processo e ele vai se tornar cada
> vez mais penoso conforme o banco crescer.
> 
> Sinto em lhe dizer, mas o que me parece é que você terá que rever todo o
> processo e modificar a forma como sua aplicação está interagindo com o
> banco, pois os tempos de inserção que você relata são absolutamente
> incompatíveis com qualquer SGBD, e o gargalo, provavelmente, está no
> aplicativo.
> 
> Para tentar separa o joio do trigo, abra um gerenciador qualquer, ou
> mesmo use o isql, e faça um INSERT típico do seu processo e veja o tempo
> em que isso ocorre, a diferença será por conta do aplicativo.
> 
> 
> Eduardo
> 
>> Oi Eduardo, boa tarde,
>>
>> Deixa eu tentar te explicar qual a situação
>>
>> Com a mudança dos sistemas para o PAF-ECF, estou transferindo os dados 
>> da Frente de Loja para a Retaguarda.
>>
>> No estado atual a Tabela Pedidos ta em torno de 280,000 registros e a 
>> tabela itens em torno de uns 800.000 registros e a tabela pagto uns 
>> 350.000 registros. A tabela estoque uns 20.000 registros.
>>
>> Faço tudo com IBOQuery nao utilizo IBTable.
>>
>> - O primeiro registro faz rapido da Tabela PEDIDOS da Frente de Loja 
>> para Retaguarda.  2 segundos
>>
>> - Ja a tabela ITENS faz inserção da Frente de Loja para a Retaguarda e 
>> atualiza estoque na tabela estoque e atualiza uma tabela chamada 
>> movimento com a movimentação do estoque. 30 segundos
>>
>> - Ja a tabela PAGTO faz inserção da Frete de Loja para Retaguarda e 
>> atualiza todas as formas de pagto possiveis, como Caixa, Contas a 
>> Receber, Cartao etc... 10 segundos aprox.
>>
>> Para transferir uma venda em torno de 42 segundos, imagina passar 300 
>> vendas diarias. leva mais tempo atualizando do que vendendo. hehe
>>
>> Minha esperança é que tivesse alguma propriedade que pudesse alterar 
>> para nao ler a quantidade de registros ja existentes na tabela, dessa 
>> forma aumentando o desempenho.
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 
> __________ NOD32 4796 (20100122) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 
> 
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use: 
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
> 





Mais detalhes sobre a lista de discussão lista