Boletim técnico do SQL Server - como resolver um impasse

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: 832524

Boletim técnico do SQL Server

Tópico abrangidos por este problema: como resolver um impasse
Objectivo
Para identificar, para resolver e recomendar uma solução para resolver um impasse.
Introdução
Este artigo examina uma situação de impasse e fornece passos de resolução de impasse. Cada impasse pode ser diferente e pode ser causado por diversas variáveis de ambiente diferente. As informações fornecidas neste artigo podem ajudar a identificar e resolver um impasse.
Caso prático
Um caso prático, vamos examinar um sistema 911 que tenha os seis operadores. Durante a actividade de pico, a aplicação front-end do Microsoft Visual Basic que estejam a utilizar tem ligações interrompidas. Devido a ligações interrompidas, os operadores tem de introduzir novamente dados. Para um sistema 911 que funciona 24 horas por dia, sete dias por semana, este comportamento é inaceitável.
O que é um impasse?
Um impasse ocorre quando o processo de servidor do sistema dois IDs(SPIDs) estão a aguardar um recurso e nenhum processo pode avançar uma vez que o processo de theother está a impedir o recurso a obter.

O thread de lockmanager verifica a existência de bloqueios. Quando detectionalgorithm de impasse de um Gestor de bloqueios detecta um impasse, o Gestor de bloqueios escolhe uma dos SPID como avictim. O Gestor de bloqueios inicia uma mensagem de erro 1205 é enviada para sobre no cliente e o Gestor de bloqueios elimina se o SPID. O SPID para matar liberta os recursos e permite que outros SPID continuar. Matar o SPID que seja vítima de thedeadlock é o que faz com que a ligação quebrada que experiências da aplicação de Visual Basicfront-end.

Numa aplicação bem concebida, a aplicação front-end deve aplicar um véu para o erro 1205, voltar a ligar ao SQL Server e, em seguida, voltar a submeter a transacção.

Althoughdeadlocks pode ser minimizado, não pode ser completamente evitadas. É por aplicação thefront end deve ser concebida para lidar com bloqueios fatais.
Como identificar um impasse
Passo 1

Para identificar um impasse, primeiro tem de obter loginformation. Se suspeitar que um impasse, tem de recolher informações sobre the(SPIDs) e os recursos que estão envolvidos de impasse. Para tal, addthe-T1204 e -parâmetros de arranque de T3605 para o SQL Server. Para adicionar estes parâmetros de twostartup, siga estes passos:
  • Inicie o SQL Server Enterprise Manager.
  • Seleccione e, em seguida, faça duplo clique no servidor.
  • Clique em Propriedades.
  • Clique em parâmetros de arranque.
  • Na caixa de diálogo Parâmetros de arranque , escreva -T1204 o texto de parâmetros de caixa e, em seguida, clique em Adicionar.
  • Na caixa de texto de parâmetros , escreva -T3605e, em seguida, clique em Adicionar.
  • Clique em OK.

Os parâmetros de arranque terão efeito quando o SQL Serveris parado e, em seguida, novamente iniciado.

-T1204 arranque parâmetro collectsinformation sobre o processo e os recursos quando o detectionalgorithm de impasse encontra um impasse. -T3605 arranque parâmetro escritas thisinformation para os registos de erros do SQL Server.

Recolhe de startupparameter-T1205 informações cada vez que o algoritmo de impasse verifica para um impasse, impasse de whena não são encontradas. Não é necessário utilizar o parâmetro-T1205.

Se utilizar o parâmetro de arranque-T1205, segue-se um sampleof de saída que estarão presentes no registo de erros do SQL Server:

2003-05-14 11:46:26.76 spid4     Starting deadlock search 12003-05-14 11:46:26.76 spid4     Target Resource Owner:2003-05-14 11:46:26.76 spid4      ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x43CAB580) Value:0x42bdf3402003-05-14 11:46:26.76 spid4      Node:1       ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x43CAB580) Value:0x42bdf3402003-05-14 11:46:26.76 spid4     2003-05-14 11:46:26.76 spid4     End deadlock search 1 ... a deadlock was not found.2003-05-14 11:46:26.76 spid4     ----------------------------------2003-05-14 11:46:31.76 spid4     ----------------------------------2003-05-14 11:46:31.76 spid4     Starting deadlock search 2


