INF: Оптимизация производительности Microsoft SQL Server

Переводы статьи Переводы статьи
Код статьи: 110352 - Vizualiza?i produsele pentru care se aplic? acest articol.
Развернуть все | Свернуть все

В этой статье

Аннотация

Чтобы наиболее эффективно оптимизировать производительность Microsoft SQL Server, необходимо Определите области, которые имеют наибольшее увеличение производительности по сравнению с большое количество ситуаций и анализа фокус в этих областях. В противном случае могут тратить немало времени и усилий на разделы, в которых может не выдавать масштабируемые улучшений.

В большинстве случаев не предусматривает следующие сведения проблемы с производительностью, исходящие из многопользовательской параллелизма. Это отдельные, сложные раздел, в котором приведена в документе "Развертывание Согласованность и параллелизма, базы данных"которого могут быть найдены в SQL Server версия 4.2 x «Справочник по программированию на C,» в приложении E, а также в других Статьи базы знаний. Он не находится в документации версии 6.0, но можно найти на компакт-ДИСК MSDN (Microsoft Developer Network) Заголовок.

Вместо теоретического обсуждения, данная статья посвящена главным образом области, которые имеет многолетний опыт группой технической поддержки Microsoft SQL Server показано, как практическое значение в реальных ситуациях.

Опыт показывает, что максимальную выгоду в производительности SQL Server может быть получивший из общих областей логическая схема базы данных, проектирование индекса Конструктор запросов и разработки приложений. И наоборот крупнейших производительности проблемы часто причиной является недостаток информации в этих же областях. Если вы являетесь касающиеся производительности, вы должны сосредоточиться на этих областей во-первых, так как часто можно достичь очень большой производительности приложений с сравнительно небольшого времени инвестиции.

В то время как другие системного уровня производительности, такие проблемы, как память, кэш-память буферов оборудование и т.д., определенно являются кандидатами для исследования, опыт работы Показывает, что увеличение производительности в этих областях часто добавочных. SQL Сервер управляет доступных аппаратных ресурсов автоматически, для большинства часть, снижая потребность (и, следовательно, преимущества) из широко Рука системные настройки.

Microsoft SQL Server 6.0 предоставляет новые возможности для платформы слоя Повышение производительности с большими объемами памяти, симметричная многопроцессорные системы, параллельных данных сканирования, оптимизатор усовершенствования и диска чередование. Тем не менее размер, эти улучшения, они являются ограниченная в область действия. Самый быстрый компьютер может мучиться с неэффективные запросы или плохо спроектированные приложения. Таким образом, даже с дополнительной производительности Увеличьте, что позволяет SQL Server 6.0 очень важно для оптимизации База данных, индекс, запрос и разработки приложений.

Большинство проблем с производительностью не могут быть успешно разрешены только с фокус на сервере. Сервер является по существу «puppet» клиента, элементов управления, которые отправляются запросы и таким образом получить блокировки и освобожденных. Несмотря на то, что некоторые СУБД возможности на стороне сервера обычно будет зависеть успешное разрешение проблем с производительностью Подтверждение роли главного клиента звукозаписей с ошибкой и Анализ поведение клиентского приложения.

Дополнительная информация

Ниже приведены некоторые рекомендации, основанные на возникают, было высокую производительность.

Нормализация логической модели базы данных

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

Среди преимуществ нормализации:
  • Ускоряется сортировка и создание индексов, поскольку таблицы являются более узкой.
  • Позволяет более кластеризованные индексы, поскольку существует несколько таблиц.
  • Индексы имеют тенденцию быть более коротким и более компактный.
  • Меньшее количество индексов в таблице, помогая производительности обновления.
  • Меньшее количество значений NULL и менее избыточных данных, повышая компактность базы данных.
  • Уменьшает воздействие параллелизма диагностики DBCC, поскольку необходимые блокировки таблицы повлияет на меньшее количество данных.
С SQL Server Рациональная нормализация часто помогает, а не вредит производительность. Делать с увеличением нормализации количество и сложность соединений, необходимых для извлечения данных. Как грубая эмпирическое правило, корпорация Майкрософт предлагается только в этом случае многие на хранение на процесс нормализации запросы соединения четырехсторонняя или выше.

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

