分析及处理：
1、新建数据库ufdata
2、停止sql服务，删除新建的mdf和ldf文件，将备份的mdf和ldf文件拷贝到该路径下，再启动sql服务，此时2005年度为置疑状态；
3、ufdata数据库置疑，可尝试对数据库进行分离、附加操作；
数据库分离、附加脚本示例如下：
分离 pubs 数据库，并将 skipchecks 设为 true。
EXEC sp_detach_db 'ufdata’, 'true’
下面的示例将 pubs 中的两个文件附加到当前服务器。
EXEC sp_attach_db @dbname = N’ufdata’,
@filename1 = N’F:/Ufdata/852/zt001/2005/UFData.mdf’,
@filename2 = N’F:/Ufdata/852/zt001/2005/UFData.ldf’
执行时错误提示如下
服务器: 消息 3624，级别 20，状态 1，行 1
Location: recovery.c:2440
Expression: seenCkptEnd
SPID: 52
Process ID: 2908
连接中断
存在2种可能，1是mdf物理文件损坏，无法修复；2是ldf日志文件损坏，可尝试重建数据库日志来进行数据库附加、修复；
4、操作时，上述步骤3可不需进行了！
停止sql服务，删除ldf文件，再重启sql服务；
5、设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure 'allow updates’,1
go
reconfigure with override
go
6、设置ufdata为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('ufdata’)
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读/置疑/脱机/紧急模式”可以看到数据库里面的表，但是仅仅有系统表;
7、下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('ufdata_001_2005′,’F:/Ufdata/852/ZT001/2005/ufdata.ldf’)
正确执行完成的提示应该类似于：
警告: 数据库’ufdata’的日志已重建。已失去事务的一致性。应运行DBCC CHECKDB以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
8、设置数据库为正常状态
sp_dboption 'ufdata’,’dbo use only’,’false’
9、要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates’,0
go
reconfigure with override
go
10、此时ufdata数据库已恢复正常，然后进行数据库修复检查工作！
置单用户模式
sp_dboption @dbname = 'ufdata’
, @optname = 'single user’
, @optvalue = 'true’
use ufdata
go
检查、修复
DBCC CHECKDB
( 'ufdata’,REPAIR_ALLOW_DATA_LOSS)
go
如果修复结果提示有错，需反复执行修复数据库语句，直到错误数为0或错误数不再变化为止。执行修复语句后必须将数据库还原为非单用户模式。
还原为非单用户模式
sp_dboption @dbname = 'ufdata’
, @optname = 'single user’
, @optvalue = 'false’
use ufdata
go
此时修复工作完成。
联系客服
