Шринк лога транзакций MS SQL 2008/2012 в экстренном случае или боремся с ошибкой HRESULT=80040E14

11.10.13

Пошаговая инструкция по уменьшению лога транзакций (*.ldf) MS SQL 2008/2012.

Когда при подключении к базе 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.

Шринк лога MS SQL 2008/2012

Шринк лога транзакций MS SQL 2008/2012

Шаг 2. Выполнить шринк (сжатие) лога транзакций. Правой кнопкой на базе - Задачи(Tasks) - Сжать(Shrink) - Файлы(Files) - установить Тип файла(File type) - Журнал(Log) - в Операция сжатия(Shrink action) - выбрать Реорганизовать страницы, перед тем осводить неиспользуемое место(Reorganize pages before releseasing unused space) - Сжать файл (Shrink file to) -
указать приемлемый размер лога.

Шринк лога транзакций MS SQL 2008/2012

Шаг 3. Установить модель восстановления Полная(Full). Правой кнопкой на базе - Свойства(Properties) - Параметры(Options) - 4-й сверху пункт Модель восстановления(Recovery model) - Полная(Full) - OK.

Шринк лога транзакций MS SQL 2008/2012

P.S.: В данной статье даны рекомендации для решения конкретной проблемы. Настройка самого MS SQL здесь не рассматривается!

+163 –3

См. также

SALE! 15%

Database Compression Tool (DCT) Универсальный инструмент сжатия, свертки и конвертации баз данных 1С

Инструментарий разработчика Чистка данных Свертка базы Инструменты администратора БД Системный администратор Программист Руководитель проекта Платформа 1С v8.3 Конфигурации 1cv8 1С:Управление торговлей 10 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 Россия Платные (руб)

Инструмент представляет собой обработку для проведения свёртки или обрезки баз данных. Работает на ЛЮБЫХ конфигурациях (УТ, БП, ERP и т.д.). Поддерживаются управляемые и обычные формы. Может выполнять свертку сразу нескольких баз данных и выполнять их автоматически без непосредственного участия пользователя.

~~8400~~ 7140 руб.

20.08.2024 8197 60 29

Выборочное удаление организаций из информационных баз 1С (управляемые формы), с удалением всех ссылающихся на эти организации данных

Чистка данных Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Розница 3.0 Платные (руб)

Позволяет удалить организации из любых из информационных баз 1С на управляемых формах (БП 3.0, УТ 11, КА 2, ERP 2, ЗУП 3.0, УНФ, Розница 2.0 и пр.). Главное требование - программа должна содержать справочник "Организации". Реализован самый быстрый алгоритм непосредственного удаления объектов. Работает даже на базах большого размера. Для ускорения работы алгоритма не запускается проверка контроля ссылочной целостности. Проверку учета можно запустить отдельно с помощью дополнительной обработки. Необходимо перед удалением самостоятельно проверить базу на наличие перекрестных ссылок разных организаций в одном документе. Эту дополнительную обработку проверки перекрестных ссылок по запросу предоставляем бесплатно нашим покупателям.

3582 руб.

16.03.2015 174222 209 81

244

Удаление данных с отбором и построением дерева ссылок в базах 1С 8.1-8.3 УТ 10.3./11, БП 2/3, ЗУП 2.5/3, КА 1.1/2, УНФ 1.6/3.0

Чистка данных Системный администратор Программист Платформа 1С v8.3 Управляемые формы Конфигурации 1cv8 1С:Управление торговлей 10 1С:Управление торговлей 11 Платные (руб)

Данные обработки помогут Вам легко и, главное быстро, выполнить удаление любых данных в Ваших базах 1С на платформах 8.1-8.3. Обработки помогут легко просмотреть связи ссылок в виде дерева, выбрать что удалять, а что нет, используя любые отборы. Это позволит уменьшить объем лишней и не нужной информации в справочниках и документах, планах видов характеристик и др. объектах и облегчит работу с данными пользователям и Вам. Понятное расположение команд и настроек, в сочетании с описанием и справкой, еще упростят процесс. (Обновление от 29.06.2023, версия 4.2)

