none
There is insufficient system memory in resource pool 'internal' to run this query. RRS feed

  • Pergunta

  • Boa tarde,

    Pesquisei e tentei sem sucesso todas as soluções referente ao erro do enunciado. O mesmo ocorre ao rodar o CHECKDB conforme retorno abaixo:

    Date and time: 2014-02-11 18:13:47
    Command: DBCC CHECKDB ([XXXXXXXXXXX]) WITH NO_INFOMSGS, ALL_ERRORMSGS, PHYSICAL_ONLY
    Msg 8921, Level 16, State 1, Line 1
    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
    Outcome: Failed
    Duration: 00:00:18
    Date and time: 2014-02-11 18:14:05
     
    Date and time: 2014-02-11 18:14:05
    Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'internal' to run this query.
    

    Já identifiquei e existe uma tabela que retorna "There is insufficient system memory in resource pool 'internal' to run this query." para qualquer operação que tento fazer com ela, desde um simples SELECT * FROM XXXXXXXXXXXXX até REBUILD em índices (que é onde acho que está o problema), onde através do comando UPDATE STATISTICS identifiquei o problemático, porém não consigo recria-lo, exclui-lo enfim nada. 

    Alguma sugestão ?

    Junior


    Junior

    terça-feira, 11 de fevereiro de 2014 19:37

