SQL Server - временные и физические таблицы

У меня на работе есть движение отойти от использования #temp таблиц и вместо этого использовать постоянные физические таблицы с SPID. Всякий раз, когда кто-то ранее вставлял в таблицу #temp, теперь INSERT INTO dbo.MyPermanentTable (SPID, ...) VALUES (@@SPID, ...)требуется an - вместе с кучей DELETE FROM dbo.MyPermanentTable WHERE SPID = @@SPIDоператоров в начале, например, хранимой процедуры. Кроме того, само собой разумеется, что везде, где используются эти «постоянные таблицы для хранения временных данных», нужно быть осторожным, чтобы включить WHERE SPID = @@SPID.

Логика, лежащая в основе этой практики, заключается в том, что она улучшит общую производительность сервера, на котором выполняются запросы (за счет уменьшения количества операций ввода-вывода и конфликтов в базе данных tempdb). Я не заинтересован в таком подходе по ряду причин - он уродлив, потенциально опасен и кажется, что он может сильно повредить производительности тех запросов, которые используют новую схему.

У кого-нибудь есть опыт использования этого или подобных подходов к устранению таблиц #temp?

Можно довольно легко продемонстрировать, что это не приведет к уменьшению количества операций ввода-вывода или конкуренции, а вместо этого увеличит оба.

• IO : каждая строка, вставленная, прочитанная или удаленная из таблицы #temp, теперь будет вставлена, прочитана или удалена из таблицы @@ SPID. Но каждая строка будет шире с дополнительным столбцом @@ SPID, поэтому количество необходимых страниц немного увеличится, а количество операций ввода-вывода будет немного больше. Но что еще более важно, удаление таблицы #temp и инициализация новой таблицы сеанса #temp сеансом теперь должны быть смоделированы с помощью DELETE FROM @@spidTable WHERE spid = @@SPID, и, таким образом, операция усечения / создания (т. Е. Операции управления экстентом страницы) будет преобразована в строковых операциях несравненно медленнее.
• раздор . Каждое сканирование, в котором использовались блокировки страниц в таблице #temp, теперь может блокировать страницу с несвязанными строками spid, создавая тем самым ранее несуществующий конфликт. Каждое обновление, которое делает больше, чем достигает порога эскалации блокировки, имеет возможность повысить блокировку до блокировки таблицы и, таким образом, заблокировать любой другой spid.

Поэтому, хотя верно и то, что вы не столкнетесь с мифическим конфликтом IAM / SGAM / GAM в базе данных tempdb, единственная причина, по которой это может произойти, заключается в том, что ваши операции станут намного медленнее из-за обычного дополнительного ввода-вывода и дополнительного конфликта.

Это похоже на радикальное решение. В Интернете много статей о сокращении разногласий с tempdb (и об оптимизации его использования) - тщательно ли проверила ваша организация этот подход?

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

и т.п.

Звуки мне , как вы должны быть устранение неисправностей проблемы с производительностью в пределах TempDb, есть несколько предложений в здесь