После уменьшения файла лога транзакций, 1с ругается в некоторых операциях?

Question

[brar]

MSSQL 2017.
Размер файла БД - 50 ГБ.
Размер фйла логов - 54 ГБ.

В MS SQL Server Management Studio в параметрах базы поменял Модель восстановления с Full на Simple. Потом Задачи ->Сжать->Файл, Тип файла - Журнал. Освободить неиспользуемое место (консоль показывает что может освободить 99%). Выполняю. Всё удачно заканчивается. Лог транзакций уменьшился практически до нуля. Вернул БД в Full.
После чего в 1с при проведении документов вываливается ошибка:

Ошибка при выполнении обработчика - 'ОбработкаПроведения'
по причине:
{ОбщийМодуль.УправлениеЗапасамиПартионныйУчет.Модуль(9739)}: Ошибка при вызове метода контекста (Выполнить)

по причине:
Ошибка выполнения запроса
по причине:
Конфликт блокировок при выполнении транзакции:
Microsoft SQL Server Native Client 11.0: Транзакция (идентификатор процесса 51) вызвала взаимоблокировку ресурсов блокировка с другим процессом и стала жертвой взаимоблокировки. Запустите транзакцию повторно.
HRESULT=80004005, SQLSrvr: SQLSTATE=40001, state=33, Severity=D, native=1205, line=1

Пришлось вернуть виртуалку в прежнее состояние.
Без перевода базы в Simple, сжатие журнала уменьшает лог-файл всего- навсего на 1 ГБ.
Полный бэкап БД и журнала, также, не приводит к уменьшению лог-файла.
Как грамотно и безопасно уменьшить лог файл хотябы в два раза?

Comments

[hint000]

IMHO нет прямой связи между сжатием журнала и ошибкой 1С.
Попробуйте проделать то же самое ещё раз, только перед этим остановите службу 1С, а после сжатия снова запустите службу.
(хотя множество раз проделывал сжатие и журнала, и самой БД на живой 1С и без проблем. Разница в том, что я на постоянку делаю модель Simple, но и это переключение туда-сюда не должно быть критично. Похоже, вы поймали какой-то случайный глюк, и не факт, что он будет повторяться, если проделаете всё то же самое.)

P.S. Ну и в любой непонятной ситуации с 1С надо почистить кэш 1С в профиле пользователя ;)

[Дмитрий Кинаш]

MHO нет прямой связи между сжатием журнала и ошибкой 1С.

hint000, только в данном случае 1С просто ретранслирует из СУБД ошибку взаимоблокировок.

Я бы в такой ситуации попробовал бы выгрузить *.dt и загрузить в новую базу. 50 ГБ - это примерно 4-5 часов. Если нужно восстанавливать работоспособность текущей, то с помощью ТИИ реструктуризировал бы таблицы и пересчитал итоги.

Answer 1

[unfilled]

Обрежьте журнал транзакций гигабайт до 5, установите приращение в 1 ГБ и не возвращайте БД в Full - вы всё равно не пользуетесь преимуществами полной модели восстановления. Оставьте в простой.
Deadlock'и у вас появляются из-за кривого кода 1С (ищите их документацию по причинам возникновения и избавлению от взаимоблокировок - её полно). Почему не возникали раньше? Возможно, потому что после "обрезки" ЖТ и переводе в полную модель восстановления, ЖТ снова начал расти и одна из кривых операций ждала завершения приращения, когда вторая кривая операция начала выполняться. Но это мой хрустальный шар только предполагает, вам и вашим одинэсникам виднее должно быть.

Answer 2

[АртемЪ]

Если 1с ругается в некоторых операциях, первое что делают это чистят кэш.