4/23/13

Artigos

Digitesuabusca...

Sobre o Autor...

(Mostra Detalhes)

Investigaoavanadadeproblemasdelocking11/Jul/2009
Os problemas de locking comum testemunhar em aplicaes de bancos de dados problemas com locking que no so diagnosticados de forma ideal e acabam se transformando em uma grande dor de cabea para os administradores da estrutura de rede, banco de dados e aplicao, que no raro se debatem com o problema por muito tempo antes de chegar a um diagnstico satisfatrio. Um problema grave com locking pode ser confundido com um servidor travado, problemas de rede ou produzir efeitos de demora de resposta na conexo que sejam semelhantes um servidor que esteja com demanda de CPU em 100%. A inteno deste artigo desvendar os possveis problemas de concorrncia que podem ocorrer em uma base de dados e desmistificar os tpicos relacionados com locks e deadlocks no Microsoft SQL Server.

Para que servem os locks. Os locks na verdade, no so um problema do banco de dados, mas sim um recurso imprescindvel para permitir que o banco de dados atenda varias conexes concorrentes de forma segura e ordenada. Em um banco de dados multiusurio, os locks previnem problemas de concorrncia, ordenando a execuo de comandos conflitantes com o travamento (lock) de recursos. Deste modo, podese dizer que os problemas com locks so desvios do comportamento ideal, freqentemente causados por falhas na modelagem da aplicao, cdigo equivocado ou mesmo falta de indexao adequada. Como saber se h problemas de locking. O primeiro recurso na investigao a procedure de sistema sp_who, que ir denunciar conexes travadas. O spid da conexo responsvel pelo travamento indicada na colula blk (bloqueado por) do resultado do sp_who:

Figura 1: resultado do comando sp_who

www.bfbiz.com.br/bh/artigo_details.aspx?ID=131

1/6

4/23/13 Figura 1: resultado do comando sp_who

Artigos

No exemplo mostrado, a conexo 53 est esperando sendo bloqueada pela conexo 52. Cabe esclarecer que um problema de locking s estaria realmente instalado se essa situao de travamento for excessivamente prolongada e repetitiva. Devemse fazer varias verificaes seguidas para verificar se o problema realmente tem esse perfil. O problema locking....e agora? Uma vez que a investigao inicial mostrou indcios de um problema de locking, ela pode ser aprofundada para permitir a identificao da causa, uma vez que o locking propriamente dito normalmente o sintoma e no a causa efetiva do problema. O prximo passo lgico seria investigar a natureza do lock gerado e o comando responsvel, usando sp_lock e dbcc inputbuffer. A procedure DBCC INPUTBUFFER retorna o ltimo comando executado por uma determinada conexo e pode ajudar na tarefa investigativa:
D B C C I N P U T B U F F E R ( 5 2 )

Figura 2: Resultado do comando DBCC INPUTBUFFER. O retorno acima demonstra o comando que gerou o lock ao qual a conexao 53 espera. Neste caso foi usado um como recurso para o exemplo um select com alguns hints de query incomuns, para forar a gerao de um lock exclusivo de tabela (tablockx holdlock) de forma que consigamos reproduzir de forma fcil um problema de locking. Outro auxilio na investigao o sp_lock, que nos mostra a natureza dos locks envolvidos. Na sada deste comando, podese destacar o lock exclusivo de tabela gerado pela conexo 52 e a contraparte (conexo 53) em status de espera. Os dois tm como alvo o ObjId (object id) 309576141 (o que poderia ser desvendado com SELECT OBJECT_NAME (309576141), descobrindose o nome da tabela envolvida).

Figura 3: Resultado do comando sp_lock Devese notar os campos Type, Mode e Status, que so extremamente importantes na investigao. A principal preocupao o status WAIT que reporta a espera da conexo, e o Type = TAB que demonstra um lock de uma tabela inteira de forma exclusiva (Mode = X). Os outros resultados contem locks compartilhados ou Shared (Mode = S) . Com o conhecimento dos comandos envolvidos (o que gerou o lock e o que espera pelo lock) e da natureza do lock, podese avanar mais um passo em direo elucidao do problema e possvel correo. As informaes mencionadas esto presentes tambm pela ferramenta Enterprise Manager do SQL e podem ser acessadas em current activity. Um pouco sobre a natureza dos locks: A diferena entre um lock compartilhado e um lock exclusivo: Locks exclusivos normalmente so gerados por operaes de modificao na base e no so compatveis com outros locks. J os locks compartilhados so compatveis com outros locks compartilhados. por esta razo que uma operao de update extensa faz a conexo de relatrios esperarem. De forma anloga, leituras recorrentes em determinada tabela podem protelar a execuo de um update na mesma tabela, com as configuraes default de conexo do servidor. Este comportamento a causa de muitos programadores usarem o lock hint NOLOCK aps o nome da tabela no comando select de relatrios. O comando a seguir, no esperaria pelo lock exclusivo demonstrado

www.bfbiz.com.br/bh/artigo_details.aspx?ID=131

2/6

