Шринк лога транзакций MS SQL 2008/2012 в экстренном случае или боремся с ошибкой HRESULT=80040E14
Когда при подключении к базе MS SQL появляются ошибки:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Журнал транзакций для базы данных "ReportServer" заполнен. Чтобы обнаружить причину, по которой место в журнале не может быть повторно использовано, обратитесь к столбцу log_reuse_wait_desc таблицы
sys. databases HRESULT=80040E14, SQLStvr: Error state=2, Severity=11,native=9002, line=1
или
Ошибка СУБД:
Microsoft OLE Provider for SQL Server: The transaction log for database “ReportServer” is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column is sys.database
HRESULT=80040E14, SQLSTATE=4 2000, native=9002
это значит, что на диске, где расположен лог транзакций закончилось место и теперь СУБД некуда записывать данные о новых транзакциях. Чаще всего такое происходит, когда не установлено никаких ограничений на размер лога и в MS SQL не создано соответствующих планов обслуживания.
В таком случае нужно уменьшить размер самого файла транзакций (*.ldf), другими словами сделать шринк (сжатие) лога. Для этого можно использовать как запрос, так и сжатие лога вручную.
Рассмотрим сжатие лога транзакций вручную:
Шаг 1. Установить модель восстановления Простая (Simple). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Простая(Simple) - OK.
Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) -
указать приемлемый размер лога.
Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Полная(Full) - OK.
P.S.: В данной статье даны рекомендации для решения конкретной проблемы. Настройка самого MS SQL здесь не рассматривается!
Database Compression Tool
Инструмент для свертки и сжатия баз данных 1С
Доступна демо-версия с прогнозом результата
Вступайте в нашу телеграмм-группу Инфостарт
Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
См. также
Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Разработчик Руководитель проекта 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Россия Платные (руб)
Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP, УНФ, КА и т.д.). Поддерживаются серверные и файловые базы, управляемые и обычные формы, интерфейс 8.5. Может выполнять свертку одновременно в несколько потоков, а также без непосредственного участия пользователя. Решение в Реестре отечественного ПО.
24900 руб.
20.08.2024 83146 431 171
Информационная безопасность Чистка данных Системный администратор Разработчик Руководитель проекта 1С 8.3 1С:Бухгалтерия 3.0 Платные (руб)
Обезличивает копию рабочей базы 1С перед передачей наружу и возвращает настоящие данные обратно, когда база вернулась. Это обратимая псевдонимизация: соответствия «исходное - псевдоним» пишутся в отдельный зашифрованный датасет, который остаётся у владельца. Работает на любой конфигурации - обходит метаданные и находит персональные данные сам, без списка реквизитов под конкретную базу. Суммы, количества, даты и номера документов не трогает никогда, оборотно-сальдовая до и после совпадает до копейки. Проверено на трёх конфигурациях: 106 031 объект, 215 642 замены, ноль ошибок, возврат 100 процентов.
42700 руб.
18.08.2026 1460 3 0
Чистка данных Системный администратор Разработчик 1С:Предприятие 8 1C:Бухгалтерия 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x 1С:Управление нашей фирмой 3.0 1С:Розница 3.0 Платные (руб)
Update 2026: добавили многопоточное удаление данных по организациям. Ускорение х6 по сравнению с однопоточным алгоритмом! Позволяет удалить организации из любых из информационных баз 1С на управляемых формах (БП 3.0, УТ 11, КА 2, ERP 2, ЗУП 3, УНФ, Розница 3.0 и пр.). Главное требование - программа должна содержать справочник "Организации". Реализован самый быстрый алгоритм непосредственного удаления объектов. Работает даже на базах большого размера. Для ускорения работы алгоритма не запускается проверка контроля ссылочной целостности. Проверку учета можно запустить отдельно с помощью дополнительной обработки. Необходимо перед удалением самостоятельно проверить базу на наличие перекрестных ссылок разных организаций в одном документе. Эту дополнительную обработку проверки перекрестных ссылок по запросу предоставляем бесплатно нашим покупателям.
12139 руб.
16.03.2015 282860 271 84
Чистка данных Разработчик Пользователь 1С:Предприятие 8 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Платные (руб)
Обработка позволяет удобно и выборочно удалить данные из базы 1С на управляемых формах например БП 3.0, УТ 11, КА 2, ERP, УНФ, ЗУП 3, Розница и др. Это могут быть неактуальные организации или другие перечни объектов. При этом есть возможность провести анализ пересечений документов с другими организациями и таким образом уберечься от того, что при удалении обороты по другой организации изменятся. Объекты нужно выбирать вручную и после этого запускать команду удаления. Будут удалены все ссылки на них.
5000 руб.
28.11.2019 31390 86 21
Оптовая торговля Логистика, склад и ТМЦ Чистка данных Разработчик Бухгалтер Пользователь 1С:Предприятие 8 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)
Если вы начали работать в программном продукте Управление Торговлей, редакция 11 или Комплексная Автоматизация редакция 2 и включили механизм учёта серий, то перейти обратно в учёт без серий будет не так-то просто. Сложность заключается в том, что нужно очистить серии в табличной части документа, например, Реализация Товаров и услуг. Предлагаем алгоритм перехода на учет без серий для программного продукта УТ11. (Очистка серий.)
5084 руб.
09.04.2019 32905 51 15
Чистка данных Системный администратор Разработчик Бухгалтер Пользователь 1С:Предприятие 8 1C:Бухгалтерия Россия Платные (руб)
Решение по удалению дублей позволяет определить связанные элементы в двух синхронизированных базах в качестве оригиналов и избежать необходимости ручного сравнения объектов в базах перед синхронизацией.
6100 руб.
27.06.2018 21474 17 3
Чистка данных Инструменты администратора БД Администрирование 1С 8.3 1С:Документооборот 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Управление холдингом 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 Платные (руб)
Решение представляет собой набор из 6 обработок для 1С по удалению организаций и справочников из базы по фильтрам, документов по фильтрам, универсальное сжатие данных, очистка битых движений регистратора, удаление устаревших регистров сведений, удаление устаревших документов "Электронное письмо входящее" и "Электронное письмо исходящее"
23999 руб.
20.02.2026 2387 1 0
Чистка данных Инструменты администратора БД Разработчик Пользователь 1С 8.3 1С:Управление торговлей 10 1С:Управление торговлей 11 1С:Библиотека стандартных подсистем Абонемент ($m)
Хочешь выборочно удалить одну организацию, тестовую номенклатуру или «мусорного» контрагента, любую ссылку - без ручного поиска ссылок и часовых разборок зависимостей? Этот инструмент сам строит дерево связей, каскадно чистит с "глубоким поиском" документы, справочники, пвх, любые ссылки, регистры, движения в так же делает резервную копию и за пару минут оставляет базу чистой и полностью работоспособной (Управляемые формы, обычный интерфейс)
1 стартмани
03.02.2026 4740 152 war41k 0
Полный бред! Не видела ни разу ни одной фирмы, где в течение дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед, если уж так плющит(видела в одной конторке, где сотрудников принудительно выгоняют на хавчик из офиса и базы) и получасовые снапшоты, если уж совсем фобия.
Выводы: простой режим восстановления, ночной бакап + в обед,
все зависит от бизнеса, если вы не видели - это не значит что этого нет.
Мне казалось, что здесь идет около1С'ный тред, а не за банковскую, биллинговую, провайдерскую или какую-то еще сферу, где критически важны состояния баз данных на сотые доли секунды. В конце концов, я совершенно не представляю, что в хозяйстве, скажем, Грефа, администраторы БД режут логи...
ЗЫ. можно не вступать в дискуссию... просто мысли вслух. Всех благ.
у меня есть конкретный 1сный кейс где идет реплицирование транзакций на резервную ноду, восстановление при отказе порядка 2х минут, вариант отката на утро совсем не приемлем, так как к середине дня будет потеряно около 800 документов.
Не, не, не... Я не попадусь на вашу уловку безотказных кластеров, мирроринга и т.п. :)
Как говорится, это совсем другая история.
Несколько раз были случаи, когда главные бухгалтера ошибочно портили данные - перезакрывали закрытый месяц, удаляли документы в закрытом периоде. Вот тут и пригождались почасовые бэкапы. Благо места занимают мало.
Ну, не знаю... Удалять документы в закрытом - запрет редактирования. В конце концов, повторюсь, проще делать снапшоты пока главбуня развлекается с ограниченным периодом полураспада(жизни)
1.Насчет того что "разрастается лог, который часто занимает весь диск" - это не обсуждаем.
SQL сервер тоже нужно настраивать, а не просто поставить по умолчанию.
2."предпочтительно использовать именно простую модель, с каждодневным бакапом" - я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет. А вот если заявляет и база большая, то простой моделью не выкрутишься.
Либо не обеспечишь нормальную периодичность восстановления, либо если обеспечишь, то тогда база будет ложиться
в момент выполнения полного бэкапа при простой модели.
никто не заявляет.
Простая модель хороша для любых баз (и больших и не больших), если нет требований по восстановлению на любой момент времени.
Отчего же не обсуждаем? Вы знакомы с проблемой "база загружена не полностью" и её причиной?
(21) МихаилМ,
нет смысла его усекать.
как бы работа самой базы? Наставляемые обновления? Изменения в конфе? Нет?
Это все не приводит к увеличению лога?
а то что написано можно делать только на базе без подключенных пользователей - хотя зачем это нужно?? если можно обойтись стандартной процедурой в одну строчку мссиквела.
кому интересно - тот хотя-бы на sql.ru поищет.
если про "Усечь журнал транзакций" в 2012 - то он не всегда отрабатывает. А лог нужно урезать обязательно.
(5) caponid,
С пользователями делается.
(1) adhocprog,
Когда у вас будут вводить по десятку документов в секунду, тогда и оцените восстановление на любой момент времени.
(9) dvv01,
А потому, что принудительно лог очищается ВСЕГДА. А не как придется в случае автошринка при выгрузке.
А есть случаи, когда нужно обрезать только лог, без бэкапа...
Метод описанный в статье имеет право на жизнь, но лучше все изначально грамотно спроектировать, что бы проблема с "внезапно" выросшим журналом не было в принципе.
Работает всё давно. Клиент без обслуживания админом, зовёт раз в пятилетку на проблемы. И тут решает он переработать каталог. И в течении двух недель его активной деятельности шлёпаются изменения по паре гигов в час. Внезапно диск под архивы заканчивается и покуда никто за этим не следит, следом, так же внезапно заканчивается и место на диске с логами. И всё. Ничего никуда не едет. Вот теперь можно и админа звать )))
Действительно, бывают запущенные ситуации, когда с логом уже ничего сделать нельзя (ни бэкап, ни шринк).
Я правильно понимаю, что эта операция поможет в случае, когда на диске уже почти не осталось свободного места?
Также можно настроить выполнение по расписанию.
USE ИмяБазыДанных
ALTER DATABASE ИмяБазыДанных
SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (ИмяФайлаЛога,100) -- 100 кол-во мб
GO
ALTER DATABASE ИмяБазыДанных
SET RECOVERY FULL;
GO ПоказатьДля откатов, делаете дифференцированные бекапы базы в продолжении для (периодичность скажем час) и всё что нужно есть.
Шринк да базе 90 Гб при полной модели при робочих юзерах (лог файл 50-150 Гб) нивжизнь не пройдёт, или будет делаться очень долго. Так как при полной модели в основной базе ещё нет изменений, которые хранятся в лог-файле, а если юзера работают с данными, изменения по которым должны быть записаны... Ну и немаловажный факт - количество юзеров. У меня их за 100 одновременно работающих. Транзакции никто таки не отменял...
Как одноразовая мера, чтобы если база выжрала всё место на диске и отказывается работать, вполне оно. Все равно никто работать уже не будет. Тогда да, это самый эффективный вариант.
причем реально база 19,5 ГБ в локальной файловой копии.(45 ГБ стала после загрузки в существующую DT-архива - может подскажете как правильно вернуть назад???).
Сделал все как в статье (не стал БЭКАП делать ибо некуда. ограничился выгрузкой в ДТ-архив.) при неработающих пользователях. размер указал 30 ГБ. Шринк прошел очень быстро. Щас настраиваю планы обслуживания (пока на тестовой базе) и ставлю вопрос о приобритении винта специально под бэкапы.
Но у меня такой вопрос
Вроде установил модель обратно в FULL, но даже сделав реиндексацию таблиц после этого размер журнала не изменился. и мало того уже рабочий день заканчивается - куча проведеных документов была, но размер какой был такой остался и дата изменения не изменяется (последние изменения базы - 0:22 - ночью в базе никто не работает кроме меня:) а лога аж 22 числа, т.е. 2 дня назад) - у меня установлено автоувеличение лога на 200 Мб, а базы на 500 МБ, может быть дата изменения меняется только во время увеличения размера.
Хотя после реиндексации размер лога должен был увеличиться на 25 ГБ (так было до шринка) - может кто нибудь разъяснить почему лог на месте стоит? - планы бэкапов еще не подключал т.е никакого архивирования нет.
Рецепт простой:
//начинаем транзакцию
BEGIN TRAN
GO
//делаем апдейт какого нибудь поля какой нибудь большой таблицы
UPDATE ....
GO
//отменяем транзакцию
ROLLBACK
GO
После этого файл можно усечь на размер заполненных данных в файле ldf.
Рецепт используем столько раз, сколько потребуется.
BACKUP LOG Base TO DISK = '<D:\Backup\Base_Log.trn'
DBCC SHRINKFILE (Base_Log, 20) WITH NO_INFOMSGSЗатем файл с логом можно удалить, либо перенести на другой диск/сервер
Полная же модель подразумевает - восстановление на любой момент времени, что невозможно, если данные транзакций уничтожены (лог транзакций стерт). Поэтому его в таком случае не трут, а также бэкапят вместе с базой. Но это именно для тех, кто понимает, что ему нужно. Для остальных - SIMPLE режим :)
При полной модели восстановления бэкапы делаются так часто как это возможно для того чтобы процесс восстановления начинать не с испокон веков существования базы а с последнего полного созданного бэкапа + далее накатывают после этого бэкапы логов транзакций. это очень удобно хотя на практике приходилось пользоваться всего пару раз в жизни. У нас например это раз в неделю по четвергам (самое оптимальное время исходя из всех регламентов скуля + сервера 1С).
При простой модели вы сможете восстановить базу только на момент последнего созданного бэкапа.
Если у вас есть нормальное ПО по управлению бэкапами и логами ТЗ (хотя все это можно написать и на SQL) то делается просто.
Полная модель. Создается бэкап базы, хранится, далее бэкапятся логи раз в нужное вам время у нас это 15 минут, логи тоже хранятся, но каждый раз когда проходит полный бэкап базы НОРМАЛЬНО все старые бэкапы базы и логов трутся и начинается новый отсчет времени. Ну и так же настроено месячное хранение базы полугодичное и годовалое которые хранятся отдельно и трутся соответственно когда создаются подобные бэкапы.
При полной модели и наших настройках мы можем восстановить базу максимум с недельной давностью, далее все остальное накатить логами.
Так же мы можем восстановить базу на начало месяца, начало полугодия и начало года но уже без логов транзакций.
Насчет тормозов не могу согласиться с предыдущими ораторами о том что простая модель работает быстрее, они работают одинаково если нормально настрое сервер SQL, просто лог транзакций должен по умолчанию лежать на другом зеркале, отдельно от того зеркала где располагается база. Много раз проверяли что так что так работает одинаково. Если же логи транзакций лежат на том же массиве что и база - безусловно будет работать медленнее.
Т.е. если сделать выгрузку через конфигуратор и грохнуть эти 700 Гб, то можно спать спокойно? Или сделать полный бэкапп нужно средствами SQL?
Что надо сделать для успешного сжатия журнала транзакций? Используется SQL Server, модель восстановления FULL.
1 Резервную копию журнала транзакций.
2 Полную резервную копию.
3 Разностную резервную копию.
4 Верны ответы 1 и 2.
5 Верны ответы 1, 2 и 3.
Правильный ответ: 1
Размер журнала выбирается не "до скольки сжать", а по тому, что мешает его переиспользовать. Смотрите log_reuse_wait_desc в sys.databases. Пока там не NOTHING, шринк даёт отсрочку, а не решение: журнал отрастёт обратно. Гонял сегодня по живому серверу, 20 баз: у трёх стоит ACTIVE_TRANSACTION или CHECKPOINT, у остальных NOTHING. Журнал 500 при базе 100 это обычно FULL без бэкапов журнала или зависшая транзакция, а не "большой журнал".
Про mdf. Шринк данных тащит страницы с конца файла в начало и ломает физический порядок индексов. После него нужен REBUILD, а он снова растит журнал. Разово после реальной чистки данных можно, регламентом нельзя.
И про рецепт из (60), это важнее остального. Переключение в SIMPLE и обратно в FULL рвёт цепочку восстановления. После возврата в FULL надо сразу снять полный бэкап, иначе бэкапы журнала, снятые до этого, к восстановлению уже не годятся.
Причины роста собрал в обработку, она читает их сама:
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 168314
Создание 15.01.13 17:04
Обновление 11.10.13 02:45
Просмотры 448138
Загрузки 0
Рейтинг
167
Комментарии 60
Код открыт Не указано
Рубрики Чистка данных
Тип файла Нет файла
Платформа 1С:Предприятие 8
Конфигурация Универсальные
Операционная система Windows
Страна Не имеет значения
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
