DetailPage-MSS-KB

Base de Dados de Conhecimento

ID do artigo: 169960 - Última revisão: quinta-feira, 16 de outubro de 2003 - Revisão: 3.0

 

Nesta página

Sumário

Microsoft SQL Server mantém a consistência de banco de dados e integridade transacional usando bloqueios. SQL Server versão 6.5 opcionalmente usa bloqueio em nível de linha para operações de inserção e utiliza o bloqueio em nível de página para outras operações. Como com qualquer sistema de banco de dados relacional, bloqueio pode levar a deadlocks entre usuários.

Por exemplo, suponha que User1 (ou Connection1) tem um bloqueio dados item "A" e quer um bloqueio no item de dados "B." Usuário2 tem um bloqueio no item de dados "B" e agora quer um bloqueio no item de dados "a". Nesse cenário de SQL Server, o Usuário1 ou Usuário2 será vítima de deadlock e o outro usuário será concedido o bloqueio solicitado.

No SQL Server, o desenvolvedor do aplicativo pode decidir qual conexão será o candidato para vítima de deadlock usando SET DEADLOCK_PRIORITY. Se o desenvolvedor não designa uma prioridade para deadlocks, o SQL Server seleciona a vítima de deadlock, escolhendo o processo que completa a cadeia circular de bloqueios.

Aplicativo de banco de dados de sistemas podem se comportar diferente quando transferidos de um banco de dados relacional para outro, baseado na implementação do sistema de banco de dados relacional. Uma das áreas para procurar alterações de comportamento está bloqueando. Este artigo explica como analisar os deadlocks no SQL Server e as técnicas que você pode usar para evitá-los.

Mais Informações

Este artigo enfatiza usando a saída do sinalizador de rastreamento T1204 para analisar deadlocks. Quando o sinalizador de rastreamento T1204 é definido, o SQL Server imprime informações sobre o deadlock quando ele ocorre. Para usar o sinalizador de traço, use o seguinte comando em um prompt de comando para iniciar o SQL Server:
   sqlservr -c -T1204
				

Os resultados de rastreamento são enviados na janela do console, a menos que você defina o sinalizador de rastreamento T3605, que envia a saída do rastreamento para o log de erros.

Os deadlocks podem ocorrer quando duas conexões atualizam tabelas na ordem oposta. Por exemplo, uma conexão insere em "exemplo1" primeira tabela e, em seguida, em "exemplo2", enquanto outra conexão insere em "exemplo2" primeira tabela e, em seguida, em "exemplo1" dentro de uma transação. Um cenário de exemplo é útil para ilustrar como evitar deadlocks.

A seguir estão as instruções SQL usadas para criar a tabela usada para este exemplo:
   create table example1 (column1 int, column2 char(20), column3 char(50))
   go
   create table example2 (column1 int, column2 char(20), column3 char(50))
   go
   declare @lvar int
   select @lvar = 0
   while @lvar < 500
   begin
   insert into example1 values (@lvar, 'AAA', 'CCC')
   insert into example2 values (@lvar, 'AAA', 'CCC')
   select @lvar = @lvar + 1
   end
   go
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
   create unique clustered index ex2ind1 on example2 (column1, column2)
   with fill factor = 90, PAD_INDEX
   go
				

Exemplo 1: Tabela inserções na ordem oposta

Neste exemplo, duas tabelas foram inseridas na ordem oposta e ocorreu um deadlock. Os deadlocks também podem ocorrer quando dois ou mais conexões executam atualizações ou exclusões em tabelas em ordem inversa.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
				

Neste ponto, Connection1 pode bloquear Connection2 porque a linha que Connection2 é inserir pode estar na mesma página onde Connection1 já tiver inserido uma linha e é mantendo um bloqueio.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

Neste ponto, Connection2 pode bloquear Connection1, porque a linha que Connection1 é inserir pode estar na mesma página onde Connection2 já tiver inserido uma linha e está mantendo um bloqueio. Isso faz com que um deadlock.

A saída para o sinalizador de rastreamento 1204 quando ocorreu o deadlock é:
97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES (100,
     'AAAA', 'CCC')
   spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (200,
   'AAAB', 'CCC')
   VICTIM: spid 13, pstat 0x0000 , cputime 30
				

