Trabalhando com Concorrência ou Simultaneidade de Dados – Parte I

Pessoal, boa tarde.

Tudo bem? Conforme eu destaquei a alguns dias, estava preparando um material novo sobre Concorrência ou Simultaneidade de Dados no SQL Server.

Pois bem, como promessa é dívida, esta aqui, mais uma artigo, dividido em algumas sessões. Na sessão de hoje, vou fazer uma breve introdução a “Concorrência ou Simultaneidade de Dados”, os principais elementos relacionados, dentre eles o tão assustador Deadlock, mais conhecido como ABRAÇO DA MORTE.

________________________________________________________________________________

INTRODUÇÃO

Quando muitas pessoas tentam modificar dados em um banco de dados ao mesmo tempo, um sistema de controles deve ser implementado de forma que as modificações feitas por uma pessoa não afetem adversamente as de outra pessoa. Isso é chamado
controle de simultaneidade.

A teoria do controle de simultaneidade tem duas classificações para os métodos de instituição do controle de simultaneidade:

–Controle de simultaneidade pessimista; e

–Controle de simultaneidade otimista.

Controle de simultaneidade pessimista: Um sistema de bloqueios impede que os usuários modifiquem os dados de uma forma
que afete outros usuários. Depois que um usuário executa uma ação que aplica um bloqueio, outros usuários não podem executar ações que estariam em conflito com o bloqueio até o proprietário liberar o bloqueio.

Isso é chamado de controle pessimista porque é principalmente usado em ambientes em que existe contenção elevada dos dados, e que o custo da proteção dos dados com bloqueios é inferior ao custo de reversão de transações, caso ocorram conflitos de simultaneidade.

Controle de simultaneidade otimista: No controle de simultaneidade otimista, os usuários não bloqueiam os dados quando os lêem. Quando um usuário atualiza os dados, o sistema verifica se outro usuário alterou os dados depois de lidos. Se outro usuário tiver atualizado os dados, um erro é ativado. Normalmente, o usuário que recebe o erro reverte a
transação e inicia novamente.

Isso é chamado de controle otimista porque é usado principalmente em ambientes em que existe contenção reduzida dos dados, e que o custo de reversão ocasional de uma transação é inferior ao custo de bloqueio dos dados quando os mesmos são lidos.

O Microsoft SQL Server oferece suporte a um intervalo de controle de simultaneidade. Os usuários especificam o tipo de controle de simultaneidade selecionando níveis de isolamento da transação para conexões ou opções de simultaneidade em cursores.

Esses atributos podem ser definidos usando instruções Transact-SQL, ou pelas propriedades e atributos de APIs (interfaces de programação de aplicativo) de banco de dados, como ADO, ADO.NET, OLE DB e ODBC.

CONHECENDO E ENTENDENDO DEADLOCKS (ABRAÇO DA MORTE)

Um deadlock acontece quando duas ou mais tarefas bloqueiam uma à outra permanentemente, sendo que cada uma tem o bloqueio de um recurso, que a outra tarefa está tentando bloquear.

Por exemplo: 

– A transação A adquire um bloqueio compartilhado da linha 1.

– A transação B adquire um bloqueio compartilhado da linha 2.

– A transação A agora solicita um bloqueio exclusivo na linha 2 e é bloqueado até que a transação B termine e libere o bloqueio compartilhado que tem na linha 2.

– A transação B agora solicita um bloqueio exclusivo na linha 1 e é bloqueado até que a transação A termine e libere o bloqueio compartilhado que tem na linha 1.

– A transação A não pode terminar até que a transação B termine, mas a transação B está bloqueada pela transação A.

Essa condição é também chamada de dependência cíclica: a transação A tem uma dependência da transação B, e a transação B fecha o círculo tendo uma dependência da transação A.

Ambas as transações em um deadlock esperarão indefinidamente, a menos que o deadlock seja quebrado por um processo externo. O monitor de deadlock do Microsoft Mecanismo de banco de dados do SQL Server verifica periodicamente as tarefas que estão em um deadlock.

Se o monitor detectar uma dependência cíclica, ele escolhe uma das tarefas como vítima e termina sua transação com um erro. Isso permite que a outra tarefa complete sua transação. O aplicativo com a transação que terminou com um erro pode repetir a transação, a qual normalmente é concluída depois que a outra transação em deadlock é encerrada.

Usando certas convenções de codificação em aplicativos reduz a chance de que os aplicativos causarão deadlocks. O deadlock é freqüentemente confundido com bloqueio normal. Quando uma transação solicita um bloqueio em um recurso bloqueado por outra transação, a transação solicitante espera até que o bloqueio seja liberado.

Por padrão, as transações SQL Server não têm tempo limite, a menos que LOCK_TIMEOUT seja configurado. A transação solicitante é bloqueada, não em deadlock, por que ela não fez nada para bloquear a transação que deve o bloqueio. Finalmente, a transação proprietária vai terminar e liberar o bloqueio e a transação solicitante terá o bloqueio atribuído e processado.

Deadlock é uma condição que pode ocorrer em qualquer sistema com vários threads, não só em sistemas de gerenciamento de banco de dados relacional, e pode ocorrer para outros recursos, além de bloqueios de objetos em bancos de dados.

Por exemplo: Uma thread em um sistema operacional de vários threads pode adquirir um ou mais recursos, como bloqueios de memória. Se o recurso sendo adquirido é atualmente propriedade de outro thread, o primeiro thread pode ter que esperar o thread proprietário liberar o recurso alvo.

