axa 3.0 клинит по страшному

[dim123]

2 сервера 1 АОС 2 база
15 пользователей
inventtrans 2,5 мил записей
inventdim i inventsum 0,5 мил записей

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

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

Кто нибудь можете подсказать в чем загвоздка

[lev]

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

[dim123]

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

[Bober]

У вас есть программист Аксапты ? Дайте ему задание найти место, в котором тормозит, и устранить тормоза.

И пожалейте наши глаза и мозг - обращайте внимание на то, что пишите. В смысле языка.

[lev]

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

[mazzy]

Цитата:

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

...Буалтер...

Кто такой Буалтер?

[dim123]

sry бугалтер .

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

ALTER DATABASE AdventureWorks
SET READ_COMMITTED_SNAPSHOT ON;

ALTER DATABASE AdventureWorks
SET ALLOW_SNAPSHOT_ISOLATION ON;

[mazzy]

Цитата:

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

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

Э-э-э...
Прежде чем бить из пушки, попробуйте сначала локализовать проблему, как здесь уже советовали.
методика здесь http://axapta.mazzy.ru/lib/querytuning/

про ваш вопрос. читайте:
aEremenko: Kernel Rollup 3 для DAX 3.0
aEremenko: Излучая оптимизм

[dim123]

mazzy

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

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

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

по этому и думал насчет snapshot

[egorych]

Цитата:

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

проблема на много шыре

Это точно!

Цитата:

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

по этому и думал насчет snapshot

снапшот в 3.0 - как зайцу стоп-сигнал!
Смотрите, что делает бухгалтер в это время, разбивайте на транзакции помельче ну и т.д. - код рефактурить (модное такое слово, но в общем верное) надо в общем!
зы. Оракл рулит!

[Wamr]

Цитата:

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

2 сервера 1 АОС 2 база
в минуту примерно 6 раз делаетса запрос на текущее состояние скалда.
...
Не получит состояние склада .

Оно (текущее состояние) не должно блокироваться, так что явно можно править.

Цитата:

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

снапшот в 3.0 - как зайцу стоп-сигнал!

не согласен, проблему с получением состояния склада решить может

[egorych]

Цитата:

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

не согласен, проблему с получением состояния склада решить может

Каким образом? Если сама Аксапта не способна установить этот режим для транзакции. Я устанавливал этот режим для БД, поведение не изменялось.

[dim123]

inventtrans + inventdim
блокируют inventsum + inventdim

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


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

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

Правилно ли я думаю ?

[mazzy]

Цитата:

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

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

Правилно ли я думаю ?

Нет, не правильно.
Надо копать дальше.

[lev]

Цитата:

3) При приеме проиходит проверка наличия материала и создание ProdJournalTable i Line .

А проверяли сколько выполняется проверка наличия, а сколько создание журнала? что из них тормозит?

[dim123]

Цитата:

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

А проверяли сколько выполняется проверка наличия, а сколько создание журнала? что из них тормозит?

да
все нормально работает отдельно
если их запускать отдельно никаких траблов


mazzy :

почему ? с использованием партии у нас растет инвентдим и сум по 30000 записей в месяц .
плюс инвентранс так как все движения с партей

[mazzy]

Цитата:

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

почему ? с использованием партии у нас растет инвентдим и сум по 30000 записей в месяц .
плюс инвентранс так как все движения с партей

1. Это плохо
2. Это не насколько плохо, поскольку со временем у вас партии должны закрыться (обнуляться). Как в количестве, так и в сумме. А inventsum имеет признак closed. По-умолчанию, стандартные классы выбирают только незакрытые записи из inventSum.

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

В общем, барабашки нет.
Вам что советуют: локализуйте проблему, поймите ее. И прините ОСОЗНАННОЕ решение.

[lev]

Цитата:

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

да
все нормально работает отдельно
если их запускать отдельно никаких траблов

Вы меня немного неправильно поняли
Я предлагаю не отдельно запускать. А именно воссоздать ситуацию зависания!
Т.е. запустите создание ревизии, пускай работает... А в это время принимайте товар на склад, и ищите места где зависает!

[dim123]

Цитата:

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

1. Это плохо
2. Это не насколько плохо, поскольку со временем у вас партии должны закрыться (обнуляться). Как в количестве, так и в сумме. А inventsum имеет признак closed. По-умолчанию, стандартные классы выбирают только незакрытые записи из inventSum.

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

В общем, барабашки нет.
Вам что советуют: локализуйте проблему, поймите ее. И прините ОСОЗНАННОЕ решение.

согласен . не закрытых 400 000 инвентсум .
инвенддим все равно будет расти . состояние скалда на какое то число будет использовать inventtrans i inventdim ? ето проблема


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

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

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

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

компания маленкая но умудрились сделать с партиями такую лажу виновен партнер которий внедрял и посоветовал ето

[mazzy]

Цитата:

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

согласен . не закрытых 400 000 инвентсум .
инвенддим все равно будет расти . состояние скалда на какое то число будет использовать inventtrans i inventdim ? ето проблема

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

Цитата:

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

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

Наверное.

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

Цитата:

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

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

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

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