Наш сервис SQL Server не работал сегодня утром, что привело к отключению некоторых наших веб-сайтов. Когда я пошел, чтобы проверить Windows Event Viewer, я увидел следующие ошибки:
Не удалось обновить уровень сценария для базы данных «master», поскольку на этапе обновления «SSIS_hotfix_install.sql» обнаружена ошибка 942, состояние 4, серьезность 25
Невозможно восстановить основную базу данных. SQL Server не может работать. Восстановите мастер из полной резервной копии, восстановите или восстановите его. Дополнительные сведения о том, как перестроить основную базу данных, см. В электронной документации по SQL Server.
Первое, что я сделал, было Google погрешности. В конце концов я нашел запись на форуме с точной проблемой и ее решением (также в блоге, где я ищу решение ). Проблема связана с группами доступности AlwaysOn, и для исправления необходимо:
Запустите службу SQL Server с флагом трассировки 902:
Чистый старт MSSQL $ InstanceName / T902
Откройте SQL Server Management Studio, перейдите в группу доступности и удалите SSISDB из баз данных доступности.
Откройте New Query, выполните скрипт SSIS_hotfix_install.sql, который находится в папке Install в папке \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQL $ InstanceName \ MSSQL
Остановите службы SQL Server:
Net Stop MSSQL $ InstanceName
Запустите службу SQL-сервера из диспетчера конфигурации SQL Server
Добавить SSISDB обратно в группу доступности
Тем не менее, я не смог пройти шаг № 2, потому что я получил следующую ошибку при попытке развернуть папку «AlwaysOn High Availability»:
Функция «AlwaysOn» должна быть включена для экземпляра сервера «InstanceName», прежде чем вы сможете создать группу доступности на этом экземпляре.
Затем я следовал инструкциям, чтобы перейти к «Диспетчеру конфигурации SQL Server» и вкладке «AlwaysOn High Availability», чтобы включить эту функцию. На этот раз функция была недоступна, и появилось сообщение о том, что компьютерный узел не находится в отказоустойчивом кластере.
Мой вопрос:
Как я могу исправить эту проблему, если у нас даже нет установки отказоустойчивого кластера, которая бы использовала эту функцию?
Я побежал dbcc checkdb
на хозяина; результаты были:
CHECKDB обнаружил 0 ошибок размещения и 0 ошибок согласованности в базе данных «master».
Группа доступности AlwaysOn НЕ включена, потому что у меня даже нет отказоустойчивого кластера.
источник