判断这个不知道看看下面这个，是否对你有用将sql server 2005服务以单用户模式启动. cmd下,cd到sql server 2005的sqlservr.exe所在的binn目录下. 然后执行 sqlservr.exe -m 单用户模式启动sql server 2005.在cmd模式下, 执行sqlcmd -E -A 命令,通过-A参数,使用DAC登录到SQL SERVER 2005.然后use 命令切换当前数据库为目标数据库.
你咋知道是数据文件损坏的， 你执行了: dbcc traceon(3604) go dbcc checkdb(your_db_name) go 语句了？
That's the way. I used that methods many times to recover databases. Don't attempt to repair a damaged database. It will always get you into more trouble than it's worth.
1. DBCC CHECKDB
重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。
use master
declare @databasename varchar(255)
set @databasename='需要修复的数据库实体的名称'
exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态 然后执行 DBCC CHECKDB('需要修复的数据库实体的名称') 检查数据库是否仍旧存在错误。注意：修复后可能会造成部分数据的丢失。 2. DBCC CHECKTABLE
如果DBCC CHECKDB 检查仍旧存在错误，可以使用DBCC CHECKTABLE来修复。
use 需要修复的数据库实体的名称
declare @dbname varchar(255)
set @dbname='需要修复的数据库实体的名称'
exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修复的数据表的名称',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修复的数据表的名称',REPAIR_REBUILD)
------把’ 需要修复的数据表的名称’更改为执行DBCC CHECKDB时报错的数据表的名称
exec sp_dboption @dbname,'single user','false' 3. 其他的一些常用的修复命令
DBCC DBREINDEX 重建指定数据库中表的一个或多个索引
用法：DBCC DBREINDEX (表名,’’) 修复此表所有的索引。 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ SQL SERVER数据库的检测及修复方法
随着K/3产品的推广，要求客户服务人员对SQL SERVER数据库的了解也进一步提高。在K/3的使用过程中，数据库文件被频繁地使用，由于某些原因，数据库有可能被损坏，本文将针对这种情况的数据库检测及修复方法做一简单讲解。希望各位在实际工作过程中有新的发现时，及时给我们提供信息，以便做进一步的更新。
1.1 SQL SERVER数据库的检测
SQL SERVER提供了数据库检测的命令，可用DBCC CHECKDB对数据库中各个对象的分配及结构的正确性进行检测，并可通过一参数控制，将所有的错误信息显示出来。其语法如下：
DBCC CHECKDB
('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
}]
) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
参数说明：
'database_name'代表被检测的数据库实体名；
NOINDEX指非系统表的非聚族索引不检测；
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修复发现的错误，其中REPAIR_ALLOW_DATA_LOSS代表，若此错误不能修复时，系统将直接删除相关数据。带此三个参数的任一个时，数据库必须处于单用户模式，可在Enterprise Manager中的数据库属性中设置；
ALL_ERRORMSGS代表将检测到的错误信息全部显示出来，否则，对于每张表最多只显示200条错误信息；
NO_INFOMSGS代表隐藏所有的信息及占用空间的报告。
经过检测，对于错误的对象，将以OBJECT ID的形式报告具体出错的信息，可根据OBJECT ID到系统表sysobjects中查找到相关的表，即NAME。 1.2 SQL SERVER问题数据库的修复
经过数据库检测后，可针对出现的问题采取相应的措施进行处理。如通过检测后，发现对象的物理存放存在问题，可用DBCC CHECKALLOC来进行修复：
DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
若是非系统对象的索引出错，则可用DBCC DBREINDEX进行修复：
DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS]
以上两种情况，也可直接使用DBCC CHECKDB(‘db_name’,repair_rebuild)来修复。
另外一种情况是在进行检测时，提示无法建立数据连接，此时表明，数据库已损坏。对于这种情况，我们可采取如下措施来尝试修复。
首先，在SQL Enterprise中新建一数据库（如数据库名为test）,建好数据库后，停止SQL Server Service Manager，并将客户数据库的MDF文件更名为test _data.mdf(即新建数据库的主文件名)，然后用更名后的文件覆盖新建数据库同名文件，接着，启动SQL Server Service Manager。对Master数据库将系统表设置为可更改状态
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
将数据库设为紧急状态：
update sysdatabases set status = 32768 where database '
停止并重新启动SQL Server Service Manager，并重建Log文件：
DBCC TRACEON (3604)
DBCC REBUILD_LOG(' test ','test _log_ldf')
将数据库设置为单用户模式，然后进行检测：
sp_dboption ' test ', 'single user', 'true'
DBCC CHECKDB(' test ')
Go
此数据库执行CHECKDB的过程中发现一些表的索引被破坏，于是针对具体的表进行重建索引的操作：
DBCC DBREINDEX（表名）
如执行以上操作仍然不能解决，若索引破坏的表是临时表或不是关键表，则可从新建账套中引入，若是主表，则可能通过近期的备份来（部份）恢复。若没有一个备份，则无法修复。 1.3 SQL Server数据库为什么易损坏呢？
以下是微软提供的一些可能引起数据库损坏的原因及一些预防措施：
操作问题，包括冷起动机器、热拔硬盘、删除一些数据库文件；
硬件问题，包括磁盘控制器的问题；
操作系统问题，包括与系统相关的一些致命错误。 1.4 预防措施：
1、定期/不定期执行CHKDSK(不带参数)，以检测硬盘物理结构并修复一些CHKDSK报告的问题；
2、常备份数据。 1.5 应用数据库修复举例
declare @databasename varchar(255)
set @databasename='AIS20021224170730'------一定要手工输入
---------执行一般性修复还存在问题时,进行允许数据丢失的修复
---------许数据丢失的修复要求在单用户下进行,此时请退出中间层,客户端,sql的其他模块
---所有功能退出,在查询分析器master里设置数据库为单用户 exec sp_dboption @databasename, N'single', N'true' -----在查询分析器master里,进行修复数据库
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
------还原数据库状态
exec sp_dboption @databasename, N'single', N'false'
第2章数据库日志损坏的修复
请遵照如下步骤来试图重建数据库事务日志. 注意: 由于事务日志丢失, 数据库可能有没有提交的数据. 注:都要替换成真实的数据库名字 2.1 步骤1: 创建一个新的数据库,命名为原来数据库的名字. 2.2步骤2: 停止SQL Server 2.3步骤3: 把老数据库的MDF文件替换新数据库的相应的MDF文件, 并把LDF文件删除 2.4步骤4: 重新启动SQL Server 服务,然后运行如下命令: Use Master Go sp_configure 'allow updates', 1 reconfigure with override Go begin tran update sysdatabases set status = 32768 where db_name' -- Verify one row is updated before committing commit tran 2.5步骤5: 停止SQL然后重新启动SQL Server 服务,然后运行如下命令: DBCC TRACEON (3604) DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF') Go 2.6步骤6: 停止SQL然后重新启动SQL Server 服务,然后运行: use master update sysdatabases set status = 8 where
Go sp_configure 'allow updates', 0 reconfigure with override Go 2.7步骤7:
运行dbcc checkdb(db_name)检查数据库的完整性. 第3章 数据库质疑的一般处理
1、执行如下SQL（打开修改系统表的开关）：
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
2、修改数据库Master中的表：sysdatabases
将 status字段数值更改为4
3、再执行如下SQL：
EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE。
--1． 恢复步骤：
--a.将smlog_log.ldf文件备份到其它目录下；
--b.将源目录下的smlog_log.ldf文件改名为smlog_log_bak.ldf；
--c.执行以下语句修改数据库的状态：
use Master
go
update sysdatabases set status=32768 where name='数据库名称' --修改状态,設為緊急狀態
go
shutdown with nowait --停止数据库服务器
go
--d.退出SQL并在(COMMAND)命令行模式中通过下面的代码重新启动SQL：
sqlservr -c -T3608 -T4022 --安全模式启动SQL SERVER
--e.在查询分析器中执行以下语句来查看刚刚修改过状态的数据库状态：
select Name,Status from sysdatabases where Name='数据库名稱'
--f.执行以下代码新建日志文件：
dbcc traceon(3604)--跟踪
dbcc rebuild_log('数据库名称','日志文件全路徑') --文件名要有全路径和扩展名
--dbcc rebuild_log('prs_msc','d:\mscsql\mssql\data\prs_msc_log.ldf
--g.将数据库置回正常状态：
update sysdatabases set status=0 where name='数据库名称'
--h.重新启动数据库后执行以下语句检查数据库：
DBCC CHECKDB --如果执行完有错误用以下语句修复
--i.要修复数据库必需将数据库改为单用户模式：
Exce sp_dboption '数据库名称','single user','true'---('false'恢复多用户)
--j.执行以下语句修复数据库：
DBCC CHECKDB('数据库名称',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS：是比较高级的修复方式
REPAIR_FAST：是简单快速的修复方式
/*
處理状态就为"置疑"的數據庫
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Go
sp_dboption '置疑的数据库名','single user','true'
Go
DBCC CHECKDB('置疑的数据库名')
Go
update sysdatabases set status=28 where name='置疑的数据库名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的数据库名', 'single user','false'
Go /*
只有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 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在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
--日志文件出现问题（丢失或文件格式非法），怎么使数据库恢复正常
--如果用sp_attach_single_file 'TEST','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.mdf'失败则需要用下列步骤完成
--1.将置疑的数据库分离，将mdf文件移走或改名！
sp_detach_db 'TEST'
--2.重新在原来目录下建立同名的数据库TEST
--3.停掉SQL Service,将先前的mdf文件拷贝回来覆盖(或改名),删除原来的log文件(或改名)
--4.启动SQL Service(否则下面的语句没办法运行)
--5.将数据库设成紧急模式(status=32768)
sp_configure 'allow updates',1
reconfigure with override
update sysdatabases set status=32768 where name='TEST'
--重新建立日志文件
DBCC traceon(3604)
dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
Go
--6.重新启动SQL Service
--7.将数据库设置成单用户模式(下面三个语句均可)
--sp_dboption 'TEST','single user','true'
update sysdatabases set status=4096 where name='TEST'
--alter database TEST set Single_user
--8.检查数据库的完整性和一致性,OK了就可以用了
DBCC CheckDB(TEST)
--9.将数据的访问权限设置成多用户模式
sp_dboption 'TEST','single user','false'
--或alter database TEST set multi_user
--10.关闭高级选项
sp_configure 'allow updates',0
reconfigure with override --结束 本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/htl258/archive/2009/04/30/4136908.aspx
cmd下,cd到sql server 2005的sqlservr.exe所在的binn目录下.
然后执行
sqlservr.exe -m
单用户模式启动sql server 2005.在cmd模式下,
执行sqlcmd -E -A
命令,通过-A参数,使用DAC登录到SQL SERVER 2005.然后use 命令切换当前数据库为目标数据库.
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
2. 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。
3. 用原有的.mdf和.ldf文件覆盖新建数据库对应的.mdf和.ldf文件。
4. 重新启动SQL Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。
5. 在SQL查询分析器中执行以下命令，以允许更新系统表：
use mastergosp_configure ‘allow updates’,1
reconfigure with override
go
6. 将这个数据库置为紧急模式：
update sysdatabases set status = 32768 where name = ‘db_name’
go
7. 使用DBCC CHECKDB命令检查数据库中的错误：
DBCC CHECKDB(‘db_name’)
GO
8. 如果DBCC CHECKDB命令失败，请转至第10步，否则先将数据库置为单用户模式，再尝试对其进行修复：
sp_dboption ‘db_name’,’single user’,’true’
DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)
GO
如果在执行
DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)
命令时提示说数据库未处于单用户模式状态的话，则重新启动SQL Server服务，然后继续尝试。
9. 如果DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)命令失败，请转至第10步，
否则若成功修复了数据库中的错误：
重新执行DBCC CHECKDB(‘db_name’)命令，确认数据库中已没有错误存在。
清除数据库的置疑状态：sp_resetstatus ‘db_name’
清除数据库的单用户模式状态：sp_dboption ‘db_name’,’single user’,’false’
重新启动SQL Server服务，如果一切正常的话，则数据库已经成功恢复。 10. 如果以上步骤都不能解决问题的话，请参考附件中的文档尝试通过重建事务日志来恢复数据库中的数据。如果您只有MDF文件，问题就更加复杂一些，我们需要直接重建事务日志了:
1. 在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。
2. 用原有的ldf文件覆盖新建数据库对应的.mdf文件，将其日志文件（.ldf）删除。
3. 启动SQL Server服务，并将数据库置为紧急模式（同上: 步骤5和步骤6）。
4. 停止并重新启动SQL Server服务。
5. 执行以下命令重建数据库日志文件：(下面是个示例，您要用您实际的数据库名)
DBCC REBUILD_LOG（’cas_db’, ‘D:\cas_db\cas_db_Log.LDF’）
6. 重新将该数据库置为单用户模式。
7. 再次尝试使用DBCC CHECKTABLE或DBCC CHECKDB命令检查并修复数据库中的错误--1，先停止服务器，然后备份tigerzz_Data.mdf和tigerzz_Log.ldf文件。
--2，启动服务器，然后删除数据库tigerzz。
--3，建立一个供恢复使用的数据库tigerzz。
--4，停止数据库服务器。
--5，将刚才生成的数据库的日志文件tigerzz_Log.ldf删除，用要恢复的数据库tigerzz_Data.mdf文件
-- 覆盖刚才生成的数据库数据文件tigerzz_Data.mdf。
--6, 启动数据库服务器。此时数据库tigerzz的状态为“置疑”。
--7，在查询分析器运行下面代码，允许对系统目录修改
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--8，设置数据库tigerzz为紧急修复模式
update sysdatabases set status = 32768 where name ='tigerzz' go
--9，重建数据库日志文件
dbcc rebuild_log('tigerzz','E:\Program Files\Microsoft SQL Server\MSSQL\Data\tigerzz_Log') --改为你的目录
go
--10，验证数据库一致性
DBCC CHECKDB('tigerzz') go
--11，恢复数据库为正常状态
sp_dboption 'tigerzz','dbo use only','false'
go
--12，禁止修改系统选项
sp_configure 'allow updates',0
go
reconfigure with override
go
你咋知道是数据文件损坏的， 你执行了:
dbcc traceon(3604)
go
dbcc checkdb(your_db_name)
go
语句了？
That's the way. I used that methods many times to recover databases. Don't attempt to repair a damaged database. It will always get you into more trouble than it's worth.