Настройка базы данных SQL Server с высокой нагрузкой на ЦП и активность ввода-вывода

Question

В последнее время наше приложение работает очень медленно.При отладке и трассировке выяснилось, что процесс показывает высокие циклы процессора, а SQL Server показывает высокую активность ввода-вывода.Не могли бы вы подсказать, как его можно оптимизировать?

Приложению уже около года, а размеры файлов базы данных не очень большие или что-то еще.База данных настроена на автоматическое сжатие.Он работает на win2003, SQL Server 2005 и представляет собой веб-приложение, написанное на языке c #, т.е. vs2005

Answer 1

1. дефрагментация файлов жесткого диска (или хотя бы mdf / ldf).
2. поместите файл ldf на отдельный жесткий диск, чем mdf, если это возможно
3. использовать инструмент профилирования из SQL 2005; он скажет вам, какие запросы выполняются чаще всего; затем используйте инструмент «Показать план выполнения», чтобы увидеть этапы выполнения; возможно, вы получите подсказку о том, какие индексы следует добавить; например, для больших таблиц следует избегать полного сканирования таблиц.

Answer 2

Запустите SQL Profiler в вашей базе данных на некоторое время, чтобы увидеть, вызвана ли медлительность какими-либо проблемными запросами. Затем вы можете проанализировать эти запросы, чтобы запустить любые индексы или статистику для повышения производительности.

Как следует из комментария, автоматическое сжатие может привести к очень фрагментированной базе данных. База данных, как правило, будет расти по мере необходимости, и лучше всего не беспокоиться о том, насколько она велика. Пока вы выполняете регулярное резервное копирование журнала транзакций, вам лучше позволить ему расти. Возможно, вам следует спросить себя, важнее ли производительность, чем покупать новые диски.

Вы также можете запустить некоторые планы обслуживания для базы данных, чтобы перестроить индексы и статистику. Это может решить проблемы в краткосрочной перспективе.

Answer 3

Я знаю, что этот поток был довольно долгое время, но я решил добавить свои 2 бита. У нас были проблемы на нашей производственной базе данных sql server 2005, где cpu регулярно работал на 80-100% постоянно в течение всего дня,Мы попытались выполнить трассировку, оценить задания, выполнить дефрагментацию, освободить место на диске, все, что могли придумать, но ничего не помогло.В конце мы нашли сообщение на сайте блога (боюсь, мы не помним, какой именно), которое возобновило использование функции отсутствующих индексов Sql Server.

Как оказалось, SQL Server 2005 и более поздние версии имеют эту функцию;SQL Server постоянно оценивает и записывает рекомендуемые индексы, которые, по его мнению, помогут повысить производительность.Мы запустили приведенный ниже запрос и внедрили 130 лучших индексов (те, которые показывают наибольший потенциальный выигрыш).Наша общая производительность ЦП в настоящее время снижается до 30-40% в самые загруженные часы дня, и пользователи по всему миру говорят нам, что их приложения гораздо более отзывчивы.

Несколько предостережений.Мы не администраторы баз данных, поэтому добавляем индексы на ваше усмотрение.Кроме того, добавление слишком большого количества индексов в какую-либо одну таблицу может отрицательно сказаться на производительности, поэтому следует помнить о том, какие индексы вы добавляете, и всегда следить за перегрузкой индекса.

SELECT mid.database_id, 
       db.name,
       migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) AS improvement_measure, 
       'CREATE INDEX [missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + CONVERT (varchar, mid.index_handle) + '_' + LEFT (PARSENAME(mid.statement, 1), 32) + ']' + ' ON ' + mid.statement + ' (' + ISNULL (mid.equality_columns,'') + CASE WHEN mid.equality_columns IS NOT NULL AND mid.inequality_columns IS NOT NULL THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '') + ')' + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
       migs.*, mid.database_id, mid.[object_id]
FROM sys.dm_db_missing_index_groups mig 
INNER JOIN sys.dm_db_missing_index_group_stats migs
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details mid
    ON mig.index_handle = mid.index_handle
INNER JOIN sys.databases db
    ON mid.database_id = db.database_id
WHERE migs.avg_total_user_cost * (migs.avg_user_impact / 100.0) * (migs.user_seeks + migs.user_scans) > 10
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

Answer 4

Помимо рассмотрения проблем производительности с запросами, я бы также проверил, не слишком ли фрагментированы БД и таблицы в БД.

Вы можете выполнить оператор DBCC showcontig, чтобы проверить это. Если это показывает, что таблицы сильно фрагментированы, вам следует рассмотреть возможность создания плана обслуживания, который регулярно выполняется. В этом плане обслуживания вы должны указать, что индексы должны быть перестроены. При этом таблицы будут дефрагментированы.

Answer 5

Одна из проблем с автоматическим сжатием заключается в том, что вы не можете контролировать, когда он срабатывает, поэтому он может работать во время использования в реальном времени и заставить все замолчать.Если вы действительно хотите, чтобы ваша база данных была сокращена, составьте план обслуживания, чтобы сделать это в нерабочее время.Но я не уверен, когда вы захотите установить эту опцию, на самом деле.Если на диске достаточно места, пусть БД естественно растет.Если нет, тогда получите больше.Дисковое пространство дешево, но задержки из-за медленного приложения могут дорого обойтись.Также отключите автоматическое закрытие.

Answer 6

Также для часто используемых запросов вы можете проанализировать их с помощью оператора EXPLAIN. Это скажет вам, используются ли соответствующие индексы и сколько строк сканируется.