none
lentidão SQL Server RRS feed

  • Pergunta

  • Bom dia pessoal,

    Reinstalei um SQL Server 2008 num Server 2003, com uma base de 27 Gb. O acesso antes ao BD era um pouco lento, mas depois da reinstalação ficou pior ainda. Os meus procedimentos foram:

    - fazer um backup da base antiga;
    - reinstalar o  SQL Server 2008;
    - criar uma base de dados com o mesmo nome (não fiz nenhuma configuração);
    - voltar o backup sobre a base de dados criada.

    Depois disso percebi que um simples select a uma tabela ficou mais lento do que o normal e o acesso a disco monitorado pelo windows está um terror.

    Alguém por favor poderia me dar uma luz ?

    Obrigado,

    Gilcimar

    segunda-feira, 21 de março de 2011 13:03

Respostas

  • Gil,

    Verifique como está a Memória, altere a memória nas propriedades da Instância através do Management Studio.

     

    Altere o Maximum Server memory para 2147483647.

     

    Grato,

     

    Maurício

     

     

     

    • Marcado como Resposta Richard Juhasz segunda-feira, 28 de março de 2011 20:03
    quinta-feira, 24 de março de 2011 22:54
  • Gilcimar,

     

    Por esses dados, eu alteraria o nível de paralelismo para 1.O comando seria esse:

     

    sp_configure 'show advanced options', 1;
    GO
    RECONFIGURE WITH OVERRIDE;
    GO
    sp_configure 'max degree of parallelism', 1;
    GO
    RECONFIGURE WITH OVERRIDE;
    GO
    

    Uma boa fonte esta nesse LINK (blog de Paul Randal).

    []s!



    http://www.diaadiasql.com.br

    • Marcado como Resposta Richard Juhasz segunda-feira, 28 de março de 2011 20:03
    sexta-feira, 25 de março de 2011 01:36

