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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 19.06.2009, 09:15   #1  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
axa 3.0 клинит по страшному
2 сервера 1 АОС 2 база
15 пользователей
inventtrans 2,5 мил записей
inventdim i inventsum 0,5 мил записей

в минуту примерно 6 раз делаетса запрос на текущее состояние скалда.

В момент когда Буалтер дополнителнио добавляет к Счетам на покупку дополнительные расходы система в определенных местах подвисает на 10 минут . Т.е невозможно взять продукцыю невозможно начать новый заказа на производство .
Не получит состояние склада .

Кто нибудь можете подсказать в чем загвоздка
Старый 19.06.2009, 09:33   #2  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
для начала потрессировать функцию, в которой происходит зависание. найти то место где зависает.
скорее всего это какой нибудь запрос, который выполняется без индекса и т.п.
включите лог запросов к базе, там вы сможете увидеть план исполнения запросов, и по возможности прооптимизить зависающий запрос.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 19.06.2009, 09:47   #3  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
проблема в том што по отдельности все запросы не клинят
Старый 19.06.2009, 09:48   #4  
Bober is offline
Bober
Участник
 
311 / 104 (4) +++++
Регистрация: 29.05.2007
У вас есть программист Аксапты ? Дайте ему задание найти место, в котором тормозит, и устранить тормоза.

И пожалейте наши глаза и мозг - обращайте внимание на то, что пишите. В смысле языка.
Старый 19.06.2009, 09:52   #5  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
ну если тормоза есть, значит они чем то вызваны. вызваны они выполнением какого то кода (не обязательно запроса).
могу предложить, в "трудных" местах выполнения добавить счетчик времени, и в конце операции вывести инфолог с временем выполнения. так вы сузите круг своих поисков.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 19.06.2009, 11:00   #6  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от dim123 Посмотреть сообщение
...Буалтер...
Кто такой Буалтер?
__________________
полезное на axForum, github, vk, coub.
Старый 19.06.2009, 11:04   #7  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
sry бугалтер .

как вы думаете поможет ли это ?

ALTER DATABASE AdventureWorks
SET READ_COMMITTED_SNAPSHOT ON;

ALTER DATABASE AdventureWorks
SET ALLOW_SNAPSHOT_ISOLATION ON;
Старый 19.06.2009, 11:18   #8  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от dim123 Посмотреть сообщение
как вы думаете поможет ли это ?
Э-э-э...
Прежде чем бить из пушки, попробуйте сначала локализовать проблему, как здесь уже советовали.
методика здесь http://axapta.mazzy.ru/lib/querytuning/

про ваш вопрос. читайте:
aEremenko: Kernel Rollup 3 для DAX 3.0
aEremenko: Излучая оптимизм
__________________
полезное на axForum, github, vk, coub.
Старый 19.06.2009, 12:01   #9  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
mazzy

проблема на много шыре , перформанс показывает все нормально.

sql
batch/request 200 - 400
проц - 20-80% скачет
диск 60%

т.е не в отдельных запросах проблема .
дело в структуре стандарта . и inventsum invenddim i inventtrans
indexi в порядке

по этому и думал насчет snapshot
Старый 19.06.2009, 12:10   #10  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от dim123 Посмотреть сообщение
проблема на много шыре
Это точно!
Цитата:
Сообщение от dim123 Посмотреть сообщение
по этому и думал насчет snapshot
снапшот в 3.0 - как зайцу стоп-сигнал!
Смотрите, что делает бухгалтер в это время, разбивайте на транзакции помельче ну и т.д. - код рефактурить (модное такое слово, но в общем верное) надо в общем!
зы. Оракл рулит!
Старый 19.06.2009, 12:23   #11  
Wamr is offline
Wamr
----------------
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
 
1,737 / 858 (32) +++++++
Регистрация: 15.01.2002
Адрес: Москва
Записей в блоге: 7
Цитата:
Сообщение от dim123 Посмотреть сообщение
2 сервера 1 АОС 2 база
в минуту примерно 6 раз делаетса запрос на текущее состояние скалда.
...
Не получит состояние склада .
Оно (текущее состояние) не должно блокироваться, так что явно можно править.

Цитата:
Сообщение от egorych Посмотреть сообщение
снапшот в 3.0 - как зайцу стоп-сигнал!
не согласен, проблему с получением состояния склада решить может
Старый 19.06.2009, 12:35   #12  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от Wamr Посмотреть сообщение
не согласен, проблему с получением состояния склада решить может
Каким образом? Если сама Аксапта не способна установить этот режим для транзакции. Я устанавливал этот режим для БД, поведение не изменялось.
Старый 19.06.2009, 12:49   #13  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
inventtrans + inventdim
блокируют inventsum + inventdim

вернее не блокируют а замедляют .


ситуация
1) Создаю журнал инвентура . один склад на конкретное число. Партиционый учет . Слад + Партия . Стандарт ахапта 3.0 . Время создания около 2 часов . Количество строк 10 000 после завершения . Монитор показывает около 200- 400 batch request / sek .
2) В это время не могу нормално принимать товар на склад ( Производство - П Заказ - )
3) При приеме проиходит проверка наличия материала и создание ProdJournalTable i Line .

очень не хочетса оптимизировать стандарт.
АХА 3.0 серьёзно думаю об отказе в аха партийныи учет и учитывать не в ахапте партии .

