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

[dim123]

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

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

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

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

[lev]

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

[Bober]

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

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

[dim123]

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

[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 - как зайцу стоп-сигнал!
Смотрите, что делает бухгалтер в это время, разбивайте на транзакции помельче ну и т.д. - код рефактурить (модное такое слово, но в общем верное) надо в общем!
зы. Оракл рулит!

[lev]

Цитата:

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

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

[dim123]

Цитата:

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

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

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


mazzy :

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

[mazzy]

Цитата:

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

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

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

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

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

[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

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

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

[lev]

Цитата:

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

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

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

[tolstjak]

Цитата:

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

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

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

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

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

2 сервера 1 АОС 2 база
более 70 пользователей
inventtrans более 4,0 млн. записей
inventdim 0,057 млн.записей
inventsum 0,26 мил записей

Тормозов особых не наблюдаем.
Если и бывают то только во время массовой разноски документов с проводками по главной книге с большим количеством строк. Ловим с помощью "Блокировки пользователей базы данных", а потом разбираемся конкретно с пользователем, что он в это время делал.

[ZVV]

Цитата:

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

...Ловим с помощью "Блокировки пользователей базы данных"...

Вот-вот...
В первую очередь на это посмотрите!

После беглово прочтения сложилось впечатление, что либо вам удалось по какому-то "суперантипаттерну" настроить всю систему, чтоб тормозило побольше (т.е. проблема не в Аксапте, а с дисками, например), либо банальные блокировки...
Смущает конечно что это стандарт... А стандарт ли в самом деле?

[Wamr]

диски - рейды, хорошо, конечно, но может у вас
ОЗУ мало... 1гиг какой-нибудь или
включен SysDatabaseLog на InventTrans или
сеть между АОС и SQL 10Mb или
но 15 пользователей, чтобы так напрягали систему... очень странно

[dim123]

Цитата:

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

диски - рейды, хорошо, конечно, но может у вас
ОЗУ мало... 1гиг какой-нибудь или
включен SysDatabaseLog на InventTrans или
сеть между АОС и SQL 10Mb или
но 15 пользователей, чтобы так напрягали систему... очень странно

1) 4 giga
2) 1 gig
3) автоматика которая работает через COM

да видно блокировки но а дальше ? 1 делаю журнал инвентеризации , 2 юзер начинает Производство . COM висит
запрос
select t.itemname,s.itemid,sum(s.availphysical) as cnt
from inventsum s, inventdim d, inventtable as t
where s.availphysical<>0 and t.itemid=s.itemid and d.inventlocationid='616' and d.inventdimid = s.inventdimid
and s.dataareaid='hc' and s.itemid like '7%' and d.dataareaid='hc' and t.dataareaid='hc'
group by s.itemid,t.itemname order by s.itemid

висит