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

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 897284
Sumário
Um sistema de gestão de base de dados (DBMS), como o SQL Server, depende da actualidade dos ficheiro entrada e saída (e/s) de operações. Qualquer um dos seguintes itens pode causar operações de e/s presa ou interrompidas e afectem negativamente o desempenho e capacidade de resposta do SQL Server:

  • Problemas de hardware
  • Hardware incorrectamente configurado
  • Definições de firmware
  • Controladores de filtro
  • Compressão
  • Erros
  • Outras condições no caminho de e/s
Estes problemas e/s podem causar o seguinte comportamento ocorra:

  • Bloquear
  • Contenção de bloqueios e tempos limite
  • Tempo de resposta lento
  • Esticar dos limites de recurso
A partir do Microsoft SQL Server 2000 Service Pack 4 (SP4), SQL Server inclui uma lógica que ajuda a detectar parado e bloqueados condições para a base de dados e/s leituras e escritas e leituras de e/s de ficheiro de registo e escritas. Quando uma operação de e/s pendente foi durante 15 segundos ou mais, o SQL Server efectua os seguintes passos:

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

    O texto da mensagem de registo é semelhante ao seguinte:

    00:21:25.26 2004-11-11 spid1 SQL Server encontrou 192 ocorrências de e/s pedidos tendo mais de 15 segundos a concluir no ficheiro [E:\SEDATA\stressdb5.ndf] [stressdb] (7) da base de dados. O identificador de ficheiro do sistema operativo é 0x00000000000074D4. É o desvio da mais recente e/s longa: 0x00000000022000 ".

Explicação de mensagem informativa

Texto da mensagemDescrição
Número de > ocorrênciasO número de pedidos de e/s não foi concluído a leitura ou a operação de escrita em menos de 15 segundos.
Informações de ficheiroO nome de ficheiro completo, o nome de base de dados e o número de identificação (DBID) da base de dados.
ProcessarO identificador de sistema operativo do ficheiro. Pode utilizar o identificador de sistema operativo com depuradores ou com outros utilitários para ajudar a controlar pedidos de pacotes (IRP) do pedido de e/s.
DesvioO desfasamento do último preso a operação de e/s ou parado, a última operação de e/s. Pode utilizar o deslocamento com depuradores ou com outros utilitários para ajudar a controlar pedidos IRP.

Nota Quando a mensagem informativa é escrita para o registo de erros do SQL Server, a operação de e/s já não pode bloqueada ou parada.
Esta mensagem informativa indica que a carga actual poderá estar a ocorrer uma das seguintes condições:

  • A carga de trabalho é superior às capacidades de caminho de e/s.
  • A carga de trabalho é superior a funcionalidades de sistema actuais.
  • O caminho e/s tem software de mau funcionamento; Talvez firmware ou um problema de controladores.
  • O caminho e/s tem componentes de hardware com problemas.
Para mais informações sobre padrões de e/s do SQL Server 2000, vá para o seguinte Web site da Microsoft:Nota Este artigo da TechNet também se aplica ao Microsoft SQL Server 2005 e versões posteriores.
Mais Informação

E/s presa e interrompida e/s

E/s presa

E/s presa é definido como um pedido de e/s que não é concluída. Frequentemente, e/s presa indica numa IRP presa. Para resolver uma condição e/s presa, normalmente, tem de reiniciar o computador ou executar uma acção semelhante. Uma condição e/s presa indica, normalmente, um dos seguintes:

  • Problemas de hardware
  • Um erro de um componente do caminho e/s

Interrompida e/s

Interrompida e/s é definido como um pedido de e/s que concluir ou que demora demasiado tempo a concluir. Comportamento de e/s bloqueado ocorre normalmente por uma das seguintes razões:

  • A configuração de hardware
  • As definições de firmware
  • Um problema de controladores de filtro que necessite de assistência do hardware ou o fornecedor de software para analisar e resolver

SQL Server parado e/s e bloqueados e/s de registo e comunicação

Suporte do Microsoft SQL Server processa muitos casos anualmente que envolvam problemas de e/s presa ou interrompidos. Estes problemas e/s aparecem de diferentes formas. Problemas de e/s são alguns dos problemas mais difícil para diagnosticar e depurar e necessitam de tempo significativo e recursos para a depuração da Microsoft e de cliente. As funcionalidades de relatório que foram adicionadas ao SQL Server 2000 SP4 e versões posteriores significativamente reduzem o tempo que é necessário para identificar um problema de e/s.

O relatório e a gravação de pedidos de e/s destinam-se numa base por ficheiro. A detecção e a comunicação de pedidos de e/s interrompidos e presa são duas acções distintas.

Gravação

Existem dois momentos quando ocorre uma acção de registo no SQL Server. A primeira acontece quando a operação de e/s realmente concluída. Se um pedido de e/s demora mais de 15 segundos a concluir, ocorre uma operação de registo. O segundo momento em que é quando a escrita lenta escreveu é executado. Quando é executada a escrita lenta escreveu, a escrita lenta escreveu verifica todos os dados pendentes e o registo pendente pedidos de e/s de ficheiros. Se tiver sido excedido o limite de 15 segundos, ocorre uma operação de registo.

Relatórios

Relatório de erros em intervalos com 5 minutos ou mais entre si. Relatório de erros quando é efectuado o seguinte pedido de e/s no ficheiro. Se tiver ocorrido uma acção de registo e igual ou superior a 5 minutos passaram desde o último relatório ocorreu, a mensagem informativa que é mencionada na secção "Sumário" é escrita para o registo de erros do SQL Server.

O limiar de 15 segundos não será ajustável. No entanto, pode desactivar a detecção de e/s de bloqueada ou presa utilizando o sinalizador de rastreio 830, embora a Microsoft não recomenda que o faça.

Para desactivar a detecção quando inicia o SQL Server, utilize o -T830 parâmetro de arranque para desactivar a detecção de cada vez que o SQL Server é iniciado. Para desactivar a detecção de uma instância do SQL Server que está actualmente em execução, utilize a seguinte instrução:

DBCC traceoff (830, -1)
Esta definição é eficaz apenas durante a vida do processo do SQL Server.

Nota Um pedido de e/s que passa a ser parado ou bloqueado é reportado apenas uma vez. Por exemplo, se a mensagem indicar que 10 pedidos de e/s estão parados, os 10 relatórios não ocorrerá novamente. Se a mensagem seguinte indica que os 15 pedidos de e/s estão parados, isso significa que os 15 novos pedidos de e/s tem tornam-se parado.

O pacote de pedidos de e/s (IRP) de rastreio

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

  • WriteFile
  • ReadFile
  • WriteFileScatter
  • ReadFileGather
O pedido de leitura ou escrita é processado pelo Windows como um pacote de pedido de e/s (IRP). Para determinar o estado do IRP, utilize os seguintes procedimentos:

  • Assistência do Microsoft Platform Support
  • O depurador do kernel
Para mais informações sobre o IRP e IRP rastreio, vá para o seguinte Web site da Microsoft e procurar a palavra-chave "IRP":Nota Depuração de kernel pode ser um processo INVASIVO porque a depuração de kernel pode necessitar de parar o sistema para concluir as acções de depuração. Recomendamos que verifique todas as actualizações disponíveis para os seguintes itens:

  • O BIOS
  • O firmware
  • Quaisquer outros componentes do caminho de e/s
Contacte os fabricantes de hardware antes de executar acções de depuração adicionais. A sessão de depuração irá provavelmente envolver um controlador de outro fabricante, o firmware ou o componente de controlador de filtro.

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

Global o desempenho do sistema pode desempenhar um papel fundamental no processamento de e/s. Deve ter o estado de funcionamento geral do sistema em consideração quando estiver a investigar relatórios de bloqueada ou presa operações de e/s. Cargas excessivas podem provocar o sistema global é lenta. Isto inclui o processamento de e/s. O comportamento do sistema no momento em que ocorre o problema pode ser um factor-chave para determinar a origem do problema. Por exemplo, se ficar elevada utilização da CPU ou permanece elevada utilização da CPU quando o problema ocorrer, este comportamento poderá indicar que um processo no sistema está a utilizar tanta da CPU que outros processos estão a ser negativamente afectados.

Contadores de desempenho

Para monitorizar o desempenho de e/s, examine os seguintes contadores de desempenho para obter informações de caminho de e/s específicas:

  • Média de disco s. / transferência
  • Comprimento da fila de disco médio
  • Comprimento actual da fila de disco
