Как изменить размер файлов tempdb

Обновлено: 03.07.2024

-c

-f

Ограничение этого способа заключается в том, что он работает только с логическими файлами базы данных tempdb по умолчанию, tempdevи templog. Если к базе данных tempdb были добавлены дополнительные файлы, их размер можно уменьшить после перезапуска сервера SQL Server как службы. Все файлы базы данных tempdb заново создаются в процессе запуска; таким образом, эти файлы пусты, и их можно удалить. Чтобы удалить дополнительные файлы в базе данных tempdb, выполните команду ALTER DATABASE с параметром REMOVE FILE.

Уменьшение размера базы данных Tempdb, способ 2

Для уменьшения размера базы данных tempdb в целом выполните команду DBCC SHRINKDATABASE. Команда DBCC SHRINKDATABASE использует параметр target_percent, в котором указывается желаемый размер свободного места в процентах, который останется в файле базы данных после уменьшения размера базы данных. При использовании команды DBCC SHRINKDATABASE может потребоваться перезапуск сервера SQL Server.

Внимание! При выполнении команды DBCC SHRINKDATABASE необходимо, чтобы с базой данных tempdb не производились другие операции. Чтобы гарантировать, что другие процессы не смогут использовать базу данных tempdb при выполнении команды DBCC SHRINKDATABASE, необходимо запустить сервер SQL Server в однопользовательском режиме. Дополнительные сведения см. в разделе Последствия выполнения команды DBCC SHRINKDATABASE или DBCCSHRINKFILE в процессе использования базы данных Tempdb данной статьи.

Существуют определенные ограничения для использования команды DBCC SHRINKDATABASE для базы данных tempdb. Конечный размер файла данных и файла журнала не может быть меньше размера, указанного при создании базы данных, или последнего размера, явным образом установленного при выполнении операций, изменяющих размер файлов, например команды ALTER DATABASE с параметром MODIFY FILE или команды DBCC SHRINKFILE. Другим ограничением команды DBCC SHRINKDATABASE является расчет значения параметра target_percentage и его зависимость от текущего используемого места на диске.

Уменьшение размера базы данных Tempdb, способ 3

Использование команды DBCC SHRINKFILE для уменьшения размера отдельных файлов базы данных tempdb. Команда DBCC SHRINKFILE обеспечивает большую гибкость, чем команда DBCC SHRINKDATABASE, поскольку эту команду можно использовать для отдельного файла базы данных, не затрагивая другие файлы, относящиеся к той же базе данных. Команда DBCC SHRINKFILE использует параметр target size, который равен окончательному желаемому размеру файла базы данных.

Внимание! Команду DBCC SHRINKFILE необходимо выполнять, когда с базой данных tempdb не выполняются другие операции. Чтобы гарантировать, что другие процессы не смогут использовать базу данных tempdb при выполнении команды DBCC SHRINKFILE, необходимо запустить сервер SQL Server в однопользовательском режиме. Дополнительные сведения о команде DBCC SHRINKFILE см. в разделе Последствия выполнения команды DBCC SHRINKDATABASE или DBCCSHRINKFILE в процессе использования базы данных Tempdb данной статьи.

Определите желаемый размер основного файла данных (tempdb.mdf), файла журнала (templog.ldf) и дополнительных файлов, добавленных к базе данных tempdb. Убедитесь в том, что используемое файлами место на диске меньше или равно желаемому размеру.
Подключитесь к серверу SQL Server с помощью средства Query Analyzer и выполните следующие команды Transact-SQL для конкретных файлов базы данных, размер которых необходимо уменьшить:

Преимущество команды DBCC SHRINKFILE заключается в том, что она позволяет уменьшить размер файла до размера, меньшего, чем исходный размер. Команду DBCC SHRINKFILE можно выполнять для любых файлов данных и файлов журнала. Ограничение команды DBCC SHRINKFILE заключается в том, что размер базы данных нельзя сделать меньше, чем размер базы данных model.

В SQL Server 7.0 уменьшение размера файла журнала транзакций является отложенной операцией, поэтому для выполнения операции уменьшения базы данных необходимо выполнить операцию усечения журнала и резервного копирования. Тем не менее, по умолчанию для базы данных tempdb параметру trunc log on chkpt присвоено значение ON; следовательно, для данной базы данных не требуется выполнять операцию усечения журнала. Дополнительные сведения об уменьшении размера журнала транзакций базы данных в SQL Server 7.0 см. в следующей статье базы знаний Майкрософт:

