我有个只有MDF的SQL 2005数据库，无LDF文件，且该MDF文件有一致性错误（在后来恢复中提示的，有页撕裂错误）
我按一般的方法如下操作：
第一步：先建立一个同名数据库，停止SQL SERVER2005，将没有日志的的.mdf数据库文件覆盖刚新建的.mdf数据库文件，重新启动数据库。
第三步：在查询分析器中运行如下代码：
alter database 数据库名 set emergency '--将数据库设置为紧急状态
use master
declare @databasename varchar(255)
set @databasename='数据库名' '--.mdf文件文件名
exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态
在以上步骤都是OK的，执行完后，发现数据库状态始终是RECOVERY PENDING，再要往下
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
就提示数据库正在恢复中，没法进行下去了
有没有朋友有这方面的经验，可以分享一下，多谢
30 个解决方案
#1
--将处于还原状态的数据库置为可用状态
RESTORE DATABASE [DBName] WITH RECOVERY
#2
有道理，楼主测试下。
#3
2、只有mdf文件的恢复技术
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息。
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器：消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢?别着急，下面我们举例说明恢复办法。
A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server EntERPrise Manager里面建立。
B.停掉数据库服务器。
C.将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E.设置数据库允许直接操作系统表。此操作可以在SQL Server EntERPrise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
use master go sp_configure 'allow updates',1 go reconfigure with override go
F.设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。
G.下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告：数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H.验证数据库一致性(可省略)
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I.设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦！
J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server EntERPrise Manager里面恢复，也可以使用如下语句完成。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
sp_configure 'allow updates',0 go reconfigure with override go
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息。
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器：消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢?别着急，下面我们举例说明恢复办法。
A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server EntERPrise Manager里面建立。
B.停掉数据库服务器。
C.将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E.设置数据库允许直接操作系统表。此操作可以在SQL Server EntERPrise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
use master go sp_configure 'allow updates',1 go reconfigure with override go
F.设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。
G.下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告：数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H.验证数据库一致性(可省略)
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I.设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦！
J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server EntERPrise Manager里面恢复，也可以使用如下语句完成。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
sp_configure 'allow updates',0 go reconfigure with override go
#4
恢复MDF存在LDF不存在的数据库
问题原因：
MDF文件保存完好（已拷出来），LDF已丢失。使用：
EXEC sp_attach_single_file_db @dbname = 'TyBusiness',
@physname = 'E:\Help\TyBusiness.MDF'
报如下错误：
未能打开新数据库 'TyBusiness'。CREATE DATABASE 将终止。
设备激活错误。物理文件名
'd:\Program Files\Microsoft SQL Server\MSSQL\TyBusiness_log.ldf' 可能有误。
解决办法：
1、先建一个与你要恢复的数据库名称一样的数据库。
2、停止sql server，把你的数据库替换这个数据库。
3、重起sql server，把数据库设成紧急状态（在查询分析器里面进行）：
sp_configure 'allow',1
reconfigure with override
update sysdatabases set status=32768 where name='yourdata'
4、重建日志文件
dbcc rebuild_log('yourdata','your data path\newdata_log.ldf')
5、取消紧急模式
update sysdatabases set status=0 where name='yourdata'
restore sysdatabases yourdata with recovery
sp_configure 'allow',0
reconfigure with override
6、重起sql server
7、OK！
#5
jia_guijun提的
RESTORE DATABASE [DBName] WITH RECOVERY
我试了，提示只能对ONLINE的数据库进行这样的操作
而我的数据库是先设置了emergency，然后设置了单用户模式的
我尝试了把它设置为ONLINE，但系统提示文件不可用，然后也是同样的一致性错误，页撕裂
lg3605119 ，HEROWANG 贴的都是SQL 2000下的方法
而SQL 2005的一般方法我在提问中已贴出，
只是在遇到这个有问题的MDF恢复时，走不下去，所以向大家请教
RESTORE DATABASE [DBName] WITH RECOVERY
我试了，提示只能对ONLINE的数据库进行这样的操作
而我的数据库是先设置了emergency，然后设置了单用户模式的
我尝试了把它设置为ONLINE，但系统提示文件不可用，然后也是同样的一致性错误，页撕裂
lg3605119 ，HEROWANG 贴的都是SQL 2000下的方法
而SQL 2005的一般方法我在提问中已贴出，
只是在遇到这个有问题的MDF恢复时，走不下去，所以向大家请教
#6
更改为MULTI_USER用户模式再试。
USE Master
GO
RESTORE DATABASE [DBName] WITH RECOVERY
#7
回jia_guijun
无论是单用户模式，还是多用户模式，提示都是一样的
RESTORE语句在当前上下文中无效，仅当数据库处于联机状态时，才为辅助文件组定义为RECOVER DATA ONLY选项，
当数据库处于离线状态时，不能指定文件组，RESTORE DATABASE异常终止
无论是单用户模式，还是多用户模式，提示都是一样的
RESTORE语句在当前上下文中无效，仅当数据库处于联机状态时，才为辅助文件组定义为RECOVER DATA ONLY选项，
当数据库处于离线状态时，不能指定文件组，RESTORE DATABASE异常终止
#8
该回复于2012-07-11 08:53:12被版主删除
#9
尽一切可能最好备份。祝楼主好运！
#10
该回复于2012-07-11 08:53:18被版主删除
#11
想請問下樓主這個mdf檔有多大，數據機密碼？我一直想找這個樣的MDF試一下，都沒有碰到，自己也不知道要怎麼制造出來。如果不大數據又不機密的話，可否寄給我試試？
#12
建一个同名的数据库,
detach
用MDF覆盖新的数据库文件,
attach
detach
用MDF覆盖新的数据库文件,
attach
#13
xiao_hn 数据满大的，有些敏感数据，不太方便传给您，请见谅
#14
以前用下文成功恢复过，楼主可以try.
只有mdf文件的恢复技术
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，
但是会出现类似下面的提示信息
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息
服务器: 消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢？别着急，下面我们举例说明恢复办法。
A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。
B．停掉数据库服务器。
C．将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F．设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
G．下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。[brown][/i]
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
#15
回perfectaction
谢谢。这个方式我试过，不行
谢谢。这个方式我试过，不行
#16
是否可远程看看？
#17
文件出问题了吧，上面的方法基本都可以解决了，检查数据文件结构是否正确。
#18
“且该MDF文件有一致性错误（在后来恢复中提示的，有页撕裂错误）” ,应该是PFS页的问题，2005对于损坏的页，可以跳过，如果在上述大虾们的处理步骤通不过，应该考虑是不是系统表出现损坏了。
#19
哎，莫非没有好办法了
#20
该回复于2012-07-11 08:53:35被版主删除
#21
该回复于2012-07-11 08:53:41被版主删除
#22
首先说问题描述，前后表达矛盾。一方面说“在后来恢复中提示的，有页撕裂错误”，一方面说“再要往下dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) 就提示数据库正在恢复中，没法进行下去了”
对于这个问题，我做了测试，大致分析如下:
1.lz第三步 alter database 数据库名 set emergency '--将数据库设置为紧急状态
这步执行后数据库状态已经是 emergency了，因为recovery pending状态下是不让你执行dbcc checkdb的，之所以lz误认为一直是recovery pending状态，大概都是在dbcc checkdb执行失败后查的吧，之所以最终还是recovery pending状态，是因为checkdb执行失败后sql server又将数据库状态重新置回了recovery pending了。
2.对于这个无法修复的情况，lz只能在emergency状态下多导点有用的数据出来吧。完全修复数据库是不大可能了。
对于这个问题，我做了测试，大致分析如下:
1.lz第三步 alter database 数据库名 set emergency '--将数据库设置为紧急状态
这步执行后数据库状态已经是 emergency了，因为recovery pending状态下是不让你执行dbcc checkdb的，之所以lz误认为一直是recovery pending状态，大概都是在dbcc checkdb执行失败后查的吧，之所以最终还是recovery pending状态，是因为checkdb执行失败后sql server又将数据库状态重新置回了recovery pending了。
2.对于这个无法修复的情况，lz只能在emergency状态下多导点有用的数据出来吧。完全修复数据库是不大可能了。
#23
实例Recovery出现recovery pending 一般是由于数据库文件不可用造成的。
可以通过dbcc checkprimaryfile ( 'mdf filename',3)
来查询主数据库文件中记录的每个文件的相关信息。
-------------------------------------------
QQ：1209667578 提供SQLServer数据库和优化服务！
可以通过dbcc checkprimaryfile ( 'mdf filename',3)
来查询主数据库文件中记录的每个文件的相关信息。
-------------------------------------------
QQ：1209667578 提供SQLServer数据库和优化服务！
#24
QQ：1209667578 提供SQLServer数据库修复和优化服务！
#25
该回复于2012-07-11 08:53:51被版主删除
#26
LZ， 没LDF？ 哪就是缺少日志文件了，只有数据。
#27
我顶。同时希望高手帮一帮解决掉。
#28
顶一下，今天也遇到这样的一个问题，解决不了，好多数据等着恢复呢，愁死了
#29
直接附加报什么错？
#30
该回复于2012-07-11 08:54:02被版主删除
#1
--将处于还原状态的数据库置为可用状态
RESTORE DATABASE [DBName] WITH RECOVERY
#2
有道理，楼主测试下。
#3
2、只有mdf文件的恢复技术
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息。
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器：消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢?别着急，下面我们举例说明恢复办法。
A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server EntERPrise Manager里面建立。
B.停掉数据库服务器。
C.将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E.设置数据库允许直接操作系统表。此操作可以在SQL Server EntERPrise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
use master go sp_configure 'allow updates',1 go reconfigure with override go
F.设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。
G.下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告：数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H.验证数据库一致性(可省略)
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I.设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦！
J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server EntERPrise Manager里面恢复，也可以使用如下语句完成。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
sp_configure 'allow updates',0 go reconfigure with override go
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，但是会出现类似下面的提示信息。
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息服务器：消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢?别着急，下面我们举例说明恢复办法。
A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server EntERPrise Manager里面建立。
B.停掉数据库服务器。
C.将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E.设置数据库允许直接操作系统表。此操作可以在SQL Server EntERPrise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
use master go sp_configure 'allow updates',1 go reconfigure with override go
F.设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。
G.下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告：数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H.验证数据库一致性(可省略)
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I.设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦！
J.最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server EntERPrise Manager里面恢复，也可以使用如下语句完成。
Word-WRAP: break-Word" bgColor=#f3f3f3>以下是引用片段：
sp_configure 'allow updates',0 go reconfigure with override go
#4
恢复MDF存在LDF不存在的数据库
问题原因：
MDF文件保存完好（已拷出来），LDF已丢失。使用：
EXEC sp_attach_single_file_db @dbname = 'TyBusiness',
@physname = 'E:\Help\TyBusiness.MDF'
报如下错误：
未能打开新数据库 'TyBusiness'。CREATE DATABASE 将终止。
设备激活错误。物理文件名
'd:\Program Files\Microsoft SQL Server\MSSQL\TyBusiness_log.ldf' 可能有误。
解决办法：
1、先建一个与你要恢复的数据库名称一样的数据库。
2、停止sql server，把你的数据库替换这个数据库。
3、重起sql server，把数据库设成紧急状态（在查询分析器里面进行）：
sp_configure 'allow',1
reconfigure with override
update sysdatabases set status=32768 where name='yourdata'
4、重建日志文件
dbcc rebuild_log('yourdata','your data path\newdata_log.ldf')
5、取消紧急模式
update sysdatabases set status=0 where name='yourdata'
restore sysdatabases yourdata with recovery
sp_configure 'allow',0
reconfigure with override
6、重起sql server
7、OK！
#5
jia_guijun提的
RESTORE DATABASE [DBName] WITH RECOVERY
我试了，提示只能对ONLINE的数据库进行这样的操作
而我的数据库是先设置了emergency，然后设置了单用户模式的
我尝试了把它设置为ONLINE，但系统提示文件不可用，然后也是同样的一致性错误，页撕裂
lg3605119 ，HEROWANG 贴的都是SQL 2000下的方法
而SQL 2005的一般方法我在提问中已贴出，
只是在遇到这个有问题的MDF恢复时，走不下去，所以向大家请教
RESTORE DATABASE [DBName] WITH RECOVERY
我试了，提示只能对ONLINE的数据库进行这样的操作
而我的数据库是先设置了emergency，然后设置了单用户模式的
我尝试了把它设置为ONLINE，但系统提示文件不可用，然后也是同样的一致性错误，页撕裂
lg3605119 ，HEROWANG 贴的都是SQL 2000下的方法
而SQL 2005的一般方法我在提问中已贴出，
只是在遇到这个有问题的MDF恢复时，走不下去，所以向大家请教
#6
更改为MULTI_USER用户模式再试。
USE Master
GO
RESTORE DATABASE [DBName] WITH RECOVERY
#7
回jia_guijun
无论是单用户模式，还是多用户模式，提示都是一样的
RESTORE语句在当前上下文中无效，仅当数据库处于联机状态时，才为辅助文件组定义为RECOVER DATA ONLY选项，
当数据库处于离线状态时，不能指定文件组，RESTORE DATABASE异常终止
无论是单用户模式，还是多用户模式，提示都是一样的
RESTORE语句在当前上下文中无效，仅当数据库处于联机状态时，才为辅助文件组定义为RECOVER DATA ONLY选项，
当数据库处于离线状态时，不能指定文件组，RESTORE DATABASE异常终止
#8
该回复于2012-07-11 08:53:12被版主删除
#9
尽一切可能最好备份。祝楼主好运！
#10
该回复于2012-07-11 08:53:18被版主删除
#11
想請問下樓主這個mdf檔有多大，數據機密碼？我一直想找這個樣的MDF試一下，都沒有碰到，自己也不知道要怎麼制造出來。如果不大數據又不機密的話，可否寄給我試試？
#12
建一个同名的数据库,
detach
用MDF覆盖新的数据库文件,
attach
detach
用MDF覆盖新的数据库文件,
attach
#13
xiao_hn 数据满大的，有些敏感数据，不太方便传给您，请见谅
#14
以前用下文成功恢复过，楼主可以try.
只有mdf文件的恢复技术
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库，
但是会出现类似下面的提示信息
设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。你也许会得到类似下面的错误信息
服务器: 消息 1813，级别 16，状态 2，行 1
未能打开新数据库 'test'。CREATE DATABASE 将终止。
设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
怎么办呢？别着急，下面我们举例说明恢复办法。
A．我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。
B．停掉数据库服务器。
C．将刚才生成的数据库的日志文件test_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
D．启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
E．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F．设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
G．下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1
未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。[brown][/i]
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
H．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'test' 中）。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
I．设置数据库为正常状态
sp_dboption 'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
#15
回perfectaction
谢谢。这个方式我试过，不行
谢谢。这个方式我试过，不行
#16
是否可远程看看？
#17
文件出问题了吧，上面的方法基本都可以解决了，检查数据文件结构是否正确。
#18
“且该MDF文件有一致性错误（在后来恢复中提示的，有页撕裂错误）” ,应该是PFS页的问题，2005对于损坏的页，可以跳过，如果在上述大虾们的处理步骤通不过，应该考虑是不是系统表出现损坏了。
#19
哎，莫非没有好办法了
#20
该回复于2012-07-11 08:53:35被版主删除
#21
该回复于2012-07-11 08:53:41被版主删除
#22
首先说问题描述，前后表达矛盾。一方面说“在后来恢复中提示的，有页撕裂错误”，一方面说“再要往下dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) 就提示数据库正在恢复中，没法进行下去了”
对于这个问题，我做了测试，大致分析如下:
1.lz第三步 alter database 数据库名 set emergency '--将数据库设置为紧急状态
这步执行后数据库状态已经是 emergency了，因为recovery pending状态下是不让你执行dbcc checkdb的，之所以lz误认为一直是recovery pending状态，大概都是在dbcc checkdb执行失败后查的吧，之所以最终还是recovery pending状态，是因为checkdb执行失败后sql server又将数据库状态重新置回了recovery pending了。
2.对于这个无法修复的情况，lz只能在emergency状态下多导点有用的数据出来吧。完全修复数据库是不大可能了。
对于这个问题，我做了测试，大致分析如下:
1.lz第三步 alter database 数据库名 set emergency '--将数据库设置为紧急状态
这步执行后数据库状态已经是 emergency了，因为recovery pending状态下是不让你执行dbcc checkdb的，之所以lz误认为一直是recovery pending状态，大概都是在dbcc checkdb执行失败后查的吧，之所以最终还是recovery pending状态，是因为checkdb执行失败后sql server又将数据库状态重新置回了recovery pending了。
2.对于这个无法修复的情况，lz只能在emergency状态下多导点有用的数据出来吧。完全修复数据库是不大可能了。
#23
实例Recovery出现recovery pending 一般是由于数据库文件不可用造成的。
可以通过dbcc checkprimaryfile ( 'mdf filename',3)
来查询主数据库文件中记录的每个文件的相关信息。
-------------------------------------------
QQ：1209667578 提供SQLServer数据库和优化服务！
可以通过dbcc checkprimaryfile ( 'mdf filename',3)
来查询主数据库文件中记录的每个文件的相关信息。
-------------------------------------------
QQ：1209667578 提供SQLServer数据库和优化服务！
#24
QQ：1209667578 提供SQLServer数据库修复和优化服务！
#25
该回复于2012-07-11 08:53:51被版主删除
#26
LZ， 没LDF？ 哪就是缺少日志文件了，只有数据。
#27
我顶。同时希望高手帮一帮解决掉。
#28
顶一下，今天也遇到这样的一个问题，解决不了，好多数据等着恢复呢，愁死了
#29
直接附加报什么错？
#30
该回复于2012-07-11 08:54:02被版主删除