[firebase-br] RES: Lentidao em Base de dados Grande

José mauricio Zottis bzottis em ig.com.br
Sex Jan 22 12:27:57 -03 2010


Oi, estou pegando o bonde andando e estou querendo sentar na
janela.....mas....

Passa o DDL da tua tabela que passei por um problema parecido, e a causa
tava como disse um colega nos not exists e em índices mas colocados...

Acho que a lista poderá te ajudar bem mais rapidamente


......
Espero que ajude.

-----Mensagem original-----
De: lista-bounces em firebase.com.br [mailto:lista-bounces em firebase.com.br] Em
nome de Eduardo Bahiense
Enviada em: sexta-feira, 22 de janeiro de 2010 11:11
Para: lista em firebase.com.br
Assunto: 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
Nenhum vírus encontrado nessa mensagem recebida.
Verificado por AVG - www.avgbrasil.com.br 
Versão: 9.0.730 / Banco de dados de vírus: 271.1.1/2637 - Data de
Lançamento: 01/21/10 17:34:00





Mais detalhes sobre a lista de discussão lista