9600 руб.

22.02.2013 138460 259 144

430

Универсальное удаление данных из базы 1С (любые конфигурации на упр.формах: БП 3.0, УТ 11, КА 2, ERP, УНФ, ЗУП 3, Розница и т.д.)

Чистка данных Программист Пользователь Платформа 1С v8.3 Управляемые формы 1С:Розница 2 1С:Управление нашей фирмой 1.6 1С:ERP Управление предприятием 2 1С:Зарплата и кадры государственного учреждения 3 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Зарплата и Управление Персоналом 3.x Платные (руб)

Обработка позволяет удобно и выборочно удалить данные из базы 1С. Это могут быть как неиспользуемые элементы справочников, так и неактуальные организации. При этом есть возможность провести анализ пересечений документов с другими организациями и таким образом уберечься от того, что при удалении обороты по другой организации изменятся.

3350 руб.

28.11.2019 25897 59 16

Алгоритм перехода на учет без серий для УТ11.4 или КА 2.4 (отказ от серий, удаление серий, отмена серий, без серий)

Оптовая торговля Логистика, склад и ТМЦ Чистка данных Программист Бухгалтер Пользователь Платформа 1С v8.3 Оперативный учет 1С:Управление торговлей 11 Россия Управленческий учет Платные (руб)

Если вы начали работать в программном продукте Управление Торговлей, редакция 11 или Комплексная Автоматизация редакция 2 и включили механизм учёта серий, то перейти обратно в учёт без серий будет не так-то просто. Сложность заключается в том, что нужно очистить серии в табличной части документа, например, Реализация Товаров и услуг. Предлагаем алгоритм перехода на учет без серий для программного продукта УТ11. (Очистка серий.)

2400 руб.

09.04.2019 29075 43 14

Очистка дублей в синхронизированных базах (УТ, БП, РТ, УНФ)

Чистка данных Системный администратор Программист Бухгалтер Пользователь Управляемые формы Конфигурации 1cv8 Россия Платные (руб)

Решение по удалению дублей позволяет определить связанные элементы в двух синхронизированных базах в качестве оригиналов и избежать необходимости ручного сравнения объектов в базах перед синхронизацией.

3960 руб.

27.06.2018 19167 11 3

Обработка 1С удаление битых ссылок в базе без монопольного режима

Чистка данных Программист Платформа 1С v8.3 Конфигурации 1cv8 Платные (руб)

Если в вашей информационной базе крутится очень много данных, или база должна быть доступна 24/7 (как в моем случае), или же вы боитесь запускать тестирование и исправление, НО существует потребность удалить битые ссылки, тогда эта обработка сможет Вам помочь. Обработка выявляет битые ссылки как в самих объектах метаданных, так и в их табличных частях(!), а так же может их удалить.

2400 руб.

23.08.2021 9951 19 3

Очистка регистров сведений от записей по помеченным на удаление элементам

Чистка данных Системный администратор Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

в современных конфигурациях стало очень много регистров сведений, хранящих вспомогательную и периодическую информацию и администраторы информационных систем стали сталкиваться с проблемой удаления помеченных на удаление объектов, так как ссылки на них хранятся в многочисленных регистрах сведений. Помочь почистить базу от ненужных записей предназначенная данная внешняя обработка на управляемой форме, которая ищет записи во всех регистрах сведений по помеченным на удаление объектах и очищает по ним записи их после использования данной обработки дальше можно смело пользоваться типовой обработкой удаление помеченных на удаление и проблем с удалением не возникнет! Удачи всем!

1 стартмани

21.01.2022 7719 1 dmbal 6

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. adhocprog 1142 15.01.13 20:14 Сейчас в теме

(0) а зачем возвращать в состояние "Полная"?
Можно оставаться на Простой и рассчитывать только на бэкапы.

