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

[Hyper]

Цитата:

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

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

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

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

Цитата:

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

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

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

[mazzy]

Цитата:

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

Спасибо, но у клиента как раз SQL 2000. Надо мне было сразу уточнить. Смотрю пункт 1:

Угу. Надо было уточнить.

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

все-таки, скажите пожалуйста:
= что установлено в Recovery Model в свойствах вашей базы?
= каков размер Transaction Log в вашей базе?
= каковы настройки прироста Transaction Log в вашей базе?
= сколько свободного места на диске, где находится Transaction Log? (вопрос связан с тем, что на NTFS дисках сильно возрастает время увеличения файла, если осталось мало места)

и все-таки - не занимайтесь ерундой.
проведите ваше обновление при неработающих пользователях (в пакетнике, ночью).
Честное слово, 700тыс записей - не такое уж и большое число записей. Даже для SQL2000.

Цитата:

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

Вот и занимаюсь. SQL 2000 каким-то образом влияет на следующие рекомендации, или они остаются в силе?

никак. также сразу поставьте нормальный размер и нормальный прирост.
в SQL2000 был прирост по-умолчанию в 10%.

Поэтому если ваш Transaction Log изначально мал, то он рос маленькими кусочками (на что тратится очень много времени). Кроме того, сильно увеличивается фрагментация диска.

сделайте прирост фиксированными и относительно большими кусками 200-300Мб.

Цитата:

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

А вот следующее было для меня откровением, я был уверен, что разница принципиальная, а не "только логическая":

Конечно принципиальная. С точки зрения СУБД.
Но с точки зрения Аксапты - особой разницы нет.
С точки зрения Аксапты - в случае чего, откат (rollback) затронет все что было внутри транзакции.

[mazzy]

Цитата:

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

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

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

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

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

[mazzy]

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

Цитата:

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

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

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

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

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

[Hyper]

Цитата:

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

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

Других пользователей во время обновления транзакций в системе быть не должно.

Цитата:

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

все-таки, скажите пожалуйста:
= что установлено в Recovery Model в свойствах вашей базы?
= каков размер Transaction Log в вашей базе?
= каковы настройки прироста Transaction Log в вашей базе?
= сколько свободного места на диске, где находится Transaction Log? (вопрос связан с тем, что на NTFS дисках сильно возрастает время увеличения файла, если осталось мало места)

Скорее всего у меня нет прав доступа к клиентскому SQL серверу, так что быстро уточнить может не получиться. Завтра проверю. В любом случае все рекомендации донесу.

Цитата:

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

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

[mazzy]

Цитата:

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

Других пользователей во время обновления транзакций в системе быть не должно.

Почему это?
Впрочем, как скажете.

Если других пользователей нет, то и в SQL2000 разбивать на блоки нет никакого смысла.

[Hyper]

Цитата:

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

Почему это?

В смысле - не ожидается, не будет.

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

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

[Alexius]

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

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

[mazzy]

Цитата:

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

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

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

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

[Zabr]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

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

[Hyper]

Recovery Model: Full
Space allocated for Transaction Log: 80 MB
Transaction Log File Growth: 500 MB
Свободного места на диске, где находится Transaction Log: 204 GB

О настройках логов уже не беспокоюсь.

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

Хоть бери да бросай монетку.

[Hyper]

Цитата:

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

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

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

[Alexius]

Цитата:

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

Хоть бери да бросай монетку.

Лучше попробовать оба варианта на тестовой копии базы и рассказать результаты общественности

[Hyper]

Цитата:

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

Лучше попробовать оба варианта на тестовой копии базы и рассказать результаты общественности

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

[Poleax]

Цитата:

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

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

программа для генерации тестовых данных для таблиц баз данных SQL Server ?

[mazzy]

Цитата:

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

Recovery Model: Full
Space allocated for Transaction Log: 80 MB
Transaction Log File Growth: 500 MB
Свободного места на диске, где находится Transaction Log: 204 GB

О настройках логов уже не беспокоюсь.

да. спасибо.