locked
Perda de rendimento RRS feed

  • Pergunta

  • Bom dia parceiros...

    estou tendo um perda enorme de rendimento no meu SQL2000.
    tenho um windows server 2003 64-bits xeon 3.2Ghz Quad-Core com 2Gb RAM. 2 placas de rede de 1Gbps (1 cross-over pra um servidor de uma aplicação e outra pra rede coorporativa). Tenho uma aplicação web na rede coorporativa que acessa os dados do banco, é nessa aplicação que estou tendo problemas. Está extremamente lenta a busca de dados. Pra tirar um relatório, relativamente pequeno, está demorando cerca de 15min. 

    Alguém tem alguma sujestão pra me ajudar?
    voltar pra windows server 32bits? migrar para SQLSERVER 2000 64bits (não tem pro meu processador né?)? Migrar pra SQL SERVER 2005 ou 2008 64-bits?

    Qual é a melhor opção pra mim?
    segunda-feira, 20 de outubro de 2008 14:33

Todas as Respostas

  • Gustavo,

    A atualização para SQL Server 2000 64bits não tem para o seu processador. Mas eu não recomendaria esta atualização nem mesmo para SQL Server 2005 64bits haja vista que seu servidor só tem 2 Gb de memoria.

    A Atualização para SQL Server 2005 32bits você teria um ganho, pouco mais teria, de performace por causa do melhor gerenciamento de  recursos do SQL Server 2005. Mas acredito que fazendo isso você não está resolvendo o problema!!!

    Na minha opnião a memoria do seu servidor pode está compormentendo o sistema como um todo. Mas isso é só uma opnião minha. Pois hoje em dia 2Giga de memoria para um servidor e dependendo do seu uso é muito pouco!

     

    Existem muito fatores que podem comprometer o desempenho de um banco de dados e posso lhe garantir que a migração não é a solução para o seu caso. Procure ver a utilização dos recusos e se os mesmos estão no limite. Analise a consulta deste relatorio. Se esta consultas está utilizando boas praticas de T-SQL!!!!

     

     

    Espero ter ajudado...ou pelo menos lhe tirado uma duvida!

     

     

    segunda-feira, 20 de outubro de 2008 14:59
  • Leivio,

     

    Concordo plenamente com você!!!

    segunda-feira, 20 de outubro de 2008 15:23
    Moderador
  • Leivio, desculpa cara, mas passei informação errada. estou com 4Gb RAM no meu Servidor.

    andei conversando com o analista de redes aqui da empresa, ele disse que, pelo falto de ser um processador Quad, o SQL pode estar processando 4 vezes um unico processo, o que geraria muito processamento "a toa" e uma demora desnecessária. Isso pode estar acontecendo mesmo, ou o SQL Server 2000 tem o gerenciamento ao processador Quad?
    segunda-feira, 20 de outubro de 2008 17:43
  • Boa Tarde,

     

    Primeiro eu recomendo certificar-se de que está com o SQL Server 2000 com no mínimo o SP4 (recomendável também o Build 2187). Isso já corrigiria bugs, comportamentos inesperados e problemas conhecidos.

     

    Acredito que esse analista de rede tenha se equivocado em achar que o fato do SQL Server 32bits estar em um Windows 64bits com um processador QUAD faça com que ele processe quatro vezes um único processo (não consigo imaginar um DELETE sendo executado quatro vezes por exemplo apenas por que existem quatro núcleos).

     

    O que acredito é que focar a conseqüência é um equívoco, ou seja, você está querendo tratar a lentidão (que é uma conseqüência do problema) e não a causa (o que será que provoca a lentidão). Mudar a plataforma para 64 no 2005 ou 2008 ou ainda voltar o SO para 32bits pode ajudar mas não seria a melhor alternativa (especialmente em relação a custos de atualização da plataforma).

     

    Comece tentando descobrir porque uma determinada consulta está lenta. Seria ausência de índices ? Seriam índices desfragmentados ? Há bloqueios na consulta ? A demora está no SQL Server ou na rede ? A consulta está bem formulada ?

     

    Utilizar o SQL Profiler já é um bom começo para tentar entender o que está havendo. Quando você tiver certeza de que o modelo de dados está adequado, de que a consulta está bem formulada, de que os índices certos existem e de que não estão fragmentados e de que não há bloqueios, então sim podemos começar a pensar em upgrade de servidor e SO. Enquanto você não esgotar essas hipóteses, você não deve tentar atualizar a plataforma (a menos que a atualização tenha outras razões).

     

    [ ]s,

     

    Gustavo

    segunda-feira, 20 de outubro de 2008 21:01