Есть ли какая-то логика в том, чтобы просто максимизировать базу данных tempdb и никогда не менять ее размер?

Question

Причина, по которой я спрашиваю, у нас есть выделенный массив RAID10 с ~ 150 ГБ для базы данных tempdb (диск "t").Он используется только для хранения базы данных tempdb.Диск t не используется SQL Server или каким-либо другим процессом ни для чего другого.

Наш администратор БД имеет настройку tempdb с начальным размером 15 ГБ и с шагом 20%.Каждый раз, когда сервер запускается, его размер изменяется до 15 ГБ, а затем в течение дня увеличивается до ~ 80 ГБ (в среднем).Теперь ИТ-отдел стремится увеличить начальный размер, скажем, на 30 или 40 ГБ, но, учитывая, что диск используется ТОЛЬКО для tempdb, я думаю, почему бы сразу не «максимизировать его».файлы в основной группе для базы данных tempdb присваивают каждому начальный размер 30 ГБ (всего 120 ГБ), отключают автоматическое наращивание и с этим покончено?

Существуют ли ограничения на способность SQL Server охватывать несколько файлов данных базы данныходин запрос?то есть это вызовет проблемы, если у tempdb будет, скажем, 70 ГБ всего свободного, но файл, используемый одним процессом, заполнен (30 из 30 ГБ использовано)?

Answer 1

Я бы увеличил их до 100 ГБ и оставил бы автостранок включенным, так что вам не нужно ждать, пока он будет расти каждый раз, я бы также добавил несколько файлов

Это любой минусэффект простого создания 4 файлов данных в основной группе для базы данных tempdb, каждый из которых имеет начальный размер 30 ГБ, выключить автостранок и с этим покончить?

Звучит как хороший план для меня, однако яоставил бы autogrow на всякий случай, если кто-то решит выполнить операцию сортировки для большой таблицы, у которой нет индекса для этого столбца

См. также здесь: http://technet.microsoft.com/en-us/library/cc966534.aspx

• Рекомендуется иметь от 25 до 1 файлов данных (на файловую группу) для каждого ЦП на хост-сервере.
• Это особенно верно для TEMPDB, где рекомендуется 1 файл данных на ЦП.
• Двухъядерный процессор считается за 2 процессора;логические процессы (гиперпоточность) - нет.

Answer 2

Мы считаем очень полезным создавать большие данные TempDB и файлы журналов.Любые действия, которые ограничивают действия ОС сервера, такие как изменение размера TempDB, повышают эффективность работы сервера.У нас есть 16-процессорный компьютер с 113 ГБ, выделенный для пространства данных TempDB.Эта машина предназначена для больших процессов ETL SSIS, что приводит к массовым операциям с данными.

Большая часть наших операций ETL порождает до 4 потоков SQL.После первоначальной настройки файла TempDB для каждого процессора (16) мы быстро поняли, отслеживая производительность, что наша конфигурация заставляла SQL \ windows излишне охватывать несколько файлов TempDB.Мы остановились на 5 больших файлах данных TempDB и реализовали улучшения производительности.С тех пор мы перешли к 24 процессору и используем 8 файлов TempDB.

Обратите внимание, что это большой сервер миграции данных;Я уверен, что ориентированные на транзакции системы по-прежнему выиграют от рекомендуемой конфигурации процессора 1-1 для файла TempDB.Следует также отметить, что наличие значительного увеличения% в файле TempDB может заставить критическую транзакцию выполнить операцию Windows и таким образом может не подходить для вашего конкретного приложения.