Можно ли изменить модель восстановления на простой, достаточно долго чтобы выполнить уменьшение и затем задержать модель восстановления?
Что-то как:
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
Поскольку я предложил на stackoverflow:
Вы должны были бы:
Одна вещь, которая пришла на ум, состоит в том, что Вы могли использовать массовое обновление для вставления/обновления их 100M записи. Посмотрите эту информацию в MSDN для обсуждения минимального входа с массовыми обновлениями.
Вы не можете мешать SQL использовать файл журнала, это, как SQL работает. Можно, однако, все еще сохранить файл маленьким путем проверки, что SQL часто снова использует файл. Два способа сделать это:
Переключение на режим Simple является самым легким. Если Вы не можете сделать этого, то возьмите очень частый (каждые 10-15 минут?) резервные копирования журнала транзакций.
В обоих из этих случаев необходимо будет удостовериться, что Вы не делаете всех обновлений в одном огромном пакете (UPDATE GIANTTABLE ... with no WHERE clause
). Вы, возможно, должны были бы использовать UPDATE TOP
, a WHILE
, или курсор, чтобы только обновить ограниченное количество строк (говорят приблизительно 100,000).
Вы должны были бы:
Необходимо будет выполнять резервные копирования журнала чаще. Возможно, каждые 5 минут во время тех обновлений случай.
Дифференциальное резервное копирование ночью должно смочь помочь Вам не доверие подавляющей сумме резервного копирования журнала, взятого прежде, и если Вам не интересно при наличии возможности восстановления момента времени.
Единственный реальный способ получить контроль Вашего входа состоит в том, чтобы выполнить регулярные sql резервные копирования. Если Вы не можете перейти к простой модели восстановления, то Ваша стратегия резервного копирования должна включать работающие резервные копирования журнала транзакций для установки контрольной точки на них. После того как контрольные точки установлены, SQL-сервер может начать восстанавливать дисковое пространство.