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

14

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

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

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

sql-server performance Будет ли
источник

Ответы:

18

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

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

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

Ремус Русану
источник
Я полностью согласен с вышеупомянутым Ремусом - и спасибо за отличный ответ. Проблема заключается в том, что мы вызываем предполагаемое снижение производительности сторонних приложений (с несколькими базами данных на сервере, на котором у нас есть собственная база данных - нам нужно выполнять запросы против их данных). Я все еще думаю, что вы правы, учтите, что в плане ввода-вывода я бы ожидал, что новый подход будет работать значительно хуже, чем раньше - в случае конфликтов, с точки зрения tempdbs, все будет лучше - с нашей стороны, несколько хуже.
Будет
Сколько у вас файлов tempdb? Стандартная настройка вообще не масштабируется - у вас должно быть несколько файлов базы данных и журналов tempdb, по одному на каждое видимое ядро ​​процессора (по 2 на каждый гипер-v).
TomTom
1
Вы должны прочитать эти две статьи: sqlskills.com/BLOGS/PAUL/post/… и sqlskills.com/BLOGS/PAUL/post/…, так как они решают наиболее распространенные проблемы масштабируемости tempdb.
Ремус Русану
@ TomTom воу, воу. Несколько файлов журнала? В самом деле?
Аарон Бертран
5

Это похоже на радикальное решение. В Интернете много статей о сокращении разногласий с 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

и т.п.


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

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

SPE109
источник
Выглядит полезным - спасибо SPE109, я проверю это и порекомендую нашему администратору базы данных.
Будет