У меня есть база данных SQL Server, не относящаяся к Mission Critial DB с 9 утра до 5 вечера, которую я настроил для выполнения полного резервного копирования по ночам и резервного копирования журналов каждые 30 минут в рабочее время. База данных находится в процессе полного восстановления, и обычно у меня нет причин обрезать / сжимать журналы, если я не сделаю серьезное обслуживание. Резервные копии журналов управляют размером без проблем. Однако я не был у этого клиента несколько недель и после осмотра заметил, что размер журнала увеличился примерно в 10 раз по сравнению с размером файла .mdf. Я искал, были ли резервные копии запущены, и я не получал никаких предупреждений об ошибках серьезности (почта SQL). Я попытался поместить БД в простое восстановление и сжать журнал, это не помогло. Прежде чем попробовать резервную копию журнала, я получил:
Журнал не был усечен, поскольку записи в начале журнала ожидают репликации или отслеживания измененных данных. Убедитесь, что агент чтения журнала или задание записи запущены, или используйте процедуру sp_repldone, чтобы пометить транзакции как распределенные или захваченные.
Перезапустите ополаскивание SQL Server, повторите то же самое ...
Я сказал ??? Репликация ни разу не настраивалась на эту БД или базу / сервер ??? Таким образом, резервные копии журналов не очищали .ldf. Итак, я провел пару часов исследования и обнаружил:
кажется это какая-то плохо документированная ошибка ??
Похоже, решение заключалось в запуске exec sp_repldone, более точно
EXEC sp_repldone @xactid = NULL,
@xact_segno = NULL, @numtrans = 0,
@time= 0, @reset = 1
Эту процедуру можно использовать в чрезвычайных ситуациях, чтобы разрешить усечение журнала транзакций при наличии транзакций, ожидающих репликации. Использование этой процедуры предотвращает репликацию базы данных Microsoft SQL Server 2000 до тех пор, пока база данных не будет отменена и опубликована повторно. ~ MSDN
Когда я это сделаю, я получаю следующее
Msg 18757, уровень 16, состояние 1, процедура sp_repldone, строка 1 Невозможно выполнить процедуру. База данных не опубликована. Выполните процедуру в базе данных, опубликованной для репликации.
Это имеет смысл, потому что БД никогда не публиковалась для репликации.
У меня несколько вопросов:
A) Прежде всего, WTF происходит? Что вызывает это, мне интересно узнать, почему здесь? Является ли это ошибкой или есть какой-то аспект резервного копирования, который не работает должным образом, что заставляет БД имитировать реплицированное состояние? Кто-нибудь, пожалуйста, научите меня этому.
Б) Во-вторых ... Мне действительно нужно публиковать / реплицировать эту БД, чтобы запустить этот SP, чтобы исправить это ??? Звучит безумно, или есть какой-то T-SQL, который я могу поместить в опубликованное состояние, выполните процедуру и буду в пути ...
C) В-третьих, если мне действительно нужно опубликовать эту базу данных для выполнения SP, чтобы освободить этот ненужный неверно реплицированный / запланированный журнал, чтобы вернуть мой .ldf файл и резервную копию в нужное русло. Как опубликовать базу данных без запрашиваемого онлайн-хоста ??? Я обычно не занимаюсь таким администрированием баз данных и нуждаюсь в некотором руководстве.
Извините, если это слишком многословно, но просто озвучивание вопроса помогает мне прояснить его ...
Заранее спасибо за вашу помощь
У меня такая же проблема
я сделал SELECT name, log_reuse_wait_desc FROM sys.databases
и он сказал мне, что причиной не опорожнения журнала была РЕПЛИКАЦИЯ
Я попытался
sp_removedbreplication youdbname
и это исправило это
У нас точно была эта проблема. Репликация даже НЕ установлена (SQL 2008) в sys.databases, одна из наших баз данных была внезапно и без какой-либо причины, которую я могу найти, настроена как реплицируемая.
Нам приходилось делать ужасные вещи, чтобы восстановить базу данных, потому что файл журнала рос очень быстро и (конечно) обычные процессы очистки журнала не работали.
Это было немного раньше, чем я понял, что проблема в настройке репликации. К тому времени файл журнала был заполнен. Вызывает тревогу тот факт, что даже после того, как мы смогли восстановить базу данных, этот параметр репликации ВСЕ ЕЩЕ был установлен.
Вот что удалило этот параметр:
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @ time = 0, @reset = 1
Если CDC включен для базы данных, CDC и репликация используют одну и ту же технологию.
1 Запустите select DATABASEPROPERTY ('', 'ISPublished') - должен вернуть 0
3 DBCC loginfo - найдите столбец состояния со значениями 2
DBCC OPENTRAN - для проверки наличия длительных транзакций.
Даже все это не помогает, тогда нам, возможно, придется включить репликацию и e
Проверьте, включен ли в базе данных CDC (система отслеживания измененных данных) или другой тип сервера чтения журналов. Это часто может вызвать ту же проблему. У меня была производственная база данных с включенным CDC, которую я скопировал на сервер разработки и продолжал сталкиваться с этой проблемой. У меня также были производственные серверы с поддержкой CDC, у которых была эта ошибка, когда задание агента CDC недавно не запускалось. Задание агента CDC обычно выполняется непрерывно, но в случае сбоя оно останавливается и не запускается снова, если вы не изменили настройки.
Надеюсь это поможет.
У меня была такая же проблема, я нашел более простое решение:
(обратите внимание, это на SQL 2k8)