Cada linha do rastreamento deadlock pode informar os usuários mais sobre um deadlock. Connection1 é spid 13 e Connection2 é spid 14 (você pode determinar o spid associado a uma conexão usando o procedimento armazenado do sistema de sp_who).
   >> 97/04/20 11:51:57.88 spid13   *** DEADLOCK DETECTED with spid 14 ***
   The deadlock was detected between spid 13 and spid 14.
   >> spid 13 requesting EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 14, dbid 6, page 0x188, table example2, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example2 VALUES
   (100, 'AAAA', 'CCC')
				

13 Spid foi solicitando EX_PAGE bloqueio e foi bloqueado por spid 14, que já tem bloqueio EX_PAGE para página 0x188 na tabela exemplo2 no dbid 6. O bloqueio é mantido na página pertencentes ao índice de cluster.
      Indid Value         Description
-------------------------------------
         0                Data page if there is no clustered index, or the
                          leaf page of a clustered index if there is one
         1                Non-leaf page of the clustered index page
       255                Text/image page
    Any other value       Non-clustered secondary index
				

O atual comando executado pelo spid 13 é um INSERT e o rastreamento retorna a parte do buffer de entrada.
   >> spid 14 waiting for EX_PAGE (waittype 0x8005), blocked by:
   >>   EX_PAGE: spid 13, dbid 6, page 0x180, table example1, indid 0x1
   >>   pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES
   (200, 'AAAB', 'CCC')
				

14 Spid está aguardando EX_PAGE bloqueio e está sendo bloqueado pela spid 13, que já contém EX_PAGE bloqueio na mesma página.
   >> VICTIM: spid 13, pstat 0x0000 , cputime 30
   SQL Server has chosen spid 13 as the deadlock victim.
				

A seguir está uma explicação do que significam os vários bloqueios no rastreamento:

SH_INT e EX_INT
Intenção de bloqueios que são executados em um item de nível mais alto (por exemplo, uma tabela) antes de bloqueios de nível inferior (por exemplo, uma página) podem ser executados porque o Gerenciador de bloqueio é desconhece a relação entre tipos diferentes de itens (neste caso, páginas e tabelas). Se um bloqueio EX_INT não foi obtido na tabela antes de utilizar bloqueios EX_PAG nas páginas, outro usuário poderia levar um bloqueio EX_TAB na mesma tabela e o Gerenciador de bloqueio não saberia que existe um conflito. Atualmente, SQL Server tem intenção bloqueios somente em tabelas. Há dois tipos de bloqueios intenção: (SH_INT) compartilhado e exclusivo (EX_INT) bloqueia.

EX_PAGE
Este é um bloqueio de página exclusivo que é executado quando uma página é atualizada devido a um DELETE, UPDATE, ou inserir a instrução INSERT com nível de linha bloqueio (IRL) desativado.

UP_PAGE
Isso é um bloqueio de página de atualização que é executado no lugar de um bloqueio de página compartilhada quando uma página é examinada e o otimizador sabe que a página será atualizada (ou a dica UPDLOCK é usada).

PR_EXT, NX_EXT, UPD_EXT e EX_EXT
Esses bloqueios são colocados quando alocar ou desalocando o espaço em disco. UPD_EXT é executada quando alocar ou desalocando uma página de uma extensão existente e os outros são usados ao alocar ou desalocando extensões inteiras.

IX_PAGE e LN_PAGE
Esses são IRL bloqueios. IX_PAGE é um bloqueio intenção-para--linha-bloqueio em uma página. LN_PAGE é obtido quando uma página na qual IRL está sendo feito precisa ser dividida.

RLOCK e XRLOCK
Esses bloqueios de curto prazo são colocados quando percorrer uma árvore b de índice. Há dois tipos desse tipo de bloqueio: (RLOCK) compartilhado e exclusivo (XRLOCK). Bloqueios compartilhados são feitos durante a verificação, enquanto bloqueios exclusivos são executados em páginas de índice durante uma atualização.

EX_TAB
Este é um bloqueio de tabela exclusivo que ocorre quando o otimizador do SQL Server determina que uma verificação de tabela é a maneira mais eficiente para resolver uma consulta atualização (por exemplo, quando houver índices em uma tabela). Bloqueios EX_TAB também aparecem quando você bloquear a tabela com dica TABLOCKX ou ao SQL Server escala os bloqueios de página em uma tabela para um bloqueio de tabela.

SH_TAB
Este é um compartilhada bloqueio de tabela que é usado quando o otimizador pressupõe que a maior parte da tabela será verificado (ou escala de bloqueio de página) ou a dica TABLOCK é usada.

