none
Base de dados lenta RRS feed

  • Pergunta

  • Boa tarde amigos,

    Não sei se alguém já passou pelo problema que estou enfrentado, mas possuo o SQL Server 2008 R2 e tenho uma base de tamanho 10GB que é acessada por um sistema de terceiros, onde  eu criei umas tarefas automaticas como backups, manutenção de base (redução, recriação de index e limpa de tabelas temporárias) e toda vez que o sistema efetua uma pesquisa de uma informação, essas informações retornam para o sistemas lentas, quase que travando.

    Isso não ocorre em todas as máquinas ao mesmo tempo, e sim, aleatoriamente, com 2 maquinas ou 3 no máximo até agora que eu vi.

    Não é vírus, pois já fiz varredura em todas as máquinas com o Symantec e nada foi encontrado e acreditamos que seja algum problema com a base e estamos acreditando que uma hora isso vai travar de alguma forma.

    Alguém já passou por isso e saberia me orientar como proceder neste caso?

    Obrigado a todos e no aguardo de um retorno de alguém.

    quinta-feira, 15 de outubro de 2015 15:28

Respostas

  • José,

    Isso ocorre pela concorrência das consultas/manipulação de dados para o mesmo conteúdo, o que acaba bloqueando alguns usuários e causando o "deadlock".

    Você vai precisar analisar o que pode estar gerando este(s) bloqueio(s) e posteriormente alterar seus scripts T-SQL, inclusive revendo e substituindo os "hints" utilizados (para cada situação).

    Segue abaixo um script T-SQL para ajudar você a identificar o que pode estar sendo afetado:

    SELECT 
      DES.SESSION_ID,
      DES.CPU_TIME,
      DES.READS,
      DES.WRITES,
      DES.LOGICAL_READS,
      DES.ROW_COUNT,
      DER.SESSION_ID,
      DES.STATUS,
      DES.HOST_NAME,
      DES.PROGRAM_NAME,
      DES.LOGIN_NAME,
      DES.ORIGINAL_LOGIN_NAME, 
      DEC.CLIENT_NET_ADDRESS,
      DEC.AUTH_SCHEME,
      DEC.NET_TRANSPORT,
      SUBSTRING(T.[TEXT], DER.[STATEMENT_START_OFFSET] / 2, 
    COALESCE(NULLIF(DER.[STATEMENT_END_OFFSET], - 1) / 2, 2147483647)) AS COMANDO FROM SYS.DM_EXEC_SESSIONS AS DES INNER JOIN SYS.DM_EXEC_REQUESTS DER ON DER.BLOCKING_SESSION_ID = DES.SESSION_ID INNER JOIN SYS.DM_EXEC_CONNECTIONS DEC ON DEC.SESSION_ID = DES.SESSION_ID INNER JOIN SYS.DM_EXEC_REQUESTS DER2 ON DER2.SESSION_ID = DES.SESSION_ID CROSS APPLY SYS.DM_EXEC_SQL_TEXT(DER.[SQL_HANDLE]) AS T GO

    Reveja suas tarefas automáticas, e sempre que possível, deixe agendado para executar em um horário alternativo, para evitar o impacto aos seus usuários.

    Verifique se não existe carga de dados (INSERT/UPDATE em lote) sendo executado concorrendo com seus usuários.

    Se você utiliza transações, verifique se o processo não mantém o bloqueio além do necessário (por consultas ou processos "pesados").

    Isso é algo que só você, conhecendo como funciona a operação deste sistema poderá analisar.


    Para maiores informações veja:

    https://support.microsoft.com/pt-br/kb/224453

    https://technet.microsoft.com/pt-br/magazine/2008.04.blocking.aspx

    http://blogs.technet.com/b/latam/archive/2010/03/18/deadlocks-no-sql-server-2008-o-que-fazer-para-resolv-los.aspx

    https://msdn.microsoft.com/pt-br/library/ms187713.aspx

    https://technet.microsoft.com/pt-br/library/ms181714(v=sql.110).aspx

    https://technet.microsoft.com/pt-br/library/ms189857(v=sql.105).aspx


    Se ajudou na sua solução, não esqueça de marcar como resposta !


    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 15 de outubro de 2015 17:24
  • Existem casos de lentidão que não importa quanto vc tenha de recursos no seu servidor, ele vai dar problema, esses casos muitas vezes estão relacionados com consultas mal feitas do ponto de vista da aplicação e como são ambientes de terceiros não temos acesso.

    É importante verificar a fragmentação dos índices, e se for o caso ajustar.

    Direto da MSDN:

    Reorganizar e recriar índices

    Se vc precisar reorganizar ou recriar TODOS os indices de TODAS as tabelas, utilize o comando sp_MSforeachtable ele vai interar por todas as tabelas de vez, a interrogação [?] é usada como coringa, durante a interação ela é substituída pelo nome da tabela !!!

    USE [Banco]
    /*Reorganizar TODOS os indices de TODAS as tabelas*/
    EXEC sp_MSforeachtable '
    ALTER INDEX ALL ON ?
    REORGANIZE'
    
    /*Recriar TODOS os indices de TODAS as tabelas*/
    EXEC sp_MSforeachtable '
    ALTER INDEX ALL ON ?
    REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
                  STATISTICS_NORECOMPUTE = ON)'

    No link abaixo, tem uma explicação mais detalhada da opção "FILLFACTOR".

    Especificar fator de preenchimento para um índice

    "<sentencetext xmlns="http://www.w3.org/1999/xhtml">A opção fator de preenchimento é fornecida para ajustar o armazenamento e o desempenho de dados de índice.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">Quando um índice é criado ou recriado, o valor de fator de preenchimento determina a porcentagem de espaço em cada página de nível folha a ser preenchida com dados, reservando o restante em cada página como espaço livre para futuro crescimento.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">Por exemplo, a especificação de um valor de fator de preenchimento de 80 significa que 20 por cento de cada página de nível folha ficará vazio, fornecendo espaço para a expansão do índice à medida que dados forem adicionados à tabela subjacente.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">O espaço vazio é reservado entre as linhas do índice e não no final do índice.</sentencetext>"


    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 15 de outubro de 2015 19:14

