Opções para definir a dica NOLOCK nas consultas do conjunto de dados

7

Algum contexto:
no início, escrevemos relatórios apenas "diretamente", sem nenhuma dica de bloqueio nas consultas. Com os relatórios maiores, isso às vezes causava problemas de bloqueio. No primeiro nós remediado isso usando a WITH (NOLOCK)dica para tabelas na consulta.

Como (a) é bastante invasivo e (b) é fácil esquecer a dica para uma das tabelas, passamos para uma segunda configuração de abordagem TRANSACTION ISOLATION LEVELpara 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. Portanto, isso leva à pergunta:

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

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

Opções:
Aqui estão as opções mencionadas acima, com opções adicionais sobre as quais tenho curiosidade de saber se elas funcionariam:

  1. Definir WITH (NOLOCK)dica para cada tabela. (intrusivo, muito fácil de esquecer)
  2. Defina o nível de isolamento READ UNCOMMITTEDpara a consulta inteira. (ainda fácil de esquecer)
  3. É possível especificar isso no nível do relatório ? Por exemplo, verifique se todas as consultas do conjunto de dados de um relatório serão 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 certa "fonte de dados sem bloqueio"?
  6. Relacionado à opção anterior: talvez seja possível especificar uma dica de bloqueio padrão para um "usuário no-lock-sql-user" específico (aquele que é usado na conexão)?
  7. ???

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

sql-server locking ssrs Jeroen
fonte
O problema de ir para nolocks em todos os lugares ou alterar o isolamento para leitura não confirmada em toda a linha é um problema de qualidade de dados. Você não recebe apenas leituras sujas, mas pode retornar os mesmos dados duas vezes ou perder completamente os dados. Talvez seja melhor olhar para o seu design e ver se é hora de um banco de dados de relatórios separado. Veja esta pergunta
Mike Walsh
@MikeWalsh Concordou. Foi com isso que também tentei me relacionar um pouco sobre o problema XY. Ainda, saber onde e quando é uma opção usar dicas de bloqueio pode ser benéfico, se usado com cuidado.
Jeroen

Respostas:

5

Respostas rápidas:

  1. Funciona, como você observou.
  2. Funciona, como você observou.
  3. Isso não parece funcionar. Eu não vi uma opção de imediato 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 nisso. O SSRS está em uma camada de abstração mais alta que o mecanismo de banco de dados; portanto, em certo sentido, ele não se importa com 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ê poderia ter uma réplica somente leitura que seus relatórios do SSRS poderiam usar.
  2. Use replication: snapshot, se você não precisar em tempo real, e transacional, se precisar que ele seja próximo ao tempo real.
  3. Se você não tiver o orçamento do Always On ou paciência para lidar com a replicação, faça a replicação 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 viver com dados "mais antigos" (por exemplo, atualizando a cada hora ou a cada 5 minutos). A desvantagem é que você projetará o modelo de dados duas vezes: uma para o modelo OLTP e outra para o modelo de pseudo-armazenamento. A vantagem é que, se você se mover na direção de um data warehouse centralizado, esse é um exercício muito útil.
Kevin Feasel
fonte
6

Você considerou o READ_COMMITTED_SNAPSHOTcontrole 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 que WITH (NOLOCK)na medida em que fornece consistência point-in-time absoluta para agregações ou consultas de longa execução com maior taxa de transferência devido à contenção de bloqueio reduzida.

Max Vernon
fonte