Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2      [все]
 План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
На картинке план запроса. Для меня он выглядит довольно неплохо, но запрос выполняется порядка 10-15 минут.
Подскажите, пожалуйста, где искать узкое место.

К сообщению приложен файл. Размер - 53Kb
27 июн 14, 08:53    [16226845]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
УТРОМ РАНО
Guest
Покажите сам запос.
27 июн 14, 09:00    [16226870]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
УТРОМ РАНО,
SELECT TOP 1
SUM
(A.POSTEDQTY) ,
SUM
(A.POSTEDVALUE) ,
SUM
(A.PHYSICALVALUE) ,
SUM
(A.DEDUCTED) ,
SUM
(A.REGISTERED) ,
SUM
(A.RECEIVED) ,
SUM
(A.PICKED) ,
SUM
(A.RESERVPHYSICAL) ,
SUM
(A.RESERVORDERED) ,
SUM
(A.ONORDER) ,
SUM
(A.ORDERED) ,
SUM
(A.ARRIVED) ,
SUM
(A.QUOTATIONRECEIPT) ,
SUM
(A.QUOTATIONISSUE) ,
SUM
(A.PHYSICALINVENT) ,
SUM
(A.AVAILPHYSICAL) ,
SUM
(A.AVAILORDERED) ,
A.ITEMID ,
B.INVENTSIZEID ,
B.INVENTCOLORID ,
B.INVENTLOCATIONID ,
B.INVENTBATCHID ,
B.INVENTGTDID_RU ,
B.ETT_BUSINESSUNITID ,
B.ETT_SEASONID ,
B.ETT_DEFECTREASONID ,
B.ETT_CUSTINVENTDIMID

FROM INVENTSUM A , INVENTDIM B;
WHERE A.DATAAREAID
=
'dat'
AND B.DATAAREAID
=
'dat'
AND A.INVENTDIMID
=
B.INVENTDIMID

GROUP BY A.ITEMID ,
B.INVENTSIZEID ,
B.INVENTCOLORID ,
B.INVENTLOCATIONID ,
B.INVENTBATCHID ,
B.INVENTGTDID_RU ,
B.ETT_BUSINESSUNITID ,
B.ETT_SEASONID ,
B.ETT_DEFECTREASONID ,
B.ETT_CUSTINVENTDIMID
ORDER BY A.ITEMID , B.INVENTSIZEID , B.INVENTCOLORID , B.INVENTLOCATIONID , B.INVENTBATCHID , B.INVENTGTDID_RU , B.ETT_BUSINESSUNITID , B.ETT_SEASONID , B.ETT_DEFECTREASONID , B.ETT_CUSTINVENTDIMID;
27 июн 14, 09:36    [16227046]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
aleks2
Guest
1. Сначала сгруппируй INVENTSUM.
2. А потом, присобачь к ей INVENTDIM.
27 июн 14, 09:53    [16227139]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
УТРОМ РАНО
Guest
при условии что входной параметр 'dat' имеет одно и то же значение. 1 обновите статистику по двум таблицам, 2 - основная стоимость приходится на сортировку, при этом Вас интересует только одна строка, перестройте сам запрос.

SELECT TOP 1 SUM(A.POSTEDQTY) ,SUM(A.POSTEDVALUE) ,SUM(A.PHYSICALVALUE) ,SUM(A.DEDUCTED) ,SUM(A.REGISTERED) ,SUM(A.RECEIVED) ,
SUM(A.PICKED) ,SUM(A.RESERVPHYSICAL) ,SUM(A.RESERVORDERED) ,SUM(A.ONORDER) ,SUM(A.ORDERED) ,SUM(A.ARRIVED) ,SUM(A.QUOTATIONRECEIPT) ,
SUM(A.QUOTATIONISSUE) ,SUM(A.PHYSICALINVENT) ,SUM(A.AVAILPHYSICAL) ,SUM(A.AVAILORDERED) ,A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,
B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID

FROM INVENTSUM A INNER JOIN INVENTDIM B ON A.INVENTDIMID = B.INVENTDIMID AND A.DATAAREAID = B.DATAAREAID
WHERE A.DATAAREAID = 'dat'
GROUP BY A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
ORDER BY A.ITEMID , B.INVENTSIZEID , B.INVENTCOLORID , B.INVENTLOCATIONID , B.INVENTBATCHID , B.INVENTGTDID_RU , B.ETT_BUSINESSUNITID , B.ETT_SEASONID , B.ETT_DEFECTREASONID , B.ETT_CUSTINVENTDIMID; 
27 июн 14, 09:57    [16227158]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
aleks2,
не совсем понятно..
27 июн 14, 10:39    [16227431]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
УТРОМ РАНО,
время выполнения не изменилось...
27 июн 14, 11:17    [16227722]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
invm
Member

Откуда: Москва
Сообщений: 9772
Статистику по таблицам нужно обновить.
27 июн 14, 11:17    [16227724]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
invm,
статистика регулярно обновляется, ежедневно
27 июн 14, 11:39    [16227913]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
invm
Member

Откуда: Москва
Сообщений: 9772
Что вернет
select
 name, 
 stats_date(object_id, stats_id)
from
 sys.stats 
where
 object_id in (object_id('INVENTSUM', 'U'), object_id('INVENTDIM', 'U'));
?
27 июн 14, 12:10    [16228221]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
WarAnt
Member

Откуда: Питер
Сообщений: 2423
gerogekochkin,

