SQL Profiler вирішує проблеми

Іцик Бен-Ган, Журнал «SQL Magazine OnLine»

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

У статті «Спіймай подія», опублікованій у попередньому номері журналу, описувалася архітектура системи трасування SQL Server 7.0 і було показано, як графічно задати трасу в SQL Profiler. На цей раз мова піде про те, як за допомогою SQL Profiler відтворювати траси, і як через розширені процедури трасування визначати автоматичний старт. Грунтуючись на такому потужному фундаменті, ви зможете зі знанням справи застосовувати SQL Profiler і збережені процедури для найрізноманітніших досліджень, починаючи з довго виконуються запитів і закінчуючи складними тупиковими блокуваннями.

Попередня підготовка до відтворення траси

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

При будь-якому повторному прогоні потрібно фіксувати події Connect, Disconnect, ExistingConnection, а також RPC: Starting і SQL: BatchStarting. Крім того, при відтворенні курсорів API серверної частини (Тобто курсорів сервера, які управляються функціями курсору API) необхідно фіксувати події CursorExecute, CursorOpen і CursorPrepare. Для відтворення підготовлених операторів SQL серверної боку слід додати ще події Exec Prepared SQL і Prepare SQL. При відтворенні потрібні стовпці, які будуть містити такі дані: назва програми, двійкову інформацію, ідентифікатор з'єднання або ідентифікатор процесу сервера (SPID), ідентифікатор бази даних, клас події, підклас події, ім'я хост-вузла, цифрову інформацію, ім'я сервера, ім'я користувача SQL, час початку прогону і текстову інформацію.

Важливо відзначити, що при повторному прогоні фіксуються події не імітуються, вони відбуваються заново. Тому слід врахувати, що в процесі початкової трасування ви, найімовірніше, змінили свою базу даних. Наприклад, при відтворенні траси, що включає оператор INSERT, в таблиці може з'явитися дублікат ключа. Щоб уникнути подібних проблем, слід повернути базу даних у вихідний стан, якщо траса відтворюється на вихідному сервері (тобто на тому сервері, на якому проводилася первинна трасування).

Якщо повторний прогін буде проводитися на іншому сервері, важливо переконатися в тому, що база даних на ньому знаходиться в тому ж стані, в якому була база даних на вихідному сервері. При цьому обов'язково слід використовувати ті ж самі імена користувачів, їхні повноваження, ідентифікатори баз даних, які застосовувалися на вихідному сервері.

Використання тих же самих ідентифікаторів вимагає особливого уміння і досвіду, особливо тому, що корпорація Microsoft не заохочує звернення безпосередньо до системної таблиці sysdatabases, що необхідно для зміни ідентифікаторів баз даних. Можна забезпечувати збіг ідентифікаторів баз даних іншим способом. Для цього слід скопіювати файли призначеної для користувача бази даних з вихідного сервера на той, де буде відтворюватися траса, а потім відновити на ньому резервну копію бази даних master з вихідного сервера. Альтернативний спосіб полягає в тому, щоб відновити на сервері, обраному для прогону, взяту з вихідного сервера резервну копію для користувача бази даних, а потім відновити там же резервну копію бази даних master. В обох випадках на сервері, де відтворюється траса, файли бази даних будуть розміщуватися в тих же директоріях, що й на вихідному сервері, а системні таблиці бази даних master будуть міститися вихідні ідентифікатори бази даних. Щоб повністю позбавитися від цих проблем, потрібно просто прибрати з трасування стовпець з ідентифікатором бази даних і встановити як заданої використовувану за замовчуванням базу даних для кожного користувача, який фіксується в процесі трасування.

Можна також керувати рівнем синхронізації сценарію і швидкістю відтворення. Виберіть пункт Settings з меню Replay, щоб увійти в діалогове вікно Replay SQL Server. Параметр Synchronization Level, який управляє синхронізацією в рамках з'єднання, може приймати такі значення:

Повна синхронізація (Full synchronization). Це значення використовується за замовчуванням. При цьому всі події, що відбувалися в одному з'єднанні, відтворюються у вихідному порядку.

Часткова синхронізація (Partial synchronization). При цьому значення події в одному з'єднанні можуть починатися раніше подій, вже зафіксованих в інших з'єднаннях.

