Коллеги, нужна помощь.
Отчет подвисает сервер, сис админ выдал , где виснет.Программист  по 1С сказал что со скулем не дружит, нужна помощь
WITH merged_query_stats AS

(

   SELECT

       [sql_handle],

       statement_start_offset,

       statement_end_offset,

       plan_generation_num,

       [plan_handle],

       query_hash AS query_fingerprint,

       query_plan_hash AS plan_fingerprint,

       creation_time,

       last_execution_time,

       execution_count,

       total_worker_time / 1000 AS total_worker_time_ms,

       min_worker_time / 1000 AS min_worker_time_ms,

      max_worker_time / 1000 AS max_worker_time_ms,

       total_physical_reads,

       min_physical_reads,

       max_physical_reads,

       total_logical_writes,

       min_logical_writes,

       max_logical_writes,

       total_logical_reads,

       min_logical_reads,

       max_logical_reads,

       total_clr_time,

       min_clr_time,

       max_clr_time,

       total_elapsed_time / 1000 AS total_elapsed_time_ms,

       min_elapsed_time / 1000 AS min_elapsed_time_ms,

       max_elapsed_time / 1000 AS max_elapsed_time_ms,

       total_elapsed_time / 1000 AS total_completed_execution_time_ms

   FROM sys.dm_exec_query_stats AS q

   -- To reduce the number of rows that we have to deal with in later queries, filter out any very old rows

   WHERE q.last_execution_time > DATEADD (hour, -4, GETDATE())

 

   -- The UNIONed query below is a workaround for VSTS #91422, sys.dm_exec_query_stats does not reflect stats for in-progress queries.

   UNION ALL

   SELECT

       [sql_handle],

       statement_start_offset,

       statement_end_offset,

       NULL AS plan_generation_num,

       plan_handle,

       query_hash AS query_fingerprint,

       query_plan_hash AS plan_fingerprint,

       start_time AS creation_time,

       start_time AS last_execution_time,

       0 AS execution_count,

       cpu_time AS total_worker_time_ms,

       NULL AS min_worker_time_ms,  -- min should not be influenced by in-progress queries

       cpu_time AS max_worker_time_ms,

       reads AS total_physical_reads,

       NULL AS min_physical_reads,  -- min should not be influenced by in-progress queries

       reads AS max_physical_reads,

       writes AS total_logical_writes,

       NULL AS min_logical_writes,  -- min should not be influenced by in-progress queries

       writes AS max_logical_writes,

       logical_reads AS total_logical_reads,

       NULL AS min_logical_reads,   -- min should not be influenced by in-progress queries

       logical_reads AS max_logical_reads,

       NULL AS total_clr_time,      -- CLR time is not available in dm_exec_requests

       NULL AS min_clr_time,        -- CLR time is not available in dm_exec_requests

       NULL AS max_clr_time,        -- CLR time is not available in dm_exec_requests

       total_elapsed_time AS total_elapsed_time_ms,

       NULL AS min_elapsed_time_ms, -- min should not be influenced by in-progress queries

       total_elapsed_time AS max_elapsed_time_ms,

       NULL AS total_completed_execution_time_ms

   FROM sys.dm_exec_requests AS r

   WHERE [sql_handle] IS NOT NULL

       -- Don't attempt to collect stats for very brief in-progress requests; the active statement

       -- will likely have changed by the time that we harvest query text, in the next query

       AND DATEDIFF (second, r.start_time, @current_collection_time) > 1

)

-- Insert the fingerprint stats into a temp table.  SQL isn't always able to produce a good estimate of the amount of

-- memory that the upcoming sorts (for ROW_NUMER()) will need because of lack of accurate stats on DMVs.  Staging the

-- data in a temp table allows the memory cost of the sort operations to be more accurate, which avoids unnecessary

-- spilling to tempdb.

SELECT

   fingerprint_stats.*,

   example_plan.sample_sql_handle,

   example_plan.sample_plan_handle,

   example_plan.sample_statement_start_offset,

   example_plan.sample_statement_end_offset

INTO #temp_fingerprint_stats

FROM

-- Calculate plan fingerprint stats by grouping the query stats by plan fingerprint

