Grande quantidade de tempdb log escrevendo, sem leitura

Question

Estou correndo em algum comportamento que parece estranho para mim. Estou usando o SQL Server 2008 Enterprise, de 32 bits (quad Core 2), no Windows 7 (para teste).

Eu tenho um procedimento armazenado que usa duas variáveis de tabela. Um recebe cerca de 2 ou 3 linhas inseridas, o outro recebe de 0 a 100 linhas. Então eu seleciono talvez 20-60 linhas do segundo, e é isso.

O desempenho é muito rápido. Eu criei um aplicativo simples para fazer consultas, e eu posso fazer 1300 / seg com 1 thread, e cerca de 4000 com 4 threads.

Digite tempdb: Quando abro o monitor de recursos para ver o que está acontecendo, vejo que há muita gravação em arquivos de log tempdb. (Eu criei 2, 100MB em 2 discos físicos diferentes - eles não parecem passar dos 100MB). Há uma atividade de leitura zero - o DB inteiro se encaixa na RAM.

Com um único thread executando consultas, há cerca de 3 MB / s de gravação em arquivos de log do tempdb. Conforme eu aumente, ele vai para 20MB / s por arquivo de log.

No Monitor de Atividades SQL, "Registro" ultrapassa 300 ms / s para "Tempo de Espera" quando estou usando 5 encadeamentos. Em 3 threads, é até 25ms / seg.

Pergunta: O que está acontecendo? Por que o SQL escrevendo para tempdb registra como um louco, mas emitindo zero leituras (não vejo nenhuma atividade de leitura no monitor de recursos ou no monitor de atividades)? Em um ambiente que não é de teste, parece-me que ter uma gravação extra de 40MB / s pode ser prejudicial ao desempenho geral.

Eu sei que as variáveis de tabela (@foo) nem sempre são armazenadas na memória, mas estou confuso sobre o motivo pelo qual tempdb tem que registrar todas essas coisas. Como posso resolver o que está fazendo? Posso colocar o log do tempdb em um ramdisk ou algo assim? Quaisquer outros ponteiros?

Obrigado antecipadamente!

    

Answer 1

Esse é o comportamento típico do log escrever com antecedência . Quando uma página é atualizada em um banco de dados, a atualização é primeiramente gravada no log e depois aplicada à página da memória. A página fica suja na memória até que o ponto de verificação ocorra, ponto no qual ela é gravada no disco. O log deve ser escrito antes da atualização para suportar recuperação e reversão. A menos que um desses dois ocorra (recuperação ou reversão), não há necessidade de ler novamente o log. Portanto, o comportamento que você vê é típico de um sistema que modifica páginas em tempdb. Você só veria as leituras de log se a reversão ocorresse (já que a recuperação não pode ocorrer para tempdb).

Uma pergunta mais interessante é por que tantas atualizações de páginas estão ocorrendo no tempdb? Os culpados típicos são atualizações diretas (por exemplo, estado de sessão em tempdb com ASP) ou indiretas (spools e classificações em planos de consultas).