YourSQLDba将数据库置于紧急模式的原因浅析
从SQL SERVER 2000 上迁移了一个数据库到SQL SERVER 2008 R2上,暂且用DataBaseName代替迁移的真实的数据库名(后面的资料也会将数据库真实的名字用DataBaseName代替),迁移过程中也没有啥问题,配置了YourDataBase,作业“YourSQLDba_FullBackups_And_Maintenance”每天凌晨12点整运行,结果第一天晚上YourDatabase将数据库DataBaseName置于紧急模式,检查错误日志情况如下:
错误现象:
YourSQLDba对数据库做一致性检查时,发现有错误,所以它将该数据库置于紧急模式,具体内容如下所

查看YourSQLDba的具体错误日志信息

单击Action字段,看到的内容如下(太多内容,部分省略)
- <Exec>
- <ctx>yMaint.IntegrityTesting</ctx>
- <cmd>DBCC checkDb('DataBaseName')</cmd>
- <err>Error 2508, Severity 16, level 3 : The In-row data RSVD page count for object "bMaterialIn79", index ID 0, partition ID 4563097419776, alloc unit ID 4563097419776(type In-row data) is incorrect. Run DBCC UPDATEUSAGE.</err>
- <err>Error 2508, Severity 16, level 3 : The In-row data RSVD page count for object "bMaterialIn93", index ID 0, partition ID 70442742317056, alloc unit ID 70442742317056(type In-row data) is incorrect. Run DBCC UPDATEUSAGE.</err>
- <msg>DBCC results for 'LibraryMS'.</msg>
- <msg>Service Broker Msg 9675, State 1: Message Types analyzed: 14.</msg>
- <msg>Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.</msg>
- <msg>Service Broker Msg 9667, State 1: Services analyzed: 3.</msg>
- <msg>Service Broker Msg 9668, State 1: Service Queues analyzed: 3.</msg>
- <msg>Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.</msg>
- <msg>Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.</msg>
- <msg>Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.</msg>
- <msg>Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.</msg>
- <msg>DBCC results for 'sys.sysrscols'.</msg>
- <msg>There are 6701 rows in 63 pages for object "sys.sysrscols".</msg>
- <msg>DBCC results for 'sys.sysrowsets'.</msg>
- <msg>There are 819 rows in 12 pages for object "sys.sysrowsets".</msg>
- <msg>DBCC results for 'sys.sysallocunits'.</msg>
- <msg>There are 848 rows in 17 pages for object "sys.sysallocunits".</msg>
- .................................................................................
- .................................................................................
- <msg>DBCC results for 'bMaterialIn79'.</msg>
- <msg>There are 1346 rows in 18 pages for object "bMaterialIn79".</msg>
- <msg>CHECKDB found 0 allocation errors and 1 consistency errors in table 'bMaterialIn79'(object ID 69627341).</msg>
- ...............................................................................
- ...............................................................................
- <msg>DBCC results for 'bMaterialIn93'.</msg>
- <msg>There are 2162 rows in 23 pages for object "bMaterialIn93".</msg>
- <msg>CHECKDB found 0 allocation errors and 1 consistency errors in table 'bMaterialIn93'(object ID 1074870946).</msg>
- <msg>CHECKDB found 0 allocation errors and 2 consistency errors in database 'DataBaseName'.</msg>
- <msg>DBCC execution completed. If DBCC printed error messages, contact your system administrator.</msg>
- </Exec>
对数据库执行DBCC CHECKDB('DataBaseName')得到的内容跟YourSQLDba的错误日志信息一致
- DBCC results for 'DataBaseName'.
- Service Broker Msg 9675, State 1: Message Types analyzed: 14.
- Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
- Service Broker Msg 9667, State 1: Services analyzed: 3.
- Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
- Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
- Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
- Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
- Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
- DBCC results for 'sys.sysrscols'.
- There are 6701 rows in 63 pages for object "sys.sysrscols".
- DBCC results for 'sys.sysrowsets'.
- There are 819 rows in 12 pages for object "sys.sysrowsets".
- ...................................................................
- ..................................................................
- DBCC results for 'bMaterialIn79'.
- Msg 2508, Level 16, State 3, Line 1
- The In-row data RSVD page count for object "bMaterialIn79", index ID 0, partition ID 4563097419776, alloc unit ID 4563097419776(type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
- There are 1346 rows in 18 pages for object "bMaterialIn79".
- CHECKDB found 0 allocation errors and 1 consistency errors in table 'bMaterialIn79'(object ID 69627341).
- .....................................................................
- .....................................................................
- The In-row data RSVD page count for object "bMaterialIn93", index ID 0, partition ID 70442742317056, alloc unit ID 70442742317056(type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
- There are 2162 rows in 23 pages for object "bMaterialIn93".
- CHECKDB found 0 allocation errors and 1 consistency errors in table 'bMaterialIn93'(object ID 1074870946).
- DBCC results for 'bMaterialApply40'.
- ....................................................................
- ....................................................................
- CHECKDB found 0 allocation errors and 2 consistency errors in database 'DataBaseName'.
- DBCC execution completed. If DBCC printed error messages, contact your system administrator.
分析原因:
这些错误提示数据页在保留空间中不正确的值,在SQL 2000中,这些错误也有可能是数据条目或者数据页的数目跟索引或表中记录的不一致所导致的。CheckDB 不会修复类似错误,在SQL 2005 中CheckDB只会给出一个警告信息。这不是什么严重的错误,按照提示运行DBCC UPDATEUSAGE行了,这通常发生在SQL 2000升级为2005/2008后,在SQL 2005/2008中一般不会遇到。刚好我这个数据库DataBaseName是从SQL 2000升级到SQL 2008,其实这确实不是一个什么严重错误,但是YourSQLDba意识到了“严重性”将数据库出于紧急模式,不能让系统或用户继续操作该数据库了,那么接下来用DBCC UPDATEUSAGE 解决该问题。
- DBCC UPDATEUSAGE(LibraryMS,"dbo.bMaterialIn79");
- GO
- DBCC UPDATEUSAGE: Usage counts updated for table 'bMaterialIn79'(index 'bMaterialIn79', partition 1):
- USED pages(In-row Data): changed from (21) to (19) pages.
- RSVD pages(In-row Data): changed from (-107) to (73) pages.
- DBCC UPDATEUSAGE: Usage counts updated for table 'bMaterialIn79'(index 'PK_bMaterialIn79', partition 1):
- RSVD pages(In-row Data): changed from (8) to (17) pages.
- DBCC execution completed. If DBCC printed error messages, contact your system administrator.
- DBCC UPDATEUSAGE(LibraryMS,"dbo.bMaterialIn93");
- GO
- DBCC UPDATEUSAGE: Usage counts updated for table 'bMaterialIn93'(index 'bMaterialIn93', partition 1):
- USED pages(In-row Data): changed from (38) to (24) pages.
- RSVD pages(In-row Data): changed from (-18) to (49) pages.
- DBCC UPDATEUSAGE: Usage counts updated for table 'bMaterialIn93'(index 'PK_bMaterialIn93', partition 1):
- RSVD pages(In-row Data): changed from (16) to (17) pages.
- DBCC execution completed. If DBCC printed error messages, contact your system administrator.
关于DBCC UPDATEUSAGE的MSDN解释如下:
-----------------------------------------------------------------------------------------------------------------------
备注
DBCC UPDATEUSAGE 将针对表或索引中的每个分区更正行、已用页、保留页、叶级页和数据页的计数。如果系统表中没有错误,则 DBCC UPDATEUSAGE 不返回数据。如果发现错误,并对其进行更正,同时没有使用 WITH NO_INFOMSGS,DBCC UPDATEUSAGE 将返回系统表中更新的行和列。
使用 DBCC UPDATEUSAGE 同步空间使用计数器。因为 DBCC UPDATEUSAGE 在大型表或大型数据库中运行可能会需要一些时间,所以通常只在怀疑 sp_spaceused 返回的值不正确时使用。sp_spaceused 在返回表或索引的空间信息之前接受可选参数以运行 DBCC UPDATEUSAGE。
升级数据库
在 SQL Server 的早期版本中,用于表和索引行计数以及页计数的值可能不正确。根据 SQL Server 2005 之前的版本创建的数据库可能包含错误的计数。因此,我们建议在升级之后运行 DBCC UPDATEUSAGE,以便更正所有的无效计数。
DBCC CHECKDB 已得到增强,可以检测页计数或行计数变为负值的情况。检测到上述问题后,DBCC CHECKDB 的输出会包含一个警告和一个建议,建议运行 DBCC UPDATEUSAGE 解决该问题。
------------------------------------------------------------------------------------------------------------------------
YourSQLDba将数据库置于紧急模式的原因浅析的更多相关文章
- SQLSERVER数据库置疑、可疑、脱机、单用户、紧急模式等的修复
数据库出现置疑.可疑.脱机.单用户.紧急模式主要是因为数据库的日志文件除了问题,2000和2008修复方式不一样,2008的修复脚本在2000中不适用,主要是不被2000识别. 假设数据库名为:eis ...
- SQL Server 数据库单用户模式处理
在还原数据库bak备份文件时,由于某种原因(具体何种原因在此不进行分析)导致数据库还原后处于单用户模式,如下图: 单个用户模式导致,数据库无法打开,只能通过脚本去查询数据库内的表,然后进行查询数据,极 ...
- 数据库精华知识点总结(1)—数据库的三层模式和二级映像,E-R(实体联系图)图,关系模型
Data base: 长期存储在计算机内,有组织的,可共享的大量数据集合.基本特征:永久存储,可共享,有一定的物理和逻辑结构. Data base manage system(DBMS):用户和os之 ...
- oracle数据库的归档模式
1:开发环境和测试环境中,数据库的日志模式和自动归档模式一般都是不设置的,这样有利于系统应用的调整,也免的生成大量的归档日志文件将磁盘空间大量的消耗. 2:生产环境时,将其设置为日志模式并自动归档就相 ...
- 修改oracle数据库为归档模式
参考博客:http://blog.csdn.net/codesaint/article/details/1901030 Oracle分为非归档模式(NOARCHIVELOG) 和归档模式(ARCHI ...
- 救援模式(Rescue Mode)、单用户模式(Single-User Mode)、紧急模式(Emergency Mode)的区别与联系
前天聚餐的时候一航和启飞学长讲到RUCTF中更改root密码要进入单用户模式,我插了一句"有的系统显示的是救援模式",说完后心里一直很虚...(技术上的事还是想好再说)今天查了一下 ...
- SQL Server数据库有三种恢复模式:简单恢复模式、完整恢复模式和大容量日志恢复模式
SQL Server数据库有三种恢复模式:简单恢复模式.完整恢复模式和大容量日志恢复模式: 1.Simple 简单恢复模式, Simple模式的旧称叫”Checkpoint with truncate ...
- Oracle数据库LOGGING&NOLOGGING模式概述
1.日志记录模式(LOGGING .FORCE LOGGING .NOLOGGING) 1.1三者的含义 LOGGING:当创建一个数据库对象时将记录日志信息到联机重做日志文件.LOGGING实际上是 ...
- 进入CentOS7紧急模式恢复root密码
第一步.重启CentOS7,在以下界面选择要编辑的内核(一般第一个),按e进入编辑界面 第二步.在编辑界面找到如下一行,将ro改为rw init=/sysroot/bin/sh.改完后<Ctrl ...
随机推荐
- 1Z0-053 争议题目解析486
1Z0-053 争议题目解析486 考试科目:1Z0-053 题库版本:V13.02 题库中原题为: 486.You execute the following Recovery Manager (R ...
- 1Z0-053 争议题目解析683
1Z0-053 争议题目解析683 考试科目:1Z0-053 题库版本:V13.02 题库中原题为: 683.Your production database it functional on the ...
- 1Z0-053 争议题目解析699
1Z0-053 争议题目解析699 考试科目:1Z0-053 题库版本:V13.02 题库中原题为: 699.Your database is using a default temporary ta ...
- 【字符编码】字符编码 && Base64编码算法
一.前言 在前面的解决乱码的一文中,只找到了解决办法,但是没有为什么,说白了,就是对编码还是不是太熟悉,编码问题是一个很简单的问题,计算机从业人员应该也必须弄清楚,基于编码的应用有Base64加密算法 ...
- Android置底一个View后运行报错
大致问题是 放一个LinearLayout ID @+id/layout ,然后在它上面放一个button 设置android:layout_above="@id/layout" ...
- using语法糖详解 2015-01-06 17:45 50人阅读 评论(0) 收藏
前段事件在using外套try catch 突然想到,如果出现异常 会不会执行释放,不执行的话那服务器很可能导致崩溃... 特意上了CSDN问了大神..得到了答案.. Using相等于try catc ...
- 工作流引擎Oozie(一):workflow
1. Oozie简介 Yahoo开发工作流引擎Oozie(驭象者),用于管理Hadoop任务(支持MapReduce.Spark.Pig.Hive),把这些任务以DAG(有向无环图)方式串接起来.Oo ...
- sed命令使用详解归纳
用法 sed [option] 'Address Command' yourfile e.g. sed -n '2,13p' lineuser #打印文件lineuser中第2~13行的内容,-n为o ...
- NanUI for Winform 使用示例【第一集】——山寨个代码编辑器
NanUI for Winform从昨天写博客发布到现在获得了和多朋友的关注,首先感谢大家的关注和支持!请看昨天本人的博文<NanUI for Winform发布,让Winform界面设计拥有无 ...
- Data type confusion: what is an int(11)?
http://everythingmysql.ning.com/profiles/blogs/data-type-confusion-what-is-an Over and over I see cu ...