凑合修mdf

新建一个数据库 要求mdf ldf文件要和以前的名字一样，地址最好也一样 选项的CHECKPAGE改为NONE
停掉数据库服务，用原来的MDF文件覆盖这个新的mdf
试运行
EXEC sp_attach_single_file_db @dbname = '库名',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\库名.mdf'
“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 use mastergosp_configure ‘allow updates‘,1goreconfigure with overridego
　　设置MHDYF2005为紧急修复模式，语句如下： update sysdatabases set status=-32768 where dbid=DB_ID(‘MHDYF2005‘)
　　此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。
　　下面执行真正的恢复操作，重建数据库日志文件 dbcc rebuild_log(‘MHDYF2005‘,‘C:\Program Files\Microsoft SQL Server\MSSQL\Data\MHDYF2005_log.ldf‘)

以下关键的
use master
declare @databasename varchar(255)
set @databasename='vtdata'         ---你的.mdf文件文件名
exec sp_dboption @databasename, N'single', N'true' ---将目标数据库置为单用户状态
alter database vst set emergency --将AKS_PM 数据库设为紧急模式。dbcc checkdb(N'vst',REPAIR_ALLOW_DATA_LOSS) --检查数据库 （具备修复)dbcc checkdb(N'vst',REPAIR_REBUILD) exec sp_dboption N'vst', N'single', N'false'--将目标数据库置为多用户状态
会报LDF文件有误或别的什么权限的问题 多按F5运行几次兴许就可以进行运行了

-----------------------------------------------------------------

．我们使用默认方式建立一个供恢复使用的数据库(如MHDYF2005)。可以在SQL Server里面建立。

　　2．停掉数据库服务器。

　　3．将刚才生成的数据库的日志文件MHDYF2005_log.ldf删除，用要恢复的数据库mdf（yu1.mdf）文件覆盖刚才生成的数据库数据文件MHDYF2005_data.mdf。

　　4．启动数据库服务器。（刷新之后）此时会看到数据库MHDYF2005的状态为“置疑”。这时候不要对此数据库进行任何操作。

　　5．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。 use mastergosp_configure ‘allow updates‘,1goreconfigure with overridego

　　6．设置MHDYF2005为紧急修复模式，语句如下： update sysdatabases set status=-32768 where dbid=DB_ID(‘MHDYF2005‘)

　　此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表。

　　7．下面执行真正的恢复操作，重建数据库日志文件 dbcc rebuild_log(‘MHDYF2005‘,‘C:\Program Files\Microsoft

　　SQL Server\MSSQL\Data\MHDYF2005_log.ldf‘)

　　执行过程中，如果遇到下列提示信息： 服务器: 消息 5030，级别 16，状态 1，行 1

　　未能排它地锁定数据库以执行该操作。

　　DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了MHDYF2005库的系统表，那么退出SQL Server Enterprise Manager就可以了。

　　正确执行完成的提示应该类似于：

　　警告: 数据库 ‘MHDYF2005‘ 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。

　　8．验证数据库一致性（可省略），语句如下： dbcc checkdb(‘MHDYF2005‘)

　　一般执行结果如下：CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 ‘MHDYF2005‘ 中）。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

　　9．设置数据库为正常状态，语句如下： sp_dboption ‘MHDYF2005‘,‘dbo use only‘,‘false‘

　　如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。

　　10．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成： sp_configure ‘allow updates‘,0goreconfigure with overridego

alter database 你的.mdf文件名 set emergency '--将数据库设置为紧急状态
use master
declare @databasename varchar(255)
set @databasename='你的.mdf文件名'         '--你的.mdf文件文件名
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'--将目标数据库置为多用户状态

不过这些资料不是一点用都没有，从中我还是悟出了一定的道理，经过几番试验以后，通过下面的方法终于把这个千疮百孔的数据库修好了。

1.       在SQL Server Management Studio中随便创建一个数据库，例如：PVLink。

2.       停止SQL Server服务。

如果不停止此服务，刚才创建的PVLink数据库将即不能被拷贝，也不能被覆盖。

3.       把已经损坏的数据库的mdf文件拷贝并覆盖刚才新建的数据库产生的mdf文件。