Без синхронізації (No synchronization). При цьому значенні параметра події можуть наступати відразу після закінчення попереднього події в тому ж з'єднанні, тобто без будь-якої синхронізації в рамках з'єднання.

Параметру швидкості відтворення, Replay Rates, можна привласнити одну з таких значень:

Як можна швидше (As fast as possible). Це значення застосовується по умолчанію.В даному випадку така подія починається відразу ж по завершенні попереднього.

Зберігати інтервал між подіями (Maintain interval between events). Це значення зберігає початковий інтервал часу між моментами настання подій.

Витримувати ставлення до часу старту (Maintain relationship to start time). При цьому значення події відбуваються в ті ж моменти часу відносно початку відтворення траси, що і при початковій трасування.

Організація відтворення траси

Припустимо, необхідно відтворити трасу виконання підготовлених серверних операторів SQL, які представляють собою оператори Transact-SQL (T-SQL), що їх посилають користувачем на сервер через ADO, OLE DB або ODBC. SQL Server 7.0 виконує серверні підготовлені оператори SQL за допомогою псевдохранімих процедур sp_prepare і sp_execute, які викликає клієнтську програму.

Виклик sp_prepare змушує SQL Server готувати оператори T_SQL до виконання, компілюючи їх і розміщуючи в кеш плани виконання. При виклику sp_execute SQL Server виконує заздалегідь поміщені в кеш плани і, можливо, робить це неодноразово. Кожен виклик збереженої процедури породжує події RPC: BatchStarting, Prepare SQL і Exec Prepared SQL. Саме з цієї причини зазначені події необхідно включити до визначення траси.

SQL Profiler містить кілька прикладів визначень трас, які можна застосовувати у вигляді шаблонів. У тому числі і приклад номер 6, «T-SQL for Replay», що відноситься до повторного прогону траси. Цей приклад доцільно використовувати для завдання вихідних даних трасування, що генеруються при відтворенні. Щоб відкрити збережені вихідні дані трасування для відтворення, виберіть пункт Open з меню File і виділите для зберігання інформації, яка збирається в ході трасування, файл, таблицю або сценарій SQL. Вони можуть бути представлені або пунктами меню Replay або кнопками на панелі інструментів.

Застосування розширених збережених процедур

Деякі функції трасування з SQL Profiler недоступні. До їх числа відносяться запуск трасування за розкладом, запуск при настанні певної події або при початку роботи SQL Server. Крім того, з SQL Profiler не можна задати відправлення результатів трасування в журнал додатків Windows NT або Windows 2000. Для виконання цих функцій і для забезпечення більшої свободи програмного управління трасами можна скористатися набором розширених збережених процедур під загальним назвою xp_trace *.

Розглянемо принципи використання цих процедур, що зберігаються на прикладі запуску трасування sp_start_mytrace та збереженої процедури зупинки трасування sp_stop_mytrace. Перша збережена процедура, sp_start_mytrace, визначає трасувальні події, стовпці даних, фільтри і створює чергу для зберігання фіксованих подій. Потім вона витягує події з черги і поміщає їх у системний файл. Процедура sp_start_mytrace спілкується з чергою подій і відстежує її стан за допомогою описувача цілого типу queue handle, який процедура створює в процесі побудови черги. Процедура sp_stop_mytrace використовує цей описувач, коли треба закінчити ведення черги.

Відстежувати стан описувача черзі – нелегке завдання. Хоча існує безліч методик отримання його значення, самим простим і функціональним способом є створення таблиці, в яку будуть записуватися дані про всі трас та їхнього чергах, а також про час початку трасування, ідентифікаторі користувача, включив трасування і про ім'я комп'ютера, з якого вона була запущена. У лістингу 1 наведено оператори, що створюють таку таблицю, яка називається activetraces. Щоб побачити, які трасування знімаються в даний момент, досить переглянути цю таблицю. Щоб зупинити трасування, треба просто запросити з таблиці відповідний описувач черги.

Процедура, що зберігається для запуску трасування