2. aspirator23 339 15.01.13 21:37 Сейчас в теме

(1) Полная более гибкая. А для больших баз еще и быстрая: с одной стороны можно обеспечить маленькие интервалы восстановления, с другой быстрый бэкап в рабочее время.

6. zzz_natali 61 16.01.13 04:48 Сейчас в теме

(2) aspirator23,
Полный бред! Не видела ни разу ни одной фирмы, где в течение дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед, если уж так плющит(видела в одной конторке, где сотрудников принудительно выгоняют на хавчик из офиса и базы) и получасовые снапшоты, если уж совсем фобия.

Ответить

46. un2qum 6 04.06.21 03:19 Сейчас в теме

(6)

ние дня начинали восстанавливать бакап, а потом еще пол-дня чесали репу, какие доки/транзашки были сделаны, а какие нет(учитывая, что 30-50тичисленное стадо манагеров постоянно разбредается и никого не собрать по тубзикам-курилкам, чтобы выяснить где был реал-тайм).
Выводы: простой режим восстановления, ночной бакап + в обед,

все зависит от бизнеса, если вы не видели - это не значит что этого нет.

Ответить

47. zzz_natali 61 04.06.21 08:56 Сейчас в теме

(46)
Мне казалось, что здесь идет около1С'ный тред, а не за банковскую, биллинговую, провайдерскую или какую-то еще сферу, где критически важны состояния баз данных на сотые доли секунды. В конце концов, я совершенно не представляю, что в хозяйстве, скажем, Грефа, администраторы БД режут логи...
ЗЫ. можно не вступать в дискуссию... просто мысли вслух. Всех благ.

48. un2qum 6 06.06.21 02:20 Сейчас в теме

(47)

Грефа, администраторы БД режут лог

у меня есть конкретный 1сный кейс где идет реплицирование транзакций на резервную ноду, восстановление при отказе порядка 2х минут, вариант отката на утро совсем не приемлем, так как к середине дня будет потеряно около 800 документов.

49. zzz_natali 61 07.06.21 08:45 Сейчас в теме

(48)
Не, не, не... Я не попадусь на вашу уловку безотказных кластеров, мирроринга и т.п. :)
Как говорится, это совсем другая история.

50. user618912_redgad 14 09.06.21 08:30 Сейчас в теме

(6)
Несколько раз были случаи, когда главные бухгалтера ошибочно портили данные - перезакрывали закрытый месяц, удаляли документы в закрытом периоде. Вот тут и пригождались почасовые бэкапы. Благо места занимают мало.

51. zzz_natali 61 09.06.21 08:49 Сейчас в теме

(50)
Ну, не знаю... Удалять документы в закрытом - запрет редактирования. В конце концов, повторюсь, проще делать снапшоты пока главбуня развлекается с ограниченным периодом полураспада(жизни)

13. mxm2 1268 16.01.13 10:42 Сейчас в теме

(2) aspirator23, Полная модель восстановления - обеспечивает восстановление "с точностью" "до минуты" (имею ввиду из бакапа), но это приводит к тому что разрастается лог (часто он занимает весь диск, и база "останавливается"), Простая модель - позволит восстановить информацию только на момент создания бакапа, никакого (почти) влияния на скорость работы эти модели не имеют (полная модель теоретически медленнее - т.к. при её использовании делается множество "лишних записей" в лог, в отличие от простой модели). подробнее тут http://www.gilev.ru/1c/mssql/backup.htm. Поэтому предпочтительно использовать именно простую модель, с каждодневным бакапом (в наиболее ненагруженное пользователями и фоновыми заданиями время), и с регулярным автоматическим шринкованием, через планы обслуживания СКЛ (кстати использование планов обслуживания 2008/2012 также позволяет "без написаания запросов", производить гибкие настройки многих вещей, в частности бакапов и шринков, да и много чего еще). вот тут еще инфа есть про бакап http://aquablog.3dn.ru/publ/15-1-0-52