Por exemplo, o tempo médio Disk Sec/Transfer num computador que esteja a executar o SQL Server é normalmente inferior a 15 milissegundos. Se o valor médio Disk Sec/Transfer climbs, isto indica que o subsistema de e/s é não óptimo manter com o pedido de e/s.

Tenha cuidado quando utilizar os contadores de desempenho, uma vez que o SQL Server tira pleno partido das capacidades de e/s assíncronas que push fortemente o comprimento da fila de disco. Por conseguinte, maior comprimento da fila de disco por si só não indicam um problema.

No Monitor de sistema do Windows, pode rever os contadores de "disco físico: Bytes de disco/seg" para cada afectados de disco e comparar a taxa de actividade contra os contadores "processo: Bytes de es dados/seg" e "processo: outros Bytes/seg de e/s" para cada processo que identifique se um conjunto de processos específico está a gerar excessivo e/s pedidos. Existem várias outras e/s relacionados com contadores disponíveis no processo de objecto que revela indicações mais granulares. Se determinar que uma instância do SQL Server é responsável pela carga excessiva de e/s no servidor, reveja a secção seguinte no "Índices e paralelismo". Para mais informações detalhadas sobre a detectar e resolver os congestionamentos de e/s, reveja a secção "Congestionamentos de e/s" na documentação do MSDN Resolução de problemas de desempenho do SQL Server 2008 ou Resolução de problemas de desempenho no SQL Server 2005.

Os índices e paralelismo

Frequentemente, rajada de e/s ocorre porque não existe um índice. Este comportamento pode ser gravemente empurrar o caminho e/s. Uma fase de que utiliza o Assistente de activação de índice (ITW) poderá ajudar a resolver a pressão de e/s no sistema. Se uma consulta de prestações de um índice em vez de uma pesquisa da tabela, ou talvez se utiliza uma ordenação ou hash, o sistema pode ter as seguintes vantagens:

  • Uma redução é efectuada na e/s física que é necessário para concluir a acção que cria directamente vantagens de desempenho para a consulta.
  • Menos páginas na cache de dados tem de ser invertido. Por conseguinte, essas páginas que estão na cache de dados permanecem relevantes para consultas activas.
  • Ordena e hashes são utilizados porque um índice pode estar em falta ou porque as estatísticas estão desactualizadas. Pode reduzir tempdb a utilização e contenção adicionando um ou mais índices.
  • Uma redução é efectuada em recursos, operações paralelas ou ambos. Uma vez que o SQL Server não garante a execução da consulta paralela e porque considera-se a carga no sistema, é melhor optimizar a todas as consultas de execução remota de série. Para optimizar uma consulta, abra o analisador de consultas e defina o valor de sp_configure do máximo grau de paralelismo opção para 1. Se todas as consultas são optimizadas para executar rapidamente uma operação de série, execução paralela é muitas vezes apenas um melhor resultado. No entanto, muitas vezes execução paralela é seleccionada porque a quantidade de dados é apenas grande. Para um índice em falta, poderá ter uma ordenação grande ocorra. Vários trabalhadores que estiverem a efectuar a operação de ordenação irão criar uma resposta mais rápida. No entanto, esta acção pode aumentar substancialmente a pressão no sistema. Pedidos de muitos trabalhadores leitura grandes podem causar uma rajada de e/s com maior utilização da CPU de vários trabalhadores. Número de vezes que uma consulta pode ser optimizada para executar mais rapidamente e utilize menos recursos se for adicionado um índice ou se ocorre outra acção de optimização.

Exemplos práticos de suporte do Microsoft SQL Server

Os exemplos seguintes foram processados pelo suporte de escalamento de plataformas e suporte do Microsoft SQL Server. Estes exemplos destinam-se para fornecer um quadro de referência e o conjunto da ajuda suas expectativas cerca parado e bloqueados situações de e/s e sobre como um sistema, poderão ser afectado ou poderá responder. Não existe nenhum hardware específico ou conjunto de controladores que apresentem qualquer risco específico ou o aumento do risco sobre outra. Todos os sistemas são iguais a este respeito.

Exemplo 1: Uma registo escrita que se encontra bloqueada durante 45 segundos

