Настройка индексов

[vesna dba]

Запрос и его план
SELECT MAX(A.NAMEALIAS),MAX(A.VSN_CUSTTYPE),MAX(A.LINEOFBUSINESSID),A.CUSTACCOUNT,MAX(B
.INVOICINGNAME),B.VSN_BONDCODE,SUM(C.VSN_QTY),SUM(C.LINEAMOUNTMST),SUM(C.TAXAMOU
N
TMST),SUM(C.VSN_QTYPCS),SUM(C.QTY),MAX(D.REFINVENTCLASS),MAX(D.REFINVENTRAITING)
,
MAX(D.REFFUNCTIONALSUBGROUP),MAX(D.REFTRADEMARK),MAX(D.VSN_AGGREGATPACKID),MAX(D
.
VSN_GENERALNAME),MAX(D.NAMEALIAS),MAX(D.ITEMNAME),MAX(D.PACKING_RU),D.ITEMID
FROM SMMBUSRELTABLE A,VSN_CUSTINVOICEJOURCONTR B,CUSTINVOICETRANS C,INVENTTABLE D
WHERE (A.DATAAREAID='VC')
AND (((B.DATAAREAID='DAT')
AND (B.DATAAREAID#2='VC'))
AND ((((((B.INVOICEDATE>={TS '2007-02-01 00:00:00.000'})
AND (B.INVOICEDATE<={TS '2007-02-28 00:00:00.000'}))
AND (B.INVOICETYPE=0))
AND (B.VSN_STORNED=0))
AND
NOT ((B.INVOICEACCOUNT=' КЛ-00235')))
AND (A.CUSTACCOUNT=B.INVOICEACCOUNT)))
AND ((C.DATAAREAID='DAT')
AND ((((B.NUMBERSEQUENCEGROUP=C.NUMBERSEQUENCEGROUP)
AND (B.INVOICEDATE=C.INVOICEDATE))
AND (B.INVOICEID=C.INVOICEID))
AND (B.SALESID=C.SALESID)))
AND ((D.DATAAREAID='VC')
AND (C.ITEMID=D.ITEMID))
GROUP BY A.CUSTACCOUNT,B.VSN_BONDCODE,D.ITEMID
ORDER BY A.CUSTACCOUNT,B.VSN_BONDCODE,D.ITEMID OPTION(FAST 15)
[attachment=605:Plan1_Cu...iceTrans.JPG]

Запрос и его план после изменения индекса INVOICEIDX (сделан кластерным)
[attachment=606:Plan2_Cu...iceTrans.JPG]

Индексы на таблице CUSTINVOICETRANS:
I_064INVOICEIDX
по полям:
- DATAAREAID
- SALESID
- INVOICEDATE
- INVOICEID
- LINENUM
- NUMBERSEQUENCEGROUP
I_064ITEMIDIDX
- DATAAREAID
- ITEMID
- INVOICEDATE
I_064RECID
- DATAAREAID
- RECID
I_064TRANSIDIDX
- DATAAREAID
- INVENTTRANSID
- INVOICEID
- INVOICEDATE
I_064VSN_INVOICEID
- DATAAREAID
- INVOICEID

Индексы кроме I_064VSN_INVOICEID из стандартного функционала.
--
Комментарий программиста относительно отчета, в котором разбираем запрос к базе данных, который вызывает TABLE SCAN:
"Отчет не из стандартного функционала Аксапты.
Создан сотрудниками отдела программирования.
Отчет создан стандартными визуальными средствами разработки с использованием объекта Query.
Запросы формируются на уровне ядра и возможности вмешаться в построение запроса к базе данных у нас нет."
---
Гуру, отзовитесь. Наверняка это касается многих.

[Vadik]

я бы для начала отказался от VIEW VSN_CUSTINVOICEJOURCONTR

[vesna dba]

Цитата:

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

я бы для начала отказался от VIEW VSN_CUSTINVOICEJOURCONTR

Это вьюшник по custinvoicejour и rcontracttable т.е . по шапкам накладных и договорам (Отчет в модуле РК, отчет по продажам).
Отказ невозможен.

[Vadik]

Цитата:

Сообщение от vesna dba

Это вьюшник по custinvoicejour и rcontracttable т.е . по шапкам накладных и договорам (Отчет в модуле РК, отчет по продажам).

это я понял

Цитата:

Отказ невозможен.

попробуйте вместо этого view использовать в запросе две таблицы

[vesna dba]

Цитата:

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

попробуйте вместо этого view использовать в запросе две таблицы

А смысл?
Сканирование таблицы вообще не в той стороне.

[vesna dba]

Цитата:

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

я бы для начала отказался от VIEW VSN_CUSTINVOICEJOURCONTR

А ведь вы попали пальцем в небо, или не попали.. ну короче пища для размышлений была.

Разобрались мы с этим запросом.
Проблема была следующая:
Пользователь, который формировал отчет, в своем наборе прав имел фильтры по номенклатуре. В результате указанный мною запрос изменялся - добавлялись условия выборки по INVENTTABLE и на этом все надолго повисало. У пользователя без таких фильтров отрабатывало за приемлемое время.
Решен вопрос был путем измения сборки вьюшника (INVENTTABLE засунули в него), условия по фильтрам по INVENTTABLE в запрос попадать не стали, изменили немного логику функционала (из за пересборки вьюшника). Теперь отчет формируется нормально.

[Vadik]

Цитата:

Сообщение от vesna dba

А ведь вы попали пальцем в небо

Цитата:

Пользователь, который формировал отчет, в своем наборе прав имел фильтры по номенклатуре. В результате указанный мною запрос изменялся

звиняйте, ну нет в роду телепатов..