MSSQLSERVER_833

Aplica-se a:SQL ServerInstância Gerenciada de SQL do Azure

Detalhes

Explicação

Esta mensagem indica que o SQL Server emitiu uma solicitação de leitura ou gravação de disco, e que a solicitação demorou mais de 15 segundos para retornar. O SQL Server relata esse erro e indica um problema com o subsistema de E/S. Um sistema de gerenciamento de banco de dados (DBMS), como o SQL Server, depende da pontualidade das operações de entrada e saída (E/S) de arquivos. Qualquer um dos itens a seguir pode causar operações de E/S presas ou paralisadas e afetar negativamente a capacidade de resposta e o desempenho do SQL Server:

• Hardware defeituoso
• Hardware configurado incorretamente
• Configurações de firmware
• Drivers de filtro
• Compactação
• •s
• Outras condições no caminho de E/S

Esses problemas de E/S podem causar o seguinte comportamento:

• Bloqueio.
• Contenção de travas e tempos limites.
• Tempo de resposta lento.
• Alongamento dos limites de recursos.
• Você também pode notar outros sintomas associados a esta mensagem, como:
  • Tempos de espera elevados para PAGEIOLATCH espera.
  • Avisos ou erros no log de eventos do sistema.
  • Indicações de problemas de latência de disco nos contadores do monitor do sistema.

Quando uma operação de E/S estiver pendente por 15 segundos ou mais, o SQL Server executará as seguintes etapas:

1. Detecta que uma operação está pendente.

2. Grava uma mensagem informativa no log de erros do SQL Server, conforme descrito na seção Detalhes.

   A explicação para diferentes seções desta mensagem informativa é dada na tabela a seguir:

Possíveis causas:

A mensagem informativa indica que a carga atual pode estar enfrentando uma das seguintes condições:

• A carga de trabalho excede os recursos do caminho de I/O devido à configuração incorreta do subsistema de E/S (SAN, NAS e conexão direta) ou porque a capacidade de hardware foi atingida.
• A carga de trabalho excede os recursos atuais do sistema, como E/S, CPUs e HBAs.
• O caminho de E/S tem software com defeito. Pode ser um problema de firmware ou driver.
• O caminho de E/S tem componentes de hardware com defeito.
• Problema de desempenho no nível do sistema operacional.
• Intervenção do driver de filtro no processo de E/S ou no caminho de armazenamento dos arquivos de banco de dados. Por exemplo, programa antivírus.

O SQL Server registra a hora em que iniciou uma solicitação de E/S e registra a hora em que a E/S foi concluída. Se a diferença entre elas for de 15 segundos ou mais, essa condição será detectada. Isso também significa que o SQL Server não é a causa da condição de E/S atrasada que esta mensagem descreve e relata. Essa condição é conhecida como E/S paralisada. A maioria das solicitações de disco ocorre dentro da velocidade típica do disco. Essa velocidade típica do disco é frequentemente conhecida como tempo de busca de disco. O tempo de busca no disco para a maioria dos discos padrão é de dez milissegundos ou menos. Portanto, 15 segundos é muito tempo para que o caminho de E/S do sistema retorne ao SQL Server. Para obter mais detalhes, consulte a seção Mais informações .

Ação do usuário

Solucione esse erro executando as seguintes etapas:

1. Examine o log de eventos do sistema em busca de mensagens de erro relacionadas ao hardware.
2. Examine os logs específicos de hardware se eles estiverem disponíveis. Use os métodos e técnicas necessários para determinar a causa do atraso no sistema operacional, nos drivers ou no hardware de E/S.
3. Atualize todos os drivers de dispositivo e firmware ou execute outros diagnósticos associados ao seu subsistema de E/S.
4. O acesso ao disco pode ser retardado por drivers de filtro, por exemplo, um programa antivírus. Para aumentar a velocidade de acesso, exclua os arquivos de dados do SQL Server especificados na mensagem de erro das verificações de vírus ativas. Para obter mais informações, consulte Como escolher o software antivírus para executar em computadores que executam o SQL Server (microsoft.com).
   • Use o utilitário de linha de comando fltmc.exe para consultar todos os drivers de filtro instalados no sistema e entender as funções que ele executa no caminho de armazenamento para os arquivos de banco de dados.
5. Use o Monitor de Desempenho para examinar os seguintes contadores:
   • Média de seg/transferência do disco
   • Média de comprimento da fila do disco
   • Comprimento atual da fila do disco