(

   SELECT

       mqs.query_fingerprint,

       mqs.plan_fingerprint,

       -- The same plan could be returned by both dm_exec_query_stats and dm_exec_requests -- count distinct plan

       -- handles only

       COUNT(DISTINCT plan_handle) AS plan_count,

       MIN (mqs.creation_time) AS creation_time,

       MAX (mqs.last_execution_time) AS last_execution_time,

       SUM (mqs.execution_count) AS execution_count,

       SUM (mqs.total_worker_time_ms) AS total_worker_time_ms,

       MIN (mqs.min_worker_time_ms) AS min_worker_time_ms,

       MAX (mqs.max_worker_time_ms) AS max_worker_time_ms,

       SUM (mqs.total_physical_reads) AS total_physical_reads,

       MIN (mqs.min_physical_reads) AS min_physical_reads,

       MAX (mqs.max_physical_reads) AS max_physical_reads,

       SUM (mqs.total_logical_writes) AS total_logical_writes,

       MIN (mqs.min_logical_writes) AS min_logical_writes,

       MAX (mqs.max_logical_writes) AS max_logical_writes,

       SUM (mqs.total_logical_reads) AS total_logical_reads,

       MIN (mqs.min_logical_reads) AS min_logical_reads,

       MAX (mqs.max_logical_reads) AS max_logical_reads,

       SUM (mqs.total_clr_time) AS total_clr_time,

       MIN (mqs.min_clr_time) AS min_clr_time,

       MAX (mqs.max_clr_time) AS max_clr_time,

       SUM (mqs.total_elapsed_time_ms) AS total_elapsed_time_ms,

       MIN (mqs.min_elapsed_time_ms) AS min_elapsed_time_ms,

       MAX (mqs.max_elapsed_time_ms) AS max_elapsed_time_ms,

       SUM (mqs.total_completed_execution_time_ms) AS total_completed_execution_time_ms

   FROM merged_query_stats AS mqs

   GROUP BY

       mqs.query_fingerprint,

       mqs.plan_fingerprint

) AS fingerprint_stats

INNER JOIN

