Fala pessoal,
ando meio ocupado depois da mudança de emprego, então dei uma parada de postar, mas hoje separei um conteudo para publicar...vamos lá.
Para um melhor entendimento de todos e contextualização do uso de NOLOCK dentro do Microsoft SQL Server é interessante passarmos antes por algumas definições.
O LOCK é um mecanismo usado pelo Banco de Dados para bloquear conteudo na tentativa de sincronizar os múltiplos acessos de diversos usuários à mesma informação.
O uso do lock está diretamente ligado ao controle de concorrência. Este controle pode ser classificado como otimista ou pessimista. No caso do SQL Server, ele possui suporte a ambos, no entanto, o pessimista é o padrão.
Controle de Concorrência Otimista (Optimistic Concurrency Control)
No controle de concorrência otimista, o usuário não cria Locks quando faz a leituras dos dados. Desta forma, quando o usuário for atualizar dados, o sistema verifica se outro usuário está alterando os mesmos dados. Caso positivo, um erro será gerado. O controle é chamado de controle otimista porque é principalmente utilizado em ambientes onde a disputa dos dados é baixa e o custo de ocasionais Rollbacks das transações é menor do que o custo de utilizar Locks em comandos de leitura.
Controle de Concorrência Pessimista (Pessimistic Concurrency Control)
No controle de concorrência pessimista, a base de dados cria Locks que impedem usuários modificarem dados que podem afetar outros usuários de algum modo. No momento em que um usuário faz uma ação, o banco de dados cria um Lock para aquele conteúdo, desta forma, outros usuários ficam impedidos de realizarem ações que conflitem com o Lock até que o primeiro usuário acabe sua transação. O controle é chamado de controle pessimista porque é usado principalmente em ambientes onde a disputa dos dados é alta e o custo da proteção dos dados com Locks é menor do que o custo dos Rollbacks das transações se ocorrerem conflitos.
Com a definição do lock e dos controles de concorrência, fica mais fácil o entendimento do recurso NOLOCK do Microsoft SQL Server.
O NOLOCK permite executar consultas ao banco de dados sem bloquear o conteúdo. Com esta breve descrição é importante a reflexão que o recurso do NOLOCK só faz sentido no uso do Controle de Concorrência Pessimista.
Considerando este cenário, vamos nos aprofundar um pouco mais no recurso NOLOCK do Microsoft SQL Server. Ele possui duas características bem importantes:
1. Permite executar uma instrução SQL sem causar bloqueio da tabela que está sendo lida;
2. Permite ler dados não commitados.
A primeira característica é bem interessante, principalmente quando se busca performance e paralelismo. No entanto, a segunda característica precisa ser bem observada para evitar um uso indevido do NOLOCK e causar problemas no sistema. Diante disto, é muito importante que o desenvolvedor saiba exatamente o que está fazendo quando estiver utilizando o NOLOCK.
Vamos entender a sintaxe para utilização deste recurso. Segue abaixo um exemplo:
– Instrução SQL Normal:
SELECT * FROM NOTA_FISCAL ORDER BY CD_NOTA_FISCAL;
– Instrução SQL com NOLOCK:
SELECT * FROM NOTA_FISCAL WITH (NOLOCK) ORDER BY CD_NOTA_FISCAL;
Vamos agora analisar o uso para uma aplicação com as seguintes características:
1. A tabela de Nota Fiscal é modificada apenas com comandos de INSERT ou DELETE. Nunca UPDATE, pois devido ao negócio da aplicação não existe atualização das Notas.
2. Quem modifica esta tabela é apenas um procedimento de importação que roda através de um scheduler e não permite multi-threads do mesmo tipo. Ou seja, não temos nunca 2 importações de notas fiscais rodando em paralelo, elas ficam em fila se por algum motivo existir uma concorrência.
3. Existem diversas consultas e reports que precisam de acesso rápido a esta tabela de Nota Fiscal.
4. Todos os reports possuem horário de geração.
Diante destas características do sistema, o uso de NOLOCK pode ser recomendado e trazer um beneficio bem interessante a performance das consultas e reports relacionados as notas fiscais.
Vamos entender melhor esta conclusão..
Quando NÃO usamos NOLOCK e estamos no controle de concorrência pessimista, precisamos esperar que os outros procedimentos na tabela acabem para que consultas possam ser realizadas. Desta forma, denegrindo a performance de relatórios que estão rodando em paralelo a procedimentos de importação. No entanto, com o uso do NOLOCK em uma aplicação com as características descritas acima, podemos consultar os dados sem a necessidade de esperar que as importações realmente terminem, pois teremos lá o conteúdo de momento.
O report vai marcar a hora que ele foi gerado e como não são feitos UPDATES nas notas, nunca teremos dados inconsistentes. No pior caso, poderíamos ter uma nota que posteriormente ela seria cancelada (deletada), mas isto é algo comum dentro do negocio da aplicação.
O uso do NOLOCK implica em abrir mão da consistência em nome da melhor concorrência e tem suas aplicabilidades. No entanto, é importante sempre entender bem do negocio da aplicação e utilizá-lo com bom senso para que suas desvantagens não te tragam problemas piores que um problema de performance.
espero ter ajudado alguem com mais esse conhecimento....e não esqueçam da clicadinha basica nos anuncios, para dar uma insentivada ...rsrs