256650 INF: Уменьшение размера журнала транзакций в SQL Server 7.0 (Эта ссылка может указывать на содержимое полностью или частично на английском языке)

Последствия выполнения команды DBCC SHRINKDATABASE или DBCCSHRINKFILE в процессе использования базы данных Tempdb

Server: Msg 8909, Level 16, State 1, Line 0 Table Corrupt: Object ID 1, index ID 0, page ID %S_PGID. The PageId in the page header = %S_PGID.

Хотя ошибка 2501 может не означать наличия повреждений в базе данных tempdb, она приводит к сбою операции уменьшения размера. С другой стороны, ошибка 8909 может быть признаком повреждения в базе данных tempdb. Перезапустите сервер SQL Server, чтобы заново создать базу данных tempdb и очистить ее от ошибок согласованности. Тем не менее, имейте в виду, что могут быть другие причины ошибок физического повреждения данных, таких как ошибка 8909, включая проблемы с подсистемой ввода-вывода.

В этой статье приведены различные способы, которые можно использовать для сжатия базы данных tempdb в Microsoft SQL Server. Прежде чем сжать базу данных tempdb с помощью методов, описанных в этой статье, ознакомьтесь со следующей информацией:

Размер базы данных tempdb устанавливается равным последнему заданному значению (то есть размеру по умолчанию или последнему размеру, установленному с помощью команды alter database) после каждого перезапуска. Поэтому, если нет необходимости использовать другие значения или немедленно уменьшить размер, не следует выполнять действия, приведенные в этой статье. Для уменьшения размера базы данных можно подождать следующего перезапуска службы SQL Server. Большие размеры базы данных tempdb не повлияют негативным образом на работоспособность службы SQL Server.

В SQL Server 2005 и более поздних версиях сжатие базы данных tempdb ничем не отличается от сжатия базы данных пользователя, кроме того что для размера базы данных tempdb устанавливается заданное значение после каждого перезапуска экземпляра SQL Server.

Команду shrink можно безопасно выполнить в базе данных tempdb во время ее работы. Однако могут возникнуть другие ошибки, например блокирование, взаимоблокировка и др., из-за которых команда shrink не будет выполнена. Поэтому, чтобы команда shrink была выполнена правильно наверняка, мы советуем запускать ее, когда сервер работает в однопользовательском режиме или после прекращения всех действий с базой данных tempdb.

Сведения о базе данных tempdb

База данных tempdb является временной рабочей областью. Сервер SQL Server использует базу данных tempdb для выполнения многих задач. Вот некоторые из них:

хранение временных таблиц, созданных явным образом;

хранение рабочих таблиц, содержащих результаты, созданные в процессе обработки запросов и сортировки;

хранение материализованных статических курсоров;

хранение записей о версиях при использовании уровней изоляции моментальных снимков или уровней изоляции моментальных снимков зафиксированного чтения.

Сервер SQL Server записывает в журнал транзакций базы данных tempdb сведения, необходимые только для отката транзакции, но недостаточные для воспроизведения транзакций в процессе восстановления базы данных. Это позволяет повысить производительность инструкций INSERT в базе данных tempdb. Кроме того, сведения для воспроизведения каких-либо транзакций не требуется записывать в журнал, поскольку база данных tempdb создается заново каждый раз после перезапуска сервера SQL Server. Таким образом, в ней нет транзакций для наката или отката. При запуске сервера SQL Server база данных tempdb создается заново с помощью копии базы данных model, а ее размер устанавливается равным последнему заданному значению. Заданный размер является последним значением размера, установленным явным образом при выполнении операций, изменяющих размер файла, таких как ALTER DATABASE с параметром MODIFY FILE либо инструкции DBCC SHRINKFILE или DBCC SHRINKDATABASE.

По умолчанию база данных tempdb настроена для автоувеличения размера по мере необходимости. Таким образом, со временем размер этой базы данных может превысить желаемый. Простой перезапуск сервера SQL Server устанавливает размер базы данных равным последнему заданному значению.

В SQL Server 2005 и более поздних версиях можно использовать любой из следующих способов изменения размера базы данных tempdb:

