Операционная система вернула SQL Server ошибку 21 (устройство не готово) во время чтения по смещению 0x0000000001c000 в файле 'E: \ SQL Database \ S ***** d \ NewAdvWorks.mdf'. Дополнительные сообщения в журнале ошибок SQL Server и журнале системных событий могут содержать более подробную информацию. Это серьезная ошибка системного уровня, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку целостности базы данных (DBCC CHECKDB). Эта ошибка может быть вызвана многими факторами; Дополнительные сведения см. в электронной документации по SQL Server.
Что сработало для меня:
alter database [database_name] set offline
... подождите несколько секунд ...
alter database [database_name] set online
Это лучше, чем перезапуск SQL Server, поскольку перезапуск SQL Server переводит все базы данных в автономный режим (а не только базу данных, которая недоступна).
Сегодня я столкнулся с такой же ошибкой. Это исправило перезапуск службы SQL Server.
Журнал ошибок SQL Server и журнал событий Windows показали одну и ту же ошибку:
Операционная система вернула SQL Server ошибку 21 (устройство не готово) во время чтения по смещению 0x00000000026000 в файле blah.mdf. Дополнительные сообщения в журнале ошибок SQL Server и журнале системных событий могут содержать более подробную информацию. Это серьезная ошибка системного уровня, которая угрожает целостности базы данных и должна быть немедленно исправлена. Выполните полную проверку целостности базы данных (DBCC CHECKDB). Эта ошибка может быть вызвана многими факторами; Дополнительные сведения см. в электронной документации по SQL Server.
И:
Ошибка: 823, уровень серьезности: 24, состояние: 2
Прочитав ответ Роберта ван ден Берга, я бы попробовал перевести базу данных в автономный режим, а затем сначала в онлайн, если у вас есть другие базы данных, которые вам нужно сохранить в сети.
Сначала прочтите журналы, указанные в сообщении об ошибке.
Затем попробуйте перезагрузить сервер, затем запустите DBCC CheckDB очередной раз.
В моем случае я смог использовать
exec sp_detach_db [dbName];
с последующим
exec sp_attach_db [dbName] , @filename1 = N'U:\mdf\dbName.mdf' , @filename2 = N'G:\ldf\dbName_log.ldf';
для 30 баз данных в SQL 2017. Несмотря на то, что процесс «отсоединения» вызывал ошибку, SQL все же отсоединил базу данных.
я использовал select db_name(database_id), * from sys.master_files до того, как я начал отсоединяться, поэтому я мог написать сценарий процесса присоединения, учитывая, что в этом состоянии у меня было 30 баз данных.
Я нашел катализатор в своем случае. Накануне вечером я «расширил» два тома. Управление дисками сообщило, что в то время не могло расширить том. Я решил подождать окна обслуживания, чтобы повторить попытку, и ошибок еще не было.
Через пять часов началось резервное копирование с использованием VSS. Я убежден, что сочетание неудачного «расширения тома» и моментального снимка VSS привело тома в необычное состояние.