Todas as Respostas

  • Opa boa tarde,

    Essas rotinas administrativas vc executa no horário de expediente?

    Quando vc executa as queries no servidor elas também ficam lentas?

    Já analisou a rede para ver se ela nao esta com gargalo?


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    quinta-feira, 15 de outubro de 2015 17:09
  • José,

    Isso ocorre pela concorrência das consultas/manipulação de dados para o mesmo conteúdo, o que acaba bloqueando alguns usuários e causando o "deadlock".

    Você vai precisar analisar o que pode estar gerando este(s) bloqueio(s) e posteriormente alterar seus scripts T-SQL, inclusive revendo e substituindo os "hints" utilizados (para cada situação).

    Segue abaixo um script T-SQL para ajudar você a identificar o que pode estar sendo afetado:

    SELECT 
      DES.SESSION_ID,
      DES.CPU_TIME,
      DES.READS,
      DES.WRITES,
      DES.LOGICAL_READS,
      DES.ROW_COUNT,
      DER.SESSION_ID,
      DES.STATUS,
      DES.HOST_NAME,
      DES.PROGRAM_NAME,
      DES.LOGIN_NAME,
      DES.ORIGINAL_LOGIN_NAME, 
      DEC.CLIENT_NET_ADDRESS,
      DEC.AUTH_SCHEME,
      DEC.NET_TRANSPORT,
      SUBSTRING(T.[TEXT], DER.[STATEMENT_START_OFFSET] / 2, 
    COALESCE(NULLIF(DER.[STATEMENT_END_OFFSET], - 1) / 2, 2147483647)) AS COMANDO FROM SYS.DM_EXEC_SESSIONS AS DES INNER JOIN SYS.DM_EXEC_REQUESTS DER ON DER.BLOCKING_SESSION_ID = DES.SESSION_ID INNER JOIN SYS.DM_EXEC_CONNECTIONS DEC ON DEC.SESSION_ID = DES.SESSION_ID INNER JOIN SYS.DM_EXEC_REQUESTS DER2 ON DER2.SESSION_ID = DES.SESSION_ID CROSS APPLY SYS.DM_EXEC_SQL_TEXT(DER.[SQL_HANDLE]) AS T GO

    Reveja suas tarefas automáticas, e sempre que possível, deixe agendado para executar em um horário alternativo, para evitar o impacto aos seus usuários.

    Verifique se não existe carga de dados (INSERT/UPDATE em lote) sendo executado concorrendo com seus usuários.

    Se você utiliza transações, verifique se o processo não mantém o bloqueio além do necessário (por consultas ou processos "pesados").

    Isso é algo que só você, conhecendo como funciona a operação deste sistema poderá analisar.


    Para maiores informações veja:

    https://support.microsoft.com/pt-br/kb/224453

    https://technet.microsoft.com/pt-br/magazine/2008.04.blocking.aspx

    http://blogs.technet.com/b/latam/archive/2010/03/18/deadlocks-no-sql-server-2008-o-que-fazer-para-resolv-los.aspx

    https://msdn.microsoft.com/pt-br/library/ms187713.aspx

    https://technet.microsoft.com/pt-br/library/ms181714(v=sql.110).aspx

    https://technet.microsoft.com/pt-br/library/ms189857(v=sql.105).aspx


    Se ajudou na sua solução, não esqueça de marcar como resposta !


    Abraços,

    Durval Ramos
    Microsoft Partner | MTA | MCSA - SQL Server 2012 | MCSE - Data Platform
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 15 de outubro de 2015 17:24
  • Tiago,

    Essas rotinas são executadas fora do expediente das 20h as 6h da manha do outro dia.

    Quando acontece essa lentidão, sim!

    Já analisei se tem algo a ver com a Rede e a mesma está normal, sem gargalo nenhum. Também achei que fosse a rede, pois na maioria das vezes o que faz cair o desempenho é a rede ou o ponto onde se encontra a máquina problemática, mas me enganei.

    Não sei se tem alguma outra análise além destas que citei devem ser realizadas. E olha que a nossa base é pequena, imagine se fosse 100GB ou teras rsrs Tô sem nenhuma ideia do que pode estar ocasionando isso.

    quinta-feira, 15 de outubro de 2015 17:29
  • José,

    Faça uma analise o que o Durval falou, mas faça uma analise da sua base de dados, analise o planos de execução, talvez os índices não sejam mais eficientes, verifique as estatísticas e valide se as queries estão desenvolvidas da melhor forma.

      


    Se a resposta foi útil por favor classifique. Tiago Neves - @tiagolneves - acesse o meu blog http://www.tiagoneves.net

    quinta-feira, 15 de outubro de 2015 17:53
  • Durval,

    Irei dar uma olhada nesta rotina que me passou e analisar com calma. As minhas rotinas estão sendo feitas fora do intervalo de trabalho, como mencionei, esta sendo executado das 20h as 6h da manha do outro dia, então, não tem impacto com os usuários.

    Tiago,

    Irei com certeza fazer uma análise que o Durval mandou. Acredito que pode ser realmente problema de índices, porem, se for, não poderei mexer, pois estaremos migrando de sistema, ou seja, mudando de fornecedor de sistema, então, não valerá a pena mexer com isso.

    Mas irei avaliar o conjunto todo.

    Obrigado pelas dicas amigos e isso está me ajudando e agregando conhecimento na área.

    quinta-feira, 15 de outubro de 2015 18:28
  • Existem casos de lentidão que não importa quanto vc tenha de recursos no seu servidor, ele vai dar problema, esses casos muitas vezes estão relacionados com consultas mal feitas do ponto de vista da aplicação e como são ambientes de terceiros não temos acesso.

    É importante verificar a fragmentação dos índices, e se for o caso ajustar.

    Direto da MSDN:

    Reorganizar e recriar índices

    Se vc precisar reorganizar ou recriar TODOS os indices de TODAS as tabelas, utilize o comando sp_MSforeachtable ele vai interar por todas as tabelas de vez, a interrogação [?] é usada como coringa, durante a interação ela é substituída pelo nome da tabela !!!

    USE [Banco]
    /*Reorganizar TODOS os indices de TODAS as tabelas*/
    EXEC sp_MSforeachtable '
    ALTER INDEX ALL ON ?
    REORGANIZE'
    
    /*Recriar TODOS os indices de TODAS as tabelas*/
    EXEC sp_MSforeachtable '
    ALTER INDEX ALL ON ?
    REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
                  STATISTICS_NORECOMPUTE = ON)'

    No link abaixo, tem uma explicação mais detalhada da opção "FILLFACTOR".

    Especificar fator de preenchimento para um índice

    "<sentencetext xmlns="http://www.w3.org/1999/xhtml">A opção fator de preenchimento é fornecida para ajustar o armazenamento e o desempenho de dados de índice.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">Quando um índice é criado ou recriado, o valor de fator de preenchimento determina a porcentagem de espaço em cada página de nível folha a ser preenchida com dados, reservando o restante em cada página como espaço livre para futuro crescimento.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">Por exemplo, a especificação de um valor de fator de preenchimento de 80 significa que 20 por cento de cada página de nível folha ficará vazio, fornecendo espaço para a expansão do índice à medida que dados forem adicionados à tabela subjacente.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">O espaço vazio é reservado entre as linhas do índice e não no final do índice.</sentencetext>"


    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 15 de outubro de 2015 19:14
  • Olá Flávio,

    Essa rotina eu já tenho agendada. Eu já executo a reorganização e recriação de índices e mesmo assim, o problema ainda persiste.

    Agradeço pela ajuda.

    quinta-feira, 15 de outubro de 2015 19:50
  • A lentidão ocorre em uma consulta direto do SSMS, feita por você ????
    Certa vez tive um problema de lentidão onde a empresa do sistema, havia criado uma view que demorava muito para ser executada quando acessei, vi que os caras faziam várias voltas sem necessidade, criei uma direta e passei para os Dev´s....

    Em outro caso, era uma consulta da propria ferramenta que dava varias voltas sem necessidade, mas só peguei quando rodei o profile para identificar, entrei em contato e eles ajustaram e atualizaram o software, nos dois casos eu queimei as pestanas pensando que o problema podia ser no banco quando na verdade é no meio de campo.

    Em outro momento eu fui verificar o tamanho das tabelas e identifiquei uma de log´s que os caras auditavam cada instrução do banco, jogando toda a consulta na base, isso com um volume por minuto imenso...cada insert, delete, update era logado !!!!! Esse último ainda estou brigando para eles resolverem, mas também quebrei a cabeça acreditando que era o banco !!!!


    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    sexta-feira, 16 de outubro de 2015 01:18
  • José, boa tarde. 

    Essa rotina de "REDUÇÃO" que você realiza, seria o SHRINK?

    Se for, você faz ela primeiro ou depois do rebuild dos indices?

    abs,


    Vinícius Kleber

    sexta-feira, 16 de outubro de 2015 17:47
  • José,

    Por acaso esta lentidão ocorre somente em funcionalidades específicas desta aplicação?

    Você esta utilizando alguma ferramenta do tipo SQL Server Profiler para monitorar o uso do seu SQL Server quando esta aplicação esta em uso?

    Por acaso esta base de dados foi migrado de alguma outra versão do SQL Server?


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 20 de outubro de 2015 14:43
    Moderador
  • Existem casos de lentidão que não importa quanto vc tenha de recursos no seu servidor, ele vai dar problema, esses casos muitas vezes estão relacionados com consultas mal feitas do ponto de vista da aplicação e como são ambientes de terceiros não temos acesso.

    É importante verificar a fragmentação dos índices, e se for o caso ajustar.

    Direto da MSDN:

    Reorganizar e recriar índices

    Se vc precisar reorganizar ou recriar TODOS os indices de TODAS as tabelas, utilize o comando sp_MSforeachtable ele vai interar por todas as tabelas de vez, a interrogação [?] é usada como coringa, durante a interação ela é substituída pelo nome da tabela !!!

    USE [Banco]
    /*Reorganizar TODOS os indices de TODAS as tabelas*/
    EXEC sp_MSforeachtable '
    ALTER INDEX ALL ON ?
    REORGANIZE'
    
    /*Recriar TODOS os indices de TODAS as tabelas*/
    EXEC sp_MSforeachtable '
    ALTER INDEX ALL ON ?
    REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
                  STATISTICS_NORECOMPUTE = ON)'

    No link abaixo, tem uma explicação mais detalhada da opção "FILLFACTOR".

    Especificar fator de preenchimento para um índice

    "<sentencetext xmlns="http://www.w3.org/1999/xhtml">A opção fator de preenchimento é fornecida para ajustar o armazenamento e o desempenho de dados de índice.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">Quando um índice é criado ou recriado, o valor de fator de preenchimento determina a porcentagem de espaço em cada página de nível folha a ser preenchida com dados, reservando o restante em cada página como espaço livre para futuro crescimento.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">Por exemplo, a especificação de um valor de fator de preenchimento de 80 significa que 20 por cento de cada página de nível folha ficará vazio, fornecendo espaço para a expansão do índice à medida que dados forem adicionados à tabela subjacente.</sentencetext><sentencetext xmlns="http://www.w3.org/1999/xhtml">O espaço vazio é reservado entre as linhas do índice e não no final do índice.</sentencetext>"


    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    José, um ponto importante é que após processos de manutenção na sua base é importante atualizar as estatísticas das consultas.

    EXEC sp_updatestats;

    Direto do BOL !!!!

    UPDATE STATISTICS (Transact-SQL)

    Estatisticas



    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"


    terça-feira, 20 de outubro de 2015 18:26
  • Olá Flavio,

    Desculpa pela demora em responder, mas a lentidão ocorre em dias exporádicos e aleatorios as máquinas, onde o sistema efetua uma leitura de uma determinada pesquisa e quando ele busca as informações, o sistema vai mostrando em camera lenta, é como se o sistema estivesse com problema só que não é, é a base que está com gargalo que não sei identificar.

    terça-feira, 20 de outubro de 2015 19:43
  • Olá Vinicius,

    Eu executo o rebuild dos indices primeiro e depois executo o shrink da base.

    Porque? tem alguma influência na ordem?

    terça-feira, 20 de outubro de 2015 19:44
  • Pedro Galvão,

    Essa lentidão ocorre no sistema como um todo, qualquer funcionalidade, porém, ocorre em 1, 2 ou 3 máquinas simultâneas.

    Não estou usando o sql profiler, pois acredito que não seja problema com o sql em si, talvez algum problema com a base que eu desconheço.

    Esta base não foi migrada de uma versão para outra.

    terça-feira, 20 de outubro de 2015 19:46
  • Desta eu não sabia Flavio, valeu pela dica! Irei criar um job depois de executar todo o processo de manutenção da minha base.
    terça-feira, 20 de outubro de 2015 19:47
  • José,

    Ok, então você não acredita que seja problema do SQL Server, mas desconfia do banco de dados!!!! Neste servidor, existe alguma outra base de dados?

    Este banco de dados é composto por mais de um filegroup? Ele esta armazenado na mesma unidade de disco dos demais bancos?


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 20 de outubro de 2015 22:21
    Moderador
  • Olá Vinicius,

    Eu executo o rebuild dos indices primeiro e depois executo o shrink da base.

    Porque? tem alguma influência na ordem?

    Vc executa rebuild e o shrink, logo OBRIGATORIAMENTE vc precisa atualizar suas estatísticas, consequentemente seus planos de execução já criados são excluídos e cada nova consulta precisa refazer o processo, o ideal é vc verificar a periodicidade desses procedimentos pois se a frequência for grande vc mesmo pode está degradando a performance, digamos que vc faça isso todo domingo, na segunda feira a cada nova consulta o servidor precisa recriar o plano de execução pois vc atualizou seus metadados.. Além disso, como vc não atualiza as estatísticas, ele tenta atender sua consulta usando um plano de execução que não é mais o correto !!!!


    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    terça-feira, 20 de outubro de 2015 23:05
  • Pedro, não existe outra base de dados, somente ela que está com o nosso sistema interno.

    Eu não acredito que seja problema do SQL Server em si, mas estou muito desconfiado da base, porém todas as manutenções que eu sei e possíveis estou realizando. A pesquisa fica lenta se eu executo alguma função do sistema interno nosso, é como se o sistema executasse em camera lenta.

    Não sei se resolveria o problema se eu fizesse um backup do sistema e recriasse a base e restaurasse, o que você acha Pedro? Surtiria algum efeito? Acredito que você é muito experiente e pode me orientar nisso. Com certeza isso seria de um enorme aprendizado para mim, pois nunca passei por este estagio de problema, muito menos vi isso em cursos.

    quinta-feira, 22 de outubro de 2015 18:27
  • Sugiro que faça um backup e restaure em OUTRA base....

    E a partir dai simule algumas consultas....e se tiver como, aponte o sistema para ela para efeito de teste.. isso não impactaria no seu ambiente de produção !!!


    Flávio Farias
    "May the Force be with you"
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"

    quinta-feira, 22 de outubro de 2015 19:24
  • José boa tarde, execute a query abaixo para ver quais são os wait type;

    DBCC SQLPERF ('SYS.DM_OS_WAIT_STATS', CLEAR)

    SELECT TOP 20
    [WAIT TYPE] = WAIT_TYPE,
    [WAIT TIME (S)] = WAIT_TIME_MS / 1000,
    [% WAITING] = CONVERT(DECIMAL(12,2), WAIT_TIME_MS * 100.0
    / SUM(WAIT_TIME_MS) OVER())
    FROM SYS.DM_OS_WAIT_STATS
    WHERE WAIT_TYPE NOT LIKE '%SLEEP%'
    ORDER BY WAIT_TIME_MS DESC


    Vinícius Kleber

    quinta-feira, 22 de outubro de 2015 19:30
  • Bom dia Flavio,

    Eu fiz isso, mas ficou normal. Estou pensando seriamente em migrar essa base para um outro servidor que temos e separarmos os 2 sistemas que temos, não sei se é isso que pode estar ocasionando o problema, mas é uma possibilidade. É porque em um servidor eu tenho o sistema que usamos hoje e uma VM rodando no mesmo servidor e dentro da VM o sistema que iremos migrar ano que vem que é o sistema da TOTVS.

    Acredito que seja por isso que está deixando a base lenta, não posso afirmar de certeza, so depois que executar o teste.

    Depois posto aqui a todos a solução do meu problema.

    terça-feira, 27 de outubro de 2015 12:06
  • Ja tentou acompanha pelo active monitor o AIO? Isso te ajuda a identificar quais bancos estão com AIO pesado, você também  pode acompanhar pelo gerenciador de tarefas do windows para saber saber como ta o consumo de RAM se tiver consumindo mt pode ser alguma aplicação terceira ou mesmo alguma consulta pesada ou sem lock consumindo recurso no banco.
    terça-feira, 27 de outubro de 2015 12:15
  • José,

    Como esta configurada a memória e disco rígido desta máquina virtual? Por acaso você esta trabalhando com alocação dinâmica?


    Pedro Antonio Galvao Junior [MVP | MCC | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | Professor Universitario | SoroCodigos | @JuniorGalvaoMVP | http://pedrogalvaojunior.wordpress.com]

    terça-feira, 27 de outubro de 2015 12:52
    Moderador
  • Jose,

    Cual ea version de SQL Server? Standard, Enterprise? X64, X32?

    Como esta configura, Max Memory, Min Memory, max degree of parallelism?

    Tem o plan de ejecucion da query?

    Como sao os valores o Perfmon:

      Memory: Pages/sec

      Processor: % CPU Usage

      PhysicalDisk: Avg. Disk Queue Length


    Carlos Ignacio Aguero. DBA SQL Server. Toda mi respeto al pueblo Peruano por la ayuda prestada en la guerra de Malvinas.

    terça-feira, 27 de outubro de 2015 14:14