Не запускается очистка логов в Change log for Creatio от samarasoft. Можно ли её чистить через запрос в БД?

Добрый вечер!

Давным давно был установлен Change log for Creatio от samarasoft и настроен сбор данных по изменениям контактов, звонков, обращений и чатов.

В течение 4 лет данный модуль собирал данные и не чистился: логи копились годами, а далее систему отдали мне в управление.

Поняв, что это не нормально, в настройках журналирования Change log for Creatio я выбрал очистку логов, указал для теста дату очистки и нажал start.

Через 30 секунд я получил подтверждение запроса с уже подозрительным количеством underfined 🤔

Нажав да, процесс не начался, а логов осталось ровно столько же сколько было.

 

В системе ~239 млн записей логов и полагаю, что модуль просто зависает в попытке выполнить очистку.

Вопрос: можно ли используя SQL TRUNCATE SmrLoggingRecord просто очистить эти логи не поломая систему и не уничтожив работу модуля?

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

Нравится

3 комментария
Лучший ответ

SQL запрос по TRUNCATE SmrLoggingRecord полностью решил проблему. Записи очистились за 3 секунды, после чего модуль вернулся в строй. Очистка теперь работает пользовательскими инструментами. Вопрос закрыт.

Добрый вечер.

 

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

 

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

Приложение у нас развернуто onsite, Standalone-приложение.

Пачками удалить 239 млн не выйдет, так как запрос delete top просто положит БД.

"Попробовать сделать и посмотреть, что получится" — это не совсем тот ответ, что я ожидал получить.

 

Возможно ли связаться как-то с samarasoft, чтоб они могли указать на возможные взаимосвязи, если мы через truncate очистим всю таблицу разом?

SQL запрос по TRUNCATE SmrLoggingRecord полностью решил проблему. Записи очистились за 3 секунды, после чего модуль вернулся в строй. Очистка теперь работает пользовательскими инструментами. Вопрос закрыт.

Показать все комментарии