Необходима ли перезагрузка?

Полный контроль размера файлов базы данных tempdb по умолчанию (tempdev и templog).

Работает на уровне базы данных.

Позволяет сжать отдельные файлы.

Способ сжатия файлов базы данных через графический пользовательский интерфейс.

Примечание. Средство SQL Server Management Studio в SQL Server 2005 не показывает правильный размер файлов базы данных tempdb после выполнения операции сжатия. Значение параметра «Выделенное в данный момент место» всегда берется из динамического административного представления sys.master_files и не обновляется после выполнения операции по сжатию размера для базы данных tempdb. Чтобы узнать правильный размер файлов базы данных tempdb после сжатия, в SQL Server Management Studio выполните следующую инструкцию:

Здесь рассказывается о первых трех методах.

Примечание. Для установок SQL Server 2000 вместо SQL Server Management Studio нужно использовать анализатор запросов. Кроме того, для использования команд DBCC базу данных потребуется перевести в однопользовательский режим.

Следующие три способа можно использовать для сжатия базы данных tempdb до значения ниже заданного:

Способ 1. Используйте команды Transact-SQL
Примечание. Для этого способа нужно перезапустить SQL Server.

Остановите SQL Server.

Из командной строки запустите экземпляр в режиме минимальной конфигурации. Для этого выполните следующие действия:

В командной строке перейдите к следующей папке:

Если этот экземпляр SQL Server является именованным, выполните следующую команду:

sqlservr.exe -s имя_экземпляра -c -f Если этот экземпляр SQL Server является экземпляром по умолчанию, выполните следующую команду:

sqlservr -c -f Примечание. Параметры -c и -f приводят к запуску SQL Server в режиме минимальной конфигурации, в котором размер файла данных базы данных tempdb составляет 1 МБ, а размер файла журнала — 0,5 МБ.

Подключитесь к серверу SQL Server с помощью анализатора запросов и выполните следующие команды Transact-SQL:

Остановите SQL Server. Для этого в окне командной строки нажмите клавиши CTRL+C, перезапустите SQL Server как службу и проверьте размер файлов Tempdb.mdf и Templog.ldf.

Ограничение этого способа заключается в том, что он работает только с логическими файлами базы данных tempdb по умолчанию, tempdev и templog. Если к базе данных tempdb были добавлены дополнительные файлы, их можно сжать после перезапуска сервера SQL Server как службы. Все файлы базы данных tempdb заново создаются во время запуска. Однако они являются пустыми и могут быть удалены. Чтобы удалить дополнительные файлы в базе данных tempdb, выполните команду ALTER DATABASE с помощью параметра REMOVE FILE.

Способ 2. Используйте команду DBCC SHRINKDATABASE
Используйте команду DBCC SHRINKDATABASE для сжатия базы данных tempdb. DBCC SHRINKDATABASE получает параметр target_percent. Этот параметр указывает желаемый размер свободного места в процентах, который останется в файле базы данных после ее сжатия. При использовании команды DBCC SHRINKDATABASE может потребоваться перезапуск сервера SQL Server.

Определите место на диске, используемое в настоящий момент базой данных tempdb, с помощью хранимой процедуры sp_spaceused. Затем рассчитайте долю в процентах свободного места на диске, доступного для использования, как значение параметра команды DBCC SHRINKDATABASE. Этот расчет основан на желаемом размере базы данных.

Примечание. В некоторых случаях потребуется выполнить команду sp_spaceused @updateusage=true для повторного расчета используемого места на диске, чтобы получить обновленный отчет. Дополнительные сведения о хранимой процедуре sp_spaceused см. на веб-сайте электронной документации на SQL Server.

Рассмотрим следующий пример.

Предположим, что база данных tempdb содержит два файла: основной файл данных (Tempdb.mdf) размером 100 МБ и файл журнала (Tempdb.ldf) размером 30 МБ. Предположим, что команда sp_spaceused сообщает, что основной файл данных содержит 60 МБ данных. Также предположим, что необходимо сжать основной файл данных до 80 МБ. Рассчитаем желаемую долю в процентах свободного места на диске, которое останется после уменьшения размера: 80 МБ – 60 МБ = 20 МБ. Теперь поделим 20 МБ на 80 МБ = 25 % и получим значение параметра target_percent. Размер файла журнала транзакций уменьшается соответствующим образом, оставляя 25 % или 20 МБ свободного места после сжатия базы данных.

