Размер виртуального журнала SQL Server

8

Я отчасти случайный администратор баз данных, будучи разработчиком, унаследовавшим пару серверов баз данных (2005 и 2008 гг.) От кого-то, кто мало знал об администрировании баз данных и, похоже, еще меньше интересовался изучением этой темы.

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

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

Я узнал об этом в SQL Server 2012, и мне было интересно, правда ли это о 2005 и / или 2008 году, и что именно это означает: «Когда база данных использует простую модель восстановления, компонент Database Engine усекает журнал транзакций после контрольной точки. [. ..] Database Engine запускает автоматическую контрольную точку в простой модели восстановления, когда виртуальный журнал заполняется на 70 процентов ». Где указан размер виртуального журнала?

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

Любая помощь будет принята с благодарностью.

sql-server transaction-log Петер Бродин
источник
1
Прочитайте этот rusanu.com/2012/07/27/how-to-shrink-the-sql-server-log и посмотрите, проливает ли он свет на происходящее.
Ремус Русану

Ответы:

6

Один файл журнала транзакций имеет физический размер (который вы видите на диске), и он также разбит внутри физического файла на логические разделы, называемые виртуальными файлами журнала (VLF).

И автоматическое увеличение, и автоматическое сжатие работают с файлом журнала физических транзакций.

Усечение журнала транзакций (также называемое «очисткой журнала») работает с логическими разделами журнала транзакций (VLF) и не влияет на размер физического файла. Эта часть часто является предметом путаницы.

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

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

Это поведение одинаково для SQL Server 2005+.

Джон Сайгель
источник
Спасибо, это то, что я искал, когда задавал вопрос. Я пришел к тем же выводам после прочтения более раннего ответа Ремуса.
Петтер Бродин
2

Итак, вот что я нашел после прочтения других ответов здесь и проведения некоторых собственных исследований:

Вопрос: «Сжатие ли в действительности сжимает файл (ы) журнала или только БД?» A: Из того, что я понимаю: да, это так. Автоусадка устанавливается на уровне базы данных и влияет на все файлы (это видно, если щелкнуть правой кнопкой мыши базу данных -> свойства -> файлы или выполнить запрос 1). Autogrow, однако, работает на уровне файлов.

Q: "Где указан размер виртуального журнала?" A: Смотрите ответ Джона Зигеля и ссылку Ремуса. Чтобы увидеть физический и логический размер журнала, используйте запрос 2

Одна из проблем заключается в том, что если в базе данных был активирован режим полного восстановления, который был увеличен до большого размера, а затем был изменен режим восстановления на простой, контрольная точка не будет запущена, поскольку VLF автоматически сработал. Можно попытаться решить эту проблему (см. Ответ Ремуса о возможных проблемах с заголовком / концом файлов журнала), выполнив запрос 3, который уменьшит размер файла журнала до того размера, который был при его создании.

Запросы:

1)

SELECT name, physical_name AS current_file_location, DB_NAME(database_id) AS dbname
FROM sys.master_files
WHERE DB_NAME(database_id) = 'mydb'

2) 

DECLARE @tmpt TABLE(
    dbname VARCHAR(255),
    logsize DECIMAL,
    logspaceused DECIMAL,
    stat INT
)

INSERT INTO @tmpt
    EXEC ('DBCC SQLPERF(LOGSPACE)')

SELECT * FROM @tmpt WHERE dbname LIKE 'mydb' ORDER BY logspaceused DESC

3)

checkpoint
DBCC SHRINKFILE('logfile_name')
Петер Бродин
источник
2

Как вы указали в своем вопросе, в SQL 2005 и 2008 после контрольной точки файл журнала транзакций также будет усечен.

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

SQL Server 2005: http://technet.microsoft.com/en-us/library/ms189085(v=sql.90).aspx

SQL Server 2008: http://technet.microsoft.com/en-us/library/ms189085(v=sql.100).aspx

Небо
источник
Да, это мой план в долгосрочной перспективе, но сейчас я просто хочу избавиться от автоусадки.
Петтер Бродин
Изменения - это то, что вы хотите изменить их на полное восстановление, но прежде чем оценивать, действительно ли это необходимо. Если вам нужно восстановить как можно ближе к катастрофе, то вам нужно. Если вы вернетесь к последней полной резервной копии (обычно по ночам), то режим восстановления SIMPLE будет работать нормально.
cfradenburg