none
SQL Server 2008 picos de consumo de memória após migração RRS feed

  • Pergunta


  • Oi pessoal, tudo bem?

     

    Eu estou precisando de uma ajuda.

    Até alguns meses atrás estávamos usando Windows Server 2003, SQL Server 2000 Std. em uma Maquina Dell PowerEdge, com 2 processadores Xeon 3Ghz x32, 3GB RAM, HD's SCSI, as bases estavam divididas em 2 Pools de discos com Raid 5. Tudo funcionava muito bem.

    Resolvemos trocar a maquina por um outro Dell, mas com arquitetura de x64. Agora são 2 XeonE5410 Quad Core, 8GB RAM, HD's SAS em um único pool com raid 10, com Windows Server 2008 SP2 x64,  SQL Server 2008 (SP1) - 10.0.2531.0 (X64).

     

    Deixei o SQL Server configurado para usar toda a memória disponível, então o sistema sempre está com muita memória alocada: Total: 8186, Cached: 534, Free 0, mas a maquina roda muito bem em 99% do tempo, porém em alguns momentos temos picos de processamento. E estes picos de processamento fazem o banco parar de responder, mas eu consigo logar no Windows e ver o Resource Monitor, nestes momentos o processamento está em quase 100% em todos os processadores. A memória permanece inalterada. Pelo Task Manager dá pra ver que o processamento está sendo consumido pelo SQL Server, mas disco e rede estão com utilização igual ao normal. O problema é que eu não consigo descobrir o que pode estar gerando o problema.

    Deixei um SQL Profiler em execução logado apenas dados relevantes para tentar pegar o problema, mas como a query só aparece no sql profiler depois de concluída, e este problema gradativamente desconecta todas as maquinas do banco, não consigo descobrir o "responsável".

    Tenho planos de manutenção de índice e estatísticas rodando semanalmente.

    Existe alguma outra forma de registrar os processos que estão consumindo muito recurso ou até limitar o máximo de recurso de um único processo pode alocar para preservar a maquina em geral?

    Nos momentos em que este problema ocorre aparecem os seguintes error no EventViewer:

    • 701, MSSQLSERVER, There is insufficient system memory to run this query.
    • 17300,MSSQLSERVER, Server SQL Server was unable to run a new system task, either because there is insufficient memory or the number of configured sessions exceeds the maximum allowed in the server. Verify that the server has adequate memory. Use sp_configure with option 'user connections' to check the maximum number of user connections allowed. Use sys.dm_exec_sessions to check the current number of sessions, including user processes.
    • 17803, MSSQLSERVER,Logon        There was a memory allocation failure during connection establishment. Reduce nonessential memory load, or increase system memory. The connection has been closed. [CLIENT: ip]
    • 18056, MSSQLSERVER,  The client was unable to reuse a session with SPID 427, which had been reset for connection pooling. The failure ID is 29. This error may have been caused by an earlier operation failing. Check the error logs for failed operations immediately before this error message.

    Já olhei no sp_configure e ele não está limitando o nr. Máximo de conexões:

     

    configuration_id

    name

    value

    minimum

    maximum

    value_in_use

    description

    103

    user connections

    0

    0

    32767

    0

    Number of user connections allowed

     

    Alguém tem alguma dica de como posso descobrir a fonte do problema?


    Obrigada,


    Luana.

    terça-feira, 9 de fevereiro de 2010 12:07

