Partilhar via

MSSQLSERVER_833

  • Artigo

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

Detalhes

Atributo Valor
Nome do produto SQL Server
ID do evento 833
Origem do Evento MSSQLSERVER
Componente SQLEngine
Nome simbólico BUF_LONG_IO
Texto da mensagem O SQL Server encontrou %d ocorrências de solicitações de E/S demorando mais do que %d segundos para serem concluídas no arquivo [%ls] no banco de dados [%ls] (%d). O identificador de arquivo do SO é 0x%p. O deslocamento da E/S mais demorada é: %#016I64x.

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 DBMS (sistema de gerenciamento de banco de dados), como o SQL Server, depende da pontualidade das operações de E/S (entrada e saída) de arquivo. Qualquer um dos itens a seguir pode causar operações de E/S travadas 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 trava e tempos limite.
  • Tempo de resposta lento.
  • Alongamento dos limites de recursos.
  • Você também pode notar outros sintomas associados a esta mensagem, como:
    • Tempos de espera altos para esperas PAGEIOLATCH.
    • Avisos ou erros no log de eventos do sistema.
    • Indicações de problemas de latência de disco em contadores de 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:

Texto da mensagem Descrição
<Número> de ocorrências O número de solicitações de E/S que não concluíram a operação de leitura ou gravação em menos de 15 segundos.
Informações do arquivo O nome completo do arquivo, o nome do banco de dados e o número de identificação do banco de dados (DBID).
Handle O identificador do sistema operacional do arquivo. Você pode usar o identificador do sistema operacional com depuradores ou outros utilitários para ajudar a rastrear solicitações de IRP (pacote de solicitação de E/S).
Deslocamento O deslocamento da última operação de E/S presa ou da última operação de E/S paralisada. Você pode usar o deslocamento com depuradores ou outros utilitários para ajudar a controlar solicitações de IRP.

Observação:
quando a mensagem informativa é gravada no log de erros do SQL Server, a operação de E/S pode não estar mais travada ou paralisada.

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 E/S devido à configuração incorreta do subsistema de E/S (SAN, NAS e conexão direta) ou porque a capacidade do 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 firmware ou um problema de driver.
  • O caminho de E/S tem componentes de hardware com defeito.
  • Problema de desempenho no nível do sistema operacional.
  • Filtre a intervenção do driver no processo de E/S ou no 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 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 é freqüentemente conhecida como tempo de busca do 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 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 do 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 a ser executado 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. Também é possível usar recursos como o registro do Storport ETW 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 a camada de armazenamento e o 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 travada e E/S paralisada

E/S travada

A E/S travada é definida como uma solicitação de E/S que não é concluída. Freqüentemente, a E/S travada indica um IRP travado. 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 travada normalmente 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 que é concluída ou que leva muito tempo 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 parou a E/S e travou a gravação e a geração de relatórios de E/S

O Suporte do SQL Server lida com muitos casos a cada ano que envolvem problemas de E/S travados 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 detecção e o relatório de solicitações de E/S paralisadas e travadas 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 do 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. 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 travada usando o sinalizador de rastreamento 830, embora não seja recomendável fazer isso.

Você pode desabilitar a detecção de E/S paralisada e travada 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á 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.

Observação

Uma solicitação de E/S que fica paralisada ou travada é relatada apenas uma vez. Por exemplo, se a mensagem relatar que 10 solicitações de E/S estão paralisadas, esses 10 relatórios não ocorrerão novamente. Se a próxima mensagem relatar que 15 solicitações de E/S estão paralisadas, isso significa que 15 novas solicitações de E/S foram paralisadas.

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

O SQL Server usa as chamadas de API padrão 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 IRP (pacote de solicitação de E/S). Para determinar o estado do IRP, use os dois recursos a seguir:

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 seus fornecedores de hardware antes de executar ações adicionais de depuração. 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 travadas. 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 para determinar a 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 do 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 transferência de disco em um computador que executa o SQL Server normalmente é inferior a 15 milissegundos. Se o valor médio de discagem de disco/transferência aumentar, isso indica que o subsistema de E/S não está acompanhando de maneira ideal a demanda de E/S.

Tenha cuidado ao usar os contadores de desempenho porque o SQL Server aproveita ao máximo os recursos de E/S assíncrona que enviam 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 examinar o contador "Disco Físico: Bytes de Disco/s" para cada disco afetado e comparar a taxa de atividade com os contadores "Processo: Bytes de Dados de E/S/s" e "Processo: Outros Bytes de E/S/s" 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 gargalos de E/S, consulte Solucionar problemas de desempenho lento do SQL Server causados por problemas de E/S.

Índices e paralelismo

Freqüentemente, intermitências de E/S ocorrem porque um índice está ausente. Esse comportamento pode empurrar severamente o caminho de E/S. Uma passagem que usa o Assistente de Torneamento de Índice (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 verificação de tabela, ou talvez se 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 ausente ou porque as estatísticas estão desatualizadas. Você pode reduzir o uso e a contenção de tempdb adicionando um ou mais índices.
  • É feita uma redução nos recursos, nas operações paralelas ou em ambos. 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 Query Analyzer 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 intermitência de E/S junto com o aumento do uso da CPU. Uma consulta geralmente 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 tratados pelo Suporte ao SQL Server e ao Suporte ao 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 paralisadas e paralisadas. 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 esse 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 travada por aproximadamente 45 segundos. A gravação de 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 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 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 Noções básicas e resolução de 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, a essa altura, 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. Combinado 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 área de armazenamento), o valor de tempo limite de "repetição 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 estol, o fabricante do hardware recomenda uma configuração de "repetição 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 se tornam parte da pilha de solicitação 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 travadas 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 do arquivo de dados do SQL Server nas seleções de backup de arquivo. Quando o backup ocorre, ele tenta coletar 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/Ss 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 trabalho 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 leitura antecipada do SQL Server. Além disso, outro bug no driver de filtro deixa as ações uma 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 Suporte ao Produto 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 tentativas infinitas. A operação de E/S fica travada e o SQL Server não pode concluir a ação especificada. Muito parecido com a condição de gravação de log descrita anteriormente, muitos comportamentos ruins do sistema podem ocorrer depois que essa condição altera 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 alguns são baseados 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 rígidas são necessárias para reduzir a latência para espelhos ou operações de reconstrução de raid.

Exemplo 5: Compactação

A Microsoft não dá 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 interrompe o protocolo WAL (Write Ahead Logging). A compactação NTFS também requer processamento aprimorado para cada operação de E/S. A compactação cria um comportamento semelhante "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 registro de gravação em sys.dm_os_wait_stats DMV (exibições de gerenciamento dinâmico) 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 esperas PAGEIOLATCH é um comportamento típico e esperado. No entanto, se os tempos médios de espera do PAGEIOLATCH forem consistentemente maiores que 10 milissegundos, você deverá investigar por que o subsistema de E/S está sob pressão. Para obter mais informações, consulte um dos seguintes documentos:

Referências

O SQL Server requer que os sistemas ofereçam suporte à "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).