COM (NOLOCK) vs DEFINIR NÍVEL DE ISOLAMENTO DA TRANSAÇÃO LIDO NÃO COMPROMETIDO


118

Alguém poderia me dar alguma orientação sobre quando devo usar WITH (NOLOCK)em vez deSET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

Quais são os prós / contras de cada um? Você teve alguma conseqüência não intencional ao usar um em vez do outro?

Respostas:


105

Eles são a mesma coisa. Se você usar a set transaction isolation levelinstrução, ela se aplicará a todas as tabelas na conexão, portanto, se quiser apenas nolockem uma ou duas tabelas, use-a; caso contrário, use o outro.

Ambos darão leituras sujas. Se você concordar com isso, use-os. Se você não pode fazer leituras sujas, considere snapshotou dê serializabledicas.


Considere, em REPEATABLE READvez de SERIALIZABLEse você não se preocupa com dados fantasmas. SERIALIZABLEé REALMENTE restritivo e quase nunca deve ser usado (exceto por exemplo em algumas aplicações financeiras críticas).
Kryptos,


10
  • NOLOCK é local para a tabela (ou visualizações, etc.)
  • READ UNCOMMITTED é por sessão / conexão

Quanto às diretrizes ... uma pesquisa aleatória de StackOverflow e da internet elétrica ...


O último link "Por que usar NOLOCK é ruim .." não existe mais.
sangam

1
internet elétrica não tem preço. obrigado por adicionar um pouco de sol ao meu dia.
JJS

9

Pelo que sei, a única diferença é o alcance dos efeitos, como disse Strommy. Dica NOLOCK em uma tabela e READ UNCOMMITTED na sessão.

Quanto aos problemas que podem ocorrer, é tudo uma questão de consistência. Se você se importar, esteja ciente de que você pode obter o que é chamado de leituras sujas, o que pode influenciar outros dados sendo manipulados em informações incorretas.

Eu pessoalmente não acho que vi nenhum problema com isso, mas isso pode ser mais devido a como eu uso o nolock. Você precisa estar ciente de que há cenários em que não há problema em usar. Cenários em que você está principalmente adicionando novos dados a uma tabela, mas tem outro processo que vem atrás para verificar um cenário de dados. Provavelmente não haverá problema, pois o fluxo principal não inclui voltar e atualizar as linhas durante a leitura.

Também acredito que hoje em dia você deve olhar para o Controle de simultaneidade de várias versões. Eu acredito que eles o adicionaram em 2005 e isso ajuda a impedir que os escritores bloqueiem os leitores, dando aos leitores um instantâneo do banco de dados para usar. Vou incluir um link e deixar mais pesquisas para o leitor:

MVCC

Níveis de isolamento de banco de dados


+1 Embora eu não tenha entrado no aspecto "você deveria" de READ_UNCOMMITTED ", Sean cobre isso muito bem. Também há casos em que você pode ler a mesma linha duas vezes no SQL Server (devido a divisões de página).
Anon246

6

Você não pode usar Definir nível de isolamento de transação com leitura não confirmada em uma exibição (você só pode ter um script lá, na verdade), então você teria que usar (nolock) se linhas sujas devessem ser incluídas.


4

Como você tem que usar WITH (NOLOCK) para cada tabela, pode ser irritante escrevê-lo em todas as cláusulas FROM ou JOIN. No entanto, há um motivo pelo qual é chamada de leitura "suja". Portanto, você realmente deve saber quando faz um, e não defini-lo como padrão para o escopo da sessão. Por quê?

Esquecer um WITH (NOLOCK) pode não afetar seu programa de uma forma muito dramática, no entanto, fazer uma leitura suja onde você não quer pode fazer a diferença em certas circunstâncias.

Portanto, use WITH (NOLOCK) se os dados atuais selecionados puderem estar incorretos, pois podem ser revertidos posteriormente. Isso é usado principalmente quando você deseja aumentar o desempenho, e os requisitos no contexto do aplicativo permitem que ele corra o risco de que dados inconsistentes sejam exibidos. No entanto, você ou alguém responsável deve avaliar os prós e contras da decisão de usar o WITH (NOLOCK).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.