ІНСТРУКЦІЇ. Виправлення неполадок у роботі застосунків із SQL Server

Переклади статей Переклади статей
Номер статті: 224587 - Показ продуктів, яких стосується ця стаття.
Розгорнути все | Згорнути все

На цій сторінці

ПІДСУМКИ

У цій статті описуються кроки виправлення проблем продуктивності сервера SQL Server. Виправлення проблем продуктивності включає кроки для виявлення та визначення причини уповільнення застосунку. До можливих причин відносяться:
  • блокування;
  • конфлікт системних ресурсів;
  • проблеми розробки застосунку;
  • певний набір запитів або збережених процедур з тривалим часом виконання.
У цій статті описується визначення джерела проблеми продуктивності. Стаття також містить посилання на інші статті бази знань Microsoft Knowledge Base, в яких описуються деталі певних неполадок продуктивності, які можуть бути гориснимидля додаткового виправлення проблем.

SQL Profiler


SQL Profiler — це потужний засіб усунення проблем продуктивності роботи застосунку з SQL Server 7.0 або новішої версії. SQL Profiler дозволяє легко фіксувати всі події, які виникають на сервері зі звичайним навантаженням, та надає відомості про них. Використання SQL Profiler разом з Microsoft Windows NT Performance Monitor та деякими простими запитами для виявлення блокувань, забезпечить відомості, потрібні для вирішення більшості проблем продуктивності.

Що спостерігати

1. Налаштуйте SQL Profiler для запису трасування. Для цього виконайте такі дії:
  1. Відкрийте SQL Profiler.
  2. У меню Сервіс виберіть команду Параметри.
  3. Переконайтеся, що включені параметри Всі класи подій та Всі стовпці даних.
  4. Натисніть кнопку OK.
  5. Створіть нове трасування.
  6. В меню Файл виберіть команду Створити, а потім виберіть Трасування.
  7. На вкладці Загальні вкажіть ім'я трасування та файл, в який необхідно записувати дані.
  8. На вкладці Події додайте до трасування наступні типи подій:

    Згорнути цю таблицюРозгорнути цю таблицю
    ЗаголовокПодіяОпис
    КурсориCursorPrepareЦя подія вказує, що курсор у SQL підготовлено з використанням ODBC, OLEDB або DB-бібліотеки.
    Помилка та попередженняMissing Column StatisticsЦя подія вказує на те, що статистика стовпця, корисна для Optimizer, недоступна. У стовпці Text показано список стовпців з відсутньою статистикою. Ця подія разом з подією Misc: Auto-UpdateStats вказує, що параметр Auto Create Statistics було ініційовано.
    Misc.AttentionЦя подію вказує, що сигнал уваги було надіслано клієнтом.
    Misc.Auto-UpdateStatsЦя подія вказує на те, що було ініційновано операцію Auto Update Statistics.
    Misc.Exec Prepared SQLЦя подія вказує, що ODBC, OLE DB або DB-бібліотека виконала попередній оператор або оператори Transact-SQL.
    Misc.Execution PlanЦя подія показує дерево плану оператора Transact-SQL, який виконувався.
    Misc.Prepare SQLЦя подія вказує, що застосунок ODBC, OLE DB або DB-бібліотеки приготував оператор або оператори Transact-SQL для використання.
    Misc.Unprepare SQLЦя подія вказує, що застосунок ODBC, OLE DB або DB-бібліотеки не приготував оператор або оператори Transact-SQL для використання.
    SessionsConnectЦя подія вказує, що створено нове підключення.
    SessionsDisconnectЦя подія вказує, що клієнт відключився.
    SessionsExisting ConnectionЦя подія вказує, що підключення існувало під час запуску трасування SQL Profiler.
    Stored ProceduresSP: CompletedЦя подія вказує, коли завершилося виконання збереженої процедури.
    Stored ProceduresSP: RecompileЦя подія вказує, що збережену процедуру було перекомпільовано під час виконання.
    Stored ProceduresSP: StartingЦя подія вказує, коли збережена процедура почала виконання.
    Stored ProceduresSP: StmtCompletedЦя подія вказує, коли оператор у збереженій процедурі завершив виконання.
    TSQL:SQL:BatchCompletedЦя подія вказує, що пакет Transact-SQL завершено. Стовпець Text показує, який оператор виконувався.
    TSQL:SQL:StmtCompletedЦя подія вказує, що оператор Transact-SQL завершено. Стовпець Text показує, який оператор виконувався.
    TSQL:RPC:CompletedЦя подія вказує, що віддалений виклик процедури (RPC) завершено.
  9. Якщо застосунок отримує помилку переривання за часом очікування, перестає реагувати на дії користувача (зависає) або відбуваються інші події, які спричиняють невиконання операторів, також застосовуються наступні події:

    Згорнути цю таблицюРозгорнути цю таблицю
    TSQL:SQL:BatchStartingЦя подія вказує на запуск пакету Transact-SQL. Стовпець Text показує, який оператор виконується.
    TSQL:SQL:StmtStartingЦя подія вказує на запуск оператора Transact-SQL. Стовпець Text показує, який оператор виконується.
    TSQL:RPC:StartingЦя подія вказує на запуск віддаленого виклику процедури (RPC).
    Stored ProceduresSP: StmtStartingЦя подія вказує, коли оператор у збереженій процедурі починає виконуватися.


    Це допомагає визначити оператор, що виконувався, коли минув час очікування
  10. На вкладці Стовпці даних переконайтеся, що присутні наступні стовпці:

    Для SQL Server 2000

    Start Time

    End Time

    LoginSid

    SPID

    Event Class

    TextData

    IntegerData

    BinaryData

    Duration

    CPU

    Reads

    Writes

    Application Name

    NT User Name

    DBUserName


    Для SQL Server 7.0

    Start Time

    End Time

    Connection ID

    SPID

    Event Class

    Text

    Integer Data

    Binary Data

    Duration

    CPU

    Reads

    Writes

    Application Name

    NT User Name

    SQL User Name