4.       启动SQL Server服务。

此时可以看见刚才创建的PVLink数据库名字后面没有加号，无法察看其任何信息，其实目前它已经处于无法使用的状态。

5.       把数据库设置为紧急状态。

通过在“查询分析器”中执行：alter database PVLink set EMERGENCY 可以将数据库设置为紧急状态，此时数据库PVLink的图标改变成粉红色并出现“紧急”字样。

6.       将数据库设置为单用户模式。

如果不设置为单用户模式，我们将无法使用带有效repair选项的DBCC CHECKDB来检查/修复数据库，SQL Server 2005设置单用户模式比SQL Server 2000容易，只要在“查询分析器”中执行：

use master

go

sp_dboption 'PVLink',single,true

即可。

7.       修复数据库

修复数据库主要使用DBCC来操作，一般来讲，我们可以使用以下三个选项来修复：

REPAIR_ALLOW_ DATA_LOSS

尝试修复报告的所有错误。这些修复可能会导致一些数据丢失。

REPAIR_FAST

仅为保持向后兼容性而保留。

REPAIR_REBUILD

执行由 REPAIR_FAST 执行的所有修复，包括需要较长时间的修复（如重建索引）。执行这些修复时不会有丢失数据的危险。

一般我们通过执行：DBCC CHECKDB('PVLink',REPAIR_REBUILD) 即可完成修复工作，此时 SQL Server 2005会给出很多提示，因为这个过程可能会导致一些数据库设计或者数据的丢失，并且在这个过程中，会产生新的以ldf为扩展名的数据库日志文件。

8.       完成以上的步骤后，一般情况下数据库应该可用了，如果数据库此时仍然是紧急状态，可以通过：alter database PVLink set ONLINE ，把数据库变成在线状态。

以上介绍的方法对于通过“附加”的方法无法恢复受到比较严重损坏的数据库比较有效，总的来看，SQL Server 2005给数据库管理和开发提供了更加有效实用的工具和方法。

以前看到网上经常会有人说不能修改MS SQL2005的系统表，我是用这种方法来修改的，不知道和你们说的是否是一个意思呢。

看看是否能解决你们的“不允许对系统目录进行即席更新”的问题。

select * from sysconfigures
select * from sysconfigures where config='1539'
--0 1539 maximum degree of parallelism 3
update sysconfigures set value='1' where config='1539'
--不允许对系统目录进行即席更新。

sp_configure
--allow updates 0 1 0 0
--show advanced options 0 1 1 1
--allow updates 0 1 1 1
EXEC sp_configure 'allow updates', '1'
--下面这句不需要执行，因为默认的是1
EXEC sp_configure 'show advanced option', '1'
--下面的这句要执行，否则它只有等到重启时才会生效
RECONFIGURE WITH OVERRIDE

EXEC sp_configure 'max degree of parallelism' ,'1'
RECONFIGURE WITH OVERRIDE

如果您的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

一次Project项目平台(PWA)意外停机且配置数据库SharePoint_Config 的LDF被意外删除,如果直接附加MDF文件则无法附加.

先尝试sp_attach_single_file_db恢复,执行如下:

sp_attach_single_file_db 'SharePoint_Config','D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data\SharePoint_Config.mdf'
出现错误提示:
文件激活失败。物理文件名称'D:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\SharePoint_Config_log.LDF'可能不正确。
由于数据库没有完全关闭，无法重新生成日志。
消息 1813，级别 16，状态 2，第 1 行
无法打开新数据库 'SharePoint_Config'。CREATE DATABASE 中止。

然后尝试如下步骤:
1、新建SharePoint_Config 数据库

2、停止SQL SERVER 2005，将原来的SharePoint_Config .mdf数据库文件覆盖刚新建的SharePoint_Config .mdf数据库文件，重新启动数据库,
此时数据库中的表不能正常读取。

3、将数据库设置为紧急状态：

alter database SharePoint_Config set emergency
此时数据处于紧急状态,库中的表可以读取
4、执行如下代码：

use master

declare @databasename varchar(255)

set @databasename='SharePoint_Config'         --设置变量为数据名

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'--将目标数据库置为多用户状态
数据库正常。