14. aspirator23 339 16.01.13 11:26 Сейчас в теме

(13) Важное замечание сделал(11).
1.Насчет того что "разрастается лог, который часто занимает весь диск" - это не обсуждаем.
SQL сервер тоже нужно настраивать, а не просто поставить по умолчанию.
2."предпочтительно использовать именно простую модель, с каждодневным бакапом" - я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет. А вот если заявляет и база большая, то простой моделью не выкрутишься.
Либо не обеспечишь нормальную периодичность восстановления, либо если обеспечишь, то тогда база будет ложиться
в момент выполнения полного бэкапа при простой модели.

16. mxm2 1268 16.01.13 11:52 Сейчас в теме

(14) aspirator23,

- я уже писал, что простая модель хороша для небольших баз. А также в случае если требования по восстановлению
никто не заявляет.

Простая модель хороша для любых баз (и больших и не больших), если нет требований по восстановлению на любой момент времени.

32. AlexO 135 14.11.14 12:55 Сейчас в теме

(14) aspirator23,

Насчет того что "разрастается лог, который часто занимает весь диск" - это не обсуждаем.

Отчего же не обсуждаем? Вы знакомы с проблемой "база загружена не полностью" и её причиной?
(21) МихаилМ,

без предварительного выяснения, почему увеличился размер transaction log,
нет смысла его усекать.

как бы работа самой базы? Наставляемые обновления? Изменения в конфе? Нет?
Это все не приводит к увеличению лога?

3. bintape 15.01.13 22:27 Сейчас в теме

Еще бы автор написал, для чего вообще нужна данная процедура )

4. Kserken 487 15.01.13 22:51 Сейчас в теме

(3) batan, данная процедура нужна в том случае, если логи сильно разрастаются. Было у меня на практике, когда нерадивые сисадмины не следили за логами и они разрастались до размеров нескольких сотен ГБ (240 Гб если быть точным, был и в 70 Гб). Поэтому и приходилось выполнять такие манипуляции.

5. caponid 16.01.13 01:21 Сейчас в теме

Читайте плз документацию к БД она не просто так писана - если бы мог, поставил бы минус публикации - есть стандартные процедуры с бекапом и обрезкой лога.
а то что написано можно делать только на базе без подключенных пользователей - хотя зачем это нужно?? если можно обойтись стандартной процедурой в одну строчку мссиквела.
кому интересно - тот хотя-бы на sql.ru поищет.

7. aspirator23 339 16.01.13 06:56 Сейчас в теме

(5) То что написано делается без "выгоняния" пользователей.
(6) Попробуйте поработать с большими базами данных. Тогда и опыт появился бы и понимание как это работает.
То что вы не видели, не означает, что у всех также.

Ответить

31. AlexO 135 14.11.14 12:52 Сейчас в теме

(5) caponid,

есть стандартные процедуры с бекапом и обрезкой лога.

если про "Усечь журнал транзакций" в 2012 - то он не всегда отрабатывает. А лог нужно урезать обязательно.
(5) caponid,

а то что написано можно делать только на базе без подключенных пользователей

С пользователями делается.
(1) adhocprog,

Можно оставаться на Простой

Когда у вас будут вводить по десятку документов в секунду, тогда и оцените восстановление на любой момент времени.
(9) dvv01,

А почему сразу его не поставить в TRUE?

А потому, что принудительно лог очищается ВСЕГДА. А не как придется в случае автошринка при выгрузке.
А есть случаи, когда нужно обрезать только лог, без бэкапа...

8. Aleksey-29 16.01.13 08:28 Сейчас в теме

делаем то же самое. работает на 100%. Выгонять пользователей не нужно. Место на диске за 3 минуты освобождается.

9. dvv01 120 16.01.13 09:15 Сейчас в теме

На одной из картинок в параметрах есть такое свойство как "автоматическое сжатие = FALSE".
А почему сразу его не поставить в TRUE? И забыть про все вышеописанное?

17. Kserken 487 16.01.13 14:07 Сейчас в теме

(9) dvv01, можно даже настроить, чтобы с логом вообще проблем не было, но в данном примере рассмотрено как это можно сделать просто и быстро

10. logos 214 16.01.13 09:21 Сейчас в теме

Вредительская статья. Уходить на простую модель без предварительного полного бэкапа - мягко говоря опрометчиво. Ну в общем то и формулировка задачи странная. Проще 1 раз настроить задания по созданию бэкапов и обрезанию логов (о боже с запросами, да да) и забыть об этом.

Ответить

11. Babuin 16.01.13 09:47 Сейчас в теме

Автор забыл добавить что после обратного перехода на полную модель нужно собственно сделать полный бэкап, так как он предыдущими действиями прервал цепочку восстановления, соответственно если есть задания по бэкапу оно не будет выполнятся, пока не пройдет новый фул бэкап.
Метод описанный в статье имеет право на жизнь, но лучше все изначально грамотно спроектировать, что бы проблема с "внезапно" выросшим журналом не было в принципе.

19. Kserken 487 16.01.13 14:22 Сейчас в теме

(11) Babuin, по-поводу полного бэкапа добавлю. А вот насчет настройки - это отдельная тема. Я лишь показал, как по-быстрому место освободить. У самого базы висят и все настроено. Так что настройку тут не рассматриваю.

52. ne_en 84 05.11.21 11:08 Сейчас в теме

(11) Внезапно выросший журнал, говорите? Легко!
Работает всё давно. Клиент без обслуживания админом, зовёт раз в пятилетку на проблемы. И тут решает он переработать каталог. И в течении двух недель его активной деятельности шлёпаются изменения по паре гигов в час. Внезапно диск под архивы заканчивается и покуда никто за этим не следит, следом, так же внезапно заканчивается и место на диске с логами. И всё. Ничего никуда не едет. Вот теперь можно и админа звать )))

12. bforce 482 16.01.13 10:28 Сейчас в теме

Идея неплоха, но в заголовке статьи не хватает надписи "в экстренном случае" или "когда штатные средства не позволяют"
Действительно, бывают запущенные ситуации, когда с логом уже ничего сделать нельзя (ни бэкап, ни шринк).

Я правильно понимаю, что эта операция поможет в случае, когда на диске уже почти не осталось свободного места?

18. Kserken 487 16.01.13 14:18 Сейчас в теме

(12) bforce, дельное замечание по-поводу названия. Да, когда места нет, а его нужно срочно освободить.

15. ixileon 16.01.13 11:39 Сейчас в теме

Я обычно делаю скриптом. Быстрее получается.
Также можно настроить выполнение по расписанию.

USE ИмяБазыДанных
ALTER DATABASE ИмяБазыДанных
SET RECOVERY SIMPLE;
GO

DBCC SHRINKFILE (ИмяФайлаЛога,100) -- 100 кол-во мб
GO

ALTER DATABASE ИмяБазыДанных
SET RECOVERY FULL;
GO

Показать

Ответить

20. Kserken 487 16.01.13 14:26 Сейчас в теме

(15) ixileon, можно скриптом. А можно как и у меня. Тут кому как удобнее.

39. Hasper 16.12.18 20:56 Сейчас в теме

(15) А как в автомате по всем базам.. т.к. баз за 100 ню?

53. ne_en 84 05.11.21 11:16 Сейчас в теме

(15) А не стоит ли теперь полный бэк сделать? А то мало ли чего, а тут цепочка в лоскуты.

21. МихаилМ 16.01.13 14:48 Сейчас в теме

без предварительного выяснения, почему увеличился размер transaction log,
нет смысла его усекать. втом числе и автоусекать.

22. Иной 17.01.13 00:26 Сейчас в теме

