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

Rodrigo dominio em engeplus.com.br
Sex Jan 22 15:25:32 -03 2010


Obrigado fenando pela ajuda,

Sim, ja é assim, tipo só vai enviar as novas vendas que ja foram geradas, e 
é nessas que esta muito lento.

Tipo só atualiza o movimento do dia que ainda  nao fora atualizado 
anteriormente,

Grato
Rodrigo


----- Original Message ----- 
From: "Fernando Passos" <fernando_passos em gcti.com.br>
To: "FireBase" <lista em firebase.com.br>
Sent: Friday, January 22, 2010 2:12 PM
Subject: Re: [firebase-br] RES: Lentidao em Base de dados Grande


Cara,
Pergunta besta se já tento criar uma flag, para dizer que os dados ja foram
enviados pra retaguarda e o mesmo da retaguarda para o caixa, aqui acabamos
de bolar o lance da carga e descarga e está extremamente rápido foi criado
so um campo data stamp para controlar quando foi a ultima ateracao do
registro dai criamos os inserts e updates em cima disto.
Tenta posta como se tá fazendo o código com certeza o problema não deve ser
o banco.


não sei se ajudei .




2010/1/22 José mauricio Zottis <bzottis em ig.com.br>

> 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
>
>
> ______________________________________________
> 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
>
______________________________________________
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






Mais detalhes sobre a lista de discussão lista