Как ограничить рост 1с журнала транзакций 1С+MS-SQL?
Очень часто в форумах слышатся жалобы, что журнал транзакций в базе данных достиг размера, в разы, превышающего размер самой базы данных. Как же его можно ограничить?
Очень просто. Для этого:
- Открываем Enterprise Manager , находим там наш сервер и нашу базу данных, включаем свойства базы данных.
- Переходим на закладку « Options ».
- Выставляем опцию Recovery model в режим « Simple ».
- Ставим отметку в поле « Auto shrink ».
Режим « Simple » — служит для того, чтобы полностью отказаться от идеи хранения лога транзакций. Как только транзакция завершена со статусом «Успешно», лог по ней удаляется, но размер файла при этом не меняется. А вот, собственно, « Auto shrink » делает обрезку файла до размера содержащейся в нем информации.
На особо нагруженных базах не рекомендуется устанавливать опцию « Auto shrink », так как урезка лог файла создает дополнительную нагрузку на сервер. В любом случае, урезать лог файл можно и вручную. Для этого открываем Enterprise Manager , находим там наш сервер и нашу базу данных, по ней щелкаем правой кнопкой мыши и из выпадающего контекстного меню выбираем « Shrink Database. ».
Далее, нам откроется диалоговое выбора режима сжатия.
Красным отмечен очень интересный пункт. Эта опция позволяет не только обрезать лог и сжать файл данных, но и переупорядочить даные на страницах, путем более плотного их размещения. Размер базы данных может значительно уменьшиться для тех баз, где давно не выполнялось это действие.
Как очистить лог файл sql 1с
Как удалить лог файл базы данных файл _log.ldf?
Подробности —> 
31.01.2021 
2 
9362
В процессе работы с базой 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» — выполняем задачу
После этого, файл с логами должен уменьшиться до 1 Мб.
P.S. Если вам помогла статья, помогите и вы нам либо комментарием под ней либо поделитесь ссылочкой на нее.
P.S.S. Если у вас возникли проблемы с техникой воспользуйтесь услугой ремонт компьютеров, либо закажите выезд компьютерного мастера.
Как очистить лог файл sql 1с
Два примера того, как возможно сократить журнал (уменьшить лог) транзакций СУБД SQL (файл *.ldf) для корректной работы 1С 8.
Чаще всего потребность в данной операции возникает из-за переполнения журнала транзакций и откаже корректной работы базы 1С 8. Сопровождается ошибкой: «Журнал транзакций для базы данных переполнен». Причина: «LOG_BACKUP»
Запускается SQL Server Management Studio. В ветке «Базы данных» дерева «Обозревателя объектов» находим базу данных по названию. Вызываем контекстное меню и в нем выбираем пункт «Создать запрос» и вводим текст:
ALTER DATABASE [name_db] SET RECOVERY SIMPLE
DBCC SHRINKFILE ([name_db], 50);
ALTER DATABASE [name_db] SET RECOVERY FULL
, где [name_db] — имя (название) базы данных СУБД. В примере — «Бухгалтерия».
Но этот способ не всегда может сработать. Опустим причины и попытки разобраться и заставить работать этот метод. А перейдем к способу, который является интерактивным выражением уже представленного.
Правой кнопкой мыши на базе вызываем меню и переходим в свойства базы. Переходим на страницу «Параметры».
Нажатие на изображении увеличит его 
На странице «Параметры» для «Модели восстановления» выбирается значение «Простая». Запоминаем исходное значение, скорее всего это «Полная». Нужно будет потом вернуть это значение для модели восстановления.
Это была небольшая подготовка. Теперь выполним непосредственно сжатие (шринк) журнала (лога) транзакций. Для этого вызываем контекстное меню правой кнопкой мыши для базы. В подменю «Задачи» выбираем подменю «Сжать», в нем пункт «Файлы».
Нажатие на изображении увеличит его 
В открывшемся окне устанавливаем «Тип файла» — «Журнал». В «Операция сжатия» выбирается вариант «Реорганизовать страницы, перед тем освободить неиспользуемое место». И указывается новое значение размера файла журнала транзакций в поле вводе «Сжать файл до:». Указать приемлемый размер лога. Нажимается кнопка «ОК».
После выполнения операции сокращения вернем «Модель восстановления» в исходное значение «Полная»
Как очистить лог файл sql 1с
Как почистить логи сервера MSSQL?
Не тот лог, который к базе прилагается в *.ldf-файле, а тот, который в папке самого сервера в россыпи *.log, *.mdmp и *.txt.
Желательно, штатными средствами сервера, что-то мне страшно удалять эти тысячи файлов вручную.
(0) Ну и плюс хочется ограничить рост этой папки впредь.
(0) в конфигураторе задай периодичность. и грохай старые по мере необходимости.
хотя у журнала другое расширение.
(2) Казалось бы, причем тут конфигуратор о_О??
сначала бы надо понимать откуда там это берется.
(5) +100500
и не удивляться, что к MS SQL это не имеет ни малейшего отношения
(4) я не вкурил сразу. в бине скуля что ли логи? или сервера 1с?
(2) Вы про конфигуратор 1С? А где я про него говорил?
(5) И как это узнать? Там 60 гигабайт, 36 с половиной тысяч файлов. Где копать?
(7) c:\Program Files (x86)\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\
Это логи скуля. Ни к 1С, ни к конкретной базе привязки не имеющие.
ctrl+a потом shift+del. а как еще то?
(6) может и имеет. настроили таск в скуле, он туда чего-то вваливает по окончанию джоба
(8) смотри джобы винды и скуля
ПКМ по «Журналы SQL сервер-Настроить» Что выставлено?
еще могут счетчики собираться.
(10) Слушайте, а давайте вы еще раз прочитаете (0), но на этот раз внимательно, ладно?
(13) Лимит 6. В списке 6 архивов и current, созданный сегодня.
(0)удали все будь мужиком .
(15) врят ли эти уже наваленные текстовики можно из скуля почистить.
(15) Тогда посмотри в
«Агент SQL сервер :ПКМ по «Журналы ошибок-Настроить» — По моему он туда спамит.
(18) У него, вроде, конкретный файл задан. Он ростом всего 2 килобайта.
.mdmp
файлы дампов. советую задуматься.
У файлов *.log
pid51 * dbghelp 12B40000 12C54FFF 00115000
2012-11-28 15:08:21.86 spid51 *
*.mdmp — бинарные какие-то.
(20) задуматься можно, а толку, если не знаешь, как это анализировать?
это жжж не спроста
О! А вот это уже улика.
в *.txt
End log dump for db = ‘ESETRADB’
Никто не сталкивался с Eset Remote Administrator 4.2? Как решить эту проблему, или хотя бы определить, почему он мусорит в лог?
Выборка более-менее вменяемых строк из SQLDump10144.txt (номер 10144 тоже настораживает):
Begin transaction log dump for database ‘ESETRADB’; for Index maintenance — filter on ObjId.
.
Operation = LOP_SET_BITS
Context = LCX_PFS
Log Record Fixed Length = 54
Log Record Length = 56
AllocUnitName = dbo.LinkClientQuarantine.IX_LinkClientQuarantine_ClientID
Log Record = 00003600000000000000000000000000000000000000070b0100000001000000a3000000e61b00009c01000003000001eb07010001000000
.
Operation = LOP_DELETE_ROWS
Context = LCX_MARK_AS_GHOST
Log Record Fixed Length = 62
Log Record Length = 116
AllocUnitName = dbo.LinkClientQuarantine.IX_LinkClientQuarantine_ClientID
Number of Locks = 3
Lock Information = HoBt 72057594043629568:ACQUIRE_LOCK_IX OBJECT: 22:1954106002:0 ;ACQUIRE_LOCK_IX PAGE: 22:1:249;ACQUIRE_LOCK_X KEY: 22:72057594043629568 (0400be72e6fc)
Log Record = 00003e00e61b00009c0100000400020096d02b0000000313f900000001000200a3000000e61b00002f010000090000010000570000000001010000000000020012001a000603000000019cec0000000000000000000000000101000c0000924a79740000010200040204000a0400be72e6fc0200
и таких пар LOP_SETS_BITS-LOP_DELETE_ROWS — на полтора мегабайта.