数据库销毁(数据库销毁后的一般修复方法)
常见故障解释
83个故障
缺陷信息为:“在文件' ' % 1！' '(偏移量为%#016I64x)中的状态% 2！的实现过程中，操作系统已将缺陷% 3！返回给了SQL Server。”
"操作系统在文件' ' % 1！' '中的% 2！' '偏移量%#016I64x期间向SQL Server返回了错误% 3！。"
例如:
消息823，24层，3号州，1号线
操作系统返回错误5(访问被拒绝。)写入到文件“文件路径文件名”中偏移量0x0000000000e000处的SQLServer。
823故障是指SQL Server在应用到操作系统时，无法从Windows中读取或写入页面，Windows返回的故障代码和相应的文本将被插入到信息中。对于读取操作，在报告823错误之前，SQL Server已重试读取请求4次。
从故障发生的机制可以看出，823故障是在发出页面读写请求时产生的，与读写的内容无关，所以823故障与SQL Server本身无关。这个问题通常是物理文件被破坏引起的，但也可能是设备驱动程序引起的。如果数据文件上反复出现823故障，要么是硬件有问题，要么是数据文件严重损坏。这个缺陷基本上意味着数据页中的有效数据已经丢失，DBCC CHECKDB一般很难修复。
84个故障
故障信息为:“基于一致性，SQL Server检测到逻辑输入/输出故障% 1！文件' ' % 1！' '中偏移量为%#016I64x的位置在技术资源网络的数据库标识% 2！中的页% 3！的% 4！中出现此问题。
" SQL Server检测到一个基于逻辑一致性的输入/输出错误:% 1！它发生在文件' ' % 1！' '中偏移量%#016I64x处的数据库标识% 2！的第% 3！页的% 4！中
例如:
SQL Server检测到基于逻辑一致性的输入/输出错误:tornpage(预期签名:0x0实际签名:0x4e0372a8)。在文件“S: Microsoft SQL Server MSSQL . 1 MSSQL Data www 71 _ global _ Data . MDF”中偏移量00000000000处读取数据库ID 13中的页(1:0)时出现此错误。
此错误表示Windows报告页面已成功从磁盘读取，但SQL Server在页面中检测到逻辑错误。
常见的问题类型如下:
1、校验和
SQL Server在编写每一页时，可以根据页面强度数据计算一个校验值，并一起存储在页面中。下次读取页面时，根据读取的页面数据计算新的校验值。如果写入和读出的数据相同，则两个校验值必须相等。如果两个校验值不相等，说明上次写入SQL Server的数据和这次读出的内容肯定不一样，现在读出的数据有问题。这样，SQL Server就可以销毁数据页。
2、撕页
撕页封面实际上是一种检测电源故障导致页面损坏的方法。例如，意外的电源故障可能仅导致页面的一部分写入磁盘。当应用不完整的页面封面时，将在页面的每个512字节扇区的末尾放置一个2位签名(在原始的2位被复制到页面标题之后)。每次写入时，此签名在二进制数字01和10之间交替出现，这样您就可以始终确定是否只有一些扇区被写入磁盘。如果以后阅读页面时发现某个位置的状态不准确，说明页面没有被准确写入，那么检测到问题的页面称为断页。与Checksum相比，不完全页检测的应用程序资源最少，但其算法过于简单，无法检测所有由磁盘硬件故障引起的问题。
3、短转移
读取数据的长度小于预期。例如，一个读取请求预期读取8KB的数据，但实际上只返回4KB。这也意味着当前读取的页面已损坏。
4、错误的页面标识
读取页面后，SQL Server会将存储在页面开头的页码与所需的目标页码进行比较。如果你发现你要读的页面是第200页，而你读的内容显示是第100页，那么SQL Server就会触发824麻烦。这种缺陷往往会传递给SQL Server，因为I/O系统并不能准确处理SQL Server的需求，甚至是一个空页面。
5、恢复待定
在企业版的SQL Server中，用户可以在恢复时请求跳过一些损坏的页面(出错后继续)。这些跳过的页面被标识为“恢复挂起”。如果有用户想访问，会遇到824问题。
6、陈旧阅读
一些硬件系统经常会产生漏写的现象(SQL Server请求在硬盘文件中写入一页，I/O子系统报告写入已经完成，但下次SQL Server读取时，仍会先读取内容再写入)。因为我读的旧版本的页面没有问题，所以校验和和撕页算法都不能检查问题。SQL Server也有针对这类问题的对策。打开SQL Server启动参数开关-T818后，SQL Server将保护内存中的哈希表，该哈希表记录所有已写入页面的最新LSN(日志序列号)值。下次读出页面时，我们将比较这两个值是否相等。因为LSN是一个积极增加的独特价值，LSN的价值将大于产生新版本的每一页的原始价值。如果读取的LSN与内存中注册的LSN不一致，则意味着最后一次写入请求没有真正完成。这时，824故障也会触发。
84虽然是“逻辑故障”和SQL Server自动发明的数据销毁，但销毁的起源大多不是SQL Server本身。这里的问题是预期的写作没有完全完成。84故障原因根本在I/O子系统。由于SQL Server的读写需求都是发送到Windows，再由Windows发送到底层磁盘系统，所以Windows下面的每一层都可能出现问题，比如磁盘驱动器故障、磁盘估计问题、设备驱动不准确等等。可以说，SQL Server本身不会造成824问题。
因为824错误是页面级别的逻辑错误，所以DBCC CHECKDB在很多情况下都可以修复。这种修复只是逻辑上的。存储在页面中的数据在824错误发生之前就丢失了，SQL Server无法修复回来，所以824错误只是意味着部分数据丢失。
65个故障
问题消息是:“从数据库%d提取逻辑页%S_PGID的尝试失败。逻辑页属于分配单元%I64d，而不是%I64d。
"尝试提取数据库%d中的逻辑页%S_PGIDin失败。它属于分配单元%I64d，而不是%I64d。
例如:
尝试提取数据库2中的逻辑页(1:584)失败。它属于分配单元445237904015360，而不是72057594060079104。
05也是一个非常著名的数据库损坏问题。此问题通常表明指定数据库中的页面或分配已损坏。当按页链读取属于表的页或应用索引分配映射(IAM)时，SQL Server将检测到此损坏。分配给表的所有页面必须属于与该表关联的分配单元之一。如果标题中包含的分配单元标识与表关联的分配单元标识不匹配，将引发此异常。故障信息中列出的第一个分配单元标识是表头显示的标识，第二个分配单元值是与表关联的标识。
严重级别21表示可能存在数据损坏。原因包括页面链断开、IAM断开或该对象的sys.objects目录视图中的条目无效。这些问题通常是由硬件或磁盘设备驱动程序的故障引起的。
严重性级别12表示可能存在临时问题，即缓存中出现问题，但并不表示磁盘上的数据已损坏。临时605问题可能由以下情况引起:
系统通知SQL Server输入/输出操作已提前完成；虽然没有实际的数据丢失
糟糕，但真实的问题信息。
使用优化器提醒NOLOCK运行查询，或将事务隔离级别设置为READ。
未提交.当应用NOLOCK或READ UNCOMMITTED的查询试图读取时
当数据被其他用户移动或更改时，会出现605故障。如果验证是临时的
05，您可以稍后重新运行查询。
通常，如果故障发生在数据访问期间，但是后续的DBCC CHECKDB操作没有错误地完成，那么605故障可能是暂时的。
因为605 bug意味着有些页面出了问题，也是非常严重的数据库损坏。一般用DBCC CHECKDB很难修复。
其他问题
在SQL Server内部，除了文件页面分配和每个页面的内部模式之外，还有其他绑定规则。以下是技术资源网络问题的一些常见示例。
PFS页面已损坏:
消息8946，级别16，状态12，第1行表错误:分配页(1:13280496)有
Invalidpfs _ pageheade技术资源网络rvalues.typeis0 .检查类型、所有单元id和页面
页面上的标识。
系统表的集合索引页损坏:
服务器:消息8966，16级，状态1，第1行无法读取和查看页面(1:18645)
带SH型闩锁。sysindexes失败。
消息7985，16级，状态2，服务器SUNART，第1行系统表预检查:对象
ID 4。无法读取和锁定带锁定类型SH的页面(1:51)。check语句
由于不可修复的错误而终止。
字段的值不符合字段数据类型的定义:
Msg 2570，第16层，状态3，第1页(1:152)，objectID 2073058421中的插槽0，
索引标识0，分区标识72057594038321152，分配单元标识72057594042318848(类型
“行内数据”)。列“c1”值超出了数据类型“datetime”的范围。更新
列转换为合法值。