(

   -- This query assigns a unique row identifier to each plan that has the same fingerprint -- we'll

   -- select each fingerprint's 'Plan #1' (the earliest example that's still in cache) to use as a sample plan

   -- for the fingerprint.  Later (in the outer query's WHERE clause) we'll filter out all but the first plan,

   -- and use that one to get a valid sql_handle/plan_handle.

   SELECT

       *,

       ROW_NUMBER() OVER (

           PARTITION BY plan_fingerprint

           ORDER BY creation_time

       ) AS plan_instance_number

   FROM

   (

       SELECT

           query_hash AS query_fingerprint,

           query_plan_hash AS plan_fingerprint,

           qs.[sql_handle] AS sample_sql_handle,

           qs.plan_handle AS sample_plan_handle,

           qs.statement_start_offset AS sample_statement_start_offset,

           qs.statement_end_offset AS sample_statement_end_offset,

           qs.creation_time

       FROM sys.dm_exec_query_stats AS qs

       -- To get a sample plan for in-progress queries, we need to look in dm_exec_requests, too

       UNION ALL

       SELECT

           query_hash AS query_fingerprint,

           query_plan_hash AS plan_fingerprint,

           r.[sql_handle] AS sample_sql_handle,

           r.plan_handle AS sample_plan_handle,

           r.statement_start_offset AS sample_statement_start_offset,

           r.statement_end_offset AS sample_statement_end_offset,

           r.start_time AS creation_time

       FROM sys.dm_exec_requests AS r

   ) AS all_plans_numbered

) AS example_plan

   ON example_plan.query_fingerprint = fingerprint_stats.query_fingerprint

       AND example_plan.plan_fingerprint = fingerprint_stats.plan_fingerprint

-- To improve perf of the next query, filter out plan fingerprints that aren't very interesting according to any of our

-- perf metrics.  Note that our most frequent allowed execution rate for this script is one execution every 15 seconds,

-- so, for example, a plan that is executed 50 times in a 15+ second time interval will qualify for further processing.

WHERE plan_instance_number = 1

   AND (fingerprint_stats.total_worker_time_ms > 500       -- 500 ms cumulative CPU time

   OR fingerprint_stats.execution_count > 50               -- 50 executions

   OR fingerprint_stats.total_physical_reads > 50          -- 50 cumulative physical reads

   OR fingerprint_stats.total_logical_reads > 5000         -- 5,000 cumulative logical reads

   OR fingerprint_stats.total_logical_writes > 50          -- 50 cumulative logical writes

   OR fingerprint_stats.total_elapsed_time_ms > 5000)      -- 5 seconds cumulative execution time

-- SQL doesn't always have good stats on DMVs, and as a result it may select a loop join-based plan w/the

-- sys.dm_exec_query_stats DMV as the inner table.  The DMVs don't have indexes that would support efficient

-- loop joins, and will commonly have a large enough number of rows that unindexed loop joins will be an

-- unattractive option. Given this, we gain much better worst-case perf with minimal cost to best-case perf

-- by prohibiting loop joins via this hint.

OPTION (HASH JOIN, MERGE JOIN);





-- Step 2: Rank the plan fingerprints by CPU use, execution count, etc and store the results in #am_fingerprint_stats_snapshots

-- Now we have the stats for all plan fingerprints.  Return only the top N by each of our perf metrics.

-- The reason we need a derived table here is because SQL disallows the direct use of ROW_NUMBER()

-- in a WHERE clause, yet we need to filter based on the row number (rank).

попытка 2
WITH merged_query_stats AS

(

   SELECT

       [sql_handle],

       statement_start_offset,

       statement_end_offset,

       plan_generation_num,

       [plan_handle],

       query_hash AS query_fingerprint,

       query_plan_hash AS plan_fingerprint,

       creation_time,

       last_execution_time,

       execution_count,

       total_worker_time / 1000 AS total_worker_time_ms,

       min_worker_time / 1000 AS min_worker_time_ms,

      max_worker_time / 1000 AS max_worker_time_ms,

       total_physical_reads,

       min_physical_reads,

       max_physical_reads,

       total_logical_writes,

       min_logical_writes,

       max_logical_writes,

       total_logical_reads,

       min_logical_reads,

       max_logical_reads,

       total_clr_time,

       min_clr_time,

       max_clr_time,

       total_elapsed_time / 1000 AS total_elapsed_time_ms,

       min_elapsed_time / 1000 AS min_elapsed_time_ms,

       max_elapsed_time / 1000 AS max_elapsed_time_ms,

       total_elapsed_time / 1000 AS total_completed_execution_time_ms

   FROM sys.dm_exec_query_stats AS q

   -- To reduce the number of rows that we have to deal with in later queries, filter out any very old rows

   WHERE q.last_execution_time > DATEADD (hour, -4, GETDATE())

 

   -- The UNIONed query below is a workaround for VSTS #91422, sys.dm_exec_query_stats does not reflect stats for in-progress queries.

   UNION ALL

   SELECT

       [sql_handle],

       statement_start_offset,

       statement_end_offset,

       NULL AS plan_generation_num,

       plan_handle,

       query_hash AS query_fingerprint,

       query_plan_hash AS plan_fingerprint,

       start_time AS creation_time,

       start_time AS last_execution_time,

       0 AS execution_count,

       cpu_time AS total_worker_time_ms,

       NULL AS min_worker_time_ms,  -- min should not be influenced by in-progress queries

       cpu_time AS max_worker_time_ms,

       reads AS total_physical_reads,

       NULL AS min_physical_reads,  -- min should not be influenced by in-progress queries

       reads AS max_physical_reads,

       writes AS total_logical_writes,

       NULL AS min_logical_writes,  -- min should not be influenced by in-progress queries

       writes AS max_logical_writes,

       logical_reads AS total_logical_reads,

       NULL AS min_logical_reads,   -- min should not be influenced by in-progress queries

       logical_reads AS max_logical_reads,

       NULL AS total_clr_time,      -- CLR time is not available in dm_exec_requests

       NULL AS min_clr_time,        -- CLR time is not available in dm_exec_requests

       NULL AS max_clr_time,        -- CLR time is not available in dm_exec_requests

       total_elapsed_time AS total_elapsed_time_ms,

       NULL AS min_elapsed_time_ms, -- min should not be influenced by in-progress queries

       total_elapsed_time AS max_elapsed_time_ms,

       NULL AS total_completed_execution_time_ms

   FROM sys.dm_exec_requests AS r

   WHERE [sql_handle] IS NOT NULL

       -- Don't attempt to collect stats for very brief in-progress requests; the active statement

       -- will likely have changed by the time that we harvest query text, in the next query

       AND DATEDIFF (second, r.start_time, @current_collection_time) > 1

)

-- Insert the fingerprint stats into a temp table.  SQL isn't always able to produce a good estimate of the amount of

-- memory that the upcoming sorts (for ROW_NUMER()) will need because of lack of accurate stats on DMVs.  Staging the

-- data in a temp table allows the memory cost of the sort operations to be more accurate, which avoids unnecessary

-- spilling to tempdb.

SELECT

   fingerprint_stats.*,

   example_plan.sample_sql_handle,

   example_plan.sample_plan_handle,

   example_plan.sample_statement_start_offset,

   example_plan.sample_statement_end_offset

INTO #temp_fingerprint_stats

FROM

-- Calculate plan fingerprint stats by grouping the query stats by plan fingerprint

(

   SELECT

       mqs.query_fingerprint,

       mqs.plan_fingerprint,

       -- The same plan could be returned by both dm_exec_query_stats and dm_exec_requests -- count distinct plan

       -- handles only

       COUNT(DISTINCT plan_handle) AS plan_count,

       MIN (mqs.creation_time) AS creation_time,

       MAX (mqs.last_execution_time) AS last_execution_time,

       SUM (mqs.execution_count) AS execution_count,

       SUM (mqs.total_worker_time_ms) AS total_worker_time_ms,

       MIN (mqs.min_worker_time_ms) AS min_worker_time_ms,

       MAX (mqs.max_worker_time_ms) AS max_worker_time_ms,

       SUM (mqs.total_physical_reads) AS total_physical_reads,

       MIN (mqs.min_physical_reads) AS min_physical_reads,

       MAX (mqs.max_physical_reads) AS max_physical_reads,

       SUM (mqs.total_logical_writes) AS total_logical_writes,

       MIN (mqs.min_logical_writes) AS min_logical_writes,

       MAX (mqs.max_logical_writes) AS max_logical_writes,

       SUM (mqs.total_logical_reads) AS total_logical_reads,

       MIN (mqs.min_logical_reads) AS min_logical_reads,

       MAX (mqs.max_logical_reads) AS max_logical_reads,

       SUM (mqs.total_clr_time) AS total_clr_time,

       MIN (mqs.min_clr_time) AS min_clr_time,

       MAX (mqs.max_clr_time) AS max_clr_time,

       SUM (mqs.total_elapsed_time_ms) AS total_elapsed_time_ms,

       MIN (mqs.min_elapsed_time_ms) AS min_elapsed_time_ms,

       MAX (mqs.max_elapsed_time_ms) AS max_elapsed_time_ms,

       SUM (mqs.total_completed_execution_time_ms) AS total_completed_execution_time_ms

   FROM merged_query_stats AS mqs

   GROUP BY

       mqs.query_fingerprint,

       mqs.plan_fingerprint

) AS fingerprint_stats

INNER JOIN

(

   -- This query assigns a unique row identifier to each plan that has the same fingerprint -- we'll

   -- select each fingerprint's 'Plan #1' (the earliest example that's still in cache) to use as a sample plan

   -- for the fingerprint.  Later (in the outer query's WHERE clause) we'll filter out all but the first plan,

   -- and use that one to get a valid sql_handle/plan_handle.

   SELECT

       *,

       ROW_NUMBER() OVER (

           PARTITION BY plan_fingerprint

           ORDER BY creation_time

       ) AS plan_instance_number

   FROM

   (

       SELECT

           query_hash AS query_fingerprint,

           query_plan_hash AS plan_fingerprint,

           qs.[sql_handle] AS sample_sql_handle,

           qs.plan_handle AS sample_plan_handle,

           qs.statement_start_offset AS sample_statement_start_offset,

           qs.statement_end_offset AS sample_statement_end_offset,

           qs.creation_time

       FROM sys.dm_exec_query_stats AS qs

       -- To get a sample plan for in-progress queries, we need to look in dm_exec_requests, too

       UNION ALL

       SELECT

           query_hash AS query_fingerprint,

           query_plan_hash AS plan_fingerprint,

           r.[sql_handle] AS sample_sql_handle,

           r.plan_handle AS sample_plan_handle,

           r.statement_start_offset AS sample_statement_start_offset,

           r.statement_end_offset AS sample_statement_end_offset,

           r.start_time AS creation_time

       FROM sys.dm_exec_requests AS r

   ) AS all_plans_numbered

) AS example_plan

   ON example_plan.query_fingerprint = fingerprint_stats.query_fingerprint

       AND example_plan.plan_fingerprint = fingerprint_stats.plan_fingerprint

-- To improve perf of the next query, filter out plan fingerprints that aren't very interesting according to any of our

-- perf metrics.  Note that our most frequent allowed execution rate for this script is one execution every 15 seconds,

-- so, for example, a plan that is executed 50 times in a 15+ second time interval will qualify for further processing.

WHERE plan_instance_number = 1

   AND (fingerprint_stats.total_worker_time_ms > 500       -- 500 ms cumulative CPU time

   OR fingerprint_stats.execution_count > 50               -- 50 executions

   OR fingerprint_stats.total_physical_reads > 50          -- 50 cumulative physical reads

   OR fingerprint_stats.total_logical_reads > 5000         -- 5,000 cumulative logical reads

   OR fingerprint_stats.total_logical_writes > 50          -- 50 cumulative logical writes

   OR fingerprint_stats.total_elapsed_time_ms > 5000)      -- 5 seconds cumulative execution time

-- SQL doesn't always have good stats on DMVs, and as a result it may select a loop join-based plan w/the

-- sys.dm_exec_query_stats DMV as the inner table.  The DMVs don't have indexes that would support efficient

-- loop joins, and will commonly have a large enough number of rows that unindexed loop joins will be an

-- unattractive option. Given this, we gain much better worst-case perf with minimal cost to best-case perf

-- by prohibiting loop joins via this hint.

OPTION (HASH JOIN, MERGE JOIN);





-- Step 2: Rank the plan fingerprints by CPU use, execution count, etc and store the results in #am_fingerprint_stats_snapshots

-- Now we have the stats for all plan fingerprints.  Return only the top N by each of our perf metrics.

-- The reason we need a derived table here is because SQL disallows the direct use of ROW_NUMBER()

-- in a WHERE clause, yet we need to filter based on the row number (rank).

жесть...

когда у тебя в глобальнике 7ке ошибка будет тоже весь модуль кинешь текстом в сообщение?

что то не получается вставить  красивенько (

возьмите программиста 1с который дружит со скулем. Тут работать надо. Так ничего не скажешь

вообще то этот запрос не имеет к 1с никакого отношения.

Судя по тексту, этот запрос вычисляет оптимальный план выполнения какого то другого запроса

(0) Удаленно сложно будет. Совет могу дать: разбей запрос на простые подзапросы и оцени работу каждого простого подзапроса.

+7 после того, как оценишь подзапросы - выполни целиком и посмотри план выполнения.

Вроде два предложения сказал... А работы - на несколько часов.

With само по себе не используется.

(0) запрос выводит информацию о медленных запросах, выполнявшихся на сервере, к 1С отношения не имеет никакого. Судя по аглицким комментариям и отсутствию в гугле, он выдран либо с какого-то малопопулярного блога, либо, что более вероятно, используется какой-нибудь системой мониторинга за SQL Server (типа SQL Monitor, Spotlight и т.д.)

Без Фотки не взлетит !

Да вообще не взлетит)

админ тупо не тот запрос скинул, а мы тут ага сиди и разбирайся ))

