INF: Analisar e evitar bloqueios no SQL Server

Traduções de Artigos Traduções de Artigos
Artigo: 169960 - Ver produtos para os quais este artigo se aplica.
Expandir tudo | Reduzir tudo

Nesta página

Sumário

Microsoft SQL Server mantém a consistência transaccional de integridade e a base de dados através da utilização de bloqueios. SQL Server versão 6.5 opcionalmente utiliza o nível de linha bloqueio para operações de inserção e utiliza o nível de página bloqueio para outras operações. Como com qualquer sistema base de dados relacional, bloqueio pode conduzir a bloqueios entre utilizadores.

Por exemplo, suponha que o Utilizador1 (ou Connection1) tem um bloqueio dados produto "A" e pretende um bloqueio no item de dados "B." User2 tem um bloqueio num item de dados "B" e agora pretende um bloqueio no item de dados "a". Neste cenário de SQL Server, o Utilizador1 ou User2 será uma vítima de impasse e será concedido ao utilizador o bloqueio pedido.

No SQL Server, o programador da aplicação pode decidir qual a ligação irá ser o candidato para vítima de impasse utilizando SET DEADLOCK_PRIORITY. Se o programador não designa uma prioridade de bloqueios, SQL Server selecciona a vítima de impasse, seleccionando o processo que conclui a cadeia circular de bloqueios.

Aplicação de base de dados de sistemas poderão ter um comportamento diferente quando transportados de uma base de dados relacional para outro, baseado na implementação do sistema de base de dados relacional. Uma das áreas para procurar alterações comportamentais bloquear. Este artigo explica como analisar bloqueios no SQL Server e as técnicas que pode utilizar para evitar esses.

Mais Informação

Este artigo realça utilizando o resultado do sinalizador de rastreamento T1204 para analisar bloqueios. Quando o sinalizador de rastreio T1204 estiver definido, SQL Server imprime informações sobre o bloqueio quando ela ocorrer. Para utilizar este sinalizador de rastreio, utilize o seguinte comando numa linha de comandos para iniciar o SQL Server:
   sqlservr -c -T1204
				

Os resultados de rastreio são enviados para a janela da consola, a menos que defina sinalizador de rastreamento T3605, que envia o resultado do rastreio para o registo de erros.

Bloqueios podem ocorrer quando duas ligações actualizarem tabelas de ordem oposta. Por exemplo, uma ligação insere na tabela "exemplo1" primeiro e, em seguida, em "exemplo2", enquanto outra ligação insere na tabela "exemplo2" primeiro e, em seguida, em "exemplo1" dentro de uma transacção. Um cenário de exemplo é útil para ilustrar como evitar bloqueios.

Seguem-se as instruções de SQL utilizadas para criar a tabela utilizada 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 oposto

Neste exemplo, duas tabelas foram inseridas numa ordem oposta e Ocorreu um impasse. Bloqueios também podem ocorrer quando dois ou mais ligações executar actualizações ou eliminações em tabelas numa ordem oposta.
   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 é inserir Connection2 pode estar na mesma página onde Connection1 já tiver inserido uma linha e é manter um bloqueio.
   Connection1 > INSERT INTO example2 VALUES (100, 'AAAA', 'CCC')
				

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