O exemplo de bloqueio anterior pode ser evitado se as duas conexões atualizam tabelas na seqüência a seguir:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (200, 'AAAB', 'CCC')
   Connection2 > INSERT INTO example2 VALUES (200, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

Exemplo 2: Inserções para partes diferentes da mesma tabela

Esse bloqueio também pode ocorrer quando inserir duas conexões em partes diferentes da mesma tabela na ordem oposta quando linhas compartilham páginas. Por exemplo:
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > INSERT INTO example1 VALUES (400, 'AAAA', 'CCC')
				

Nesta tabela de exemplo, há um índice de cluster na primeira coluna da tabela exemplo1. Linhas com os mesmos valores para a primeira coluna serão tendem a se enquadram na mesma página. No exemplo, a segunda linha inserida pelo Connection1 provavelmente ficará na mesma página como a primeira linha inserida pelo Connection2, pois possuem um valor de índice de cluster de 400. Isso faz com que Connection2 ao bloco Connection1.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

Agora Connection2 também pode estar bloqueado por Connection1, levando a um deadlock. Este é o rastreamento de deadlock:
   97/04/20 12:56:01.40 spid16   *** DEADLOCK DETECTED with spid 15 ***
   spid 16 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 15, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (100,
   'AAAB', 'CCC')
   spid 15 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 16, dbid 6, page 0x8bd, table example1, indid 0
     pcurcmd INSERT(0xc3), input buffer: INSERT INTO example1 VALUES (400,
   'AAAA', 'CCC')
   VICTIM: spid 16, pstat 0x0000 , cputime 130
				

Solicitação de bloqueio EX_PAGE para página 0x2c5 spid 16 está bloqueada por spid 15, que já contém EX_PAGE bloqueio para página 0x2c5 após tinha a inserção primeira. E spid 15 também tem bloqueado por spid 16 no aguardando um bloqueio EX_PAGE para página 0x8db líderes para deadlock.

Esse bloqueio pode ser evitado usando o comando a seguir para habilitar IRL para tabela exemplo1:
   sp_tableoption 'example1', 'insert row lock', true
				

Exemplo 3: Inserções usando IRL

IRL permite que dois ou mais usuários compartilhar uma página quando eles só inserir operações, que geralmente resulta em melhor taxa de transferência. No entanto, habilitar IRL não sempre reduzirá deadlocks. Em alguns casos, IRL pode introduzir deadlocks.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

Com IRL habilitado, as duas conexões manterá um bloqueio IX_PAGE na página que contém duas novas linhas. Se IRL foi desabilitado, Connection1 deve ter adquirido um bloqueio EX_PAGE e Connection2 poderia ter sido bloqueado imediatamente.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

Neste ponto, Connection2 precisa um bloqueio de página exclusivo para fazer uma instrução UPDATE, que é incompatível com o IX_PAGE bloqueio do Connection1. Portanto, Connection2 aguardará.
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 100
   and column2 = 'AAAA'
				

Agora Connection1 pode estar bloqueado por Connection2, levando a um deadlock. Este é o rastreamento de deadlock:
   97/04/20 15:13:50.07 spid17   *** DEADLOCK DETECTED with spid 18 ***
   spid 17 requesting UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 18, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 100 and column2 = 'AAAA'
   spid 18 waiting for UP_PAGE (waittype 0x8007), blocked by:
     IX_PAGE: spid 17, dbid 6, page 0x2c5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   VICTIM: spid 17, pstat 0x0000 , cputime 20
				

17 Spid (conexão um) está aguardando um bloqueio UP_PAGE, que é a primeira etapa para obter um bloqueio de página exclusivo. Ele está sendo bloqueado por spid 18, que contém o bloqueio IX_PAGE na página 0x2c5. 18 Spid está aguardando UP_PAGE bloqueio na mesma página e está sendo bloqueado pela IX_PAGE bloqueio mantido por spid 17. Isso leva a um deadlock porque IX_PAGE bloqueio é compartilhável, enquanto UP_LOCK não é. Durante a insere primeiro, tanto o spids tem IX_PAGE bloqueio na mesma página e posterior tentaram atualizar o bloqueio para UP_PAGE bloqueio, que não é possível porque UP_PAGE bloqueio é exclusivo.

Uma maneira para evitar o deadlock é inserir o valor atualizado diretamente na tabela em vez de inserir e, em seguida, atualizar a linha na mesma transação. Se isso não for possível, usando o seguinte comando para desabilitar IRL ajudará a evitar o deadlock:
   sp_tableoption 'example1', 'insert row lock', false
				

Exemplo 4: Inserções para linhas na mesma página

Um deadlock também poderá resultar quando as linhas que as dois spids estiver trabalhando em diferem mas pertencem à mesma página.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 405
   and column2 = 'AAAA'
				

Neste ponto, Connection1 pode estar bloqueado por Connection2. Essa situação pode ocorrer porque Connection1 quer atualizar uma linha em uma página onde Connection2 já tiver inserido uma linha.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

Neste ponto, Connection2 também pode ser bloqueado por Connection1, que o levará a um deadlock. Essa situação pode ocorrer quando Connection2 quer atualizar uma linha em uma página onde Connection1 inseriu uma linha. Este é o rastreamento de deadlock:
   97/04/20 15:48:21.18 spid20   *** DEADLOCK DETECTED with spid 19 ***
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x2c4, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 105 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0xc48, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 405 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 60
				

Esse bloqueio pode ser evitado por difusão fora as linhas em páginas diferentes. Um método para fazer isso é recriar o índice de cluster nesta tabela com um fator de preenchimento grande. Uma instrução que cria um índice de cluster com um fator de preenchimento de 50 por cento é:
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

Esta instrução cria o índice em cluster deixando metade das páginas vazio, incluindo os níveis de não-folha de índice em cluster (devido à opção de PAD_INDEX). A tabela ocupará duas vezes o tamanho real, e o número de linhas por página é metade dos quais eles foram.

O fator de preenchimento não é mantido em uma tabela; a tabela é re-organized com o fator de preenchimento especificado somente durante tempo de criação do índice. Com o passar do tempo, as linhas por página deixará de ser o fator de preenchimento especificado durante a criação de índice. Quando isso ocorrer, talvez seja uma boa idéia de recriar o índice de cluster com o fator de preenchimento desejado.

Outra solução para evitar a situação de deadlock anterior é preencher a tabela com colunas fictícios (por exemplo, dummy1 char(255)). Isso aumenta o tamanho da linha e leva a menos linhas por página (o menor número como uma linha por página). Como esse tipo de preenchimento é mantido longo do tempo, você não precisa recriar o índice de cluster para manter o preenchimento (embora talvez você queira recriar o índice de cluster por outros motivos). A desvantagem dessa técnica é que o espaço de armazenamento é perdido em campos fictícios.

Exemplo 5: Linhas de preenchimento

Linhas de preenchimento leva ao menos linhas por página (, portanto, menos bloqueios), mas não irá eliminar completamente deadlocks.

Esta tabela de exemplo, exemplo1 é preenchido para ocupar uma linha por página. A seguir estão as instruções usadas para criar a tabela para este exemplo:
   create table example1 (column1 int, column2 char(20), column3 char(50),
   dummy_column4 char (255), dummy_column5 char (255), dummy_column6 char
   (255))
   go
   create unique index ex1ind5 on example1 (column3, column2, column1,
   dummy_column4, dummy_column5, dummy_column6) with fill factor = 85
   go
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (400, 'AAAB', 'CCC', ' ', ' ',
   ' ', ' ')
   Connection1 > UPDATE example1 SET column3 = 'CCCA' where column1 = 401
   and column2 = 'AAAA'
				

Neste ponto, Connection1 está bloqueado por Connection2 ao atualizar a linha. Porque o SQL Server deve manter ponteiros de cadeia de página, ele bloqueia a página anterior, a próxima página e a página que está sendo atualizada. Como Connection2 mantém um bloqueio na página anterior, Connection1 deve esperar até que Connection2 confirma a transação.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

Neste ponto, Connection2 está bloqueado por Connection1 porque ele deve bloquear a página anterior, que está bloqueada por Connection1. O resultado é um deadlock. Este é o rastreamento de deadlock:
   spid 20 requesting UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 19, dbid 6, page 0x12b5, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCB' where column1 = 101 and column2 = 'AAAB'
   spid 19 waiting for UP_PAGE (waittype 0x8007), blocked by:
     EX_PAGE: spid 20, dbid 6, page 0x1531, table example1, indid 0
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCA' where column1 = 401 and column2 = 'AAAA'
   VICTIM: spid 20, pstat 0x0000 , cputime 300
				

Esse bloqueio pode ser evitado inserindo fictícios linhas entre as linhas que são sendo inseridas, atualizados ou excluídos. Por exemplo, se Connection1 funciona (inserções, atualizações ou exclusões) com linha pk = 1 e Connection2 funciona com linha pk = 5, inserindo uma linha entre essas duas linhas (como uma linha que contenha pk = 3) irá evitar deadlocks. Esse método também aumenta o tamanho da tabela, mas pode ser a melhor solução para as tabelas de fila fundamentais para o aplicativo.

Exemplo 6: Índices que não estão em cluster

Em alguns casos, os índices secundários não-agrupado podem introduzir deadlocks. Neste exemplo, a manutenção do índice secundário apresenta deadlock.

A instrução usada para criar o índice secundário usado neste exemplo é:
   create index ex1ind2 on example1 (column3) with fill factor = 90,
   PAD_INDEX
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCBA', ' ', '
   ', ' ', ' ')
   Connection2 > INSERT INTO example1 VALUES (300, 'AAAB', 'CCCZ', ' ', '
   ', ' ', ' ')
   Connection2 > UPDATE example1 SET column3 = 'CCBA' where column1 = 105
				

Neste ponto, Connection2 pode estar bloqueado por Connection1 porque Connection1 pode ser mantendo um bloqueio na página de índice não-agrupado secundário onde Connection2 precisa atualizar.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

Neste ponto, Connection1 pode estar bloqueado por Connection2, resultando em um deadlock. Essa situação pode acontecer quando Connection1 está aguardando um bloqueio para atualizar o índice não agrupado secundário onde Connection2 já tiver inserido e mantém um bloqueio na página. Este é o rastreamento de bloqueio para esse exemplo deadlock:
   97/04/20 19:05:38.75 spid11   *** DEADLOCK DETECTED with spid 12 ***
   spid 11 requesting EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 12, dbid 6, page 0x112f, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCCZ' where column1 = 305
   spid 12 waiting for EX_PAGE (waittype 0x8005), blocked by:
     EX_PAGE: spid 11, dbid 6, page 0x1108, table example1, indid 0x2
     pcurcmd UPDATE(0xc5), input buffer: UPDATE example1 SET column3 =
   'CCBA' where column1 = 105
   VICTIM: spid 11, pstat 0x0000 , cputime 50
				

Esse bloqueio pode ser evitado por descartar o índice secundário. Não é possível preencher o índice para conter uma linha por página, portanto, essa situação pode ser evitada eliminando o índice secundário não-agrupado ou modificando o aplicativo.

Os deadlocks podem ocorrer com mais de duas conexões, caso em que o rastreamento de deadlock lista os spids envolvidos no deadlock e também os bloqueios conflitantes. Deadlocks podem ocorrer com bloqueios RLOCK e XRLOCK, que são adquiridos durante desviar o índice. Os deadlocks também podem ocorrer devido a bloqueios de extensão (PR_EXT NX_EXT, UPD_EXT & EX_EXT).

Para obter informações adicionais sobre como analisar deadlocks, você pode ativar os seguintes sinalizadores de rastreamento:

T1200
Imprime todas as informações de solicitação/liberar bloqueio quando ele ocorre, se um deadlock está envolvido ou não. Isso é caro em termos de desempenho, mas pode ser útil para análise.

T1206
Imprime todos os bloqueios mantidos por participantes spids no deadlock.

T1208
Imprime o nome de host e o nome do programa fornecido pelo cliente. Isso pode ajudar a identificar um cliente envolvido em um deadlock, supondo que o cliente especifica um valor exclusivo para cada conexão.

A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 6.5 Standard Edition
Palavras-chave: 
kbmt kbhowto kbusage KB169960 KbMtpt
Tradução automáticaTradução automática
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 traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.
Clique aqui para ver a versão em Inglês deste artigo: 169960  (http://support.microsoft.com/kb/169960/en-us/ )
Retired KB ArticleAviso de Isenção de Responsabilidade sobre Conteúdo do KB Aposentado
Este artigo trata de produtos para os quais a Microsoft não mais oferece suporte. Por esta razão, este artigo é oferecido "como está" e não será mais atualizado.
Partilhar
Opções de suporte adicionais
Fóruns de Suporte da Comunidade Microsoft
Contacte-nos directamente
Encontre um parceiro certificado Microsoft
Loja Microsoft