Всегда ли записи в TempDB приводят к фактической физической записи на диск, или записи TempDB кэшируются SQL Server для отложенной записи, как в кеше файловой системы Windows?
Они всегда? Определенно нет. Они когда-нибудь? Да, но не в результате типичного механизма. Ссылка здесь Что делает контрольная точка для tempdb? ,
В «хорошо управляемой» системе записи в файл базы данных пользователя происходят на контрольной точке. В системе с плохим поведением запись также происходит, когда лентяй должен очистить страницы из пула буферов, чтобы освободить место для других страниц.
Контрольная точка выполняется только для базы данных tempdb, когда файл журнала tempdb заполнен на 70% - это предотвращает рост журнала tempdb, если это вообще возможно (обратите внимание, что длительная транзакция по-прежнему может по существу удерживать заложники журнала и предотвращать его очистку так же, как в пользовательской базе данных).
Но нет необходимости сбрасывать базу данных tempdb на диск, так как восстановление после сбоя никогда не запускается на базе данных tempdb, оно всегда воссоздается при запуске.
Tempdb не восстанавливается в случае сбоя, поэтому нет необходимости принудительно загружать грязные страницы tempdb на диск, за исключением случая, когда процесс lazywriter (часть пула буферов) должен освободить место для страниц из других баз данных.
Это замечательно (это было для меня сюрпризом) единственный механизм, с помощью которого страницы tempdb будут записываться на диск. Если есть давление в буферном пуле, страницы tempdb могут быть сброшены на диск. Если нет, это не должно происходить.
Edit: Спорно ли «плохо себя» является подходящим для описания базы данных пользователя, написание страниц за пределами контрольной точки. Необычно, нетипично или просто не идеально, может быть?
Дополнительное редактирование (следующие комментарии / чат с @PaulWhite):
Вышеупомянутое упущение заключается в том, что временные таблицы не являются единственным источником трафика tempdb. Цитирование из Понимания событий хеширования, сортировки и разлива Exchange :
Некоторые операции выполнения запросов к SQL Server откалиброваны для обеспечения наилучшей производительности, используя (несколько) большой объем памяти в качестве промежуточного хранилища. Оптимизатор запросов выберет план и оценит стоимость на основе этих операторов, используя эту блокнот памяти. Но это, конечно, только оценка. При выполнении оценки могут оказаться неверными, и план должен продолжаться, несмотря на нехватку памяти. В таком случае эти операторы попадают на диск.
Я неправильно предположил, что механизм физической записи для операции разлива был точно таким же, как описанный ранее, то есть лениврайтер, заставляющий страницы базы данных tempdb на диск в результате давления на буферный пул (вызванного разливом).
@PaulWhite объяснил, где я был не прав (спасибо, Пол!):
Я думаю, вы спрашиваете, почему физическая активность базы данных tempdb возникает, когда запрос превышает выделение памяти рабочей области, а не просто использование базы данных tempdb в памяти. Если бы он это сделал, запрос использовал бы больше памяти, чем его выделение, что побеждает точку ограничения памяти гранты в первую очередь.
Разливы действительно особые в письменной форме до хранения. Физическая активность в базе данных tempdb наблюдается при разливе, даже несмотря на массу свободной памяти и нулевое давление на базу данных tempdb.
Пол также указал мне на свой пост в блоге Advanced TSQL Tuning: Why Internals Knowledge Matters, который включает примеры сценариев для демонстрации разливов, для тех, кто хочет глубже вникнуть.