Проектирование эффективного индекса с помощью

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

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

Ниже приведены рекомендации по проектированию индекса.
  • Изучите предложения WHERE SQL-запросов, так как это Основной целью оптимизатора.

    Каждый столбец в предложение WHERE является потенциальным кандидатом индекс. При наличии большого количества запросов для проверки выберите представителя набор или медленно менять. Если средство разработки незаметно для пользователя Создает код SQL, это более сложная задача. Многие из этих средств разрешить ведение журнала синтаксиса SQL, созданный файл или экран в целях отладки. Необходимо узнать у поставщика инструмента, если Такая возможность доступна.
  • Используйте узкие индексы.

    Узкие индексы, обычно более эффективны, чем с несколькими столбцами, составные индексы. Узкие индексы имеют несколько строк на страницу и меньшее количество уровней индекса Повышение производительности.

    Оптимизатор может быстро и эффективно анализировать несколько сотен или даже тысячи, индекс и объединения возможностей. Наличие большего числа Узкие индексы предоставляет оптимизатору больше возможностей для выбора который обычно позволяет повысить производительность. Наличие меньше ширины, с несколькими столбцами предоставляет индексов оптимизатор с меньшим количеством вариантов для выбора, что может привести к снижению производительности.

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

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

    Правильное использование кластеризованных индексов очень можно увеличить производительность. Операций даже UPDATE и DELETE часто приводит к ускорению кластеризованные индексы, поскольку эти операции требуют много чтения. A разрешены один кластеризованный индекс для каждой таблицы, поэтому разумно использовать этот индекс. Запросы, возвращающие несколько строк или запросов, включающих диапазон значения, являются хорошими кандидатами ускорение с кластеризованным индексом.

    Примеры:
          SELECT * FROM PHONEBOOK
          WHERE LASTNAME='SMITH'
    
          -or-
    
          SELECT * FROM MEMBERTABLE
          WHERE  MEMBER_NO > 5000
           AND MEMBER_NO < 6000
    
    						
    В отличие от упомянутых выше столбцов LASTNAME или MEMBER_NO являются вряд ли разумно некластеризованного индекса, если данный тип запрос является наиболее распространенным. Попробуйте использовать некластеризованные индексы для столбцов, где несколько строки возвращаются.
  • Проверьте уникальность столбцов.

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

    Ниже приведен пример запроса для проверки уникальности столбца.
          SELECT COUNT (DISTINCT COLNAME)
          FROM TABLENAME
    
    						
    Возвращает количество уникальных значений в столбце. Для сравнения Общее число строк в таблице. В таблице 10 000 строк, 5000 уникальные значения бы сделать столбец подходящим кандидатом для некластеризованных индекс. На той же таблице 20 уникальных значений бы удовлетворения кластеризованный индекс. Три уникальных значений вообще не должны индексироваться. Это только примеры не жестких и четких правил. Не забудьте поместить индексы отдельные столбцы, перечисленные в предложениях WHERE запросов.
  • Проверьте распределение данных в индексированных столбцах.

    Часто длительное выполнение запроса возникает, если столбец с минимальными уникальный Индекс значения или выполняется ОБЪЕДИНЕНИЕ такого столбца. Это Фундаментальная проблема, связанная с данными и сам запрос и обычно не Разрешить без определения ситуации. Например физические телефонный справочник, отсортированный в алфавитном порядке по фамилии, не сможет быстро Поиск человека, если всех жителей города называются просто «Иванов» или «Иванов». В дополнение к выше запрос, который дает один рисунок для уникальность столбцов запроса GROUP BY можно использовать для просмотра данных Распределение индексированными значениями ключа. Это обеспечивает более высокий разрешение рисунка данных и аппаратуры для как оптимизатор представления данных.

    Ниже приведен пример запроса Проверьте распределение данных Индекс значения ключей, при условии, что два столбца ключа на COL1, COL2:
          SELECT COL1, COL2, COUNT(*)
          FROM TABLENAME
          GROUP BY COL1, COL2
    
    						
    Это возвращает одну строку для каждого значения ключа, подсчет экземпляров каждого значения. Чтобы уменьшить количество возвращаемых строк, может быть полезным исключить с помощью предложения HAVING. Например предложение
          HAVING COUNT(*) > 1
    
    						
    исключает все строки, которые имеют уникальный ключ.

    Число строк, возвращаемых в запросе также является важным фактором в Выбор индекса. Оптимизатор пользуется некластеризованный индекс затрат по крайней мере одна страница ввода-вывода на возвращенную строку. На данной скорости быстро становится более эффективное сканирование всей таблицы. Это еще одна причина для ограничить размер результирующего набора или для обнаружения больших результатов с помощью кластеризованный индекс.