Подключитесь к серверу SQL Server с помощью анализатора запросов и выполните следующие команды Transact-SQL:

Существуют определенные ограничения для использования команды DBCC SHRINKDATABASE для базы данных tempdb. Конечный размер файла данных и файла журнала не может быть меньше размера, указанного при создании базы данных, или последнего размера, явным образом установленного при выполнении операций, изменяющих размер файлов, например команды ALTER DATABASE с параметром MODIFY FILE. Другим ограничением команды BCC SHRINKDATABASE является расчет значения параметра target_percentage и его зависимость от текущего используемого места на диске.

Способ 3. Используйте команду DBCC SHRINKFILE
Используйте команду DBCC SHRINKFILE для сжатия отдельных файлов базы данных tempdb. Команда DBCC SHRINKFILE обеспечивает большую гибкость, чем команда DBCC SHRINKDATABASE, так как ее можно использовать для отдельного файла базы данных, не затрагивая другие файлы, относящиеся к той же базе данных. Команда DBCC SHRINKFILE использует параметр target size. Это желаемый окончательный размер файла базы данных.

Определите желаемый размер основного файла данных (tempdb.mdf), файла журнала (templog.ldf) и дополнительных файлов, добавленных к базе данных tempdb. Убедитесь, что используемое файлами место на диске меньше желаемого размера или равно ему.

Подключитесь к серверу SQL Server с помощью анализатора запросов и выполните следующие команды Transact-SQL для конкретных файлов базы данных, которые необходимо сжать:

Преимущество команды DBCC SHRINKFILE заключается в том, что она позволяет уменьшить размер файла до размера ниже исходного. Команду DBCC SHRINKFILE можно выполнять для любых файлов данных и файлов журнала. Ограничение команды DBCC SHRINKFILE заключается в том, что размер базы данных нельзя сделать меньше, чем размер шаблона базы данных.

Ошибки 2501 и 8909 при выполнении операций сжатия

SQL Server 2005 и более поздние версии

SQL Server 2000

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

В SQL Server 2000 и более ранних версиях эти ошибки вызовут сбой операций сжатия. Поэтому для сжатия базы данных tempdb необходимо будет перезапустить SQL Server, чтобы повторно создать базу данных tempdb.

Работа с базой данных TEMPDB

TEMPDB представляет собой системную базу данных Microsoft SQL Server, в которой хранятся временные таблицы созданные как самим сервером, так и пользователями. Эта база данных создается заново при каждом перезапуске Microsoft SQL Server. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB, однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.

При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы . Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, UNION, DISTINCT и т.п.

Проблема

В процессе работы 1С:Предприятия 8 возможно значительное увеличение размера базы данных TEMPDB .

Причина

Причиной увеличения размера базы данных TEMPDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства в базе данных TEMPDB из-за наличия активных транзакций, использующих объекты этой базы данных. Основные причины, вызывающие длительную блокировку работы этих механизмов базы данных TEMPDB, заключаются в следующем:

"Большие" транзакции, использующие TEMPDB , выполнение которых занимает большой промежуток времени.
Сетевые ошибки, из-за которых Microsoft SQL Server не получает уведомление о потере сетевого подключения. Если клиентская рабочая станция зависает, перезагружается, или будет выключена во время исполнения определяемой пользователем транзакции, то Microsoft SQL Server будет считать, что клиент продолжает работу, и выполняющаяся клиентская транзакция будет по-прежнему активна. Время обнаружения подобной ситуации зависит от настроек параметров сетевого протокола, используемого Windows . Например, при использовании протокола TCP/IP это время составляет 2 часа.

Если для завершения активных транзакций не хватает места в базе данных, Microsoft SQL Server автоматически увеличивает размер TEMPDB на величину, заданную в параметрах этой базы данных (по умолчанию - 10% от текущего размера).

Решение

Уменьшить размер базы данных TEMPDB до требуемой величины можно следующими способами:

В этом случае размер базы данных TEMPDB будет установлен по умолчанию или, если эта величина переопределена пользователем, размер будет установлен в соответствии с заданными параметрами.

