Имеем 1С 8.2 и MS SQL 2008

Задача ограничить рост журнала транзакций

В свойствах базы установил
Модель восстановления: Простая.

При попытки сделать УРИБ обмен (файл более 2х- гигов) лог вырастает до ограничения указанных в свойствах базы и 1С-ка выдает ошибку. Журнал транзакций полный.

Сейчас ограничения на лог отключен. идет обмен и журнал уж 25 гигов (почти догнала по размеру саму базу, которая 27 гигов)

Отсюда вопрос. При таких параметров можно ограничить журнал транзакций скажем двумя гигабайтами?

а обмен почаще можно делать? файл 2ГБ это xml или zip?
Лог можно шринкать периодически. В настройках файлов БД SQL там-помоему алгоритм увеличения файла лога можно указать и ограничения тоже. Могу ошибаться.

(1) xml. Чаще врядли
Просто данные выгружаются в централку,а из централки все эти данные грузятся в другую централку, вот и получается большой обмен

В настройках задаю ограничения, но 1С выпадает в ошибку, что мол журнал то полный

периодически высвобождайте неиспользуемое пространство в файле лога,
процентов на 90% уменьшится, я не особо спец по склсерверу

(0) И что 50 гб на сервере это проблема? Зачем вообще ограничивать рост журнала?

(4) лучший ответ конечно. я не особо спец, но совет дать могу. :)

(4) По большей части чисто спортивный интерес. Говорят же что если поставить модель восстановления простая - то лог расти не будет. Но что то не получается у меня

(6) При простой модели, лог растет, но не так активно. Так же в 2008, при простой можно его обрезать в 0.
Можно делать бекап, а потом обрезать.

(7) Т.е. я нее могу ограничить рост лога, а максимум настроить автообразания и поиметь тормоза от постоянного туда-сюда?

(8) Туда-сюда - да, но тормозов особых не будет. Но обрезать лог можно только если есть бекап.

(9) Ну как минимум увеличивается фрагментация жесткого диска. Плюс затраты на рост и обрезания. Вообшем быстрее точно не будент

На простой модели восстановления лог растет меньше всего, т.к. записи из него удаляются сразу после завершения транзакции. Если в транзакции меняется очень много данных, он все равно будет расти, пока транзакция не будет подтверждена. Автоматически уменьшать лог крайне не рекомендуется, лучше выделить ему сразу достаточно места. Если такое поведение считаете неправильным, надо искать, как можно разбить транзакцию на несколько маленьких (не знаю механизмов 1С - ничего посоветовать не могу).

(0) в обмене стоит галочка про 1000 элементов в транзакции?

(8) можно ограничить рост лог файла

(13) это только к ошибкам приведет, как уже было написано. Надо убирать причину такого роста, а не тупо запрещать ему расти.

В свойствах базы поставь автосжатие (autoshrink) тогда лог будет автоматом сжиматься + не ограничивай размер лога.

А причина простая, слишком много мелких запросов модифицирующих базу.

Если поставить автосжатие, будет не база, а мелко порезанная капуста... Фрагментация данных моет вырасти очень быстро, что скажется на быстродействии. В данном случае, судя по размеру лога, в одной транзакции происходит измнение практически всех страниц базы. Это может быть сделано и одним запросом. Ну и в одной транзакции, главное - из-за этого лог растет. Иначе на простой модели восстановления он бы не рос.

(12) Да как раз по 1000 и стоит

(13) Нельзя

Обмен еще идет, и лог уже обогнал базу. 27,5

Закончился обмен. проверил настройке стоит по 500 объектов в транзакции размер лога 29,7 Гб

(0) Помойму скуль ведет себя как положено, когда у него будет время, он займется логом. Экономить место затратная и редко осмысленная процедура.
Отключать логу автогроу можно только если ты абсолютно в себе уверен, может упасть насмерть. Лучше сразу выкуси под него гигов 20-30 и поставь прирост 5ГБ - рост лога критичная процедура, тем более он у тебя раз в 100 растет.
И обрати внимание: http://msdn.microsoft.com/en-us/library/ms189275.aspx
"The simple recovery model risks significant work-loss exposure if the database is damaged." Если 1с со скулем не договорятся о логе, ты получишь significant work-loss exposure. Дай скулю все что он хочет.

(21) Это бух.база, нужно чтобы налоги рисовать. Так что не критична к потери данных или к пару дней простоя.