Не всегда означает использование индексов с хорошей производительностью и наоборот. Если с помощью индекса всегда создаются наилучшей производительности, оптимизатор Задание было бы очень простой - всегда использовать любой доступный индекс. На самом деле, Неправильный выбор индексированного извлечения может привести к очень плохой производительностью. Поэтому задача оптимизатора является выбор индексированного извлечения где будет Справка производительность и избежать индексированного поиска, где он будет повредить производительность.

Проектирование эффективных запросов с помощью

Некоторые типы запросов по своей природе являются вычислительных ресурсов. Это относится к фундаментальные и базы данных индекса проблемы, общие для наиболее реляционной системы управления (RDBMS), не только к SQL Server. Они не неэффективным, так как оптимизатор будет реализовывать запросы в наиболее эффективным способом невозможно. Тем не менее, они являются ресурсоемкими и SET ориентированная природа SQL может сделать их неэффективным. Нет степень Логика оптимизатора можно избежать затрат ресурсов неизбежно этих конструкции. Они являются внутренне дорогостоящим по сравнению с более простой запрос. Несмотря на то, что SQL Server использует оптимальный план доступа, это по существу возможности ограничено.

Например:
  • Больших результирующих наборов
  • IN, NOT IN или запросов
  • Высоко неуникальные предложения WHERE
  • ! = операторы сравнения (не равно)
  • Некоторые функции столбца, такие как SUM
  • Преобразования данных или выражения в предложении WHERE
  • Локальные переменные в предложении WHERE
  • Сложные виды предложением GROUP BY
Различные факторы могут требующий использовать некоторые из этих конструкций запросов. Влияние этих будет выполняется вовсе, если оптимизатор может ограничить результирующий набор до применения интенсивных ресурсов часть запроса. В Ниже приведены некоторые примеры.

Интенсивного использования ресурсов:
   SELECT SUM(SALARY) FROM TABLE
				

Менее интенсивно.
   SELECT SUM(SALARY) FROM TABLE WHERE
   ZIP='98052'
				

Интенсивного использования ресурсов:
   SELECT * FROM TABLE WHERE
   LNAME=@VAR
				

Менее интенсивно.
   SELECT * FROM TABLE
   WHERE LNAME=@VAR AND ZIP='98052'
				

В первом примере невозможно ускоренной СУММУ операции с индекс. Каждая строка должна читать и суммировать. Предполагается, что в предметный указатель столбец ZIP, оптимизатор будет скорее всего используется для первоначально ограничить результирующий набор до применения СУММЫ. Это может быть намного быстрее.

Во втором примере локальная переменная не разрешается только во время выполнения. Однако оптимизатор невозможно отложить Выбор плана доступа до запуска время; он должен выбрать во время компиляции. Еще во время компиляции когда доступ создан план, значение @ VAR неизвестна и поэтому не может быть используется в качестве входных данных для индекса выделенной области.

Показанный метод для улучшения ограничивается в результате Установка с использованием предложения AND. Как альтернативный способ с помощью хранимой процедуры и передачи значения для @ VAR в качестве параметра в хранимую процедуру.

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

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

Используйте эффективное проектирование приложений

Роль, которую играет Разработка приложений в производительности SQL Server не может быть overstated. Вместо рисунка на сервер в роли главного больше точное изображение как контролирующий сущности и сервер в качестве клиента puppet клиента. SQL Server используется в разделе команды клиента что касается запросов, при их передаче и как результаты Обработка. Это в свою очередь имеет основной влияет на тип и продолжительность блокировки, объем ввода/вывода и Процессора нагрузку на сервер и, следовательно ли производительность хорошего или плохого.