SELECT TOP 1
    SUM(A.POSTEDQTY) ,SUM(A.POSTEDVALUE) ,
    SUM(A.PHYSICALVALUE) ,SUM(A.DEDUCTED) ,
    SUM(A.REGISTERED) ,SUM(A.RECEIVED) ,
    SUM(A.PICKED) ,SUM(A.RESERVPHYSICAL) ,
    SUM(A.RESERVORDERED) ,SUM(A.ONORDER) ,
    SUM(A.ORDERED) ,SUM(A.ARRIVED) ,SUM(A.QUOTATIONRECEIPT) ,
    SUM(A.QUOTATIONISSUE) ,SUM(A.PHYSICALINVENT) ,
    SUM(A.AVAILPHYSICAL) ,SUM(A.AVAILORDERED) ,
    A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,
    B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,
    B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
    B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
FROM 
    INVENTSUM A 
    JOIN (SELECT TOP 1 ITEMID FROM INVENTSUM WHERE DATAAREAID = 'dat') a1 ON a1.ITEMID = A.ITEMID
    INNER JOIN INVENTDIM B ON A.INVENTDIMID = B.INVENTDIMID AND A.DATAAREAID = B.DATAAREAID
WHERE 
    A.DATAAREAID = 'dat'
GROUP BY 
    A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,
    B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
    B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
ORDER BY 
    B.INVENTSIZEID , B.INVENTCOLORID , B.INVENTLOCATIONID , B.INVENTBATCHID , B.INVENTGTDID_RU , 
    B.ETT_BUSINESSUNITID , B.ETT_SEASONID , B.ETT_DEFECTREASONID , B.ETT_CUSTINVENTDIMID;
27 июн 14, 12:27    [16228325]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
invm,
вернуло вот что:
I_174ITEMDIMIDX 2014-06-30 03:35:09.553
I_174CLOSEDITEMDIMIDX 2014-06-30 03:35:43.137
I_174DIMIDIDX 2014-06-30 03:36:12.370
_WA_Sys_00000001_273A9FE0 2014-06-30 03:39:30.803
_WA_Sys_0000000C_273A9FE0 2014-06-30 03:41:23.453
_WA_Sys_0000000D_273A9FE0 2014-06-30 03:42:19.850
_WA_Sys_00000010_273A9FE0 2014-06-30 03:44:03.253
_WA_Sys_00000011_273A9FE0 2014-06-30 03:45:49.720
_WA_Sys_00000015_273A9FE0 2014-06-30 03:46:55.447
_WA_Sys_0000000A_273A9FE0 2014-06-30 03:47:38.090
_WA_Sys_00000008_273A9FE0 2014-06-30 03:49:09.237
_WA_Sys_00000007_273A9FE0 2014-06-30 03:50:42.273
_WA_Sys_00000006_273A9FE0 2014-06-30 03:52:20.353
_WA_Sys_00000013_273A9FE0 2014-06-30 03:53:03.223
_WA_Sys_0000000B_273A9FE0 2014-06-30 03:53:44.357
_WA_Sys_00000009_273A9FE0 2014-06-30 03:55:19.540
_WA_Sys_00000014_273A9FE0 2014-06-30 03:56:59.867
_WA_Sys_00000016_273A9FE0 2014-06-30 03:58:27.427
_WA_Sys_0000001A_273A9FE0 2014-06-30 04:00:10.200
_WA_Sys_00000012_273A9FE0 2014-06-30 04:01:39.700
_WA_Sys_00000002_273A9FE0 2014-06-30 04:03:18.823
_WA_Sys_0000000F_273A9FE0 2014-06-30 04:04:28.623
_WA_Sys_0000000E_273A9FE0 2014-06-30 04:05:11.070
_WA_Sys_00000005_273A9FE0 2014-06-30 04:06:44.603
_WA_Sys_00000004_273A9FE0 2014-06-30 04:08:12.640
_WA_Sys_00000017_273A9FE0 2014-06-30 04:09:40.180
_WA_Sys_00000019_273A9FE0 2014-06-30 04:11:01.733
_WA_Sys_00000003_273A9FE0 2014-06-30 04:12:42.910
I_698DIMIDIDX 2014-06-30 08:11:36.350
I_698LOCATIONIDIDX 2014-06-30 08:12:52.383
I_698BATCHIDIDX 2014-06-30 08:13:57.770
I_698DIMIDX 2014-06-30 08:17:14.810
I_698GTDIDIDX_RU 2014-06-30 08:18:32.400
I_698ECC_BUSINESSUNITIDIDX 2014-06-30 08:19:30.770
I_698ECC_DEFECTREASONIDIDX 2014-06-30 08:20:32.483
I_698ECC_CUSTINVENTDIMIDIDX 2014-06-30 08:21:31.060
I_698ECC_FINDIMIDX 2014-06-30 08:22:54.690
I_698ECC_REQIDX 2014-06-30 08:23:58.527
_WA_Sys_00000009_7C7BF5BB 2014-06-30 08:26:58.290
_WA_Sys_00000001_7C7BF5BB 2014-06-30 02:47:48.947
_WA_Sys_00000002_7C7BF5BB 2014-06-30 02:51:37.977
_WA_Sys_00000003_7C7BF5BB 2014-06-30 02:52:32.520
_WA_Sys_00000004_7C7BF5BB 2014-06-30 02:53:43.470
_WA_Sys_00000005_7C7BF5BB 2014-06-30 02:57:43.803
_WA_Sys_00000006_7C7BF5BB 2014-06-30 02:58:51.727
_WA_Sys_0000000A_7C7BF5BB 2014-06-30 03:04:35.790
_WA_Sys_0000000B_7C7BF5BB 2014-06-30 03:07:58.290
_WA_Sys_0000000C_7C7BF5BB 2014-06-30 03:11:31.457
_WA_Sys_0000000D_7C7BF5BB 2014-06-30 03:14:06.537
_WA_Sys_0000000E_7C7BF5BB 2014-06-30 03:16:01.693
_WA_Sys_0000000F_7C7BF5BB 2014-06-30 03:20:38.320
_WA_Sys_00000010_7C7BF5BB 2014-06-30 03:26:03.347
I_698ECC_ADJTRANSACTION 2014-06-30 03:27:27.653
_WA_Sys_00000008_7C7BF5BB 2014-06-30 03:28:59.463
I_698ECC_INVENTDIMSIDX 2014-06-30 03:29:49.497
I_698INVENTPROFILEIDX_RU 2014-06-30 03:30:38.000
I_698INVENTOWNERIDX_RU 2014-06-30 03:31:28.030
_WA_Sys_00000012_7C7BF5BB 2014-06-30 03:32:25.100
_WA_Sys_00000011_7C7BF5BB 2014-06-30 03:33:19.827
I_698ECC_BUSUNITLOCIDX 2014-06-30 03:34:30.150
30 июн 14, 08:30    [16236743]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
WarAnt,

