Entrar com a conta da Microsoft
Entrar ou criar uma conta.
Olá,
Selecionar uma conta diferente.
Você tem várias contas
Escolha a conta com a qual você deseja entrar.

Sintomas

Durante a inicialização do Microsoft SQL Server, você percebe um ou mais dos seguintes sintomas logo após a recuperação do banco de dados e as conexões do cliente estiverem ativadas.

Sintoma 1

Você recebe mensagens de erro e declarações semelhantes às seguintes em seu log de erros do SQL Server:

2014-12-13 08:03:34.85 spid24s Using 'dbghelp.dll' version '4.0.5'2014-12-13 08:03:34.85 spid24s **Dump thread - spid = 0, EC = 0x0000000082274B202014-12-13 08:03:34.85 spid24s ***Stack Dump being sent to C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQL2008R2\MSSQL\LOG\SQLDump0001.txt2014-12-13 08:03:34.85 spid24s * *******************************************************************************2014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:34.85 spid24s * BEGIN STACK DUMP:2014-12-13 08:03:34.85 spid24s * 12/13/14 08:03:34 spid 242014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:34.85 spid24s * Location: ghost.cpp:17422014-12-13 08:03:34.85 spid24s * Expression: tcln1 != NULL2014-12-13 08:03:34.85 spid24s * SPID: 242014-12-13 08:03:34.85 spid24s * Process ID: 354442014-12-13 08:03:34.85 spid24s *2014-12-13 08:03:35.47 spid24s Error: 17066, Severity: 16, State: 1.2014-12-13 08:03:35.47 spid24s SQL Server Assertion: File: <ghost.cpp>, line=1742 Failed Assertion = 'tcln1 != NULL'. Este erro pode estar relacionado ao tempo. Se o erro persistir após a reexecução da instrução, use DBCC CHECKDB para verificar a integridade estrutural do banco de dados ou reinicie o servidor para garantir que as estruturas de dados na memória não sejam corrompidas.

Sintoma 2

Você recebe mensagens de erro e exceções semelhantes às seguintes em seu log de erros do SQL Server:

2014-12-13 12:38:30.25 spid51 usando ' dbghelp. dll ' versão ' 4.0.5 ' 2014-12-13 12:38:30.25 spid51 * * * despejo de pilha sendo enviado para C:\Program Files\Microsoft SQL Server \ MSSQL10_50. SQL2008R2\MSSQL\LOG\SQLDump0003.txt2014-12-13 12:38:30.25 spid51 SqlDumpExceptionHandler: processar 51 gerado exceção fatal c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.2014-12-13 12:38:30.25 spid51 * *******************************************************************************2014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 * BEGIN STACK DUMP:2014-12-13 12:38:30.25 spid51 * 12/13/14 12:38:30 spid 512014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 *2014-12-13 12:38:30.25 spid51 * Exception Address = 000000000030D47C Module(sqlservr+00000000000FD47C)2014-12-13 12:38:30.25 spid51 * Exception Code = c0000005 EXCEPTION_ACCESS_VIOLATION2014-12-13 12:38:30.25 spid51 * Access Violation occurred reading address FFFFFFFFFFFFFFFF2014-12-13 12:38:30.25 spid51 * Input Buffer 54 bytes -2014-12-13 12:38:30.25 spid51 * exec usp_select12014-12-13 12:38:30.77 Server Error: 17310, Severity: 20, State: 1.2014-12-13 12:38:30.77 Server A user request from the session with SPID 51 generated a fatal exception. O SQL Server está encerrando esta sessão. Entre em contato com o serviço de suporte ao produto com o despejo produzido no diretório de log. A violação de acesso terá a seguinte pilha de chamadas: sqlservr! TaskGhostCleanup:: IsHashed + 0x8dsqlservr! TaskGhostCleanup:: enqueue + 0x32sqlservr! IndexRowScanner:: MoveToRowOnNextPage + 0x9csqlservr! IndexDataSetSession:: GetNextRowValuesInternal + 0x11cb

Sintoma 3

Depois de receber as mensagens mencionadas nas seções de sintoma anteriores, você receberá as seguintes mensagens no log de erros do SQL Server:

