[OFF] COMPARE DATABASE

 Tópico anterior Próximo tópico Novo tópico

[OFF] COMPARE DATABASE

VB / VBA

 Compartilhe  Compartilhe  Compartilhe
#252889 - 23/01/2008 14:06:44

ALMARTI
NITEROI
Cadast. em:Dezembro/2003


Membro da equipe
Amigos, recentemente deparei-me com uma situao complexa em termo de escolha de banco de dados, e gostaria de dividir com vocs. A situao-problema a seguinte:
Foi comprada uma aplicao que dispunha como base de dados o PostGre 8. A aplicao funcionava sem problemas, at que resolveu-se unificar todas as unidades, ao todo umas 150. Quando colocamos 9 unidade ao mesmo tempo na base, a mesma perdeu 95% de performance. Averiguei que o Postgree no possui auto-incremento, e sim uma sequence. Verifiquei que uma espcie de gatilho. Assim, quando cada unidade faz insert, esta sequence conta todos os registros e gera o prximo nºmero. Acontece que apenas as 9 unidade geral cerca de 1,8 registros por segundo. Isto tem gerado um vcuo em base que, sinceramente, acredito que no aguenta as 150 unidade.
Convenci meus colegas aqui a fazermos uma migrao para SqlServer 2000, Oracle ou at mesmo o MySql5, uma vez que este j relacional.
Minha pergunta , o Postgree realmente possui esta falha? Ele no possui um bom gerenciamento de concorrencias?


______________________________________________
Uai Solues em Software
suporte@uaisolucoes.com.br

#252896 - 23/01/2008 14:27:00

LCSD
SAO PAULO
Cadast. em:Janeiro/2001


Infelizmente, essa sua informao ver­dica sim.

O POSTGRESQL no fazer um INSERT, e pegar o ºltimo registro e somar um. Ele OBRIGAT“RIAMENTE acaba correndo a base inteira para fazer este tipo de comando. Por mais que VC inclusa CHAVES ou mude os GATILHOS, sempre ele far isso.

No seu caso, pelo tamanho da base e a velocidade que o seu sistema ir precisar, acredito que o ORACLE seria a melhor alternativa (lgico, vai acabar gastando muito mais para isso tambm).


  
Quando precisar, pode contar comigo....
E quando precisar, no esquea de agradecer, pois a educao a ALMA DO NEGCIO...


Obrigado.

Luiz Cesar

#252939 - 23/01/2008 16:37:32

ALMARTI
NITEROI
Cadast. em:Dezembro/2003


Membro da equipe
Ou seja, o Postgre invivel para operaes de grande fluxo envolvendo vrias conexes.


______________________________________________
Uai Solues em Software
suporte@uaisolucoes.com.br

#253011 - 24/01/2008 08:58:30

WEBMASTER
CURITIBA
Cadast. em:Janeiro/2001


Membro da equipe
Interessante, lembro de ter lido a documentacao (nunca mexi com ele diretamente) dele a alguns anos atras e nao lembro de visto absolutamente nada a respeito.

Sera que foi de proposito ?


WebMaster - VBMania

Nao me mande e-mail com duvidas
Para isso e que existe o forum do VBMania !!!

#253013 - 24/01/2008 09:12:25

HUGOSSOUZA
SAO PAULO
Cadast. em:Dezembro/2004


tem certeza q ele corre toda a tabela?
nao sei se estou falando besteira mas se vc olhar em sequences ele tem um registro para cada campo serial do banco de dados.
nao seria o caso ele s pegar o contador atual e colocar + 1 ao inves de percorrer toda a tabela?
pq se vc mudar esse contador ele continua do numero que vc colocou.




_
Leia :
Regras do frum
Como Fazer Perguntas Inteligentes



#253018 - 24/01/2008 09:36:51

LCSD
SAO PAULO
Cadast. em:Janeiro/2001


O problema que o POSTGRE ainda no uma base de dados TOTALMENTE "relacional".

L­ recentemente no me lembro aonde, em um frum referente a PostGre, um usurio reclamando com a prpria PostGree que a documentao diz que na hora de se fazer um INSERT, ele pega o ºltimo e insere um, e que durantes testes PESADOS dele, foi descoberto que isso NA REAL no existe.

Portanto, a documentao FALA uma coisa, mas na verdade, faz outra.

E o problema ainda continua na verso ATUAL (que se no me falhe a memria, a verso 8.2).

O melhor aguardar a prxima verso e verificar se este BUG DE BASE foi arrumado.

Faz ANOS que no trabalho diretamente com POSTGRE, mas eu gostei da ferramente na poca que trabalhei, e sempre procuro me manter atualizado sobre ela.


  
Quando precisar, pode contar comigo....
E quando precisar, no esquea de agradecer, pois a educao a ALMA DO NEGCIO...


Obrigado.

Luiz Cesar

#253064 - 24/01/2008 13:39:48

ALMARTI
NITEROI
Cadast. em:Dezembro/2003


Membro da equipe
Bom, andei lendo tambm a documentao, e no entendi o porque de se insistir na Sequence eao inv de criar uma opo de autoincremento. Aqui se falhou em termos de procuo. COmo eu disse, so cerca de 75 a 90 inserts por minuto. COm tendencia progressiva. S que, ao fim 9 empresas no banco ele no aguentou.
Na verdade, no ocorreu nenhum bug, nada assim. O que ocorreu foi:
falta de performance,
duplicao de indices (a sequence criou o mesmo numero para insertes oriunods de fontes diferentes)
Um vcuo gigantesco, cuja correo tem levado 4 horas.

Um coisa que fico pensando o seguinte: porque desenvolver uma base free de maneira que grandes corporoes pudessem usar? Acho que devem (no sei quais) existir limites propositais.


______________________________________________
Uai Solues em Software
suporte@uaisolucoes.com.br

#253067 - 24/01/2008 13:44:12

LCSD
SAO PAULO
Cadast. em:Janeiro/2001


S que ele no uma BASE pra que se ter uma tamanho destes como VC est tendo hoje.

SE VC parar um pouco para analizer, ir perecber que muitos SITES quem usam essa base de dados. E a MASSA DE DADOS de um site para cadastro de alguma coisa, no to GRANDE como a movimentao de um sistema seu.




  
Quando precisar, pode contar comigo....
E quando precisar, no esquea de agradecer, pois a educao a ALMA DO NEGCIO...


Obrigado.

Luiz Cesar

 Tópico anterior Próximo tópico Novo tópico


Tópico encerrado, respostas não sao permitidas
Encerrado por WEBMASTER em 18/08/2009 10:03:45