Uma tentativa para escrever um ficheiro de registo do SQL Server periodicamente fica retida durante cerca de 45 segundos. A escrita de registo não é concluída atempadamente. Este comportamento cria uma condição de bloqueio que faz com que as interrupções de cliente de 30 segundos.

O pedido apresentado a consolidação do SQL Server e a consolidação tornou-se bloqueadas como uma operação de escrita de registo pendentes. Este comportamento faz com que a consulta para continuar a exploração bloqueios e para bloquear pedidos recebidos de outros clientes. Em seguida, outros clientes inicia o tempo limite. Isto compostos o problema porque a aplicação não reverter transacções abertas quando ocorre um tempo de espera de consulta. Este procedimento cria centenas de transacções abertas que estão a segurar bloqueios. Por conseguinte, ocorre uma grave situação de bloqueio.

Para mais informações sobre transacções, processamento e de bloqueio, consulte o seguinte artigo na Microsoft Knowledge Base:A aplicação de serviços de um Web site utilizando o agrupamento de ligações. Como as ligações mais tornam-se bloqueadas, o Web site cria mais ligações. Estas ligações fique bloqueadas e o ciclo continuar.

Depois de aproximadamente 45 segundos, termina a escrita de registo. No entanto, por este tempo, centenas de ligações são cópias. Os problemas de bloqueio causam vários minutos de tempo de recuperação para o SQL Server e para a aplicação. Combinado com os problemas de aplicação, a condição de e/s interrompida tem um efeito negativo muito no sistema.
Resolução
Este problema foi registado a um pedido de e/s presa num controlador de adaptador de barramento anfitrião (HBA). O computador tiver várias placas de HBA com suporte de activação pós-falha. Quando um HBA foi atrás ou não estava a comunicar com a rede de área de armazenamento (SAN), o valor de tempo limite "Repetir antes da activação pós-falha" tiver sido configurado para 45 segundos. Quando o limite de tempo foi excedido, o pedido de e/s foi encaminhado para o HBA de segundo. A segunda HBA processado o pedido e rapidamente terminado. Para ajudar a impedir que essas condições de compartimentos, o fabricante de hardware recomendado uma definição de "Repetir antes da activação pós-falha" de 5 segundos.

Exemplo 2: Intervenção do controlador de filtro

Muitos programas de software antivírus e produtos de cópia de segurança utilizem controladores de filtro de e/s. Estes controladores de filtro de e/s tornam-se parte da pilha de pedido de e/s, e que tenham acesso ao pedido de IRP. Microsoft Product Support Services observou vários problemas de erros que criar condições de e/s de bloqueado ou parado, as condições de e/s numa implementação de controlador de filtro.

Uma tal condição era um controlador de filtro para o processamento cópia de segurança que a permissão de uma cópia de segurança dos ficheiros que estavam abertos quando ocorreu a cópia de segurança. O administrador do sistema tinha incluído o directório de ficheiro de dados do SQL Server nas selecções de cópia de segurança do ficheiro. Quando ocorreu a cópia de segurança, a cópia de segurança tentou obter a imagem correcta do ficheiro no momento da cópia de segurança iniciada. Este procedimento adiada pedidos de e/s. Os pedidos de e/s são permitidos para concluir a apenas um de cada vez à medida que foram processadas por software.

Quando iniciar a cópia de segurança, desempenho do SQL Server ignorado drasticamente porque a/s do SQL Server foram forçado a terminar um de cada vez. Aos compostos o problema, a lógica de "um de cada vez" foi tal que a operação de e/s não foi possível executar de modo assíncrono. Por conseguinte, quando o SQL Server esperado para registar um pedido de e/s e para continuar, o trabalhador foi bloqueado na leitura ou a chamada de escrita até que o pedido de e/s concluída. Tarefas de processamento, como um servidor de SQL leitura antecipada efectivamente foram desactivadas pelas acções do controlador de filtro. Além disso, o outro erro no controlador de filtro deixado as acções "um de cada vez" no processo, mesmo quando a cópia de segurança foi concluída. A única forma de restaurar o desempenho do SQL Server foi para fechar e reabrir a base de dados, ou reiniciar o SQL Server para que o identificador de ficheiro foi libertado e reacquired sem a interacção de controlador de filtro.
Resolução
Para resolver este problema, os ficheiros de dados do SQL Server foram removidos do processo de cópia de segurança do ficheiro. O fabrico de software também corrigido o problema que o ficheiro no modo de "um de cada vez".