6. Você também pode usar recursos como o log ETW do Storport para medir a latência das solicitações feitas a uma unidade de disco. Outro kit semelhante de solução de problemas de E/S de disco está disponível como um perfil interno do Windows Performance Recorder.
7. Monitore sys.dm_io_virtual_file_stats e escolha o nível de armazenamento e IOPS apropriados para sua taxa de transferência de armazenamento.

Para obter um passo a passo guiado para diagnosticar e solucionar problemas de desempenho do SQL Server que ocorrem devido a problemas de E/S, consulte Solucionar problemas de desempenho lento do SQL Server causados por problemas de E/S.

Mais informações

E/S presa e E/S paralisada

E/S presa

A E/S presa é definida como uma solicitação de E/S que não é concluída. Frequentemente, E/S presa indica um IRP preso. Para resolver uma condição de E/S travada, você geralmente deve reiniciar o computador ou executar uma ação semelhante. Uma condição de E/S presa geralmente indica um dos seguintes problemas:

• Hardware defeituoso.
• Um bug em um componente de caminho de E/S.

E/S paralisada

A E/S paralisada é definida como uma solicitação de E/S concluída ou que leva tempo excessivo para ser concluída. O comportamento de E/S paralisada geralmente ocorre devido a um dos seguintes motivos:

• Configuração de hardware.
• Configurações de firmware.
• Um problema de driver de filtro que requer assistência do fornecedor de hardware ou software para rastrear e resolver.

SQL Server paralisou a E/S e bloqueou a gravação e os relatórios de E/S

O Suporte do SQL Server lida com muitos casos a cada ano que envolvem problemas de E/S presos ou parados. Esses problemas de E/S aparecem de maneiras diferentes. Os problemas de E/S são alguns dos mais difíceis de diagnosticar e depurar e exigem tempo e recursos significativos para depuração da Microsoft e do cliente. O relatório e o registro de solicitações de E/S são projetados por arquivo. A detecção e o relatório de solicitações de E/S paradas e presas são duas ações separadas.

Gravação

Há dois momentos em que uma ação de registro ocorre no SQL Server. A primeira é quando a operação de E/S é concluída. O segundo momento é quando o escritor preguiçoso corre. Quando o gravador lento é executado, ele verifica todos os dados pendentes e solicitações de E/S de arquivo de log pendentes. Se a solicitação de E/S exceder o limite de 15 segundos, ocorrerá uma operação de registro.

Relatório

O relatório ocorre em intervalos de cinco minutos ou mais de diferença. O relatório ocorre quando a próxima solicitação de E/S é feita no arquivo. Se uma ação de registro tiver ocorrido e cinco minutos ou mais tiverem se passado desde que o último relatório ocorreu, a mensagem informativa mencionada na seção Detalhes será gravada no log de erros do SQL Server.

O limite de 15 segundos não é ajustável. No entanto, você pode desabilitar a detecção de E/S paralisada ou presa usando o sinalizador de rastreamento 830, embora não seja recomendável fazer isso.

Você pode desabilitar a detecção de E/S parada e presa usando o sinalizador de rastreamento 830. Para habilitar esse sinalizador sempre que o SQL Server for iniciado, use o parâmetro de inicialização -T830. Para desabilitar a detecção de uma instância do SQL Server que está sendo executada no momento, use a seguinte instrução:

    dbcc traceon(830, -1)

Essa configuração é efetiva somente durante a vida útil do processo do SQL Server.

Rastreando o pacote de solicitação de E/S (IRP)

O SQL Server usa as chamadas padrão da API do Microsoft Windows para ler e gravar dados. Por exemplo, o SQL Server usa as seguintes funções:

• WriteFile
• ReadFile
• WriteFileScatter
• ReadFileGather

A solicitação de leitura ou gravação é tratada pelo Windows como um pacote de solicitação de E/S (IRP). Para determinar o estado da IRP, use os dois recursos a seguir::

• Suporte do Windows
• Registro em log do ETW Storport

Recomendamos que você verifique se há atualizações disponíveis para os seguintes itens:

• O BIOS
• O firmware
• Quaisquer outros componentes do caminho de E/S

Entre em contato com os fornecedores de hardware antes de executar ações de depuração adicionais. A sessão de depuração provavelmente envolverá um driver, firmware ou componente de driver de filtro de terceiros.