Todas as Respostas

  • Luana,

    Você realizou a alteração do nível de compatibilidade?

    Atualizei as estatísticas de índices e do seu banco de dados?
    Pedro Antonio Galvão Junior - MVP - Windows Server System - SQL Server/Coordenador de Projetos/DBA
    terça-feira, 9 de fevereiro de 2010 15:33
    Moderador
  • Luana,
    O questionamento do Junior sobre as atualizações de indeces e estatisticas é importante quando fazemos migração. Considerando que você tenha feito esse procedimento e mesmo assim continua o erro podemos considerar outros itens:

    1. A sua instancia SQL Server 2005 X64 está com SP3 + CUP06 (Build:9.00.4226 ) ver mais   ou superior?
    2. O Arquivo de paginação do Windows Server está corretamente dimencionado (Arquivo com pelo menos 4GB)?

    Veja se os itens acima estão OK na sua instancia e retorne para que possamos ajuda-la.

    []´s


    Blog - Leivio Fontenele
    http://leivio.spaces.live.com/

    MCP | MCTS | MCITP - DBA SQL Server Sênior http://leivio.spaces.live.com/ | http://br.linkedin.com/in/leivio
    terça-feira, 9 de fevereiro de 2010 16:54
  • Luana,

    Pessei por um problema semelhante brincando com meu SQL em casa. (Win2008_SP2_32Bits + SQL2008_SP1_32Bits)
    Eu criei após efetuar a instalação do SQL adicionei mais uma partição para fazer uns testes com o TempDB, criei mais um datafile para o TempDB nesta nova partição.
    Após efetuar este procedimento o SQL se manteve normal até precisar usar o TempDB. A máquina simplesmente parava, e os sintomas eram os mesmos do seu caso (exceto pelas mensagens de erro que eu não me lembro agora) CPU em 100%, disco e memória em valores normais.
    Descobri que era falta de permissão para o usuário do serviço do SQL para gravar/ler esta nova partição.

    Não sei se ajuda mas não custa checar.

    Att,
    Ricardo Muramatsu
    http://ricardomura.spaces.live.com
    terça-feira, 9 de fevereiro de 2010 18:55
  • Luana,

    o Windows é multi-thread, ou seja, um único processo é dividido em vários threads. O Serviço do SQL SErver DB engine é um processo que gera vários threads, inclusive um para cada conexão ao SQL Server. Isto complica a monitoração de consumo de CPU porque você simplesmente vê o processo do SQL Server consumindo CPU mas não cosegue descobrir facilmente qual conexão está causando tal comportamento.

    No entanto, existe uma maneira de você descobrir qual thread do SQL Server que é responsável pelo alto processamento. Com esta informação em mãos, você poderá checar os processos(SPID) dentro do SQL Server para ver qual conexão está gerando o alto consumo. Para isso você precisará usar o Sysmtem Monitor(antigo Performance Monitor) para descobrir esses threads e checar quanto consome cada thread do SQL Server e o número d thread vai ser o SPID da conexão.

    Espero ter ajudado.



    Se a resposta resolveu sua questão ouproblema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    quarta-feira, 10 de fevereiro de 2010 21:58
  • Verdade Alex,

    Se a Luana achar interessante essa checagem pode usar esse script para ver como estão as coisas no server:
    select
    	spid
    	,status
    	,sid
    	,hostname
    	,program_name
    	,cmd
    	,cpu
    	,physical_io
    	,blocked
    	,dbid
    	,convert(sysname, rtrim(loginame))
    	as loginname
    from 
    	master.dbo.sysprocesses with (nolock)

    http://ricardomura.spaces.live.com
    quinta-feira, 11 de fevereiro de 2010 00:21
  • Luana, para fazer a correlação do thread do Windows com SPID da sysproceses, pode usar o método descrito nesse link: http://support.microsoft.com/kb/117559/en-us
    Se a resposta resolveu sua questão ouproblema, classifique-a para manter a qualidade do forum e a confiabilidade dos participantes.

    Alex M. Bastos
    http://bastosalex.spaces.live.com
    quinta-feira, 11 de fevereiro de 2010 12:11
  • Junior, tudo bem?

    Muito Obrigada pela resposta.
    A atualização de estatísticas e recriação dos indices ocorre semanalmente para todas as bases de dados.
    Sobre o nível de compatibilidade, alguns bancos estão com nível SQL Server 2000 (80), pois durante homologação antes da migração verificamos que certas aplicações não funcionavam sem está configuração. Isso também foi sugerido pela ferramente sql server upgrade advisor para algumas bases.
    Mas nem todas estão assim, bases de sistemas mais novos já usam compatibilidade com SQL Server 2008.

    Obrigada,

    Luana.
    quinta-feira, 11 de fevereiro de 2010 15:46
  • Leivio, 

    Obrigada pela atenção, sobre as suas perguntas:

    1) Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)   Mar 29 2009 10:11:52   Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.0 <X64> (Build 6002: Service Pack 2) 

    2)A configuração de memória de paginação está configurada automaticamente pelo Windows: Minimo: 16MB, Recomendado: 12279MB, Atual: 8486MB

    Aguardo alguma sugestão.

    Obrigada,

    Luana.
    quinta-feira, 11 de fevereiro de 2010 15:51
  • Oi Ricardo,

    Obrigada pela post.

    Meu SQL roda sobre uma conta de domínio sem privilégios de administrador (tanto no dominio quanto na maquina local).
    Para que a conta tivesse as permissões adequadas, fiz a configurações do usuário que rodaria o serviço pelo SQL SERVER CONFIGURATION MANAGER.

    Loguei com a conta que roda este serviço na maquina do SQL Server e foi acessar a pasta onde está o TempDB, e já ao acessar a pasta recebi a mensagem de acesso negado.
    Olhei a configuração da pasta onde está o TEMPDB e existe a seguinte permissão para uma conta do SQL Server: "SQLServerMSSQLUSER$NOMEDAMAQUINA$MSSQLSERVER(NOMEDAMAQUINA\SQLSERVERMSSQLUSER$NOMEDAMAQUINA\MSSQLSERVER)" tem Full Control sobre a pasta.

    Vou estar alterando as permissões desta pasta, e retorno com os resultados.

    Obrigada pela ajuda.

    Luana.
    quinta-feira, 11 de fevereiro de 2010 16:06
  • Oi Alex, 

    Obrigado pela ajuda.
    Eu já tenho usado o system monitor para acompanhar a performance da maquina.
    O maior problema é que quando o erro ocorre eu perco o acesso a sql server. todas as conexões são bloqueadas.

    Obrigada,

    Luana.
    quinta-feira, 11 de fevereiro de 2010 16:08
  • Oi Ricardo,

    Então o unico problema é que quando o erro ocorre perco o acesso ao SQL Server Management Studio. Ele diz que não tem recursos suficientes para atender a minha requisição de conexão, e a tabela sysprocesses loga apenas o trafego corrente e não dados históricos. Como no momento em que o problema ocorre minha conexão com o banco cai, eu não consigo rodar este select para descobrir o que está dando errado.....

    Obrigado pela ajuda.

    Luana.

    quinta-feira, 11 de fevereiro de 2010 16:13
  • Luana,
    Aumente a área MEMTOLEAVE colocando nos parametros de inicialização o "–g512" caso não resolva aplique o FIX CUP04 para SQL Server 2008 SP1 .

    Correção : O uso da CPU e o uso de memória aumentam gradualmente e muitas identificações de sessão são no status inativo no SQL Server 2005 e no SQL Server 2008 .

    No final de maio do ano passado dois servidores  SQL Server 2005 X64 com 128GB de RAM e 32Cores  que administro apresentaram problemas como esses descrito na correção. Os problema foram devido a bugs no Service Pack 3(SP3).  Apos aplicação de FIX resolveu o problema de CPU 100%, mas o FIX instalado tinha outro bug ue só foi corrigido pela MS em dezembro de 2009. Acredito que a aplicação desse FIX possa solucionar seu problema.

    Apos a instalação do FIX fique monitorando a sua instancia para indentificação de possiveis bugs. e envio imediato para o Connect SQL Server .

    []´s

    Blogs Leivio Fontenele
    http://leivio.spaces.live.com/blog/cns!A9C38548B0E679DB!239.entry

    MCP | MCTS | MCITP - DBA SQL Server Sênior http://leivio.spaces.live.com/ | http://br.linkedin.com/in/leivio
    quinta-feira, 11 de fevereiro de 2010 16:40
  • Oi Alex,

    Estarei verificando o artigo e espero postar a solução do problema aqui em breve.
    Caso mais alguém tenha alguma sugestão será bem vinda.

    Obrigada,

    Luana.
    quinta-feira, 11 de fevereiro de 2010 16:47
  • Luana,

    A pasta onde ficam os arquivos do tempdb não necessitam demais configurações, a não ser que você tenha adicionado mais datafiles em outras pastas/drives.

    Através do SQLCmd será que você conseguiria acessar para coletar as informações do sysprocesses?
    Se conseguir tente fazer isso:
    c:\sqlcmd -d master -q "select * from sysprocesses

    O resultado é ruim de ver mas vc ainda pode jogar para um arquivo assim:
    c:\sqlcmd -d master -q "select * from sysprocesses -o c:\resultado.txt

    Você saberia identificar qual o processo está acarretando este problema?
    Ocorre em horários específicos? Se sim, tente descobrir quem executa estes processos.
    Como está o espaço em disco antes e durante o processo?

    Existe um pack de atualização que você pode tentar instalar, mas eu acho que deve esperar mais opiniões do pessoal deste forum com relação a este procedimento, se desejar veja o KB http://support.microsoft.com/default.aspx/kb/973602



    http://ricardomura.spaces.live.com
    quinta-feira, 11 de fevereiro de 2010 16:47
  • Ricardo,

    Com relação ao seu questionamento sobre os horário é tudo muito aleatório. O problema já ocorre a algumas semanas, e é intermitente. Estou rodando um profiler na maquina e através dele vejo as transações que consomem mais recursos, porém o maior problema é que o SQL corta as conexões, e isso corta o log do SQL Profiler e me impede de consultar através de instruções SQL quem gerou o trafego, pois eu só consigo me conectar no sql server quando o processamento volta a niveis normais.
    Eu continuo tendo acesso ao Windows, consigo ver o Gerenciador de Tarefas e Monitor de Recursos, só não consigo conexão com o serviço do SQL.

    Realmente acho que o problema não é permissão, pois chequei com a ferramenta AccessChk da MS e segue abaixo as permissões do usuário que roda os serviços do SQL.

    RW E:\Database\MSSQL10.MSSQLSERVER\MSSQL\DATA\tempdb.mdf
    RW E:\Database\MSSQL10.MSSQLSERVER\MSSQL\DATA\templog.ldf

    Com relação ao espaço em disco, temos mais de 300GB livres e o espaço não tem se alterado.

    Vou monitorar o sysprocess, como vocês disseram. Também vou aplicar as patchs em ambiente de homologação. O maior problema é que ainda não consegui reproduzir este erro em homologação que é um ambiente bem parecido: Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64)   Mar 29 2009 10:11:52   Copyright (c) 1988-2008 Microsoft Corporation  Standard Edition (64-bit) on Windows NT 6.0 <X64> (Build 6002: Service Pack 2)

    A documentação que gerei após criar este ambiente de homologação foi o que usei para criar a maquina de produção, elas estão muito parecidas, com excessão do fornecedor do hardware e que a maquina de homologação tem apenas 4GB de RAM, enquanto a de produção tem 8GB.

    Assim que achar uma solução, coloco no fórum.
    Enquanto isso, toda sugestão é bem vinda.

    Obrigada,

    Luana. 
    quinta-feira, 11 de fevereiro de 2010 19:50
  • Luana,

    Você disse em seu primeiro post:
    "Agora são 2 XeonE5410 Quad Core"

    E a documentação do SQL diz:
    "Number of CPUs 4"
    Ref.: http://www.microsoft.com/sqlserver/2008/en/us/compare-std-ent.aspx

    No seu caso você teria 8 cores se estiver ativo Hypertreading seriam 16. Acho que vale a pena checar de que forma o SQL 2008 Std interpreta essas informações.

    Outra coisa a se considerar é a forma como você migrou essas bases, você fez um Detrach/Attach ou um Backup/Restore?
    Caso tenha feito um Attach/Dettach existe a possibilidade de refazer usando backup/restore?
    Após a migração você checou as informaçoes sobre as contas de usuários?

    http://ricardomura.spaces.live.com
    quarta-feira, 17 de fevereiro de 2010 10:27
  • Oi Ricardo,

     

    Desculpe a demora.

    Na realidade são 2 CPUs (socket) Quad Core, então o Windows entende como 8 processadores.

    A base de dados foi restaurada, não foi por attach/detach.

    Já rodamos o DBCC Chekdb e elas estão em ordem.

    Descobrimos uma maquina com problema na placa de rede, gerando um trafego enorme, a ponto de derrubar o switch e depois que corrigimos isso o problema mencionado acima diminuiu muito, mas as vezes (agora bem raramente e por poucos minutos) se olhar no log do SQL Server a mensagem "There is insufficient system memory to run this query" está sendo exibida.

    Olhamos a configuração da maquina e vimos que os 8GB de RAM da maquina estavam sendo consumidos e que o pico de utilização de memória era 11GB (8GB RAM + 3GB pagefile). E estavamos tendo muito "Hard Faults/sec" nos contadores de memoria.

    Acrescentamos mais 8GB de RAM a maquina e acreditávamos que desta forma não teríamos mais os "Hard Faults/sec" nos contadores de memória e que o pico de utilização permaneceria em 11GB, porém sem o uso do pagefile, mas não foi bem o que aconteceu.

     

    Agora o SQL esta usando 15,7GB de RAM e o pico de utilização foi para 18GB (somando-se RAM + Pagefile) e ainda temos os "Hard Faults/sec" de memória.

    Até agora não tive a mensagem "There is insufficient system memory to run this query" , mas este comportamento está me incomodando bastante.

    Antes tinhamos uma maquina muito mais fraca e não tinhamos este problema.

    As aplicações que usamos são as mesmas, a única coisa que vejo de diferente é a arquitetura, saimos de uma maquina de 32bits com Windows Server 2003 e SQL 2000 para 64 bits com Windows Server 2008 x64 e SQL Server 2008 x64.

    Alguém tem alguma idéia sobre isso?

    É normal? Existe alguma configuração a ser feita?

    O pagefile está sendo administrado pelo windows e o sql está livre para usar o quanto de memória for necessário, devo alterar estas configurações?

     

    Obrigada,

     

    Luana.

    terça-feira, 6 de abril de 2010 20:25
  • A licensa do SQL eh por sockets. No caso da Luana, a maquina tem 2 sockets (ou processadores fisicos), entao a licensa permite o uso de todos os processadores logicos na maquina.


    Fabricio Voznika [MSFT], SQL Server Storage Engine Team
    quarta-feira, 7 de abril de 2010 20:09
  • A licensa do SQL eh por sockets. No caso da Luana, a maquina tem 2 sockets (ou processadores fisicos), entao a licensa permite o uso de todos os processadores logicos na maquina.


    Fabricio Voznika [MSFT], SQL Server Storage Engine Team
    quarta-feira, 7 de abril de 2010 20:10
  • MEM_TO_LEAVE nao eh necessario em x64 ou IA64 e eh ignorado.
    Fabricio Voznika [MSFT], SQL Server Storage Engine Team
    quarta-feira, 7 de abril de 2010 22:13
  • Luana, tem varios pontos e pergutas interessantes aqui. Vou tentar responder o que for possivel.

    O SQL gerencia memoria de forma a otimizar performance o maximo possivel. Isso quer dizer que ele vai usar o maximo de memoria possivel para evitar acesso ao disco. A quantidade de memoria usada eh baseada na quantidade de memoria fisica disponivel (e nao virtual).

    Quanto aos erros de falta de memoria, antes de executar qualquer query, o engine de execucao faz uma estimativa de quanta memoria eh preciso para executar a query e pre-reserva a memoria. Verifique o plano de execucao da query que falhou pra ver se nao tem nenhum problema de statisticas e pra achar jeitos de fazer a query ser mais eficiente. Existes outros motivos pra erros de memoria, mas esse seria o ponto iniciar pra investigar o problema.

    Em modo geral, x64 requere mais memoria do que x86, mas nao muito mais. Enderecos de memoria aumentam de 32-bits pra 64-bits e a granularidade do cache tambem muda. Quanto mais de memoria eh preciso eh dificil de prever e eh muito dependente do tipo de applicacao.

    Sobre hard faults, nao eh fora do comum ter alguns hard faults num sistema rodando varias coisas. Quantos faults por segundo vc tah tendo em media? Tem mais alguma coisa alem do SQL rodando na maquina? Como qual ferramenta vc estah medindo hard faults?

     


    Fabricio Voznika [MSFT], SQL Server Storage Engine Team
    quarta-feira, 7 de abril de 2010 22:17
  • Oi Fabricio,

    Obrigada pelas informações.

    A maquina é dedicada ao sql server apenas.

    Nosso plano de manutenção realizado semanalmente atualiza as estatísticas e recria o índice. E ai já tem uma coisa que eu não consigo entender, logo depois de rodar o plano de manutenção, faço a consulta abaixo para ver a fragmentação dos índices: 

     

     

    SELECT cast (DB_NAME (database_id) as varchar (30)) as 'db', cast (OBJECT_NAME(object_id, database_id) as varchar (80)) as 'indice',avg_fragmentation_in_percent

    FROM sys.dm_db_index_physical_stats (NULL, NULL, NULL, NULL, NULL) 

    WHERE avg_fragmentation_in_percent >= 15

    order by avg_fragmentation_in_percent desc; 

    GO

     

     

    E eu imaginava que nada retornaria fragmentado, ou que apenas índices muito pequenos continuariam fragmentados, mas não é isso que ocorre, conforme podemos ver no exemplo abaixo:

     

    db indice avg_fragmentation_in_percent fragment_count avg_fragment_size_in_pages page_count X zzzzz 64.936.582.109.479.300 4868 89.348.808.545.603.900 43495 XX aaaa 49.887.048.192.771.000 2651 1.602.980.007.544.320 42495 XX bbbbb 72.569.548.309.901.200 2430 10.996.296.296.296.200 26721 X ccccc 229.607.250.755.287 457 34.759.299.781.181.600 15885

     

    O meu FillFactor está o default (0), não sei se este é o motivo, mas o fato é que rodo o plano de manutenção num horário que ninguém está usando a base, então porque a fragmentação permanece mesmo após o plano de manutenção?

     

    Sobre os page faults, usei os contadores do Windows:

     

     

    Name Min Avg Max Hourly Trend Std      Deviation 90th           Percentile 80th Percentile 70th Percentile Memory\Page Faults/sec     9.574     40.970     60.040             -50         4.318           41.558       41.944         42.112

     

     

    Name Min   Avg Max Hourly Trend Std     Deviation 90th      Percentile 80th    Percentile 70th Percentile \Process(_Total)\Page
    Faults/sec        9.574    40.429    55.554         -19 4.333 41.029 41.425 41.644

     

    Quanto a query que falhou como a maquina trava e não consigo acessá-la nem através do comando: sqlcmd -S <servername> -U sa -P <sa_senha> -A -i c:\scripts\<minha consulta>.sql -o c:\scripts\resultado.rpt, não consigo determinar qual é a query que está originando o problema, pois o sql não roda a consulta, nem mesmo a mais simples como um sp_who, ele diz que não tem recursos para executar esta query.

    Alguma idéia de como posso descobrir? Já tentei usar o profiler também, mas não consegui pegar a origem do problema.

    Tks,

     

    Lu.

    segunda-feira, 12 de abril de 2010 18:57
  • Os contadores de page faults incluem soft and hard faults. Soft faults geralmente nao criam problemas de performance e eh normal ter alguns faults. O numero de page faults que vc reportou eh bem pequeno e nao estaria causando problemas nem se fossem hard faults. Cada pagina eh 4KB, no pior dos casos 60 hard faults/sec daria 245KB/sec total, o que muito pouco pra causar problemas.

    Se vc quiser olhar hard faults use o contador Memory\Pages/sec.

    Sobre o error de memoria, seria interessante se vc pudesse mandar o errorlog apos o erro. Erros de memoria normalmente enviam um sumario do uso de memoria pro errorlog que ajudaria a encontrar o problema. vc tambem pode executar 'dbcc memorystatus' periodicamente e guardar o resultado pra ver se alguma coisa muda antes do erro.

    Se profiler nao estah functionando, vc pode tentar usa Extended Events que eh muito mais eficiente. O codigo abaixo registra num arquivo todas as queries e SPs executadas e todos os erros. Assim vc pode tentar relacionar a query com o erro.

    Crie diretorio c:\temp
    CREATE EVENT SESSION oom ON SERVER
        ADD EVENT sqlserver.sp_statement_starting (action (sqlserver.session_id, sqlserver.sql_text)),
        ADD EVENT sqlserver.sql_statement_starting (action (sqlserver.session_id, sqlserver.sql_text)),
        ADD EVENT sqlsos.exception_ring_buffer_recorded (action (sqlserver.session_id, sqlserver.sql_text))
        ADD TARGET package0.asynchronous_file_target (set filename='c:\temp\oom.xel')
    GO
    ALTER EVENT SESSION oom ON SERVER STATE = start
    GO

    Espere o erro acontecer, pare a coleta de eventos e leia o arquivo:

    ALTER EVENT SESSION oom ON SERVER STATE = stop
    GO
    SELECT *, CAST (event_data as XML) FROM
          sys.fn_xe_file_target_read_file('c:\temp\oom*.xel', 'c:\temp\oom*.xem', NULL, NULL))
    GO

    MSDN tem mais informacoes sobre Extended Events. Espero que isso ajude.


    Fabricio Voznika [MSFT], SQL Server Storage Engine Team
    quinta-feira, 15 de abril de 2010 07:45
  • Obrigado Fabrício,

     

    Vou fazer isso.

    Posterei os resultados aqui.

     

    Tks,

     

    Luana.

    segunda-feira, 19 de abril de 2010 12:14
  • Luana,

    Vc conseguiu resolver este seu caso?

    Estou passando por algo parecido e encontrei seu post...Pode postar como resolveu por favor.

     

    Obrigada,

    Rubia.

     


    Rubia Teles
    sexta-feira, 13 de janeiro de 2012 16:54
  • Consegui resolver da seguinte forma:

    Alter database tempdb modify file
    ( Name = 'tempdev', size = 20)

    Alter database tempdb modify file
    (Name = 'templog', size = 1)
    dbo.tempdb_space_usage dbo.sp_sampleTempDbSpaceUsage

    em seguida reiniciei a instância e pronto.

    Tem um link muito bom da Microsoft:

    http://support.microsoft.com/kb/307487.

    Creio que vc já resolveu, mas é bom postar a solução, pq quado estamos pesquisando nos deparamos com questões iguais às nossas e sem a solução. Nada mais frustrante!

    Rubia Teles
    • Sugerido como Resposta Rubia Teles terça-feira, 17 de janeiro de 2012 13:43
    terça-feira, 17 de janeiro de 2012 13:43
  • Pessoal, somente incrementando o post da Luana, que foi um dos mais completos sobre os problemas do SQL na arquitetura 64 bits. Tive problemas após migrar para o sql2008 R2 a partir de um SQL 2000. Primeiro tive que limitar em 60% a memoria, senão não deixava memoria para o S.O. trabalhar e consequentemente gerava os erros de falta de memoria para executar a consulta, semelhente aos problemas relatados no post original.
    Tive ganhos enormes com o backup, usando a compactação e reduzindo janelas de backup.
    Tive um aumento alto de consumo de CPU em rotinas que antes (SQL 2000 32 bits rodando em win 2003 64 bits) rodavam sem problemas. Este topico aqui ficou muito bom.  

    Abraço a todos.

    quarta-feira, 2 de maio de 2012 13:48