Как мешать Файлу журнала вырастить в SQL Server 2008?

Вам, вероятно, придется снять подозрительный сервер фермы, пока это не работает правильно.

3
задан 23 May 2017 в 15:41
8 ответов

Можно ли изменить модель восстановления на простой, достаточно долго чтобы выполнить уменьшение и затем задержать модель восстановления?

Что-то как:

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

2
ответ дан 3 December 2019 в 05:08

Поскольку я предложил на stackoverflow:

Вы должны были бы:

  1. Переключитесь на простой режим восстановления или копируйте журнал транзакций более часто
  2. Примените свои обновления в меньших пакетах с механизмом цикличного выполнения.
2
ответ дан 3 December 2019 в 05:08

Одна вещь, которая пришла на ум, состоит в том, что Вы могли использовать массовое обновление для вставления/обновления их 100M записи. Посмотрите эту информацию в MSDN для обсуждения минимального входа с массовыми обновлениями.

0
ответ дан 3 December 2019 в 05:08

Вы не можете мешать SQL использовать файл журнала, это, как SQL работает. Можно, однако, все еще сохранить файл маленьким путем проверки, что SQL часто снова использует файл. Два способа сделать это:

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

Переключение на режим Simple является самым легким. Если Вы не можете сделать этого, то возьмите очень частый (каждые 10-15 минут?) резервные копирования журнала транзакций.

В обоих из этих случаев необходимо будет удостовериться, что Вы не делаете всех обновлений в одном огромном пакете (UPDATE GIANTTABLE ... with no WHERE clause). Вы, возможно, должны были бы использовать UPDATE TOP, a WHILE, или курсор, чтобы только обновить ограниченное количество строк (говорят приблизительно 100,000).

0
ответ дан 3 December 2019 в 05:08

Вы должны были бы:

  1. Переключитесь на простой режим восстановления или копируйте журнал транзакций более часто
  2. Примените свои обновления в меньших пакетах с механизмом цикличного выполнения.
3
ответ дан 3 December 2019 в 05:08

Необходимо будет выполнять резервные копирования журнала чаще. Возможно, каждые 5 минут во время тех обновлений случай.

Дифференциальное резервное копирование ночью должно смочь помочь Вам не доверие подавляющей сумме резервного копирования журнала, взятого прежде, и если Вам не интересно при наличии возможности восстановления момента времени.

1
ответ дан 3 December 2019 в 05:08

Единственный реальный способ получить контроль Вашего входа состоит в том, чтобы выполнить регулярные sql резервные копирования. Если Вы не можете перейти к простой модели восстановления, то Ваша стратегия резервного копирования должна включать работающие резервные копирования журнала транзакций для установки контрольной точки на них. После того как контрольные точки установлены, SQL-сервер может начать восстанавливать дисковое пространство.

0
ответ дан 3 December 2019 в 05:08

Простой ответ - Вы не делаете. Простая модель восстановления так хороша, как это добирается. Файл журнала Bassically необходим для целого сценария записи данных (база данных НЕ записана, когда Вы фиксируете обновление).

0
ответ дан 3 December 2019 в 05:08

Теги

Похожие вопросы