Por vezes, não poderá parar e iniciar novamente o SQL Server. Nesse caso, youcan utilizar Query Analyzer para executar o seguinte comando para activar os sinalizadores de deadlocktrace.

Nota Desta forma é possível recolher informações sobre o deadlocksimmediately. "-1" indica todos os SPID.

dbcc traceon (1204, 3605, -1)godbcc tracestatus(-1)go

Passo 2

Em seguida, tem de recolher um rastreamento SQL Profiler. Ifyou activar o sinalizador de rastreamento de impasse, irá obter a maior parte da requiredinformation, mas nem sempre. Por exemplo, no estudo de acase a identifiedthat de saída de sinalizador de rastreio um sistema de sp_cursoropen procedimento armazenado e uma "actualização tblQueuedEvents setnotifyid = 3, ResynchDate" declaração estiveram envolvidos na adeadlock. Infelizmente, não souber thedefinition do procedimento armazenado do sistema sp_cursoropen . Alsodo de tem a instrução de actualização concluída porque o mesmo wastruncated.

SQL Profiler pode obter as instruções completas para além dos planos de execução das demonstrações. Um rastreamento SQL Profiler também tem um lockevent de "impasse" e "cadeia de impasse". "Impasse" corresponde a T1204 o sinalizador e "cadeia de impasse" corresponde ao pavilhão - T1205. Activar os sinalizadores de rastreio de impasse e executar um rastreamento SQL Profiler durante a occurrenceof um impasse devem fornecer-lhe os dados que tem de ter a resolução de problemas de adeadlock. Neste caso e, outros utilizadores, executar o SQL Profiler muda a execução de timingof suficiente para impedir o impasse. Por conseguinte, será typicallycapture as informações de impasse com os sinalizadores de rastreio e, em seguida, execute SQLProfiler.
Resolução de problemas de um impasse
Depois de ocorre um impasse, youcan reunir informações sobre o bloqueio, utilizando o utilitário desqldiag e utilizando o SQL Profiler. Na saída do ficheiro de theSQLDiag.txt, procure uma entrada "Em espera para o gráfico". A "aguardar-para o gráfico" entryindicates que foi detectado um impasse.

Segue-se uma saída que poderá ver no registo de erros do SQL Server quando utiliza o parâmetro de arranque de T1205 a sampleof.

2003-05-05 15:11:50.80 spid4    Wait-for graph2003-05-05 15:11:50.80 spid4    Node:12003-05-05 15:11:50.80 spid4    ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x33AE1538) Value:0x1932003-05-05 15:11:50.80 spid4    Victim Resource Owner:2003-05-05 15:11:50.80 spid4    ResType:LockOwner Stype:'OR' Mode: X SPID:60 ECID:0 Ec:(0x1F1BB5B0) Value:0x1932003-05-05 15:11:50.80 spid4    Requested By: 2003-05-05 15:11:50.80 spid4    Input Buf: RPC Event: sp_cursoropen;12003-05-05 15:11:50.80 spid4    SPID: 55 ECID: 0 Statement Type: EXECUTE Line #: 12003-05-05 15:11:50.80 spid4    Owner:0x1937f2a0 Mode: S        Flg:0x0 Ref:1 Life:00000000 SPID:55 ECID:02003-05-05 15:11:50.80 spid4    Grant List 0::2003-05-05 15:11:50.80 spid4    KEY: 8:1653632984:2 (da00ce043a9e) CleanCnt:1 Mode: U Fl ags: 0x0 2003-05-05 15:11:50.80 spid4    Node:22003-05-05 15:11:50.80 spid4    ResType:LockOwner Stype:'OR' Mode: S SPID:55 ECID:0 Ec:(0x33AE1538) Value:0x1932003-05-05 15:11:50.80 spid4    Requested By: 2003-05-05 15:11:50.80 spid4    Input Buf: Language Event: Update tblQueuedEvents Set NotifyID = 2, ResynchDate2003-05-05 15:11:50.80 spid4    SPID: 60 ECID: 0 Statement Type: UPDATE Line #: 12003-05-05 15:11:50.80 spid4    Owner:0x1936e420 Mode: X        Flg:0x0 Ref:0 Life:02000000 SPID:60 ECID:02003-05-05 15:11:50.80 spid4    Grant List 0::2003-05-05 15:11:50.80 spid4    KEY: 8:1653632984:1 (2d018af70d80) CleanCnt:1 Mode: X Flags: 0x0


