SQL Server 2005: Совместное использование процессоров через несколько распределенных экземпляров
Я не мечтал бы об использовании дисков SATA для сервера - ни один из них не имеет ожидаемый рабочий цикл качественного диска сервера, и у них нет богатого набора команд, который SCSI/SAS имеет для контроля производительности диска и здоровья. Серверы Lenovo являются дешевыми и большими, если у Вас есть много серверов ни с одним из них действительно настолько важный, но существует причина, что серверы HP с 300 рядами составляют 40% рынка - они работают. В особенности их дисковые контроллеры 'SmartArray' являются несравненными в надежности и производительности, и их гарантия перед отказом является желанным дополнением. Не самое дешевое, но насколько Ваше время стоит? Я покупал их (хорошо Compaq первый tbh) серверы в течение двадцати лет теперь и не имею никакой проблемы безотносительно покупки 500-800 новых в год, которые я делаю. Серьезно проверьте их.
Короткий ответ нет. Длинный ответ, да, вид. Если Вы тратите тонну времени, удостоверяясь, что Ваша база данных и приложение являются установкой для обработки этого.
Если бы необходимо было разместить ту же базу данных по обоим серверам и использовать репликацию SQL, чтобы гарантировать, что базы данных синхронизируются между ними, то Вы могли поместить подсистему балансировки нагрузки перед SQL Server и сделать, чтобы клиенты соединились с подсистемой балансировки нагрузки вместо единственного SQL Server. Однако это создает свой собственный набор проблем, которые должны быть решены сначала.
Более оптимальный вариант мог бы состоять в том, чтобы посмотреть на объединение в федерацию Вашей базы данных так, чтобы половина данных была сохранена на каждом сервере, и данные запрашиваются с сервера, который содержит те данные. Однако это - также чрезвычайно жесткая вещь получить настройки правильно.
База данных была правильно настроена так, чтобы индексы были все созданы в самой лучшей установке?
-
1спасибо mrdenny. мы рассмотрим некоторые из этих возможностей. наши серверы имеют большое использование и вещь, которая поднимает большую часть ресурса, полнотекстовый поиск. мы пытаемся сжать некоторую новую функциональность в наше приложение и наши серверы просто can' t берут его. насколько я знаю, что мы настроили наши базы данных в меру нашей способности. Я думаю, что мы сделаем, должен копировать базы данных и выполнять новые возможности против дублируемой базы данных только для чтения. – jensendarren 9 June 2009 в 13:15
-
2Если полнотекстовый поиск берет объем питания, то необходимо считать обновление SQL 2008. Полнотекстовый поиск был полностью переписан и намного более эффективен в SQL 2008 затем, это было прежде. – mrdenny 9 June 2009 в 22:07