Время выполнения запроса в Management Studio и профилировщике. Что это измеряет? - PullRequest
8 голосов
/ 21 июня 2010

Мой производственный SQL Server находится в удаленном центре обработки данных (и веб-серверы расположены в одном центре обработки данных).Во время разработки мы заметили, что одно конкретное представление занимает много времени (около 60-80 секунд) в нашем локальном SQL Server разработки, и мы были в порядке с ним. Он был переведен в рабочий и когда я выполнял тот же запрос в производственной БД(который находится в центре обработки данных) из моей локальной Management Studio. Я вижу, что выполнение запроса занимает около 7 минут 17 секунд (доступно в правом нижнем углу Management Studio). Когда я запускаю профилировщик, я вижу, что время заняловыполнение этого запроса - 437101 микросекунд миллисекунд, , хотя в среде управления оно отображается как 7:17., что на самом деле составляет около 437101 миллисекунд.Мой администратор БД говорит, что в prod просмотр занимает от 60 до 80 секунд, хотя я вижу разные цифры из профилировщика и студии управления. Может кто-нибудь сказать мне, что означают эти длительности в профилировщике и студии управления?

Мое предположение: длительностьмежду отправкой последнего байта запроса и получением последнего байта ответа от сервера.Статистика клиента была следующей: Время обработки клиента: 90393 Общее время выполнения: 92221 Время ожидания ответов сервера: 1828

Я лучше всего понимаю, что означает «длительность» в профилировщике, «время, затрачиваемое SQL Server».(механизм оптимизации для анализа запроса, генерации плана запроса или использования существующего плана запроса + выборки записей с разных страниц) для генерации набора результатов, который исключает время, затрачиваемое данными на передачу по клиенту по проводам "*

Редактировать: Я считаю, что оба эти времени примерно одинаковы (Management Studio против профилировщика).Как они соотносятся со временем, которое я вижу в статистике клиентов?

Может ли кто-нибудь пролить свет на это?

Ответы [ 3 ]

8 голосов
/ 29 июня 2010

Если я правильно понимаю ваш вопрос, вы сначала задаете вопрос о разнице между продолжительностью, сообщаемой Profiler, и статистикой, представленной в SSMS (либо в правом нижнем углу для общего времени, и / или с помощью SET STATISTICS TIME ON),В дополнение к этому, вы, похоже, не убеждены в комментариях производственного администратора баз данных о том, что представление выполняется в течение ожидаемой продолжительности ~ 60 секунд.

Во-первых, из Books Online - статистика, которую SSMS будет сообщать через SETSTATISTICS TIME ON:

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

Вы на это способны.Что касается Duration в Profiler, он описывается следующим образом:

«Продолжительность (в микросекундах) события.»

С того места, где я сижу, эти два должны бытьфункционально эквивалентен (и, как я уверен, вы заметили, Profiler сообщит за микросекунды, если вы идете против SQL 2005 или более поздней).Я говорю это потому, что «событие» в этом случае (относительно Duration в Profiler) является выполнением выбора, который включает в себя доставку клиенту;это согласуется в обоих случаях.

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

select
    a.session_id
    ,a.start_time
    ,a.status
    ,a.command
    ,db_name(a.database_id) as database_name
    ,a.blocking_session_id
    ,a.wait_type
    ,a.wait_time
    ,a.cpu_time
    ,a.total_elapsed_time
    ,b.text
from sys.dm_exec_requests a
    cross apply sys.dm_exec_sql_text(a.sql_handle) b
where a.session_id != @@spid;

Я подозреваю, что вы увидите что-то вроде ASYNC_NETWORK_IO кактип ожидания, если проблема связана с географией, иначе посмотрите, что из этого выйдет.Если вы профилируете запрос вашего удаленного выполнения, Duration будет отражать статистику времени, которую вы видите в SSMS.ОДНАКО, если вы используете Profiler и обнаруживаете, что длительность этого запроса при выполнении с одного из веб-серверов , который находится в том же центре обработки данных, что и SQL Server, все еще занимает 7 минут, тогда администратор БДбольшой, толстый лжец :).Я бы использовал Profiler для записи запросов, которые занимают более 1 минуты, постараюсь отфильтровать для вашего просмотра и взять среднее значение, чтобы увидеть, если вы нацелены на производительность.

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

0 голосов
/ 20 марта 2014

Попробуйте с этим:

DECLARE @time AS DATETIME = CURRENT_TIMESTAMP

-- Your Query

SELECT CAST(DATEDIFF(SECOND, @time, CURRENT_TIMESTAMP) AS VARCHAR)
    + ','
    + CAST(DATEDIFF(MICROSECOND, @time, CURRENT_TIMESTAMP) AS VARCHAR)
    AS 'Execution Time'
0 голосов
/ 20 ноября 2012

Я боролся с этим, пока не нашел это ...

http://blog.sqlauthority.com/2009/10/01/sql-server-sql-server-management-studio-and-client-statistics/

Кроме того, если вы откроете вкладку «Свойство» для своего запроса, вы можете найти магическое «Истекшее время», которое может дать вам некоторое время выполнения ... Надеюсь, это поможет ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...