Обработка накладной в заказе больше 10 минут для 200 строк - DAX: Администрирование

sao · 20.09.2005, 18:02

Здравствуйте.
Вот такая проблема возникла. Обработка накладной в заказе идет больше 10 минут. Количество строк 200.
Axapta 3.0 SP3CU1, Application измененный (но мне кажется проблемы не в приложении). Размер БД 14 GB. Две компании. Одна тестовая, полностью дублирует оригинал. запускаю в 2-х уровневой на сервере.
Железо:4-х процессорный Intel Xeo 2,4 Ghz, 3GB оперативки.
в MSSQL включены все 4 процессора. MSSQL все настройки по умолчанию, как после установки. Сервер не используется, как контроллер доменов.
В профайлере кода смотрел. Оттуда неясно, почему так тормозит. Все цифры в пределах допустимого.
Сейчас реиндексацию запустил. Не знаю поможет это или нет.

MironovI · 20.09.2005, 18:17

Помимо профайлера можно посмотреть трассировку операторов sql, отсортировав ее по времени выполнения - тож удобная штука..

**mazzy** · 20.09.2005, 18:21

Цитата:

Изначально опубликовано sao
В профайлере кода смотрел. Оттуда неясно, почему так тормозит. Все цифры в пределах допустимого.

http://axapta.mazzy.ru/hints/querytuning/

**Vadik** · 20.09.2005, 18:33

Цитата:

Изначально опубликовано sao
Размер БД 14 GB. Две компании. Одна тестовая, полностью дублирует оригинал. запускаю в 2-х уровневой на сервере.

давно компанию продублировали?
а sp_updatestats давно запускали?

sao · 13.10.2005, 20:41

Aplication стандартный. 500 строк в заказе.
Проблема разбивается на:
1. Нажимаем на кнопку Обработка в заказе. Ждем.....
2. Когда идет непосредственно сама обработка накладной. Тоже долго долго ждем.

Предварительно сделал чистку, а после описанных изменения обновление статистики
http://axapta.mazzy.ru/lib/dbgrowthsolution/
Да... Сам диагноз похож на описанный здесь
http://forum.mazzy.ru/index.php?showtopic=1790

Попытки поиска и решения:
По первой проблеме
Мониторинг показал тормоза вот здесь
Class SalesTableType\checkSalesQty

Код:

...
    while select salesLine
        index hint SalesStatusIdx
        where salesLine.salesId     == salesTable.salesId
           && (salesLine.salesStatus != SalesStatus::Invoiced && salesLine.salesStatus != SalesStatus::Canceled)
           || (salesLine.SalesDeliverNow < 0)
...

Без оптимизации запрос выполнялся больше 2 минут. смотрел у же в профайлере Query Analyzer.
Создал кластерный индекс по (SalesID, RecID), добавил в SalesStatusIdx поле SalesDeliverNow . в коде убрал хинт. в профайлере Query Analyzer получилось около 400 милисекунд. в аксапте менюшка открывается с задержкой 2 - 4 секунды.
Можно ли еще что нибудь сделать? Если да, то что? Вообще к чему стремится надо?
По второй проблеме
Мониторинг показал, что по таким таблицам
SalesParmLine, CustInoviceTrans, TaxTrans, LedgerBalancesDimTrans не оптимально выборка проходит. По той же схеме провел оптимизацию.
В профайлере кода получил картинку (прилагается).
Там динамически запрос создается. Вроде по SalesParmtable, SalesParmLine.
особо не разбирался, но может кто подскажет, что можно сделать..?
еще тормоза наблюдаютя в Tax\adjustAmount....
В итоге обработка 500 строк получилась около 5 минут. это нормально?
Еще вопрос: Почему у многих таблиц нет Primary key и кластерных индексов в стандартном функционале?

**Vadik** · 13.10.2005, 21:10

По первой проблеме - присмотритесь к условию на SalesDeliveryNow - это не проблема с производительностью, это бага, какая-то добрая душа сэкономила пару скобок

PHP код:


			
while select salesLine

        index hint SalesLineIdx

        where salesLine.salesId == salesTable.salesId           &&

              ((salesLine.salesStatus != SalesStatus::Invoiced  &&

                salesLine.salesStatus != SalesStatus::Canceled) ||

                salesLine.SalesDeliverNow < 0)