результат выскакивает очень быстро, но он отличается от того, что в долгом запросе....
30 июн 14, 09:20    [16236862]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

А это у Вас Axapta, да? Если так, зачем вы выбираете остаток по первой попавшейся номенклатуре и почему не используете условие INVENTSUM.CLOSED=1?
30 июн 14, 09:25    [16236872]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
gerogekochkin,

Добрый день.

Выложите действительный план в виде файла .sqlplan. И раз уж вы опубликовали тут сам запрос с именами таблиц и т.д. - то, думаю, и в анонимном плане смысла особого нет, так что выкладывайте как есть.

Еще желательно озвучить версию сервера. Определения таблиц INVENTDIM, INVENTSUM и индексов на них.

Пока, предварительно, по картинке и запросу можно предположить, что запрос страдает от недооценки строк из-за TOP, что, может сказываться например, на:
- сортировке, которой мало памяти и которая сливает на диск (это должно показываться в плане, если версия сервера >=2012, но версия нам неизвестна)
- неудачном выборе типа соединения
Если дело в этом, то можете попробовать обмануть оптимизтор, заставив его оптимизировать запрос так, как если бы нам требовалось более одной строки.
+ Что-то вроде такого:
declare @n int = 1;
SELECT TOP (@n)
	SUM (A.POSTEDQTY) ,
	SUM (A.POSTEDVALUE) ,
	SUM (A.PHYSICALVALUE) ,
	SUM (A.DEDUCTED) ,
	SUM (A.REGISTERED) ,
	SUM (A.RECEIVED) ,
	SUM (A.PICKED) ,
	SUM (A.RESERVPHYSICAL) ,
	SUM (A.RESERVORDERED) ,
	SUM (A.ONORDER) ,
	SUM (A.ORDERED) ,
	SUM (A.ARRIVED) ,
	SUM (A.QUOTATIONRECEIPT) ,
	SUM (A.QUOTATIONISSUE) ,
	SUM (A.PHYSICALINVENT) ,
	SUM (A.AVAILPHYSICAL) ,
	SUM (A.AVAILORDERED) ,
	A.ITEMID ,
	B.INVENTSIZEID ,
	B.INVENTCOLORID ,
	B.INVENTLOCATIONID ,
	B.INVENTBATCHID ,
	B.INVENTGTDID_RU ,
	B.ETT_BUSINESSUNITID ,
	B.ETT_SEASONID ,
	B.ETT_DEFECTREASONID ,
	B.ETT_CUSTINVENTDIMID
FROM 
	INVENTSUM A , 
	INVENTDIM B
WHERE 
	A.DATAAREAID = 'dat'
	AND B.DATAAREAID = 'dat'
	AND A.INVENTDIMID = B.INVENTDIMID
GROUP BY 
	A.ITEMID ,
	B.INVENTSIZEID ,
	B.INVENTCOLORID ,
	B.INVENTLOCATIONID ,
	B.INVENTBATCHID ,
	B.INVENTGTDID_RU ,
	B.ETT_BUSINESSUNITID ,
	B.ETT_SEASONID ,
	B.ETT_DEFECTREASONID ,
	B.ETT_CUSTINVENTDIMID
ORDER BY 
	A.ITEMID , 
	B.INVENTSIZEID , 
	B.INVENTCOLORID , 
	B.INVENTLOCATIONID , 
	B.INVENTBATCHID , 
	B.INVENTGTDID_RU , 
	B.ETT_BUSINESSUNITID , 
	B.ETT_SEASONID , 
	B.ETT_DEFECTREASONID , 
	B.ETT_CUSTINVENTDIMID
option(optimize for (@n = 100000));

Попробуйте.
Если не поможет, выкладывайте план и определения таблиц с индексами, как попросил выше.
30 июн 14, 10:29    [16237110]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
gerogekochkin
WarAnt,

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