По этой причине важно принимать правильные решения во время Этап разработки приложения. Однако даже если у вас могут возникнуть проблемы с производительностью с помощью готовых приложений, где кажется, изменения в клиентские приложения невозможно, это не изменяет основные факторы, которые могут повлиять на производительность – а именно, клиент играет роль главного и многие проблемы производительности не могут быть разрешены без внесения изменений клиента.

С помощью хорошо разработанные приложения SQL Server может поддерживать тысячи параллельных пользователей. С помощью плохо разработанные приложения даже самые мощные серверной платформы может bog с лишь несколько пользователи.

Используя приведенные ниже предложения для разработки клиентских приложений будет предоставлять Хорошая производительность SQL Server:
  • Используйте небольшие результирующие наборы. Извлечение слишком большие результирующие наборы (например, из тысячи строк) для просмотра на клиентском компьютере добавляет ЦП и сетевой нагрузки ввода-вывода, делает меньшими возможностями удаленного использования приложения а можно ограничить многопользовательской масштабируемости. Лучший Дизайн приложение предлагает пользователю достаточно ввести данные таким образом, запросы При отправке, которые создают скромные результирующих наборов.

    Методы разработки приложений этого: ограничение Использование подстановочных знаков при построении запросов, поддерживания определенных входных данных поля и prohibiting improvised запросов.
  • Правильное использование dbcancel() в приложениях DB-Library. Все приложения следует разрешать отмену запроса в процессе выполнения. Приложение, необходимо предложить пользователю перезагрузить клиентский компьютер для отмены запроса. Не После этого принципа может привести к проблемам производительности, которые не могут быть Разрешить. При использовании dbcancel() необходимо охвачены соответствующие меры что касается уровня транзакции. Для получения дополнительных сведений обратитесь к следующие статьи базы знаний Майкрософт:
    117143: INF: когда и как использовать dbcancel() или sqlcancel()
    Такие же проблемы появляются в приложениях ODBC, если ODBC sqlcancel() вызов будет использован.
  • Всегда обрабатывать все результаты до завершения. Не создавать приложения или использование готового приложения, которое прекращает обработку строк без Отмена запроса. При этом будет обычно привести к блокировке и медленно производительность.
  • Всегда реализуют время ожидания запроса. Не разрешать выполнение запросов неограниченное время. Сделать соответствующие библиотеки DB или ODBC вызывает для установки время ожидания запроса. В DB-Library это делается с помощью вызова dbsettime() и в ODBC с SQLSetStmtOption().
  • Не используйте средства разработки приложений, которая не позволяет явный контроль над инструкций SQL, отправляемых на сервер. Не задан Используйте средство для создания инструкции SQL на основе более прозрачным объекты уровня, если он не предоставляет важные функции, такие как запрос отмену, время ожидания запроса и полный контроль транзакций. Он является Часто невозможно, для поддержания хорошей производительности или для решения проблемы производительности, если приложение по себе создает «прозрачный SQL», поскольку это не позволяет явный контроль над транзакций и блокировки проблем, которые критичны к производительности рисунок.
  • Не смешивается оперативной обработки транзакций и поддержки принятия решений Запросы (OLTP).
  • Не разрабатывать приложения и использование готового приложения, которое заставляет Перезагрузите клиентский компьютер для отмены запроса пользователя. Это может привести к различные проблемы с производительностью, которые трудно решить, так как потерянные возможных соединений. Для получения дополнительных сведений см. следующие статьи базы знаний Майкрософт:
    137983: Восстановление потерянных подключений в SQL Server

Методы для анализа низкой производительности

Может показаться соблазнительным для решения проблемы с производительностью исключительно на уровне системы Повышение производительности сервера. Например объем памяти, тип файла системы, количество и тип процессора и т. д. Опыт Microsoft SQL Server поддержку показало, что большинство проблем с производительностью не могут быть решены этим путем. Должны быть решены путем анализа приложения, приложения отправки в базу данных, запросы и как эти запросы взаимодействуют со схемой базы данных.

