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

[Hyper]

Цитата:

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

сформировать текст SQL запроса вида "UPDATE MyTable SET Field1=Value" и исполнить его в одной транзакции в отдельном подключении (new UserConnection()).

С UserConnection (table1.setUserConnection()) я сегодня тоже провозился. Не буду даже начинать. Расстроила меня сегодня третья Аксапта.

Правда, прямое использование SQL я не пробовал. Почему-то считал, что с точки зрения SQL сервера это будет тоже самое, что и doupdate из Аксапты - вид сбоку. Это не так?

Цитата:

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

в этой конструкции у Вас не будет Where

Не понял, почему не будет? В каждой записи поля заполняются разными значениями, каким же образом я буду определять какую запись я сейчас буду модифицировать?

[mazzy]

Цитата:

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

С UserConnection (table1.setUserConnection()) я сегодня тоже провозился. Не буду даже начинать. Расстроила меня сегодня третья Аксапта.

Какой то полной фигней вы занимаетесь, честное слово.
Вы ж насилуете Аксапточку почем зря. Она сама отдаст и все сделает.
помните только одно: 700тыс - не самый большой объем. работали же.

ищите причину тормозов.
с огромной вероятностью, они где-то на стороне SQL.

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

[mazzy]

Кстати, насчет "ждать чего угодно".
Скажите, метод update на вашей обновляемой таблице переопределен?
Если переопределен, то он ничего не запоминает во внутренние структуры в пределах одной транзакции?

Цитата:

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

Правда, прямое использование SQL я не пробовал. Почему-то считал, что с точки зрения SQL сервера это будет тоже самое, что и update из Аксапты - вид сбоку. Это не так?

Если у таблицы переопределен метод update, то update из Аксапты работает по-другому (не эквивалентен update из SQL-сервера)

кроме того, аксапта может перейти в другой режим обновления
если таблица отслеживается в SysDatabaseLog.

Но главное - посмотрите в метод update.

[Hyper]

Цитата:

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

Скажите, метод update на вашей обновляемой таблице переопределен?

Для данной задачи используется только doupdate.

[mazzy]

Цитата:

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

Для данной задачи используется только doupdate.

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

но в рамках данной темы это значит, что побочных эффектов не должно - doupdate аксапты эквивалентен update одной (!) записи с SQL-сервера.

[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. Сразу поставьте ему вменяемый размер и сразу задайте вменяемые параметры роста.

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