Для отримання відомостей про використання SQL Profiler, див. інтерактивні книги SQL Server 7.0 та SQL Server 2000 Books Online.


2. Скористайтесь монітором продуктивності для отримання значень лічильників Windows NT та SQL Server. Для цього виконайте такі дії:
  1. Запустіть Windows NT Performance Monitor.
  2. В меню Вигляд виберіть команду Журнал.
  3. В меню Параметри виберіть команду Журнал.
  4. Визначте ім'я та розміщення файлу журналу для лічильників продуктивності. Можна налаштувати необхідний інтервал оновлення.
  5. В меню Правка виберіть команду Додати до журналу.
  6. Додайте всі об'єкти (об'єкти Windows NT та SQL Server).
  7. Щоб запустити журнал, в меню Параметри виберіть команду Журнал, а потім натисніть кнопку Запуск журналу.

Докладніше див. у статті бази знань Microsoft Knowledge Base:
150934 Створення журналу монітору продуктивності для усунення проблем NT (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)

3. Перевірка наявності блокування.

Щоб з'ясувати, чи відбувається блокування, запустіть збережену системну процедуру sp_who:
exec sp_who
Результат буде містити стовпець blk. Перевірте результат на наявність ненульових записів, які вказують, що є блокування. Періодично запускайте цю процедуру, коли спостерігається уповільнення продуктивності.

Примітка. Збережена системна процедура sp_who перевіряє наявність блокування. Зазвичай цих відомостей недостатньо для повного усунення проблеми блокування. Докладніше див. у статті бази знань Microsoft Knowledge Base:
251004 ІНФО: Відстеження блокування SQL Server 7.0 (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)

Запустіть застосунок зі звичайним навантаженням

Найкращий спосіб використання SQL Profiler — це відстеження даних SQL Profiler і монітору продуктивності та блокування результату у той же період часу. Цей період часу повинен містити час, коли продуктивність застосунку погіршується. Поєднання цих відомостей допоможе отримати чітку картину того, де відбувається уповільнення продуктивності.


