Нужен ли файл log ldf
Обновлено: 16.07.2024
Когда SQL Server резервирует новое место на диске, то он инициализирует его нулями. Данное поведение можно отключить и как следствие сократить время выполнения некоторых операций и снизить нагрузку на дисковую подсистему.
Возможность резервирования места на диске без инициализации называется Instant File Initialization (мгновенная инициализация файлов).
Фича эта не сильно известна, хотя ее использование стало возможным начиная с SQL Server 2005.
Какие преимущества можно получить от Instant File Initialization:
1. Ускорить создание новой базы данных
2. Сократить задержки и уменьшить время необходимое для увеличения файлов данных
3. Сократить время старта SQL Server, поскольку инициализация tempdb будет более быстрой
4. Сократить время при восстановлении из резервной копии, поскольку перед восстановлением SQL Server резервирует место под файлы, а потом переносит в них информацию из бекапа.
Важно отметить, что Instant File Initialization работает только для файлов данных (MDF и NDF). Файлы лога (LDF) всегда инициализируются нулями.
Как использовать Instant File Initialization?
Все очень просто включается. Открываем SQL Server Configuration Manager и узнаем от какого имени запускается экземпляр нашего SQL Server.
Далее в Local Security Policy (Локальная политика безопасности) ищем User Rights Assignment (Название прав пользователя) – Perform volume maintenance tasks (Выполнение задач по обслуживанию томов)
Добавляем нужную нам личность в настройки, как показано на картинке.
Права, которые необходимы для работы Instant File Initialization, экземпляр SQL Server проверяет только один раз – во время старта. Именно поэтому нужно перезапустить SQL Server, чтобы применились наши настройки.
Теперь будем проводить эксперименты…
Для начала давайте проверим… включен ли Instant File Initialization?
Если он выключен, то при выполнении запроса:
в журнале можно увидеть заполнение нулями файлов данных:
Но если Instant File Initialization включен, то нулями заполняется только файл лога:
Если лень смотреть в журнал, то можно воспользоваться следующим скриптом:
На случай, если нужно временно отключить Instant File Initialization, то можно включить флаг трассировки 1806. Но как показывается практика, возможность использовать эту функциональность сильно экономит время и сокращает дисковую нагрузку.
Вот пара тестовых примеров и время на их выполнение с Instant File Initialization и без:
Если в целом, использование Instant File Initialization – потрясающий способ уменьшить время простоя при восстановлении после сбоя. Создание файлов не будет занимать долго времени для инициации их нулями до того, как начнётся сама операция восстановления. Так что возьмете на вооружение… что есть в мире такая фишка как Instant File Initialization.
Кстати, для SQL Server 2016 CTP3.0 можно включить Instant File Initialization еще на этапе установки:
Если хотите поделиться этой статьей с англоязычной аудиторией:
Instant File Initialization – Killer Feature for SQL Server
Понятное дело, что если записываются все изменения то лог-файл просто обязан расти. Всякие фоновые задания, которые пишут по одной записи в какой-нибудь регистр в 1С делают изменения в данных, а следовательно, растет размер лога. Причем, чем больше изменений, тем больше растет ldf-файл. А такая операция, как обновление информационной базы часто ведет вообще к огромному росту, так как при обновлении информационной базы происходит много изменений в данных и это все фиксируется.
Так же на размер файла транзакций влияет и интенсивность работы пользователей. Если мы открываем один и тот же документ и каждый раз меняем один реквизит и записываем документ, то в mdf-файле ничего изменяться не будет, а вот в файле транзакций, будет 10 записей с транзакциями, каждая из которых что-то меняет.
В MS SQL возможно использование нескольких моделей восстановления данных. Это, собственно, механизм, который и отвечает за журнал транзакций.
Полная модель восстановления (Full) - фиксируются ВСЕ транзакции. При этой модели будет максимальный рост журнала транзакций, но при этом риска данных журналов практически нет.
С неполным протоколированием - похожа на полную модель восстановления, но уменьшает место, занимаемое журналами, за счет неполного протоколирования большинства массовых операций. Возможно восстановление до конца любой резервной копии.
Простая модель (Simple) - данные по журналам практически не фиксируются.
Посмотреть на вашу модель можно открыв Microsoft SQL Server Managment Studio, щелкнув на нашу БД правой кнопкой:
Методы борьбы с размерами файла транзакций MS SQL
Итак, проблема ясна. Есть большой файл(ы) транзакций, необходимо что-то с этим делать. Так как серверные жесткие диски не всегда имеют возможность хранить логи терабайтами. Есть несколько способов борьбы с большим размеров логов.SHRINK (сжатие) лога транзакций
В простонародье это "шринк" файла. Это "обрезка" файла и удаление оттуда данных транзакций. Действительно, если журнал транзакций нам нужен только при возникновении сбоев, может имеет смысл настроить частое резервное копирование, а лог транзакций вообще отключить? Это возможно.Шаг 1. Сжатие log-файла
Откроем Microsoft SQL Server Managment Studio и "сожмем" log-файл.
После этого откроется окно:
Тут можно подобрать нужные параметры сжатия и освободить используемое место журнала транзакций. При этом ваши данные в базе данных никак не пострадают. Здесь мы имеем дело исключительно с журналом транзакций и как мы сказали выше, база данных вообще может обойтись без журнала в простой модели протоколирования, а значит очистка это вполне нормально.
Шаг 2. Переключение на простую модель восстановления
Если вы хотите на корню решить вопрос с ростом логов, то вы можете переключить модель восстановления на простую (Simple). На самом первом скриншоте выше, переключите модель на простую и нажмите OK.
Так же возможно выполнения вот такого запроса:
Этот способ наладить работу с размером логов имеет как плюсы (быстро и навсегда решает проблему роста логов), так и минусы. Например, вы теряете возможность оперативно откатывать изменения.
Важно, что речь не о полных бэкапах, а именно когда речь идет о восстановлении по данным журнала транзакций. Как пример, бэкап был вчера, а сегодня после обеда, когда было внесено 50 документов, вы случайно очистили важный документ и хотите вернуть его. Это можно сделать с помощью логов.
Некоторые считают такой метод, не верным и отчасти это так, но если вы и раньше не пользовались восстановлением данных по данным журнала транзакций, то я не думаю, что это вообще проблема для вас :)
Создание резервных копий журнала транзакций
Кроме способа описанного выше в MS SQL есть возможность создавать резервные копии журнала транзакций. Это можно сделать из Microsoft SQL Server Managment Studio:
А следующим шагом:
Важно! Делая бэкап журнала транзакций мы усекаем его. MS SQL понимает, что копия журнала сделана, а значит можно уменьшить размер log-файла.
Это же самое можно выполнить запросом:
Плюсы второго вариант очевидны, вы всегда можете восстановить данные (надо вам сделать эксперименты самостоятельно с этим), написать скрипт, который может это сделать автоматически. При этом после каждого бэкапа размер журнала транзакций будем сокращен. Если вам не нужно, вы всегда можете использовать первый вариант и простую модель восстановления БД.
Друзья, почти ежедневно сталкиваюсь с тем, что на курсе: Администратор 1С, при опросе студентов, на предмет «Как Вы организовали бэкап в MS SQL?». Очень редко кто пишет: «Да, помимо «полного» я делаю и бэкап журналов транзакций».
К сожалению, редко кто делает бэкап ЖТР (
И тем самым открывает прямой путь к таким проблемам как:
«Распух лог в MS SQL», «Сильно увеличился LDF», «Разрастается log, что делать?», «Журнал занял все свободное место на диске», и многое, многое другое.
В этой статье я не буду рассыпать терминами и сложными понятиями гуру специалиста DBA, нет!
Так как вижу реальную картину, реальную проблематику вопроса, на более чем 5000 тыс студентов (Что проходили у нас курс: Администратор 1С). И реальность она несколько в другом!
Большинство не делает бэкапов журналов транзакций, так как не понимает зависимостей (связей), между их созданием и размерами самого журнала (*ldf).
Собственно цель данной статьи, максимально понятно, на простом языке, объяснить и закрыть раз и навсегда проблему растущего лога в MS SQL!
Приступим…
Кратко пройдемся по основам, чтоб даже новички быстро смогли уловить суть и не потеряться в терминах.
Файл *LDF он же и есть наш журнал транзакций!
Что там хранится?
Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все транзакции и производимые ими в базе изменения.
Журнал транзакций — это важная составляющая базы данных. Если система даст сбой, этот журнал поможет вам вернуть базу данных в согласованное состояние.
Если говорить еще проще, благодаря бэкапу ЖТР есть возможность восстановить базу фактически на любой момент времени (вплоть до нужной секунды)!
При этом следует понимать, что никаких по факту данных из 1С в прямом смысле этого слова в журнале нет!
Все данные пишутся в файл *mdf, а вот фиксация этих действий пишется в *ldf, по каждому действию (транзакции), что происходит у Вас в 1С. Все что делают пользователи в 1С, фиксируется в журнале транзакций, только сам факт (фиксация) произошедших событий в базе, а не сами данные.
Собственно отсюда и название «Журнал транзакций». Конечно на практике все сложнее, но в упрощенном для понимания виде все именно так.
Почему растет лог файл в MS SQL (*ldf) ?
К слову мы только что ответили на частый вопрос: «Вот у меня лог не разрастался» в базе «А», а в базе «Б» растет очень быстро».
Конечно если с базой «Б» пользователи работают интенсивно или различные фоновые, регламентные задачи (их много), безусловно, он будет расти быстрее, такова физика работы «MS SQL»!
«Простая» и «полная» модель восстановления
Да, «полная» модель восстановления подразумевает, что в журнал будем писать «По максимуму» все возможное. Все что сможет записать MS SQL, он туда запишет. Исключения конечно есть. К примеру, когда свободное место закончилось на диске или есть ограничения на сам лог (если установили). Есть и другие причины, но мы сейчас не об этом.
Нам важно понимать одно: «Полная» модель = «Полный» лог! А значит, есть возможность не терять данные, при необходимости восстановится на любой момент времени (фактически до секунды), а выполнив бэкап еще и «заключительного фрагмента журнала» и вообще ничего не потерять!
Вывод:
Только в «полной» модели мы должны работать! Она не зря «по умолчанию» в MS SQL!
«Активная» и «Неактивная» часть журнала
Сперва дадим ответ на вопрос: «Что происходит в момент создания бэкапа ЖТР ?»
Чтоб разобраться в этом вопросе, нам нужно понимать, что журнал транзакций может быть «условно разделен» на две части: «Активная» и «Неактивная» часть журнала.
Неактивная часть журнала транзакций содержит информацию о завершенных транзакциях и не используется сервером SQL Server в процессе восстановления данных. Вместо увеличения размера файла журнала транзакций SQL Server будет повторно использовать освободившееся пространство.
И вот в момент, когда мы создаем бэкап журналов транзакций, мы тем самым «усекаем» его «неактивную» часть (точнее это делает сам MS SQL), вплоть до начала его активной части!
При этом вначале всегда происходит его бэкап, а только после уже «усечение», как на рисунке выше.
Бэкап журналов нужно делать довольно часто (раз на 30-60 мин), особенно если с базой активно работают пользователи, он может вырасти довольно быстро, и конечно без автоматизации этого процесса не обойтись!
Также мы можем сделать и бэкап «заключительного фрагмента журнала транзакций», если нужно восстановить базу на самый последний момент времени. В таком случаи мы также усекаем журнал (ту часть, что есть на момент создания самого заключительного фрагмента журнала).
Вывод:
В «полной» модели восстановления бэкап журналов транзакций НЕОБХОДИМ! Если Вы не хотите в один прекрасный день обнаружить, что свободное место на диске, где он находится, уже закончилось!
Если ЛОГ уже вырос ?
Конечно, если Вы раньше не делали бэкапов журналов, лог соответственно вырос, то здесь одним бэкапом журналов транзакций не обойтись!
И вот почему:
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>
Любая база данных SQL Server состоит из нескольких файлов операционной системы. Это файлы с данными и файлы журнала транзакций. Отдельные файлы могут относиться только к одной базе данных, при этом информация из файлов данных никогда не смешивается с информацией из журнала транзакций в одном физическом файле. Все данные БД хранятся в файлах MDF, а все транзакции и изменения в базе данных фиксируются в LDF-файла, т.е. в файлах журнала транзакций, который является очень важным компонентом базы данных. По сути, файл журнала транзакций представляет собой строку записей журнала. Физически записи журнала хранятся в одном или нескольких LDF-файлах, которые и образуют журнал транзакций.
LDF-файл содержит в себе достаточно информации, чтобы воспроизвести или отменить изменения или, даже, восстановить базу данных на определённый момент времени. Поэтому, в рамках аудита или с целью восстановления, может возникнуть потребность открыть LDF-файл и просмотреть его содержимое. Но просмотр содержимого LDF-файла не является простой задачей.
Есть несколько функций и команд SQL Server (например, fn_dblog, fn_dump_dblog и DBCC PAGE), которые потенциально обеспечивают возможность просмотра содержимого файла LDF. Тем не менее, чтобы использовать их вам потребуются хорошие знания по T-SQL, некоторые из функций являются недокументированными и тот набор данных, который они возвращают очень трудно перевести в человеческий вид. Ниже приведены примеры просмотра содержимого файла LDF с использованием функций и команд SQL Server:
Вот пример использования функции fn_dblog для просмотра активного журнала транзакций, которая в качестве результата возвращает 129(!) столбцов (только 7 из них представлены на рисунке ниже).
Функция fn_dump_dblog используется для чтения резервной копии журнала транзакций в обычном и сжатом виде. Результат аналогичен:
К сожалению, официальная документация не доступна для функций fn_dblog и fn_dump_dblog. Чтобы перевести столбцы в читабельный вид, вы должны быть знакомы с внутренней структурой и форматом данных, знать служебные флаги и алгоритмом хранения.
Чтение содержимого журнала транзакций с помощью ApexSQL Log
Чтобы с помощью ApexSQL Log открыть LDF-файл и просмотреть его содержимое:
Подключитесь к БД, которой принадлежит LDF-файл.
На следующем шаге необходимо добавить все журналы транзакций и отдельные LDF-файлы, информацию которых вы хотите прочитать. Убедитесь, что они образуют полную цепочку журнала. Цепочкой является непрерывная последовательность ВСЕХ резервных копий журнала транзакций. Она начинается с полной резервной копии базы данных и дополняется всеми резервными копиями журнала. Если эта цепочка будет нарушена, то вы сможете получить полную информацию только от момента создания полной резервной копии до точки разрыва (такой информацией может быть история изменения записи в таблице, изменение структуры объекта и т.д.).
Кроме того, если цепочка образована из достаточного количества резервных копий журнала транзакций, то поиск информации может быть осуществлён быстрее, чем по одному большому куску активного журнала транзакций. ApexSQL Log умеет читать и отдельные LDF-файлы, которые вы можете указать, за счёт этого может быть гарантирована дополнительная целостность и неразрывность цепочки.
Для этого используйте кнопку ADD на шаге Select SQL logs to analyze
На вкладке Database backups укажите полную резервную копию базы данных, именно от неё начнется цепочка транзакций.
На шаге Filter setup укажите временной интервал (Time range), когда ваша операция произошла. Это поможет ускорить поиск.
Когда все настройки установлены, нажмите кнопку Open, чтобы начать чтение LDF-файлов.
Когда процесс закончится, то в сводной таблице ApexSQL Log появится информация о всех транзакциях из указанных источников и с учётом всех фильтров, которые были установлены.
Вместо заключения:
Существует несколько способов чтобы открыть и просмотреть содержимое LDF-файлов. Но все их объединяет одно – информацию тяжело использовать, т.к. она хранится в плохочитаемой структуре.
Но благодаря инструменту ApexSQL Log вы можете получить информацию в человеческом виде: получить полный список транзакций, весь перечень операций, имена и схемы объектов, точное время, когда произошла транзакция, кто её выполнил и многое другое.
Как удалить лог файл базы данных файл _log.ldf?
Подробности --> 31.01.2021 0 2192
В процессе работы с базой 1С, которая размещена в СУБД Microsoft SQL Server, происходит постепенный рост файла с логами, который может достигать приличных размеров. Решение вопроса крайне простое. Для этого вам потребуется Microsoft SQL Server Management Studio. Запускаем его и переходим в соответствующую базу.
Прежде чем делать любые манимуляции, необходимо сделать бэкап базы данных! Если возникли трудности, напишите комментарий к статье, мы поможем.
Если у вас рускоязычная версия, то выполните следующую последовательность действий:
1. Заходите в "Свойства";
2. Находите в раздел "Параметры";
3. В пункте "Модель восстановления" выбираем "Простая"
4. Выбираем для параметра "Автоматическое сжатие" значение "True"
5. Выбираем для параметра "Статистика автоматического создания" значение "True"
6. Нажимаем ок и снова возвращаемся к базе данных
7. Нажимаем правой клавишей на нашей базе - "Задачи" - > "Сжать" -> "База данных" - выполняем задачу
Для англоязычкой версии, выполните следующие пункты:
1. Заходите в "Properties";
2. Находите в раздел "Options";
3. В пункте "Модель восстановления" выбираем "Simple"
4. Выбираем для параметра "Auto Shrink" значение "True"
5. Выбираем для параметра "Auto update statistics" значение "True"
6. Нажимаем ок и снова возвращаемся к базе данных
7. Нажимаем правой клавишей на нашей базе - "All Tasks" - > "Shrink" -> "Database" - выполняем задачу
Читайте также: