Записки для себя
Возможен вариант, когда база данных mdf размером 5-10 Гб, а лог файл 20-30 Гб. Значить выбрана полная модель восстановления. При такой модели в лог файл записываются все транзакции. Для уменьшения лог файла можно воспользоваться Средой Microsoft SQL Server Management Studio.
1. Переводим базу в режим (модель) протоколирования Simple (Простая).
2. В окне параметров в закладке Файлы уменьшаем начальный размер лога до необходимого.
3. Переводим базу в режим Full (Полная).
Как правильно оптимизировать файл лога 1С 8.2?
Добрый вечер. Наиболее частая причина разрастания лог файла — это неправильно выбранная модель восстановления и/или некорректно настроенное резервное копирование БД и журнала транзакций.
Вероятнее всего у вас выбрана полная(full) модель восстановления — она выбирается по умолчанию для пользовательских баз и обеспечивает хранение наибольшего количества операций в журнале транзакций. При этом автоматического урезания журнала в этом режиме не происходит.
Посмотреть какая выбрана модель восстановления можно например с помощью «MS SQL Management Studio» в свойствах базы на закладке «Параметры»
Для данной модели восстановления урезание журнала транзакций напрямую зависит от резервного копирования и если его не делать файл будет только расти.
Как уменьшить размер log файла sql 1с
Добрый вечер коллеги!
Перечитал кучу статей, но так и не нашел ответа на свой вопрос.
Есть 5 баз 1С в MSQL 2012, Настроен Maintance plan. В конце Задачи"Очистка после обслуживания", и "Очистка журнала". Но логи не удаляются приходиться в ручную очищать после предельного переполнения. Метод восстановления баз стоит полный.
1.Что будет если установлю метод восстановления простой
2. На что влияет если я выполняю сначала переход с полного режима на простой, после очищаю лог и потом снова высталяю метод восстановления полный
3. Возможно есть какая то фишка по очистке логов.
Ответы
На сколько я знаю, переход с полного на простой метод восстановления безопасно выполнять, только после выполнения полной резервной копии баз-данных, как сообстно и очистку transactionLog.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
- Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 10 октября 2018 г. 5:47
Вы принципиально не понимаете необходимость и методы управления журналом транзакций. У меня журнал транзакций занимает объем порядка 40GB в нормальном режиме работы базы. И я его не урезаю, т.к. он все равно у вас вырастет до такого объема, если под нагрузкой имеет такой объем.
Идея иметь большой файл — сокращение операций ввода/вывода, которые потребуются сделать сиквелу при приращении файла логов. Операции ввода/вывода априори медленные.
поэтому, если вы используете модель восстановления Full, выполняйте регулярное резервное копирование журнала транзакций, смиритесь с его объемом и не делайте shrink. В противовес к этому, вы получаете возможность восстановления на максимально близкий к падению момент времени.
Если вы все таки хотите урезать логи, то уйдите на Simple и откатывайтесь на последний полный бэкап.
Innovation distinguishes between a leader and a follower — Steve Jobs
- Помечено в качестве ответа Razor1212007 20 ноября 2018 г. 11:41
Все ответы
На сколько я знаю, переход с полного на простой метод восстановления безопасно выполнять, только после выполнения полной резервной копии баз-данных, как сообстно и очистку transactionLog.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
- Помечено в качестве ответа Иван Проданов Microsoft contingent staff, Moderator 10 октября 2018 г. 5:47
На сколько я знаю, переход с полного на простой метод восстановления безопасно выполнять, только после выполнения полной резервной копии баз-данных, как сообстно и очистку transactionLog.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
Innovation distinguishes between a leader and a follower — Steve Jobs
Модель восстановления стоит Full. Создан план обслуживания, настроена очистка логов. Но задача не выполняется. Либо я что то не то делаю.
У вас нет шага по резервному копированию журнала транзакций базы данных.
И очистки логов нет. Очистка журнала делает очистку журналов заданий в базе, но никак не логов.
Поэтому еще раз: или меняйте модель восстановления, как вам уже говорили, или выполняйте резервное копирование журнала транзакций дополнительным шагом.
Innovation distinguishes between a leader and a follower — Steve Jobs
У меня стоит полная модель восстановления, я добавил шаг по резервному копированию журнала транзакций базы данных. Но как теперь очистить лог?
- Изменено Razor1212007 7 ноября 2018 г. 12:02
Microsoft recommends that instead of truncating logs, you switch to simple recovery mode instead. That way you don’t generate logs you won’t be using, and you won’t incur performance impacts from repeatedly filling and truncating the logs. You also remove the need to regularly back up the transaction log.
Innovation distinguishes between a leader and a follower — Steve Jobs
How to BACKUP LOG WITH TRUNCATE_ONLY in SQL Server 2008, R2, 2012
Microsoft recommends that instead of truncating logs, you switch to simple recovery mode instead. That way you don’t generate logs you won’t be using, and you won’t incur performance impacts from repeatedly filling and truncating the logs. You also remove the need to regularly back up the transaction log.
Innovation distinguishes between a leader and a follower — Steve Jobs
Если речь идет о команде Shrink, то скорее всего это сжатие.
Сжатие файлов данных позволяет освободить неиспользуемое пространство путем перемещения страниц данных с конца файла в незанятое пространство ближе к началу файла. Когда в конце файла образуется достаточно свободного места, страницы данных в конце файла могут быть освобождены и возвращены в файловую систему.
Avis de non-responsabilité:
Mon opinion ne peut pas coïncider avec la position officielle de Microsoft.
Bien cordialement, Andrei .
MCP
Кто нибудь может написать Русским языком сделай так и так и будет тебе счастье. Как всегда слов много а по делу нифига. Ссылками все кидаются. Как и в безопасности администраторов много, а у кого идеальная система безопасности не понятно.
- Изменено Razor1212007 15 ноября 2018 г. 14:08
А вы сходите к своему руководству и попросите уменьшить вам ЗП в пользу сообщества?
Вам дали ссылки на материалы. Это вопрос обсуждался уже даже не 1000 раз. Но вы упорно не хотите сделать работу, вы хотите, чтобы ее за вас сделали.
А вы сходите к своему руководству и попросите уменьшить вам ЗП в пользу сообщества?
Вам дали ссылки на материалы. Это вопрос обсуждался уже даже не 1000 раз. Но вы упорно не хотите сделать работу, вы хотите, чтобы ее за вас сделали.
И что вы плачьтесь по зарплате, вам чего то не хватает, так наверно работу надо искать лучше. А зачем вы тут сидите Гуру администраторы. Ссылки кидать? Сколько я читал информации так и не нашел решения. Логично если бы разобрался, наверно не задавал вопрос.
- Изменено Razor1212007 16 ноября 2018 г. 12:33
т.к. от вас так и не дождались требований к точке восстановления при отказе (RPO) и времени восстановления (RTO), то точно ответить за вас никто не может.
В общем случае, я думаю, вам поможет следующее:
1. Установите режим восстановления Simple
2. Задайте желаемый размер файла логов в свойствах базы
3. переделайте задание резервного копирования, исключив из него резервное копирование журнала транзакций
В данном решении вы восстанавливаетесь на последний полный бэкап. Если он у вас проходит раз в день, то теряете данные, сделанные после бэкапа, если раз в неделю, то максимум за неделю.
Если вас это устраивает, то план действий выше. Если требования иные, то просьба озвучить их
Innovation distinguishes between a leader and a follower — Steve Jobs
Так я спросил но никто не ответил """"Получается нужно переходить на простой режим восстановления. И если что не так с базой то откатиться на вечерний бэкап и все?"""
может не поняли меня. Интересует только восстановление на дату бэкапа, т.е на каждый предыдущий день вечер. Вам спасибо за четкое объяснение.
А для себя было интересно как восстановить базу на момент ее падения. Я так понимаю использовать метод Full, делать резервную копию транзакции, но как их урезать я не понял. Должен быть SQL запрос типа такого
USE ″DBName″
ALTER DATABASE ″DBName″ SET RECOVERY SIMPLE
DBCC SHRINKFILE (″DBName″, ″Размер до которого урезать лог″);
ALTER DATABASE ″DBName″ SET RECOVERY FULL
Или я чего то не понял и это может только навредить? как у вас в компаниях настроено?
- Изменено Razor1212007 19 ноября 2018 г. 12:48
Вы принципиально не понимаете необходимость и методы управления журналом транзакций. У меня журнал транзакций занимает объем порядка 40GB в нормальном режиме работы базы. И я его не урезаю, т.к. он все равно у вас вырастет до такого объема, если под нагрузкой имеет такой объем.
Идея иметь большой файл — сокращение операций ввода/вывода, которые потребуются сделать сиквелу при приращении файла логов. Операции ввода/вывода априори медленные.
поэтому, если вы используете модель восстановления Full, выполняйте регулярное резервное копирование журнала транзакций, смиритесь с его объемом и не делайте shrink. В противовес к этому, вы получаете возможность восстановления на максимально близкий к падению момент времени.
Если вы все таки хотите урезать логи, то уйдите на Simple и откатывайтесь на последний полный бэкап.
Innovation distinguishes between a leader and a follower — Steve Jobs
- Помечено в качестве ответа Razor1212007 20 ноября 2018 г. 11:41
Вы принципиально не понимаете необходимость и методы управления журналом транзакций. У меня журнал транзакций занимает объем порядка 40GB в нормальном режиме работы базы. И я его не урезаю, т.к. он все равно у вас вырастет до такого объема, если под нагрузкой имеет такой объем.
Идея иметь большой файл — сокращение операций ввода/вывода, которые потребуются сделать сиквелу при приращении файла логов. Операции ввода/вывода априори медленные.
поэтому, если вы используете модель восстановления Full, выполняйте регулярное резервное копирование журнала транзакций, смиритесь с его объемом и не делайте shrink. В противовес к этому, вы получаете возможность восстановления на максимально близкий к падению момент времени.
Если вы все таки хотите урезать логи, то уйдите на Simple и откатывайтесь на последний полный бэкап.
Innovation distinguishes between a leader and a follower — Steve Jobs
Прекрасно я понимаю что журнал транзакции нужен для того что бы откатиться на максимально последний момент времени. Мне непонятно когда у него будет свой предел
У вас он 40 Гб, у кого-то 200 и продолжает расти. Получается из ваших слов вы с ним ничего не делаете, он достиг своего предела, возможно у вас не вноситься столько информации как у нас?
Почему растет LOG в MS SQL ?
Друзья, почти ежедневно сталкиваюсь с тем, что на курсе: Администратор 1С, при опросе студентов, на предмет «Как Вы организовали бэкап в MS SQL?». Очень редко кто пишет: «Да, помимо «полного» я делаю и бэкап журналов транзакций».
К сожалению, редко кто делает бэкап ЖТР (
И тем самым открывает прямой путь к таким проблемам как:
«Распух лог в MS SQL», «Сильно увеличился LDF», «Разрастается log, что делать?», «Журнал занял все свободное место на диске», и многое, многое другое.
В этой статье я не буду рассыпать терминами и сложными понятиями гуру специалиста DBA, нет!
Так как вижу реальную картину, реальную проблематику вопроса, на более чем 5000 тыс студентов (Что проходили у нас курс: Администратор 1С). И реальность она несколько в другом!
Большинство не делает бэкапов журналов транзакций, так как не понимает зависимостей (связей), между их созданием и размерами самого журнала (*ldf).
Собственно цель данной статьи, максимально понятно, на простом языке, объяснить и закрыть раз и навсегда проблему растущего лога в MS SQL!
Приступим…
Кратко пройдемся по основам, чтоб даже новички быстро смогли уловить суть и не потеряться в терминах.
Файл *LDF он же и есть наш журнал транзакций!
Что там хранится?
Каждая база данных SQL Server имеет журнал транзакций, в котором фиксируются все транзакции и производимые ими в базе изменения.
Журнал транзакций — это важная составляющая базы данных. Если система даст сбой, этот журнал поможет вам вернуть базу данных в согласованное состояние.
Если говорить еще проще, благодаря бэкапу ЖТР есть возможность восстановить базу фактически на любой момент времени (вплоть до нужной секунды)!
При этом следует понимать, что никаких по факту данных из 1С в прямом смысле этого слова в журнале нет!
Все данные пишутся в файл *mdf, а вот фиксация этих действий пишется в *ldf, по каждому действию (транзакции), что происходит у Вас в 1С. Все что делают пользователи в 1С, фиксируется в журнале транзакций, только сам факт (фиксация) произошедших событий в базе, а не сами данные.
Собственно отсюда и название «Журнал транзакций». Конечно на практике все сложнее, но в упрощенном для понимания виде все именно так.
Почему растет лог файл в MS SQL (*ldf) ?
Конечно, если учитывать что каждое действие сделанное пользователем в 1С фиксируется в журнале транзакций, то он просто не может не расти! И здесь также стоит отметить, что не только действие пользователя влияет на рост журнала, но и различные регламентные задачи (фоновые различные процессы), особенно сильно заметен рост, когда происходит в базе 1С реструктуризация. Собственно при обновлении конфигурации также можем замечать “взрывной” рост журнала транзакций.
К слову мы только что ответили на частый вопрос: «Вот у меня лог не разрастался» в базе «А», а в базе «Б» растет очень быстро».
Конечно если с базой «Б» пользователи работают интенсивно или различные фоновые, регламентные задачи (их много), безусловно, он будет расти быстрее, такова физика работы «MS SQL»!
MS SQL всегда (в “полной” модели восстановления) будет пытаться зафиксировать, фактически все действия в базе. И журнал будет расти до тех пор, пока мы не сделаем его бэкап, этим мы и «усекаем» его!
«Простая» и «полная» модель восстановления
Да, «полная» модель восстановления подразумевает, что в журнал будем писать «По максимуму» все возможное. Все что сможет записать MS SQL, он туда запишет. Исключения конечно есть. К примеру, когда свободное место закончилось на диске или есть ограничения на сам лог (если установили). Есть и другие причины, но мы сейчас не об этом.
Нам важно понимать одно: «Полная» модель = «Полный» лог! А значит, есть возможность не терять данные, при необходимости восстановится на любой момент времени (фактически до секунды), а выполнив бэкап еще и «заключительного фрагмента журнала» и вообще ничего не потерять!
На сайте Microsoft можно найти информацию о том, что единственная «рабочая» модель, предназначенная для реальной работы, есть только «Полная» модель восстановления! Так как в работе недопустимо терять данные, а это гарантированно произойдет в «Простой» модели восстановления, если случится “сбой”.
«Простая» модель восстановления может использоваться для тестирования, разработки, для временного переключения (Обязательно! С предварительным бэкапом базы и лога). К примеру, только на время реструктуризации ее можно включить, а потом обратно вернуть в «Полную» модель. Есть и другие случаи, когда мы только временно переключаем режим с «Полной в Простой» Но работаем всегда в “полной” модели восстановления!
В “простой” модели мы никак не можем восстановиться (в случаи чего) на интересующий нас момент времени. Только на тот момент, когда сделан либо «полный» бэкап, либо «полный» + «разностный»!
Вывод:
Только в «полной» модели мы должны работать! Она не зря «по умолчанию» в MS SQL!
«Активная» и «Неактивная» часть журнала
Сперва дадим ответ на вопрос: «Что происходит в момент создания бэкапа ЖТР ?»
Чтоб разобраться в этом вопросе, нам нужно понимать, что журнал транзакций может быть «условно разделен» на две части: «Активная» и «Неактивная» часть журнала.
«Активная» – содержит изменения, которые были сделаны в базе, но еще не зафиксированы на диске.
«Неактивная» – изменения уже зафиксированы на диске, следовательно, можно усекать неактивную часть журнала (делать бэкап), вплоть до его активной части!
Неактивная часть журнала транзакций содержит информацию о завершенных транзакциях и не используется сервером SQL Server в процессе восстановления данных. Вместо увеличения размера файла журнала транзакций SQL Server будет повторно использовать освободившееся пространство.
И вот в момент, когда мы создаем бэкап журналов транзакций, мы тем самым «усекаем» его «неактивную» часть (точнее это делает сам MS SQL), вплоть до начала его активной части!
При этом вначале всегда происходит его бэкап, а только после уже «усечение», как на рисунке выше.
Бэкап журналов нужно делать довольно часто (раз на 30-60 мин), особенно если с базой активно работают пользователи, он может вырасти довольно быстро, и конечно без автоматизации этого процесса не обойтись!
Также мы можем сделать и бэкап «заключительного фрагмента журнала транзакций», если нужно восстановить базу на самый последний момент времени. В таком случаи мы также усекаем журнал (ту часть, что есть на момент создания самого заключительного фрагмента журнала).
Вывод:
В «полной» модели восстановления бэкап журналов транзакций НЕОБХОДИМ! Если Вы не хотите в один прекрасный день обнаружить, что свободное место на диске, где он находится, уже закончилось!
Если ЛОГ уже вырос ?
Конечно, если Вы раньше не делали бэкапов журналов, лог соответственно вырос, то здесь одним бэкапом журналов транзакций не обойтись!
И вот почему:
Зарегистрируйтесь, чтоб продолжить чтение статьи
Зарегистрироваться / Войти
Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>