Как узнать, ограничена ли производительность базы данных SQL Server аппаратно?

Тестирование приложения в настоящее время под однопользовательской нагрузкой - поскольку тестовые данные увеличились до производственных размеров (400k-2M строк на таблицу), некоторые SELECT sp больше не достаточно быстрые (с ограниченными тестовыми данными, которые раньше составляли <30 мс каждый, сейчас это 100-200 мс, но их несколько, поэтому задержка становится очевидной в пользовательском интерфейсе).

Вы можете использовать DBCC SQLPERF("waitstats"). Это вернет время ожидания тех задач, которые ожидал ваш SQL-сервер. Подробные объяснения каждого счетчика можно найти в Интернете. Вы можете использовать эту информацию, чтобы выяснить ваши узкие места.

Кроме того, включите статистику клиента в анализаторе запросов, чтобы увидеть время ожидания на стороне клиента.

Я предполагаю, что ваше оборудование не изменилось со времени вашего первоначального теста, поэтому, поскольку они постоянны, я не сомневаюсь в них.

Мысли:

• аппаратные средства почти никогда не являются проблемой: это плохой дизайн и код
• всегда проверяйте качество и количество близких к производству данных

Некоторые решения:

Запустите отсутствующий индекс DMV, чтобы увидеть отсутствующие индексы:

SELECT 
  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
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

... и самые дорогие запросы DMV

SELECT TOP 20
    qs.sql_handle,
    qs.execution_count,
    qs.total_worker_time AS Total_CPU,
    total_CPU_inSeconds = --Converted from microseconds
    qs.total_worker_time/1000000,
    average_CPU_inSeconds = --Converted from microseconds
    (qs.total_worker_time/1000000) / qs.execution_count,
    qs.total_elapsed_time,
    total_elapsed_time_inSeconds = --Converted from microseconds
    qs.total_elapsed_time/1000000,
    st.text,
    qp.query_plan
FROM
    sys.dm_exec_query_stats AS qs
        CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
        CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC

В противном случае, на этот ТАКой вопрос есть хорошие советы от меня и других высокопоставленных представителей SQL: https://stackoverflow.com/q/4118156/27535 (я не буду копировать / вставлять все 3 длинных ответа)

Зарегистрируйте системные ресурсы или посмотрите в диспетчере задач, чтобы увидеть, сколько системных ресурсов используется процессами.

Интересно отметить версию MSSQL 2000, на которой работает

Есть четыре версии двоичных файлов

1. Экспресс
2. стандарт
3. профессиональный
4. предприятие

Каждая из этих версий имеет ограничения с точки зрения оперативной памяти и процессора.

Стоит изучить возможность того, что объем хранимых в настоящее время данных просто перерос возможности возможностей версии MSSQL 2000 из-за запросов, требующих больше оперативной памяти для выполнения запросов / подзапросов, или недостаточной загрузки ЦП. Вам может потребоваться обновить бинарную версию до версии MSSQL 2000 Entrprise (вероятно, из-за того, сколько лет вашей версии MSSQL) или до лучшей версии, которую может позволить ваш бюджет.

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

Отказ от ответственности: я не администратор SQL Server