Respostas:
Esse nível de isolamento permite leituras sujas. Uma transação pode ver alterações não confirmadas feitas por outra transação.
Para manter o nível mais alto de isolamento, um DBMS geralmente adquire bloqueios nos dados, o que pode resultar em perda de simultaneidade e uma alta sobrecarga de bloqueio. Esse nível de isolamento relaxa essa propriedade.
Você pode conferir o artigoREAD UNCOMMITTED da Wikipedia sobre alguns exemplos e leituras adicionais.
Você também pode estar interessado em conferir o artigo do blog de Jeff Atwood sobre como ele e sua equipe resolveram um problema de impasse nos primeiros dias do Stack Overflow. De acordo com Jeff:
Mas é
nolockperigoso? Você pode acabar lendo dados inválidos comread uncommittedativado? Sim, em teoria. Você não encontrará escassez de astronautas de arquitetura de banco de dados que começam a lançar a ciência do ACID em você e quase acionam o alarme de incêndio do prédio quando você diz que deseja tentarnolock. É verdade: a teoria é assustadora. Mas eis o que penso: "Na teoria, não há diferença entre teoria e prática. Na prática, existe".Eu nunca recomendaria usar
nolockcomo uma correção geral "boa para o que lhe aflige" o óleo de cobra para qualquer problema de impasse no banco de dados que você possa ter. Você deve tentar diagnosticar a origem do problema primeiro.Mas, na prática, adicionar
nolockperguntas que você absolutamente conhece como assuntos simples e diretos de leitura nunca parece levar a problemas ... Desde que você saiba o que está fazendo.
Uma alternativa para o READ UNCOMMITTEDnível que você pode querer considerar é o READ COMMITTED SNAPSHOT. Citando Jeff novamente:
Os snapshots contam com um método de rastreamento de alterações de dados totalmente novo ... mais do que apenas uma pequena alteração lógica, exige que o servidor lide com os dados fisicamente de maneira diferente. Quando esse novo método de rastreamento de alterações de dados é ativado, ele cria uma cópia ou instantâneo de cada alteração de dados. Ao ler essas capturas instantâneas em vez de dados ativos em momentos de contenção, os bloqueios compartilhados não são mais necessários nas leituras e o desempenho geral do banco de dados pode aumentar.
READ UNCOMMITTEDtambém pode fazer com que você leia linhas duas vezes ou perca linhas inteiras . Se uma divisão de página ocorrer enquanto você estiver lendo, poderá perder partes inteiras de dados. WITH(NOLOCK)só deve ser usado se a precisão dos resultados não é importante
Isso pode ser útil para ver o progresso de consultas longas de inserção, fazer estimativas aproximadas (semelhantes COUNT(*)ou aproximadas SUM(*)) etc.
Em outras palavras, os resultados retornados pelas consultas de leitura suja são bons, desde que você os trate como estimativas e não tome nenhuma decisão crítica com base neles.
Meu caso de uso favorito para read uncommited é depurar algo que está acontecendo dentro de uma transação.
Inicie seu software em um depurador, enquanto você percorre as linhas de código, ele abre uma transação e modifica seu banco de dados. Enquanto o código está parado, você pode abrir um analisador de consultas, definido no nível de isolamento não lido de leitura e fazer consultas para ver o que está acontecendo.
Você também pode usá-lo para verificar se os procedimentos de execução longa estão paralisados ou atualizando corretamente seu banco de dados.
É ótimo se sua empresa adora fazer procedimentos armazenados excessivamente complexos.
A vantagem é que pode ser mais rápido em algumas situações. A desvantagem é que o resultado pode estar errado (dados que ainda não foram confirmados podem ser retornados) e não há garantia de que o resultado seja repetível.
Se você se preocupa com a precisão, não use isso.
Mais informações estão no MSDN :
Implementa leitura suja ou bloqueio de nível de isolamento 0, o que significa que nenhum bloqueio compartilhado é emitido e nenhum bloqueio exclusivo é respeitado. Quando esta opção está definida, é possível ler dados não confirmados ou sujos; os valores nos dados podem ser alterados e as linhas podem aparecer ou desaparecer no conjunto de dados antes do final da transação. Esta opção tem o mesmo efeito que definir NOLOCK em todas as tabelas em todas as instruções SELECT em uma transação. Este é o menos restritivo dos quatro níveis de isolamento.
selectinstruções @Kip - não precisariam esperar para adquirir bloqueios compartilhados em recursos que são bloqueados exclusivamente por outras transações.
Quando está tudo bem em usar READ UNCOMMITTED?
Bom : grandes relatórios agregados mostrando totais em constante mudança.
Arriscado : Quase todo o resto.
A boa notícia é que a maioria dos relatórios somente leitura se enquadra nessa categoria de Bom .
Ok para usá-lo:
Isso cobre provavelmente a maioria do que um departamento de Business Intelligence faria no, digamos, SSRS. A exceção, é claro, é qualquer coisa com sinais de $ na frente. Muitas pessoas respondem por dinheiro com muito mais zelo do que as aplicadas nas principais métricas relacionadas necessárias para atender o cliente e gerar esse dinheiro. (Eu culpo os contadores).
Quando arriscado
Qualquer relatório que desça para o nível de detalhe. Se esse detalhe for necessário, geralmente implica que cada linha será relevante para uma decisão. De fato, se você não pode extrair um pequeno subconjunto sem bloqueá-lo, talvez seja pelo bom motivo que ele está sendo editado no momento.
Data histórica. Raramente faz uma diferença prática, mas, embora os usuários entendam que dados em constante mudança não podem ser perfeitos, eles não sentem o mesmo sobre dados estáticos. Leituras sujas não vão doer aqui, mas leituras duplas podem ocasionalmente ser. Vendo que você não deveria ter bloqueios em dados estáticos, por que arriscar?
Quase tudo o que alimenta um aplicativo que também possui recursos de gravação.
Quando mesmo o cenário OK não está bom.
NOLOCKessas tabelas para nada.read uncommittedpara aplicativos da Web quando o usuário vê alguma grade da interface do usuário em que a precisão dos dados não é tão importante. O usuário só quer uma rápida visão geral de quais registros podem estar lá, e talvez com alguma paginação, classificação e filtragem. Somente quando o usuário clica no botão Editar, tento ler o registro mais atual com um nível de isolamento mais rigoroso. Essa abordagem não deveria ser melhor em termos de desempenho?
select item from things with (UPDLOCK). Coloque um tempo limite rápido lá para que, se não conseguir obter o bloqueio rapidamente, informe ao usuário que está sendo editado. Isso o manterá seguro não apenas dos usuários, mas dos desenvolvedores. O único problema aqui é que você deve começar a pensar em intervalos e em como lidar com isso na interface do usuário.
Em relação aos relatórios, usamos em todas as nossas consultas de relatórios para impedir que uma consulta atinja os bancos de dados. Podemos fazer isso porque estamos obtendo dados históricos, não dados de até microssegundos.
Use READ_UNCOMMITTED em situações em que é improvável que a origem seja alterada.
Não use READ_UNCOMMITTED quando souber que a fonte pode mudar durante a operação de busca.
READ UNCOMMITTED.
READ UNCOMMITTEDmaioria das situações em que seus dados estão sendo usados ativamente e você deseja reduzir a carga no servidor para evitar possíveis bloqueios e reversões de transações apenas porque alguns usuários abusam sem cuidado " Atualizar "em uma página da web com uma grade de dados. Os usuários que visualizam vários registros ao mesmo tempo geralmente não se importam muito se os dados estiverem um pouco desatualizados ou parcialmente atualizados. Somente quando um usuário estiver prestes a editar um registro, você poderá fornecer os dados mais precisos.
Isso fornecerá leituras sujas e mostrará transações que ainda não foram confirmadas. Essa é a resposta mais óbvia. Não acho que seja uma boa ideia usar isso apenas para acelerar suas leituras. Existem outras maneiras de fazer isso se você usar um bom design de banco de dados.
Também é interessante observar o que não está acontecendo. READ UNCOMMITTED não ignora apenas outros bloqueios de tabela. Também não está causando bloqueios por conta própria.
Considere que você está gerando um relatório grande ou está migrando dados do seu banco de dados usando uma instrução SELECT grande e possivelmente complexa. Isso fará com que um bloqueio compartilhado possa ser escalado para um bloqueio de tabela compartilhado durante a transação. Outras transações podem ser lidas na tabela, mas as atualizações são impossíveis. Pode ser uma má idéia se for um banco de dados de produção, pois a produção pode parar completamente.
Se você estiver usando READ UNCOMMITTED, não definirá um bloqueio compartilhado na tabela. Você pode obter o resultado de algumas novas transações ou pode não depender de onde foram inseridos os dados e por quanto tempo a transação SELECT foi lida. Você também pode obter os mesmos dados duas vezes se, por exemplo, ocorrer uma divisão de página (os dados serão copiados para outro local no arquivo de dados).
Portanto, se for muito importante para você que os dados possam ser inseridos enquanto você faz o SELECT, READ UNCOMMITTED pode fazer sentido. Você deve considerar que seu relatório pode conter alguns erros, mas se for baseado em milhões de linhas e apenas algumas delas forem atualizadas ao selecionar o resultado, isso pode ser "bom o suficiente". Sua transação também pode falhar por completo, pois a exclusividade de uma linha pode não ser garantida.
Uma maneira melhor pode ser usar o SNAPSHOT ISOLATION LEVEL, mas seus aplicativos podem precisar de alguns ajustes para usá-lo. Um exemplo disso é se seu aplicativo usa um bloqueio exclusivo em uma linha para impedir que outros o leiam e entrem no modo de edição na interface do usuário. O NÍVEL DE ISOLAMENTO DO INSTANTÂNEO também possui uma penalidade de desempenho considerável (especialmente no disco). Mas você pode superar isso jogando o hardware no problema. :)
Você também pode considerar restaurar um backup do banco de dados para relatar ou carregar dados em um data warehouse.
Eu sempre uso LER SEM COMPROMISSO agora. É rápido com o mínimo de problemas. Ao usar outros isolamentos, você quase sempre encontrará alguns problemas de bloqueio.
Contanto que você use os campos de incremento automático e preste um pouco mais de atenção às inserções do que a sua multa, e poderá dizer adeus aos problemas de bloqueio.
Você pode cometer erros com READ UNCOMMITED, mas, para ser sincero, é muito fácil garantir que suas inserções sejam a prova completa. Inserções / atualizações que usam os resultados de uma seleção são as únicas coisas a serem observadas. (Use READ COMMITTED aqui ou garanta que leituras sujas não causem problemas)
Então vá para Dirty Reads (Especialmente para grandes relatórios), seu software será mais suave ...
Committedpara inserções e atualizações. Quanto a outros problemas, ele também demonstrou conhecimento dos problemas de divisão de página ao mencionar o uso de uma chave de incremento automático. Concordo com ele que quase todas as reportagens ao vivo feitas para serem lidas por apenas um ser humano podem tolerar pequenas discrepâncias na casa decimal final. Eu concordo que é uma história diferente para listagens detalhadas ou dados destinados a serem lidos e transformados automaticamente, assim como Clive.