Обслуживание журнала транзакций при переходе на простое восстановление

Фон:

Я недавно унаследовал более 50 серверов SQL с более 450 базами данных. Ночные резервные копии составляют примерно 8 ТБ, и, разумеется, мы используем больше дискового пространства, чем нам хотелось бы. Все базы данных настроены на полное восстановление, и журналы транзакций никогда не копировались. Я просмотрел все SQL-серверы и выявил серверы с низким приоритетом, для которых требуется только ночное резервное копирование и где приемлем день потери данных.

Вопрос:

Я переключаю много баз данных с низким приоритетом в SIMPLEрежим восстановления с FULL. Будут ли усечены существующие журналы транзакций (при создании контрольных точек)? Некоторые из существующих журналов транзакций имеют размер 50-100 ГБ; Каков наилучший подход к определению того, к чему я должен сокращать их для целей продвижения вперед? Я явно не хочу держать их такими большими. Или они со временем сами уменьшатся (я не думаю, что они будут)?

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

Чтобы уменьшить LDFразмер файла до минимально возможного, выполните шаги, указанные Кимберли Триппом здесь: 8 шагов для повышения пропускной способности журнала транзакций.

1. Подождите, пока в базе данных будет низкая активность

2. Запустить в SSMS:

   DBCC SHRINKFILE(transaction_log_logical_filename, TRUNCATEONLY)

3. Измените размер файла журнала транзакций:

   ALTER DATABASE db_name
   MODIFY FILE ( NAME = transaction_log_logical_filename, SIZE = new_size)
   

Я переключаю множество баз данных в режим восстановления SIMPLE из режима полного восстановления (T-Logs и восстановление на определенный момент времени не требуется). Будут ли усечены существующие журналы транзакций (при создании контрольных точек)?

В простой модели восстановления ядро ​​базы данных будет выдавать автоматические контрольные точки, а его частота определяется интервалом восстановления (расширенные настройки сервера) или заполнением журнала на 70%.

Если у вас не возникнут какие-либо длительные транзакции, которые задержат усечение журнала, автоматическая контрольная точка будет обрезать неиспользуемую часть T-журнала.

Некоторые из существующих журналов транзакций имеют размер 50-100 ГБ, что является наилучшим подходом при определении того, к чему я должен сокращать их для целей продвижения вперед. Я явно не хочу держать их такими большими.

Если для модели восстановления базы данных установлено значение ПОЛНОЕ для тех баз данных с 50-100 ГБ T-журналов, то вам придется начать делать частые резервные копии T-журналов. Помните, что в модели полного восстановления после создания цепочки резервного копирования журнала даже автоматические контрольные точки не приводят к усечению журнала.

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

Или они со временем сами уменьшатся (я не думаю, что они будут)?

Как отметил @TomTom, это ручная операция.

Прочитать :

• Управление размером файла журнала транзакций
• Как сжать журнал сервера SQL - Отлично Пишите.
• Как работают контрольные точки и что регистрируется - Автор: Пол Рэндал

На многие вопросы мы не можем ответить. Как долго это кусок строки?

Некоторые из существующих журналов транзакций имеют размер 50-100 ГБ, что является наилучшим подходом при определении того, к чему я должен сокращать их для целей продвижения вперед.

Пока они должны быть. Я предлагаю не сокращаться. Бревна Trunacate, зайдите через неделю и посмотрите, сколько места занято, ТО решите. Но вы должны ответить на этот.

Ночные резервные копии составляют примерно 8 ТБ, и, разумеется, мы используем больше дискового пространства, чем нам хотелось бы.

Так зачем превращать их в простые? Я имею в виду, серьезно.

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

Немного логики скажет вам, что если вы их урежете ОДИН РАЗ, тогда вы, скорее всего, будете использовать ОЧЕНЬ меньше места для их резервного копирования. В результате вы можете сохранить их в режиме полного восстановления. Попробуйте это в первую очередь. Если они увеличивают громкость и т. Д., То резервные копии журнала в будущем будут намного меньше.

Я просмотрел все SQL-серверы и определил НИЗКИЕ приоритетные серверы, для которых требуется только ночное резервное копирование и потеря данных в течение нескольких дней даже в случае аварии не будет проблемой (базы данных факсов и тому подобное).

Да. До тех пор, пока вы не окажетесь в суде и не получите свою задницу за то, что у вас нет важных юридических документов. Знаете ли вы, что журналы факсов вполне могут быть частью того, что вы должны хранить годами в качестве деловой информации? Это так в моей юрисдикции (10 лет). Если вы являетесь акционерной компанией U, вас может удивить подобное (SOX). Невыполнение этого требования делает ОЧЕНЬ плохо в суде, если вы хотите доказать, что не получили факс. Или отправил один. Никого не волнует, случалось ли это ежемесячно назад, и у вас есть более свежие журналы - вы не соответствуете требованиям закона. Удостоверьтесь, что это подписано кем-то ОЧЕНЬ высоким, потому что ваш бизнес не критичен, может быть причиной увольнения.

Или они со временем сами уменьшатся (я не думаю, что они будут)?

Нет. И они не должны этого делать. Изменение размера журналов выполняется вручную, за исключением баз данных с небольшим объемом.