AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 20.09.2005, 18:02   #1  
sao is offline
sao
Участник
 
58 / 16 (1) ++
Регистрация: 07.04.2005
Адрес: Подмосковье
Обработка накладной в заказе больше 10 минут для 200 строк
Здравствуйте.
Вот такая проблема возникла. Обработка накладной в заказе идет больше 10 минут. Количество строк 200.
Axapta 3.0 SP3CU1, Application измененный (но мне кажется проблемы не в приложении). Размер БД 14 GB. Две компании. Одна тестовая, полностью дублирует оригинал. запускаю в 2-х уровневой на сервере.
Железо:4-х процессорный Intel Xeo 2,4 Ghz, 3GB оперативки.
в MSSQL включены все 4 процессора. MSSQL все настройки по умолчанию, как после установки. Сервер не используется, как контроллер доменов.
В профайлере кода смотрел. Оттуда неясно, почему так тормозит. Все цифры в пределах допустимого.
Сейчас реиндексацию запустил. Не знаю поможет это или нет.
Старый 20.09.2005, 18:17   #2  
MironovI is offline
MironovI
Участник
 
724 / 77 (4) ++++
Регистрация: 30.05.2005
Помимо профайлера можно посмотреть трассировку операторов sql, отсортировав ее по времени выполнения - тож удобная штука..
Старый 20.09.2005, 18:21   #3  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Re: Обработка накладной в заказе больше 10 минут для 200 строк
Цитата:
Изначально опубликовано sao
В профайлере кода смотрел. Оттуда неясно, почему так тормозит. Все цифры в пределах допустимого.
http://axapta.mazzy.ru/hints/querytuning/
__________________
полезное на axForum, github, vk, coub.
Старый 20.09.2005, 18:33   #4  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Re: Обработка накладной в заказе больше 10 минут для 200 строк
Цитата:
Изначально опубликовано sao
Размер БД 14 GB. Две компании. Одна тестовая, полностью дублирует оригинал. запускаю в 2-х уровневой на сервере.
давно компанию продублировали?
а sp_updatestats давно запускали?
Старый 13.10.2005, 20:41   #5  
sao is offline
sao
Участник
 
58 / 16 (1) ++
Регистрация: 07.04.2005
Адрес: Подмосковье
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 и кластерных индексов в стандартном функционале?

Последний раз редактировалось sao; 05.02.2007 в 18:26.
Старый 13.10.2005, 21:10   #6  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
По первой проблеме - присмотритесь к условию на 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, чтобы процитировать оттуда, А БАГА НА МЕСТЕ
За это сообщение автора поблагодарили: kashperuk (2).
Старый 13.10.2005, 21:11   #7  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
По-моему, это довольно известных кусок кода. Когда-то боролся. Там ведь, кажется, просто пары скобок после && не хватает? Ограничение по SalesId должно ведь всегда работать.
Старый 13.10.2005, 23:22   #8  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2476 (88) +++++++++
Регистрация: 20.08.2005
Цитата:
Изначально опубликовано 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
__________________
Axapta v.3.0 sp5 kr2
Старый 17.10.2005, 10:13   #9  
sao is offline
sao
Участник
 
58 / 16 (1) ++
Регистрация: 07.04.2005
Адрес: Подмосковье
Большое спасибо насчет первой проблемы. Сейчас все работает, как надо. А вот вторая без изменений. Допишу еще немного:
Основная валюта RUR, а заказы идут в UE. Из-за этого вызывается Tax\AdjustAmount и теряется около 2 - 3 минут (500 строк в заказе).
Само обновление идет около 3 минут. После обновления теряем около 1,3 минуты на SalesFormletter_Invoice\WriteTaxAmount_Ru.

Сейчас вопрос стоит можно ли вообще что нибудь придумать, чтоб это стало работать побыстрее?
Старый 17.10.2005, 10:30   #10  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Кое-что можно..
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
Еще вспомнил - аналогичные проблемы у приходных накладных.

Последний раз редактировалось Wamr; 17.10.2005 в 10:52.
За это сообщение автора поблагодарили: raz (6), Logger (10).
Старый 17.10.2005, 13:19   #11  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от Wamr
Еще вспомнил - аналогичные проблемы у приходных накладных.
А еще фактура есть, вот уж где тормоза!
Старый 19.10.2005, 14:40   #12  
sao is offline
sao
Участник
 
58 / 16 (1) ++
Регистрация: 07.04.2005
Адрес: Подмосковье
Спасибо большое за исправления в налогах. Вообщем стало около 7 - 8 минут для 500 строк. Раньше было 12 - 14. Клиент все равно не доволен . Говорит люди сидят до 10:00 и начинают из-за этого увольняться.
................
Еще могу добавить, что будет влиять (но не сильно) на производительность галочка Проверка кредитного лимита у клиента.
Старый 19.10.2005, 14:52   #13  
glibs is offline
glibs
Member
Сотрудники компании It Box
Most Valuable Professional
Лучший по профессии 2011
Лучший по профессии 2009
 
4,942 / 911 (40) +++++++
Регистрация: 10.06.2002
Адрес: I am from Kyiv, Ukraine. Now I am in Moscow. For private contacts: glibs@hotmail.com
Цитата:
Сообщение от sao
...
люди сидят до 10:00 и начинают из-за этого увольняться.
...
Ужасно.

Что вы имеете против такого решения (см. первые полдюжины сообщений)? http://www.axforum.info/forums/showt...1267#post31267
__________________
С уважением,
glibs®
Старый 19.10.2005, 16:12   #14  
ppson is offline
ppson
Участник
Аватар для ppson
Ex AND Project
1C
 
2,102 / 114 (8) +++++
Регистрация: 25.06.2002
Адрес: SPb, Msk
У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.
__________________
Старый 19.10.2005, 16:16   #15  
komar is offline
komar
Шаман форума
Аватар для komar
Ex AND Project
 
5,571 / 600 (32) +++++++
Регистрация: 24.05.2002
Цитата:
Сообщение от ppson
У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.
В пакетную обработку все! И на ночь - чтобы никто не видел!
Старый 19.10.2005, 16:18   #16  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ppson
У меня на клиенте после запуска периодического сопоставления в бухгалтерии скорость обработки накладных по закупкам/заказам уменьшается на порядки. Просто 1С какой то.
1. Посмотрите что именно блокирует периодическое сопоставление и что блокируют пользователи при обработке накладных по закупкам/заказам.
2. Слушайте что komar говорит.
__________________
полезное на axForum, github, vk, coub.
Старый 19.10.2005, 16:29   #17  
ppson is offline
ppson
Участник
Аватар для ppson
Ex AND Project
1C
 
2,102 / 114 (8) +++++
Регистрация: 25.06.2002
Адрес: SPb, Msk
Цитата:
Сообщение от komar
В пакетную обработку все! И на ночь - чтобы никто не видел!
Не поможет. Отгрузки ведутся круглосуточно.
Обработку копают, но все как то неприятно.
__________________
Старый 19.10.2005, 16:37   #18  
George Nordic is offline
George Nordic
Модератор
Аватар для George Nordic
Злыдни
 
4,479 / 1250 (50) ++++++++
Регистрация: 17.12.2003
Адрес: Moscow
Записей в блоге: 9
Групповая обработка накладных
Далал все сам. Пользователей не устраивает, что что-то там автоматом разносится, и не понятно, что чем закончилось. Короче, свой пакет есть. И форма, в которой видны все добавленные в пакет накладные. Можно выбрать накладные как без комплектации (белый цвет), так и скомплектованные (зеленый цвет).
Вверху видны все накладные, можно убрать фильтр и будет видно как проведенные накладные (желтый цвет), так и удаленные (сторнированные, красный цвет). Эти категории добавить в обработку нельзя.
Также видны лапки - статус закупки для этого заказа (специфика)
Внизу видны выбранные накладные. Белая лапка - добавлено в обработку, зеленая - обработана, не ошибок, красная - обработана, есть ошибки. Ошибки видны в одном окне, но есть и стнандартный системый журнал.
Возможно проставлять дату, которой будет проведена накладная.

[IMG]InvoiceBatch2.jpg[/IMG]

С Уважением,
Георгий
Миниатюры
Нажмите на изображение для увеличения
Название: InvoiceBatch2.jpg
Просмотров: 552
Размер:	120.9 Кб
ID:	1489  
Старый 19.10.2005, 16:54   #19  
kvan is offline
kvan
Moderator
Аватар для kvan
Дети Юза
 
775 / 49 (3) +
Регистрация: 07.08.2002
Адрес: Donetsk
Цитата:
Обработку копают, но все как то неприятно.
Там копать и копать вплоть до класса FormLetter ...
Но как показывает практика, лучше начать со всяких дописок и своих собственных приблуд ...
Старый 19.10.2005, 17:00   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от ppson
Не поможет. Отгрузки ведутся круглосуточно.
Обработку копают, но все как то неприятно.
Тогда надо разбивать большую транзакцию в обработке на несколько маленьких.
Чтобы длительных блокировок не было.
Но это, как правило, сильно усложняет алгоритм и защиту от дурака.

В общем, читайте чего советуют при работе с базой данных.
__________________
полезное на axForum, github, vk, coub.
Теги
программно, производительность, ax3.0

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Номер и дата накладной в Заказе 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
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 02:43.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.