MSSQLSERVER_833

Aplica-se a:SQL ServerAzure SQL Managed Instance

Detalhes

Explicação

Essa mensagem indica que o SQL Server emitiu uma solicitação de leitura ou gravação do disco e que a solicitação levou 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 seguintes itens pode causar operações de E/S bloqueadas ou paralisadas e afetar negativamente a capacidade de resposta e o desempenho do SQL Server:

• Hardware defeituoso
• Hardware configurado incorretamente
• Configurações de firmware
• Controladores de filtro
• Compressão
• Erros
• Outras condições no caminho de E/S

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

• Bloqueio.
• Contenção de trava e tempos limites.
• Tempo de resposta lento.
• Alongamento dos limites de recursos.
• Poderá também notar outros sintomas associados a esta mensagem, tais 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 está pendente há 15 segundos ou mais, o SQL Server executa as seguintes etapas:

1. Deteta que uma operação foi pendente.

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

   A explicação para as diferentes secções desta mensagem informativa é dada no quadro seguinte:

Causas possíveis

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 um 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 caminho de armazenamento de 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 essa diferença for de 15 segundos ou mais, essa condição é detetada. 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. Esta 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 de disco para a maioria dos discos padrão ocorre em 10 milissegundos ou menos. Portanto, 15 segundos é muito tempo para o caminho de E/S do sistema retornar 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 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 um software antivírus para ser executado em computadores que executam o SQL Server (microsoft.com).
   • Use o utilitário de linha de comandofltmc.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 de disco
   • Comprimento médio da fila de disco
   • Comprimento da fila de disco atual
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 de solução de problemas de E/S de disco semelhante está disponível como um perfil interno do Gravador de Desempenho do Windows.
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

E/S presa é definida como uma solicitação de E/S que não é concluída. Frequentemente, E/S presas indicam um IRP preso. Para resolver uma condição de E/S bloqueada, normalmente tem de reiniciar o computador ou executar uma ação semelhante. Uma condição de E/S bloqueada normalmente indica um dos seguintes problemas:

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

E/S paralisada

E/S paralisada é definida como uma solicitação de E/S que é concluída ou que leva tempo excessivo para ser concluída. O comportamento de E/S paralisada normalmente 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.

O 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 todos os anos que envolvem problemas de E/S bloqueados ou paralisados. 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 deteção e o relatório de solicitações de E/S paralisadas e bloqueadas 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 pendentes do arquivo de log. Se a solicitação de E/S exceder o limite de 15 segundos, ocorrerá uma operação de registro.

Elaboração de Relatórios

A notificação ocorre em intervalos de cinco minutos ou mais. 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 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 desativar a deteção de E/S paralisada ou presa usando o sinalizador de rastreamento 830, embora não seja recomendável fazer isso.

Você pode desativar a deteção de E/S paralisada 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 deteção de uma instância do SQL Server em execução no momento, use a seguinte instrução:

    dbcc traceon(830, -1)

Essa configuração é efetiva apenas 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:

• EscreverFicheiro
• 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 do IRP, use os dois recursos a seguir::

• Suporte do Windows
• Registro em log do Storport ETW

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.

Desempenho do sistema e ações do plano de consulta

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 paralisadas. Cargas excessivas podem fazer com que o sistema geral fique 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 aumenta ou permanece 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 de disco
• Comprimento médio da fila de disco
• Comprimento da fila de disco atual

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

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 de Sistema do Windows, você pode revisar o contador "Disco físico: Bytes de disco/seg" para cada disco afetado e comparar a taxa de atividade com os contadores "Processo: Bytes de dados de E/S/seg" e "Processo: Outros bytes/s de E/S" para cada processo. Isso é feito 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 por 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 detetar e resolver gargalos de E/S, consulte Solucionar problemas de desempenho lento do SQL Server causados por problemas de E/S.

Índices e paralelismo

Frequentemente, ocorrem explosões de E/S porque falta um índice. Esse comportamento pode empurrar severamente o caminho de E/S. Um passo que usa o ITW (Index Turning Wizard) pode ajudar a resolver a pressão de E/S no sistema. Se uma consulta se beneficiar de um índice em vez de uma verificação de tabela, ou talvez se usar uma classificação ou hash, o sistema pode 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 é frequentemente selecionada porque a quantidade de dados é grande. Para um índice ausente, uma grande classificação 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, esta ação pode aumentar drasticamente a pressão sobre o sistema. Grandes solicitações de leitura de muitos trabalhadores podem causar um pico de E/S juntamente 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 ao Escalonamento do Windows. Estes exemplos destinam-se a fornecer um quadro de referência e ajudar a definir as suas expectativas sobre situações de E/S paralisadas e bloqueadas. 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 sobre outro. Todos os sistemas são iguais a este respeito.

Exemplo 1: Uma gravação de log que fica 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 30 segundos de tempo limite do cliente.

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 bloqueie solicitações de entrada de outros clientes. Em seguida, outros clientes começam a atingir o tempo limite. 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 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 de log leva aproximadamente 45 segundos para ser concluída. No entanto, por esta altura, centenas de conexões são de backup. Os problemas de bloqueio causam vários minutos de tempo de recuperação para o SQL Server e o aplicativo. Combinada com problemas de aplicação, 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 parada, 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 viu vários problemas de bugs que criam condições de E/S bloqueadas 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 foi 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 o SQL Server read-ahead. Além disso, outro bug no driver de filtro deixa as ações um 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 o 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 lida com a condição de erro corretamente. O software pode tentar infinitas tentativas. 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 essa condição prejudica 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 que 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 terminar antes de ser considerada completa. Para instalações espelhadas remotas, 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: Compressã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 compressão NTFS também requer maior processamento 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 writelog aguardam 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. Se você vir esperas PAGEIOLATCH significativas, isso significa que o SQL Server está aguardando no subsistema de E/S. Uma certa quantidade de espera PAGEIOLATCH é um comportamento típico e esperado. No entanto, se os tempos médios de espera PAGEIOLATCH forem consistentemente superiores a 10 milissegundos, você deve investigar por que o subsistema de E/S está sob pressão. Para obter mais informações, consulte os documentos seguintes:

• Resolução de 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

• Utilizar o DISKSPD para testar o desempenho do armazenamento da carga de trabalho
• diagnóstico do SQL Server deteta problemas de E/S não relatados devido a leituras obsoletas ou gravações perdidas
• Algoritmos de registo 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 Noções básicas de E/S do Microsoft SQL Server, Capítulo 2.