С помощью команды DBCC SHRINKDATABASE можно уменьшить размер всей базы данных. Для этого нужно в Query Analyzer выполнить следующую команду: С помощью команды DBCC SHRINKFILE можно уменьшить размер отдельных файлов базы данных. Для этого нужно в Query Analyzer выполнить следующую последовательность команд:

Копировать в буфер обмена
DBCC SHRINKFILE ( Имя_Файла_Данных, Желаемый_Размер_Файла_Данных )
go
DBCC SHRINKFILE ( Имя_Файла_Журнала_Транзакций, Желаемый_Размер_Файла_Журнала_Транзакций )
go

Следует отметить, что эти команды рекомендуется выполнять в период наименьшей активности пользователей, и для их выполнения необходимо обладать правами администратора.

Более подробное описание и рекомендации по использованию этих команд можно найти в документации по Microsoft SQL Server.

Срочно понадобилось уменьшить размер tempdb. Можно выполнить сжатие, перезапуск сервера, танцы с бубнами. Всё это уменьшит размер tempdb, но не сделает его меньше Initial Size. И это большая проблема, особенно для тех экземпляров, где база tempdb вынесена в оперативную память:

Есть полезная статья от Microsoft, в которой есть решение по уменьшению Initial Size:

Но о подводных камнях там ни слова. Печаль меня настигла, когда я дошёл до пункта: "Подключитесь к серверу SQL Server с помощью анализатора запросов". Сложно найти на сервере анализатор запросов, особенно если он там не установлен. Но можно обойтись без него, читаем.

Сжимаем tempdb

Для уменьшения Initial Size базы tempdb нужно:

Остановить службы SQL Server.
Запустить SQL Server в режиме минимальной конфигурации.
Подключиться к SQL Server от имени администратора (при этом нужно не дать подключиться к серверу другим администраторам раньше вас).
Выполнить SQL запросы для уменьшения базы tempdb:
Остановить SQL Server.
Запустить SQL Server в обычном режиме.

Перед тем как остановить SQL Server подумайте, как сделать так, чтобы никто другой потом не смог установить соединение раньше вас. Особенно 1С.

Вы можете зайти на сервер через консоль KVM и отключить сеть.
Вы можете запретить доступ на сервер извне с помощью Firewall.
Вы можете остановить все приложения, которые работают с данным SQL сервером.
Вы можете сменить порт SQL сервера.
Вы можете сменить пароль администратора SQL сервера.
Вы можете ничего не делать, но при этом действовать быстро и подключиться к серверу первым.

Перед началом работ решите, какой установите Initial Size для tempdev и templog.

У меня начальный размер tempdb 12 ГБ, уменьшу до 1 ГБ.

Останавливаем службы SQL Server.

Открываем командную строку под администратором. Переходим в рабочую директорию:

Запускаем SQL сервер в режиме минимальной конфигурации:

Теперь нужно подключиться к SQL серверу. Если используем SQL Server Management Studio, то получим ошибку:

Login failed for user User. Reason: Server is in single user mode. Only one administrator can connect at this time.

Вероятно, студия выполняет несколько коннектов, что недопустимо в режиме single user mode. Похожая ошибка возникнет и в том случае, если кто-то успеет выполнить соединение раньше вам.

Запускаем вторую командную строку под администратором. Выполняем:

Если видим "1>", то подключение успешно. Вводим:

Нажимаем в этом окне Ctrl+C, соединение завершается.

Нажимаем в окне с запущенным SQL сервером Ctrl+C, на вопрос об остановке SQL сервера пишем "Y", SQL сервер останавливается.

Для начала посмотрим на метрики, какой же прирост производительности может быть получен от использования RAM-диска.

Безусловно, данный тест является синтетическим и не отражает реальный профит(который будет ниже), но разница в цифрах является весьма показательной.

При использовании RAM-диска у нас всегда будет возникать одна проблема - что будет, если размер tempDB выйдет за пределы RAM-диска?

Эта проблема решается весьма просто - MSSQL позволяет создавать дополнительные файлы данных и логов, в том числе для tempDB.
Таким образом общие рекомендации сводятся к следующему:

Первый файл данных tempDB - на RAM-диске, фиксированного размера (я ставлю 75%) от размера RAM-диске. Отключен autogrowth.
Первый файл логов tempDB - на RAM-диске, фиксированного размера (я ставлю 25%) от размера RAM-диске. Отключен autogrowth.
Второй файл данных tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.
Второй файл логов tempDB - на обычном диске, начальный размер 8 Mb. Включен autogrowth.

