План запроса, использование tempdb

[gkochkin]

Добрый день.
AX 2009, SQL Server 2008 R2
Подскажите, пожалуйста, имеется план
и запрос:

DECLARE
  @P1  NVARCHAR(5),
  @P2  NVARCHAR(41),
  @P3  NUMERIC(28, 12),
  @P4  NVARCHAR(5),
  @P5  NVARCHAR(11),
  @P6  NVARCHAR(31),
  @P7  NVARCHAR(11),
  @P8  NVARCHAR(11),
  @P9  NVARCHAR(5),
  @P10 NVARCHAR(11),
  @P11 NVARCHAR(16),
  @P12 INT;

SELECT A.ITEMID,
       A.MININVENTONHAND,
       A.MAXINVENTONHAND,
       B.ECC_BUSINESSUNITID,
       B.INVENTSIZEID,
       B.INVENTCOLORID,
       B.INVENTLOCATIONID
FROM REQITEMTABLE A,
     INVENTDIM B
WHERE A.DATAAREAID=@P1
      AND A.ITEMID=@P2
          AND A.MININVENTONHAND>@P3
      AND B.DATAAREAID=@P4
          AND B.INVENTDIMID=A.COVINVENTDIMID
              AND B.INVENTSIZEID=@P5
              AND B.INVENTCOLORID=@P6
              AND B.INVENTLOCATIONID=@P7
              AND B.ECC_BUSINESSUNITID=@P8
      AND EXISTS
(
  SELECT 'x'
  FROM ECC_REQLOCATIONPROFILELINES C
  WHERE C.DATAAREAID=@P9
        AND C.INVENTLOCATIONID=B.INVENTLOCATIONID
            AND C.INVENTLOCATIONIDREQMAIN=@P10
            AND C.REQLOCATIONPROFILEID=@P11
            AND C.INPLANNING=@P12
)
GROUP BY A.ITEMID,
         A.MININVENTONHAND,
         A.MAXINVENTONHAND,
         B.ECC_BUSINESSUNITID,
         B.INVENTSIZEID,
         B.INVENTCOLORID,
         B.INVENTLOCATIONID
ORDER BY A.ITEMID,
         A.MININVENTONHAND,
         A.MAXINVENTONHAND,
         B.ECC_BUSINESSUNITID,
         B.INVENTSIZEID,
         B.INVENTCOLORID,
         B.INVENTLOCATIONID;

Это курсор, но в таком виде я его достал из кэша.
Подскажите, выделенный красным оператор в плане (CWT_PrimaryKey):

• за что он отвечает?

• нужно ли волноваться, если в оценочном плане его стоимость высокая(более 50%)?

• ссылки по теме

[Владимир Максимов]

Цитата:

за что он отвечает?

CWT - Cursor Work Table. Т.е. создание рабочей таблицы во временной базе данных для обслуживания курсора

Clustered Index Insert - вставка данных в кластерный индекс этой рабочей таблиц

Цитата:

нужно ли волноваться, если в оценочном плане его стоимость высокая(более 50%)?

По желанию

Процент - это вовсе не время выполнения. Это какая часть от всего времени выполнения запроса предположительно будет потрачена на этот этап. Но чтобы сказать много это или мало нужно знать, а сколько же времени выполняется сам запрос

Цитата:

ссылки по теме

Гм... А что google или яндекс не работают? Ну, тогда вот

http://www.sql.ru/forum/1196636-1/plan-zaprosa - препирательства с Glory в начале темы можно пропустить, а дальше и про процент сказали и что это такое объяснили.

http://bradsruminations.blogspot.ru/...rs-part-3.html - Не совсем по теме, но что физически происходит на этом этапе становится понятно

https://www.youtube.com/watch?v=CXtj0lwA5Ko - Ну, и для общего развития и для понимания

[gkochkin]

Цитата:

Сообщение от Владимир Максимов

CWT - Cursor Work Table. Т.е. создание рабочей таблицы во временной базе данных для обслуживания курсора

Clustered Index Insert - вставка данных в кластерный индекс этой рабочей таблиц



По желанию

- я имею в виду, что, когда запрос выполняется быстро, стоимость CWT обычно 0%, если медленно, то 40-70%, насколько мной было замечено. ТО есть активно используется tempdb, что не очень хорошо. Верно ли это?

[Владимир Максимов]

Неверно поняты причины и следствия. Не факт, что причиной тормозов является высокая стоимость отдельного этапа. Все это есть по ссылкам и на видео, но если вкратце

1. Перед выполнением собственно запроса SQL строит план, по которому он будет его выполнять
2. При выполнении запроса SQL строго следует выбранному плану

Проблема в том, что план выполнения запроса может быть не оптимальным. Или выделено недостаточно места в TempDB под промежуточные результаты. Вот в этом случае запрос будет выполняться медленно. И совершенно не важно, будет ли при этом использоваться TempDB или нет.

В принципе, в синтаксисе T-SQL есть возможность явно указать, по какому плану надо выполнять ту или иную операцию. Но, во-первых, это крайне порочная практика для быстро меняющейся системы, а, во-вторых, синтаксис Axapta практически не дает возможностей по использованию хинтов для этих целей.

Как следствие, остаются только две возможности:

1. Модифицировать синтаксис самого запроса в Axapta. Возможно, разбить на вложенные запросы
2. Выполнять регулярное обслуживание базы данных вроде обновления статистики и индексов. Но тут нужен администратор базы данных

Кстати, TempDB у Вас будет использоваться вне зависимости от стоимости вставки в индекс. А за счет чего такая высокая стоимость - это надо смотреть разные дополнительные свойства. Какие именно - есть упоминание в видео-уроке

В данном случае, предположительно, проблема в том, что статистика в базе SQL давно не обновлялась. Т.е. план выполнения был выбран на основе устаревших данных. Это есть по ссылке на обсуждение прошлогодней темы на сайте SQL.ru. (первая ссылка)