Хорошо ли иметь несколько файлов данных / журналов даже на одном LUN?

Question

Я прочитал, что для каждого ядра ЦП / ЦП полезно иметь один файл, чтобы SQL мог более эффективно передавать данные на диски и с дисков.Хорошо, я вижу преимущество, если они находятся на разных шпинделях, но что, если у меня только один шпиндель (4 диска в Raid 10) для моих файлов данных (.mdf и .ndf), я все равно получу пользу от разделения файлов данных(только из файла .mdf в файл .mdf и несколько файлов .ndf)?То же самое касается файла журнала, хотя я не вижу в этом никакой пользы, поскольку данные должны записываться последовательно, и вы ограничены последовательной скоростью записи шпинделя ...

К вашему сведению, это касается SQLСервер 2005/2008 ...

Спасибо.

Answer 1

Рекомендация для нескольких файлов данных tempdb определенно не относится к IOPS.Речь идет о конфликте на страницах размещения (GAM, SGAM, PFS) в базе данных tempdb.SQL 2005+ не требует такой большой нагрузки на эти страницы, но конфликты все еще возникают.Не во всех системах требуется отображение 1 файла на 1 ядро.Большинство систем будет хорошо работать с 1 файлом на 2 или 4 ядра.Наличие слишком большого количества файлов увеличивает издержки на управление файлами.Хорошая рекомендация - начинать с 1: 4 или 1: 2 и увеличивать, если конфликт продолжается.Не превышайте 1: 1.

Для других баз данных это не рекомендуется.

И да, только 1 файл журнала ... всегда.

Answer 2

8 Шаги для повышения пропускной способности журнала транзакций :

Создание только ОДНОГО файла журнала транзакций.Несмотря на то, что вы можете создать несколько файлов журнала транзакций, вам нужен только один ... SQL Server НЕ "разбивается" по нескольким файлам журнала транзакций.Вместо этого SQL Server использует файлы журнала транзакций последовательно.

Заблуждения относительно TF 1118 :

Почему флаг трассировки не требуется так много в2005 и 2008?В SQL Server 2005 моя команда изменила систему размещения для базы данных tempdb, чтобы уменьшить вероятность конфликтов.Теперь есть кеш временных таблиц.Когда новая временная таблица создается в холодной системе (сразу после запуска), она использует тот же механизм, что и в SQL 2000. Однако при ее удалении вместо полного освобождения всех страниц остаются одна страница IAM и одна страница данных.выделяется, а временная таблица помещается в специальный кеш.Последующие создания временных таблиц заглянут в кеш, чтобы узнать, смогут ли они просто получить предварительно созданную временную таблицу «с полки».Если это так, это позволяет избежать полного доступа к битовым картам распределения.Кеш временных таблиц не велик (я думаю, что это 32 таблицы), но это все же может привести к большому снижению конкуренции за защелки в базе данных tempdb.

Таким образом, ответ таков:НЕТ на оба вопроса.Чередование журналов никогда не было проблемой, и один NDF-на-процессор в значительной степени является мифом, который отнимает очень много времени.Несколько файлов IMHO имеют смысл, только если вы можете чередовать IO (отдельные LUN).Несколько файловых групп хотя и имеют смысл, но не по причинам ввода-вывода, для административных целей: частичное восстановление и архивирование файловых групп только для чтения.

Answer 3

Все еще хорошо.Это не о IOPS - это о SQL Server, который блокирует файл для определенных операций.в основном, когда расширение файла выделяется для таблицы / индекса.Если вы делаете много вставок / обновлений, несколько файлов в основном означают, что другой поток будет блокировать другой файл, а не ждать первого.

Таким образом, на самом деле речь идет не о загрузках IOPS, а о поведении блокировки.