У меня база 90 Гб. В режиме Siple, ибо то что делают юзеры и программеры с базой часто в модели Full увеличивало базу раз в 5. Даже в Siple модели лог увеличивается, если есть большое количество изменений (15-30 Гб бывает).

Для откатов, делаете дифференцированные бекапы базы в продолжении для (периодичность скажем час) и всё что нужно есть.

Шринк да базе 90 Гб при полной модели при робочих юзерах (лог файл 50-150 Гб) нивжизнь не пройдёт, или будет делаться очень долго. Так как при полной модели в основной базе ещё нет изменений, которые хранятся в лог-файле, а если юзера работают с данными, изменения по которым должны быть записаны... Ну и немаловажный факт - количество юзеров. У меня их за 100 одновременно работающих. Транзакции никто таки не отменял...

Как одноразовая мера, чтобы если база выжрала всё место на диске и отказывается работать, вполне оно. Все равно никто работать уже не будет. Тогда да, это самый эффективный вариант.

23. echo77 1906 06.06.13 16:57 Сейчас в теме

На хера ReportServer 1С?

25. Kserken 487 20.08.13 00:01 Сейчас в теме

(23) echo77, не захотел создавать тестовую базу вот на ней и показал. Действительно, нужно будет изменить скрины.

24. Vitek84 24.06.13 12:00 Сейчас в теме

как раз такая ситуация пришла. База была брошена, франчи установили, уехали и никому до неё не было дела - никакого бэкапа - так иногда только DT-шники выгружали и то когда вспомнят. НО после проведения реиндексации реструктуризации лог вырос до 300 ГБ при базе в 45 ГБ. и почти кончилось место на диске.

причем реально база 19,5 ГБ в локальной файловой копии.(45 ГБ стала после загрузки в существующую DT-архива - может подскажете как правильно вернуть назад???).

Сделал все как в статье (не стал БЭКАП делать ибо некуда. ограничился выгрузкой в ДТ-архив.) при неработающих пользователях. размер указал 30 ГБ. Шринк прошел очень быстро. Щас настраиваю планы обслуживания (пока на тестовой базе) и ставлю вопрос о приобритении винта специально под бэкапы.

Но у меня такой вопрос
Вроде установил модель обратно в FULL, но даже сделав реиндексацию таблиц после этого размер журнала не изменился. и мало того уже рабочий день заканчивается - куча проведеных документов была, но размер какой был такой остался и дата изменения не изменяется (последние изменения базы - 0:22 - ночью в базе никто не работает кроме меня:) а лога аж 22 числа, т.е. 2 дня назад) - у меня установлено автоувеличение лога на 200 Мб, а базы на 500 МБ, может быть дата изменения меняется только во время увеличения размера.
Хотя после реиндексации размер лога должен был увеличиться на 25 ГБ (так было до шринка) - может кто нибудь разъяснить почему лог на месте стоит? - планы бэкапов еще не подключал т.е никакого архивирования нет.

26. ZLENKO 398 16.10.13 11:13 Сейчас в теме

Есть не самый простой и быстрый, но очень надежный рецепт усечения "пустого" (т.е. данных там нет но файл не уменьшается) файла ldf. Применяю когда ничто другое не помогает. Правда если изначально (при создании базы) файл был создан определенного размера, то этот способ тоже не поможет.

Рецепт простой:
//начинаем транзакцию
BEGIN TRAN
GO
//делаем апдейт какого нибудь поля какой нибудь большой таблицы
UPDATE ....
GO
//отменяем транзакцию
ROLLBACK
GO

После этого файл можно усечь на размер заполненных данных в файле ldf.
Рецепт используем столько раз, сколько потребуется.

27. 1cprogr_nsk 110 17.10.13 05:55 Сейчас в теме

Зачем используете ПОЛНУЮ модель, если шринкуете транзакционный лог? НУ да ладно это другая тема, а по этой можно просто выполнить запрос (Для примера имя БД "Base"):

BACKUP LOG Base TO DISK = '<D:\Backup\Base_Log.trn'
DBCC SHRINKFILE (Base_Log, 20) WITH NO_INFOMSGS

Затем файл с логом можно удалить, либо перенести на другой диск/сервер

28. pogonii 02.12.13 15:45 Сейчас в теме

Спасибо автору реально помогло. Такой вопрос а где можно почитать по поводу настройки SQL сервера поделитесь ссылками )))

29. FKLDOZ 8 04.12.13 09:55 Сейчас в теме

Вчера столкнулись с проблемой большого лога. Спасибо автору, статья полезная. Мне не понятно одно, 1С Сервер может вопрос логов как-то регулировать?

30. AlexO 135 17.06.14 16:58 Сейчас в теме

(29) FKLDOZ,

1С Сервер может вопрос логов как-то регулировать?

1С вообще практически ничего не может на SQL. SQL-сервер - он сам по себе, и сам управляет своими логами.

33. qwed557 30 07.01.15 21:16 Сейчас в теме

Из всего сказанного и из комментариев я что то не совсем понял. Если мы используем полную модель восстановления, сделали полный бэкап, обрезали лог базы, и если вдруг понадобиться восстановиться из бэкапа, то ничего не получиться?

34. DoctorRoza 07.01.15 21:46 Сейчас в теме

(33) qwed557, поддерживаю!

36. AlexO 135 12.01.15 11:47 Сейчас в теме

(33) qwed557,

и если вдруг понадобиться восстановиться из бэкапа, то ничего не получиться?

все получится - восстановится на момент бекапа полностью.
Полная же модель подразумевает - восстановление на любой момент времени, что невозможно, если данные транзакций уничтожены (лог транзакций стерт). Поэтому его в таком случае не трут, а также бэкапят вместе с базой. Но это именно для тех, кто понимает, что ему нужно. Для остальных - SIMPLE режим :)

37. ZloyGenii 09.11.17 17:21 Сейчас в теме

(33)

При полной модели восстановления бэкапы делаются так часто как это возможно для того чтобы процесс восстановления начинать не с испокон веков существования базы а с последнего полного созданного бэкапа + далее накатывают после этого бэкапы логов транзакций. это очень удобно хотя на практике приходилось пользоваться всего пару раз в жизни. У нас например это раз в неделю по четвергам (самое оптимальное время исходя из всех регламентов скуля + сервера 1С).
При простой модели вы сможете восстановить базу только на момент последнего созданного бэкапа.

Если у вас есть нормальное ПО по управлению бэкапами и логами ТЗ (хотя все это можно написать и на SQL) то делается просто.
Полная модель. Создается бэкап базы, хранится, далее бэкапятся логи раз в нужное вам время у нас это 15 минут, логи тоже хранятся, но каждый раз когда проходит полный бэкап базы НОРМАЛЬНО все старые бэкапы базы и логов трутся и начинается новый отсчет времени. Ну и так же настроено месячное хранение базы полугодичное и годовалое которые хранятся отдельно и трутся соответственно когда создаются подобные бэкапы.

При полной модели и наших настройках мы можем восстановить базу максимум с недельной давностью, далее все остальное накатить логами.
Так же мы можем восстановить базу на начало месяца, начало полугодия и начало года но уже без логов транзакций.

Насчет тормозов не могу согласиться с предыдущими ораторами о том что простая модель работает быстрее, они работают одинаково если нормально настрое сервер SQL, просто лог транзакций должен по умолчанию лежать на другом зеркале, отдельно от того зеркала где располагается база. Много раз проверяли что так что так работает одинаково. Если же логи транзакций лежат на том же массиве что и база - безусловно будет работать медленнее.

35. пользователь 07.01.15 22:02

Сообщение было скрыто модератором.

...

38. Perzold 20.01.18 13:04 Сейчас в теме

Статья очень помогла, и комментарии. Спасибо!

40. evpco 10.06.19 17:46 Сейчас в теме