Na entrada "Em espera para o gráfico", tem de nó 1 e Nó2. Em cada nó, terá uma secção de concessão e uma secção de pedido. O grantsection é a lista"subsídio" e a secção de pedido é "RequestBy".
Em cada nó, pode identificar o seguinte:
  • O SPID.
  • O comando que o SPID estava em execução.
  • O recurso.
  • O modo de bloqueio no recurso.

Por exemplo, no nó 1, a lista de acesso, SPID 55 foi concedido um bloqueio de actualização, modo: U, num recurso chave: 8:1653632984:2. 8 = DBID, 1653632984 = ObjectID e 2 = Indid. Para obter o número de identificação da base de dados, execute o procedimento armazenado sp_helpdb . Para obter a tabela, execute o seguinte código:
select * from sysobjects where id = 1653632984


Para obter o índice, execute o seguinte código:
select * from sysindexes where indid = 2 and id = 1653632984

Se IndexId for igual a 2, saberá que o índice é um nonclusteredindex. O comando que estava em execução SPID 55 era o procedimento armazenado sp_cursoropen .

No nó 2, a lista de acesso, SPID 60 foi concedido um bloqueio exclusivo, modo: X, no recurso chave: 8:1653632984:1.8 = DBID, 1653632984 = ObjectID, 1 = Indid. Esta é a mesma tabela mas índice 1 é o índice clusterizado. O comando que estava em execução SPID 60 era:
Update tblQueuedEvents Set NotifyID = 2, ResynchDate

Um IndexId que é igual a 1 é um índice agrupado.

AnIndexId é igual a 2 é um índice agrupado.

Nota Bloqueios totais são muito sensíveis ao tempo.

Em seguida, no nó 1, pedido por SPID 55 solicitado um bloqueio partilhado, modo: S, no IndexId = 1. Nó 2, solicitar por SPID 60 solicitar um bloqueio exclusivo, modo: X, no IndexId = 2. Becausethese de pedidos lock ocorrer ao mesmo tempo, ocorre o impasse. Cada SPID'sgranted bloqueios estão a impedir que os bloqueios pedidos continuar.

Thefollowing tabela mostra o gráfico de compatibilidade de bloqueio. Para compatibilidade de aboutlock mais informações, consulte o tópico "Bloqueio compatibilidade" no SQL Server 2000 BooksOnline.

Gráfico de compatibilidade de bloqueio
RequestedmodeÉSUIXSEISX
Shared(IS) intençãoSimSimSimSimSimNão
Partilhado (S)SimSimSimNãoNãoNão
Actualização (U)SimSimNãoNãoNãoNão
Exclusive(IX) intençãoSimNãoNãoSimNãoNão
Partilhado com a intenção de exclusivo (seis)SimNãoNãoNãoNãoNão
Exclusive(X)NãoNãoNãoNãoNãoNão


Em seguida, observando a saída, identifyObjectId 1653632984 como a tabela de tblQueuedEvents e obter um procedimento armazenado sp_help de saída para a tabela. Existem dois índices na tabela. Os dois índices foram ix_tblQueuedEvents e PK_tblQueuedEvent. ix_tblQueuedEvents é um índice clusterizado no ResynchDate e PK_tblQueuedEvent é uma chave primária, o índice agrupado exclusivo no EventSID.