Хохма в том, что о баге рапортовали в сервисную систему еще тем летом, был ответ, что уже исправлено. Я полез сейчас в SP4, чтобы процитировать оттуда, А БАГА НА МЕСТЕ

EVGL · 13.10.2005, 21:11

По-моему, это довольно известных кусок кода. Когда-то боролся. Там ведь, кажется, просто пары скобок после && не хватает? Ограничение по SalesId должно ведь всегда работать.

AndyD · 13.10.2005, 23:22

Цитата:

Изначально опубликовано sao
Еще вопрос: Почему у многих таблиц нет Primary key и кластерных индексов в стандартном функционале?

А что по вашему такое Primary key?
Primary key - это ограничение (constraint), которое гарантирует, что набор значений столбцов, входящих в него, будет уникальным в таблице. При этом он также требует, чтобы эти значения были определены, т.е. IS NOT NULL.
Кроме того, существует еще одно ограничение, требующее уникальности - UNIQUE. Но при этом значения стобцов могут быть не определены (IS NULL).
И как-раз таки это ограничение всегда присутствует в таблице, даже если не создавать индексы. В этом случае создается уникальный индекс на основе поля RecId (и DataAreaId, если таблица разбивается для компаний. Точнее порядок полей в индексе - DataAreaId, RecId). Если же существуют только неуникальные индексы в таблице, то тогда к первому из них так же добавляется поле RecId и индекс объявляется уникальным (правда увидеть это можно только на сервере БД)

Таким образом ограничение на уникальность всегда присутствует в таблице в виде Primary Key или Unique Index.

По поводу кластерного индекса
Использовать его или нет в таблице во многом зависит от характера данных, хранящихся в таблице.
Дело в том, что кластерный индекс объединяется с данными. При этом записи на страницах строго упорядочиваются в соответствии с полями, входящими в него. При поиске по ключу кластерного индекса фактически сразу получаем необходимые данные

Остальные индексы для таблицы могут ссылаться на данные двумя способами - либо ч/з Row ID если нет кластерного индекса, либо ч/з кластерный индекс в противоположном случае. Большой размер ключа кластерного индекса будет вести к увеличению размера остальных индексов, что ведет в конечном итоге к уменьшению производительности б/д.

Т.е. использование/неиспользование кластерных ключей - вопрос поиска компромиссов, результаты которых мы видим в Axapte

sao · 17.10.2005, 10:13

Большое спасибо насчет первой проблемы. Сейчас все работает, как надо. А вот вторая без изменений. Допишу еще немного:
Основная валюта RUR, а заказы идут в UE. Из-за этого вызывается Tax\AdjustAmount и теряется около 2 - 3 минут (500 строк в заказе).
Само обновление идет около 3 минут. После обновления теряем около 1,3 минуты на SalesFormletter_Invoice\WriteTaxAmount_Ru.

Сейчас вопрос стоит можно ли вообще что нибудь придумать, чтоб это стало работать побыстрее?

Wamr · 17.10.2005, 10:30

Кое-что можно..

PHP код:


			
// ALME, Russian localization
// Tax precalculation similar to purch packing slip
private void writeTaxAmount_RU()
{
    CustInvoiceTrans            invoiceTrans;
    TmpTaxWorkTrans             tmpTaxWorkTrans; // Копия временной таблицы
 
    if (! TaxParameters::find().TaxSpecifyLine)
        return;
 
    // Наполняем данными -->
    tmpTaxWorkTrans.setTmpData(this.tmpTaxWorkTrans(custInvoiceJour.RecId));
    // <--
 
    while select forUpdate invoiceTrans
        where invoiceTrans.SalesId             == custInvoiceJour.SalesId     &&
             invoiceTrans.InvoiceId         == custInvoiceJour.InvoiceId &&
             invoiceTrans.InvoiceDate         == custInvoiceJour.InvoiceDate &&
             invoiceTrans.NumberSequenceGroup == custInvoiceJour.NumberSequenceGroup
    {
        invoiceTrans.initFromTaxWorkTrans_RU(
                                             // Используем 1 копию на все строки -->
                                             //this.tmpTaxWorkTrans(custInvoiceJour.RecId)
                                             tmpTaxWorkTrans,
                                             // <--
                                             tableNum(SalesLine),
                                             0,
                                             invoiceTrans.InventTransId);
        invoiceTrans.doUpdate();
    }
}