SELECT TOP 1
    SUM(A.POSTEDQTY) ,SUM(A.POSTEDVALUE) ,
    SUM(A.PHYSICALVALUE) ,SUM(A.DEDUCTED) ,
    SUM(A.REGISTERED) ,SUM(A.RECEIVED) ,
    SUM(A.PICKED) ,SUM(A.RESERVPHYSICAL) ,
    SUM(A.RESERVORDERED) ,SUM(A.ONORDER) ,
    SUM(A.ORDERED) ,SUM(A.ARRIVED) ,SUM(A.QUOTATIONRECEIPT) ,
    SUM(A.QUOTATIONISSUE) ,SUM(A.PHYSICALINVENT) ,
    SUM(A.AVAILPHYSICAL) ,SUM(A.AVAILORDERED) ,
    A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,
    B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,
    B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
    B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
FROM 
    INVENTSUM A 
    JOIN (SELECT TOP 1 ITEMID FROM INVENTSUM WHERE DATAAREAID = 'dat' ORDER BY ITEMID) a1 ON a1.ITEMID = A.ITEMID
    INNER JOIN INVENTDIM B ON A.INVENTDIMID = B.INVENTDIMID AND A.DATAAREAID = B.DATAAREAID
WHERE 
    A.DATAAREAID = 'dat'
GROUP BY 
    A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,
    B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
    B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
ORDER BY 
    B.INVENTSIZEID , B.INVENTCOLORID , B.INVENTLOCATIONID , B.INVENTBATCHID , B.INVENTGTDID_RU , 
    B.ETT_BUSINESSUNITID , B.ETT_SEASONID , B.ETT_DEFECTREASONID , B.ETT_CUSTINVENTDIMID;

наверное надо было сортировать INVENTSUM , когда брали одну строку оттуда в подзапросе
30 июн 14, 10:57    [16237217]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug, да, верно.
я так понимаю, что система сама решает использовать closed или нет автоматически. Можно как-то повлиять на это?
Запрос, который предоставил Мистер Хенки отрабатывает меее, чем за секунду. Но опять же, можем ли мы указать Аксапте, как лучше строить запросы?
30 июн 14, 15:42    [16239358]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
SomewhereSomehow,
сервер - 2008R2 enterprise edition

