Можно ли удалить ldf файл
Обновлено: 19.05.2024
Понятное дело, что если записываются все изменения то лог-файл просто обязан расти. Всякие фоновые задания, которые пишут по одной записи в какой-нибудь регистр в 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-файла.
Это же самое можно выполнить запросом:
Плюсы второго вариант очевидны, вы всегда можете восстановить данные (надо вам сделать эксперименты самостоятельно с этим), написать скрипт, который может это сделать автоматически. При этом после каждого бэкапа размер журнала транзакций будем сокращен. Если вам не нужно, вы всегда можете использовать первый вариант и простую модель восстановления БД.
Как удалить лог файл базы данных файл _log.ldf?
Подробности --> 31.01.2021 0 2169
В процессе работы с базой 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" - выполняем задачу
Всем привет.
Из за большого размера файла log.ldf, который стал примерно 150Gb и является историей транзакция базы данных SQL, возникла необходимость его уменьшить
Файл позволяет вернуться к любой точке времени и восстановить базу на указанное время.
Т.к. настроены полные бэкапы в планировщике и достаточно часто делаются, то необходимости в этом журнале особо нет, хотя было бы не плохо иметь всегда месячную версию.
Подскажите как через планировщик настроить сжатие и очистку этого файла после успешно сделанного бэкапа?
Файл позволяет вернуться к любой точке времени и восстановить базу на указанное время.
Этот файл не позволяет этого сделать. Правильно настроенное резервное копирование, включающее в себя резервные копии журнала транзакций позволяет восстановить БД на любой (с оговорками) момент времени.
Подскажите как через планировщик настроить сжатие и очистку этого файла после успешно сделанного бэкапа?
Полный бэкап не влияет усечение журнала транзакций. Если ваша база в полной модели восстановления (что, видимо, так), и вы делаете только полные резервные копии - ваш журнал транзакций будет только расти, сколько бы шринков (DBCC SHRINKDATABASE/SHRINKFILE) вы не делали.
Грамотный подход для того, чтобы не страдать от разрастания журнала транзакций: почитать про модели восстановления; виды резервных копий (включая резервные копии журнала транзакций); настроить резервное копирование журнала транзакций с такой частотой, которая обеспечит оптимальные для вас: размер файла журнала транзакций и объём допустимой потери данных; разово обрезать журнал транзакций с помощью DBCC SHRINKFILE.
Быстрый подход: перевести бд в простую модель восстановления (alter database set recovery simple), выполнить инструкцию из первого ответа и забыть про рост журнала транзакций и восстановление на момент времени.
MS SQL 2005. У базы есть два файла логов (ldf). Необходимо один из них удалить.
Стандартную последовательность знаю
Пока просто ограничил максимальный размер "лишнего" лога 1МБ. Но хотелось бы его физически удалить. Как это можно сделать?
Через Object Explorer тоже не получается?
------------------
Knowledge is better than ignorance!
Website: juri.foxhelp.eu
------------------
Есть многое на свете, друг Горацио.
Что и не снилось нашим мудрецам.
(В.Шекспир Гамлет)
Мануал говорит что способ сжатия лог-файла зависит от модели восстановления. В любом случае нужно как-то добиться того, чтобы сервер перестал использовать этот файл - может явный чекпоинт поможет, да и BACKUP LOG упоминается в этой связи постоянно.
В оракле тоже есть похожие нюансы при сжатии/удалении LOG/UNDO/TEMP сущностей и их файлов.
Сегодня, после многочисленных попыток, хотя SHRINKFILE() по прежнему показывал 89 блоков (712КБ) команда REMOVE прошла успешно. Файл физически удалился с диска. Хотя в метаданных базы ссылка на него по прежнему есть. Впрочем обращение по этой ссылке дает ошибку. Вероятно, надо перезагрузить сервер, чтобы метаданные обновились. Вечером попробую
Единственное изменение, которое я заметил, так это что в диалоговом окне Shrink File используемый объем удаляемого лог-файла стал отрицательным числом. Вчера он упорно показывал, что используется примерно половина из доступного 1 МБ объема.
"Это же не наш метод"
Данная ссылка предполагает, что лог-файлы будут автоматически созданы. По тем же самым местам. Т.е. как было 2 файла логов, так 2 файла и останется. Метаданные-то не изменились..
Кроме того, как раз месяц назад грохнулся диск на котором были лог-файлы от нескольких тестовых баз (вырубили электричество, а стойка старая и не "удержалась"). Я именно по этой ссылке и пытался их поднять. Ничего не получилось. Так эти базы до сих пор в подвешенном состоянии
Igor KorolyovМануал говорит что способ сжатия лог-файла зависит от модели восстановления. В любом случае нужно как-то добиться того, чтобы сервер перестал использовать этот файл - может явный чекпоинт поможет, да и BACKUP LOG упоминается в этой связи постоянно.
В оракле тоже есть похожие нюансы при сжатии/удалении LOG/UNDO/TEMP сущностей и их файлов.
Опция EMPTYFILE в команде SHRINKFILE как раз и предназначена для того, чтобы принудительно блокировать любые попытки записи в указанный файл. Вне зависимости от модели восстановления. Единственная причина, по которой не была проведена полная очистка файла - это выполнение какого-то процесса в момент подачи команды SHRINKFILE. К сожалению, я не догадался посмотреть список активных на тот момент процессов, ну, или сделать CheckPoint.
Shrinking a Log File
For log files, the Database Engine uses target_size to calculate the target size for the whole log; therefore, target_size is the amount of free space in the log after the shrink operation. Target size for the whole log is then translated to target size for each log file. DBCC SHRINKFILE tries to shrink each physical log file to its target size immediately. However, if part of the logical log resides in the virtual logs beyond the target size, the Database Engine frees as much space as possible, and then issues an informational message. The message describes what actions are required to move the logical log out of the virtual logs at the end of the file. After the actions are performed, DBCC SHRINKFILE can be used to free the remaining space. For more information, see Shrinking the Transaction Log.
Because a log file can only be shrunk to a virtual log file boundary, shrinking a log file to a size smaller than the size of a virtual log file might not be possible, even if it is not being used. The size of the virtual log file is chosen dynamically by the Database Engine when log files are created or extended. For more information about virtual log files, see Transaction Log Physical Architecture.
You cannot move transaction log data from one log file to another to empty a transaction log file. To remove inactive transactions from a transaction log file, the transaction log must be truncated or backed up. When the transaction log file no longer contains any active or inactive transactions, the log file can be removed from the database. For more information, see Managing the Transaction Log.Исправлено: Igor Korolyov, 04.01.12 16:14
Владимир Максимов
"Это же не наш метод"
Данная ссылка предполагает, что лог-файлы будут автоматически созданы. По тем же самым местам. Т.е. как было 2 файла логов, так 2 файла и останется. Метаданные-то не изменились..
Кроме того, как раз месяц назад грохнулся диск на котором были лог-файлы от нескольких тестовых баз (вырубили электричество, а стойка старая и не "удержалась"). Я именно по этой ссылке и пытался их поднять. Ничего не получилось. Так эти базы до сих пор в подвешенном состоянии
Странно, мне дважды приходилось так делать, причем на продакшен, правда это были MSSQL 6.5 и 2000.
Читайте также: