Você está offline; aguardando reconexão

Diagnóstico no SQL Server ajuda a detectar interrompidas e presas operações de e/s

IMPORTANTE: Este artigo foi traduzido pelo software de tradução automática da Microsoft e eventualmente pode ter sido editado pela Microsoft Community através da tecnologia Community Translation Framework (CTF) ou por um tradutor profissional. A Microsoft oferece artigos traduzidos automaticamente por software, por tradutores profissionais e editados pela comunidade para que você tenha acesso a todos os artigos de nossa Base de Conhecimento em diversos idiomas. No entanto, um artigo traduzido pode conter erros de vocabulário, sintaxe e/ou gramática. A Microsoft não é responsável por qualquer inexatidão, erro ou dano causado por qualquer tradução imprecisa do conteúdo ou por seu uso pelos nossos clientes.

Clique aqui para ver a versão em Inglês deste artigo: 897284
Sumário
Um sistema de gerenciamento de banco de dados (DBMS), como SQL Server, conta com a agilidade de entrada e saída (e/s) operações. Qualquer um dos itens a seguir pode causar presas ou interrompidas operações de e/s e afetar negativamente o desempenho e a capacidade de resposta do SQL Server:

  • Falha de hardware
  • Hardware configurado incorretamente
  • Configurações de firmware
  • Drivers de filtro
  • Compactação
  • Bugs
  • Outras condições no caminho de i/o
Esses problemas de e/s podem causar o seguinte comportamento ocorre:

  • Bloqueio
  • Contenção de trava e tempos limite
  • Tempo de resposta lento
  • Alongamento de limites de recursos
A partir do Microsoft SQL Server 2000 Service Pack 4 (SP4), SQL Server inclui a lógica que ajuda a detectar interrompida e preso condições para gravações e leituras de i/o do banco de dados e gravações e leituras de e/s de arquivo de log. Quando uma operação de e/s foi pendente por 15 segundos ou mais, o SQL Server executa as seguintes etapas:

  1. Detecta que a operação foi pendente
  2. Grava uma mensagem informativa para o log de erros do SQL Server

    O texto da mensagem de log semelhante à seguinte:

    2004-11-11 00:21:25.26 spid1 SQL Server encontrou 192 ocorrência (s) de solicitações de e/s levando mais de 15 segundos para que termine em [E:\SEDATA\stressdb5.ndf] do arquivo de banco de dados [stressdb] (7). O identificador de arquivo do SO é 0x00000000000074D4. O deslocamento da e/s muito mais recente é: 0x00000000022000 ".

Explicação mensagem informativa

Texto da mensagemDescrição
Número de > ocorrência (s)O número de solicitações de e/s que não concluiu a leitura ou a operação de gravação em menos de 15 segundos.
Informações sobre o arquivo:O nome completo do arquivo, o nome do banco de dados e o número de identificação (DBID) do banco de dados.
AlçaO identificador de sistema operacional do arquivo. Você pode usar o identificador de sistema operacional com depuradores ou com outros utilitários para ajudar a controlar as solicitações de pacote (IRP) de solicitação de e/s.
DeslocamentoO deslocamento do último preso a operação ou a última operação de i/o de interrompida. Você pode usar o deslocamento com depuradores ou com outros utilitários para ajudar a controlar as solicitações de IRP.

Observação: Quando a mensagem informativa é gravada no log de erro do SQL Server, a operação não pode preso ou interrompida.
Esta mensagem informativa indica que a carga atual pode estar sofrendo que uma das condições a seguir:

  • A carga de trabalho está excedendo as capacidades do caminho de i/o.
  • A carga de trabalho está excedendo os recursos atuais do sistema.
  • O caminho de i/o possui um software não está funcionando corretamente; Talvez um firmware ou um problema de driver.
  • O caminho de i/o possui componentes de hardware não está funcionando corretamente.
Para obter mais informações sobre padrões do SQL Server 2000 i/o, vá para o seguinte site da Microsoft:Observação: Este artigo da TechNet também se aplica ao Microsoft SQL Server 2005 e versões posteriores.
Mais Informações

Preso e/s e e/s interrompidos

Preso e/s

