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

[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) затронет все что было внутри транзакции.

[Hyper]

Цитата:

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

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

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

Цитата:

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

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

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

Цитата:

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

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

[mazzy]

Цитата:

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

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

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

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

[Hyper]

Цитата:

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

Почему это?

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

[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]

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: "лучше обновлять каждую запись в своей транзакции вне зависимости от модели восстановления сервера. Если все выполнять в одной транзакции, то накладные расходы сервера СУБД на блокировки (или версионность) множества записей с лихвой перекроют расходы на обслуживание кучи транзакций."

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

[Alexius]

Цитата:

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

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

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

[Hyper]

Цитата:

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

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

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

[Poleax]

Цитата:

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

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

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

[Hyper]

Цитата:

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

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

Спасибо за ссылку. Хотя задачи подобного рода возникают не так регулярно, чтобы изучение еще одного программного пакета себя оправдало. Но на будущее буду иметь в виду.

[mazzy]

Цитата:

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

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

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

да. спасибо.

[Hyper]

Всем спасибо за советы. На чем я остановился:

Обновление таблиц с уникальными индексами по одному полю буду проводить кусками по пять-десять тысяч записей в одной транзакции. Во-первых, код уже написан и хуже от него точно не будет, а во-вторых, исходя из обсуждения, что лучше делать при Full Recovery Model - одну транзакцию на запись или одну транзакцию на таблицу, - вопрос спорный.

Остальные таблицы (их всего несколько) я решил пока обновлять по одной транзакции на таблицу. Тесты на мизерной базе данных пока показывают, что при использовании кучи мелких транзакций процесс выполняется медленнее, чем при меньшем количестве более крупных транзакций. Конечно, это не тест, а ерунда, т.к. при большой БД все может быть по другому, настройки данной БД не идентичны настройкам БД клиента и т.д., но пока что пусть будет так. Будет возможность - проверю в нормальных условиях.