CREATE TABLE [dbo].[INVENTDIM](
	[INVENTDIMID] [nvarchar](20) NOT NULL DEFAULT (''),
	[INVENTBATCHID] [nvarchar](20) NOT NULL DEFAULT (''),
	[WMSLOCATIONID] [nvarchar](10) NOT NULL DEFAULT (''),
	[INVENTSERIALID] [nvarchar](20) NOT NULL DEFAULT (''),
	[INVENTLOCATIONID] [nvarchar](10) NOT NULL DEFAULT (''),
	[INVENTSITEID] [nvarchar](10) NOT NULL DEFAULT (''),
	[DATAAREAID] [nvarchar](4) NOT NULL DEFAULT ('dat'),
	[RECVERSION] [int] NOT NULL DEFAULT ((1)),
	[RECID] [bigint] NOT NULL,
	[INVENTGTDID_RU] [nvarchar](30) NOT NULL DEFAULT (''),
	[ECC_BUSINESSUNITID] [nvarchar](10) NOT NULL DEFAULT (''),
	[ECC_SEASONID] [nvarchar](10) NOT NULL DEFAULT (''),
	[ECC_DEFECTREASONID] [nvarchar](10) NOT NULL DEFAULT (''),
	[ECC_CUSTINVENTDIMID] [nvarchar](20) NOT NULL DEFAULT (''),
	[INVENTSIZEID] [nvarchar](10) NOT NULL DEFAULT (''),
	[INVENTCOLORID] [nvarchar](30) NOT NULL DEFAULT (''),
	[INVENTPROFILEID_RU] [nvarchar](10) NOT NULL DEFAULT (''),
	[INVENTOWNERID_RU] [nvarchar](20) NOT NULL DEFAULT (''),
 CONSTRAINT [I_698DIMIDIDX] PRIMARY KEY CLUSTERED 
(
	[DATAAREAID] ASC,
	[INVENTDIMID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100) ON [PRIMARY]
) ON [PRIMARY]

GO
/****** Object:  Table [dbo].[INVENTSUM]    Script Date: 30.06.2014 15:49:35 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[INVENTSUM](
	[ITEMID] [nvarchar](40) NOT NULL DEFAULT (''),
	[POSTEDQTY] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[POSTEDVALUE] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[DEDUCTED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[RECEIVED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[RESERVPHYSICAL] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[RESERVORDERED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[ONORDER] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[ORDERED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[QUOTATIONISSUE] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[QUOTATIONRECEIPT] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[INVENTDIMID] [nvarchar](20) NOT NULL DEFAULT (''),
	[CLOSED] [int] NOT NULL DEFAULT ((0)),
	[REGISTERED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[PICKED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[AVAILORDERED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[AVAILPHYSICAL] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[PHYSICALVALUE] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[ARRIVED] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[PHYSICALINVENT] [numeric](28, 12) NOT NULL DEFAULT ((0)),
	[CLOSEDQTY] [int] NOT NULL DEFAULT ((0)),
	[LASTUPDDATEPHYSICAL] [datetime] NOT NULL DEFAULT ('1900-01-01 00:00:00.000'),
	[LASTUPDDATEEXPECTED] [datetime] NOT NULL DEFAULT ('1900-01-01 00:00:00.000'),
	[DATAAREAID] [nvarchar](4) NOT NULL DEFAULT ('dat'),
	[RECVERSION] [int] NOT NULL DEFAULT ((1)),
	[RECID] [bigint] NOT NULL,
 CONSTRAINT [I_174ITEMDIMIDX] PRIMARY KEY CLUSTERED 
(
	[DATAAREAID] ASC,
	[ITEMID] ASC,
	[INVENTDIMID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100) ON [PRIMARY]
) ON [PRIMARY]

GO
ALTER TABLE [dbo].[INVENTDIM]  WITH CHECK ADD CHECK  (([RECID]<>(0)))
GO
ALTER TABLE [dbo].[INVENTSUM]  WITH CHECK ADD CHECK  (([RECID]<>(0)))
GO


ALTER TABLE [dbo].[INVENTSUM] ADD CONSTRAINT [I_174ITEMDIMIDX] PRIMARY KEY CLUSTERED
(
			[ITEMID]  ASC , [INVENTDIMID]  ASC , [DATAAREAID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 )  ON [PRIMARY]
CREATE INDEX [I_174CLOSEDITEMDIMIDX] ON [dbo].[INVENTSUM]
(
				[DATAAREAID]  ASC , [CLOSED]  ASC , [ITEMID]  ASC , [INVENTDIMID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_174DIMIDIDX] ON [dbo].[INVENTSUM]
(
			[DATAAREAID]  ASC , [INVENTDIMID]  ASC , [CLOSED]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
ALTER TABLE [dbo].[INVENTDIM] ADD CONSTRAINT [I_698DIMIDIDX] PRIMARY KEY CLUSTERED
(
		[INVENTDIMID]  ASC , [DATAAREAID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 )  ON [PRIMARY]
CREATE INDEX [I_698LOCATIONIDIDX] ON [dbo].[INVENTDIM]
(
			[DATAAREAID]  ASC , [INVENTLOCATIONID]  ASC , [WMSLOCATIONID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698BATCHIDIDX] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [INVENTBATCHID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE UNIQUE INDEX [I_698DIMIDX] ON [dbo].[INVENTDIM]
(
															[DATAAREAID]  ASC , [ECC_CUSTINVENTDIMID]  ASC , [ECC_DEFECTREASONID]  ASC , [ECC_SEASONID]  ASC , [ECC_BUSINESSUNITID]  ASC , [INVENTSIZEID]  ASC , [INVENTCOLORID]  ASC , [INVENTSITEID]  ASC , [INVENTLOCATIONID]  ASC , [INVENTBATCHID]  ASC , [WMSLOCATIONID]  ASC , [INVENTSERIALID]  ASC , [INVENTGTDID_RU]  ASC , [INVENTPROFILEID_RU]  ASC , [INVENTOWNERID_RU]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698GTDIDIDX_RU] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [INVENTGTDID_RU]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_BUSINESSUNITIDIDX] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [ECC_BUSINESSUNITID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_DEFECTREASONIDIDX] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [ECC_DEFECTREASONID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_CUSTINVENTDIMIDIDX] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [ECC_CUSTINVENTDIMID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_FINDIMIDX] ON [dbo].[INVENTDIM]
(
						[DATAAREAID]  ASC , [INVENTDIMID]  ASC , [INVENTSIZEID]  ASC , [INVENTCOLORID]  ASC , [INVENTBATCHID]  ASC , [INVENTGTDID_RU]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_REQIDX] ON [dbo].[INVENTDIM]
(
						[DATAAREAID]  ASC , [INVENTDIMID]  ASC , [INVENTSIZEID]  ASC , [INVENTCOLORID]  ASC , [INVENTLOCATIONID]  ASC , [ECC_BUSINESSUNITID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_ADJTRANSACTION] ON [dbo].[INVENTDIM]
(
										[DATAAREAID]  ASC , [INVENTDIMID]  ASC , [INVENTCOLORID]  ASC , [INVENTSIZEID]  ASC , [INVENTGTDID_RU]  ASC , [ECC_SEASONID]  ASC , [ECC_BUSINESSUNITID]  ASC , [ECC_CUSTINVENTDIMID]  ASC , [INVENTLOCATIONID]  ASC , [ECC_DEFECTREASONID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_INVENTDIMSIDX] ON [dbo].[INVENTDIM]
(
				[DATAAREAID]  ASC , [INVENTDIMID]  ASC , [INVENTCOLORID]  ASC , [INVENTSIZEID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698INVENTPROFILEIDX_RU] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [INVENTPROFILEID_RU]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698INVENTOWNERIDX_RU] ON [dbo].[INVENTDIM]
(
		[DATAAREAID]  ASC , [INVENTOWNERID_RU]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,FILLFACTOR = 100 ,DROP_EXISTING = ON )  ON [PRIMARY]
CREATE INDEX [I_698ECC_BUSUNITLOCIDX] ON [dbo].[INVENTDIM]
(
			[DATAAREAID]  ASC , [ECC_BUSINESSUNITID]  ASC , [INVENTLOCATIONID]  ASC 
) 

WITH ( PAD_INDEX = OFF, ALLOW_PAGE_LOCKS = ON, ALLOW_ROW_LOCKS = ON, STATISTICS_NORECOMPUTE = OFF ,DROP_EXISTING = ON )  ON [PRIMARY]


К сообщению приложен файл (plan.sqlplan - 97Kb) cкачать
30 июн 14, 15:57    [16239430]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
Мистер Хенки
gerogekochkin
WarAnt,
этот запрос открывает таблицу остатков, top 1 в принципе добавлен искусственно. В приведенном варианте ограничиваются запасы условием JOIN(SELECT TOP 1 ITEMID.. ), что некорректно, т.к. фактически устанавливается условие отбора по коду номенклатуры, которого в исходном запросе не было.
результат выскакивает очень быстро, но он отличается от того, что в долгом запросе....

SELECT TOP 1
    SUM(A.POSTEDQTY) ,SUM(A.POSTEDVALUE) ,
    SUM(A.PHYSICALVALUE) ,SUM(A.DEDUCTED) ,
    SUM(A.REGISTERED) ,SUM(A.RECEIVED) ,
    SUM(A.PICKED) ,SUM(A.RESERVPHYSICAL) ,
    SUM(A.RESERVORDERED) ,SUM(A.ONORDER) ,
    SUM(A.ORDERED) ,SUM(A.ARRIVED) ,SUM(A.QUOTATIONRECEIPT) ,
    SUM(A.QUOTATIONISSUE) ,SUM(A.PHYSICALINVENT) ,
    SUM(A.AVAILPHYSICAL) ,SUM(A.AVAILORDERED) ,
    A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,
    B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,
    B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
    B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
FROM 
    INVENTSUM A 
    JOIN (SELECT TOP 1 ITEMID FROM INVENTSUM WHERE DATAAREAID = 'dat' ORDER BY ITEMID) a1 ON a1.ITEMID = A.ITEMID
    INNER JOIN INVENTDIM B ON A.INVENTDIMID = B.INVENTDIMID AND A.DATAAREAID = B.DATAAREAID
WHERE 
    A.DATAAREAID = 'dat'
GROUP BY 
    A.ITEMID ,B.INVENTSIZEID ,B.INVENTCOLORID ,B.INVENTLOCATIONID ,B.INVENTBATCHID ,B.INVENTGTDID_RU ,
    B.ETT_BUSINESSUNITID ,B.ETT_SEASONID ,
    B.ETT_DEFECTREASONID ,B.ETT_CUSTINVENTDIMID
ORDER BY 
    B.INVENTSIZEID , B.INVENTCOLORID , B.INVENTLOCATIONID , B.INVENTBATCHID , B.INVENTGTDID_RU , 
    B.ETT_BUSINESSUNITID , B.ETT_SEASONID , B.ETT_DEFECTREASONID , B.ETT_CUSTINVENTDIMID;

наверное надо было сортировать INVENTSUM , когда брали одну строку оттуда в подзапросе
30 июн 14, 16:05    [16239479]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

По идее, не решает. Просто в записях INVENTSUM с CLOSED=1 все остатки нулевые,
поэтому при получении текущего остатка выбирать их обычно не нужно.

Я так и не понял, зачем Вам остаток только по первой номенклатуре по первому
INVENTSIZEID, INVENTCOLORID, INVENTLOCATIONID, INVENTBATCHID и так далее?

Вы уверены, что Вам нужен TOP 1?
30 июн 14, 16:15    [16239579]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
Вы правы, top 1 я добавил сам, запрос вернее рассматривать без данного условия
30 июн 14, 16:22    [16239648]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

Ага, то есть Вам просто нужны текущие остатки.

Так вот, если нулевые Вас не интересуют, добавьте в условие запроса A.CLOSED=0.

А вообще запрос всё равно странный, лучше бы Вы рассказали, в чём его назначение.

Например, неясно, зачем Вам сортировка именно в таком порядке.

Кроме того, похоже, что Вы таким образом выбираете все
остатки (группируете по всем аналитикам, если я не пропустил какую-то), что эквивалентно группировке
по ITEMID и INVENTDIMID, и значит (т.к. это уникальный индекс на INVENTSUM) группировка у Вас вообще лишняя.

Кстати, например, у нас (но у нас Axapta 3.0, а не более старшая версия, как у Вас;
и Ваших расширенных аналитик нет, только стандартные):

Результаты такие (привожу только оценки стоимости планов, не хочется ждать 15 минут):
1. Ваш запрос: 7563.41
2. При добавлении к нему условия A.CLOSED=0 (но при этом "пустых" остатков не будет): 866.55
30 июн 14, 17:00    [16239938]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
Артём Невняткин
Member

Откуда: Ярославль
Сообщений: 5
MSSQLBug
gerogekochkin,

А это у Вас Axapta, да? Если так, зачем вы выбираете остаток по первой попавшейся номенклатуре и почему не используете условие INVENTSUM.CLOSED=1?


Тоже об этом подумал.
30 июн 14, 19:07    [16240620]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
gerogekochkin,

Интересно, поля "B.ETT_BUSINESSUNITID, B.ETT_SEASONID, B.ETT_DEFECTREASONID, B.ETT_CUSTINVENTDIMID" - в определении таблицы, что вы привели, не присутствуют, а в запросе есть... С другой стороны, в определении есть такие же поля с префиксом "ECC_" вместо "ETT_" - короче, путаница какая-то, по этому, определению таблиц верить не будем =)
К тому же появились новые данные.

По плану запроса

Оценки в порядке, но тем не менее есть сортировка, которой на вход подается около 9 ГБ данных. Не говоря о том, что сервер может испытывать трудности с выделением большого числа памяти и может попросту долго ждать пока она будет доступна (при этом должны быть ожидания типа RESOURCE_SEMAPHORE) сам оператор сортировки пытается соблюдать некий баланс между использованием памяти и tempdb, по этому, может сливать данные в tempdb, даже при точной оценке. Посмотреть, так ли это в вашем случае, можно при помощи профайлера и событий Sort Warnings.

По логике запроса

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

Но оптимизатор не может вложить в запрос новый смысл, для него это будет уже другой запрос, который он будет оптимизировать совершенно по-другому, даже если кажется, что запросы идентичны. Типичный пример: человек меняет inner join на left join (или наоборот), результат запроса не меняется, но время выполнения сокращается. После этого делается заключение о том, что А быстрее чем Б. На самом деле, с точки зрения оптимизатора сравнивать их некорректно, т.к. это просто разные по смыслу запросы, и нет ничего удивительного в том, что они выполняются разное время.

Запросы:
- от WarAnt 16228325
- от Мистер Хенки 16237217
- и "top 1 я добавил сам" 16239648
являются разными по смыслу запросами (даже если они в вашем случае возвращают один и тот же результат).
Сравнивать их с исходным запросом по производительности - смысла нет.

Но если вам что-то из этого подходит или вы можете оптимизировать логику запроса - то лучше начать с этого, а не с плана запроса. Т.к. на сегодняшний день пока нет оптимизаторов, которые бы понимали смысл и логику лучше, чем сам разработчик. И сколько ни бейся над индексами/статистиками/планами, а добиться эффекта "добавьте в условие запроса A.CLOSED=0", как предложил MSSQLBug, или заранее выбрать только один ITEMID, как предложили еще выше - не получится.
30 июн 14, 19:23    [16240654]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
Любопытный гость
Guest
SomewhereSomehow,а почему всетаки в этом случае сервер выбрал вложенные циклы?
30 июн 14, 23:06    [16241095]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
SomewhereSomehow
сам оператор сортировки пытается соблюдать некий баланс между использованием памяти и tempdb
Мне любопытно, а где-нибудь описано такое поведение? Это происходит до или после выделения памяти? Например для данного запроса выделено 13 Гб памяти, предположим что на вход сортировки подается 9 ГБ данных (что кстати не факт, даже в актуальном плане), то почему оператор сортировки может решить не использовать часть уже зарезервированной конкретно под него памяти?
1 июл 14, 00:54    [16241372]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
+ Любопытный гость

Решения оптимизатора, в массе своей, основываются на стоимости. Соответственно, в этом случае, стоимость соединения вложенными циклами оказалась ниже, чем другие типы соединения. ТС, имея под рукой БД и запрос, может посмотреть какие будут стоимости плана, если форсировать другие типы соединений при помощи option(merge/hash join). Значит ли это, что план с наименьшей стоимостью всегда выполнится быстрее – в общем случае нет. Стоимость величина оценочная и кроме того основана на модели, и, даже если оценки более-менее точные, модель может отличаться от реальности.

В данном случае, если представить себе соединение, например, merge join, то необходим либо покрывающий индекс с сортировкой по полю соединения, либо делать дополнительную сортировку, либо брать индекс и делать лукап в кластерный. Если взять hash join, то необходима дополнительная память на построение build стороны. Все эти особенности отражает модель при помощи присвоения разным вариантом разной стоимости. В итоге, выбирается наиболее дешевый вариант, которым в данном случае оказался Nested Loops + Clustered Index Seek с последующей сортировкой.

+ Mind

К сожалению, официально не документировано, хотя они вообще мало такие вещи документируют. Могу процитировать Paul White-а в одной из его статей.
Paul White
It is a common misconception that SQL Server will try to perform a sort entirely in memory if it can. In fact the algorithms used are much more complex: they aim to achieve a balance between memory usage, average response time, while maintaining high levels of resource concurrency. Memory is a precious resource in the server, so SQL Server may spill a sort to tempdb, even if sufficient main memory is available.

Это похоже на правду. Наверняка, вы и сами обращали внимание, что иногда без явных видимых причин сортировка вдруг сливает данные на диск. Простой пример.
if object_id('t') is not null drop table t;
create table t(a char(5000));
insert t select 'a' from master..spt_values;
go
set statistics xml on;
select * from t order by a;
set statistics xml off;

Картинка с другого сайта.
Вроде бы и данные фиксированной длины и оценка совпадает с фактом, а spill происходит.

На всякий случай, возвращаясь к теме, чтобы не запутывать ТСа всякими нюансами, еще раз повторю свою мысль, что если можно оптимизировать логику, то лучше начать с этого. Никакой оптимизатор, не сможет посмотреть на процедуру и сказать: "о, этот кусок старый, теперь он вообще не нужен, убираем его" и тому подобное =)
1 июл 14, 10:02    [16241907]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
SomewhereSomehow,
а что, если создать для запроса plan_guide с явным указанием maxdop?
я протестировал для запроса с "top 1". В единичном случае выполнилось в два раза быстрее!
3 июл 14, 12:38    [16254183]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> я протестировал для запроса с "top 1". В единичном случае выполнилось в два раза быстрее!
Причём здесь вообще TOP 1?

Вы бы лучше на мои комментарии ответили. ;)
3 июл 14, 12:41    [16254202]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
запрос формирует аксапта. Каким образом я могу добавить условие a.closed=0, если запрос формируется в самой системе?
3 июл 14, 13:30    [16254557]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug
gerogekochkin,

Ага, то есть Вам просто нужны текущие остатки.

Так вот, если нулевые Вас не интересуют, добавьте в условие запроса A.CLOSED=0.

А вообще запрос всё равно странный, лучше бы Вы рассказали, в чём его назначение.

Например, неясно, зачем Вам сортировка именно в таком порядке.

Кроме того, похоже, что Вы таким образом выбираете все
остатки (группируете по всем аналитикам, если я не пропустил какую-то), что эквивалентно группировке
по ITEMID и INVENTDIMID, и значит (т.к. это уникальный индекс на INVENTSUM) группировка у Вас вообще лишняя.

Кстати, например, у нас (но у нас Axapta 3.0, а не более старшая версия, как у Вас;
и Ваших расширенных аналитик нет, только стандартные):

Результаты такие (привожу только оценки стоимости планов, не хочется ждать 15 минут):
1. Ваш запрос: 7563.41
2. При добавлении к нему условия A.CLOSED=0 (но при этом "пустых" остатков не будет): 866.55


Запрос ведь формирует сама система, как я могу добавять это условие A.CLOSED=0 в запрос, который формирует Аксапта?
3 июл 14, 13:42    [16254635]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
а как я могу добавить условие A.CLOSED=0 в запрос, который формирует Аксапта???
3 июл 14, 13:44    [16254651]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> а как я могу добавить условие A.CLOSED=0 в запрос, который формирует Аксапта???
Переписав его в Axapta, разумеется. ;) Где это он там формируется, кстати?

Вы так и не ответили, какова цель этого запроса, без этого много не посоветуешь.
3 июл 14, 13:51    [16254723]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
gerogekochkin
SomewhereSomehow,
а что, если создать для запроса plan_guide с явным указанием maxdop?
я протестировал для запроса с "top 1". В единичном случае выполнилось в два раза быстрее!


Не совсем понял, а может что-то пропустил, но при чем тут maxdop? У вас на сервере стоит ограничение в 1 поток? В таком случае да, локальный хинт переопределит это значение и параллельный план будет возможен, если это решит проблему - хорошо. Но я бы на вашем месте, постарался избавиться от сортировки. Кстати, вы не посмотрели, происходит все-таки spill или нет? А память долго ждет или нет? Все-таки запрос требует много памяти... Посмотрите ожидания при помощи Extended Events - очень классная штука, помогает сразу понять корень проблемы, а не гадать.
3 июл 14, 15:03    [16255326]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
этот запрос отображает остатки в наличии.
Вот основное место, в котором отображаются все остатки: Управление запасами \ Запросы \ В наличии
3 июл 14, 15:25    [16255511]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> Управление запасами \ Запросы \ В наличии
А зачем у Вас там в "отображение аналитики" установлена галка "закрытые операции"?
3 июл 14, 15:40    [16255637]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
gerogekochkin
Member

Откуда: Москва
Сообщений: 93
MSSQLBug,
я лично не занимаюсь аксаптой, но вот что мне ответили:
"Предположим, что когда-то давно была закуплена номенклатура "А", запасы которой были впоследствии израсходованы.
Позднее встала задача: рассчитать остатки этой номенклатуры на определённую дату, которая находится где-то в середине периода её складской активности.
Для решения подобной задачи есть 2 подхода:
1. Рассчитать остатки вручную при помощи интерфейса
2. Рассчитать остатки программно.
Рассмотрим вариант 1:
Нужно выгрузить в Excel все операции по товару (складские проводки) и просуммировать их на требуемую дату.
Форма складских проводок может быть вызвана из 3-х мест системы, включая форму запасов в наличии.
Так вот, если форма запасов в наличии будет открыта с установленной галкой "закрытые операции", то нужная нам номенклатура в ней не будет отображаться.

Рассмотрим вариант 2 (и усложним его):
Нам нужно рассчитать запасы на дату для большого кол-ва номенклатуры, как и требуется в большинстве реальных запросов по отчётности.
В этом случае организуется цикл по строкам остатков, где для каждой из строк рассчитывается итог товародвижения на указанную дату с обратным знаком и суммируется с текущим значением остатка.
Такой подход расчёта является наиболее оптимальным, т.к. при этом на таблицу складских проводок удаётся наложить фильтр по номенклатуре и по складской аналитике.
Складская аналитика в каждой строке запасов в наличии уникальна (например: Склад, Цвет, Размер), поэтому если мы будем накладывать на запасы в наличии фильтр "закрытые операции" = "да", то также как и в первом варианте, мы пропустим ряд строк и не учтём какую-то часть складского движения, которая на текущий момент считается закрытой.
"
4 июл 14, 08:35    [16258153]     Ответить | Цитировать Сообщить модератору
 Re: План запроса  [new]
MSSQLBug
Guest
gerogekochkin,

> я лично не занимаюсь аксаптой, но вот что мне ответили
То, что Вам ответили --- это совершенно другая задача, а не то, что Вы тут описывали.
Кроме того, Вы пытаетесь сделать OLAP в OLTP-системе, естественно, получается плохо.

Лучше посоветуйте тем, кто у вас занимается Axapta,
обратиться с этой проблемой на профильный форум (http://www.axforum.info).
4 июл 14, 10:23    [16258504]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2      [все]
Все форумы / Microsoft SQL Server Ответить