MS SQL Server: Падение БД в состояние «suspect» с неожиданными последствиями

Ко мне (администратору СУБД) обратился администратор сервера, на котором развернут Symantec Endpoint Protection. он обнаружил, что после очередной перезагрузки операционки база sem5 упала в «suspect».
Поднять базу из суспекта несложно — казалось бы, exec sp_resetstatus sem5, и все, но чтение логов сервера дало понять, что запортились страницы с индексами и базу нужно лечить.
Итак, лечим:
ALTER DATABASE sem5 SET EMERGENCY;
DBCC CHECKDB (sem5, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS, ALL_ERRORMSGS;

Получилось? Вроде получилось… Поднимаем базу:
ALTER DATABASE sem5 SET ONLINE;

Все! Можно выдохнуть. Однако, по старой привычке, я продолжаю следить за полеченной базой. И, спустя какое-то время, обнаруживается, что у свежевылеченной базы журнал транзакций растет, растет, растет — несмотря на включенную опцию автошринк.
Пробуем порезать лог, предварительно сделав бэкапы:
BACKUP DATABASE sem5 to Disk='d:\backup\sem5.bak'
BACKUP LOG sem5 to Disk='d:\backup\sem5_log.bak'
DBCC SHRINKDATABASE (sem5, TRUNCATEONLY)

Не шринкает! Странно… Интересно, что же такое происходит с логом? И тут вспомнилось мне про поле log_reuse_wait_desc системнойго представления sys.databases:
SELECT * from sys.databases

результат превозошел самые смелые мои ожидания: REPLICATION.
Как? Откуда? Почему? На эти вопросы я ответа так и не нашел.
убираем репликацию:
sp_removedbreplication 'sem5'

И пытаемся порезать файл снова:
BACKUP DATABASE sem5 to Disk='d:\backup\sem5.bak'
BACKUP LOG sem5 to Disk='d:\backup\sem5_log.bak'
DBCC SHRINKDATABASE (sem5, TRUNCATEONLY)

Получилось!
P.S. У меня не было и мысли, что этот случай заслуживает внимания, если бы все это безобразие через две недели не повторилось снова. А если повторилось у меня — может повториться у кого угодно.
P.P.S. А вот почему после падения в suspect БД начинает считать, что журнал транзакций использован репликацией, я так до сих пор и не разобрался.