Segue-se a saída de sinalizador de rastreamento 1204 quando ocorreu o bloqueio:
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 de rastreio impasse pode dizer aos utilizadores mais informações sobre um impasse. Connection1 é spid 13, sendo Connection2 spid 14 (é possível determinar o spid associado a uma ligação utilizando 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 pelas spid 14, que já tenha EX_PAGE bloqueio para página 0x188 tabela exemplo2 no dbid 6. O bloqueio é mantido na página que pertencem ao índice agrupado.
      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 comando actual executado por spid 13 é um INSERT e o rastreio fornece parte da memória intermédia 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')
				

Spid 14 está a aguardar bloqueio EX_PAGE e está a ser bloqueada pelo 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.
				

Segue-se uma explicação sobre o que significam os bloqueios vários no rastreio:

SH_INT e EX_INT
Tipo bloqueios que são executados num item de nível superior (por exemplo, uma tabela) antes de bloqueios de nível inferior (por exemplo, uma página) podem ser obtidos, uma vez que o Gestor de bloqueio é ignora a relação entre diferentes tipos de itens (neste caso, páginas e tabelas). Se um bloqueio EX_INT não foi efectuado na tabela antes de efectuar bloqueios EX_PAG nas páginas, outro utilizador pode demorar um bloqueio EX_TAB na mesma tabela e o Gestor de bloqueio não saberá que existia um conflito. Actualmente, SQL Server tem bloqueios tipo apenas nas tabelas. Existem dois tipos de bloqueios tipo: bloqueia partilhada (SH_INT) e exclusivo (EX_INT).

EX_PAGE
Este é um bloqueio de página exclusivo é tomado quando uma página é actualizada devido a um UPDATE, DELETE ou instrução INSERT com Inserir nível da linha bloqueio (IRL) desactivado.

UP_PAGE
Este é um bloqueio de página de actualização é efectuado em vez de um bloqueio de página partilhada quando uma página é verificada e o optimizador sabe que a página será actualizada (ou sugestão UPDLOCK serve).

PR_EXT, NX_EXT, UPD_EXT e EX_EXT
Estes bloqueios são retirados quando atribuir ou anular o espaço em disco. UPD_EXT é tomada quando atribuir ou anular uma página a partir de uma extensão existente e as outras são utilizadas quando atribuir ou anular extensões toda.

IX_PAGE e LN_PAGE
Estes são IRL bloqueios. IX_PAGE é um bloqueio intenção-para--linha-bloqueio numa página. LN_PAGE é tomada quando uma página na qual IRL está a ser efectuada tem de ser dividida.

RLOCK e XRLOCK
Estes bloqueios de curto prazo são retirados quando atravessar uma árvore de b de índice. Existem dois tipos deste tipo de bloqueio: partilhada (RLOCK) e exclusivo (XRLOCK). Bloqueios partilhados são retirados durante a digitalização, enquanto bloqueios exclusivos são retirados nas páginas do índice durante uma actualização.

EX_TAB
Este é um bloqueio de tabela exclusivo que ocorre quando o optimizador do SQL Server determina que uma pesquisa da tabela é a forma mais eficaz de resolver uma consulta de actualização (por exemplo, quando existem não índices numa tabela). Bloqueios EX_TAB também aparecem quando bloquear a tabela com TABLOCKX sugestão ou quando o SQL Server escalates os bloqueios de página numa tabela para um bloqueio de tabela.

SH_TAB
Este é um partilhada bloqueio de tabela é utilizado quando o optimizador assume que a maior parte da tabela será verificado (ou bloqueio de página escalates) ou a sugestão TABLOCK é utilizada.

O exemplo de impasse anterior pode ser evitado se duas ligações de actualizarem as tabelas na seguinte sequência:
   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

Este bloqueio também pode ocorrer quando duas ligações inserindo diferentes partes da mesma tabela ordem oposta quando linhas partilham 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')
				

Esta tabela de exemplo, existe um índice agrupado na primeira coluna da tabela exemplo1. Linhas com os mesmos valores para a primeira coluna irão tendem a estar na mesma página. No exemplo, a segunda linha inserida, Connection1 provavelmente sai na mesma página como a primeira linha inserida pelo Connection2, uma vez que ambas têm um valor de índice clusterizado de 400. Isto faz com que Connection2 bloco Connection1.
   Connection2 > INSERT INTO example1 VALUES (100, 'AAAB', 'CCC')
				

Agora Connection2 também poderá estar bloqueado por Connection1, conduzindo a um impasse. Segue-se o rastreio de impasse:
   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
				

O pedido de spid 16 de bloqueio EX_PAGE para página 0x2c5 está bloqueado por spid 15, que já contém EX_PAGE bloqueio de página 0x2c5 depois que tinha da primeira inserção. E spid 15 também tem bloqueada pelo spid 16 no aguardar um bloqueio EX_PAGE para página 0x8db líder para impasse.

Este bloqueio pode ser evitado utilizando o seguinte comando para activar IRL exemplo1 tabela:
   sp_tableoption 'example1', 'insert row lock', true
				

Exemplo 3: Inserções utilizar IRL

IRL permite dois ou mais utilizadores partilhar uma página quando que só inserir operações, que resulta frequentemente em débito melhor. No entanto, activar IRL não sempre reduzirá bloqueios. Em alguns casos, IRL pode trazer bloqueios.
   Connection1 > BEGIN TRANSACTION
   Connection2 > BEGIN TRANSACTION
   Connection1 > INSERT INTO example1 VALUES (100, 'AAAA', 'CCC')
   Connection2 > INSERT INTO example1 VALUES (105, 'AAAB', 'CCC')
				

Com IRL activado, ambas as ligações vão conter um bloqueio IX_PAGE na página que contém duas novas linhas. Se IRL foi desactivado, Connection1 iria ter adquirido um bloqueio EX_PAGE e Connection2 seria foram bloqueadas imediatamente.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 105
   and column2 = 'AAAB'
				

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

Agora Connection1 pode estar bloqueado por Connection2, conduzindo a um impasse. Segue-se o rastreio de impasse:
   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 De spid (ligação um) está a aguardar um bloqueio UP_PAGE, que é o primeiro passo para obter um bloqueio de página exclusivo. Está a ser bloqueado pela spid 18, que contém IX_PAGE bloqueio na página 0x2c5. 18 De spid está a aguardar bloqueio UP_PAGE na mesma página e está a ser bloqueado por IX_PAGE bloqueio retido pela spid 17. Isto conduz a um impasse porque IX_PAGE bloqueio é partilhável, enquanto que UP_LOCK não é. Durante a primeira insere, tanto os spids tem IX_PAGE bloqueio na mesma página e mais tarde tentaram actualizar o bloqueio para bloqueio UP_PAGE, que não é possível porque UP_PAGE bloqueio é exclusivo.

Uma forma de evitar o bloqueio é inserir o valor actualizado directamente na tabela em vez de inserir e, em seguida, actualizar a linha na mesma transacção. Se não for possível, utilizando o seguinte comando para desactivar IRL ajudá-lo para evitar impasse-ão:
   sp_tableoption 'example1', 'insert row lock', false
				

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

Um bloqueio também pode resultar quando as linhas dois que SPIDs está a trabalhar são diferentes 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. Esta situação pode ocorrer porque Connection1 pretende actualizar uma linha de 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 poderá estar bloqueado por Connection1 resultará um impasse. Esta situação pode ocorrer quando Connection2 quiser actualizar uma linha de uma página onde Connection1 tiver inserido uma linha. Segue-se o rastreio de impasse:
   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
				

Este bloqueio pode ser evitado através da distribuição a linhas através de páginas diferentes. O um método para o fazer consiste em recriar o índice clusterizado nesta tabela com um factor de preenchimento grande. Segue-se uma declaração que cria um índice agrupado com um factor de preenchimento de 50 por cento:
   create unique clustered index ex1ind1 on example1 (column1, column2)
   with fill factor = 50, PAD_INDEX
				

Esta declaração cria o índice clusterizado deixando metade das páginas vazio, incluindo os níveis não folha do índice clusterizado (devido a opção PAD_INDEX). Ocupada pela tabela dobro o tamanho real e o número de linhas por página é metade do que se encontravam.

O factor de preenchimento não é mantido numa tabela; a tabela é re-organized com o factor de preenchimento especificado apenas durante o tempo de criação do índice. Ao longo do tempo, as linhas por página deixará o factor de preenchimento especificado durante a criação de índices. Quando esta situação ocorre, poderá ser conveniente recriar o índice clusterizado com o factor de preenchimento pretendido.

Outra solução para evitar a situação de impasse anterior é para preencher a tabela com colunas fictícias (por exemplo, dummy1 char(255)). Isto aumenta o tamanho da linha e clientes em potencial para menos linhas por página (mínimo de uma linha por página). Uma vez que este tipo de preenchimento é mantido ao longo do tempo, não é necessário recriar o índice agrupado para manter o preenchimento (que poderá recriar o índice agrupado por outras razões). A desvantagem desta técnica é que o espaço de armazenamento será desperdiçado campos fictício.

Exemplo 5: Área linhas

Linhas de área clientes em potencial menos linhas por página (, por isso, menos bloqueios), mas não irá eliminar completamente bloqueios.

Nesta tabela de exemplo, é acrescentado exemplo1 ocupar uma linha por página. Seguem-se as instruções utilizadas 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á bloqueada por Connection2 ao actualizar a linha. Uma vez que SQL Server tem de manter ponteiros de cadeia de página, bloqueia a página anterior, a página seguinte e a página que está a ser actualizada. Porque Connection2 contém um bloqueio na página anterior, Connection1 tem de aguardar até Connection2 consolida a transacção.
   Connection2 > UPDATE example1 SET column3 = 'CCCB' where column1 = 101
   and column2 = 'AAAB'
				

Neste ponto, Connection2 está bloqueada por Connection1 porque tem de bloquear a página anterior, que está actualmente bloqueada por Connection1. O resultado é um impasse. Segue-se o rastreio de impasse:
   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
				

Este bloqueio pode ser evitado através da inserção fictícias linhas entre as linhas que estão a ser inseridas, actualizado ou eliminado. Por exemplo, se Connection1 trabalha (inserções, actualizações ou eliminações) pk linha = 1 e Connection2 funciona com linha pk = 5, inserindo uma linha entre estas duas linhas (tal como uma linha que contém pk = 3) irá evitar bloqueios. Este método também aumenta o tamanho da tabela, mas poderá ser a melhor solução para as tabelas de fila críticas para a aplicação.

Exemplo 6: Índices agrupados

Em alguns casos, não agrupado índices secundários podem trazer bloqueios. Neste exemplo, a manutenção do índice secundário introduz um impasse.

Segue-se a instrução utilizada para criar o índice secundário utilizado 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 poderá ser manter um bloqueio na página de índice não agrupado secundário onde Connection2 necessita de actualizar.
   Connection1 > UPDATE example1 SET column3 = 'CCCZ' where column1 = 305
				

Neste ponto, Connection1 pode estar bloqueado por Connection2, resultando num impasse. Esta situação pode acontecer quando Connection1 está a aguardar um bloqueio actualizar o sem clusters secundário índice onde Connection2 já tiver inserido e contém um bloqueio nessa página. Segue-se o rastreio de impasse para este exemplo impasse:
   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
				

Este bloqueio pode ser evitado largando o índice secundário. Não é possível completar o índice para conter uma linha por página, pelo que esta situação pode ser evitada eliminando o índice secundário não agrupado ou modificando a aplicação.

Bloqueios poderão ocorrer com mais do que duas ligações, caso em que o rastreio de impasse lista spids envolvidos no bloqueio e também os bloqueios em conflito. Bloqueios poderão ocorrer com RLOCK e XRLOCK bloqueios que adquiriu durante índice atravessar. Bloqueios também poderão ocorrer devido a extensão bloqueios (PR_EXT NX_EXT, UPD_EXT & EX_EXT).

Para obter informações adicionais sobre como analisar impasses, é possível activar os seguintes sinalizadores de rastreio:

T1200
Imprime todas as informações de pedido/Libertar bloqueio quando ela ocorre, se está envolvido um impasse ou não. Isto é dispendioso em termos de desempenho, mas pode ser útil para análise.

T1206
Imprime todos os bloqueios retidos por spids participantes de impasse.

T1208
Imprime o nome do anfitrião e o nome do programa fornecido pelo cliente. Este pode ajudar a identificar um cliente envolvido num impasse, assumindo que o cliente Especifica um valor exclusivo para cada ligação.

Propriedades

Artigo: 169960 - Última revisão: 16 de outubro de 2003 - Revisão: 3.0
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á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 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: 169960
Exclusão de Responsabilidade para Conteúdo sem Suporte na KB
Este artigo foi escrito sobre produtos para os quais a Microsoft já não fornece suporte. Por conseguinte, este artigo é oferecido "tal como está" e deixará de ser actualizado.

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com