<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>

<channel>
	<title>数据库修复中心</title>
	<atom:link href="http://www.db-recovery.com/feed" rel="self" type="application/rss+xml" />
	<link>http://www.db-recovery.com</link>
	<description>数据库修复,恢复损坏的SQL Server、MDF、Oracle文件</description>
	<pubDate>Wed, 01 Sep 2010 08:27:56 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>重装系统通过数据恢复软件找回来的数据库文件提示不是有效的SQL SERVER文件的修复案例</title>
		<link>http://www.db-recovery.com/mdf-file-not-valid-sql-server-database-file.html</link>
		<comments>http://www.db-recovery.com/mdf-file-not-valid-sql-server-database-file.html#comments</comments>
		<pubDate>Wed, 01 Sep 2010 08:24:37 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[不是有效的sql数据库文件]]></category>

		<category><![CDATA[系统表]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=190</guid>
		<description><![CDATA[客户重装系统忘记备份原c分区的数据库 ，之后通过数据恢复软件找回来了几个数据库文件 。其中3个数据库都能正常附加使用，仅当中1个库无法附加，提示不是有效的SQL SERVER文件 ,如图

修复过程
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
是不是看了上面的流程有点眼熟呀， 不错，就是之前介绍过的 Sql Server置疑数据库解决方法 ，执行的语句就不用多讲了， 大家可以看前面的文章。
言归正传，我在执行到
dbcc rebuild_log(&#8217;kmxc&#8217;,'F:\www.db-recovery.com\kmxc_log.ldf&#8217;)
提示报错
服务器: 消息 5180，级别 22，状态 1，行 1
由于文件 ID 0（位于数据库 &#8216;kmxc&#8217; 中）无效，所以未能打开 FCB。
连接中断
日志创建不了， 先不管，用DBCC checkdb看看报什么错误
服务器: 消息 8966，级别 16，状态 1，行 1
未能读取并闩锁页 (33216:0)（用闩锁类型 SH）。sysindexes 失败。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
分析它结构，修复sysindexes ，其他系统表还是有错误， 看来只能重建修复系统表了。 通过原有备份，重建系统表，DBCC checkdb一点问题都没有 ， 交付客户验证无误。
]]></description>
		<wfw:commentRss>http://www.db-recovery.com/mdf-file-not-valid-sql-server-database-file.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>TempDB损坏的处理</title>
		<link>http://www.db-recovery.com/tempdb-damage.html</link>
		<comments>http://www.db-recovery.com/tempdb-damage.html#comments</comments>
		<pubDate>Tue, 31 Aug 2010 12:08:11 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[sql教程]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=188</guid>
		<description><![CDATA[故障环境:WinNT4.0Cluster+SQL Server7.0
故障描述: 8:30左右发现资料库当机,cluster作移转后sql server无法起来,查看windows日志,有错误纪录如下 
　　事件类型: 错误
　　事件来源: ClusSvc
　　事件类别目录: (2052)
　　事件识别码: 1066
　　日期: 2005-1-21
　　时间: 8:23:20
　　使用者: N/A
　　电脑: TEST
　　描述:
Cluster disk resource Disk G:: is corrupt. Running ChkDsk /F to repair problems.
请在http://go.microsoft.com/fwlink/events.asp 查看说明及支援中心，以取得其他资讯。
根据该错误纪录,需要对TEST\G做check disk.再对资料库做完整backup后,停止cluster服务,重起server后,chkdsk g: /f 执行成功.再次启动sql server,依旧无法开启,windows event log出下以下错误
　　事件类型: 资讯
　　事件来源: MSSQLServer$TEST
　　事件类别目录: Server
　　事件识别码: 17055
　　日期: 2005-1-21
　　时间: 8:23:54
　　使用者: N/A
　　电脑: TEST
　　描述:
17052 :Database &#8216;tempdb&#8217; cannot be opened. It has been marked SUSPECT by recovery. See the [...]]]></description>
		<wfw:commentRss>http://www.db-recovery.com/tempdb-damage.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>数据库由于索引损坏通过dbcc checkdb修复后记录有缺失的恢复案例</title>
		<link>http://www.db-recovery.com/shu-ju-ku-you-yu-suo-yin-sun-huai-tong-guo-dbcc-checkdb-xiu-fu-hou-ji-lu-you-que-shi-de-hui-fu-an-li.html</link>
		<comments>http://www.db-recovery.com/shu-ju-ku-you-yu-suo-yin-sun-huai-tong-guo-dbcc-checkdb-xiu-fu-hou-ji-lu-you-que-shi-de-hui-fu-an-li.html#comments</comments>
		<pubDate>Fri, 13 Aug 2010 02:22:22 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[一致性错误]]></category>

		<category><![CDATA[系统表]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=182</guid>
		<description><![CDATA[可能断电之类的情况引起数据库置疑 ，在重新附加mdf文件提示
错误3456:未能恢复日志记录(425:1157:2)，事物ID(0:368377) ,位于页(1:253),数据库&#8217;Card_Enp&#8217;(13) 。页:lsn = (424:13171:2) ，类型 =1 。 日志:opcode=4，上下文2，prevpageLsn:(425:683:2)
如图

用Sql Server置疑数据库解决方法将数据库成功加载 ，用dbcc checkdb检查数据库 ，显示结果
服务器: 消息 8978，级别 16，状态 1，行 1
表错误: 对象 ID 53575229，索引 ID 3。页 (1:4065) 缺少上一页 (1:1229) 对它的引用。可能是因为链的链接有问题。
CHECKDB 发现了 0 个分配错误和 1 个一致性错误（在表 &#8216;Consume&#8217; 中，该表的对象 ID 为 53575229）。
服务器: 消息 8951，级别 16，状态 1，行 1
表错误: 表 &#8216;ST_Fund&#8217;（ID 2050106344）。索引 &#8216;XIF1ST_Fund&#8217;（ID 2）中下列行的键缺少或无效:
服务器: 消息 8955，级别 16，状态 1，行 1
数据行（1:3914:92）（由 RID = [...]]]></description>
		<wfw:commentRss>http://www.db-recovery.com/shu-ju-ku-you-yu-suo-yin-sun-huai-tong-guo-dbcc-checkdb-xiu-fu-hou-ji-lu-you-que-shi-de-hui-fu-an-li.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>河南某宾馆数据库错误5172提示不是有效数据库文件头的修复案例</title>
		<link>http://www.db-recovery.com/sql-error-message-5172.html</link>
		<comments>http://www.db-recovery.com/sql-error-message-5172.html#comments</comments>
		<pubDate>Tue, 10 Aug 2010 02:50:56 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[一致性错误]]></category>

		<category><![CDATA[系统表]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=178</guid>
		<description><![CDATA[接收客户的数据库，咨询了些细节问题， 客户对数据库怎么坏不清楚 。
附加数据库提示
错误5172：文件头不是有效的数据库文件头，pageaudi属性不正确

执行DBCC
服务器: 消息 8966，级别 16，状态 1，行 1
未能读取并闩锁页 (0:1072693248)（用闩锁类型 SH）。sysobjects 失败。
看来是有部分页残缺了， 通过提取碎片整合，使用自主开发的数据库修复软件成功读取所有数据 。 交付客户验证无误 。
]]></description>
		<wfw:commentRss>http://www.db-recovery.com/sql-error-message-5172.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>sql故障错误消息8952，8956，8944，8928的案例修复</title>
		<link>http://www.db-recovery.com/sql8952-8956-8944-8928.html</link>
		<comments>http://www.db-recovery.com/sql8952-8956-8944-8928.html#comments</comments>
		<pubDate>Sat, 07 Aug 2010 08:39:55 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[sql教程]]></category>

		<category><![CDATA[一致性错误]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=176</guid>
		<description><![CDATA[收到一个行内朋友的数据库，说是断电引起的的 。
通过DBCC检查

服务器: 消息 8952，级别 16，状态 1，行 1
表错误: 数据库 &#8217;stk02&#8242;，索引 &#8217;sysobjects.ncsysobjects&#8217;（ID 1）（索引 ID 2）。下列键的键多余或无效:
服务器: 消息 8956，级别 16，状态 1，行 1
索引行（1:831:29）（其值为 name = &#8216;DF__eiorwkm__custome__46BE619D&#8217; and uid = 5 and id = 1186881949）指向由  标识的数据行。
服务器: 消息 8952，级别 16，状态 1，行 1
表错误: 数据库 &#8217;stk02&#8242;，索引 &#8217;syscolumns.ncsyscolumns&#8217;（ID 3）（索引 ID 2）。下列键的键多余或无效:
服务器: 消息 8956，级别 16，状态 1，行 1
索引行（1:859:116）（其值为 id = 1897224563 and name = &#8216;base_⑹ear_index&#8217; and [...]]]></description>
		<wfw:commentRss>http://www.db-recovery.com/sql8952-8956-8944-8928.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>常州某企业 sql数据库不慎删除表记录日志文件也被清空的修复案例</title>
		<link>http://www.db-recovery.com/chang-zhou-mou-qi-ye-sql-shu-ju-ku-bu-shen-shan-chu-biao-ji-lu-ri-zhi-wen-jian-ye-bei-qing-kong-de-xiu-fu-an-li.html</link>
		<comments>http://www.db-recovery.com/chang-zhou-mou-qi-ye-sql-shu-ju-ku-bu-shen-shan-chu-biao-ji-lu-ri-zhi-wen-jian-ye-bei-qing-kong-de-xiu-fu-an-li.html#comments</comments>
		<pubDate>Fri, 30 Jul 2010 06:24:04 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[sql教程]]></category>

		<category><![CDATA[删除]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=174</guid>
		<description><![CDATA[昨晚在晚上遇到个客户，由于公司里新来的IT不怎么会sql，不慎将cost表记录都给删除，之后那人就慌了到网上找各种资料向恢复记录，最后连LDF文件(日志文件)也被重新创建 。现在快已经月底，等着很多地方的收付款 ，财务那边急死了。
通过网络接收客户传来数据库文件 ，检测了下，所幸数据库未被收缩 ，通过自主开发数据库修复软件，成功提取删除记录，导入新库  。客户通过远程验证无误。
]]></description>
		<wfw:commentRss>http://www.db-recovery.com/chang-zhou-mou-qi-ye-sql-shu-ju-ku-bu-shen-shan-chu-biao-ji-lu-ri-zhi-wen-jian-ye-bei-qing-kong-de-xiu-fu-an-li.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>修复mysql数据库</title>
		<link>http://www.db-recovery.com/xiu-fu-mysql-shu-ju-ku.html</link>
		<comments>http://www.db-recovery.com/xiu-fu-mysql-shu-ju-ku.html#comments</comments>
		<pubDate>Fri, 30 Jul 2010 05:45:43 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[其他]]></category>

		<category><![CDATA[sql教程]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=172</guid>
		<description><![CDATA[有的时候因为掉电或者其他原因导致数据库损坏,我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库或者特定的数据库http://www.raidcn.net ;例如
检查优化并修复所有的数据库用: 
1.先在运行中输入CMD,启动命令行. 
2.进入Mysql的Bin目录：D:\Program Files\MySQL\MySQL Server 5.0\bin,如果不知道如何进入别的目录,就要参考网上的资料补习基础知识了.
常见方式:
运行 D:
运行 CD &#8220;E:\Program Files\MySQL\MySQL Server 5.0\bin&#8221; 
3.运行：mysqlcheck -A -o -r -uroot -pTest123
注意，将Test123改成你自己的root用户密码 
mysql.columns_priv　　　　　　　　　　　　　　　　  OK
mysql.db　　　　　　　　　　　　　　　　　　　　　   OK
mysql.func　　　　　　　　　　　　　　　　　　　　    OK
mysql.help_category　　　　　　　　　　　　　　　   OK
mysql.help_keyword　　　　　　　　　　　　　　　   OK
mysql.help_relation                     [...]]]></description>
		<wfw:commentRss>http://www.db-recovery.com/xiu-fu-mysql-shu-ju-ku.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>sql随记</title>
		<link>http://www.db-recovery.com/sql_faq.html</link>
		<comments>http://www.db-recovery.com/sql_faq.html#comments</comments>
		<pubDate>Wed, 21 Jul 2010 01:10:08 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[sql教程]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=170</guid>
		<description><![CDATA[SQL Server 2000 升级到SQL Server 2005 时，其中一项重大变更，就是对资料库系统目录(常常称为系统资料表或资料库中继资料，内存各种关于资料表、索引、资料行、配置的中继资料，以及其他与关联性和资料实际结构相关的详细资料) 结构所做的变更。
SQL版本代码:

SQL Server 7.0 资料库的版本号码是515
SQL Server 2000 资料库的版本号码是539
SQL Server 2005 资料库版本号码则是611 (如果有启用Vardecimal 功能的话，则为612)

多個檔案群組上磁碟分割(SQL2008)
简单的说，虽然您可以在相同的档案群组内拥有多个磁碟分割，但是在磁碟分割与档案群组之间拥有一对一对应关系也有很多优点。
部分资料库可用性这项功能可让资料库保持在线上状态，而且可被存取，只要主要档案群组在严重损坏修复的情况下还在线上就行了。如果您只有一个档案群组，那么整个资料库就会在还原时停摆。若将资料分散到多个档案群组，还原期间就只有受损的档案群组会离线，而应用程式还是可以继续运作。
分次還原 此種配置與部分資料庫可用性雷同。如果只有一個檔案群組時，還原的單位不是單頁，就是整個資料庫。如果有多個檔案群組時，就可以只還原一個檔案群組 — 這樣就有部分資料庫可以使用。
分割式资料库维护针对上述的任何一种磁碟分割案例，您可以依磁碟分割执行索引片段移除作业，即便所有磁碟分割都位在同一个档案群组也可行。但是对于单一档案群组，就无法进行依档案群组的一致性检查，而这可大幅减少资料库一致性检查(DBCC) 需要处理的资料量，转而降低所用的CPU 和I/O 资源量。
]]></description>
		<wfw:commentRss>http://www.db-recovery.com/sql_faq.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>mssqlserver 错误7995系统表不一致性错误的的修复案例</title>
		<link>http://www.db-recovery.com/mssqlserver-cuo-wu-7995-xi-tong-biao-bu-yi-zhi-xing-cuo-wu-de-de-xiu-fu-an-li.html</link>
		<comments>http://www.db-recovery.com/mssqlserver-cuo-wu-7995-xi-tong-biao-bu-yi-zhi-xing-cuo-wu-de-de-xiu-fu-an-li.html#comments</comments>
		<pubDate>Fri, 02 Jul 2010 03:46:25 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=165</guid>
		<description><![CDATA[客户的服务器安装了sql server2000  ，由于非正常断电引起了，数据库的部分表无法打开 ，提示823错误 。
使用dbcc checkdb 
服务器: 消息 7995，级别 16，状态 1，行 1
数据库 &#8216;dbfix11&#8242; 在 sysobjects、sysindexes、syscolumns 或 systypes 中存在一致性错误，妨碍了进一步的 CHECKDB 处理。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
修复过程
分析文件损坏程度，手工修复系统表 ，重建索引 ，成功修复所有表数据。
]]></description>
		<wfw:commentRss>http://www.db-recovery.com/mssqlserver-cuo-wu-7995-xi-tong-biao-bu-yi-zhi-xing-cuo-wu-de-de-xiu-fu-an-li.html/feed</wfw:commentRss>
		</item>
		<item>
		<title>IAM页、IAM链及分配单元</title>
		<link>http://www.db-recovery.com/iam-ye-iam-lian-ji-fen-pei-dan-yuan.html</link>
		<comments>http://www.db-recovery.com/iam-ye-iam-lian-ji-fen-pei-dan-yuan.html#comments</comments>
		<pubDate>Fri, 28 May 2010 01:13:14 +0000</pubDate>
		<dc:creator>dbsos</dc:creator>
		
		<category><![CDATA[SQL Server数据库]]></category>

		<category><![CDATA[sql教程]]></category>

		<guid isPermaLink="false">http://www.db-recovery.com/?p=162</guid>
		<description><![CDATA[IAM页

一个IAM页（索引分配页）跟踪单个文件里将近4GB的空间，以4GB为界。这4GB的数据称为“GAM间隔”。一个IAM页跟踪属于单个实体（这里我小心的选择我的用语，并且不使用SQL Server有诸如“对象”等之类隐含意义的词语）的特定GAM间隔内的扩展盘区。
一个IAM只跟踪单个文件里单个GAM的空间，所以如果数据库有多个文件、或者一些文件不止4GB，并且实体从多个文件或单个文件的多个GAM间隔分配空间的话，那么你可以看到每个实体要跟踪它使用所有空间需要多少IAM页。如果一个实体需要多个IAM页来跟踪所有扩展盘区的话，那么这些IAM必须链接在一起。这就是所说的IAM链。更多内容请往下读。每个IAM页有2条记录，一个IAM页头和位图。让我们用DBCC Page来看看,在我们创建的表上执行DBCC IND，得到下图内容：

 
通过查看Pagetype列，我们可以看到有一个IAM页（类型为10），其页ID是(1:152)：
DBCC TRACEON (3604);
GO
DBCC PAGE (&#8217;pagesplittest&#8217;, 1, 152, 3);
GO
m_pageId = (1:152)                  m_headerVersion = 1                  m_type = 10
m_typeFlagBits = 0&#215;0                m_level = 0                          m_flagBits = 0&#215;200
m_objId (AllocUnitId.idObj) = 68    m_indexId (AllocUnitId.idInd) = 256
Metadata: AllocUnitId = 72057594042384384
Metadata: PartitionId = 72057594038386688                                Metadata: IndexId = 1
Metadata: ObjectId = 2073058421      m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 90                        [...]]]></description>
		<wfw:commentRss>http://www.db-recovery.com/iam-ye-iam-lian-ji-fen-pei-dan-yuan.html/feed</wfw:commentRss>
		</item>
	</channel>
</rss>