Таким образом, при росте размера tempDB и выходе его "из берегов" RAM-диска он просто расширится на медленные диски.

Чтобы сжать дополнительные файлы БД, если tempDB выросла в их размеры, настраивается простенький план обслуживания на ночь:

P.S. Лишь внедрением RAM TempDB мы смогли ускорить закрытие месяца в ERP в два раза.

Специальные предложения

Эх! А я-то думал, что в статье будет описано, как именно сделать на сервере RAM-диск.
Какой понадёжнее, какой подешевле и т.п. Brawler; VKuser318125097; mpeg1989; sansys; Tavalik; alest; + 6 – Ответить (1) Ниже написал, каким диском пользуюсь.
Вопросы установки и настройки нужно рассмотреть? (5) Да не. Разобраться с установкой там легко.
Просто пишу свой отзыв о статье.
Я рассчитывал на сравнительный анализ ПО для RAM-дисков, а статья оказалась о другом. :) Ответьте, пожалуйста, с помощью какой программы вы делали RAM-диск? (8) а теперь 2 тыщи домашняя версия и чуть больше 3к - коммерческая. Для организации копейки, так-то. (4) Интерес скорее вызывает не столько цена, сколько опыт эксплуатации.
У вас это на рабочей базе/базах?
И нормально работает? Плюсанул за разнесение по файлам для решения проблемы переполнения.
Вроде банальная штука, но почему-то никогда в голову не приходила. Правда и вопрос этот всерьез не рассматривал. (9) Хм. И за счет чего ожидается прирост, если файлики рядом лежат?
Да и выставлять степень параллелизма в единицу - тоже спорный совет. Это радикально замедляет формирование тяжелых отчетов.
ЗЫ. Почитал про разбиение tempdb - это скорее прикрытие возможного узкого места (при большом количестве конфликтов при мультипоточном доступе к файлу), чем кнопка "турбо". Т.е. может и не иметь никакого эффекта. (15) Правильно ли я понял Ваш вопрос - за счёт чего возникает прирост производительности после перемещения tempDB в RAM. Верно? (16) Нет. Вопрос касался разделения tempdb на несколько файлов на одном и том же диске. Вопрос был не к вам.
Но если знаете точный ответ - буду благодарен. И актуальна ли эта рекомендация для RAID 5 и выше. (9) Конечно знаю. Но в данной ситуации рекомендация разбивать неприменима. Нужно ли объяснить, почему? (9) Не правильно давать ссылку на "перепосты", а не на первоисточник.
Плохо, что для 1С-ников истина по SQL на сайте 1С, а не на MSDN (((( MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков. Без тестов производительности статья ни о чем. Разбивать TempDB на несколько файлов - описано в настройках MS SQL от 1С, вероятно закрытие месяца от этого и ускорилось. (12) Я не являюсь экспертом по SQL, но насколько мне известно есть куча настроек (хеширование, статистика), которые отвечают за скорость работы с данными, ХРАНЯЩИМИСЯ НЕПОСРЕДСТВЕННО в базе (файле MDF). Но эти настройки (ИМХО) не ускоряют работы с файлами TempDB, которые (источник этой информации указать не могу) не планировались в роли оперативного хранилище здоровенных массивов информации, как сейчас их использует платформа 1С.
MS SQL сам кэширует в памяти все что нужно без всяких RAM-дисков.

MS SQL при построении плана запроса рассчитывает необходимое количество памяти и, если ошибается, то начинает задействовать tempdb. Это легко увидеть, если в профайлере получить планы запросов. Там, где стоит желтый восклицательный знак, там внутри как раз и пишет, что был задействован tempdb. Часто такое происходит на процедурах сортировки.

Было такое, как по изначальной статье, даже базы выносили, но потом все равно на ssd перешли.
Тем более в новых скулях есть настройки Buffer Pool Extension.
Как вы после перезагрузки сервера действуете или MSSQL в отложенном запуске?

Да, конечно от статьи ждал большего. Хотелось бы анализа причин, прироста производительности. Ну, простите меня, не ведующего, ну не могу я понять, почему если от SQL сервера откусить несколько десятков гигабайт памяти и сделать на них RAM-диск, то операции на этом сервере станут выполнять ЗАМЕТНО быстрее (и уж тем более в общем случае, а не как у автора - в частном случае закрытия месяца).

Ведь, насколько я знаю, все операции над temdb SQL сервер и так делает над таблицами (условно будем считать всё, что хранится в tembdb таблицами) с установленным внутренним приоритетом хранения в оперативной памяти (если её конечно достаточно)! То есть, временная таблица не будет выгружаться на диск, если для неё достаточно свободного места в оперативной памяти. Понятно, что если будут обрабатываться достаточно большие таблицы - они будут выгружаться на диск (при этом будет дублирование - часть данных наборов страниц будет в оперативном кеше и на диске). Но насколько же это будет в общем случае критично? Чтобы лишать SQL сервер гибко управлять всей своей свободной памятью, ради того, чтобы достаточно большая часть была всегда выделена под RAM диск с temdb - которая, скорее всего, в 90% не будет использована и на половину (а что будет использовано ещё и будет частично повторно кешировано в буфере SQL Server - неэффективно расходуя оперативную память на свои копии данных)! Так как SQL Server и всё-равно будет стараться держать временные таблицы в оставшейся у него оперативной памяти и выгружать их RMA-tempdb (причём выполняя объёмную пересылку данных между блоками памяти самым не производительным способом - через кучу посредников и между изолированными доменами приложений) в одну и в другую сторону только по мере необходимости (нехватки памяти, которая как раз и будет вызвана тем, что её попросту недодали SQL Server'у).

На мой взгляд RAM-диск для базы - это больше экстремальное экспериментирование, чем реальное предложение по ускорению! Вы вот так насоветуете админам - а они на своих серверах с 64Gb оперативной памяти, при базе(ах) объёмом боле 1Tb (с самой большой базой около 100Gb) и temdb, который у них при закрытии месяца пухнет свыше 100Gb возьму и выделять под RAM-tempdb минимум 16Gb (а кто-то и все 32Gb) и тем самым у них просядет обычная работа с данными рабочих баз на 25% (условно) в обычном режиме (а в пике ещё больше), а скорость работы с temdb (в часы макс нагрузки) увеличится ну максимум на 20% (и это в пике) - будет ли это реальной панацеей? Большой вопрос! Очень большой!

Тут в статье нужно было писать про исследования, которые должны были предварять такие вот серьёзные перераспределения ресурсов. Показывать где и как возникают узкие горлышки использования temdb. Обосновывать (с конкретными доводами тестов) когда и почему стоит отнимать буферную память от SQL сервера и отдавать её temdb.

И главное, в чём будет реальный экономический выигрыш - от того, что сервер будет требовать больше очень недешёвой серверной оперативной памяти, нежели - как альтернатива - просто разместить temdb на хорошем (тоже не дешёвом, но это пока с памятью не сравнить) серверном SSD диске - с высоким IOPS (лучше всего модели для PCI-ex, а не SAS/SATA; ну или хотя бы в слот M.2 - но это только на современных матерях) , и низким коэффициентом снижения производительности от числа полной перезаписи. Тут важна скорость - надёжность не так важна - это же не для хранения рабочей базы данных.

Вот тогда от статьи был бы толк.

Ну а если помещать в RAM tempdb - то я был начал только с лога temdb - который только пишется (и перезаписывается) в simple rec. mode, ему не требуется хранить большие объёмы дублирующихся данных. А данные временных таблиц - пусть SQL Server сам размещает в доступной ему буферной памяти, и выгружает на физ диск (лучше SSD), когда памяти уж совсем не хватает (а если это часто -то лучше 100 раз задуматься о том, чтобы её нарастить - ведь если её не хватает, от её перераспределения её больше не станет).

Вообще, прежде чем переходить на RAM - лучше сначала освоить перенос temdb на другой диск - если Ваш tempdb находится в том же RAID массиве что и диски рабочей базы - то задумайтесь сначала об этом, крайне негативном факторе - вынесите tempdb на отдельный RAID массив, да хотя бы просто на отдельный диск (два диска : данные и лог) и Вы сразу почувствуете прирост скорости, особенно в пиковой нагрузке! А уж если вы выберите для temdb PСI-ex SSD диски - то, наверняка, дальнейшее желание переносить их на RAM у Вас уже пропадёт!

Читайте также: