Answers:
每次重新启动Windows时,对于某些数据库都会出现此错误。(操作系统错误21-设备未就绪)
这是由于磁盘在SQL Server启动时处于脱机状态或未处于联机状态,或者是在SQL Server处于联机状态之后已转换状态。
3.如果我重新启动SQL Server,错误消失
是的,因为数据库已在SQL Server中重新安装。您也可以离线->在线数据库,并且假设磁盘设备已修复,它将可以正常工作。
通过在数据库中放置数据库,禁用磁盘,运行选择查询(以获取错误),使磁盘恢复联机并注意到选择仍然失败并出现相同错误,可以轻松地在测试环境中重现此错误。需要重新安装数据库才能重新工作,并且不会出现OS错误21。
你该怎么办?
让某人进行一些Windows跟踪以弄清楚为什么它最初不联机或为什么脱机(任何状态转换)或为什么它已向Windows显示就绪但实际上却没有(可能需要加载其他驱动程序)它)。
另外,请检查所有磁盘筛选器驱动程序是否最新,例如防病毒,主机入侵保护等,因为它们也可能阻止服务/启动/状态。
我想我找到了原因。
该问题最有可能是由于“快速启动”电源选项引起的。
这是减少启动时间的Windows技术。快速启动结合了冷关机和休眠功能的要素。
在这里您可以找到有关优缺点的另一篇文章
我已禁用它,问题似乎已解决。
这些是我的观察以及我如何解决该问题(为了使可能有相同问题的其他人受益)
通过MSSMS连接到本地默认MS SQL实例(2017)时遇到的完整错误是:
读取文件'D:\ MSSQL \ DATA \ tempdev.mdf'中的偏移量0x000000000ae000时,操作系统向SQL Server返回错误21(设备未就绪。)。SQL Server错误日志和操作系统错误日志中的其他消息可能会提供更多详细信息。这是严重的系统级错误情况,威胁数据库的完整性,必须立即更正。完成完整的数据库一致性检查(DBCC CHECKDB)。此错误可能是由多种因素引起的;有关更多信息,请参见SQL Server联机丛书。(Microsoft SQL Server,错误:823)寻求帮助,请单击:http : //go.microsoft.com/fwlink? ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=823& LinkId=20476
将tempdb移到新的D驱动器后,我就开始获取此文件。进行SQL服务的启动/停止可消除该错误。当所有内容都在C上时,从未出现此错误。我的两个驱动器都是SSD并使用Bitlocker加密,不确定是否可能是问题所在,也许C驱动器很早就被解锁,因为操作系统需要它,而D驱动器后来又被解锁了。
我多次遇到相同的问题,并认为我应该分享我的解决方案(尽管已经提供了答案):
所以我有两个SQL实例(SQL 2008和SQL 2017)。该错误未在我的SQL08实例中显示,但在SQl17上显示。这是由每个SQL实例的安装/设置过程中提供的“帐户凭据”引起的:
这可以在Windows服务下看到。在安装过程中,将SQL08设置为使用“本地系统帐户”,而将失败的SQL17设置为“ NETWORK ACCOUNT”。因此,只需对其进行更改,然后在此处重新启动SQL服务(或在SQL浏览器中重新启动实例)。
此问题的第二部分在使用SQL Server Management Studio V17时是SQL Server 2017 CTP 2.0所独有的,在这种情况下,SMO切换为使用“ sys.dm_os_enumerate_fixed_drives ”而不是旧的“ xp_fixeddrives ”来获取本地磁盘的可用空间信息。要解决此问题,请转到设备管理器并暂时禁用引用的驱动器(在我的情况下是驱动器“ G”,它只是我的DVD-ROM驱动器)。
这个问题也使我感到恼火。我有5个数据库挂接到我的SQL Server实例上,其中3个工作正常,但其中2个抱怨
读取文件'E:\ xxxxxxxx.mdf'中的偏移量0x00000000204000时,操作系统向SQL Server返回错误21(设备未就绪)。
这是我的解决方案。
附带说明一下,我确实尝试过使用db离线/在线方法。就我而言,它不起作用。蛮力重启sqlserver服务效果很好。对于那些使所有数据库脱机的风险太大的人来说,这可能是个问题。但是,如果您像我一样只是在进行本地开发,那么此解决方案应该没问题。