Ошибка AZURE SQL MI: очистка устаревшей / прерванной версии была прервана для базы данных с идентификатором '10' из-за выключения базы данных

Я пытаюсь восстановить файл .bak SQL-сервера в базу данных управляемого экземпляра SQL Azure через SSMS, но получаю сообщение об ошибке.

Сообщение 22003, уровень 16, состояние 1, строка 18 Очистка устаревшей / прерванной версии была прервана для базы данных с идентификатором «10» из-за выключения базы данных. Msg 3013, уровень 16, состояние 1, строка 18 RESTORE DATABASE завершается ненормально.

Я использую команду

CREATE CREDENTIAL [https://STORAGEACCOUNT.blob.core.windows.net/backups] 
WITH IDENTITY = 'SHARED ACCESS SIGNATURE' , 
SECRET = '<<by using original key>>' 

RESTORE DATABASE [TestDataBase] FROM URL = 'https://STORAGEACCOUNT.blob.core.windows.net/backups/TestDataBase.bak'

Я также пробовал использовать мастер восстановления SSMS, но безуспешно.

Кто-нибудь сталкивается с этой проблемой, или любая помощь будет большим подспорьем ...


sql-server azure-sql-managed-instance azure-sql-server
person Hemant Sudehely    schedule 05.06.2020    source источник

Ответы (1)


arrow_upward
0
arrow_downward

Мы проверили внутренние ресурсы на предмет похожих проблем, с которыми сталкиваются пользователи, и обнаружили следующее:

Восстановление базы данных не удалось, возможно, из-за ошибки DBCC CHECKDB, запускаемой как часть рабочего процесса, из-за ошибок очистки хранилища версий. В рамках DBCC CHECKDB мы запускаем очистку хранилища версий, и из-за некоторого дефекта очистка хранилища версий не удалась. Это проявляется, когда DBCC CHECKDB выполняется в однопользовательском режиме. Мы устранили дефект, и исправление будет развернуто в ближайшее время (в этом месяце - июнь 2020 г.). Приносим извинения за неудобства, вызванные этой проблемой.

Обходной путь. Ниже приведены два варианта самостоятельного устранения проблемы до развертывания исправления.

1) Делайте резервные копии с помощью КОНТРОЛЬНОЙ СУММЫ. Таким образом, мы не будем выполнять DBCC CHECKDB во время миграции, поскольку у нас есть некоторая уверенность в том, что база данных физически непротиворечива. Создание резервных копий с помощью CHECKSUM обычно является хорошей практикой для обеспечения целостности базы данных.

2) Повторите попытку. Текущее понимание проблемы заключается в том, что она временная и не относится к какой-либо резервной копии. Приблизительно в 9% случаев восстановление не удается, поэтому благодарим вас за терпение. Исправление развертывается при следующем развертывании.

Вы также можете обратиться к приведенному ниже документу для справки.

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-get-started-restore

Надеюсь это поможет.

Спасибо Navtej S

person NavtejSaini-MSFT    schedule 05.06.2020