Назад | Перейти на главную страницу

Ошибка SQL Server 2005, связанная с агентом SQL и восстановлением базы данных

Я восстанавливал базы данных sql 2005 с одного сервера на другой (аналогичная спецификация, та же версия, пакет обновления и т. Д.) И столкнулся со следующим.

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

Выполнение не удалось. См. Подробности в плане обслуживания и журналах журнала заданий агента SQL Server. Дополнительная информация -> Job'Full_Backup.Subplan_1'failed. (SQL ManagerUI) Дополнительная информация дает мне следующее расположение программы: Microsoft.SqlServer.Management.SqlManagerUI.MainastedPlanMenu_Run.PerformActions ()

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

Я воспроизвел эту проблему на 2 «свежих» серверах с новыми установками SQl server 2005. По моему мнению, виновником является операция восстановления, поэтому, если был какой-то способ отследить, что происходит, возможно, с одной из системных баз данных, которую я затем можно было провести расследование.

Это раздражало уже несколько недель, и мы будем благодарны за любую помощь.

Кажется, я наткнулся на ответ. Похоже, что исходный сервер SQL был обновлен с 7 до 2000 до 2005! сумасшедший, но, видимо, использовался 8 лет задолго до меня.

Проблема, похоже, связана с совместимостью базы данных, см. Следующую статью msoft

текст ссылки

«Базы данных, для которых установлен уровень совместимости 70 или ниже, не отображаются»

Я проверил это, изменив уровень на 90, и теперь, конечно же, он работает.

Спасибо всем, кто ответил, этот сайт будет очень полезным.

Поскольку эти базы данных перемещаются с одного сервера на другой, возможно, вы могли бы проверить таблицу sysdatabases в Master, чтобы увидеть, есть ли несоответствия. Если dbid не синхронизированы, возможно, в старых планах обслуживания возникли проблемы с просмотром восстановленных баз данных.

Одна из проблем может заключаться в том, что пользователи, которые существуют в этих базах данных, могут не иметь того же SID, что и на другом сервере. Маби, что план обслуживания выполняется с использованием учетных данных осиротевшего пользователя. В MS SQL есть хранимая процедура, которая исправляет этих пользователей-сирот: sp_change_users_login

Просто перейдите из SQL Management Studio в базу данных на новом сервере, перейдите в раздел «Безопасность» и посмотрите, какие логины у вас есть в этой базе данных. Затем выполните команду восстановления, как показано ниже, для каждого пользователя.

использовать базу данных

идти

sp_change_users_login 'auto_fix', 'имя пользователя'

идти

- Где «база данных» - это имя вашей восстановленной базы данных.

Вы можете обнаружить, что это так же просто, как обновить обозреватель объектов после восстановления базы данных. SSMS кэширует много информации, поэтому ему не нужно снова и снова возвращаться к серверу за одними и теми же данными, не говоря уже об улучшении производительности за счет того, что данные уже находятся в кеше. Создание плана обслуживания - это, вероятно, одно из мест, где читается кешированная информация.