SIMPLE или FULL модель восстановления баз данных?

Когда следует использовать полную модель восстановления и когда я должен использовать простую модель восстановления для баз данных?

Я всегда использовал полную модель восстановления, потому что она по умолчанию, но сегодня я столкнулся с этой ошибкой:

  

Поставщик Microsoft OLE DB для SQL Server (0x80040E14) Операция   log для базы данных «DATABASE NAME» заполнен. Чтобы узнать, почему пространство в   журнал нельзя использовать повторно, см. столбец log_reuse_wait_desc в   sys.databases

Конкретная база данных на самом деле является одной из самых маленьких и самых неактивных баз данных на моем сервере, поэтому я понятия не имею, как журнал может быть заполнен в этой базе данных, а не в других.

Чтобы сжать журнал и снова сделать доступ к базе данных, я изменил модель восстановления с FULL на SIMPLE и сменил логический файл с помощью следующей команды

alter database myDbName SET recovery simple
go
dbcc shrinkfile('LOG FILE LOGICAL NAME', 100)
go

Это помогло, но теперь мне нужно понять ПОЧЕМУ , это помогло, КАК эта ситуация началась и КАК предотвратить это в будущем?

EDIT:

Каждую ночь в 1 час мы делаем резервную копию каждой базы данных на сервере. Это делается с помощью 31 строкового скрипта, где наиболее важная часть

set @Filename = 'D:\backup\' + convert(varchar, getDate(), 112) + ' - ' + @DBName + '.bak'
set @Description = 'Full backup of database ' + @Filename
BACKUP DATABASE @DBName TO DISK = @Filename WITH INIT , NOUNLOAD , NAME = @Description, NOSKIP , STATS = 10, NOFORMAT

Является ли новая модель восстановления и databasehrink конфликтом с этим скриптом?

Мы не делаем каких-либо других резервных копий баз данных и, следовательно, не журналов транзакций, должны ли мы?

33 голоса | спросил Behrens 20 J0000006Europe/Moscow 2013, 00:08:59

1 ответ


51
  

Когда следует использовать полную модель восстановления и когда я должен использовать простую модель восстановления для баз данных?

Вы должны использовать полную модель восстановления, когда вам требуется восстановление вашей базы данных в определенный момент времени. Вы должны использовать простую модель восстановления, когда вам не требуется восстановление вашей базы данных в определенный момент времени, и когда в качестве точки восстановления достаточно последней полной или дифференциальной резервной копии. (Примечание: существует еще одна модель восстановления, зарегистрированная в массовом порядке. Дополнительные сведения о модели восстановления с большим объемом журнала см. в разделе эта ссылка )

  

Поставщик Microsoft OLE DB для SQL Server (0x80040E14) Журнал транзакций для базы данных «DATABASE NAME» заполнен. Чтобы узнать, почему пространство в журнале нельзя использовать повторно, см. Столбец log_reuse_wait_desc в sys.databases

Причина, по которой вы получили эту ошибку (скорее всего), состоит в том, что вы не создавали резервную копию своего журнала транзакций. Когда он не будет скопирован, он продолжит физически выращивать файл журнала транзакций (при условии, что авторасширение включено и разрешено maxsize), поскольку он не может повторно использовать ни одну из «частей» журнала транзакций (файлы виртуальных журналов). Он может только отмечать эти VLF для повторного использования и разрешать «обходную» структуру журнала транзакций при резервном копировании журнала транзакций (и несколько других требований, таких как активные транзакции, некоторые аспекты репликации и т. Д.).

  

Чтобы сжать журнал и снова сделать доступ к базе данных, я изменил модель восстановления с FULL на SIMPLE и сменил логический файл с помощью следующей команды

     

......

     

Это помогло, но теперь мне нужно понять, ПОЧЕМУ это помогло, КАК эта ситуация началась и КАК предотвратить это в будущем?

Это помогло вам, потому что, установив свою базу данных на простую модель восстановления, вы сказали SQL Server, что вам больше не нужно заботиться о восстановлении по времени и требовать, чтобы виртуальные файлы журналов больше не нуждались в сохранении и маркировке как активный, теперь процесс контрольной точки маркирует эти VLF как неактивные.

Выдержка /цитата взята из этой ссылки в MSDN :

  

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

Затем вы удалили файл физической базы данных и потому, что в вашем журнале транзакций было свободное пространство, теперь он смог физически сжать файл NTFS.

Чтение стоит потратить некоторое время на:

  1. Модели восстановления
  2. Управление журналами транзакций (Gail Shaw)
  3. Факторы, которые могут задержать усечение журнала
  4. >

ИЗМЕНИТЬ после редактирования :

  

Является ли новая модель восстановления и databasehrink конфликтом с этим скриптом?

Эта команда BACKUP DATABASE будет работать с моделями восстановления. Что касается рутинной базы данных ... НЕ ДЕЛАЙТЕ ЭТО !!!! Серьезно, размер вашей базы данных соответственно, и если вы используете полную модель восстановления, убедитесь, что вы выполняете рутинную и частую транзакцию лог-файлы, а не только для того, чтобы сохранить размер журнала транзакций в ожидании, но также встретить объекты точки восстановления.

  

Мы не делаем каких-либо других резервных копий баз данных и, следовательно, не журналов транзакций, должны ли мы?

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

Что касается используемой модели восстановления (простой или полной), мы не можем принять это решение за вас. Только вы, ваша бизнес-группа и ваши SLA можете.

ответил Thomas Stringer 20 J0000006Europe/Moscow 2013, 00:13:13

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132