Правилно ли я думаю ?
Старый 19.06.2009, 12:51   #14  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от dim123 Посмотреть сообщение
АХА 3.0 серьёзно думаю об отказе в аха партийныи учет и учитывать не в ахапте партии .

Правилно ли я думаю ?
Нет, не правильно.
Надо копать дальше.
__________________
полезное на axForum, github, vk, coub.
Старый 19.06.2009, 13:10   #15  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
3) При приеме проиходит проверка наличия материала и создание ProdJournalTable i Line .
А проверяли сколько выполняется проверка наличия, а сколько создание журнала? что из них тормозит?
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 19.06.2009, 13:25   #16  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
Цитата:
Сообщение от lev Посмотреть сообщение
А проверяли сколько выполняется проверка наличия, а сколько создание журнала? что из них тормозит?
да
все нормально работает отдельно
если их запускать отдельно никаких траблов


mazzy :

почему ? с использованием партии у нас растет инвентдим и сум по 30000 записей в месяц .
плюс инвентранс так как все движения с партей
Старый 19.06.2009, 13:32   #17  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от dim123 Посмотреть сообщение
почему ? с использованием партии у нас растет инвентдим и сум по 30000 записей в месяц .
плюс инвентранс так как все движения с партей
1. Это плохо
2. Это не насколько плохо, поскольку со временем у вас партии должны закрыться (обнуляться). Как в количестве, так и в сумме. А inventsum имеет признак closed. По-умолчанию, стандартные классы выбирают только незакрытые записи из inventSum.

Вполне возможно, что у вас беда с индексами, поскольку закрытых записей стало много (относительно всего количества) и теперь старые индексы работают плохо.

В общем, барабашки нет.
Вам что советуют: локализуйте проблему, поймите ее. И прините ОСОЗНАННОЕ решение.
__________________
полезное на axForum, github, vk, coub.
Старый 19.06.2009, 13:37   #18  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
Сообщение от dim123 Посмотреть сообщение
да
все нормально работает отдельно
если их запускать отдельно никаких траблов
Вы меня немного неправильно поняли
Я предлагаю не отдельно запускать. А именно воссоздать ситуацию зависания!
Т.е. запустите создание ревизии, пускай работает... А в это время принимайте товар на склад, и ищите места где зависает!
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
Старый 19.06.2009, 13:50   #19  
dim123 is offline
dim123
Участник
 
61 / 9 (1) +
Регистрация: 08.08.2005
Цитата:
Сообщение от mazzy Посмотреть сообщение
1. Это плохо
2. Это не насколько плохо, поскольку со временем у вас партии должны закрыться (обнуляться). Как в количестве, так и в сумме. А inventsum имеет признак closed. По-умолчанию, стандартные классы выбирают только незакрытые записи из inventSum.

Вполне возможно, что у вас беда с индексами, поскольку закрытых записей стало много (относительно всего количества) и теперь старые индексы работают плохо.

В общем, барабашки нет.
Вам что советуют: локализуйте проблему, поймите ее. И прините ОСОЗНАННОЕ решение.
согласен . не закрытых 400 000 инвентсум .
инвенддим все равно будет расти . состояние скалда на какое то число будет использовать inventtrans i inventdim ? ето проблема


проблема стандарта останеца журнал инвентрура не создать меньще чем за 2 часа , надо менять стандарт ? согласны ?

проблема именно в логике ахапта , проверки происходят в цыкле

склоняюсь к тому :
1) ДБ на раид 1+0
2) инвентсум и дим отдельно на раид 1+0
3) инвенттранс отдельно на раид 1+0

или ето тожа глупо ?

компания маленкая но умудрились сделать с партиями такую лажу виновен партнер которий внедрял и посоветовал ето
Старый 19.06.2009, 14:04   #20  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от dim123 Посмотреть сообщение
согласен . не закрытых 400 000 инвентсум .
инвенддим все равно будет расти . состояние скалда на какое то число будет использовать inventtrans i inventdim ? ето проблема
Тут еще важно соотношение между этими таблицами,
если количество записей в них примерно совпадает, то оптимизатору нечего делать.
если количество записей в одной отличается в разы/на порядки, то оптимизатор может начать выборку с маленькой таблицы.

Цитата:
Сообщение от dim123 Посмотреть сообщение
проблема стандарта останеца журнал инвентрура не создать меньще чем за 2 часа , надо менять стандарт ? согласны ?
Наверное.

Насколько я помню (надо бы поглядеть), в трешке для каждой строчки журнала инвентаризации делался отдельный запрос на получение остатка.
В принципе, можно и нужно, чтобы при заполнении делался один запрос на остатки, а потом перебор строк в цикле.
Вроде в последних версиях починили... Надо в трешке глядеть.

Цитата:
Сообщение от dim123 Посмотреть сообщение
склоняюсь к тому :
1) ДБ на раид 1+0
2) инвентсум и дим отдельно на раид 1+0
3) инвенттранс отдельно на раид 1+0

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

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
AXA 3.0 SP4.0 trabli s proizvoditelnostju dim123 DAX: Администрирование 11 12.01.2009 17:52
Форма RassetTable (Axa 2.5) Kolja DAX: Программирование 0 23.12.2005 15:36
а кто-нибудь использует секционировние по кампаниям в связке AXA 2.5 + Oracle 8i/9i? asaev DAX: Администрирование 9 15.06.2005 18:21
Опции темы Поиск в этой теме
Поиск в этой теме:

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

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

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

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