Preso e/s é definido como uma solicitação de e/s não termina. Com freqüência, i/o preso indica um IRP preso. Para resolver uma condição de e/s presa, geralmente você deve reiniciar o computador ou executar uma ação semelhante. Uma condição de e/s presa geralmente indica que uma das opções a seguir:

  • Falha de hardware
  • Um bug em um componente de caminho de i/o

I/o interrompido

I/o interrompido é definido como uma solicitação de e/s que concluir ou que leva tempo excessivo para ser concluída. Comportamento de i/o interrompido geralmente ocorre devido a um dos seguintes motivos:

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

SQL Server interrompida e/s e preso e/s de gravação e emissão de relatórios

Suporte do Microsoft SQL Server lida com muitos casos por ano que envolvem problemas de e/s presos ou interrompidos. Esses problemas de e/s aparecem de maneiras diferentes. Problemas de e/s são alguns dos problemas mais difíceis para diagnosticar e depurar e requerem tempo e recursos significativos de depuração da Microsoft e do cliente. Os recursos de relatórios que foram adicionados ao SQL Server 2000 SP4 e versões posteriores significativamente reduzem o tempo necessário para identificar um problema de e/s.

A emissão de relatórios e a gravação de solicitações de e/s são projetados em uma base por arquivo. A detecção e a emissão de relatórios de solicitações de i/o interrompido e presas são duas ações diferentes.

Gravação

Há dois minutos quando uma ação de registro ocorre no SQL Server. A primeira é quando a operação for concluída. Se uma solicitação de e/s tem mais de 15 segundos para terminar, ocorre uma operação de registro. O segundo momento é quando o gravador lento é executado. Quando o gravador lento é executado, o gravador lento verifica todos os dados pendentes e todos os de log pendentes solicitações de e/s de arquivo. Se for ultrapassado o limite de 15 segundos, ocorre uma operação de registro.

Emissão de relatórios

Relatório ocorre em intervalos que são 5 minutos ou mais afastado. Ocorre quando a próxima solicitação de i/o é feita no arquivo de relatório. Se uma ação de registro ocorreu e 5 minutos ou mais passaram desde o último relatório ocorreu, a mensagem informativa é mencionada na seção "Resumo" é gravada no log de erro do SQL Server.

O limite de 15 segundos não é ajustável. No entanto, você pode desativar detecção de i/o interrompido ou presa usando o sinalizador de rastreamento 830, embora não é recomendável que você faça isso.

Para desativar a detecção quando o SQL Server for iniciado, use o -T830 parâmetro de inicialização para desativar a detecção toda vez que SQL Server é iniciado. Para desativar a detecção de uma instância do SQL Server que está sendo executado, use a seguinte instrução:

DBCC traceoff (830, -1)
Esta configuração é válida somente para a vida útil do processo do SQL Server.

Observação: Uma solicitação de e/s for interrompida ou preso é relatada apenas uma vez. Por exemplo, se a mensagem informa que 10 solicitações de e/s estão desativadas, os 10 relatórios não ocorrerá novamente. Se a próxima mensagem relata que 15 solicitações de i/o estiver desativadas, isso significa que 15 novas solicitações de e/s ficam presas.

O pacote de solicitação de e/s (IRP) de rastreamento

SQL Server usa as chamadas de API do Microsoft Windows padrão 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 do IRP, use o seguinte:

  • Assistência de suporte da plataforma Microsoft
  • O depurador do kernel
Para obter mais informações sobre o IRP e IRP rastreamento, vá para o seguinte site da Microsoft e procure a palavra-chave "IRP":Observação: Depuração de kernel pode ser um processo invasivo porque a depuração de kernel pode exigir que você pare o sistema para concluir as ações de depuração. Recomendamos que você verifique as atualizações disponíveis para os seguintes itens:

  • O BIOS
  • O firmware
  • Outros componentes de caminho de i/o
Contate os fornecedores de hardware antes de executar ações adicionais de depuração. A sessão de depuração provavelmente envolverá um driver de terceiros, o firmware ou o componente de driver de filtro.

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

