У меня есть разумный сервер, подключенный к SAN, на котором будут работать SQL-серверы для нескольких одинаковых приложений. Нет проблем с безопасностью, когда одно приложение может читать базу данных другого.
К сожалению, мы тоже используем 32-битные окна.
Я считаю, что было бы лучше использовать один экземпляр на сервере, включить AWE, чтобы экземпляр сервера мог использовать почти всю имеющуюся у нас оперативную память, а затем запустить каждую из баз данных в одном экземпляре.
Однако в этом вопросе меня отвергли боги ИТ-отдела, так что мне действительно любопытно услышать ваши мысли по этому поводу. С точки зрения производительности, ошибаюсь ли я, что один экземпляр SQL лучше двух?
Я знаю, что мы могли бы сделать кое-что по аварийному переключению, но выполнение этого только на одном блейд-сервере кажется мне излишним.
32 бит - тупик.
В SQL2K5 потребление памяти для таких вещей, как компиляция плана, сам размер плана и, следовательно, кэш процесса значительно увеличились и превысили 2 КБ. Кроме того, другие компоненты, такие как кеш токенов разрешений, имеют тенденцию к росту, если у вас много пользователей (например, большая организация и олицетворение среднего уровня). Поскольку все это не может принести пользу AWE, вам сложно разместить загруженную систему в 32-битном пространстве памяти. Если у вас есть сложные запросы и планы, агрегирование экземпляров может привести к тому, что очень высокий процент пула буферов будет украден в эти кеши, и небольшой пул буферов останется для данных, что приведет к постоянному вытеснению скомпилированных планов из кеша и малому ожидаемому времени жизни страницы.
С другой стороны, несколько экземпляров SQL в одном и том же блоке имеют тенденцию наступать друг другу на пальцы, вызывая давление памяти друг на друга. Поскольку менеджеры памяти экземпляров не взаимодействуют друг с другом, гораздо труднее найти равновесие по сравнению с одним экземпляром. Кроме того, при планировании нескольких экземпляров процессора могут возникать аналогичные проблемы, поскольку операционная система будет вытеснять планировщики SQL между экземплярами, что приводит к удалению кэша ЦП.
SQL Server 2000 и 2005 Workgroup и Standard (32-разрядная версия, я не уверен насчет 64-разрядной версии) будут использовать максимум 2 ГБ памяти, поэтому наличие двух экземпляров позволит вам использовать все 4 ГБ. Это будет верно, даже если вы используете 32-разрядный SQL Standard в x64 Windows, тем более, что вам нужен экземпляр на 2 ГБ памяти.
В принципе, использование одного экземпляра с двумя базами данных быстрее, чем два экземпляра с одной базой данных каждый, хотя я не уверен, что это огромная разница. Наличие отдельных экземпляров может быть полезно для управления. Например, если вы используете логины SQL и для разных баз данных существуют разные наборы логинов, использование отдельных экземпляров может упростить отслеживание логинов.
Итак, ответ на ваш вопрос: «Это зависит от обстоятельств» :-)
JR
Комментарий Рэ Спенса: 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 ГБ, поскольку небольшой объем дополнительной памяти, используемый при наличии двух экземпляров, не будет стоить накладных расходов.
Как отмечали другие ниже, могут быть другие соображения. Если вы одновременно ссылаетесь на две базы данных, например в запросе выбора или если вы вставляете данные из одной базы данных в другую, вам нужно, чтобы они находились в одном экземпляре для скорости.
ИМХО, я бы сказал, что вы, боги ЭТОГО, ошиблись в этом. Пока нет проблем с безопасностью, которые нужно решать при наличии нескольких баз данных, работающих в одном экземпляре, это правильный путь. Мультиэкземплярность всегда приводит к некоторым накладным расходам, что фактически снижает производительность вашего сервера. С точки зрения администратора тоже лучше придерживаться одного экземпляра.
Одним из преимуществ использования нескольких экземпляров является то, что он эффективно масштабирует вашу базу данных tempdb, что может повысить производительность, если ваше приложение интенсивно использует базу данных tempdb и у вас есть база данных tempdb каждого экземпляра на разных шпинделях.
Как всегда, это зависит от: Придется ли когда-нибудь базам данных «разговаривать» друг с другом?
Если это для одного и того же приложения, вы часто будете сталкиваться со случаями, когда вы хотите, чтобы одна база данных читала или записывала в другую. В этом случае предпочтительнее использовать две БД в одном экземпляре. (Отсутствие связанных серверов, общие учетные записи, общая база данных tempdb - все это преимущества.)
Если, однако, две базы данных полностью изолированы и никогда не будут связываться друг с другом и фактически не имеют ничего общего друг с другом удаленно (например, SharePoint и SAP), тогда предпочтительнее использовать два экземпляра. (Возможность работать с разными уровнями пакетов обновления или ограничивать память, используемую одним экземпляром, - это два невероятных преимущества.)
У нас есть приложение, использующее большие и сложные хранимые процедуры, которые инкапсулируют большую часть нашей бизнес-логики.
Наши машины работают с 32-битными окнами. Раньше наш бэкэнд состоял из экземпляра sql с несколькими базами данных.
Теперь мы перешли к архитектуре, в которой у нас есть несколько экземпляров на сервере.
Производительность нашего приложения ужасно упала в тот же день, когда мы тестировали его на новой платформе, и время ожидания большинства наших форм (особенно тех, которые извлекают данные из больших сложных хранимых процессов) истекло.