Ações do plano de consulta e desempenho do sistema

No geral, o desempenho do sistema pode desempenhar um papel fundamental no processamento de E/S. Você deve considerar a integridade geral do sistema ao investigar relatórios de operações de E/S paralisadas ou presas. Cargas excessivas podem fazer com que o sistema geral seja lento, incluindo o processamento de E/S. O comportamento do sistema quando o problema ocorre pode ser um fator-chave na determinação da causa raiz do problema. Por exemplo, se o uso da CPU aumentar ou permanecer alto enquanto o problema ocorre, isso pode indicar que um processo do sistema está usando tanta CPU que outros processos estão sendo afetados negativamente.

Contadores de desempenho

Para monitorar o desempenho de E/S, examine os seguintes contadores de desempenho para obter informações específicas sobre o caminho de E/S:

• Média de seg/transferência do disco
• Média de comprimento da fila do disco
• Comprimento atual da fila do disco

Por exemplo, o tempo médio de disco s/transferência em um computador que esteja executando o SQL Server é normalmente inferior a 15 milissegundos. Se o valor Médio de Disco S/Transferência subir, isso indicará que o subsistema de E/S não está acompanhando de forma ideal a demanda de E/S.

Tenha cuidado ao usar os contadores de desempenho, pois o SQL Server aproveita ao máximo os recursos de E/S assíncrona que pressionam fortemente os comprimentos da fila de disco. Portanto, comprimentos de fila de disco mais longos por si só não indicam um problema.

No Monitor do Sistema do Windows, você pode examinar o contador "Disco Físico: Bytes de Disco/s" para cada disco afetado e comparar a taxa de atividade com os contadores "Process: IO Data Bytes/Sec" e "Process: IO Other Bytes/sec" para cada processo. Você faz isso para identificar se um conjunto específico de processos está gerando solicitações de E/S excessivas. Vários outros contadores relacionados a E/S no objeto Process revelam informações mais granulares. Se você determinar que uma instância do SQL Server é responsável pela carga excessiva de E/S no servidor, consulte a próxima seção sobre índices e paralelismo. Para obter uma discussão detalhada sobre como detectar e resolver afunilamentos de E/S, consulte Solucionar problemas de desempenho lento do SQL Server causados por problemas de E/S.

Índices e paralelismo

Frequentemente, ocorrem intermitências de E/S porque um índice está ausente. Esse comportamento pode empurrar severamente o caminho de E/S. Uma passagem que usa o Index Turning Wizard (ITW) pode ajudar a resolver a pressão de E/S no sistema. Se uma consulta se beneficiar de um índice em vez de uma varredura de tabela, ou talvez se ela usar uma classificação ou hash, o sistema poderá obter as seguintes vantagens:

• É feita uma redução na E/S física necessária para concluir a ação que cria diretamente benefícios de desempenho para a consulta.
• Menos páginas no cache de dados devem ser viradas. Portanto, as páginas que estão no cache de dados permanecem relevantes para consultas ativas.
• Classificações e hashes são usados porque um índice pode estar faltando ou porque as estatísticas estão desatualizadas. Você pode reduzir o uso e a contenção do tempdb adicionando um ou mais índices.
• É feita uma redução de recursos, operações paralelas ou ambas. Como o SQL Server não garante a execução de consultas paralelas e a carga no sistema é considerada, é melhor otimizar todas as consultas para execução serial. Para otimizar uma consulta, abra o Analisador de Consultas e defina o valor sp_configure da opção de grau máximo de paralelismo como 1. Se todas as consultas forem ajustadas para serem executadas prontamente como uma operação serial, a execução paralela geralmente é apenas um resultado melhor. No entanto, a execução paralela geralmente é selecionada porque a quantidade de dados é grande. Para um índice ausente, uma classificação grande pode ter que ocorrer. Vários trabalhadores que estão executando a operação de classificação criarão uma resposta mais rápida. No entanto, essa ação pode aumentar drasticamente a pressão sobre o sistema. Grandes solicitações de leitura de muitos trabalhadores podem causar uma explosão de E/S junto com o aumento do uso da CPU. Muitas vezes, uma consulta pode ser ajustada para ser executada mais rapidamente e usar menos recursos se um índice for adicionado ou se ocorrer outra ação de ajuste.

Exemplos práticos do suporte do SQL Server

