Перешли на Нав 5.0. Очень медленно calcsums :(

[mira]

Всем доброго дня.

Пример.
в репорте три кусочка по трем разным таблицам типа такого:
rSalesLine2.RESET;
rSalesLine2.SETCURRENTKEY(Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date");
rSalesLine2.SETRANGE(Type,rSalesLine2.Type::Item);
rSalesLine2.SETRANGE("No.",pItem);
rSalesLine2.SETRANGE("Variant Code",pVariant);
rSalesLine2.SETRANGE("Location Code",pLocDistrib);
rSalesLine2.CALCSUMS("Outstanding Qty. (Base)");
dcQtyInSales2:=rSalesLine2."Outstanding Qty. (Base)";

тормозит.. раньше все за 10 минут, сейчас по одной группе 30% за 1,5 часа

В используемых индексах в Нав4 было определенным значением для сво-ва индекса SIFTLevelsToMaintain. А в 5 версии это свойство отсутствует.
Может, в этом дело?

Или может быть, вообще только в SQL (у нас 2005) искать причины замедления?

Подскажите , плииз, направления поиска причин. Глаза разбежались
На что стоит обратить внимание? Что можно проверить?

[RedFox]

Цитата:

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

Пример.
в репорте три кусочка по трем разным таблицам типа такого:
rSalesLine2.RESET;
rSalesLine2.SETCURRENTKEY(Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date");
rSalesLine2.SETRANGE(Type,rSalesLine2.Type::Item);
rSalesLine2.SETRANGE("No.",pItem);
rSalesLine2.SETRANGE("Variant Code",pVariant);
rSalesLine2.SETRANGE("Location Code",pLocDistrib);
rSalesLine2.CALCSUMS("Outstanding Qty. (Base)");
dcQtyInSales2:=rSalesLine2."Outstanding Qty. (Base)";

тормозит.. раньше все за 10 минут, сейчас по одной группе 30% за 1,5 часа

В используемых индексах в Нав4 было определенным значением для сво-ва индекса SIFTLevelsToMaintain. А в 5 версии это свойство отсутствует.
Может, в этом дело?

Или может быть, вообще только в SQL (у нас 2005) искать причины замедления?

Подскажите , плииз, направления поиска причин. Глаза разбежались

Для начала расскажите кратко как переходили и пересоздавали ли ключики для NAV и SQL?

P.S. Кстати, все объекты перекомпиливали после перехода?

[.Quattro.]

На вашем месте я бы установил SIFTLevelsToMaintain, как было в 4-ке и посмотрел на результат.
Почти на 90% уверен, что дело в этом.

[rmv]

Немного теории:
В Пятерке поменяли механизм работы с сифтами - теперь вместо таблиц и кода на триггерах таблиц используется индексированные представления.
К сожалению, это положительное новшество еще больше увеличило различия между Native DB и SQL версией. Ключ, идеально работающей в NativeDB может сильно тормозить работу SQL версии и наоборот. На двух стульях усидеть тяжело, и, судя по 5.0, MS не спешит пересаживаться с Native DB .
Поясню на примере ключа:
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date" c sumindexfield "Outstanding Qty. (Base)" и
галками MaintainSiftIndex на каждой из комбинаций:
Type,"No."
Type,"No.","Variant Code"
Type,"No.","Variant Code","Drop Shipment"
Type,"No.","Variant Code","Drop Shipment","Location Code"
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code"
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type"
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date"

В Native DB значение поля "Outstanding Qty. (Base)" физически хранится вместе с индексом.
В SQL версии до 5.0 предрасчитанные значения хранятся в отдельной таблице причем на каждую комбинацию. Для вашего кода в связанной таблице существует только одна запись и выборка из нее получается практически мгновенной.
В SQL версии начиная с 5.0 существует одно индексированное представление (то что оно индексированная - тоже нужно проверить) c полями
Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date", SumIndexField1, .. SumIndexFieldN и первичным ключом Type,"No.","Variant Code","Drop Shipment","Location Code","Bin Code","Document Type","Shipment Date". Запрос, выполняемый при вызове кода rSalesLine2.CALCSUMS("Outstanding Qty. (Base)") будем выглядеть как:
select sum(["Outstanding Qty. (Base)"]) from IndexView where ....(перечесление фильтров).
Скорость его работы будет напрямую зависеть от количества наложенных фильтров, количества записей в таблице и селективности ключа.

В вашем случае я бы сделал:
1. Проверил что сифты действительно лежат в индексированных представлениях (возможно индексированные view отключены в настройках сервера).
2. Проанализировал запросы и селективность используемых ключей. Общие правила: Длинные ключи - зло. Поля, часто используемые в расчете сифтов должны быть передвинуты в начало ключа (к примеру болтающийся в конце ключа Posting Date не прибавит скорости работы отчетам по оборачиваемости). Для книг операций запрещается указывать поле Entry No. во вторичном ключе, если в нем определены SumIndexFields. Ключ должен строится по принципу наибольшей селективности (в общем случае разумнее использовать ключ "Document Type", "Document No." нежели "Document No.", "Document Type").

[finn]

Вот еще информация к размышлению:
http://blogs.msdn.com/microsoft_dyna...sor-types.aspx
http://blogs.msdn.com/nav_developer/...v-5-0-sp1.aspx

[mira]

SIFTLevelsToMaintain в Наве 5.0 просто нет. Убрали это свойство.

[mira]

Про ключики к сожалению ничего не знаю. Спрошу.


"Кстати, все объекты перекомпиливали после перехода?" А вот нет! Смотрю, даты компиляция разные, а если компилили после перехода, то должна, по идее, быть одна - воскресная. А зачем компилить после перехода, не подскажете? Мне же надо как-то аргументировать )

У нас два сервера: на одном база для отчетов, на другом рабочая. Обе теперь 5.0. Так вот на одном сервере все ок, а на другом тормозит. "Проверил что сифты действительно лежат в индексированных представлениях (возможно индексированные view отключены в настройках сервера)." Проверим сейчас, возможно так и есть.

Спасибо за информацию, будем обсуждать.
Обязательно сообщу о результате )

[mira]

Переформирование ключей помогает.

[yes]

Переформирование - это сначала снять галку Enambled, откомпилить, потом поставить и снова компилить?