Exemplo 3: Oculta erros

Muitos sistemas superior final tem multicanais caminhos de e/s para lidar com balanceamento de carga ou a actividades similares. Suporte técnico da Microsoft encontrou problemas com o software onde falhar de um pedido de e/s, mas o software não processa correctamente a condição de erro de balanceamento de carga. O software poderá tentar repetições infinitas. A operação de e/s fica retida e SQL Server não consegue concluir a acção especificada. Muito como o registo de escrever a condição de que foi descrita anteriormente, muitos dos comportamentos fraca sistema podem ocorrer depois de uma condição cunhas de guiamento com o sistema.
Resolução
Para resolver este problema, reiniciar o SQL Server é frequentemente necessário. No entanto, por vezes, tem de reiniciar o sistema operativo para restaurar o processamento. Também recomendamos que obtenha uma actualização de software do fornecedor e/s.

Exemplo 4: o ' Armazenamento remoto espelhamento (mirroring) e raid unidades

Muitos sistemas utilizam espelhamento (mirroring) ou tomem medidas semelhantes para evitar perda de dados. Alguns sistemas que utilizam o espelhamento (mirroring) são baseados em software e outros baseado em hardware. A situação que é normalmente detectada pelo Microsoft Support para estes sistemas é o aumento da latência.

Um aumento no período de tempo e/s global ocorre quando a e/s tem de ser concluída para o espelho antes da e/s é considerado completo. Para instalações de espelhos (mirror) remoto, podem intervir tentativas de rede. Quando ocorrem falhas de unidade e está a reconstruir o sistema de raid, o padrão de e/s também pode ser interrompido.
Resolução
As definições de configuração estrita são necessárias para reduzir a latência, espelhos ou operações de reconstrução raid.

Para mais informações, consulte os requisitos para o SQL Server suportar remoto espelhamento de bases de dados do utilizador.

Exemplo 5: compressão

A Microsoft não suporta o Microsoft SQL Server 7.0 ou ficheiros de dados do Microsoft SQL Server 2000 e ficheiros de registo em unidades comprimidas. Compressão NTFS não é segura para o SQL Server, uma vez que a compressão NTFS quebras de protocolo de escrita para a frente de registo (WAL). Compressão NTFS também necessita de um aumento de processamento para cada operação de e/s. Compressão cria "um de cada vez" como comportamento provoca problemas de desempenho graves a ocorrer.
Resolução
Para resolver este problema, descomprima os dados e os ficheiros de registo.

Para mais informações, consulte a descrição do suporte para bases de dados do SQL Server em volumes comprimidos.

Pontos de dados adicionais

Vistas de gestão dinâmica sys.dm_os_wait_stats (das DMV) de períodos de espera PAGEIOLATCH_ * e writelog são indicadores chaves para investigar o desempenho de caminho de e/s. Se vir significativa aguarda PAGEIOLATCH, isto significa que o SQL Server está à espera no subsistema de e/s. Um determinado período de espera PAGEIOLATCH é normal e o comportamento está previsto. No entanto, se a média PAGEIOLATCH tempos de espera forem consistentemente superior a 10 milissegundos (ms), deverá investigar a razão pela qual o subsistema de e/s está sob pressão. Para mais informações, consulte os seguintes documentos:



SQL Server requer que os sistemas suportam "garantia de entrega para suportes de dados estáveis" conforme descrito em os requisitos do programa de fiabilidade do SQL Server e/s. Para mais informações sobre os requisitos de entrada e saídas para o motor de base de dados do SQL Server, vá para o seguinte artigo na Microsoft Knowledge Base:

ID de evento de e/s 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 2005 Server Workgroup, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL 2005 Server Enterprise

  • kbinfo kbtshoot kbsqlserv2000sp4fea kbmt KB897284 KbMtpt
Comentários
ERROR: at System.Diagnostics.Process.Kill() at Microsoft.Support.SEOInfrastructureService.PhantomJS.PhantomJSRunner.WaitForExit(Process process, Int32 waitTime, StringBuilder dataBuilder, Boolean isTotalProcessTimeout)