Em geral o desempenho do sistema pode desempenham um papel fundamental no processamento de i/o. Você deve levar a integridade geral do sistema em consideração quando estiver investigando relatórios das operações de i/o interrompido ou presos. Carga excessiva pode fazer com que todo o sistema lento. Isso inclui processamento de i/o. O comportamento do sistema no momento em que ocorre o problema pode ser um fator-chave na determinação da causa raiz do problema. Por exemplo, se o uso da CPU é alto ou se o uso da CPU permanecer alto quando o problema ocorrer, esse comportamento pode indicar que um processo do sistema está usando muito da CPU que outros processos estão sendo afetados negativamente.

Contadores de desempenho

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

  • Média de disco s/transferência
  • Comprimento da fila de disco médias
  • Comprimento da fila de disco atual
Por exemplo, a hora média de disco s/transferência em um computador que esteja executando o SQL Server normalmente é menor do que 15 milissegundos. Se o valor de média de disco s/transferência subidas, isso indica que o subsistema de e/s não ideal acompanhar a demanda de e/s.

Tenha cuidado ao usar os contadores de desempenho como SQL Server tira total proveito dos recursos de e/s assíncronos que excedem muito os comprimentos da fila de disco. Portanto, mais comprimentos de filas de disco sozinhos não indicam um problema.

No Monitor de sistema do Windows, você pode analisar os contadores de "disco físico: Bytes de disco/s" para cada afetados disco e comparar a taxa de atividade contra os contadores "processo: IO dados Bytes/Sec" e "processo: IO outro Bytes/sec" cada processo identificar se um conjunto específico de processos está gerando i/o excesso de solicitações. Há várias outras e/s relacionados contadores disponíveis no processo de objeto que revela informações mais granulares. Se você determinar que uma instância do SQL Server é responsável pela carga excessiva de i / o no servidor, consulte a seção seguinte em "Índices e paralelismo". Para uma discussão detalhada sobre a detecção e solução de gargalos de i/o, consulte a seção "Gargalos de i/o" white paper MSDN Solução de problemas de desempenho no SQL Server 2008 ou Solucionar problemas de desempenho no SQL Server 2005.

Índices e paralelismo

Com freqüência, picos de i/o ocorrem porque existe um índice. Esse comportamento pode enviar gravemente o caminho de i/o. Uma passagem que usa o Assistente de ativação índice (ITW) pode ajudar a resolver a pressão de i/o no sistema. Se uma consulta se beneficia de um índice, em vez de uma verificação de tabela, ou talvez se ela usa uma classificação ou um hash, o sistema pode ter as seguintes vantagens:

  • É feita uma redução de e/s física é necessária para concluir a ação que cria diretamente os benefícios de desempenho para a consulta.
  • Menos páginas no cache de dados precisam ser transformada. Portanto, as páginas que estão no cache de dados permanecem relevantes para consultas ativas.
  • Classifica e hashes são usados porque um índice pode estar ausente ou as estatísticas estão desatualizadas. Você pode reduzir tempdb uso e contenção, adicionando um ou mais índices.
  • Uma redução será feita em recursos, operações paralelas ou ambos. Porque o SQL Server não garante a execução paralela da consulta e é considerada a carga no sistema, é melhor otimizar todas as consultas de execução serial. Para otimizar uma consulta, abra o Query Analyzer e definir o valor sp_configure da grau máximo de paralelismo opção de 1. Se todas as consultas são ajustadas para executar rapidamente como uma operação serial, execução paralela geralmente é apenas um resultado melhor. No entanto, muitas vezes de execução em paralelo é selecionada porque a quantidade de dados é grande. Para um índice ausente, uma grande classificação talvez precise ocorrer. Vários trabalhadores que estão realizando a operação de classificação criará uma resposta mais rápida. No entanto, essa ação pode aumentar significativamente a pressão sobre o sistema. As solicitações de muitos trabalhadores leitura grandes podem causar uma intermitência de i/o em conjunto com a maior utilização da CPU de vários trabalhadores. Muitas vezes, uma consulta pode ser ajustada para executar mais rapidamente e usar menos recursos se um índice for adicionado ou se outra ação ajuste ocorre.

Exemplos práticos de suporte do Microsoft SQL Server

