AX 2012 R2 CU7 Исправление медленно закрывающейся формы сопосталений проводок по клиенту/поставщику, открытой из журнала ГК

[Morpheus]

Это текст и план стандартного SQL зароса (новый индекс не отключал, т.к. на план выполнения он не повлиял):

SELECT T1.RECID,
	T2.RECID,
	T2.DATAAREAID,
	T3.TRANSDATE,
	T3.DOCUMENTNUM,
	T3.INVOICE,
	T3.PAYMID,
	T3.VOUCHER,
	T3.DATAAREAID,
	T3.RECID 
FROM SPECTRANS T1 CROSS 
JOIN VENDTRANSOPEN T2 CROSS 
JOIN VENDTRANS T3 
WHERE ((T1.PARTITION=5637144576) 
	AND (((T1.SPECCOMPANY='DA1') 
	AND (T1.SPECTABLEID=212)) 
	AND (T1.SPECRECID=17852886295))) 
	AND ((T2.PARTITION=5637144576) 
	AND (((T2.DATAAREAID=T1.REFCOMPANY) 
	AND (T1.REFTABLEID=866)) 
	AND (T2.RECID=T1.REFRECID))) 
	AND ((T3.PARTITION=5637144576) 
	AND (T3.RECID=T2.REFRECID 
	AND (T3.DATAAREAID = T2.DATAAREAID) 
	AND (T3.PARTITION = T2.PARTITION))) 
	ORDER BY T1.RECID

А это текст и план отрефакторенного SQL зароса:

SELECT T1.TRANSDATE,
       T1.DOCUMENTNUM,
       T1.INVOICE,
       T1.PAYMID,
       T1.VOUCHER,
       T1.RECID,
       T2.RECID,
       T3.RECID
  FROM VENDTRANS T1 CROSS
  JOIN VENDTRANSOPEN T2 CROSS
  JOIN SPECTRANS T3
 WHERE ((T1.PARTITION=5637144576)
   AND (T1.DATAAREAID='DA1'))
   AND (((T2.PARTITION=5637144576)
   AND (T2.DATAAREAID='DA1'))
   AND (T2.REFRECID=T1.RECID))
   AND ((T3.PARTITION=5637144576)
   AND ((((((T3.REFCOMPANY=T2.DATAAREAID)
   AND (T3.REFTABLEID=866))
   AND (T3.REFRECID=T2.RECID))
   AND (T3.SPECCOMPANY='DA1'))
   AND (T3.SPECTABLEID=212))
   AND (T3.SPECRECID=17852886295)))

[GannexMan]

Думаю, что план запроса лучше не стал.
Если в первом варианте, было два кластерных индекса,
то во втором только один.
Получили Key Lookup и жесткий удар по производительности.

Во втором случае одна и та же таблица VendTrans выдала разное кол-во записей.
В последнем запросе явно указано для всех таблиц данные брать только из DA1, возможно это и объясняет поведение, оптимизатор ограничил кол-во записей по выбранной компании, а не по всем

AND (T3.RECID=T2.REFRECID
AND (T3.DATAAREAID = T2.DATAAREAID)
AND (T3.PARTITION = T2.PARTITION)))

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

Если, ограничить VendTrans явным указанием DATAAREAID,
оригинальный запрос будет намного быстрей.

[Morpheus]

Цитата:

Сообщение от GannexMan

Получили Key Lookup и жесткий удар по производительности.

Key Lookup можно устранить, добавив IncludedColumn(s) поля в индекс.

Коллеги, у вас есть возможность проверить на ваших инсталляциях, быстро ли закрывается форма сопоставлений? Для теста необходимо создать в журнал ГК транзакцию платеж для клиента или поставщика и сопоставить ее с инвойсом при помощи меню Функции/Сопоставление на форме строк журнала ГК. После сопоставления закрыть форму и оценить, как быстро она закроется.

[Vadik]

Цитата:

Сообщение от Morpheus

Коллеги, у вас есть возможность проверить на ваших инсталляциях, быстро ли закрывается форма сопоставлений?

У меня на CU7 - быстро (DATAAREAIDLITERAL и PARTITIONLITERAL - включены)

[Morpheus]

Цитата:

Сообщение от Vadik

У меня на CU7 - быстро (DATAAREAIDLITERAL и PARTITIONLITERAL - включены)

А какая у Вас версия БД?

[Vadik]

Цитата:

Сообщение от Morpheus

А какая у Вас версия БД?

На инстансе с которым я сейчас плотно работаю - SQL Server 2008 R2 EE

[ZVV]

Попробуйте для интереса пересобрать свежую SQL статистику для участвующих таблиц.

[Morpheus]

Цитата:

Сообщение от Vadik

На инстансе с которым я сейчас плотно работаю - SQL Server 2008 R2 EE

У меня работает SQL Server 2008 R2 SP1 SE.

[Morpheus]

Цитата:

Сообщение от Vadik

У меня на CU7 - быстро (DATAAREAIDLITERAL и PARTITIONLITERAL - включены)

Включение DATAAREAIDLITERAL и PARTITIONLITERAL не помогло.