Todas as Respostas

  • Gilcimar,

     

    Antes de tudo, eu verificaria os indices, pegue um select, veja seu plano de execução, conforme for faça um rebuild ou um reorganize, tente tambem dar um update nas estatisticas, bom, esse é o procedimento padrão, para podermos ajudarmos mais, seria preciso mais informações.

     

    OBS: Uma base de 27gb é uma base pequena, claro que depende do seu hardware, porem o acesso não deveria ser lento mesmo.

    Algumas perguntas:

    - Sua tempdb esta em um disco separado?

    - E os arquivos de data e log?

    - A uma separação de arquivos de indices?

    Um pouco mais tecnico:

    - Os discos estão em algum raid? se sim, quais arquivos em quais discos de raid e qual o nv desses raids?


    ------------------------------------------------------------- Oracle OCA11g
    • Sugerido como Resposta Rafael S. Melo segunda-feira, 21 de março de 2011 16:39
    segunda-feira, 21 de março de 2011 13:09
    Moderador
  • Olá Fabrizzio, obrigado por responder, pois é...eu conheço mais de oracle, SQL é muito novo pra mim ainda, estou aprendendo. Poderias me dar uma dica de onde reorganizar, fazer um rebuild ou atualizar as estatisticas ?

    O hardware tem uns 5 anos (servidor HP Proliant Xeon com 4 GB de ram)
    - O tempdb está na mesmo HD da instalação e a base está em um HD SCSI secundário
    - Como citado, os logs e o database em si está no HD secundário.
    - Não há separação de arquivos e indices
    Não há nada em raid.

    Agora a minha questão, antes estava do mesmo jeito, apenas foi feita a troca dos HDs...reinstalado o SQL e importada a base, só que agora a lentidão tá muito maior. Poderias me ajudar ?

    Obrigado,

    Gilcimar

    segunda-feira, 21 de março de 2011 17:11
  • Gil,

     

    Para fazer um rebuild -> http://www.mssqltips.com/tip.asp?tip=1367

    Update de estatisticas -> http://www.mssqltips.com/tip.asp?tip=1606

    Agora, evite manter coisas em HD externos, é lento, muito lento rs.... segundo, os hds são SAS? Prefira SAS, são mais rapidos.

    Em relação a SQL X Oracle, no Oracle uma boa pratica é manter um Temporary tablespace em disco separado correto? é a mesma coisa no sql, porem o noma da base é tempdb, só de voce separar a base tempdb, tera um ganho enorme.

    Quanto de memoria limite o SQL esta usando? 4GB para um servidor ja é pouco, se o mesmo estiver utilizando os 4GB e não sobrando nada para o SO, sua lentidão pode estar externa ao SQL porem afetando o mesmo.

    Boa pratica: Se voce tiver disco sulficiente, separe os arquivos de Data e Log, crie um filegroup para indices e coloque-os em outro disco tambem.


    ------------------------------------------------------------- Oracle OCA11g
    segunda-feira, 21 de março de 2011 17:30
    Moderador
  • Oi Fabrizzio, obrigado pela aula, no final do expediente vou fazer o rebuild e o update das estatisticas. Eu achei que o problema na lentidão poderia ser algum parametro de banco não configurado corretamente. Outra coisa, no rebuild que você passou, onde está @database eu mudo para o nome da base ?

    Gilcimar

    segunda-feira, 21 de março de 2011 17:49
  • Gil,

     

    Ok, faça isso e amanha se necessario, abra outra thred reportando o problema, e caso as respostas tenham lhe ajudado, seria interessante marcar como resposta para ajudar outros usuarios que venham a ter a mesma duvida.

     

    Em relação ao link, o script ja faz de todas as bases, se quer fazer de uma base e indice especifico o comando é:ALTER INDEX ix_01 ON dbo.testes rebuild

    Onde ix_01 é o nome do indice e testes o nome da tabela, dbo é o schema...


    ------------------------------------------------------------- Oracle OCA11g
    • Marcado como Resposta gilcimar segunda-feira, 21 de março de 2011 18:06
    • Não Marcado como Resposta gilcimar quarta-feira, 23 de março de 2011 23:49
    segunda-feira, 21 de março de 2011 17:57
    Moderador
  • Oi Fabrizzio,

    A lentidão ainda não melhorou, o que pude verificar é que a TempDB está em 8,75 MB. Isto não está pequeno demais para uma base de 27GB ? Tem mais algum parametro que poderia ser alterado ?

    Gilcimar

    quarta-feira, 23 de março de 2011 23:57
  • Gilcimar,

     

    Bom, em relação ao tamanho da tempdb, ela esta com o tamanho que esta sendo utilizado, se voce quiser aumentar esse tamanho é possivel, se for um disco exclusivo para tempdb, é uma boa ideia, caso contrario não.

     

    Ta, vamos excluir algumas possibilidades:

    - Verifique os indices

    - Rode um profiler e veja o que esta demorando mais tempo para rodar

    - Voce fez o rebuild e/ou o reorganize?


    ------------------------------------------------------------- Oracle OCA11g
    quinta-feira, 24 de março de 2011 00:24
    Moderador
  • Para atualizar estatísticas executa o comando

     

    Use nome-do-database
    GO
    Exec SP_updatestats
    GO
    

    Se a maquina eh antiga, imagino que seja 32 bits e assim o uso de memoria por padrao eh metade para o kernel, metade para o as aplicacoes de sistema.Entao, o sql server esta usando 2GB.

    Lentidao eh uma sintoma que podem ter varias causas. Citados os pontos como atualização de estáticas e rebuild de índices, cito pontos como “instant file initialization”,espaço livre no datafiles, concorrência de outros databases ,a distribuição de recursos por usuários entre vários,a percentagem de dados que esta em memoria etc....

    Verifica alguns contadores de memória,CPU,disco,etc e verifica onde esta a “lentidão”.Se quiser, posta aqui os contadores que dou uma olhada.

    []s!


    http://www.diaadiasql.com.br
    quinta-feira, 24 de março de 2011 01:22
  • O disco em que está rodando a tempdb é a unidade C:. Tem a instalação do SQL e mais 2 aplicativos. A base de dados e os logs está alocada numa unidade D:. Agora as questões,

    - podes me ajudar a verificar os indices ?
    - Como rodar o profiler ?
    - Tentei fazer o rebuild naquele link acima que você me passou...mas rodou durante umas 3 horas e não terminava mais, neste caso abortei.
    - As estatisticas rodaram super rápido, mas não ajudou muito na performance.

    Por isso imaginei que poderia ser alguma coisa relacionada a tempdb, pois me ajude no meu conceito, tem muitas consultas SQL e isso vai depender do tamanho da tempdb para ajudar na performance certo ?

    Renato, é uma única databasee percebi pelo monitor do server 2003 que o consumo de recursos, está diretamente ligado ao I/O. Como comentei com o Fabrizzio, eu fiz um backup dessa base utilizando a rotina de backup do SQL Server (era um pouco lento, mas a performance era melhor). Reinstalei o S.O. e o SQL Server, criei uma base vazia com o mesmo nome e importei os dados. Tudo rodando perfeitamente a não ser pela lentidão excessiva (acesso a disco muito grande numa pequena consulta SQL). Acho que o meu erro nessa lentidão foi não ter verificado corretamente os parametros de tempdb da base antiga ou da propria base de dados.
    Se alguém ai puder dar uma luz, agradeço

    Gilcimar

    quinta-feira, 24 de março de 2011 16:19
  • Gil,

     

    Primeiro, suas duvidas:

    - Abra o Profiler, o mesmo esta em SQL Server -> Performance Tools -> SQL Server Profiler

    Conecte-se a instancia;

    Marque o CheckBox para trazer todas as colunas e eventos;

    Va em TSQL e marque:

    SQL:BatchStarting -> Inicio de uma proc por exemplo

    SQL:StmtStarting -> Inicio de uma query dentro de uma proc

    SQL:StmtCompleted -> Fim da query dentro da proc

    SQL:StmtRecompile -> Querys que foram recompiladas

    - Em relação a indices, após rodar o profiler, voce tera um arquivo do que aconteceu no seu banco por um tempo, a partir do mesmo, verifique tudo que levou mais tempo para rodar, analise as querys e veja se as reespectivas tabelas utilizadas possuem indices adequados, se não, crie-os.

     

    OBS: Se no seu profiler retornar muitos valores em relação ao Recompile (Tive este problema a algumas semanas atraz), voce deve:

    - Verificar as procs (querys) e tentar utilizar mais variaveis de tabela ao invez de tabelas temporarias;

    - Declarar tudo que sera usado de variaveis no começo do codigo

    Essas ações foram sulficientes para resolver o meu problema.

     

    Caso as procs estejam OK, os indices estejam OK e não tenha muitos Recompile, voce deve:

    - Voce possui o Driver C de instalação do Windows e tudo mais, evite usar este disco para manter qualquer coisa do banco de dados

    - Jogue a sua TEMPDB em uma pasta reservada no disco D junto com os dados (Isso claro se não tiver um outro disco, se tiver um outro disco, jogue-o ai)

    Essa ações ja devem reduzir seu custo de I/O.


    ------------------------------------------------------------- Oracle OCA11g
    quinta-feira, 24 de março de 2011 16:44
    Moderador
  • Executa isso e nos retorna a resposta:

     

    WITH Waits AS
     (SELECT
      wait_type,
      wait_time_ms / 1000.0 AS WaitS,
      (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS,
      signal_wait_time_ms / 1000.0 AS SignalS,
      waiting_tasks_count AS WaitCount,
      100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage,
      ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum
     FROM sys.dm_os_wait_stats
     WHERE wait_type NOT IN (
      'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK',
      'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE',
      'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH',
      'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',
      'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER',
      'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
      'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE',
      'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES',
      'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK')
     )
    SELECT
     W1.wait_type AS WaitType,
     CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S,
     CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S,
     CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S,
     W1.WaitCount AS WaitCount,
     CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage,
     CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S,
     CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S,
     CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S
    FROM Waits AS W1
     INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum
    GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage
    HAVING SUM (W2.Percentage) - W1.Percentage < 95; -- percentage threshold
    GO
    

     

    Verifica como esta o nivel de paralelismo no seu servidor tb:

    select 
    		sc.name
    		,sc.value_in_use
    		,si.cpu_count 
    from 
    		sys.configurations sc
    		,sys.dm_os_sys_info si
    where 
    		sc.configuration_id in(1538,1539)
    

     


    http://www.diaadiasql.com.br
    quinta-feira, 24 de março de 2011 17:17
  • Oi Fabrizzio, não sei se essa rotina é realmente lenta ou o meu servidor tá ruim das pernas, o profiler ficou rodando umas 4 horas (eu cancelei a execução, não sabia se deveria deixar ir até o fim ou se tinha fim). O que tem muito é aviso  de HASH Warning. Bem, enfim não entendi muito o arquivo de trace do SQL.

    Gil

    quinta-feira, 24 de março de 2011 20:02
  • Oi Renato, segue os dados:

    Wait Type                  Wait_S         Resource_S   Signal_S   WaitCount   Percentage   AvgWait_S   AvgRes_S   AvgSig_S
    PAGEIOLATCH_SH       35517.35     35372.37      144.99     727670       42.95          0.0488        0.0486      0.0002
    CXPACKET                 33623.40     33603.32      20.08       14378         40.66          2.3385        2.3371      0.0014
    OLEDB                      7133.42       7133.42       0.00          40362294   8.63            0.0002        0.0002      0.0000
    WRITELOG                2079.91       2075.61       4.30          3560          2.52            0.5842        0.5830      0.0012
    ASYNC_NETWORK_IO 1607.71        1549.30      58.41        184108       1.94            0.0087        0.0084      0.0003     

    name                                     value_in_use     cpu_count
    cost threshold for parallelism              5                  2
    max degree of parallelism                 0                   2

    Obrigado por enquanto,

    Gilcimar

    quinta-feira, 24 de março de 2011 22:53
  • Gil,

    Verifique como está a Memória, altere a memória nas propriedades da Instância através do Management Studio.

     

    Altere o Maximum Server memory para 2147483647.

     

    Grato,

     

    Maurício

     

     

     

    • Marcado como Resposta Richard Juhasz segunda-feira, 28 de março de 2011 20:03
    quinta-feira, 24 de março de 2011 22:54
  • Gilcimar,

     

    Por esses dados, eu alteraria o nível de paralelismo para 1.O comando seria esse:

     

    sp_configure 'show advanced options', 1;
    GO
    RECONFIGURE WITH OVERRIDE;
    GO
    sp_configure 'max degree of parallelism', 1;
    GO
    RECONFIGURE WITH OVERRIDE;
    GO
    

    Uma boa fonte esta nesse LINK (blog de Paul Randal).

    []s!



    http://www.diaadiasql.com.br

    • Marcado como Resposta Richard Juhasz segunda-feira, 28 de março de 2011 20:03
    sexta-feira, 25 de março de 2011 01:36
  • Vou verificando aqui, por enquanto obrigado pessoal.

    Gilcimar

    sexta-feira, 25 de março de 2011 11:13
  • Boa tarde, 

    Cara, estou com o mesmo problema aqui no meu servidor, entao li este Post, alterei a memoria conforme maumauboy, e melhorou 80%. pois quando fiz o acompanhamneto pelo perfomance monitor, o acesso ao disco estava muito intenso impedinfo a gravacao no banco. 

     

    Evangelista, 

     

    terça-feira, 5 de abril de 2011 20:07