4/23/13 Artigos no comando select de relatrios. O comando a seguir, no esperaria pelo lock exclusivo demonstrado anteriormente e no geraria um lock compartilhado para a leitura.
S E L E C T * F R O M P e r s o n . C o n t a c t W I T H ( n o l o c k )

Este recurso, embora til em vrios casos, deve ser utilizado com cautela e com o conhecimento de que ele ir possibilitar o que chamado de leitura suja (dirty read) pois possvel ler um dado que no foi ainda comitado na tabela o que pode ser inadmissvel em alguns processos. Tipos de locks suportados pelo SQL Server Natureza Operaes de leitura, sem modificao de dados. Gerado durante a fase inicial da operao de update Operaes de modificao, (INSERT, UPDATE, or DELETE). No compatvel com nenhum outro lock. So gerados automaticamente para definir uma hierarquia, impedindo locks nas instancias superiores. (um lock de intent para a tabela gerado automaticamente quando um lock de registro criado). No permite que a estrutura de uma tabela seja modificada durante um SELECT, por exemplo. Podem ser schema modification (SchM) e schema stability (SchS). Protege um intervalo de registros

Lock Shared (S) Update (U) Exclusive (X)

Intent Schema Keyrange

Tabela 1 Tipos de locks gerados pelo SQL Server Causas recorrentes de problemas de locks em servidores: Falta de indexao causando lock escalation A falta de indexao pode no apenas afetar a performance de leitura, mas tambm gerar um lock muito acima do necessrio. Na falta de um ndice, uma operao que normalmente leria (e geraria lock compartilhado em apenas um registro) pode gerar uma leitura massiva na tabela e um lock de tabela:
S E L E C T * F R O M P e r s o n . C o n t a c t W H E R E C o n t a c t I d = 2

Imaginando que a coluna ContactId no fosse indexada, a operao resultante de table scan iria gerar o lock compartilhado de tabela, impedindo comandos de update em toda extenso da tabela, pela durao do comando. Esse aumento na granularidade do lock normalmente referenciado por lock escalation.

Parmetros discrepantes Outro problema que pode levar o SQL a gerar um lock com granularidade maior que a normal so parmetros inconsistentes. Esse comportamento pode ser observado em vrias circunstncias no SQL 7.0 e SQL 2000 (o SQL 2005 / 2008 tem um otimizador de consultas mais avanado que no normalmente revela o mesmo problema). O exemplo a seguir ilustra o problema criando equivocadamente uma coluna com tipo decimal com o atributo identity e fazendo a procura de formas distintas no campo com dois tipos de parmetros:
P a s s o 1 : C r i a t a b e l a t e s t e C R E A T E T A B L E t b _ i n d x t e s t ( c 1 d e c i m a l ( 1 0 , 0 ) i d e n t i t y ( 1 , 1 ) , c 2 v a r c h a r ( 3 0 ) ) P a s s o 2 : I n s e r e r e g i s t r o s ( n e c e s s r i o c a n c e l a r o l o o p a p s a l g u n s s e g u n d o s ) S E T N O C O U N T O N W H I L E 1 = 1 I N S E R T t b _ i n d x t e s t D E F A U L T V A L U E S P a s s o 3 : C r i a u m n d i c e n o c a m p o c 1 C R E A T E N O N C L U S T E R E D I N D E X i x _ t x t O N t b _ i n d x t e s t ( c 1 )

Primeiro teste: utilizando como parmetro 3.00

T e s t a o a c e s s o c o m o v a l o r 3 . 0 0 S E T S T A T I S T I C S I O O N S E L E C Tc 2 F R O M t b _ i n d x t e s t W H E R E c 1 = 3 . 0 0

www.bfbiz.com.br/bh/artigo_details.aspx?ID=131

3/6

4/23/13

Artigos

Scan count 1, logical reads 16, physical reads 0, readahead reads 0.

Segundo teste: utilizando parmetro 3

T e s t a o a c e s s o : c o m o v a l o r 3 S E T S T A T I S T I C S I O O N S E L E C Tc 2 F R O M t b _ i n d x t e s t W H E R E c 1 = 3