(14) тот
(11) ничего это не с блога, что дали, с тем и прошу помочь

(15) это обновление статистики, к 1с отношения не имеет, и походу админ протупил, настроив обновление в рабочее время

(15) а теперь пусть скажет какой процесс этот запрос выполнял, да и вообще бред какой-то - игра в глухие телефоны

+16 и каким боком ты у этого запроса?

(0) Мдя, пока такие одмины сюкюэль существуют, реальные специалисты будут в цене...

(15) 1. я имел в виду, что приведённый фрагмент вряд ли написан вашими специалистами.
2. этот запрос к 1С отношения не имеет, 1С не использует CTE и не делает запросов к DMV (по крайней мере версии <= 8.2). Это какой-то служебный запрос, который отслеживает "медленные" запросы на сервере.

  AND (fingerprint_stats.total_worker_time_ms > 500       -- 500 ms cumulative CPU time
   OR fingerprint_stats.execution_count > 50               -- 50 executions
   OR fingerprint_stats.total_physical_reads > 50          -- 50 cumulative physical reads
   OR fingerprint_stats.total_logical_reads > 5000         -- 5,000 cumulative logical reads
   OR fingerprint_stats.total_logical_writes > 50          -- 50 cumulative logical writes
   OR fingerprint_stats.total_elapsed_time_ms > 5000)      -- 5 seconds cumulative execution time