Os exemplos a seguir foram manipulados pelo Suporte do SQL Server e pelo Suporte de Escalonamento do Windows. Esses exemplos destinam-se a fornecer um quadro de referência e ajudar a definir suas expectativas sobre situações de E/S paradas e presas. Eles também fornecem uma estrutura para entender como um sistema pode ser afetado ou pode responder. Nenhum hardware específico ou conjunto de drivers representa qualquer risco específico ou risco aumentado em relação a outro. Todos os sistemas são iguais a este respeito.

Exemplo 1: Uma gravação de log que está presa por 45 segundos

Uma tentativa de gravar um arquivo de log do SQL Server periodicamente fica presa por aproximadamente 45 segundos. A gravação do log não é concluída em tempo hábil. Esse comportamento cria uma condição de bloqueio que causa tempos limite de cliente de 30 segundos.

O aplicativo enviou uma confirmação para o SQL Server e a confirmação fica presa como uma gravação de log pendente. Esse comportamento faz com que a consulta continue mantendo bloqueios e bloquear solicitações de entrada de outros clientes. Em seguida, outros clientes começam a expirar. Isso agrava o problema porque o aplicativo não reverte transações abertas quando ocorre um tempo limite de consulta. Isso cria centenas de transações abertas que estão mantendo bloqueios. Portanto, ocorre uma grave situação de bloqueio.

Para obter mais informações sobre manipulação e bloqueio de transações, consulte o seguinte artigo da Base de Dados de Conhecimento Microsoft: 224453 Compreendendo e resolvendo problemas de bloqueio do SQL Server

O aplicativo atende a um site usando o pool de conexões. À medida que mais conexões são bloqueadas, o site cria mais conexões. Essas conexões ficam bloqueadas e o ciclo continua.

A gravação do log leva aproximadamente 45 segundos para ser concluída. No entanto, neste momento, centenas de conexões são copiadas. Os problemas de bloqueio causam vários minutos de tempo de recuperação para o SQL Server e o aplicativo. Combinada com problemas de aplicativos, a condição de E/S paralisada tem um efeito muito negativo no sistema.

Resolução

O problema é rastreado para uma solicitação de E/S presa em um driver HBA (Host Bus Adapter). O computador tem várias placas HBA com suporte a failover. Quando um HBA está atrasado ou não está se comunicando com a SAN (Storage Area Network, rede de armazenamento de dados), o valor de tempo limite "repetir antes do failover" é configurado para 45 segundos. Quando o tempo limite excede, a solicitação de E/S é roteada para o segundo HBA. O segundo HBA lida com a solicitação e é concluído rapidamente. Para ajudar a evitar essas condições de paralisação, o fabricante do hardware recomenda uma configuração de "repetir antes do failover" de cinco segundos.

Exemplo 2: Intervenção do driver de filtro

Muitos programas de software antivírus e produtos de backup usam drivers de filtro de E/S. Esses drivers de filtro de E/S tornam-se parte da pilha de solicitações de E/S e têm acesso à solicitação IRP. O Atendimento Microsoft detectou vários problemas causados por bugs que criam condições de E/S presas ou condições de E/S paralisadas em uma implementação de driver de filtro.

Uma dessas condições é um driver de filtro para processamento de backup que permite o backup dos arquivos que estão abertos quando o backup ocorre. O administrador do sistema incluiu o diretório de arquivo de dados do SQL Server nas seleções de backup de arquivo. Quando o backup ocorre, o backup tenta reunir a imagem correta do arquivo no momento em que o backup é iniciado. Isso atrasa as solicitações de E/S. As solicitações de E/S podem ser concluídas apenas uma de cada vez, pois o software as manipula.

Quando o backup é iniciado, o desempenho do SQL Server cai drasticamente à medida que as E/S do SQL Server são forçadas a concluir uma de cada vez. A lógica de um de cada vez é tal que a operação de E/S não pode ser executada de forma assíncrona, o que agrava o problema. Portanto, quando o SQL Server espera postar uma solicitação de E/S e continuar, o trabalhador fica preso na chamada de leitura ou gravação até que a solicitação de E/S seja concluída. As ações do driver de filtro desabilitam efetivamente as tarefas de processamento, como a leitura antecipada do SQL Server. Além disso, outro bug no driver de filtro deixa as ações de cada vez no processo, mesmo quando o backup é concluído. A única maneira de restaurar o desempenho do SQL Server é reiniciar o SQL Server para que o identificador de arquivo seja liberado e readquirido sem a interação do driver de filtro.

