В моем приложении сразу после восстановления я выполняю много (> 100000000) обновлений вновь созданной базы данных. Таким образом, файлы LOG разрастаются значительно.
Как я могу остановить его рост?
ПРИМЕЧАНИЕ. Установка простой модели восстановления НЕ сработает.
Кроме того, этот вопрос изначально был размещен здесь: https://stackoverflow.com/questions/4400057/how-to-stop-log-file-from-growing-in-sql-server-2008
Вам необходимо:
Как я предлагал переполнение стека:
Вам необходимо:
Можете ли вы изменить модель восстановления на простую, достаточно продолжительную, чтобы выполнить сжатие, а затем вернуть модель восстановления?
Что-то вроде:
alter database <mydb> set recovery simple
go
checkpoint
go
alter database <mydb> set recovery full
go
backup database pubs to disk = 'c:\mydb.bak' with init
go
dbcc shrinkfile (N'mydb_log' , 1)
go
Признаюсь, я позаимствовал это у http://sql-server-performance.com/Community/forums/p/28345/151682.aspx
Эта ссылка также ведет на: http://madhuottapalam.blogspot.com/2008/05/faq-how-to-truncate-and-shrink.html
Вам нужно будет чаще выполнять резервное копирование журналов. Может быть, каждые 5 минут во время этих обновлений.
Дифференциальное резервное копирование в ночное время должно помочь вам не полагаться на огромное количество резервных копий журналов, сделанных ранее, и если вы не заинтересованы в возможности восстановления на определенный момент времени.
Одна вещь, которая пришла в голову, заключается в том, что вы можете использовать массовое обновление, чтобы вставить / обновить эти 100 миллионов записей. См. Эту информацию на MSDN для обсуждения при минимальном ведении журнала с массовыми обновлениями.
Единственный реальный способ получить контроль над вашим журналом - это выполнять регулярное резервное копирование sql. Если вы не можете перейти к простой модели восстановления, тогда ваша стратегия резервного копирования должна включать выполнение резервного копирования журнала транзакций, чтобы установить для них контрольную точку. Как только контрольные точки установлены, sql server может начать восстановление дискового пространства.
Ответ прост - нет. Простая модель восстановления настолько хороша, насколько это возможно. Файл Bassically Log необходим для всего сценария записи данных (база данных НЕ записывается, когда вы фиксируете обновление).
Вы не можете остановить SQL от с помощью файл журнала, именно так работает SQL. Однако вы можете сохранить размер файла небольшого размера, убедившись, что SQL часто повторно использует файл. Это можно сделать двумя способами:
Перейти в простой режим проще всего. Если вы не можете этого сделать, делайте очень частые (каждые 10-15 минут?) Резервные копии журнала транзакций.
В обе из этих случаев вам нужно будет убедиться, что вы не делать все обновления одним огромным пакетом (UPDATE GIANTTABLE ... with no WHERE clause). Возможно, вам придется использовать UPDATE TOP, а WHILEили курсор, чтобы обновить ограниченное количество строк (скажем, 100 000 или около того).