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

[mazzy]

Цитата:

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

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

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

[jaran]

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

[Eldar9x]

Цитата:

Попробуйте делать коммит хотя бы пачками, по 1000 штук например...

действительно, я вообще не понимаю зачем создавать для каждой строки транзакцию.
Если у вас там выше (для общего цикла по файлу) нет общей обрамляющей транзакции, тогда в базе будет каша, часть строк создаться, часть нет.
Я бы вообще сделал в виде:

ttsbegin;
  
{

}
ttscommit;

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

Цитата:

А вот это точно замедлит работу.
Хотя для отладки можно и так попробовать.

Ну да. Имелось ввиду не для каждой строки. Например, каждые 500 записей.

[mazzy]

Цитата:

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

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

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

[Eldar9x]

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

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

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

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

[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