Início / dba / Perguntas / 29289
Accepted
Jeroen
Asked: 2012-11-27 03:05:57 +0800 CST

Opções para definir dica NOLOCK em consultas de conjunto de dados

  • 772

Algum contexto:
No início, escrevíamos relatórios apenas "diretos", sem nenhuma dica de bloqueio nas consultas. Com os relatórios maiores, isso às vezes causava problemas de bloqueio. Inicialmente , corrigimos isso usando a WITH (NOLOCK)dica para tabelas na consulta.

Como (a) é bastante intrusivo e (b) é fácil esquecer a dica para uma das tabelas, passamos para uma segunda configuração TRANSACTION ISOLATION LEVELde abordagem READ UNCOMMITTED(o que é bom) na parte superior da consulta de cada conjunto de dados.

Como você pode imaginar, ainda é fácil esquecer a dica para um dos conjuntos de dados. Então isso leva à pergunta:

Descrição: Quais são as opções para envio de NOLOCKdicas junto com as consultas do relatório?

PS. Eu percebo que isso é até certo ponto um problema XY (com muitas das minhas outras opções para X, como otimizar a consulta, não fazer relatórios no banco de dados operacional etc.), mas tentei fazer disso uma pergunta válida em si mesmo .

Opções:
Aqui estão as opções mencionadas acima, com opções adicionais sobre as quais estou curioso para saber se funcionariam:

  1. Definir WITH (NOLOCK)dica para cada mesa. (obstrutivo, muito fácil de esquecer)
  2. Defina o nível de isolamento READ UNCOMMITTEDpara toda a consulta. (ainda fácil de esquecer)
  3. É possível especificar isso no nível do relatório ? Por exemplo, certifique-se de que todas as consultas de conjunto de dados para um relatório sejam executadas sem bloqueio.
  4. É possível especificar isso em algum outro nível do SSRS ? Por exemplo, talvez defina isso para uma determinada pasta de relatório ou utilizando uma extensão?
  5. É possível especificar isso no nível da fonte de dados/cadeia de conexão ? Por exemplo, todos os relatórios relevantes usam uma determinada "fonte de dados sem bloqueio"?
  6. Relacionado à opção anterior: talvez seja possível especificar uma dica de bloqueio padrão para um "no-lock-sql-user" específico (aquele que é usado na conexão)?
  7. ???

Quais opções são viáveis? Existem opções que eu perdi?

sql-server locking

2 respostas

  1. Você já considerou READ_COMMITTED_SNAPSHOTo controle de versão de linha para o banco de dados?

    Kim Tripp tem um bom artigo sobre isso em http://msdn.microsoft.com/en-us/library/ms345124%28v=sql.90%29.aspx

    READ_COMMITTED_SNAPSHOTpermite uma funcionalidade melhor do WITH (NOLOCK)que fornece consistência pontual absoluta para agregações ou consultas de execução longa com maior rendimento devido à contenção de bloqueio reduzida.

    • 6
  2. Best Answer

    Respostas rápidas:

    1. Funciona, como você observou.
    2. Funciona, como você observou.
    3. Isso não parece funcionar. Não vi uma opção de improviso e sempre que essa pergunta é feita, a resposta sempre volta para definir o nível de isolamento no procedimento armazenado .
    4. Eu não acreditaria. O SSRS está em uma camada de abstração mais alta do que o mecanismo de banco de dados, portanto, em certo sentido, não importa qual seja o nível de isolamento - afinal, você pode usar soluções não RDBMS em seus relatórios.
    5. Isso não funciona. Você não pode definir o nível de isolamento na cadeia de conexão .
    6. Isso pode funcionar. Você pode criar um gatilho de login .

    Existem algumas opções viáveis ​​se os relatórios forem otimizados e ainda estiverem causando problemas:

    1. Use Always On se você tiver o SQL 2012. Você pode ter uma réplica somente leitura que seus relatórios do SSRS possam usar.
    2. Use replicação: instantâneo se você não precisar de tempo real e transacional se precisar que seja quase em tempo real.
    3. Se você não tem orçamento para o Always On ou paciência para lidar com a replicação, faça a replicação de forma barata: crie um esquema compatível com relatórios (ou seja, desnormalize as tabelas e coloque-as em um formato que facilite a execução de relatórios ) e use o SSIS para alimentar esse esquema de relatório. Isso funciona melhor se seus usuários finais puderem conviver com dados "mais antigos" (por exemplo, atualização a cada hora ou a cada 5 minutos). A desvantagem é que você projetará o modelo de dados duas vezes: uma vez para o modelo OLTP e outra para o modelo de pseudoarmazenamento. A vantagem é que, se você se mover na direção de um data warehouse centralizado, este é um exercício muito útil.
    • 5

relate perguntas