Мы рассматриваем возможность кластеризации наших экземпляров SQL Server 2008 EE. Хранилище находится в SAN. Можно ли разместить файлы данных / журналов tempdb в SAN? Каковы плюсы и минусы этого решения? Можем ли мы для достижения оптимальной производительности создать такое же количество файлов данных tempdb, как и ядра процессора?
Единственный вариант - поместить TempDB на общий дисковый ресурс, то есть в SAN. Конкуренция со стандартным дисковым вводом-выводом - это то, что вас беспокоит, особенно для TempDB, поскольку это центральное узкое место для всего экземпляра.
Что касается количества файлов для TempDB, см. Сообщение Пола Рэндала по этой теме. Он отвечает за механизм хранения, поэтому он является экспертом в этой области: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(1230)-tempdb-should-always-have-one-data-file-per- процессор-core.aspx
Если вы используете кластеризацию MS SQL, я понимаю, что все тома должны находиться в общем хранилище, которым обычно является SAN.
Да, вы можете разместить файлы данных и журналов tempdb в SAN. Вы не обязательно иметь к. Вы мог (и акцент на том, чтобы быть ОСТОРОЖНЫМ здесь) иметь tempdb в хранилище с прямым подключением (DAS) на каждом узле, однако буква диска и размеры должны совпадать, и вы столкнетесь с проблемами. Плюсы и минусы будут примерно такими же, как и для обычных файлов БД в SAN, и применяются те же концепции высокой доступности. Производительность ввода-вывода может быть проблемой, поэтому размещайте ее там, где вы хотите повысить производительность.
Что касается «оптимальной производительности» - не существует строгого правила, сколько файлов у вас должно быть для tempdb. Начните с 1/4 числа ядер, проверьте свои рабочие нагрузки, при необходимости увеличьте. Если у вас слишком много файлов для tempdb, вы можете получить узкое место в своей подсистеме ввода-вывода, если она не сможет справиться с этим.