Ускорение работы MS SQL 2005
Хочешь сказать как MS SQL установил, по умолчанию она идеально должна работать? (если конечно БД спроектирована грамотно)
Практически да. Можно попробовать поиграться с настройками буферов сортировки, хэширования, кэша страниц и т.п. Но перед началом тюнинга надо, естественно, понять, из-за чего тормоза (а причины могут быть очень разные). Более детальных советов дать не могу, т.к. работаю с Oracle.
см. http://technet.microsoft.com/ru-ru/library/ms189081.aspx
http://www.citforum.ru/database/sqlserver.shtml
З.Ы. На нашем сервере иногда творятся чудеса: в один день обрабатывает 1000 записей около получаса, а на другой день таже операция занимает около секунды. О чём это говорит? Что план запроса неустойчивый? Если да, то как сделать его более устойчивым?
ЗЫ:rolleyes:просматривала записи и обнаружила, что тут ответ не указала.
общая рекомендация на будущее от ДБА разработчикам:
такой подход в корне не верен для любой БД. особенно для таких мощных агрегатов, как MS SQL или Oracle. если у СУБД начального уровня установка некоторых переменных, не включенных по умолчанию, может дать прирост производительности (и то - не факт), то лезть в потроха MS SQL - не нужно.
сначала - смотрим на запросы. частые ошибки - неправильное использование индексов, неправильное проектирование структуры таблиц (пересечение таблиц по строковым полям, например. ужас), неправильное построение запросов (некоторые жутко любят злоупотреблять JOIN'ами) и. т.п.
также смотрим на общее состояние ОС. дисковая подсистема - частая причина тормозов.
а уж тонкий тюнинг СУБД - последнее дело.
общая рекомендация на будущее от ДБА разработчикам:
такой подход в корне не верен для любой БД. особенно для таких мощных агрегатов, как MS SQL или Oracle. если у СУБД начального уровня установка некоторых переменных, не включенных по умолчанию, может дать прирост производительности (и то - не факт), то лезть в потроха MS SQL - не нужно.
сначала - смотрим на запросы. частые ошибки - неправильное использование индексов, неправильное проектирование структуры таблиц (пересечение таблиц по строковым полям, например. ужас), неправильное построение запросов (некоторые жутко любят злоупотреблять JOIN'ами) и. т.п.
также смотрим на общее состояние ОС. дисковая подсистема - частая причина тормозов.
а уж тонкий тюнинг СУБД - последнее дело.
Насколько я знаю, для Oracle это часто рассматривается как задача Oracle support. Есть некоторые параметры инициализации инстанса сервера, которые следует включать только по их прямой рекомендации, когда вы им опишете свою ситуацию, предоставите все данные, и они ее изучат.
А так полностью согласен - подавляющее большинство сложностей - сложности двух видов.
Первые решаются часто рассмотрения плана запросов и принятием нужных действий - нужные индексы, разумная денормализация и нормализация, партишининг (для оракла) и прочее. (примечание - такие вещи, как схема партишененга, должны быть решены на уровне архитектурного решения).
Вторые - когда просто объективно требуется нарастить аппаратные мощности.