Давайте пройдемося по цих двох збереженим процедурам, щоб побачити, яким чином виконується запуск і зупинка трасування. У збереженої процедури, що починає трасування, є чотири необов'язкових вхідних параметра. Перші два, @ spid_filter і @ dbid_filter, дозволяють обмежити збираються під час трасування відомості тільки тими, які відносяться до конкретного процесу сервера (визначається за його ідентифікатором, SPID) і заданої базі даних. Якщо ці параметри не будуть задані, то в ході трасування будуть збиратися дані про всі процеси і базах даних. Параметр @ email_address дозволяє призначити адресу електронної пошти, за якою буде направлятися докладна інформація про хід трасування. Якщо цей параметр не вказати, то процедура sp_start_mytrace буде виводити інформацію тільки на екран. Якщо ж він заданий, але адреса вказана неправильно, то збережена процедура видасть повідомлення про помилку і завершиться. Останній параметр, @ filename, призначений для вказівки імені файлу, в який буде спрямовуватися збирається у час трасування інформація. У випадку, коли цей параметр не визначений, відомості за замовчуванням будуть поміщатися в файл c: \ mytraceN.trc, де N – номер описувача черги. Така угода, що визначає правило для присвоєння імен файлів з даними трасування, дозволяє одночасно знімати кілька трас, не дозволяючи одній з них заблокувати файл для запису результатів тільки для себе.

Процедура sp_start_mytrace спочатку викликає збережену процедуру xp_trace_addnewqueue для створення черги подій. Перші чотири параметри цієї процедури (максимальний розмір черги max_items, таймер timeout, верхній thread_boost і нижній thread_reduce пороги) використовують значення, встановлені за замовчуванням. Призначення цих параметрів описано в статті «Спіймай подія: трасування за допомогою SQL Profiler», опублікованій у другому номері нашого журналу. Параметр data_columns представляє собою бітову маску для стовпців даних, які треба фіксувати. Щоб згенерувати цю маску, слід виконати бітову операцію АБО (|) для цілих значень, що представляють кожен стовпець. Вихідний параметр queue_handle містить ціле число, рівне розміру черги. Він призначений для використання в подальшому.

Потім збережена процедура sp_start_mytrace викликає розширену збережену процедуру seteventclassrequired для кожної події, яка повинна відбиватися в трасі. У викликаної процедури є три параметри. Перший параметр, queue_handle, є описувачем черги, отриманим з збереженої процедури xp_trace_addnewqueue. Параметр event_class представляє собою ціле число, відповідне події, яка слід фіксувати. (Для отримання повного списку класів подій і їх імен запускається збережена процедура xp_trace_geteventnames. У наводиться прикладі використані класи подій, прийняті в SQL Profiler за замовчуванням.) Параметру Isrequired відповідає двійкова змінна, що визначає, включати дану подію в трасу чи ні.

Після відбору подій, які необхідно фіксувати, слід встановити фільтри для подій. За замовчуванням при визначенні траси відкидаються всі події, які генерує SQL Profiler. Але якщо вам хочеться дізнатися більше про трасувань розширених збережених процедурах SQL Server 7.0, які SQL Profiler застосовує для трасування, можна спробувати поміняти виключає фільтр SQL Profiler на що включає. Запустіть це трасування, а потім будь-яку іншу трасування за вашим вибором. Ви побачите, які розширені процедури використовує SQL Profiler для ведення другий траси.

Кожній категорії фільтра відповідає своя розширена збережена процедура, але всі вони слідують зразком xp_trace_set * filter. Процедура sp_start_mytrace використовує збережену процедуру xp_trace_setappfilter для виключення з траси всіх подій, породжених роботою SQL Profiler. Якщо користувач запросив фільтри для збору даних тільки про технології (SPID) або про певну базі даних, то sp_start_mytrace звертається відповідно до процедур xp_trace_setspidfilter або xp_trace_setdbfilter.

Після цього sp_start_mytrace визначає варіант виведення черги (тобто місце для запису результатів трасування). Хоча можна вказати кілька вихідних пунктів призначення, всі вони повинні бути різних типів. Наприклад, можна одночасно виводити дані у файл і в таблицю, але не можна одночасно здійснювати вивід у два файли. Для завдання вихідного пункту призначення sp_start_mytrace викликає процедуру xp_trace_setqueuedestination. Щоб вибрати кілька варіантів виведення, слід відповідне число разів повторити виклик розширеної збереженої процедури. У процедури setqueuedestination використовуються наступні параметри, не рахуючи описувача черги queue_handle:

Варіант виводу (Destination): 2 – файл, 3 – журнал додатки, 4 – таблиця, 5 – передавальний сервер; Значення (Value): включено (1), відключено (0) Сервер (Server): ім'я зареєстрованого сервера, якщо потрібно надіслати результати на інший сервер або NULL, в іншому випадку Об'єкт (Object): ім'я таблиці або файлу (при цьому варіант виведення повинен бути рівний відповідно 1 або 3). Якщо такий об'єкт вже існує, то процедура просто помістить в нього результати, якщо ж цього об'єкту ще немає, процедура створить його.

Процедура sp_start_mytrace посилає інформацію, зібрану під час трасування, в розташований на цьому ж сервері файл, заданий параметром @ filename.

Трасування починається

Тепер, коли траса визначена, збережена процедура sp_start_mytrace додає рядок у таблицю activetraces, щоб стежити за даною трасуванням. Щоб переконатися, що описувач черги розглянутої траси та інші дані не втрачені, процедура sp_start_mytrace формує повідомлення з докладною інформацією про трасу і виводить його на екран, а також посилає на сервер за допомогою розширеної збереженої процедури xp_sendmail. Потім sp_start_mytrace викликає розширену процедуру xp_trace_startconsumer, єдиним параметром якої служить описувач черзі, щоб почати надсилати інформацію про події, що відбуваються в задану вихідну чергу.

У лістингу 3 проведена друга збережена процедура, sp_stop_mytrace, яка припиняє трасування, використовуючи описувач черги. Sp_stop_mytrace звертається до таблиці activetraces за описувачем черги, а потім викликає збережену процедуру xp_trace_destroyqueue для отриманого описувача черзі, щоб зупинити трасування. Завершуючи свою роботу, sp_stop_mytrace видаляє з таблиці activetraces рядок, відповідну зупиненої трасування.

Тестування збережених процедур

Для проведення тестування цих процедур, що зберігаються потрібно виконати наступні команди:


DECLARE @mydbid int
DECLARE @myspid int
SELECT @ mydbid = db_id (`pubs`), @ myspid = @ @ spid
EXEC sp_start_mytrace @myspid, @mydbid


Ви повинні будете отримати друковане повідомлення (і повідомлення по електронній пошті, якщо задано відповідний параметр), що сповіщає про запуск трасування з перерахуванням основних параметрів. До них відносяться: стан описувача черги, час запуску трасування; ім'я комп'ютера, з якого вона була запущена; ідентифікатор ініціював її користувача; місце розташування файлу з результатами трасування та ім'я збереженої процедури для зупинки трасування.


The following trace has started:
Queue Handle: 14
Start Time: Dec 19 1999  2:07PM
Host: SHIRE
Login Name: MIDDLE_EARTH\Gandalf
Destination File: c:\mytrace14.trc
Use EXEC sp_stop_mytrace 14 to stop it.


Тепер перейдіть на базу даних Pubs і запустіть декілька запитів, що звертаються до її таблиць. Переконайтеся в тому, що ви використовуєте те ж саме з'єднання, за яким викликали збережену процедуру. Це важливо, тому що в нашому тесті ми за допомогою системної функції @ @ SPID з'ясовували значення SPID для поточного з'єднання і потім використовували це значення як фільтр трасування. Коли це буде зроблено, запустіть наступний оператор, підставивши в нього замість 14 те значення, яке отримали в друкованому сполученні і в повідомленні електронної пошти:


sp_stop_mytrace 14


Тепер можна в SQL Profiler відкрити згенерований файл і переглянути його.

Автоматичний запуск

Розглянуті вище збережені процедури можна застосовувати вручну для запуску і завершення трасування, але можна робити це автоматично, як при початку роботи SQL Server, так і при настанні деякого заздалегідь заданого події. Щоб ініціювати автоматичний запуск, треба спочатку зберегти визначення трасування. Це робиться за допомогою розширеної збереженої процедури xp_trace_savequeuedefinition. Тепер розширена збережена процедура xp_trace_setqueueautostart буде запускати трасування відповідно до вказаних умов.

Процедурі savequeuedefinition крім описувача черги потрібно ще два параметри. Параметр queue_name служить для ідентифікації черги. (Процедура savequeuedefinition збереже визначення траси в ключі регістра HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ MSSQLServer \ SQLServerProfiler \ Server \ Queues \ [queue_name]. Ви завантажуєте визначення траси пізніше за допомогою розширеної збереженої процедури xp_trace_loadqueuedefinition.) Відповідно до параметром is_shared це визначення може бути призначено для колективного використання (1) або приватного (0).

Для успішної роботи розширеної збереженої процедури setqueueautostart також необхідно задати ім'я черги і булеву величину, яка визначає, чи дозволений автоматичний запуск (1) чи ні (0).

У лістингу 4 наведена інша частина процедури, що відповідає за автоматичний запуск трасування (зверніть увагу на те, що в наведеному коді описані на початку даного розділу кроки пропущені). Для відключення автоматичного запуску слід виконати команду


EXEC xp_trace_setqueueautostart
   `My Sample`,
0 – auto-start? 1 – enable, 0 – disable

І вічний бій …

Тепер, коли ви розібралися у функціях трасування SQL Profiler, ви зможете застосовувати їх для дослідження багатьох ситуацій в базах даних. Візьмемо, наприклад, запити, які виконуються дуже довго. Щоб з'ясувати, у чому причина додаткових затримок, визначте трасу, зазначивши стосуються справи події (набір подій буде відрізнятися при запуску запитів зі збережених процедур або в пакетному режимі). Зазвичай для цього потрібно відслідковувати події SQL: StmtCompleted і SP: StmtCompleted. Згрупуйте запити або за часом виконання, або за тривалістю використання CPU в залежності від того, що саме вам потрібно з'ясувати: чому запити виконуються повільніше, ніж хотілося б, або чому вони використовують занадто багато ресурсів CPU. Щоб не витрачати ресурси трасування на швидко виконуються запити, можна встановити фільтр трасування, вказавши мінімальну тривалість виконання запиту, або ж мінімальний час використання CPU в мілісекундах.

SQL Profiler може застосовуватися і для аналізу тих процесів, які відбуваються «за лаштунками» SQL Server Enterprise Manager. Припустимо, ви хочете подивитися, що робить Enterprise Manager, коли ви додаєте файл `file5` до групи файлів `fg5` в базі даних testdb. Спочатку потрібно відкрити діалогове вікно з властивостями бази даних testdb і додати файл. Але перш ніж натиснути OK, запустіть трасування в SQL Profiler, використовуючи події та стовпці даних за замовчуванням, і встановивши для ідентифікатора бази даних спеціальний фільтр із значенням 1 (master). Запустіть трасування; натисніть OK в Enterprise Manager, після чого зупиніть трасування. SQL Profiler зафіксує оператори, подібні наступним:


use [master]
ALTER DATABASE [testdb] ADD FILEGROUP [fg5]
ALTER DATABASE [testdb] ADD FILE (NAME = N `file5`,
FILENAME = N`d:\MSSQL7\DATA\file5_Data.NDF` ,
SIZE = 1, FILEGROWTH = 10%) TO FILEGROUP [fg5]


SQL Profiler може допомогти вирішити і такі проблеми, як введення автоматичного повідомлення при зміні параметра автоматичного збільшення. Це нелегке завдання, так як помістити тригер на системну таблицю не можна. Один із способів отримання такої інформації – застосувати SQL Profiler для визначення траси при наступних подіях, стовпцях даних і фільтрах:

Події: TSQL: SQL: StmtCompleted і SP: StmtCompleted. Стовпці даних: EventClass, TextData, NTUserName, ApplicationName, SQLUserName і StartTime. Фільтри: спеціальний фільтр, значення якого дорівнює ідентифікатору бази даних, за якою бажано проводити фільтрацію; і фільтр для тексту, що дозволяє відібрати повідомлення, що містять% alter% database% modify% file%.

Тепер можна створити вихідну таблицю, структура якої задана оператором, наведеним у Лістингу 5. Відзначимо, що в даному випадку необхідно побудувати таблицю самостійно, а не користуватися таблицею, яку може створити SQL Profiler. Це обумовлено необхідністю надалі отримувати інформацію з шпальти TextData, перебуваючи в тригері. Справа в тому, що в таблицях, побудованих за допомогою SQL Profiler, стовпець TextData має тип ntext, який з трігера недоступний. Щоб зробити стовпець таблиці доступним для читання з трігера, необхідно визначити його тип як nvarchar.

