SQL Profiler решает проблемы
 

Источник:http://www.osp.ru/win2000/sql/2000/04/406.htm

Предварительная подготовка к воспроизведению трассы

При помощи 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. Управлять воспроизведением можно при помощи опций, приведенных в таблице 1. Они могут быть представлены или пунктами меню Replay или кнопками на панели инструментов.

Таблица 1.
Пункт меню Описание
Начать выполнение (Start execution) Воспроизводит всю трассу до точки прерывания или до наступления заданного события. В точке прерывания прогон приостанавливается.
Прекратить выполнение (Stop execution) Прекращает воспроизведение, если оно производится.
Прервать выполнение (Pause execution) Прерывает выполняемое воспроизведение.
Выполнить один шаг (Execute single step) Воспроизводит трассу по шагам, причем на одном шаге происходит одно событие.
Дойти до курсора (Run to cursor) Воспроизводит трассу до тех пор, пока не наступит событие, выделенное на экране курсором.
Вставить/Удалить точку прерывания (Toggle break-point) Позволяет вставить или удалить точку прерывания.
Применение расширенных хранимых процедур

Некоторые функции трассировки из 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. Чтобы увидеть, какие трассировки снимаются в настоящий момент, достаточно просмотреть эту таблицу. Чтобы остановить трассировку, надо просто запросить из таблицы соответствующий описатель очереди.