Модификация огромного количества (сотни тысяч) записей в Axapta 3.0 SP4

[Hyper]

Цитата:

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

как скажете, конечно. забота о целостности полностью на ваших плечах

Да. В детали вдаваться не буду, но о целостности данных в контексте данной задачи (не буду отвлекаться на полное ее описание) волноваться не стоит.

Цитата:

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

Конечно принципиальная. С точки зрения СУБД.

Так. И все-таки с точки зрения СУБД SQL 2000, не Аксапты, с точки зрения быстродействия есть какая-то разница делать 700 000 мелких транзакций или одну большую?

[mazzy]

Цитата:

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

Так. И все-таки с точки зрения СУБД SQL 2000, не Аксапты, с точки зрения быстродействия есть какая-то разница делать 700 000 мелких транзакций или одну большую?

ответ сильно зависит от значения свойства Recovery Model и от числа одновременно работающих пользователей.

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

Если Recovery Model = Full
то с точки зрения СУБД накладных расходов на обслуживание 700 000 мелких транзакций значительно больше, чем на обслуживание одной большой. (в этом режиме все транзакции хранятся в transaction log). в этом случае 700 000 мелких транзакций - как самоубийство тупым столовым ножом.

Если Recovery Model = Simple
то СУБД выкидывает информацию о выполненных транзакциях.
в этом случае мелкие транзакции гарантировано поместятся даже в маленьких Transaction Log. Из-за отсутствия затрат времени на рост Transaction Log (как правило очень существенных, измеряемых в долях секунды) много мелких транзакций может выполнится гораздо быстрее, чем одна большая транзакция. (накладные расходы на обслуживание транзакции измеряются килобайтами и микросекундами)

================
чтобы гарантировано сделать работу быстрой - избавьтесь от накладных расходов на рост Transaction Log. Сразу поставьте ему вменяемый размер и сразу задайте вменяемые параметры роста.

================
есть и другие различия. но они дадут проценты к производительности. в разы - вряд ли.

[Alexius]

1. Массовое обновление для СУБД лучше всего производить запросами update_recordset или если его синтаксиса не хватает, то прямыми на сервер СУБД. В этом случае сервер сможет самостоятельно оптимизировать процесс обновления. Хотя бывают и исключения

2. Если обновление будет выполняться по одной записи и целостность данных не волнует, то лучше обновлять каждую запись в своей транзакции вне зависимости от модели восстановления сервера. Если все выполнять в одной транзакции, то накладные расходы сервера СУБД на блокировки (или версионность) множества записей с лихвой перекроют расходы на обслуживание кучи транзакций.

[mazzy]

Цитата:

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

Если все выполнять в одной транзакции, то накладные расходы сервера СУБД на блокировки (или версионность) множества записей с лихвой перекроют расходы на обслуживание кучи транзакций.

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

поэтому спорно.
но мнение имеет право на жизнь.

[Zabr]

Цитата:

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

for(i=0;i<70;i++)

Нормальный вполне способ. Сам так и делаю частенько.

Цитата:

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

так что при отсутствии индекса по RecId экспериментировать, пожалуй, не имеет смысла?

Так может вам стоит построить индекс по recid ? Для 700 тыс.записей будет строиться может пару-тройку минут. Будет не нужен - отключите потом.

Цитата:

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

Какой то полной фигней вы занимаетесь, честное слово.

Это точно. За время обсуждения можно было вручную всё проапдейтить (утрирую конечно, но всё же..)

[Hyper]

Цитата:

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

Нормальный вполне способ. Сам так и делаю частенько.

Зачем же самим так делать, если я фигней занимаюсь?