Потім слід визначити тригер, який буде сповіщати вас про зміну параметра автоматичного збільшення. Створення тригера описано в лістингу 6.

Для перевірки роботи тригера змініть властивості файлу:


ALTER DATABASE testdb MODIFY FILE
(NAME = `testdb_dat`, MAXSIZE = 30MB)


Ви отримаєте повідомлення про те, що властивості файлу були змінені:


File properties changed:
Statement: ALTER DATABASE testdb MODIFY FILE
(NAME = `testdb_dat`,  MAXSIZE = 30MB)
NT User Name: Gandalf
Application Name: MS SQL Query Analyzer
SQL User Name: NA
Time: 2000-11-22 14:15:28


Завжди дуже важко з'ясувати, які події привели до створення тупикової блокування. Однак у SQL Profiler передбачені спеціальні події, які можуть помітно полегшити проведення «розслідування». Наприклад, можна відстежувати за допомогою трасування поява події Lock: Deadlock. Наступ цієї події говорить

про те, що виникла тупикова ситуація. При цьому користувачеві повідомляються ідентифікатор процесу сервера (SPID), ідентифікатор заблокованою транзакції, час настання блокування, назва програми та ідентифікатор користувача. Надзвичайно зручним виявляється подія Lock: Deadlock Chain, яка генерується кожен раз при блокуванні: воно дозволяє з'ясувати ідентифікатори процесу (SPID) і транзакції.

Можна записати ідентифікатори транзакцій, залучених в тупикову блокування, потім згрупувати результати трасування по ідентифікаторах транзакцій і аналізувати лише ці транзакції. При іншому підході результати трасування відсилаються в таблицю. Потім за допомогою запитів можна провести в ній фільтрацію за номером SPID чи кодом транзакції.

Щоб згенерувати ситуацію виникнення тупикової блокування, створіть дві таблиці, t1 і t2, в кожній з яких повинен бути тільки один стовпець цілого типу. Введіть у кожну таблицю один рядок, що містить значення 1. Задайте трасу, в якій буде фіксуватися наступний набір подій: Lock: Deadlock, Lock: Deadlock Chain, і відповідні їм події початку і закінчення виконання операторів (RPC, SP, SQL). Вибір повинен виконуватися в залежності від передбачуваного джерела блокування. У нашому прикладі знадобляться тільки події SQL: StmtStarting і SQL: StmtCompleted.

Крім стовпців даних, що призначаються за умовчанням, додайте стовпець для фіксації ідентифікатора транзакції та стовпці на ваш розсуд. Встановіть фільтр траси, відповідний ідентифікатором тієї бази даних, з якою ви працюєте. Після цього відкрийте два з'єднання з сервером з Query Analyzer. Перебуваючи в першому з'єднанні, виконайте:


BEGIN TRANSACTION UPDATE t1 SET col1 = 1


У поєднанні 2 запустіть наступну транзакцію:


BEGIN TRANSACTION
  UPDATE t2 SET col1 = 1
  SELECT * FROM t1
COMMIT TRANSACTION


Нарешті, в сполученні 1 виконайте оператори:


SELECT * FROM t2
COMMIT TRANSACTION


Зупиніть трасування і відкрийте файл з її результатами. Знайдіть події Lock: Deadlock Chain events, і запишіть номери залучених транзакцій. Згрупуйте вихідні дані по ідентифікаторах транзакцій і розкрийте відповідні транзакції. Вихідні дані будуть виглядати аналогічно наведеним на екрані 1.

До складу SQL Server Enterprise Manager входить спеціальний майстер, який може допомогти встановити траси, в тому числі і ті, що застосовуються для пошуку причин появи тупикових блокувань. Щоб для визначення траси скористатися майстром створення трас Create Trace Wizard, слід увійти в Enterprise Manager, вибрати в меню Tools пункт Wizards, потім відкрити категорію Management і вибрати Create Trace Wizard.

Заключне зауваження

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

Іцик Бен-Ган itzikb@hi-tech.co.il має сертифікати MCDBA, MCSE + I, MCSD, MCT і SQL Server MVP. Є старшим викладачем на курсах з SQL Server в коледжі Hi-Tech у Ізраїлі та головою ізраїльської групи користувачів SQL Server.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*