По поводу adjustAmount - он сам вроде быстро работает, но есть проблема с его многократным вызовом.
Кстати, вспомнил - http://www.axforum.info/forums/showt...t=adjustAmount
Еще вспомнил - аналогичные проблемы у приходных накладных.

komar · 17.10.2005, 13:19

Цитата:

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

Еще вспомнил - аналогичные проблемы у приходных накладных.

А еще фактура есть, вот уж где тормоза!

sao · 19.10.2005, 14:40

Спасибо большое за исправления в налогах. Вообщем стало около 7 - 8 минут для 500 строк. Раньше было 12 - 14. Клиент все равно не доволен

. Говорит люди сидят до 10:00 и начинают из-за этого увольняться.
................
Еще могу добавить, что будет влиять (но не сильно) на производительность галочка Проверка кредитного лимита у клиента.

glibs · 19.10.2005, 14:52

Цитата:

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

...
люди сидят до 10:00 и начинают из-за этого увольняться.
...

Ужасно.

Что вы имеете против такого решения (см. первые полдюжины сообщений)? http://www.axforum.info/forums/showt...1267#post31267

ppson · 19.10.2005, 16:12

У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.

komar · 19.10.2005, 16:16

Цитата:

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

У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.

В пакетную обработку все! И на ночь - чтобы никто не видел!

**mazzy** · 19.10.2005, 16:18

Цитата:

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

У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.

1. Посмотрите что именно блокирует периодическое сопоставление и что блокируют пользователи при обработке накладных по закупкам/заказам.

2. Слушайте что komar говорит.

ppson · 19.10.2005, 16:29

Цитата:

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

В пакетную обработку все! И на ночь - чтобы никто не видел!

Не поможет. Отгрузки ведутся круглосуточно.
Обработку копают, но все как то неприятно.

**George Nordic** · 19.10.2005, 16:37

Далал все сам. Пользователей не устраивает, что что-то там автоматом разносится, и не понятно, что чем закончилось. Короче, свой пакет есть. И форма, в которой видны все добавленные в пакет накладные. Можно выбрать накладные как без комплектации (белый цвет), так и скомплектованные (зеленый цвет).
Вверху видны все накладные, можно убрать фильтр и будет видно как проведенные накладные (желтый цвет), так и удаленные (сторнированные, красный цвет). Эти категории добавить в обработку нельзя.
Также видны лапки - статус закупки для этого заказа (специфика)
Внизу видны выбранные накладные. Белая лапка - добавлено в обработку, зеленая - обработана, не ошибок, красная - обработана, есть ошибки. Ошибки видны в одном окне, но есть и стнандартный системый журнал.
Возможно проставлять дату, которой будет проведена накладная.

[IMG]InvoiceBatch2.jpg[/IMG]

С Уважением,
Георгий

**kvan** · 19.10.2005, 16:54

Цитата:

Обработку копают, но все как то неприятно.

Там копать и копать вплоть до класса FormLetter ...
Но как показывает практика, лучше начать со всяких дописок и своих собственных приблуд ...

**mazzy** · 19.10.2005, 17:00

Цитата:

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

Не поможет. Отгрузки ведутся круглосуточно.
Обработку копают, но все как то неприятно.

Тогда надо разбивать большую транзакцию в обработке на несколько маленьких.
Чтобы длительных блокировок не было.
Но это, как правило, сильно усложняет алгоритм и защиту от дурака.

В общем, читайте чего советуют при работе с базой данных.

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Номер и дата накладной в Заказе	ymv2000	DAX: Программирование	1	14.07.2006 13:35
Обработка накладной – функция изменить дату	Sanya	DAX: Функционал	2	05.08.2005 12:50
Обработка Накладной в Евро	Натка	DAX: Функционал	4	26.08.2004 19:38
Суммарная обработка накладной	AlexUnik	DAX: Функционал	1	19.08.2004 15:51
Обработка накладной	Viola	DAX: Функционал	1	05.04.2004 14:40

Опции темы	Поиск в этой теме
Версия для печати Отправить по электронной почте	Поиск в этой теме: Расширенный поиск
Опции просмотра
Линейный вид Комбинированный вид Древовидный вид