У меня есть разумный сервер, подключенный к SAN, на котором будут работать SQL-серверы для нескольких приложений. Нет никаких проблем с безопасностью, когда одно приложение может читать базу данных другого.
К сожалению, у нас тоже 32-битная версия Windows.
Я считаю, что было бы лучше использовать один экземпляр на сервере, включить AWE, чтобы экземпляр сервера мог использовать почти всю имеющуюся у нас оперативную память, а затем запустить каждую из баз данных в одном экземпляре.
Однако меня переубедили боги ИТ-отдела, поэтому мне очень любопытно услышать ваши мысли по этому поводу. С точки зрения производительности, я не прав, что один экземпляр SQL лучше двух?
Я знаю, что мы могли бы реализовать некоторые функции аварийного переключения, но делать это только на одном блейде мне кажется излишним.
решение1
SQL Server 2000 и 2005 Workgroup и Standard (32 бит, я не уверен насчет 64 бит) будут использовать максимум 2 ГБ памяти, поэтому наличие двух экземпляров позволит вам использовать все 4 ГБ. Это будет верно даже если вы используете 32-битный SQL Standard на x64 Windows, тем более, что вам нужен экземпляр на 2 ГБ памяти.
В принципе, использование одного экземпляра с двумя базами данных быстрее, чем два экземпляра с одной базой данных каждый, хотя я не уверен, что это огромная разница. Наличие отдельных экземпляров может быть полезно для управления. Например, если вы используете логины SQL, и есть разные наборы логинов для разных баз данных, использование отдельных экземпляров может облегчить отслеживание логинов.
Так что ответ на ваш вопрос: «Это зависит» :-)
Дж.Р.
Re Spence's comment: SQL Server Standard на 32-разрядной Windows может использовать максимум 2 ГБ памяти. SQL Server Enterprise может использовать 3 ГБ, если вы используете переключатель /3GB. В Windows 2003 Enterprise с AWE может использоваться как минимум до 16 ГБ памяти (возможно, больше), поэтому вы можете получить большую отдачу от своей памяти, запустив более одного экземпляра SQL Server.
Боюсь, ответ все еще "зависит от обстоятельств". Если у вас много памяти, например 8 ГБ или 16 ГБ, то вам следует разместить самые большие базы данных в отдельных экземплярах, чтобы они могли иметь по 2 ГБ (или 3 ГБ с /3 ГБ) каждый. Если у вас только 4 ГБ, то я бы, вероятно, использовал один экземпляр и переключатель /3 ГБ, поскольку небольшой объем дополнительной памяти, используемый двумя экземплярами, не будет стоить накладных расходов.
Как уже прокомментировали другие ниже, могут быть и другие соображения. Если вы ссылаетесь на две базы данных одновременно, например, в запросе на выборку или если вы вставляете данные из одной базы данных в другую, то вы хотите, чтобы они были в одном экземпляре для скорости.
решение2
32 бита — это тупик.
В SQL2K5 потребление памяти для таких вещей, как компиляция плана, сам размер плана и, следовательно, кэш процедур значительно увеличились по сравнению с 2k. Также другие компоненты, такие как кэш маркеров разрешений, имеют тенденцию к росту, если у вас много пользователей (т. е. крупные организации и олицетворения среднего уровня). Поскольку все это не может извлечь выгоду из AWE, вам будет трудно втиснуть загруженную систему в 32-битное пространство памяти. Если у вас сложные запросы и планы, агрегация экземпляров может привести к тому, что очень высокий процент буферного пула будет украден, чтобы эти кэши оставили небольшой буферный пул для данных, что приведет к постоянному вытеснению из кэша скомпилированных планов и низкой ожидаемой продолжительности жизни страницы.
С другой стороны, несколько экземпляров SQL на одном компьютере имеют тенденцию наступать друг другу на пятки, вызывая давление памяти друг у друга. Поскольку менеджеры памяти экземпляров не взаимодействуют друг с другом, гораздо сложнее найти равновесие по сравнению с одним экземпляром. Кроме того, планирование процессора нескольких экземпляров может страдать от аналогичных проблем, поскольку ОС будет вытеснять планировщики SQL среди экземпляров, что приведет к засорению кэша ЦП.
решение3
IMHO, я бы сказал, что вы, боги ИТ, ошибаетесь в этом. Пока нет проблем с безопасностью, которые нужно решать, имея несколько баз данных, работающих в одном экземпляре, это путь. Многоэкземплярность всегда вносит некоторые накладные расходы, которые фактически дадут вашему серверу неоптимальную производительность. С точки зрения администрирования также лучше придерживаться одного экземпляра.
решение4
Как всегда, это зависит:Понадобится ли когда-нибудь базам данных «общаться» друг с другом?
Если это для одного и того же приложения, вы часто будете сталкиваться с ситуациями, когда вам нужно, чтобы одна база данных читала или писала в другую. Если это так, то предпочтительнее две базы данных на одном экземпляре. (Никаких связанных серверов, общих входов, общей tempdb — все это преимущества здесь.)
Однако если две базы данных полностью изолированы и никогда не будут взаимодействовать друг с другом и фактически не имеют друг с другом никакого отдаленного отношения (например, SharePoint и SAP), то два экземпляра могут быть предпочтительнее. (Возможность работать на разных уровнях пакетов обновления или ограничивать память, используемую одним экземпляром, — два преимущества, которые я сразу придумал.)