Как лучше всего поддерживать размеры файла журнала SQL

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

Прямо сейчас я беру полную резервную копию баз данных и журналов каждый день в 5 утра. Некоторые из файлов журнала имеют объем до 300 ГБ, и даже после создания резервной копии они не уменьшаются в размере. Я могу заставить их уменьшиться в размере, запустив что-то похожее на:

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

Когда я проверяю LSN файлов резервных копий, я вижу что-то вроде:

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

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

Вопросов:

1. Почему файл журнала не сжимается после моих резервных копий? Это потому, что есть незафиксированные транзакции?
2. Сначала я думал, что я должен уменьшать файлы журнала после каждого резервного копирования в 5:00. После прочтения того, как это плохо сказывается на производительности, я теперь считаю, что мне нужно регулярно делать резервные копии журналов каждые пару часов в течение дня. Это верно?
3. Моя обычная полная резервная копия базы данных / журналов происходит каждый день в 5:00 и иногда занимает 3 часа. Если я планирую выполнять резервное копирование журнала каждый час, что произойдет, если резервное копирование журнала столкнется с резервным копированием в 5:00 утра?

1. Почему файл журнала не сжимается после моих резервных копий? Это потому, что есть незафиксированные транзакции?

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

2. Сначала я подумал, что мне следует сокращать файлы журнала после каждых 5 часов резервного копирования. После прочтения того, как это плохо сказывается на производительности, я теперь считаю, что мне нужно регулярно делать резервные копии журналов каждые пару часов в течение дня. Это верно?

Обычное и запланированное сжатие файлов не очень хорошая идея. Только тогда, когда вам нужно освободить столь необходимое пространство, вы должны подумать о DBCC SHINKFILE. Кроме того, когда вы постоянно увеличиваете свой журнал транзакций, вы можете препятствовать другим вещам, таким как восстановление базы данных. Слишком много VLF в журнале транзакций (обычная проблема, когда журнал транзакций увеличивается только с небольшим приращением хранилища), время на восстановление базы данных может быть больше, чем нужно.

3. Мое нормальное полное резервное копирование базы данных / журналов происходит каждый день в 5:00 и иногда занимает 3 часа. Если я планирую выполнять резервное копирование журнала каждый час, что произойдет, если резервное копирование журнала столкнется с резервным копированием в 5:00 утра?

Ничего не произойдет, это совершенно законная операция. Смотрите этот график ниже из MSDN . Там, где есть черная точка, эти две операции не могут происходить одновременно. Как видите, резервное копирование базы данных и журнал транзакций разрешены одновременно.

Отсюда следует, что вы должны чаще делать резервные копии журнала транзакций. Увеличение размера файла NTFS - не единственная проблема, с которой вы можете столкнуться, если не будете чаще выполнять резервное копирование журнала транзакций. Если у вас произошел сбой хранилища и ваш журнал транзакций был утерян, вы можете восстановить только к моменту времени последнего резервного копирования журнала транзакций. Если журнал транзакций будет потерян, вы не сможете сделать резервную копию хвоста журнала и восстановить его до момента сбоя. В вашем случае вы можете потерять данные за 24 часа. Но если вы будете делать резервные копии журналов транзакций каждые, скажем, 30 минут, то максимальная потеря данных будет 30 минут. В этом случае, если ваш журнал транзакций исчез, и у вас есть полная резервная копия и ваша неповрежденная цепочка журналов, вы можете восстановить эту последнюю резервную копию журнала.

Документация TechNet по усечению журнала транзакций

Основная проблема, с которой вы сталкиваетесь, заключается в том, что вы создаете резервные копии журналов один раз в день. Поведение ядра состоит в том, что записи журнала (использованное пространство) в файле журнала будут удалены только после успешного резервного копирования журнала. Это пространство освобождается при возникновении контрольной точки , но если ваша база данных находится в режиме полного / массового восстановления журнала, то записи журнала будут удалены только после успешного резервного копирования.

Резервные копии журналов предназначены для использования в сочетании с полными резервными копиями и должны запускаться с регулярным интервалом между полными резервными копиями. Этот интервал может быть любым, хотя я обычно запускаю резервные копии журналов каждые 15 минут. Ваш интервал зависит от вашей точки восстановления (RPO) и количества данных, которые вы можете потерять в случае восстановления.

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

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

1. Сделайте резервную копию вашего текущего файла журнала.

2. Установите для вашей базы данных простое восстановление

   • В «Полном восстановлении» -> «Файл журнала» не удаляются подтвержденные транзакции, а только переупорядочиваются ваши данные -> «Файл Shink» не оказывает большого влияния -> и наоборот, для простого восстановления.

3. Shink ваш файл журнала до 1 МБ или меньше (это на ваше усмотрение)

4. Установите для вашей базы данных полное восстановление.

Надеюсь, это поможет

Фонг Тран