Сжатие файла лога транзакций MS SQL
Чаще всего к этому методу прибегают, когда MS SQL не настроено ограничение по размеру файла лога и отсутствуют планы обслуживания в результате чего на диске заканчивается место, а решить проблему необходимо срочно. Для этого нам нужно уменьшить распухший *.ldf файл. В этом нам поможет инструмент сжатие (shrink).
Для выполнения процедуры сброса пароля пользователю не нужно обладать какими-то специфическими навыками программиста 1С. Первым делом, перед началом подобного рода действий, необходимо сделать резервную копию базы на тот случай, если что-то пойдёт не так.
Пункт 1. Модель восстановления
Устанавливаем модель восстановления простая (simple). ПКМ на базе / свойства (properties) / параметры (options) / модель восстановления (Recovery model) / простая (simple) / OK.
Открываем свойства базы данных
Выбираем модель восстановления — простая
Пункт 2. Сжатие лога транзакций
Сжимаем лог транзакций. ПКМ на базе / задачи (tasks) / сжать (shrink) / файлы (files) / установить тип файла (file type) / Журнал (log) / в операция сжатия (shrink action) / Реорганизовать страницы, перед тем осводить неиспользуемое место (reorganize pages before releseasing unused space) / сжать файл (shrink file to) / указать приемлемый размер лога.
Сжать файл лога транзакций.
Сжимаем до 0 Мб
Пункт 3. Меняем модель восстановление на изначальную
ПКМ на базе — свойства (properties) — параметры(options) / модель восстановления (recovery model) / полная (full) / OK
Выбираем модель восстановления — полная
Внимание: данный способ не решает проблему, а снимает симптом. Рекомендую настроить максимальный размер лога или план обслуживания бд.
Как уменьшить файл логов транзакций SQL базы?
Дана база SQL с файлом логов транзакции.
Каждую ночь автоматически через Microsoft SQL Server Management Studio 2016 делаются полные бэкапы.
Модель восстановления — полная. Автосжатие отключено. Теперь о проблеме.
Размер базы — 4 Гб, логов — 49 Гб, что неприемлимо.
Хочу освободить физическое место на диске.
При выборе сжатия файла журнала он указывает на 17 Мб. (0%)
Отслеживать
31.1k 3 3 золотых знака 20 20 серебряных знаков 40 40 бронзовых знаков
задан 20 фев 2018 в 9:00
user284751 user284751
3 1 1 серебряный знак 5 5 бронзовых знаков
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Полная модель восстановления подразумевает регулярные бэкапы журнала транзакций. После каждого бэкапа журнал транзакций сокращается.
Если вы не собираетесь делать регулярные бэкапы — модель восстановления нужно сменить на простую.
Отслеживать
ответ дан 20 фев 2018 в 10:18
Pavel Mayorov Pavel Mayorov
58.3k 7 7 золотых знаков 71 71 серебряный знак 145 145 бронзовых знаков
При использовании полной модели восстановления или модели восстановления с неполным протоколированием, необходимо регулярно создавать резервную копию журнала транзакций, для снижения вероятности потери результатов работы и для усечения журнала транзакций.
Также существует возможность усечения файла лога:
USE AdventureWorks2012; GO -- Truncate the log by changing the database recovery model to SIMPLE. ALTER DATABASE AdventureWorks2012 SET RECOVERY SIMPLE; GO -- Shrink the truncated log file to 1 MB. DBCC SHRINKFILE (AdventureWorks2012_Log, 1); GO -- Reset the database recovery model. ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL; GO Как через SQL 2016 в планировщике сжать и почистить log.ldf (лог транзакций) файл от базы данных?
Всем привет.
Из за большого размера файла log.ldf, который стал примерно 150Gb и является историей транзакция базы данных SQL, возникла необходимость его уменьшить
Файл позволяет вернуться к любой точке времени и восстановить базу на указанное время.
Т.к. настроены полные бэкапы в планировщике и достаточно часто делаются, то необходимости в этом журнале особо нет, хотя было бы не плохо иметь всегда месячную версию.
Подскажите как через планировщик настроить сжатие и очистку этого файла после успешно сделанного бэкапа?
- Вопрос задан более трёх лет назад
- 3835 просмотров
Комментировать
Решения вопроса 1
Владимир Коротенко @firedragon
Не джун-мидл-сеньор, а трус-балбес-бывалый.
DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);Ответ написан более трёх лет назад
Нравится 1 1 комментарий
kipishio kipishio @kipishio Автор вопроса
Спасибо. Уже смотрю мануал.
Ответы на вопрос 2
Файл позволяет вернуться к любой точке времени и восстановить базу на указанное время.
Этот файл не позволяет этого сделать. Правильно настроенное резервное копирование, включающее в себя резервные копии журнала транзакций позволяет восстановить БД на любой (с оговорками) момент времени.
Подскажите как через планировщик настроить сжатие и очистку этого файла после успешно сделанного бэкапа?
Полный бэкап не влияет усечение журнала транзакций. Если ваша база в полной модели восстановления (что, видимо, так), и вы делаете только полные резервные копии — ваш журнал транзакций будет только расти, сколько бы шринков (DBCC SHRINKDATABASE/SHRINKFILE) вы не делали.
Грамотный подход для того, чтобы не страдать от разрастания журнала транзакций: почитать про модели восстановления; виды резервных копий (включая резервные копии журнала транзакций); настроить резервное копирование журнала транзакций с такой частотой, которая обеспечит оптимальные для вас: размер файла журнала транзакций и объём допустимой потери данных; разово обрезать журнал транзакций с помощью DBCC SHRINKFILE.
Быстрый подход: перевести бд в простую модель восстановления (alter database set recovery simple), выполнить инструкцию из первого ответа и забыть про рост журнала транзакций и восстановление на момент времени.
Управление размером файла журнала транзакций
В этой статье описывается, как отслеживать размер журнала транзакций SQL Server, сжимать журнал транзакций, добавлять или увеличивать файл журнала транзакций, оптимизировать tempdb скорость роста журнала транзакций и управлять ростом файла журнала транзакций.
Эта статья относится к SQL Server. Хотя и очень похоже, сведения об управлении размером файлов журнала транзакций в Управляемый экземпляр SQL Azure см. в статье «Управление файловым пространством для баз данных в Управляемый экземпляр SQL Azure». Сведения о База данных SQL Azure см. в разделе «Управление пространством файлов для баз данных в База данных SQL Azure».
Общие сведения о типах дискового пространства для базы данных
Для управления файловым пространством базы данных важно разобраться со следующими объемами дискового пространства.
| Объем пространства базы данных | Определение | Комментарии |
|---|---|---|
| Место, занятое данными | Объем пространства, используемого для хранения данных базы данных. | Как правило, используемое пространство увеличивается (уменьшается) при операциях вставки (удаления). В некоторых случаях используемое пространство остается неизменным при операциях вставки или удаления в зависимости от объема и шаблона данных, участвующих в операции и фрагментации. Например, удаление одной строки на каждой странице данных не обязательно приведет к уменьшению используемого пространства. |
| Выделенное пространство данных | Объем форматированного файлового пространства, который стал доступным для хранения данных базы данных. | Объем выделенного пространства увеличивается автоматически, но никогда не уменьшается после удалений. Такое поведение гарантирует, что будущие вставки выполняются быстрее, так как пространство не нуждается в переформатировании. |
| Выделенное, но неиспользуемое пространство данных | Разница между объемом выделенного и используемого пространства данных. | Это количество представляет максимальный объем свободного пространства, которое можно освободить путем сжатия файлов данных базы данных. |
| Максимальный размер данных | Максимальный объем пространства, который можно использовать для хранения данных базы данных. | Объем выделенного пространства данных не может превышать максимальный размер данных. |
На следующей схеме показана связь между разными типами дискового пространства для базы данных.
Запрос одной базы данных для сведений о пространстве файлов
Используйте следующий запрос, чтобы вернуть объем выделенного места в файле базы данных и объем неиспользуемого пространства. Единицы результатов запроса указываются в МБ.
-- Connect to a user database SELECT file_id, type_desc, CAST(FILEPROPERTY(name, 'SpaceUsed') AS decimal(19,4)) * 8 / 1024. AS space_used_mb, CAST(size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS decimal(19,4)) AS space_unused_mb, CAST(size AS decimal(19,4)) * 8 / 1024. AS space_allocated_mb, CAST(max_size AS decimal(19,4)) * 8 / 1024. AS max_size_mb FROM sys.database_files; Мониторинг используемого пространства журнала
Для мониторинга используемого пространства журнала используйте sys.dm_db_log_space_usage. Это динамическое административное представление возвращает сведения об используемом сейчас журналом объеме пространства и сообщает, когда журнал транзакций требует усечения.
Сведения о текущем размере файла журнала, его максимальном размере и параметре автоматического увеличения файла также можно использовать size max_size growth столбцы и столбцы для этого файла журнала в sys.database_files.
Избегайте переполнения содержащего журналы диска. Хранилище журналов должно отвечать требованиям к числу операций ввода-вывода в секунду и низкой задержке для транзакционной нагрузки.
Сжатие файла журнала
Чтобы уменьшить физический размер файла физического журнала, возвращая свободное место в файле операционной системе, сжать файл журнала. Сжатие делает разницу только в том случае, если файл журнала транзакций содержит неиспользуемое пространство.
Если файл журнала заполнен, скорее всего, из-за открытых транзакций, изучите , что предотвращает усечение журнала транзакций.
Операции сжатия не следует рассматривать как обычную операцию обслуживания. Файлы данных и журналов, увеличивающиеся из-за регулярных, повторяющихся бизнес-операций, не нуждаются в операциях сжатия. Команды сжатия могут повлиять на производительность базы данных во время выполнения, поэтому по возможности их следует выполнять в периоды низкого уровня использования. Не рекомендуется сжимать файлы данных, если из-за обычной рабочей нагрузки приложения файлы снова будут увеличиваться до того же выделенного размера.
Обратите внимание на потенциальное негативное влияние на производительность сжатия файлов базы данных, см. раздел «Обслуживание индекса» после сжатия.
Перед сжатием следует учесть факторы, которые могут вызвать задержку усечения журнала. Если после сжатия журнала снова потребуется дисковое пространство, размер журнала транзакций снова будет увеличиваться, что повлияет на производительность во время операций увеличения. Дополнительные сведения см. в Рекомендации.
Вы можете сжать файл журнала, только если база данных активна и хотя бы один виртуальный файл журнала (VLF) свободен. В ряде случаев сжатие невозможно до тех пор, пока не выполнена следующая операция усечения журнала.
Такие факторы, как длительная транзакция, могут хранить VLFs активными в течение длительного периода, могут ограничить сжатие журналов или даже предотвратить сжатие журнала вообще. Дополнительные сведения см. в разделе Факторы, которые могут вызвать задержку усечения журнала.
Сжатие файла журнала удаляет виртуальные файлы журнала, которые не содержат частей логического журнала (то есть, неактивные виртуальные файлы журнала). При сокращении файла журнала транзакций неактивные VLFS удаляются из конца файла журнала, чтобы уменьшить размер журнала до приблизительного целевого размера.
Дополнительные сведения об операциях сжатия см. по следующим ссылкам:
Сжатие файла журнала (без сжатия файлов базы данных)
- DBCC SHRINKFILE (Transact-SQL)
- Сжатие файла
Мониторинг событий сжатия файла журнала
Мониторинг пространства журнала
- sys.dm_db_log_space_usage (Transact-SQL)
- sys.database_files (Transact-SQL) (см size max_size . столбцы и growth файлы журнала.
Обслуживание индекса после сокращения
После завершения операции сжатия файлов данных индексы могут стать фрагментированными. Это снижает их эффективность оптимизации производительности для определенных рабочих нагрузок, таких как запросы с использованием масштабного сканирования. Если снижение производительности происходит после завершения операции сжатия, рассмотрите возможность обслуживания индекса для перестроения индексов. Имейте в виду, что перестроение индекса требует свободного места в базе данных и, следовательно, может привести к увеличению выделенного пространства, противодействуя эффекту сжатия.
Добавление или увеличение размера файла журнала
Вы можете выделить дополнительное место на диске, увеличив существующий файл журнала (если для этого достаточно места на диске) либо добавив файл журнала в базу данных, как правило, на другом диске. До тех пор, пока в журнале и на содержащем его дисковом томе достаточно свободного места, будет достаточного одного файла журнала транзакций.
- Чтобы добавить файл журнала в базу данных, используйте предложение ADD LOG FILE инструкции ALTER DATABASE . Это позволяет увеличить размер файла.
- Чтобы увеличить размер файла журнала, используйте предложение MODIFY FILE инструкции ALTER DATABASE с указанием синтаксиса SIZE и MAXSIZE . Дополнительные сведения см. в разделе ALTER DATABASE (Transact-SQL) File и Filegroup options.
Дополнительные сведения см. в Рекомендации.
Оптимизация размера журнала транзакций tempdb
Перезапуск экземпляра сервера изменяет размер журнала транзакций базы данных до исходного tempdb , предварительного автоматического увеличения размера. Это может снизить производительность журнала транзакций tempdb .
Эту нагрузку можно избежать, увеличив размер tempdb журнала транзакций после запуска или перезапуска экземпляра сервера. Дополнительные сведения см. в статье tempdb Database.
Управление увеличением размера файла журнала транзакций
Используйте инструкцию alter DATABASE (Transact-SQL) File и Filegroup options для управления ростом файла журнала транзакций. Обратите внимание на следующее:
- Чтобы изменить текущий размер файла в КБ, МБ, ГБ и ТБ, используйте параметр SIZE .
- Чтобы изменить шаг приращения размера, используйте параметр FILEGROWTH . Значение 0 указывает, что автоматическое приращение выключено и дополнительное пространство для файла не разрешено.
- Чтобы управлять максимальным размером файла журнала в КБ, МБ, ГБ и единицах ТБ или задать для роста значение UNLIMITED, используйте MAXSIZE этот параметр.
Дополнительные сведения см. в Рекомендации.
Рекомендации
Далее приведены некоторые общие рекомендации по работе с файлами журналов транзакций.
- Шаг приращения автоматического увеличения журнала транзакций, задаваемый параметром FILEGROWTH , должен быть достаточно большим, чтобы с запасом соответствовать потребностям транзакций рабочих нагрузок. Во избежание слишком частых увеличений размера файла журнала следует задать достаточно большое значение шагу роста файла журнала. Чтобы подбирать оптимальный размер журнала транзакций, рекомендуем отслеживать объем журнала, занимаемый в следующих случаях.
- Во время, необходимое для выполнения полного резервного копирования, так как резервные копии журнала создаются только после его завершения.
- Во время, необходимое для самых продолжительных операций обслуживания индекса.
- Во время, необходимое для выполнения наибольшего пакета в базе данных.
- В версиях до SQL Server 2022 (16.x) журналы транзакций не могут использовать мгновенное инициализацию файлов, поэтому расширенные периоды роста журналов особенно важны.
- Начиная с SQL Server 2022 (16.x) (все выпуски) и в База данных SQL Azure мгновенное инициализация файлов может воспользоваться событиями роста журнала транзакций до 64 МБ. Размер автоматического увеличения по умолчанию для новых баз данных составляет 64 МБ. События автоматического увеличения файла журнала транзакций, превышающие 64 МБ, не могут воспользоваться мгновенным инициализацией файлов.
- Рекомендуется не устанавливать для журналов транзакций значение параметра FILEGROWTH выше 1024 МБ. Значения для параметра FILEGROWTH по умолчанию.
Версия Значения по умолчанию Начиная с SQL Server 2016 (13.x) Данные — 64 МБ. Файлы журналов — 64 МБ. Начиная с SQL Server 2005 (9.x) Данные — 1 МБ. Файлы журналов — 10 %. До SQL Server 2005 (9.x) Данные — 10 %. Файлы журналов — 10 %.
- Большой автоматический увеличение может привести к приостановке базы данных во время выделения нового пространства, что может привести к истечении времени ожидания запроса.
- Приращение большого автоматического увеличения может создавать слишком мало и больших VLFs , а также может повлиять на производительность. Чтобы определить оптимальное распределение VLF для текущего размера журнала транзакций всех баз данных в данном экземпляре, и необходимый рост увеличивается для достижения требуемого размера, см. этот сценарий для анализа и исправления VLFs, предоставляемых командой SQL Tiger.
- Файл будет сжат либо до размера, в котором 25 % пространства не используется, либо до исходного размера, каким бы большим он ни был.
- Сведения об изменении параметра свойства auto_shrink см. в разделе «Просмотр» или «Изменение свойств базы данных» и параметров ALTER DATABASE SET (Transact-SQL).
Следующие шаги
- BACKUP (Transact-SQL)
- Устранение неполадок при переполнении журнала транзакций (ошибка SQL Server 9002)
- Раздел «Резервные копии журналов транзакций» в руководстве по архитектуре журнала транзакций SQL Server и управлению им
- Резервные копии журналов транзакций (SQL Server)
- Параметры инструкции ALTER DATABASE для файлов и файловых групп (Transact-SQL)