Во-первых Изолируйте запрос или запросы, которые выполняются медленно. Часто оказывается, всего приложения выполняется медленно, когда только небольшая часть SQL-запросов выполняются медленно. Обычно это не позволяет решить проблему производительности без разбить проблемы и изоляция медленных запросов. Если у вас есть средство разработки, который явно создает SQL, используйте любое доступное диагностические или режиме отладки программы для захвата сформированного кода SQL. Во многих функции трассировки случаях доступны, но они могут не быть задокументированы открыто. Обратитесь в службу технической поддержки для приложения, чтобы определить, если трассировка Существует возможность для наблюдения за инструкций SQL, создаваемые приложения.

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

Если приложения конечным пользователем или средство разработки не поддерживает трассировку функция, существует несколько альтернативных вариантов:
  • С помощью флага трассировки 4032 в соответствии с инструкциями в SQL Сервер 4,2 x «Поиск и устранение неисправностей» и SQL Server версии 6.0 «Ссылка на transact-SQL». Это позволит захвата инструкций SQL отправляются на сервер, в журнале ошибок SQL.
  • Мониторинг запросов через сетевой анализатор, такой как сеть корпорации Майкрософт Монитор является частью Systems Management Server.
  • Для приложений ODBC с помощью программы Администратор ODBC Выбор Трассировка вызовов ODBC. Для получения дополнительных сведений в документации ODBC.
  • Используйте клиентские программы независимых производителей, что перехватывает SQL в Слои ODBC или DB-Library. Примером этого является инспектор SQL от синего Lagoon программное обеспечение.
  • Средство SQLEye анализа предоставляется в качестве примера в корпорации Майкрософт Компакт-ДИСК TechNet. Примечание: SQLEye не поддерживается в корпорации Майкрософт Поддержка.
После медленного запроса является изолированной, выполните следующее:
  • Запуск подозрительных медленного запроса в изоляции, например с помощью средства запросов ISQL и убедитесь, что будет происходить очень медленно. Часто лучше выполнить запрос сам компьютер сервера с помощью ISQL и локальных каналов и перенаправления выходной файл. Это помогает избежать complicating факторов, таких как сети и экран ввода/вывода и буферизация результирующего приложения.
  • Используйте SET STATISTICS IO на для проверки ввода-вывода, используемых в запросе. Обратите внимание, значение счетчика логического вывода страниц. Оптимизатор стремится свести к минимуму число ввода-вывода. Сделайте запись логических счетчика ввода/вывода. Это формирует базовый уровень, с которого для улучшения измерения. Часто бывает более эффективно сосредоточиться исключительно на Вывод STATISTICS IO и Экспериментируйте с различными типами запросов и индексации, чем SET SHOWPLAN Д. Интерпретация и эффективного применения выходные данные инструкции SHOWPLAN можно необходимы некоторые изучить и требует времени, которое может быть более эффективно затраченное на эмпирический тестов. Если проблема производительности не устранены Эти простые рекомендации, то можно использовать инструкции SHOWPLAN для более тщательно Исследуйте поведение оптимизатора.
  • Если запрос включает в себя представление или хранимая процедура, извлечь из запроса представление или хранимую процедуру и выполнить его отдельно. Это позволяет план доступа для изменения во время экспериментов с различными индексами. Он также помогает локализовать проблемы на сам запрос, а не как оптимизатор обрабатывает представлений или хранимых процедур. Если проблема не в запросе сам но только в случае запрос будет выполняться как часть представления или хранятся процедуры, выполнение запроса само по себе поможет определить это.
  • Имейте в виду возможное триггеров на связанные таблицы, которые можно прозрачно создайте ввода-вывода во время выполнения триггера. Следует удалить все триггеры, связанные с медленной работе запроса. Это помогает определить неполадки является в запросе, триггера или представления и поэтому позволяет Направьте ваш фокус.
  • Проверка индексов таблиц, используемых при медленной работе запроса. Использование перечисленных выше способов определить, являются ли они хорошо индексов и При необходимости измените их. Как первый усилия попробуйте индексирования в каждом столбце в предложении WHERE. Часто проблемы с производительностью вызываются не просто у столбца в предложении WHERE проиндексированы, при этом нет необходимости использовать индекс такого столбца.
  • С помощью запросов, которые ранее уже упоминалось, проверить уникальность данных и для каждого столбца, указанных в предложении WHERE, распределения и особенно для каждого индексированного столбца. В многих случаях Простой осмотр запрос, таблицы, индексы и данные немедленно Показать проблемы Причина. Например, проблемы с производительностью часто вызванных Индекс ключа с помощью только три или четыре уникальных значений или выполнения ПРИСОЕДИНЕНИЯ такого столбца или возвращение чрезмерное количество строк клиент.
  • На основе этого исследования, внести необходимые изменения в приложение запроса, или индексы. Выполните запрос еще раз после внесения изменений и обратите внимание на любое изменение в количество ввода-вывода.
  • После заметить улучшение выполнения основного приложения на наличие общей производительность, тем лучше.
