Вопросы Теги

Сбои резервного копирования журнала транзакций SQL-сервера

У меня есть Стандартная версия SQL-сервера 2008 года. Зеркальное отражение настраивается на сервере в полном режиме безопасности. Его хорошо работать до сегодня. Резервное копирование журнала транзакций перестало работать каждый раз с ошибкой

"Ошибка: 25.09.2014 8:34:33.17 Кодов: Источник 0xC002F210: Резервное копирование Журнала JuneDB Выполняет Описание Задачи SQL: Выполнение запроса "ЖУРНАЛ РЕЗЕРВНОГО КОПИРОВАНИЯ [JuneDB] К ДИСКУ = N'H:\BKs\Hou..." перестало работать со следующей ошибкой: "Читайте на отказавшем "E:\LDFs\JuneDB.ldf": 1 (Неправильная функция.) ЖУРНАЛ РЕЗЕРВНОГО КОПИРОВАНИЯ завершается неправильно".. Возможные причины отказа: проблемы с запросом, свойство "ResultSet" не набор правильно, параметры не набор правильно или соединение, не установленное правильно"

  • Я использую План технического обслуживания для взятия резервных копий.
  • Диск также содержит файлы журнала 5 других баз данных, и их резервные копии журнала прекрасны.
  • Эта проблема, запущенная после успешного завершения, восстанавливает индексный план технического обслуживания.
  • Полное резервное копирование не имеет никакой проблемы.

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

Вещи я попробовал

  • Работал DBCC CHECKDB([JuneDB]) С NO_INFOMSGS не возвратил сообщений об ошибках
  • Выполнил запрос для взятия резервного копирования транзакции вместо того, чтобы использовать План технического обслуживания. Это дало ту же ошибку

Обновление я просто заметил в 4:30, что мы выполнили план технического обслуживания для восстановления всех индексов. Смотря на журнал ошибок, я начал получать ошибки для Резервных копирований журнала транзакций после 4:30. Я не уверен, как восстанавливают индексы, мог возможно заставить резервные копирования журнала транзакций перестать работать, но они уверенный кажутся связанными

0
задан 25 September 2014 в 20:53
1 ответ

Спасибо всем за то, что ответили и помогли мне в этом. Оказывается, это повреждение файла журнала. Следующие шаги решили мою проблему

  • Остановить зеркальное отображение
  • Переключение базы данных на простую модель восстановления
  • Выполнение контрольной точки (которая должна очищать активный журнал, если ничто другое не требует, чтобы журнал оставался активным)
  • Возврат к модели полного восстановления
  • Восстановление цепочки резервных копий журнала путем выполнения полного резервного копирования
  • Начать зеркальное отображение

http://sqlmag.com/blog/transaction-log-corruption-and-backups

1
ответ дан 4 December 2019 в 17:10

Теги

Похожие вопросы