笔记18-徐 SQLSERVER常见错误解读
笔记18-徐 SQLSERVER常见错误解读
f
--SQLSERVER常见错误解读 --829错误：这个错误表明SQL Server在读取数据库文件时，发现了逻辑一致性错误，即数据页的页面ID不正确。 --表示数据库页的一致性检查失败，可能是由于硬件故障或磁盘上的物理损坏导致的。 --SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected xxx; actual xxx). It occurred during a read of page (xxx:xxx) in database ID xx at offset xxx in file 'xxx.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online. --823错误 --823错误是发出一个页面读写请求时发生的，和读写的内容没有关系 ---，所以823错误和SQL本身没有关系。通常是物理数据文件损坏或者 --硬件出现问题。 --修复方法：DBCC CHECKDB很难修复 --824错误 原因基本是I/O子系统的问题，可以负责任地说SQL自己绝少会导致824错误的 --此错误表明Windows已经从磁盘成功读取页，但SQLSERVER检测到页中存在逻辑错误 --常见逻辑错误： --1、checksum： --SQL在写入每个页面时，根据页面里的数据算出一个校验值，一同存储到页面里。当下次读取页面的时候， --在根据这次读到的页面数据，算出一个新的校验值。如果写入和读出的数据一模一样，那么两个校验值一 --定是相等的。而如果两个校验值不相等，意味着上次SQL写入的数据和这次读出的一定不同，现在读出来 --的数据有问题。通过校验值SQL能发现数据页面损坏，这个功能是SQL2005以后引入的 --2、torn page --SQL2000引入的残缺页（torn page）保护，是一种对电源故障导致的页损坏进行检测的方法。 --页的每个512B扇区末尾会放置一个2位签名（在这之前会把原来的2位复制到页头之后）每次 --进行写操作时，这个签名在二进制01和10之间交替。这样始终可以确定是否只有部分扇区写到 --磁盘。如果稍后读取页时发现某个位的状态不正确，则说明该页没有被正确写入。 --如果页面没有被正确写入，因此检测到问题页面，称为残缺页。相对于checksum，残缺页使用 --的资源最少，但是它的算法太简单，无法检测到磁盘硬件故障导致的所有错误 --不知道01 还是10 是指明那个扇区被正确写入 --3、short transfer --读到的数据长度比预期的少。例如，一个读取要求预期可以读到8KB的数据，可是实际只返回了 --4KB。这意味着当前读到的页面有损坏 --4、bad page id --在读到页面后，SQL会比较页面开头存储的页面编号和自己请求的目标编号。如果发现自己 --想要读取的页面是第200页，而读到的内容里显示它是第100页，SQL就会触发824错误。 --这种错误经常是因为I/O子系统没有正确处理SQL的请求，传给SQL一个错误的页面，甚至 --是一个空页面 --5、restore pending --在SQL2005以后的企业版里，用户可以要求在做还原的时候跳过一些有损坏的页面（continue after error） --延迟的错误。这些跳过的页面被标识成“restore pending”.如果用户想去访问它，也会遇到824错误 --6、stale read --由于硬件系统发生漏写的现象，checksum和torn page算法都不能检测到错误。 --可以打开SQL启动参数开关 /T818 以后，SQL会在内存维护一张哈希表，记录下自己所有做过的写入 --的动作的页面的LSN值。在下次读出页面的时候去比较这两个值是否相等。由于LSN是自动增长的唯一值， --每个发生新修改的页面，LSN的值会比原来的要大。所以如果读到的LSN的内存中存放的不一样，就 --说明上次写入的请求没有真正完成。触发824错误 --net start MSSQLSERVER /t818 --修复方法：DBCC CHECKDB能修复，但是只是逻辑修复，会有部分数据丢失 --605错误 --605也是一个非常有名的数据库损坏错误。此错误通常表示指定数据库中的页或分配已经损坏 --SQL会在根据页链接或使用索引分配映射IAM读取属于表的页时，检测到此损坏。分配给表的 --所有页必须属于与该表相关联的分配单元之一。如果页眉中包含的分配单元ID与表相关联的分配 --单元ID不匹配，将引发此异常。。错误消息中列出的第一个分配单元ID是页眉中的ID，第二个分配 --单元ID是表相关联的ID --严重级别21：可能存在数据损坏，造成原因包括损坏的页链、损坏的IAM或该对象的sys.objects目录视图 --中存在无效条目（即是页面失去了链接）。这些错误通常由硬件或磁盘驱动程序引起 --严重级别12：存在暂时性错误，即在缓存中出现错误，但不表示对磁盘上的数据造成破坏。 --包括： --（1）操作系统过早地通知SQL已完成某个I/O操作，尽管不存在实际的数据损坏，但显示错误消息 --（2）运行带有优化器提示NOLOCK查询，或将事务隔离级别设置为READ UNCOMMITTED,当使用NOLOCK --或READ UNCOMMITTED的查询尝试读取被其他用户移走或更改的数据时，将发生605错误。 --若要验证是否是605错误，请稍候重新运行该查询 --修复方法：如果数据访问发生该错误，运行DBCC CHECKDB没有显示错误，那么605错误是暂时的 --605意味着页面分配出现问题，所以也是一个非常严重的数据库损坏。一般用DBCC CHECKDB也很难修复 --以下这些错误都是使用DBCC CHECKDB来修复 --有些不丢数据能修复，有些丢数据能修复，有些丢数据也不能修复 --（1）PFS页面头有损坏 --（2）系统表中的聚集索引页面有损坏 --（3）某个字段的值不符合字段数据类型定义 --（4）元数据有损坏 -----------------------DBCC CHECKDB------------------------------------------------------------------------- --DBCC CHECKDB完成两项任务 --（1）检查数据库里有没有损坏发生 --（2）尽力修复数据库损坏，使数据能够被正常访问 --所以即使是一个正常运行的数据库，也建议定期运行这句命令，以确保没有损坏发生。 --对于已经发生访问错误的数据库，应该在第一时间运行这句命令，了解损坏范围和程度 --检查指定数据库中所有对象的逻辑和物理完整性 --1、首先检查一些关键的系统表 --2、对数据库运行DBCC CHECKALLOC --3、对数据库中的每个表和视图运行DBCC CHECKTABLE --4、对数据库运行DBCC CHECKCATALOG --5、验证数据库中每个索引视图的内容 --6、验证数据库中的Service Broker数据 --这意味着运行了DBCC CHECKDB，就不必再单独运行DBCC CHECKALLOC、DBCC CHECKTABLE、DBCC CHECKCATALOG --也意味着单独运行DBCC CHECKALLOC、DBCC CHECKTABLE、DBCC CHECKCATALOG不能完成DBCC CHECKDB的所有功能 --但是至少完成了大部分功能 --1、在检查数据库之前SQL需要去了解这个数据库到底存放了什么样的数据，也就是所谓数据库的“元数据”。没有这些 --信息，SQL无法知道自己将要去访问什么样的表格和怎样解释读到的记录 --SQL2000关键系统表： --sysindexes --sysobjects --syscolumnes --这些系统表存放的是表格和索引的定义信息，以及表格里每一个字段的数据类型定义 --所以SQL必须要确认这些表完好无损 --SQL2005关键系统表： --sysallocunits --syshobts --hobt:堆或B树 --syshobtcolumnes --sysrowsets --sysrowsetcolumns --SQL2000有3个关键系统表 SQL2005有5个关键系统表 --SQL2005里的关键系统表只有在DAC模式才能看到（但是我测试的时候使用DAC都不能看到关键系统表） --每一张系统表都有一个聚集索引 --2、DBCC CHECKALLOC --检查数据库所有页的分配。验证各种内部结构，这些结构可用于跟踪这些页，以及它们之间的关系 --3、DBCC CHECKTABLE --是否已正确连接索引、行内、LOB以及行溢出数据页 --索引是否按照正确的顺序排列 --各指针是否一致 --每页上的数据是否合理（包括计算列） --页面偏移量是否合理 --基表的每一行是否在每个非聚集索引中具有匹配的行，以及非聚集索引的每一行是否在基表中具有匹配的行 --已分区的表或索引的每一行是否都位于正确的分区中 --4、DBCC CHECKCATALOG --检查指定数据库系统表里记录的元数据逻辑一致性。 --在sys.columns视图里，有一个列不属于sys.objects里的任何一个表格或视图 --在外键视图sys.foreign_keys里的一个外键在sys.indexes里找不到对应的索引 --某个对象的父对象不存在。（例如有一个主键对象存在，但是主键所依附的表格不存在了） --这些错误除非用户自己去直接修改系统表里的数据否则不应该出现!!!!!!!!!!!!!!!!!!!!!!!!!! --5、验证数据库中每个索引视图的内容 --SQL支持在某些视图上建立索引，以提高视图的性能。在视图中一些经过计算的字段值，SQL会将 --它们存储到索引页面里。下次可以直接使用，而不需要再做计算 --如果视图查询的源数据量非常大，可以跳过这一步，可以使用PHYSICAL_ONLY这个参数 --6、验证数据库中Service Broker数据 --如果SQL使用了Service Broker的功能，SQL还会调用Service Broker的组件，检查相关的系统对象 --Service Broker的queue、pipeline等 是否正常。这部分和传统的表格索引没有直接关系 --如果你的数据库没有说“ 0 allocation errors” 和“0 consistency errors”，而是有若个 --错误，就意味着数据库有损坏，赶紧修吧 ------------------------DBCC CHECKDB提供的修复方法-------------------------------------------- --默认DBCC CHECKDB只会验证数据库是否完好，不会主动做修复数据库的动作 --repair_allow_data_loss 修复所有错误，执行修复可能会丢失数据 --repair_rebuild 快速修复以及耗时修复（重建索引、非聚集索引中的额外键），执行修复时不会丢失数据 --repair_fast 未执行任何修复，只是为了向后兼容性 --解决方法： --1、DBCC CHECKDB(GPOSDB) --有错误的情况下 --2、单用户模式下 ALTER DATABASE GPOSDB SET SINGLE_USER DBCC CHECKDB(GPOSDB,REPAIR_REBUILD) --还是不能修复 --3、单用户模式下 紧急模式下 --应当是最后手段，并只有在无法从备份还原数据库时才采用 --如果DBCC CHECKDB成功，修复操作不会考虑表本身或表之间可能存在的任何约束 --，如果指定的表与一个或多个约束有关，建议在修复操作后运行DBCC CHECKCONSTRAINTS --建议运行DBCC CHECKDB(GPOSDB,REPAIR_ALLOW_DATA_LOSS)之前备份数据库，因为 --DBCC CHECKDB造成的修改，可能会无法接受，而这个时候也无办法再用备份恢复的方法 --恢复数据库了 --只有万不得已的时候才使用DBCC CHECKDB(GPOSDB,REPAIR_ALLOW_DATA_LOSS) ALTER DATABASE GPOSDB SET EMERGENCY --紧急只读模式 ALTER DATABASE GPOSDB SET SINGLE_USER DBCC CHECKDB(GPOSDB,REPAIR_ALLOW_DATA_LOSS) USE GPOSDB DBCC CHECKCONSTRAINTS(systempara) --还还是不能修复 --1、恢复数据库备份 --2、如果是用户表、视图、存储过程损坏，可以DROP掉试试 --3、使用紧急只读模式，使用导入导出数据或者select into 导出数据ALTER DATABASE GPOSDB SET EMERGENCY --各个表的状态将会不一致，一般在逻辑上会有很大问题 --安装固件和各种软件的升级补丁 --SQLSERVER2000:SQLSERVER2000 SP4 +hotfix build 2245 --SQLSERVER2005:现在还没有发现导致数据库损坏的bug --SQLSERVER2008:现在还没有发现导致数据库损坏的bug --WindowsXP：升级到WindowsXP SP3 --Windows2000：升级到Windows2000 SP4 +hotfix KB838647 +hotfix 905205（scsiport.sys） --Windows2003：升级到Windows2003 SP2 +hotfix KB940467（storport.sys） --Windows2008：现在还没有发现会导致数据库损坏的bug
f
