use master
go
sp_attach_single_file_db 'db_NAME',
'D:\db_NAME.mdf' --PATH
go
(
http://technet.microsoft.com/zh-cn/library/ms174385.aspx SQL系统的存储过程支持。
将只有一个数据文件的数据库附加到当前服务器。sp_attach_single_file_db 不能用于多个数据文件。
重要提示 |
---|
后续版本的 Microsoft SQL Server 将删除该功能。请避免在新的开发工作中使用该功能,并着手修改当前还在使用该功能的应用程序。,我们建议您改用 CREATE DATABASE database_name FOR ATTACH。有关详细信息,请参阅CREATE DATABASE (Transact-SQL)。不要针对复制数据库使用此过程。 |
)
OR
CREATEDATABASE TestDB
ON
(
FILENAME ='D:\TestDB.mdf'
) for ATTACH_REBUILD_LOG
*
网上看到的整理了一下。
在SQL Server 7.0中,微软推出了sp_attach_db和sp_attach_single_file_db系统存储过程。
它对于SQL Server数据库管理员执行下面的任务是非常方便的:
1 使用sp_attach_db系统存储过程直接将.MDF和.LDF文件附加到服务器。
2 使用sp_attach_single_file_db系统存储过程只附加.MDF文件。
3 使用sp_detach_db将数据库从一个服务器分离,复制.MDF文件到另一个服务器上,然后使用
sp_attach_db系统存储过程重新附加这些文件到两个服务器上。
尽管它对于SQL Server数据库管理员是很有用的,但是在使用这两个存储过程时是有一些限制的。限制如下:
1 你不能附加多个日志文件
2 你不能附加16个以上的文件
在SQL Server 2008中,微软宣布上面的系统存储过程将在未来的版本中被废弃。而他们在"Create Database"
SQL语句中添加了一个从句"For Attach"。
下面介绍使用"For Attach"从句的多种方法,以克服在使用sp_attach_db和sp_attach_single_file_db时要面临的限制。
*/
--建立测试数据库
Use Master
go
CREATEDATABASE TestDB
ON
( NAME = TestDB,
FILENAME ='D:\TestDB.mdf',
SIZE =10,
MAXSIZE =50,
FILEGROWTH =5 )
LOGON
( NAME = TestDB_log,
FILENAME ='D:\TestDB_log.ldf',
SIZE = 5MB,
MAXSIZE = 25MB,
FILEGROWTH = 5MB )
GO
--现在,让我们分离该数据库,并尝试使用sp_detach_db和sp_attach_db将它重新附加。
--执行下面的事务SQL语句。
use master
go
sp_detach_db 'TestDB'
go
sp_attach_db 'TestDB',
'D:\TestDB.mdf',
'D:\TestDB_log.ldf'
GO
--你也可以使用具有"For Attach"从句的"Create database"命令附加上相同的数据库文件,如下所示。
use master
go
sp_detach_db 'TestDB'
go
CREATEDATABASE TestDB
ON
(FILENAME ='D:\TestDB.mdf'),
(FILENAME ='D:\TestDB_log.ldf')
for Attach
go
--现在,让我们分离数据库TestDB,然后删除.ldf文件,再然后使用sp_attach_single_file_db
--系统存储过程通过,执行下面的TSQL命令将它重新附加上。
use master
go
sp_detach_db 'TestDB'
go
exec master..xp_cmdshell 'del "D:\TestDB_log.ldf"'
go
--你可以使用下面的事务SQL语句来激活xp_cmdshell。
use master
go
sp_configure 'show advanced options',1
go
reconfigurewith override
go
sp_configure 'xp_cmdshell',1
go
reconfigurewith override
go
--或者,你可以在MS-DOS命令提示符中使用Windows资源管理器的"Del"命令来删除.ldf文件。
--现在,让我们只使用sp_attach_single_file_db来附加.MDF文件。执行下面所示的命令。
use master
go
sp_attach_single_file_db 'TestDB',
'D:\TestDB.mdf'
go
--你可以只通过使用带有"For ATTACH_REBUILD_LOG"从句的"Create database"命令来附加
--相同的数据库.MDF文件,如下所示。
use master
go
sp_detach_db 'TestDB'
go
exec master..xp_cmdshell 'del "D:\TestDB_log.ldf"'
go
--注意:当日志文件被重新创建时,SQL Server自动对日志文件名称添加后缀"_log"。
CREATEDATABASE TestDB
ON
(
FILENAME ='D:\TestDB.mdf'
) for ATTACH_REBUILD_LOG
--本文介绍了带有"For Attach"和"for ATTACH_REBUILD_LOG"用于一个单独的.MDF文件和一个单独的.
--LDF文件的"Create Database"语句的使用。
SQL2005 如何在没有日志文件的情况下如何恢复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’ —将目标数据库置为单用户状态
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N’single‘, N’false’—将目标数据库置为多用户状态
执行出现“数据库其他多个文件与数据库主文件不匹配….”错误,再执行一次即可。
以上是2005以上的使用方法
SQL 2003以下的方法有
在需要进行SQL Server恢复的时候,如果当时仅仅备份了mdf文件,那么还能不能恢复数据库呢?答案是肯定的,下面就教您
只有mdf文件的SQL Server恢复方法,供您参考。
如果您的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.我们使用默认方式建立一个供SQL Server恢复使用的数据库(如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
g