Проверьте настройки программы для ввода-вывода или ЦП поведения. Часто полезно для Определяет, является ли запрос ввода-вывода или связанным с НИМ. Это позволяет сосредоточиться на улучшение усилия на true, узким местом. Например если запрос ЦП связан, Добавление памяти SQL Server вряд ли улучшить производительность, Поскольку память только повышает эффективность работы кэш-памяти, который в данном случае уже высокий.

Как проверить поведение ввода/вывода и ЦП запроса:
  • С помощью системного монитора Windows NT для наблюдения ввода/вывода и ЦП. Смотреть все экземпляры счетчика «% активности диска» логический диск объект. Также смотреть "% общего времени процессора" счетчик системы объект. Чтобы просмотреть сведения о производительности допустимый диск, необходимо иметь ранее включен параметр DISKPERF Windows NT, выполнив "diskperf -Y» из командной строки, а затем перезагружать систему. Обратитесь к документации Windows NT для получения дополнительных сведений.
  • При выполнении запроса, если постоянно высокое (для графика ЦП Например, более 70 процентов), и значение «% активности диска» постоянно низкий уровень, это указывает на состояние ЦП.
  • При выполнении запроса, если граф ЦП постоянно низкий (для Например, менее 50 процентов), и постоянно «% активности диска» Высокая, указывает связанный ввод-вывод состояния.
  • Сравните граф ЦП с информацией STATISTICS IO.

Заключение

SQL Server может очень высокую производительность для больших баз данных. Это особенно в случае с SQL Server версии 6.0. Этот уровень производительности потенциальные, необходимо использовать эффективные базы данных, индекс, запрос и приложения Дизайн. Эти области являются наиболее подходящих для получения значительного Улучшение производительности. Попробуйте сделать настолько эффективна, насколько это возможно, каждый запрос Таким образом, когда приложения масштабируются для нескольких пользователей, коллективном сетевой нагрузки устойчивой. Исследование поведение клиентского приложения запросы, предоставленных приложением и экспериментирования с индексами используя рекомендации в данном документе, настоятельно рекомендуется. Методическим подход при анализе проблем производительности часто приносит значительные улучшения для сравнительно немного времени инвестиции.

Свойства

Код статьи: 110352 - Последний отзыв: 1 июня 2011 г. - Revision: 4.0
Информация в данной статье относится к следующим продуктам.
  • Microsoft SQL Server 4.21a Standard Edition
  • Microsoft SQL Server 6.0 Standard Edition
  • Microsoft SQL Server 6.5 Standard Edition
Ключевые слова: 
kbinfo kbother kbmt KB110352 KbMtru
Переведено с помощью машинного перевода
ВНИМАНИЕ! Перевод данной статьи был выполнен не человеком, а с помощью программы машинного перевода, разработанной корпорацией Майкрософт. Корпорация Майкрософт предлагает вам статьи, переведенные как людьми, так и средствами машинного перевода, чтобы у вас была возможность ознакомиться со статьями базы знаний KB на родном языке. Однако машинный перевод не всегда идеален. Он может содержать смысловые, синтаксические и грамматические ошибки, подобно тому как иностранец делает ошибки, пытаясь говорить на вашем языке. Корпорация Майкрософт не несет ответственности за неточности, ошибки и возможный ущерб, причиненный в результате неправильного перевода или его использования. Корпорация Майкрософт также часто обновляет средства машинного перевода.
Эта статья на английском языке:110352
Заявление об отказе относительно содержимого статьи о продуктах, поддержка которых прекращена
Эта статья содержит сведения о продуктах, поддержка которых корпорацией Майкрософт прекращена. Поэтому она предлагается как есть и обновляться не будет.

Отправить отзыв

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com