Os exemplos a seguir foram tratados pelo suporte do Microsoft SQL Server e suporte a plataformas de escalonamento. Esses exemplos destinam-se a fornecer um quadro de referência e um conjunto de ajuda sobre as suas expectativas interrompida e preso situações de e/s e sobre como um sistema pode ser afetado ou pode responder. Não há nenhum hardware específico ou um conjunto de drivers que representam qualquer risco específico ou maior risco em relação a outro. Todos os sistemas são iguais nesse sentido.

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

Uma tentativa de gravar um arquivo de log do SQL Server periodicamente fica preso por aproximadamente 45 segundos. A gravação de log não terminar de forma atempada. Esse comportamento cria uma condição de bloqueio que faz com que o tempo limite do cliente de 30 segundos.

O aplicativo enviada uma confirmação para o SQL Server e a confirmação ficou preso como uma gravação de log pendentes. Esse comportamento faz com que a consulta continue mantendo bloqueios e bloquear as solicitações recebidas de outros clientes. Em seguida, outros clientes Iniciar tempo limite. Isso aumenta ainda mais o problema porque o aplicativo não reverter transações abertas quando ocorre um tempo limite da consulta. Isso cria centenas de transações abertas que estão mantendo bloqueios. Portanto, ocorre uma situação de bloqueio grave.

Para obter mais informações sobre tratamento e bloqueio de transação, consulte o seguinte artigo da Base de Conhecimento Microsoft:Um site de serviços de aplicativo usando o pool de conexões. Como mais conexões ficam bloqueados, o site cria mais conexões. Essas conexões ficam bloqueadas e o ciclo continua.

Após aproximadamente 45 segundos, a gravação de log termina. No entanto, até este momento, centenas de conexões de backup. Os problemas de bloqueio causar vários minutos de tempo de recuperação para SQL Server e para o aplicativo. Combinado com os problemas de aplicativo, a condição de i/o interrompido tem um efeito muito negativo no sistema.
Resolução
Esse problema foi controlado a uma solicitação de e/s presa em um driver de adaptador de barramento de Host (HBA). O computador tinha várias placas HBA com suporte de failover. Quando um HBA estava atrás ou não estava se comunicando com Storage Area Network (SAN), o valor de tempo limite "repetir antes do failover" foi definido como 45 segundos. Quando o tempo limite foi excedido, a solicitação de e/s foi roteada para o segundo HBA. O segundo HBA atendeu à solicitação e concluído rapidamente. Para evitar tais condições de parada, o fabricante do hardware recomendável uma configuração de "repetição antes do failover" de 5 segundos.

Exemplo 2: Filtrar intervenção do driver

Muitos programas de software antivírus e produtos de backup usam drivers de filtro de i/o. Esses drivers de filtro de i/o tornam-se parte da pilha de solicitação de e/s, e eles têm acesso à solicitação de IRP. Microsoft Product Support Services teve vários problemas de bugs criar preso condições de e/s ou interrompida condições de e/s em uma implementação de driver de filtro.

Uma condição é um driver de filtro para o processamento de backup que permitiu um backup dos arquivos que foram abertos quando ocorreu o backup. O administrador do sistema tinha incluído o diretório de arquivos de dados do SQL Server no arquivo de seleções de backup. Durante o backup, o backup tentou obter a imagem correta do arquivo no momento em que o backup foi iniciado. Esse procedimento adiada solicitações de e/s. As solicitações de i/o pudesse concluir apenas um de cada vez, como eles foram tratados pelo software.

Quando o backup é iniciado, o desempenho do SQL Server descartada drasticamente porque i/os do SQL Server foram forçados a concluir um de cada vez. Para agravar o problema, a lógica de "uma vez" foi, de forma que a operação não pôde ser executada assincronamente. Portanto, quando o SQL Server esperado para postar uma solicitação de e/s e continuar, o trabalhador ficou travado na leitura ou a chamada de gravação até que a solicitação de e/s concluída. Tarefas de processamento como uma SQL Server de leitura antecipada efetivamente foram desabilitadas pelas ações do driver de filtro. Além disso, outro erro do driver de filtro deixado as ações "uma vez" em processo, mesmo quando o backup foi concluído. A única maneira de restaurar o desempenho do SQL Server foi para fechar e reabrir o banco de dados ou reiniciar o SQL Server para que o identificador de arquivo foi lançado e readquirido sem a interação do driver de filtro.
Resolução
Para resolver esse problema, os arquivos de dados do SQL Server foram removidos do processo de backup do arquivo. O fabricante do software também corrigido o problema deixado o arquivo no modo de "uma vez".