2014-12-13 08:04:53.37 Server Process 0:0:0 (0x23c8) Worker 0x000000002880C1A0 parece estar sem concessão no Scheduler 23. Tempo de criação do thread: 13062953007877. CPU de thread aprox usado: kernel 0 ms, usuário 0 ms. Utilização de processo 0%. System Idle 88%. Intervalo: 70013 MS. 2014-12-13 08:04:53.37 processo de servidor 0:0:0 (0x71d8) o 0x000000002A8D21A0 de trabalho parece estar sem concessão no Agendador 30. Tempo de criação do thread: 13062953007891. CPU de thread aprox usado: kernel 0 ms, usuário 0 ms. Utilização de processo 0%. System Idle 88%. Interval: 70013 ms.2014-12-13 08:04:53.38 Server ***Unable to get thread context for spid 02014-12-13 08:04:53.38 Server * *******************************************************************************2014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * BEGIN STACK DUMP:2014-12-13 08:04:53.38 Server * 12/13/14 08:04:53 spid 294882014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * Non-yielding Scheduler2014-12-13 08:04:53.38 Server *2014-12-13 08:04:53.38 Server * *******************************************************************************2014-12-13 08:04:53.38 Server Stack Signature for the dump is 0x00000000000003412014-12-13 08:04:55.43 Server External dump process return code 0x20000001. O processo de despejo externo não retornou erros. 2014-12-13 de 08:04:55.43 do processo de servidor 0:0:0 (0x9358) Worker 0x0000000081CE41A0 parece estar sem concessão no Agendador 4. Tempo de criação do thread: 13062953009701. CPU de thread aprox usado: kernel 0 ms, usuário 15 ms. Utilização de processo 0%. System Idle 88%. Intervalo: 70011 MS.

O SQL Server pode não responder às solicitações do usuário neste ponto. Se esse for o caso, você deve reiniciar o serviço para corrigir a situação.

Causa

Esse problema ocorre porque as consultas de usuário tentam usar as filas de limpeza de fantasma antes que esse processo seja totalmente inicializado.

Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança incluídas na atualização cumulativa anterior. Confira as atualizações cumulativas mais recentes do SQL Server:

Solução alternativa

Para contornar esse problema, siga estas etapas:

  1. Configure -t669 como parâmetro de inicialização. Esses sinalizadores de rastreamento impedem que consultas do usuário enfileiramento de solicitações para o processo de limpeza de fantasma.

  2. Configure um alerta do SQL Server Agent para disparar um trabalho na mensagem SQL 3408. Por exemplo, configure o seguinte alerta:

    Recuperação concluída. Esta é uma mensagem informativa apenas. Não é necessária nenhuma ação do usuário.

  3. Dentro desse trabalho, execute um script TSQL para esperar de 5 a 10 minutos e, em seguida, execute o comando DBCC TRACEOFF (669,-1) .

Esse procedimento verifica se esse sinalizador de rastreamento está ativo apenas durante a inicialização do SQL Server. O uso desse sinalizador de rastreamento não afeta o funcionamento normal do processo de limpeza de Ghost em segundo plano.

Status

A Microsoft confirmou que isso é um problema com o SQL Server e atualmente está investigando uma correção para esse problema. Este artigo da base de dados de conhecimento será atualizado com informações adicionais à medida que se tornarem disponíveis.

Referências

Dentro do mecanismo de armazenamento: limpeza de Ghost em alertas detalhados sp_add_alert (TRANSACT-SQL) DBCC TRACEOFF (Transact-SQL) sinalizadoresdeinicialização do mecanismo de banco de dados do mecanismo de banco de dados

Facebook LinkedIn Email
ASSINAR RSS FEEDS

Precisa de mais ajuda?

Quer mais opções

Descobrir Comunidade

Explore os benefícios da assinatura, procure cursos de treinamento, saiba como proteger seu dispositivo e muito mais.

Benefícios da assinatura do Microsoft 365

Treinamento do Microsoft 365

Segurança da Microsoft

Centro de acessibilidade

As comunidades ajudam você a fazer e responder perguntas, fazer comentários e ouvir especialistas com conhecimento avançado.

Perguntar à comunidade da Microsoft

Microsoft Tech Community

Windows Insiders

Insiders do Microsoft 365

Essas informações foram úteis?

Qual é o seu grau de satisfação com a qualidade do idioma?
O que afetou sua experiência?
Ao pressionar enviar, seus comentários serão usados para aprimorar os produtos e serviços da Microsoft. Seu administrador de TI poderá coletar esses dados. Política de Privacidade.

Agradecemos seus comentários!

×