O rastreio de SQL Profiler não foi possível capturar o deadlockoccurrence. Lembre-se de bloqueios totais são muito dependente do tempo. A sobrecarga de SQLProfiler provavelmente adicionado algum tempo para a execução de um dos andthat a processos impedidos de SQL Profiler obter numa situação de impasse. No entanto, itdid fornecem informações queutilize pode utilizar para resolver o problema. Encontrado thefull update tblQueuedEvents declaração ser semelhante à seguinte:

Update tblQueuedEvents Set NotifyID = 2, ResynchDate = '5/7/2003 10:44:16' where eventSID = 73023
Encontrou, também, o plano de execução. Ainda não tiver a declaração de procedimento completo sp_cursoropen armazenado, mas tem suficiente torecommend de informações uma solução que irá resolver o impasse.

Aqui é o plano de theexecution.

Nota Este plano de execução específico é de leitura para a direita para a leftand de baixo para cima.

StmtText                                                      				                                                                           				   				                                  --------------------------------------------------------------------------------------------------------------------------------------------------------------------				Update tblQueuedEvents Set NotifyID = 2, ResynchDate = '5/7/2003 10:44:16'				where eventSID = 73023                                                     				   				                    |--Clustered Index				Update(OBJECT:([SOTS].[dbo].[tblQueuedEvents].[ix_tblQueuedEvents ]),				SET:([tblQueuedEvents].[NotifyID]=[@1],				[tblQueuedEvents].[ResynchDate]=[Expr1004]))       |--Top(1)                                                                 				                                                                           				   				                          |--Compute Scalar(DEFINE:([Expr1004]=Convert([@2])))                				                                                                           				   				                                 |--Index				Seek(OBJECT:([SOTS].[dbo].[tblQueuedEvents].[PK_tblQueuedEvents]),				SEEK:([tblQueuedEvents].[EventSID]=[@3]) 
Recomendamos uma solução para resolver thedeadlock
Tenha em atenção que a instrução de actualização está a executar uma "actualização do índice clusterizado" no índice agrupado. Por conseguinte, a nonclusteredindex e o índice clusterizado têm ambos de ser actualizados. O índice clusterizado é ix_tblQueuedEvents e o índice agrupado é PK_tblQueuedEvents. Para efectuar as actualizações, a instrução de actualização tem os bloqueios de obtainexclusive em ambos os índices. Estes dois índices são os índices que areinvolved de impasse. A revisão de vestígios de SQL Profiler, fez não as consultas de seeany utilizado a ResynchDate na cláusula WHERE. Statementswere muito específica e utilizadas a EventSID na cláusula WHERE. A opção mais adequada de um clusteredindex seria EventSID. Com estas informações e um debate com thecustomer, verificámos que o índice de ResynchDate foi antigo e não era necessário. Recomendamos que o cliente largar o índice de ix_tblQueuedEvents na ResynchDate e que fazem PK_tblQueuedEvent um índice agrupado. Isto resolver o deadlocksituation.

Isto é apenas um exemplo de um impasse que involveslocks do incidente. Bloqueios fatais também podem envolver paralelismo e envolver threads. Caninvolve um, dois, três, ou os SPIDs mais e recursos. Com qualquer caso de impasse, tem de obter o – T1204 saída de parâmetro de arranque e traceto o SQL Profiler identificar, para resolução de problemas e para resolver o impasse. O deadlocksituation implicarão diferentes processos e recursos. Por conseguinte, solutionswill variam de caso para caso. Métodos típicos que pode utilizar para resolver deadlocksinclude:
  • Adicionar e eliminar índices.
  • Adicionar sugestões de índice.
  • Modificar a aplicação para aceder a recursos num padrão semelhante.
  • A remover a actividade da transacção como accionadores. Por predefinição, os activadores são transaccionais.
  • Manter transacções tão curtas quanto possível.

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 832524 - Última Revisão: 04/08/2016 09:53:00 - Revisão: 2.0

Microsoft SQL Server 2000 Standard Edition

  • kbsqlsetup kbtypenonkb kbpubtypett kbresource kbquery kbperformance kbserver kbdatabase kbhowto kbinfo kbcode kbmt KB832524 KbMtpt
Comentários