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