Вот этот кусок выбирает те запросы, которые использовали суммарно более 500 миллисекунд процессорного времени, выполнялись больше 50 раз, совершили суммарно более 50 операций физ. чтения, более 5000 лог. чтения, более 50 операций записи, либо выполнялись, суммарно более 5 секунд.
Всё же даже с комментариями, блин.

А использующаяся, но не объявленная в тексте переменная @current_collection_time, как бэ намекает нам, что этот запрос является частью чего-то бОльшего, но к 1С отношения не имеющего.

(16) нет там обновления статистики

(15) страшно представить, что за блондинки у вас там

хром дружелюбно предложил перевести на русский... Может это поможет неблодинке? :D

С merged_query_stats        AS query_fingerprint,        query_plan_hash AS plan_fingerprint,        creation_time,        last_execution_time,        execution_count,        total_worker_time / 1000 AS total_worker_time_ms,        min_worker_time / 1000 AS min_worker_time_ms,       max_worker_time / 1000 AS        / 1000 AS total_elapsed_time_ms,        min_elapsed_time / 1000 AS min_elapsed_time_ms,        max_elapsed_time / 1000 AS max_elapsed_time_ms,        total_elapsed_time / 1000 AS total_completed_execution_time_ms    ОТ sys.dm_exec_query_stats AS Q    - Чтобы уменьшить количество строк, которые мы имеем дело с более поздних запросов, фильтрует все очень старые строки    , ГДЕ q.last_execution_time> DATEADD (час, -4, GETDATE ())    - объединяются запроса ниже обходной путь для VSTS # 91422, sys.dm_exec_query_stats не отражают статистику в ходе запросов.    UNION ALL    SELECT,        [sql_handle ],        statement_start_offset,        statement_end_offset,        NULL AS plan_generation_num,        plan_handle,        query_hash AS query_fingerprint,        query_plan_hash AS plan_fingerprint,        start_time AS creation_time,        start_time AS last_execution_time,        0 AS execution_count,        cpu_time AS total_worker_time_ms,        NULL AS min_worker_time_ms, - мин не должны влиять на- прогрессе запросы        cpu_time AS max_worker_time_ms,        гласит total_physical_reads,        NULL AS min_physical_reads, - мин не должны зависеть от прогресса в запросах        говорится max_physical_reads,        пишет total_logical_writes,        NULL AS min_logical_writes, - мин не должны зависеть от прогресса в запросах        пишет max_logical_writes,        logical_reads AS total_logical_reads,        NULL AS min_logical_reads, - мин не должны зависеть от прогресса в запросах        logical_reads AS max_logical_reads,        NULL AS total_clr_time, - CLR время не доступен в dm_exec_requests        NULL AS min_clr_time, - CLR время не доступны в dm_exec_requests        NULL AS max_clr_time, - CLR время не доступен в dm_exec_requests        total_elapsed_time AS total_elapsed_time_ms,        NULL AS min_elapsed_time_ms, - мин не должны зависеть от прогресса в запросах        total_elapsed_time AS max_elapsed_time_ms,        NULL AS total_completed_execution_time_ms    ОТ sys.dm_exec_requests как г    WHERE [sql_handle] IS NOT NULL        - не пытайтесь собирать статистику для очень краткого незавершенного запросов; активный оператор        - скорее всего, изменилось к тому времени, жмем текст запроса, в следующем запросе        и DATEDIFF (вторая , r.start_time, @ current_collection_time)> 1 ) - Вставьте отпечаткам пальцев статистики во временную таблицу. SQL не всегда в состоянии произвести хорошую оценку суммы - память о том, что предстоящий видов (для ROW_NUMER ()) необходимо из-за отсутствия точной статистики по DMV. Постановка - данные во временной таблице позволяет памятью стоимости операций сортировки, чтобы быть более точным, что позволяет избежать ненужного - разлив в # Temp_fingerprint_stats ОТ - Вычислить статистику план отпечатков пальцев с помощью группировки статистику запросов по плану отпечатков пальцев (    SELECT,        mqs.query_fingerprint,        mqs.plan_fingerprint,        - тот же план может быть возвращен как dm_exec_query_stats и dm_exec_requests - подсчет различных плану        - работает только с        COUNT (DISTINCT plan_handle) AS plan_count,        MIN (mqs.creation_time) AS creation_time,        MAX (mqs.last_execution_time) AS last_execution_time,        SUM (mqs.execution_count) AS execution_count,        SUM (mqs.total_worker_time_ms) AS total_worker_time_ms,        MIN (mqs.min_worker_time_ms) AS min_worker_time_ms,        MAX (mqs.max_worker_time_ms) AS max_worker_time_ms,        SUM (mqs.total_physical_reads) AS total_physical_reads,        MIN (mqs.min_physical_reads) AS min_physical_reads,        MAX (mqs.max_physical_reads) AS max_physical_reads,        SUM (mqs.total_logical_writes) AS total_logical_writes,        MIN (МКС . min_logical_writes) AS min_logical_writes,        MAX (mqs.max_logical_writes) AS max_logical_writes,        SUM (mqs.total_logical_reads) AS total_logical_reads,        MIN (mqs.min_logical_reads) AS min_logical_reads,        MAX (mqs.max_logical_reads) AS max_logical_reads,        SUM (mqs.total_clr_time) AS total_clr_time ,        MIN (mqs.min_clr_time) AS min_clr_time,        MAX (mqs.max_clr_time) AS max_clr_time,        SUM (mqs.total_elapsed_time_ms) AS total_elapsed_time_ms,        MIN (mqs.min_elapsed_time_ms) AS min_elapsed_time_ms,        MAX (mqs.max_elapsed_time_ms) AS max_elapsed_time_ms,        SUM (mqs. total_completed_execution_time_ms) AS total_completed_execution_time_ms    ОТ merged_query_stats AS MQS    GROUP BY        mqs.query_fingerprint,        mqs.plan_fingerprint ) AS fingerprint_stats INNER JOIN (    - Этот запрос присваивается уникальный идентификатор строки для каждого плана, который имеет тот же отпечатки пальцев - Мы    - выбор каждого отпечатка пальца «План № 1" (самый ранний пример, что до сих пор в кэш-памяти) для использования в качестве образца плана    - для отпечатков пальцев Позже (во внешнем запросе, где оговорка) мы отфильтровать все, кроме первого плана.    - и использовать что, чтобы получить действительный sql_handle / plan_handle.    ВЫБРАТЬ        *,        ROW_NUMBER () OVER (            PARTITION BY plan_fingerprint            ORDER BY creation_time        ) AS plan_instance_number    ИЗ    (        ВЫБРАТЬ            query_hash AS query_fingerprint,            query_plan_hash AS plan_fingerprint,            QS. [sql_handle] AS sample_sql_handle,            qs.plan_handle AS sample_plan_handle,            qs.statement_start_offset AS sample_statement_start_offset,            qs.statement_end_offset AS sample_statement_end_offset,            qs.creation_time        ОТ sys.dm_exec_query_stats AS QS        - Чтобы получить образец план в ходе запросы, мы должны смотреть в dm_exec_requests тоже        UNION ALL        SELECT,            query_hash AS query_fingerprint ,            query_plan_hash AS plan_fingerprint,            г. [sql_handle] AS sample_sql_handle,            r.plan_handle AS sample_plan_handle,            r.statement_start_offset AS sample_statement_start_offset,            r.statement_end_offset AS sample_statement_end_offset,            r.start_time AS creation_time        ОТ sys.dm_exec_requests AS г    ) AS all_plans_numbered ) AS example_plan    ON example_plan . query_fingerprint = fingerprint_stats.query_fingerprint        И example_plan.plan_fingerprint = fingerprint_stats.plan_fingerprint - Для улучшения перфорация очередной запрос, отфильтровать план отпечатки пальцев, которые не очень интересны по любому из наших - перфорация показателей. Обратите внимание, что наши самые частые разрешено выполнение тариф для этого сценария является одной выполнение каждые 15 секунд, -. так, например, план, который выполняется 50 раз в 15 + второй раз интервал будет иметь право на дальнейшую обработку , ГДЕ plan_instance_number = 1    AND (fingerprint_stats.total_worker_time_ms> 500 - 500 мс общее время процессора    ИЛИ fingerprint_stats.execution_count> 50 - 50 казней    ИЛИ fingerprint_stats.total_physical_reads> 50 - 50 кумулятивных физического чтения    или fingerprint_stats.total_logical_reads> 5000 - 5000 кумулятивных логических операций чтения    или fingerprint_stats. total_logical_writes> 50 - 50 кумулятивных пишет логического    ИЛИ fingerprint_stats.total_elapsed_time_ms> 5000) - 5 секунд, общее время выполнения - SQL не всегда имеют хорошую статистику по DMVs, и в результате он может выбрать цикла соединения на основе плана W / - sys.dm_exec_query_stats DMV как внутренней таблице. DMVs не имеют индексов, которые будут поддерживать эффективный - петля присоединяется, и как правило, имеют достаточно большое количество строк, которые не проиндексированные циклами будет - непривлекательная вариант. Учитывая это, мы получаем гораздо лучше наихудшего перфорация с минимальными затратами лучшем случае перфорация - посредством запрещения цикл присоединяется через этот намек. OPTION (HASH JOIN, MERGE JOIN); - Шаг 2: Rank план отпечатки пальцев с использованием процессора , оформление счета, и т.д., и сохранить результаты в # am_fingerprint_stats_snapshots - Теперь у нас есть статистика для всех план отпечатки пальцев. Вернуться только верхнюю N каждым из наших перфорация метрик. - Причина мы должны производной таблицы здесь, потому что SQL запрещает прямое использование ROW_NUMBER () - в ИНЕКЕ, но нам нужно фильтр, основанный на номер строки (ранг).

