Создание большого числа заказов на продажу. Падение скорости загрузки.

[mazzy]

Цитата:

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

да, поменяю модель восстановления БД на Простую.

Э-э-э... Надеюсь не на рабочей базе?

[Eldar9x]

Цитата:

И будет чертовски обидно, если после нескольких часов работы транзакция откатится из-за недостатка места под transaction log
Не говоря уже о тех несчастных пользователях, которые ждут окончания блокировки чтобы продолжить свою никчемную работу по обработке текущих заказов, а также любых складских операций (из-за блокировки inventSum)

Ну..., по моему будет обиднее разбираться, какая часть данных создалась, а какая нет.
Хотя было же уже предложено поделить на несколько файлов. А по поводу блокировок, такие операции не обязательно делать в час-пик.

[Wamr]

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

Этим страдает и стандартный импорт.
Думаю, это ваш случай.

[mazzy]

Цитата:

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

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

Посмотрел код еще раз.
А ведь действительно - импорт в этой ветке не предполагает, что данные уже могут существовать.
Т.е. повторный импорт не предусмотрен.

Тогда согласен - лучше сделать в одну транзакцию.

Хотя более правильным было бы сделать по другому:
1. программист должен учитывать, что импорт одного и того же файла может выполняться несколько раз. либо в результате ошибки оператора, либо еще по каким причинам.
2. программист должен проверить, не была ли уже заимпортирована запись.
2.1. если уже существует, то
2.1.1. если запись была изменена, то либо ошибка, либо варнинг, либо overwrite в зависимости от настроек и логики импорта
2.1.2. если запись не изменена, то пропустить запись
2.2. если запись еще не существует, то создать ее.

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

[bobski]

Отчего же, Wamr. Ответ есть. Отвлекся. К сожалению временные таблицы не задействованы. Было бы на что грешить, кроме самого себя.

[Maxim Gorbunov]

bobski, есть предположение, что у вас список неиспользованных номеров в номерной серии растет сильно. Смотрите, серия непрерывная, при выделении номера вы говорите makeDecisionLater = true (второй параметр в NumberSeq::newGetNum()), но нигде не отмечаете выделенный номер как использованный. Скорее всего, у вас NumberSequenceList вырастает до безбожных размеров. А так как он проверяется при каждом вызове NumberSeq::num(), производительность падает потихоньку.

Проверьте NumberSequenceList. У вас там должна быть куча номеров в статусе Active. Кроме того, добавьте вызов numberSeq.used(), либо вызывайте newGetNum() с makeDecisionLater = false.

Кстати, в джобе из первого сообщения такой проблемы нет, так как там makeDecisionLater = false.

[sukhanchik]

А еще в 4.0 есть волшебный классик \System Documentation\Classes\RecordInsertList. Специально так сказать сделанный давно давно для массовых вставок. Конечно в будущих версиях его кажется убрали... Но в 4.0 его еще можно заюзать.
Смысл в том, чтобы вместо insert() использовать RecordInsertList.add(). А по завершению - RecordInserList.insertdatabase().
И еще. Может все-таки откажетесь от непрерывной номерной серии и поставите ей предварительное выделение (а может и ручками сами посчитаете номера)? Хотя бы на время импорта.

[kashperuk]

Цитата:

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

А еще в 4.0 есть волшебный классик \System Documentation\Classes\RecordInsertList. Специально так сказать сделанный давно давно для массовых вставок. Конечно в будущих версиях его кажется убрали... Но в 4.0 его еще можно заюзать.
Смысл в том, чтобы вместо insert() использовать RecordInsertList.add(). А по завершению - RecordInserList.insertdatabase().
И еще. Может все-таки откажетесь от непрерывной номерной серии и поставите ей предварительное выделение (а может и ручками сами посчитаете номера)? Хотя бы на время импорта.

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

[Wamr]

что-то мы все тут гадаем и гадаем...
может пора уже посмотреть SQL трейс и загрузку диска\памяти\проца на локальной машинке?

[belugin]

Цитата:

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

что-то мы все тут гадаем и гадаем...
может пора уже посмотреть SQL трейс и загрузку диска\памяти\проца на локальной машинке?

а еще есть TraceParser

[jaran]

Проверьте выполнение на толстом и тонком клиенте
На Axapta 3.0 SP3 в подобном коде на толстом клиенте не происходит замедления процесса создания заказов, в то время как на тонком скорость постепенно падает