Scan count 1, logical reads 3, physical reads 0, readahead reads 0. Comparando os dois resultados, concluise que mudando o parmetro da query entre 3 e 3.00 (o equivalente entre um decimal(10,0) e um decimal(10,2)), o otimizador de consultas do SQL Server reverte o plano de execuo para um table scan, o que pode ser comprovado pelo plano de execuo e a sada das estatsticas de acesso que apontam para 16 pginas lidas no table scan contra 3 pginas da consulta que utiliza indexao. Deste modo, devese ficar atento a problemas como este, que so de difcil deteco e podem levar o SQL a aumentar o lock na tabela para table lock de forma absolutamente desnecessria simplesmente porque o otimizador de consultas no conseguiu gerar um plano de execuo plenamente otimizado quando h converso de tipos de dados nestas circunstncias. Transaes no concludas corretamente. Muitas vezes tambm possvel que o cdigo da aplicao ou procedure tenha erros de lgica que impeam o trmino adequado da transao (falta do COMMIT TRAN). Exemplos comuns so loops infintos (erro de lgica na clausula de terminao do loop) ou clausulas IF/ELSE que no fecham a transao em determinados casos. Neste caso convm investigar os comandos que detm os locksproblema para determinar sua localizao no cdigo fonte da aplicao. Relatrios retirados diretamente nas tabelas de produo. Consultas pesadas nas tabelas utilizadas pela aplicao podem gerar locks compartilhados que iro concorrer com operaes de modificao na base e dar e impresso de um servidor irresponsivo. Devese pesar a possibilidade de usar lock hints como o nolock ou definir o isolamento transacional no inicio do relatrio para READ UNCOMMITTED, caso seja admissvel a ocorrncia de dirty reads (possibilidade de leitura de dados que foram posteriormente apagados por um rollback de transao, pois no se aguarda a finalizao da mesma). Outra considerao seria a criao de um servidor espelho dedicado para os relatrios ou mesmo tabelas histricas na mesma base. Transaes muito grandes. Uma transao de atualizao de registros que envolva toda a massa de dados uma tabela, como por exemplo, o clculo e atualizao de comisses numa tabela de vendas podem gerar um lock de tabela por tempo exagerado em horrio de produo concorrendo com operaes de leitura. Quebrar transaes grandes em pedaos menores, executando 5% ou 10% do update por vez pode ser um exemplo de tentativa de evitar que o SQL aumente o lock para um lock de tabela. Esse procedimento poderia ser facilmente implantado em muitos casos controlandose pela chave primria da tabela ou outras tcnicas.

O que so DeadLocks? Alm dos problemas de lock citados ao longo do artigo, existe o deadlock, um tipo especial de situao de lock. No deadlock duas transaes entram em conflito, onde uma espera a outra avanar e viceversa, mas nenhuma pode prosseguir pois esto mutuamente bloqueadas. Este estado detectado pelo SQL e ao invs das conexes esperarem eternamente pela resoluo do conflito, o prprio SQL se encarrega de terminar uma das conexes envolvidas de modo que a restante possa prosseguir (por default terminada a conexo que tem a menor quantidade de trabalho empenhado). Essa uma situao no muito freqente nas aplicaes de banco de dados, porm extremamente grave quando de sua ocorrncia, uma vez que transaes so efetivamente terminadas forosamente, com gerao do erro correspondente. Os processos identificados como integrantes do deadlock devem ser reescritos, preferencialmente modificando

www.bfbiz.com.br/bh/artigo_details.aspx?ID=131

4/6

4/23/13

Artigos

Os processos identificados como integrantes do deadlock devem ser reescritos, preferencialmente modificando o acesso ao recursos para evitar o conflito cruzado de acesso recursos, alm dos casos citados no restante do artigo que podem favorecer o aparecimento de um deadlock por causa de um lock escalation, por exemplo. No SQL 2005 houve uma significante melhora na investigao de deadlocks, com a incluso do deadlock graph no profiler, identificando graficamente a ocorrncia, inclusive com os objetos envolvidos e tipo de lock. Msg 1205, Level 13, State 45, Line 1 Transaction (Process ID 51) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Figura Profiler 2005 /2008 e o Deadlock Graph

Concluso: O conhecimento dos problemas mais comuns relacionados locks pode levar ao desenvolvedor de aplicaes a chance de criar aplicaes estveis e com alta performance, mesmo nos cenrios mais agressivos em relao concorrncia de conexes. Este objetivo est de acordo com a inteno de ajudar o leitor a cada vez mais se destacar pela proficincia de seus sistemas e atuao em seu campo. Foram explanadas as principais ferramentas de investigao, de forma que o leitor certamente conseguir identificar no apenas os casos citados, mas quaisquer outros que eventualmente surjam em seu banco de dados. indicado ao final, um link para o artigo clssico da TechNet sobre a resoluo dos problemas de locking. O novo recurso do SQL 2005 /2008 em relao concorrncia, o snapshot isolation, ser alvo de um artigo especialmente para o assunto, em prxima oportunidade e certamente ser um aliado futuro na melhoria da concorrncia de conexes. Para se aprofundar: Books on line: Transaction Isolation Levels Locking Hints INF: Understanding and Resolving SQL Server Blocking Problems http://support.microsoft.com/kb/224453/enus Escreva seu comentrio sobre este artigo e nos envie sua opinio.

www.bfbiz.com.br/bh/artigo_details.aspx?ID=131

5/6

4/23/13

Artigos

Nome Email

Enviar

Comentriossobreoartigo Muito bom o artigo, explica basicamente como observar os locks e me ajudou a identificar os principais problemas da aplicao de um cliente que eu estava trabalhando. Parabns. Quem enviou : Samuel Vaz Postado em : 25/08/2009 Parabns pelo excelente artigo. Quem enviou : Cid Macedo Postado em : 19/09/2009

www.bfbiz.com.br/bh/artigo_details.aspx?ID=131

6/6