SQL Server "Run Dry Run" Modo? Carregar buffers de dados, sem manter bloqueios ou alterando dados

Question

Vou executar algumas consultas contra um banco de dados do SQL Server, seguido de uma exclusão. Idealmente, tudo isso acontece dentro de uma transação (ou seja, atômica).

Mas, praticamente, como os dados já foram expulsos dos buffers, o SQL Server terá que executar muito IO físico para concluir o T-SQL transalizado. Isso pode ser um problema, porque se o lote inteiro levar mais de 30 segundos para ser executado, os usuários terão problemas de tempo limite.

Eu notei que se eu dirigisse meu selectS em peças, cada vez que executa cada vez mais o SQL final, permitindo que o SQL Server preencha os buffers com cada vez mais dados necessários. por exemplo:

Primeira corrida:

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 ROLLBACK

Segunda corrida:

 BEGIN TRANSACTION
 SELECT ... WHERE ...
 SELECT ... WHERE ...
 ROLLBACK

...

n -th Run:

BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
ROLLBACK

E quando eu chego ao corrida final:

BEGIN TRANSACTION
SELECT ... WHERE ...
SELECT ... WHERE ...
...
SELECT ... WHERE ...
DELETE FROM ... WHERE ...
COMMIT

Todo o lote é rápido, já que os buffers estão pré-preenchidos.

Existe um modo de servidor SQL (ou seja, SET NOEXEC ON) Isso faria com que o SQL Server não executasse modificações de dados reais, não fizesse nenhum bloqueio, mas preenchesse os buffers com os dados necessários? por exemplo

SET NOEXEC ON
EXECUTE ThatThingYouDo

SET NOEXEC OFF
EXECUTE ThatThingYouDo

ou

SET DRYRUN ON
EXECUTE ThatThingYouDo

SET DRYRUN OFF
EXECUTE ThatThingYouDo

Answer 1

Não.
Digamos que você tenha inserção seguida de atualização nas linhas inseridas. Você nunca poderá imitar a atualização porque as linhas inseridas não existem. Agora, neste caso, por que suas seleções estão em uma transação? Por padrão (ou seja, a menos que você use holdlock ou similar), você não está travando as linhas durante a transação.

Se você acha que o pool de buffer (também conhecido como cache de dados) está "cheio", você precisa de mais RAM ou alguma outra atualização/escala.

Answer 2

Descobri que sempre que você tenta fazer algo extremamente fora do normal para resolver um problema, o design básico é provavelmente o problema. Isso é extremamente fora do normal.

Talvez você possa fornecer mais informações sobre o exclusão (tamanho da tabela, atividade, índice, linhas para excluir, outros processos em execução etc.) que estão demorando tanto e haverá uma solução convencional, usando um índice ou travamento, etc. para abordá -lo .