Кстати. Это по-ходу BioTime

админа уволить

программиста 1С тоже уволить

SQL снести...

Албанцу поставить шест и включить приятную музыку...

Раздать счеты?

у вас sql 2012 что ли http://msdn.microsoft.com/en-us/library/ms189741.aspx

да вы смелые люди

Зачем счёты? посадить вахтёршу с журналом и всё

так. про sql 2012. короче таблица эта системная. к 1С если имеет отношение, то весьма косвенное.

Кстати, с вахтёршей договориться легче, чем с бездушной програмой

Аутор про 1С ничего не говорила

(28) Разноцветные «пампушки».

(0) а что за отчет?

(0) блондинка, открой для себя http://pastebin.com/ для перекидывания простынями текста. А еще намотай этот запрос на кол админу, а сюда пости запрос 1С, от выполнения которого у сервера висюн приключается. Если запрос 1С такой же длинный, юзай сервисы типа пастебина

(7) + 1
Это самый простой и надежный способ решить проблему.
Любую сложную задачу можно разбить на несколько простых.
Так и здесь.

Я понимаю что все хотят всех уволить, но какой должен быть реальный порядок действий, что б зная узкое место на SQL, найти этот фрагмент кода в 1с. (Не зависимо от версии) ?

(38)Уволить автора (0), пригласить реального спеца...
Либо автору топика нужно срочно постичь премудрости Select -а :)

+(38)Причем тут версия?
Попросту еще непонятно откуда вообще выдернули сам запрос?
Из какой программы?
...
В общем телепат отдыхает :)

ЦУП курите.

(39) Я не про левый запрос в (0). Я про то, что допустим у тебя есть запрос SQL, который тормозной. Тебе надо найти, это место в 1с. как быть ?

(42) ответ в (41)

(43) а если 7.7 ?

(0) Админ, по ходу, тоже присутствовал при казусе в бассейне и теперь плохо соображает…  :0)

посмотрел время (0) - 7 утра.
сакуру к серверу наручником пристегнули?

(46) Ижевск и Казань - это блеать ДВА разных города! и даже не по пути!

(46) сакуру?