Resolução

Para resolver esse problema, os arquivos de dados do SQL Server são removidos do processo de backup de arquivo. O fabricante do software corrigiu o problema que deixava o arquivo no modo "um de cada vez".

Exemplo 3: Erros ocultos

Muitos sistemas high-end têm caminhos de E/S multicanal para lidar com balanceamento de carga ou atividades semelhantes. O Atendimento Microsoft encontrou problemas com o software de balanceamento de carga em que uma solicitação de E/S falha, mas o software não manipula a condição de erro corretamente. O software pode tentar tentativas infinitas. A operação de E/S fica presa e o SQL Server não pode concluir a ação especificada. Assim como a condição de gravação de log descrita anteriormente, muitos comportamentos ruins do sistema podem ocorrer depois que tal condição atinge o sistema.

Resolução

Para resolver esse problema, reinicie o SQL Server. No entanto, às vezes você precisa reiniciar o sistema operacional para restaurar o processamento. Também recomendamos que você obtenha uma atualização de software do fornecedor de E/S.

Exemplo 4: Armazenamento remoto, espelhamento e unidades raid

Muitos sistemas usam espelhamento ou adotam etapas semelhantes para evitar a perda de dados. Alguns sistemas que usam espelhamento são baseados em software e outros em hardware. A situação normalmente descoberta pelo Suporte da Microsoft para esses sistemas é o aumento da latência.

Um aumento no tempo geral de E/S ocorre quando a E/S deve ser concluída antes de ser considerada concluída. Para instalações de espelhamento remoto, novas tentativas de rede podem ser envolvidas. Quando ocorrem falhas na unidade e o sistema raid está sendo reconstruído, o padrão de E/S também pode ser interrompido.

Resolução

Definições de configuração rigorosas são necessárias para reduzir a latência para espelhos ou para operações de reconstrução de raid.

Exemplo 5: Compactação

A Microsoft não oferece suporte a arquivos de dados e arquivos de log do SQL Server em unidades compactadas. A compactação NTFS não é segura para o SQL Server porque a compactação NTFS quebra o protocolo WAL (Write Ahead Logging). A compactação NTFS também requer processamento maior para cada operação de E/S. A compactação cria um comportamento semelhante ao "um de cada vez" que causa problemas graves de desempenho.

Resolução

Para resolver esse problema, descompacte os dados e os arquivos de log.

Para obter mais informações, consulte Suporte para bancos de dados em volumes compactados.

Pontos de dados adicionais

PAGEIOLATCH_* e esperas de writelog em sys.dm_os_wait_stats exibições de gerenciamento dinâmico (DMV) são indicadores-chave para investigar o desempenho do caminho de E/S. Quando você vê esperas de PAGEIOLATCH significativas, isso significa que o SQL Server está aguardando o subsistema de E/S. Uma certa quantidade de PAGEIOLATCH espera é um comportamento típico e esperado. No entanto, se os tempos médios de espera do PAGEIOLATCH forem consistentemente maiores que 10 milissegundos, você deve investigar por que o subsistema de E/S está sob pressão. Para obter mais informações, consulte um dos seguintes documentos:

• Solucionar problemas de desempenho lento do SQL Server causados por problemas de E/S
• sys.dm_os_waiting_tasks (Transact-SQL)
• sys.dm_exec_requests
• O repositório de tipos de espera do SQL Server

Referências

• Usar o DISKSPD para testar o desempenho de armazenamento da carga de trabalho
• 826433 diagnóstico do SQL Server adicionado para detectar problemas de E/S não relatados devido a leituras obsoletas ou gravações perdidas
• Algoritmos de registro e armazenamento de dados

O SQL Server requer que os sistemas ofereçam suporte a "entrega garantida para mídia estável", conforme descrito nos Requisitos do Programa de Confiabilidade de E/S do SQL Server. Para obter mais informações sobre os requisitos de entrada e saída para o mecanismo de banco de dados do SQL Server, visite Requisitos de entrada/saída do Mecanismo de Banco de Dados.

Para obter mais informações sobre erros de E/S, consulte Microsoft SQL Server I/O Basics, Chapter 2 (Noções básicas de E/S do Microsoft SQL Server, Capítulo 2).