A thread em espera tem uma dependência do thread proprietário para aquele recurso em particular. Em uma instância do  Mecanismo de Banco de Dados, sessões podem fazer um deadlock ao adquirir recursos que não são de banco de dados, como
memória ou threads.

A seguir a Figura 1 ilustra a relação e dependência de transações para um determinado objeto, neste caso uma tabela:

Figura 1 – Ocorrência de um deadlock devido a dependência de um objeto.

Na Figura 1, apresentada acima a transação T1 tem uma dependência da transação T2 para o recurso de bloqueio de tabela Part. Da mesma forma, a transação T2 tem uma dependência da transação T1 para o recurso de bloqueio de tabela Supplier. Devido a essas dependências formarem um ciclo, há um deadlock entre as transações T1 e T2.

Os deadlocks também podem ocorrer quando uma tabela é particionada e a configuração LOCK_ESCALATION do ALTER TABLE é configurada para AUTO. Quando a LOCK_ESCALATION é configurada para AUTO, a simultaneidade aumenta ao permitir que o Mecanismo de Banco de Dados bloqueie partições de tabela no nível de HoBT em vez de no nível de TABLE. Entretanto, quando transações separadas mantêm bloqueios de partição em uma tabela e querem um bloqueio em algum lugar de outra partição de transações, isso causa um deadlock.

Esse tipo de deadlock pode ser evitado configurando LOCK_ESCALATION para TABLE; embora essa configuração irá reduzir a simultaneidade forçando as atualizações extensas em uma partição a esperarem por um bloqueio de tabela.

MANIPULANDO DEADLOCKS

Quando uma instância do Microsoft Mecanismo de banco de dados do SQL Server escolhe uma transação como uma vítima de deadlock, ele encerra o lote atual, reverte a transação e retorna a mensagem de erro 1205 ao aplicativo.

“Your transaction (process ID #52) was deadlocked on {lock | communication buffer | thread} resources with another process and has been chosen as the deadlock victim. Rerun your transaction.”

Como qualquer aplicativo que envia consultas Transact-SQL pode ser escolhido como vítima de deadlock, os aplicativos deverão ter um manipulador de erros que possa interceptar a mensagem de erro 1205. Se um aplicativo não interceptar o erro, o aplicativo poderá prosseguir sem saber que sua transação foi revertida e que erros podem ocorrer.

A implementação de um manipulador de erros que intercepte a mensagem de erro 1205 permite que um aplicativo manipule a situação de deadlock e tome uma ação paliativa (por exemplo, enviar automaticamente de novo a consulta que estava envolvida no deadlock). Ao enviar a consulta novamente de forma automática, o usuário não precisa saber que ocorreu um deadlock.

O aplicativo deveria pausar brevemente antes de enviar novamente a consulta. Isso dá a outra transação envolvida no deadlock uma chance para completar e liberar seus bloqueios que formaram parte do ciclo de deadlock. Isso minimiza a probabilidade do deadlock ocorrer novamente quando a consulta reenviada solicitar seus bloqueios.

_____________________________________________________________________________________

Bom pessoal, vou encerrar esta primeira parte aqui, nos próximos dias retorno com a Parte II deste novo artigo, onde vamos entender um pouco mais sobre Deadlocks e apresentar os chamados Níveis de Isolamento.

Nos encontramos em breve, agradeço mais uma vez sua visita.

Até mais.

Anúncios

Sobre Junior Galvão - MVP

Profissional com vasta experiência na área de Tecnologia da Informação e soluções Microsoft. Graduado no Curso Superior em Gestão da Tecnologia de Sistemas de Informação. Pós-Graduado no Curso de Gestão e Engenharia de Processos para Desenvolvimento de Software com RUP na Faculdade FIAP - Faculdade de Informática e Administração Paulista de São Paulo. Pós-Graduado em Gestão da Tecnologia da Informação Faculdade - ESAMC Sorocaba. Formação MCDBA Microsoft, autor de artigos acadêmicos e profissionais postados em Revistas, Instituições de Ensino e WebSistes. Meu primeiro contato com tecnologia ocorreu em 1995 após meus pais comprarem nosso primeiro computador, ano em que as portas para este fantástico mundo se abriram. Neste mesmo ano, comecei o de Processamento de Dados, naquele momento a palavra TI não existia, na verdade a Tecnologia da Informação era conhecida como Computação ou Informática, foi assim que tudo começou e desde então não parei mais, continuando nesta longa estrada até hoje. Desde 2001 tenho atuado como Database Administrator - Administrador de Banco de Dados - SQL Server em tarefas de Administração, Gerenciamento, Migração de Servidores e Bancos de Dados, Estratégias de Backup/Restauração, Replicação, LogShipping, Implantação de ERPs que utilizam bancos SQL Server, Desenvolvimento de Funções, Stored Procedure, Triggers. Experiência na Coordenação de Projetos de Alta Disponibilidade de Dados, utilizando Database Mirroring, Replicação Transacional e Merge, Log Shipping. Atualmente trabalho como Administrador de Banco de Dados no FIT - Instituto de Tecnologia da Flextronics, como também, Consultor em Projetos de Tunnig e Performance para clientes, bem como, Professor Titular na Fatec São Roque. Desde 2008 exerço a função de Professor Universitário, para as disciplinas de Banco de Dados, Administração, Modelagem de Banco de Dados, Programação em Banco de Dados, Sistemas Operacionais, Análise e Projetos de Sistemas, entre outras. Possuo titulações e Reconhecimentos: Microsoft MVP, MCC, MSTC e MIE.
Esse post foi publicado em Dicas, Mundo SQL Server, SQL Server, VIRTUAL PASS BR e marcado , , , , . Guardar link permanente.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s