Respostas

  • Pessoal está se atentando muito a mensagem de erro  de falta de memória do resource governor e pouco ao fato que nem mesmo um simples select está funcionando... além do mais, ele estava usando o sql express, o resource governor nem sequer estava habilitado já que não está disponível nessa versão do produto. 

    Procurando pela mensagem Check terminated. A failure was detected while collecting facts. joga a gente para diversos resultados, inclusive uma thread em um forum onde o próprio Paul Randall que escreveu o DBCC CheckDB informa que isso é corrupção dos metadados e que não tem solução a não ser restaurar um backup... 

    sugiro dar uma olhada nesse post e tentar os passos que ele indica para verificar os metadados e ver se não é esse o caso: http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55422 


    Felipe Ferreira - @SQLBoy SQL Server MVP | SolidQ Mentor | Friends of RedGate http://www.templar.com.br/blogs/felipe

    sexta-feira, 14 de fevereiro de 2014 17:01
  • Bom dia pessoal,

    Após toda a ajuda e já partindo para recuperar o que conseguir de dados da tabela através de um backup, restaurei no servidor ENTERPRISE o backup da base e iniciei as ações, seguem os resultados:

    1 - tentativa de exclusão de index:  
    ERRO: Msg 701, Level 17, State 123, Line 2
    There is insufficient system memory in resource pool 'default' to run this query.

    2 - Efetuado o Detach + Atach e rodado:
    ALTER DATABASE SeuBanco SET EMERGENCY;
    ALTER DATABASE SeuBanco SET SINGLE_USER;
    DBCC CHECKDB (SeuBanco, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
    ALTER DATABASE SeuBanco SET MULTI_USER;

    ERRO: Msg 8921, Level 16, State 1, Line 3
    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
    Msg 701, Level 17, State 123, Line 3
    There is insufficient system memory in resource pool 'default' to run this query.

    3 - Rodado DBCC CHECKCATALOG (SeuBanco) com sucesso;

    4 - Rodado DBCC CHECKTABLE (SeuBanco) com sucesso;

    5 - Rodado DBCC CHECKTABLE (TB_CONHECIMENTOS, REPAIR_REBUILD);
    ERRO: DBCC execution completed. If DBCC printed error messages, contact your system administrator.
    Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'default' to run this query.

    6 - DBCC CHECKTABLE (TB_CONHECIMENTOS, REPAIR_ALLOW_DATA_LOSS);
    ERRO: DBCC execution completed. If DBCC printed error messages, contact your system administrator.
    Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'default' to run this query.

    E pra mim suspersa, agora ao tentar executar as duas ações, sendo TRUNCATE e depois RECRIAR a tabela o erro abaixo ocorreu:
    ERRO: Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'default' to run this query.

    Após isso tentei DROPAR  a tabela e tive o mesmo erro.

    A SOLUÇÃO QUE HAVIA ENCONTRADO, AGORA JÁ NÃO POSS APLICAR!

    Junior

    segunda-feira, 17 de fevereiro de 2014 14:13

Todas as Respostas

  • Junior,

    Verifique se o banco de dados TEMPDB esta online e se o mesmo não esta com o seu log cheio.

    Além disso, verifique senão existe falta de espaço em disco, como também, se o TEMPDB não esta com o seu tamanho de crescimento esgotado.


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    quarta-feira, 12 de fevereiro de 2014 14:27
  • Junior,

    Verifique a quantidade mínima e máxima de memória alocada na instância do seu SQL Server utilizando sp_configure. Se estiver muito baixa ou dinâmica, altere às configurações de acordo com às suas condições de hardware. Veja um modelo abaixo:

    sp_configure 'show advanced options', 1
    RECONFIGURE
    GO
    
    sp_configure 'min server memory', 1024
    
    sp_configure 'max server memory', 6144
    RECONFIGURE
    GO

    Provavelmente, esta tabela pode estar precisando de mais memória alocada para cada consulta, então será necessário esta alteração também:

    sp_configure 'min memory per query', 28672
    RECONFIGURE
    GO

    Caso seu SQL Server seja versão 2008, existe um Kb recomendando à atualização do Service Pack para corrigir este tipo de problema.

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

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

    De qualquer forma, se esta tabela gera problemas assim pode ser que a quantidade de registros esta elevada para suas configurações de hardware e software(que estamos ajustando agora). Então, seria interessante você estudar uma possibilidade de expurgar alguns dados antigos ou particionar esta tabela. 

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

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    quarta-feira, 12 de fevereiro de 2014 14:41
    Moderador
  • Então Junior,

    Seguinte, tenho 207 GB de espaço em disco na unidade da TempDB, a base está no ar. 
    Quanto ao LOG o crescimento é SEM LIMITE e hoje encontra-se com 9 MB e log 512 KB (após SHRINK).

    Mais erro persiste, creio não ser esse o problema pois foi efetuada a troca de servidor e o erro já ocorria no antigo.

    Estou trabalhando com SQL SERVE EXPRESS 2012 SP1 com uma máquina com 4 GB. 

    Não sei se existe relação mais existe outra INSTANCIA rodando na mesma máquina e com as mesmas configurações Ok. 

    Junior 

    Junior


    • Editado junior_cav quarta-feira, 12 de fevereiro de 2014 18:20
    quarta-feira, 12 de fevereiro de 2014 18:19
  • Durval,

    Estou trabalhando com SQL SERVE EXPRESS 2012 SP1 com uma máquina com 4 GB. 

    Julgo não poder excluir os registros da tabela, na verdade não consigo nem acessa-la para tal, conforme enunciado o comando UPDATE STATISTICS aponta problema de INDEX, sendo  mesmo a chave primaria, porem não consigo excluir nem a NOCLUSTERED que nela existe, tudo que tento fazer retorna o mesmo erro. :) 

    Junior


    Junior

    quarta-feira, 12 de fevereiro de 2014 18:22
  • Durval,

    Estou trabalhando com SQL SERVE EXPRESS 2012 SP1 com uma máquina com 4 GB. 

    Julgo não poder excluir os registros da tabela, na verdade não consigo nem acessa-la para tal, conforme enunciado o comando UPDATE STATISTICS aponta problema de INDEX, sendo  mesmo a chave primaria, porem não consigo excluir nem a NOCLUSTERED que nela existe, tudo que tento fazer retorna o mesmo erro. :) 

    Junior


    Junior

    Junior,

    Você pode alterar às configurações de memória no SQL Server Express. Aplique às mudanças indicadas de configuração de memória e, se necessário (e possível), reinicie o serviço do SQL Server.

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

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    quarta-feira, 12 de fevereiro de 2014 18:51
    Moderador
  • Durval, já havia aplicado as sugestões e não obtive sucesso. 

    Deixei com 3 GB para o SQL, mesmo ele apenas utilizando menas meória por se tratar de versão Express.

    Também apliquei o CUMULATIVE 8, mais erro persiste.

    Junior


    Junior

    quinta-feira, 13 de fevereiro de 2014 00:11
  • Pessoal, acabei de tentar dar um select dessa base em um servidor com 80 GB de espaço em disco, com Windows 2008 R2 Enterprise, o NUCLEOS, 56 GB de RAM. 

    E as mensagens são as mesmas para os operações relatadas. Acredito não ser recursos de máquina. 

    Segue Ex: de como cheguei nessa tabela:

    Date and time: 2014-02-13 15:28:14
    Command: UPDATE STATISTICS [Apolo].[dbo].[XXXXXXXXXXXXXXXXX] [_WA_Sys_00000004_00521600]
    Msg 50000, Level 16, State 1, Procedure CommandExecute, Line 152
    Msg 701, There is insufficient system memory in resource pool 'default' to run this query.
    Outcome: Failed
    Duration: 00:00:22
    Date and time: 2014-02-13 15:28:36


    Para todos os índices dela o erro ocorre. 

    Junior


    • Editado junior_cav quinta-feira, 13 de fevereiro de 2014 17:48 Adicionado comando
    quinta-feira, 13 de fevereiro de 2014 17:19
  • Pessoal, acabei de tentar dar um select dessa base em um servidor com 80 GB de espaço em disco, com Windows 2008 R2 Enterprise, o NUCLEOS, 56 GB de RAM. 

    E as mensagens são as mesmas para os operações relatadas. Acredito não ser recursos de máquina. 

    Segue Ex: de como cheguei nessa tabela:

    Date and time: 2014-02-13 15:28:14
    Command: UPDATE STATISTICS [Apolo].[dbo].[XXXXXXXXXXXXXXXXX] [_WA_Sys_00000004_00521600]
    Msg 50000, Level 16, State 1, Procedure CommandExecute, Line 152
    Msg 701, There is insufficient system memory in resource pool 'default' to run this query.
    Outcome: Failed
    Duration: 00:00:22
    Date and time: 2014-02-13 15:28:36


    Para todos os índices dela o erro ocorre. 

    Junior


    Junior, 

    Ok, mas qual é a versão do SQL Server que está instalada neste servidor ?

    Procurei mais documentos sobre seu assunto e realmente tudo indica sobre configurações no servidor.

    Segue abaixo dois links de Kb, aplicando uma correção sobre este assunto:

    - No SQL Server 2008

    http://support.microsoft.com/kb/982854/pt-br

    - No SQL Server 2012

    http://support.microsoft.com/kb/2769594/pt-br

    Se o problema persistir, você pode tentar "forçar a limpeza" da memória do SQL para começar a trabalhar. Segue os comandos abaixo:

    DBCC FREESYSTEMCACHE
    DBCC FREESESSIONCACHE
    DBCC FREEPROCCACHE

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

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    sexta-feira, 14 de fevereiro de 2014 16:46
    Moderador
  • Pessoal está se atentando muito a mensagem de erro  de falta de memória do resource governor e pouco ao fato que nem mesmo um simples select está funcionando... além do mais, ele estava usando o sql express, o resource governor nem sequer estava habilitado já que não está disponível nessa versão do produto. 

    Procurando pela mensagem Check terminated. A failure was detected while collecting facts. joga a gente para diversos resultados, inclusive uma thread em um forum onde o próprio Paul Randall que escreveu o DBCC CheckDB informa que isso é corrupção dos metadados e que não tem solução a não ser restaurar um backup... 

    sugiro dar uma olhada nesse post e tentar os passos que ele indica para verificar os metadados e ver se não é esse o caso: http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=55422 


    Felipe Ferreira - @SQLBoy SQL Server MVP | SolidQ Mentor | Friends of RedGate http://www.templar.com.br/blogs/felipe

    sexta-feira, 14 de fevereiro de 2014 17:01
  • Felipe,

    Mas o que esta me chamando a atenção é ele utilizar um banco no 2012 que estava supostamente configurado para trabalhar com Resource Governor.

    Até onde conhece e trabalho, as configurações de Resource Governor são vínculadas com a instância do SQL Server, mas aplicadas aos Objetos, ao meu ver, tem algo de errado ai, isso não poder acontecer.

    Se pegarmos as primeira mensagem erro do post, se refere ao TempDB!!!!

    Command: DBCC CHECKDB ([XXXXXXXXXXX]) WITH NO_INFOMSGS, ALL_ERRORMSGS, PHYSICAL_ONLY
    Msg 8921, Level 16, State 1, Line 1
    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
    


    Pedro Antonio Galvão Junior [MVP | Microsoft Evangelist | Microsoft Partner | Engenheiro de Softwares | Especialista em Banco de Dados | SorBR.Net | Professor Universitário | MSIT.com]

    sábado, 15 de fevereiro de 2014 12:25
  • O fato de falar de memória e tempdb me parece mais aqueles erros genéricos... eu conheço o Junior que fez o post, essa base de dados foi migrada do SQL 2008 R2 express onde já estava dando esse erro para o SQL 2012 express, onde o erro persistiu... nenhum dos ambientes usava o resource governor. 

    conversei com ele pelo skype e depois que ele deu truncate na tabela foi possível fazer o select... o erro só acontece em 1 tabela específica do banco, não importa o servidor usado, mesmo tendo muito recurso disponível.  restaurando um backup mais antigo ele conseguiu achar uma versão do backup que não acontece o erro e ele consegue fazer select normalmente... 

    pra mim a unica coisa que não bate é que se fosse só 1 indice corrompido ou dados corrompidos o dbcc ceckdb não deveria parar, ele deveria conseguir rodar :/


    Felipe Ferreira - @SQLBoy SQL Server MVP | SolidQ Mentor | Friends of RedGate http://www.templar.com.br/blogs/felipe

    sábado, 15 de fevereiro de 2014 12:48
  • Durval,

    Já havia aplicado os CUMULATIVE 8 (que já compreende o Hotfix que me repassou), então executei os comandos que sugeriu.

    Mais mesmo erro persiste.

    Ainda acredito que seja dado corrompido na tabela que identifiquei, só não estou conseguindo identificar, recuperar ou excluir esses registos se for o caso. 

    Junior

    Junior

    sábado, 15 de fevereiro de 2014 17:49
  • Isso mesmo Felipe,

    Estou efetuando os testes numa máquina com muito recurso, efetuando o procesos de truncate da tabela, tanto o select (por mais que não tenho registros) quanto manutenção de índices ocorreu com sucesso. Sem erros.

    Retornando backup e executando o comando que gera a mensagem inicial do POST, bem como após todas as alterações efetuadas até o momento tenho o erro que segue:

    2014-02-14 16:40:32.180 spid64 DBCC CHECKTABLE (XXXXXXXXXXXXXXXXXX) WITH all_errormsgs, no_infomsgs executed by sa found 0 errors and repaired 0 errors. Elapsed time: 0 hours 1 minutes 2 seconds. Internal database snapshot has split point LSN = 00139036:000055d9:0001 and first LS‏

    Só uma ressalva Felipe, o comando CHECKDB agora vai até o final porém me acusa erros mencionados em apenas UMA TABELA. As demais valida com êxito.

    Junior


    Junior

    sábado, 15 de fevereiro de 2014 18:29
  • O fato de falar de memória e tempdb me parece mais aqueles erros genéricos... eu conheço o Junior que fez o post, essa base de dados foi migrada do SQL 2008 R2 express onde já estava dando esse erro para o SQL 2012 express, onde o erro persistiu... nenhum dos ambientes usava o resource governor. 

    conversei com ele pelo skype e depois que ele deu truncate na tabela foi possível fazer o select... o erro só acontece em 1 tabela específica do banco, não importa o servidor usado, mesmo tendo muito recurso disponível.  restaurando um backup mais antigo ele conseguiu achar uma versão do backup que não acontece o erro e ele consegue fazer select normalmente... 

    pra mim a unica coisa que não bate é que se fosse só 1 indice corrompido ou dados corrompidos o dbcc ceckdb não deveria parar, ele deveria conseguir rodar :/


    Felipe Ferreira - @SQLBoy SQL Server MVP | SolidQ Mentor | Friends of RedGate http://www.templar.com.br/blogs/felipe

    Felipe,

    Foi ótimo você ter passado mais informações do seu contato direto como o Junior, acredito que o problema dele foi resolvido.

    Apenas para complementar sua informação, dependendo de como está corrompido o banco de dados é possível que o DBCC CHECKDB não consiga concluir à operação. Já tive este problema com alguns bancos de dados e, como já disse, dependendo de como foi corrompido eu fiz um trabalho de recuperação diferente:

    1. Semelhante ao que você propôs ao Junior, truncando ou dropando a tabela ou índice corrompido(eu sempre inicio removendo primeiro os índices, algumas vezes é o suficiente) e voltando um backup da tabela corrompida em um servidor de homologação para depois recriar toda à estrutura e seus dados(o mais atual possível).
    2. Pode parecer incrível, mas já tive casos de apenas desatachar e atachar novamente o banco de dados e o problema se resolveu. Como se alguma transação estivesse travada no Log. Em seguida rodava o CHECKDB e era o suficiente para ajustar os problemas.
    3. Se o CHECKDB não funciona e eu consigo identificar a(s) tabela(s) com problema, eu também executo um processo para reparar a(s) tabela(s) afetada(s). Segue o script abaixo:

    ALTER DATABASE SeuBanco SET EMERGENCY; ALTER DATABASE SeuBanco SET SINGLE_USER; DBCC CHECKDB (SeuBanco, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS; ALTER DATABASE SeuBanco SET MULTI_USER;

    DBCC CHECKCATALOG (SeuBanco); --1ªOPÇÃO DBCC CHECKTABLE (SeuBanco); --2ªOPÇÃO DBCC CHECKTABLE (TB_CONHECIMENTOS, REPAIR_REBUILD); --3ªOPÇÃO (mais drástica) DBCC CHECKTABLE (TB_CONHECIMENTOS, REPAIR_ALLOW_DATA_LOSS);


    Bom, esta é minha contribuição para finalizar este post.

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    segunda-feira, 17 de fevereiro de 2014 12:01
    Moderador
  • Bom dia pessoal,

    Após toda a ajuda e já partindo para recuperar o que conseguir de dados da tabela através de um backup, restaurei no servidor ENTERPRISE o backup da base e iniciei as ações, seguem os resultados:

    1 - tentativa de exclusão de index:  
    ERRO: Msg 701, Level 17, State 123, Line 2
    There is insufficient system memory in resource pool 'default' to run this query.

    2 - Efetuado o Detach + Atach e rodado:
    ALTER DATABASE SeuBanco SET EMERGENCY;
    ALTER DATABASE SeuBanco SET SINGLE_USER;
    DBCC CHECKDB (SeuBanco, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
    ALTER DATABASE SeuBanco SET MULTI_USER;

    ERRO: Msg 8921, Level 16, State 1, Line 3
    Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
    Msg 701, Level 17, State 123, Line 3
    There is insufficient system memory in resource pool 'default' to run this query.

    3 - Rodado DBCC CHECKCATALOG (SeuBanco) com sucesso;

    4 - Rodado DBCC CHECKTABLE (SeuBanco) com sucesso;

    5 - Rodado DBCC CHECKTABLE (TB_CONHECIMENTOS, REPAIR_REBUILD);
    ERRO: DBCC execution completed. If DBCC printed error messages, contact your system administrator.
    Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'default' to run this query.

    6 - DBCC CHECKTABLE (TB_CONHECIMENTOS, REPAIR_ALLOW_DATA_LOSS);
    ERRO: DBCC execution completed. If DBCC printed error messages, contact your system administrator.
    Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'default' to run this query.

    E pra mim suspersa, agora ao tentar executar as duas ações, sendo TRUNCATE e depois RECRIAR a tabela o erro abaixo ocorreu:
    ERRO: Msg 701, Level 17, State 123, Line 1
    There is insufficient system memory in resource pool 'default' to run this query.

    Após isso tentei DROPAR  a tabela e tive o mesmo erro.

    A SOLUÇÃO QUE HAVIA ENCONTRADO, AGORA JÁ NÃO POSS APLICAR!

    Junior

    segunda-feira, 17 de fevereiro de 2014 14:13
  • Bom dia pessoal,

    Alguma sugestão para que eu consiga ELIMINAR essa tabela? Não consigo para poder reconstrui-la e alimenta-la, ja tenho tudo pronto pra RECOMPOR ela mais agora efetuando a copia e tentando todos os comandos o erro inicial voltou. TRUNCATE, DROP TABLE, DROP INDEX. Tenho como "forçar" a destruição da mesma ?


    Junior

    sexta-feira, 28 de fevereiro de 2014 14:27
  • Bom dia pessoal,

    Alguma sugestão para que eu consiga ELIMINAR essa tabela? Não consigo para poder reconstrui-la e alimenta-la, ja tenho tudo pronto pra RECOMPOR ela mais agora efetuando a copia e tentando todos os comandos o erro inicial voltou. TRUNCATE, DROP TABLE, DROP INDEX. Tenho como "forçar" a destruição da mesma ?


    Junior

    Junior,

    Com tantos problemas que você já passou com este banco de dados, não só com esta tabela, você já pensou em criar um novo banco ?

    Crie um novo banco e tente restaurar a tabela com os últimos dados íntegros. Assim que você obtiver êxito, migre os demais objetos do seu banco de dados (tabelas, views, procedures, ...).

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    sexta-feira, 28 de fevereiro de 2014 15:39
    Moderador
  • Cara estamos falando de um volume considerável de dados , uns 8 GB. 

    Na verdade já criei até a forma de recompor a tabela, só não consigo excluí-la, tenho certeza absoluta que o problema é nela pois para meu cliente poder utilizar o sistema, rastreei dentro das procedures os INSERTS e DELETES nela e comentei, agora não tenho mais erros nos processos. 

    Só preciso mesmo eliminar ela do BD de forma definitiva, nem precisa mais identificar se é INDICE (o que creio ser) e salvar esses dados. 

    Junior 



    Junior

    sexta-feira, 28 de fevereiro de 2014 20:23
  • Junior,

    Desculpe, eu não conheço seu ambiente (hardware e software), mas eu já realizei uma operação semelhante em um banco de dados com 32Gb com compatibilidade 90 em um SQL Server 2008 R2 com aproximadamente 40 tabelas(estou em casa, mas se desejar posso postar números corretos após o carnaval) e funcionou sem problemas, mas o servidor que eu utilizo tem uma configuração razoável.

    Foi apenas uma vez, normalmente quando existe estrutura de dados corrompida eu consigo resolver com o DBCC como já indicamos. No meu caso, quando eu executava um "SELECT *" nas tabelas corrompidas ele só trazia parte dos dados da tabela e depois gerava um erro. Em poucas palavras, houve perda de parte dos dados.

    Abraços,

    Durval Ramos
    Microsoft Partner | MTA - SQL Server 2012
    ----------------------------------
    Se foi resolvido clique "Marcar como resposta" e se foi útil "Votar como Útil"
    sexta-feira, 28 de fevereiro de 2014 23:07
    Moderador
  • Uma nova informação que ocorreu hoje. Ao executar o DBCC apenas na base com problema, quando ai gerou o erro. 

    Existia ao mesmo tempo outra aplicação rodando em cima de outra base n mesma instância e gerou esse mesmo erro na aplicação nesse momento. É sabido que o erro encontra-se em determinada base e tabela, mais verifiquei que afeta toda a instância. 

    Talvez essa informação dê uma clareada.

    Junior 


    Junior

    segunda-feira, 10 de março de 2014 15:37