Exemplo 3: Oculta erros

Muitos sistemas high-end têm multicanais caminhos de i/o para lidar com o balanceamento de carga ou atividades semelhantes. Suporte aos produtos Microsoft encontrou problemas com o software onde a falha de uma solicitação de e/s, mas o software não manipula corretamente a condição de erro de balanceamento de carga. O software pode tentar repetições infinitas. A operação de i/o fica preso e do SQL Server não pode concluir a ação especificada. Assim como o log gravar condição descrito anteriormente, muitos comportamentos ruim do sistema podem ocorrer depois que dessas condições wedges o sistema.
Resolução
Para resolver esse problema, geralmente é necessário reiniciar o SQL Server. No entanto, às vezes você deve reiniciar o sistema operacional para restaurar o processamento. Também recomendamos que você obtenha uma atualização de software do fornecedor e/s.

Exemplo 4: Armazenamento remoto de espelhamento e unidades raid

Muitos sistemas de usam o espelhamento ou tomar medidas semelhantes para evitar perda de dados. Alguns sistemas que usam o espelhamento são baseados em software e algumas são baseadas em hardware. A situação que normalmente é descoberta pela Microsoft Support para esses sistemas é maior latência.

Um aumento no tempo de i/o geral ocorre quando o i/o deve terminar ao espelho antes da e/s seja considerado concluído. Para instalações de espelhamento remoto, tentativas de rede podem se tornar envolvidas. Quando ocorrerem falhas de disco e o sistema raid está sendo reconstruído, o padrão de e/s também pode ser interrompido.
Resolução
Configurações rígidas são necessárias para reduzir a latência em espelhos ou para operações de reconstrução de raid.

Para obter mais informações, consulte os requisitos para o SQL Server oferecer suporte ao espelhamento remoto de bancos de dados do usuário.

Exemplo 5: compactação

A Microsoft não suporta arquivos de log em unidades compactadas ou arquivos de dados do Microsoft SQL Server 2000 e Microsoft SQL Server 7.0. A compactação NTFS não é segura para o SQL Server porque a compactação NTFS quebras de protocolo gravar log à frente (WAL). A compactação NTFS também requer processamento maior para cada operação de e/s. Compactação cria "uma vez" como o comportamento que faz com que haja outros problemas graves de desempenho.
Resolução
Para resolver esse problema, descompacte os dados e os arquivos de log.

Para obter mais informações, consulte Descrição do suporte para bancos de dados do SQL Server nos volumes compactados.

Pontos de dados adicionais

PAGEIOLATCH_ * e writelog aguarda em exibições de gerenciamento dinâmico de DM os_wait_stats (DMV) é indicadores importantes para investigar o desempenho e disponibilidade. Se você vir esperas PAGEIOLATCH significativas, isso significa que o SQL Server está aguardando o subsistema de e/s. Uma certa quantidade de PAGEIOLATCH de espera é normal e o comportamento esperado. No entanto, se a média de tempos de espera de PAGEIOLATCH consistentemente maior que 10 milissegundos (ms), você deve investigar por que o subsistema de e/s está sob pressão. Para obter mais informações, consulte os seguintes documentos:



SQL Server requer que os sistemas de suportam "entrega garantida para mídias estáveis" conforme descrito em os requisitos do programa SQL Server i/o de confiabilidade. Para obter mais informações sobre os requisitos de entrada e saídas para o mecanismo de banco de dados do SQL Server, consulte o seguinte artigo da Base de Conhecimento Microsoft:

EventID i / 833

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 897284 - Última Revisão: 10/01/2015 04:24:00 - Revisão: 1.0

Microsoft SQL Server 2014 Business Intelligence, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Enterprise Core, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2012 Web, Microsoft SQL Server 2012 Business Intelligence, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Datacenter, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2008 R2 Web, Microsoft SQL Server 2008 R2 Workgroup, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition

  • kbinfo kbtshoot kbsqlserv2000sp4fea kbmt KB897284 KbMtpt
Comentários