Розгляньте результати

  1. Перевірка наявності блокування.

    Якщо стовпець blk у результаті sp_who містить ненульове значення, це означає, що спостерігається блокування системи. Якщо процеси блокують один одного, вони можуть мати довший час виконання. Докладніше див. у статті бази знань Microsoft Knowledge Base:
    224453 ІНФО: Вирішення проблем блокування SQL Server 7.0 або 2000 (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)
  2. Аналіз результатів SQL Profiler.

    Ефективний перегляд даних SQL Profiler є дуже корисним у вирішенні проблем продуктивності. Найважливішим є розуміння того, що непотрібно переглядати всі дані. Вибирайте найголовніше. SQL Profiler забезпечує можливості, які допомагають ефективно переглядати отримані дані. На вкладках Властивості (виберіть пункт Властивості в меню Файл) SQL Profiler дозволяє обмежувати відображувані дані за допомогою видалення стовпців даних або подій, групувати (сортувати) стовпці даних та застосовувати фільтри. Можна виконувати пошук цілого трасування або певного стовпця з певними значеннями (в меню Правка виберіть команду Знайти). Також можна зберегти дані SQL Profiler у таблиці SQL Server (в меню Файл виберіть пункт Зберегти як та клацніть Таблиця трасування), а потім запустіть запити SQL.

    Будьте уважні та виконуйте фільтрацію тільки збереженого файлу трасування. Якщо виконувати ці дії в активному трасуванні, є риск втратити дані, отримані з моменту запуску трасування. Спочатку збережіть активне трасування у файлі або таблиці (в меню Файл виберіть команду Зберегти як), а тоді, перш ніж продовжити, знову відкрийте файл (у меню Файл виберіть команду Відкрити). Якщо виконувати дії зі збереженим файлом трасування, фільтрація не видаляє відфільтровані дані, вони лише не відображаються. У разі потреби можна додавати та видаляти події та стовпці даних, щоб зфокусувати пошуки.

    Перший крок аналізу файлів трасування SQL Profiler щодо випадків, пов'язаних з продуктивністю, — це визначити, де відбуваються різні типи подій на сервері.

    Групування трасування за класом подій:

    a. У меню Файл виберіть команду Властивості.

    b. На вкладці Стовпці даних кнопкою ВГОРУ перемістіть Клас подій під заголовок Групи, а кнопкою ВНИЗ видаліть усі інші стовпці з-під заголовку Групи.

    c. Натисніть кнопку OK.

    Групування стовпцю класів подій показує, який тип подій відбувається на SQL Server та з якою частотою. Виконайте пошук наступних подій в цьому стовпці:

    SP:RECOMPILE

    Ця подія вказує, що збережену процедуру було перекомпільовано під час виконання. Деякі події перекомпіляції вказують, що замість виконання запитів SQL Server витрачає ресурси на їх компіляцію.

    Докладніше про усунення неполадок перекомпіляції збережених процедур див. у статті бази знань Microsoft Knowledge Base:
    243586 ІНФО: Усунення неполадок, пов'язаних із перекомпіляцією збережених процедур (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)


    Attention

    Сигнал уваги вказує, що запис було скасовано клієнтом. Зазвичай це відбувається з однієї з двох причин:

    користувач явно скасував запит або завершив застосунок;

    - або -

    завершився час очікування запиту.

    Якщо з'являються сигнали уваги, це може означати, що певні запити виконуються повільно.

    Докладніше див. у статті бази знань Microsoft Knowledge Base:
    243589 ІНСТРУКЦІЇ. Усунення неполадок запитів, що працюють повільно на SQL Server 7.0 або пізнішої версії (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)
    Щоб визначити запит, який отримав сигнал уваги, змініть трасування, щоб воно не групувалося за якимось стовпцем даних, та відфільтруйте за ідентифікатором системного процесу (SPID), який отримав сигнал (на вкладці Фільтри встановіть SPID = x). Подія SQL:StmtStarting, SQL:BatchStarting або SP:StmtStarting, яка мала місце перед сигналом уваги, є запитом, який отримав переривання за часом очікування або скасування. Щоб легко знайти подію, можна виконати пошук "Attention" у стовпці Клас події (в меню Змінити виберіть команду Знайти).

    PREPARE SQL та EXEC PREPARED SQL

    Подія Prepare SQL вказує, що застосунок ODBC, OLE DB або DB-Library підготував оператор або оператори Transact-SQL для використання. Подія Exec Prepared SQL вказує, що застосунок використовує існуючий оператор для запуску команди.

    Порівняйте кількість цих двох подій. Найкращим варіантом є підготовка оператора SQL один раз, а виконання його кілька разів. Це зберігає для Optimizer час для компіляції нового плану під час кожного виконання оператора. Тому кількість подій Exec Prepared SQL має бути значно більшою, ніж кількість подій Prepare SQL. Якщо кількість подій Prepare SQL приблизно дорівнює кількості подій Exec Prepared SQL, це означає, що застосунок не найкращим чином використовує модель "підготовка-виконання". Краще не готувати оператор, який буде виконано лише один раз. Докладніше про підготовку операторві SQL див. у розділі "Підготовка операторів SQL" в інтерактивній книзі SQL Server 7.0 Books Online.

    Якщо кількість подій Exec Prepared SQL не є від трьох до п'яти разів більше кількості подій Prepare SQL, можливо, застосунок неефективно використовує модель "підготовка-виконання". Докладніше див. у статті бази знань Microsoft Knowledge Base:
    243588 ІНСТРУКЦІЇ. Усунення неполадок продуктивності нерегламентованих запитів (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)

    У SQL Server 2000 надмірні переходи для підготовки/виконання будуть усунуті, таким чином співвідношення 1 до 3-5 вже не є обов'язковим. Однак це все одно може бути добрим правилом: спробувати та повторно використовувати план більше одного разу.

    Missing Column Statistics

    Ця подія вказує, що статистичні дані, які Optimizer міг використати для отримання кращого плану запиту, були недоступні. Це означає, що запит не має корисних індексів щонайменше в одній з використовуваних таблиць. Крім корисних індексів, SQL Server навіть не має статистичних даних щодо стовпців, які використовуються для створення ґрунтовного рішення для плану запиту. Наслідком є те, що створений план запитів може бути неоптимальним. Якщо ці події відбуваються, перегляньте запит та створений план виконання, а потім прочитайте статтю бази знань Microsoft Knowledge Base, яка містить кроки для покращення продуктивності цього запиту:
    243589 ІНСТРУКЦІЇ. Усунення неполадок запитів, що працюють повільно на SQL Server 7.0 або пізнішої версії (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)

    Під час перегляду подій Missing Column Statistics спочатку зверніть увагу на події, пов'язані з тривалими запитами. Деякі події створюються та розв'язуються автоматично за допомогою SQL Server та можуть не потребувати втручання користувача. Тому найкраща стратегія — це спочатку зосередитися на тривалих запитах, як показано далі в цій статті, та звернути увагу, чи є запити, пов'язані з подіями Missing Column Statistics.

    Якщо подій цього класу немає, наступним кроком має бути визначення, де витрачається зайвий час.

    Групування результатів трасування за тривалістю:

    a. У меню Файл виберіть команду Властивості.

    b. На вкладці Стовпці даних кнопкою ВГОРУ перемістіть Тривалість під заголовок Групи, а кнопкою ВНИЗ видаліть усі інші стовпці з-під заголовку Групи.

    c. На вкладці Події видаліть усі групи, окрім TSQL та Збережені процедури.

    d. Натисніть кнопку OK.

    За допомогою групування за тривалістю можна легко з'ясувати, які оператори, сценарії або процедури SQL запускаються найповільніше. Дуже важливо не тільки дізнатися часу, коли сталася проблема, але також отримати для порівняння відрізок часу, коли продуктивність є прийнятною. Можна фільтрувати дані за часом початку, щоб розбити трасування на розділи, коли продуктивність є прийнятною, і виділити окремий розділ, коли продуктивність є поганою. Знайдіть запити з найбільшою тривалістю, коли продуктивність є прийнятною. Імовірно, вони є джерелом проблеми. Якщо загальна продуктивність система зменшилася, навіть звичайні запити можуть бути тривалими, тому що вони очікують на системні ресурси.

    Якщо кількість запитів з довгою тривалістю невелика, див. статтю бази знань Microsoft Knowledge Base:
    243589 ІНСТРУКЦІЇ. Усунення неполадок запитів, що працюють повільно на SQL Server 7.0 або пізнішої версії (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)
    Якщо тривалість окремих запитів невелика, але їх декілька, та лічильник Компіляцій SQL/сек у результатах монітору продуктивності (описано далі) має велике значення, див. статтю бази знань Microsoft Knowledge Base:
    243588 ІНСТРУКЦІЇ. Усунення неполадок продуктивності нерегламентованих запитів (Це посилання може вказувати на матеріали, повністю або частково викладені англійською мовою.)
    Перевірка інших стовпців даних:

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

    Якщо використання ЦП інтенсивне, виконайте групування за цим параметром, щоб побачити, які запити найбільше використовують час ЦП. Виконайте пошук операцій "hash" або "merge" у стовпці Text, щоб визначити, який план виконання запиту використовується цими типами з'єднання. Вони більше використовують ЦП та пам'ять, ніж з'єднання вкладеного циклу, яке зазвичай більше використовує ввод/вивід.

    Якщо дисковий ввод/вивід є вузьким місцем, виконайте групування за допомогою операцій читання та запису. Перегляньте поля Application Name, NT User Name та SQL User Name, щоб виділити джерело тривалих запитів.

    Стовпець IntegerData події виключення визначатиме помилки, які було повернуто клієнту. Текст повідомлення про помилку можна знайти за допомогою номеру в інтерактивній книзі SQL Server 7.0 Books Online.

    Поле Connection ID допомагає переконатися, що переглядаються однакові сеанси для певного клієнта. Параметр SPID не може цього гарантувати, тому що користувач може відключитися, а новий користувач підключитися і отримати таке ж значення SPID.

    Користь від цих полів може бути різною, залежно від ситуації, але необхідно перевірити ці поля, якщо обов'язкові поля, описані вище в цій статті, не дають відповіді.
  3. Перевірка результатів монітору продуктивності.

    Монітор продуктивності покаже всі вузькі місця системи. Можливо, що SQL Server та застосунок працюють належним чином, але комп'ютеру не достає потужності, пам'яті або інших ресурсів. Або певні лічильники вказують на проблеми під час роботи застосунку та SQL Server. Як мінімум, перевірте наступні лічильники:

  • Об'єкт: Процес

    Лічильник: Процесор

    Екземпляр: SQL Server

  • Об'єкт: Процесор

    Лічильник: % часу процесора

    Екземпляр: Перевірте кожний екземпляр процесора

  • Об'єкт: Фізичний диск

    Лічильник: Середня довжина черги дисків

    Екземпляр: Перевірте кожний екземпляр фізичного диску

  • Об'єкт: SQL Server: статистика SQL

    Лічильник: Компіляцій SQL/сек
Шукайте тенденції в межах періоду часу, коли продуктивність погіршилася: що збільшилося спочатку? Який ресурс є найбільш дефіцитним на комп'ютері: процесор або дисковий ввод/вивід? Ці відомості разом з результатами Profiler, описаними вище, допоможуть звузити проблемні області. Велика кількість проблем з процесором може вказувати на велику кількість перекомпіляцій збережених процедур, компіляцій нерегламентованих запитів або інтенсивного використання операцій з'єднань. Щоб визначити правильний напрям дій, перегляньте статті, на які є посилання в цій статті. Велика довжина черг диску може вказувати на недостатню кількість системної пам'яті або необхідність покращити дискову підсистему.

Властивості

Номер статті: 224587 - Востаннє переглянуто: 29 грудня 2007 р. - Редакція: 4.1
ЗАСТОСОВУЄТЬСЯ ДО:
  • Microsoft SQL Server 7.0 Standard Edition
Ключові слова: 
kbhowto kbhowtomaster kbinfo kbproductlink KB224587

Надіслати відгук

 

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