Спасибо! Очень помогло!!! Очень подробно и доходчиво, так. что имея 0 знаний по SQL базам - очистил место за счет логов старых баз. Благодаря комментариям понял зачем все это надо!!! И если б не "А вот насчет настройки - это отдельная тема" разобрал бы это г.... - при базе менее 3 ГБ размер лога уже превышает 700 ГБ!!!
Т.е. если сделать выгрузку через конфигуратор и грохнуть эти 700 Гб, то можно спать спокойно? Или сделать полный бэкапп нужно средствами SQL?

41. kuzyara 2093 27.12.19 12:08 Сейчас в теме

Вопрос №17
Что надо сделать для успешного сжатия журнала транзакций? Используется SQL Server, модель восстановления FULL.
1 Резервную копию журнала транзакций.
2 Полную резервную копию.
3 Разностную резервную копию.
4 Верны ответы 1 и 2.
5 Верны ответы 1, 2 и 3.
Правильный ответ: 1

42. sergio111 21.10.20 10:28 Сейчас в теме

есть еще дополнение. если не сделался бакап, журнал резко начинает расти. если его попытаться уменьшить указанным способом, то возникает ошибка, что не завершен бакап. нужно остановить задание бакап.

43. webester 26 03.12.20 09:14 Сейчас в теме

(42)Что может быть тупее сидеть на полной и резать логи? Сёма вы или трусы оденьте или крестик снимите. Или тебе не нужен лог журнала и ты сидишь на простой модели. Или лог тебе нужен и ты его архивируешь раз в 1\2\3\5\10\ПодставитьНужно минут предотвращая лог и обслуживая арихвы логов(например убирая их в облако или удаляя раз в три дня или сколько там нужно). Но юзать полную модель и не юзать архивы логов.

44. sergio111 09.12.20 11:39 Сейчас в теме

(43) у вас наверняка мало опыта по работе с большими базами. более 500 гБ.

45. zzz_natali 61 09.12.20 11:58 Сейчас в теме

(44)Практика показывает, что обрезать базу выгоднее, чем каждый день перемешивать винегрет в 50тилитровой кастрюле

59. Pawlick 10 16.06.24 11:37 Сейчас в теме

(44) Я бы сказал, что у человека совсем такого опыта нет, и судя по тому, что с 2013 по 2021 мнение не поменялось - так и не появилось. А чисто житейской логики видимо и не было ;)

54. user1719153 21.06.22 18:29 Сейчас в теме

всем привет. Случайно при сжатии - выбрал на Журнал (лог) - а Data. Что я натворил этим ? что-то попортил или все норм? Спасибо за ответы

55. user1549679 09.09.22 12:02 Сейчас в теме

(54) Ничего страшного не случится. MSSQL сам проверит и если что-то будет не так, то просто покажет ошибку.

56. Raskad 10 22.03.23 09:05 Сейчас в теме

Добрый день.
А как понять, до скольки сжимать файл журнала? Если сама база, допустим, весит 100 Гб, а файл журнала 500 Гб?

57. botru 23.05.23 11:37 Сейчас в теме

Какие негативные последствия могут быть после сжатия файла данных (mdf)?
Стоит ли это делать и когда лучше?

58. botru 23.05.23 11:41 Сейчас в теме

Какие негативные последствия могут быть после сжатия файла данных (mdf)?
Стоит ли это делать и когда лучше?

Оставьте свое сообщение

E-mail:

Автор:

Сергей 1С (Kserken)

Рейтинг: 487

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 168314

Создание 15.01.13 17:04

Обновление 11.10.13 02:45

Статистика:

Просмотры 405015

Загрузки 0

Рейтинг 160

Комментарии 58

Характеристики:

Код открыт Не указано

Рубрики Чистка данных

Кому Системный администратор

Тип файла Нет файла

Платформа Платформа 1С v8.3

Конфигурация Не имеет значения

Операционная система Windows

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)