Início / dba / Perguntas / 12286
Accepted
Will A
Asked: 2010-07-05 08:46:10 +0800 CST

SQL Server - Tabelas temporárias x físicas

  • 772

Um movimento está em andamento em meu local de trabalho para deixar de usar tabelas #temp e, em vez disso, usar tabelas físicas permanentes com SPIDs. Sempre que alguém insere anteriormente INTO em uma tabela #temp, agora INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)é necessário um - junto com um monte de DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDinstruções no início, por exemplo, de um procedimento armazenado. Além disso, nem é preciso dizer que, em qualquer lugar em que essas 'tabelas permanentes para armazenar dados temporários' sejam usadas, é preciso ter o cuidado de incluir um arquivo WHERE SPID = @@SPID.

A lógica por trás da mudança em direção a essa prática é que ela melhorará o desempenho geral do servidor no qual as consultas estão sendo executadas (reduzindo a E/S e a contenção em tempdb). Não gosto dessa abordagem por vários motivos - é feia, potencialmente perigosa e parece que pode prejudicar o desempenho das consultas que usam o novo esquema.

Alguém tem alguma experiência com isso ou abordagens semelhantes para eliminar tabelas #temp?

sql-server performance

3 respostas

  1. Best Answer

    Pode-se demonstrar facilmente que isso não reduzirá IO nem contenção, mas aumentará ambos.

    • IO : Cada linha inserida, lida ou excluída de uma tabela #temp agora será inserida, lida ou excluída da tabela @@SPID. Mas cada linha será mais larga com uma coluna @@SPID adicional, portanto, o número de páginas necessárias aumentará ligeiramente e o IO será um pouco maior. Porém, mais importante, a queda de uma tabela #temp e a inicialização de uma tabela #temp de uma nova sessão por uma sessão agora terão que ser simuladas com um DELETE FROM @@spidTable WHERE spid = @@SPIDe, portanto, a operação de truncar/criar (ou seja, operações de gerenciamento de extensão de página) serão transformadas em operações de linha, incomparavelmente mais lento.
    • Contenção : Cada varredura que estava usando bloqueios de página na tabela #temp agora terá o potencial de bloquear uma página com linhas spid não relacionadas, criando assim uma contenção inexistente anteriormente. Cada atualização que atinge o limite de escalonamento de bloqueio tem a oportunidade de escalar o bloqueio para bloqueio de tabela e, assim, bloquear todos os outros spid.

    Portanto, embora seja verdade que você não atingirá a contenção mítica de IAM/SGAM/GAM em tempdb, a única razão pela qual isso aconteceria é porque suas operações se tornariam muito mais lentas devido a E/S extra comum e contenção extra.

    • 18

  2. Esta parece ser uma solução drástica. Há muitos artigos on-line sobre como reduzir a contenção de tempdb (e otimizar seu uso) - sua organização examinou minuciosamente esse caminho?

    http://www.sql-server-performance.com/tips/tempdb_p1.aspx

    http://www.sqlservercentral.com/blogs/robert_davis/archive/2010/03/05/Breaking-Down-TempDB-Contention.aspx

    http://searchsqlserver.techtarget.com/tip/Optimize-tempdb-in-SQL-Server-by-striping-and-splitting-to-multiple-files

    etc.

    • 5

  3. Parece-me que você deveria estar solucionando os problemas de desempenho no tempDB, há algumas sugestões aqui

    • 2

relate perguntas