数据库分离后怎么恢复 数据库恢复工具
各位老铁们，大家好，今天由我来为大家分享数据库分离后怎么恢复，以及数据库恢复工具的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
SQL server 数据库分离后在哪可以找到
在你SQL
server安装路径的实例名文件夹下面的DATA文件夹中，比如我的就是在C:\Program
Files\Microsoft
SQL
Server\MSSQL10.MSSQL_SERVER\MSSQL\DATA中，能找到对应的*.mdf文件，其中MSSQL10.MSSQL_SERVER是以实例名命名的文件夹，我用的SQL
server2008默认名字就叫这个，如果你改过了就是你起的那个名字。
另外你分离以后才可以移动你的*.mdf文件，否则会报错，因为正在使用。
希望采纳！
sql2005备份数据库怎么恢复
数据库数据恢复步骤
1、通过日志恢复SQLSERVER2005数据(也可通过LogExplorer工具查找进行恢复数据)
(A)......通过日志和时间点来恢复数据的前提条件：数据库的故障恢复改为非简单模式，去掉自动关闭和自动收缩两个选项，如果是简单模式：类似下面的语句操作数据就不会记录到日志中：select*intotfrom[表名].【采用LogExplorer工具可以在线操作，通过恢复日志（指定时间点恢复）来恢复数据，必须停止数据库或者再另一个数据库恢复（前提是必须有一个完全备份和日志备份）】
这时为保证数据的完整要将数据库的恢复模式改成“完整.
1.1、这时对数据库事务日志做备份（注意，如果没做个数据库完整备份，是不能做事务日志备份的）
这时新建一个数据库zp（将以前的数据库改名），恢复数据库
这时我们看到，有两个还原的数据库备份，因为我对zp数据库备份了两次，两次的备份的数据文件都一样。这里我们选择最近时间的备份默认在数据库的设置如下：是追加到备份集里，所以会有两个备份。
同时，在”选项“里设置”不回滚“事务，
注意：通过事务日志还原数据库，必须选择"不回滚"事务
确定后：出现下面情况：
这时发现，数据库一直是”正在还原“，这时还原数据库事务日志，
1.2、“常规”里选择时间，（刚删除的时间）
1.3、“选项”里将恢复状态设置为”回滚未提交“事务
确定后，查询数据库，发现数据回来了.
2、无日志的数据恢复
2.1.新建一个同名的数据库
2.2再停掉sqlserver(注意不要分离数据库)
2.3用原数据库的数据文件覆盖掉这个新建的数据库
2.4再重启sqlserver
2.5此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
2.6完成后一般就可以访问数据库中的数据了，这时，数据库本身一般还要问题，解决办法是，利用
数据库的脚本创建一个新的数据库，并将数据导进去就行了.
USEMASTER
SP_CONFIGURE'ALLOWUPDATES'，1RECONFIGUREWITHOVERRIDE
UPDATESYSDATABASESSETSTATUS=32768WHERENAME='数据库名'
sp_dboption'数据库名'，'singleuser'，'true'
DBCCCHECKDB('数据库名')
updatesysdatabasessetstatus=28wherename='数据库名'
sp_configure'allowupdates'，0reconfigurewithoverride
sp_dboption'数据库名'，'singleuser'，'false'
数据库出现置疑了怎么恢复
备份数据文件,然后按下面的步骤处理:
1.新建一个同名的数据库(数据文件与原来的要一致)
2.再停掉sql server(注意不要分离数据库)
3.用原数据库的数据文件覆盖掉这个新建的数据库
4.再重启sql server
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)
6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用
数据库的脚本创建一个新的数据库,并将数据导进去就行了.
USE MASTER
GO
SP_CONFIGURE'ALLOW UPDATES',1 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 reconfigure with override
Go
sp_dboption'置疑的数据库名','single user','false
假设数据库为TEST：
按以下步骤执行
A．设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
use master
go
sp_configure'allow updates',1
go
reconfigure with override
go
B．设置test为紧急修复模式
update sysdatabases set status=-32768 where dbid=DB_ID('test')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
C．下面执行真正的恢复操作，重建数据库日志文件
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使用”。此时可以访问数据库里面的用户表了。
D．验证数据库一致性（可省略）
dbcc checkdb('test')
一般执行结果如下：
CHECKDB发现了 0个分配错误和 0个一致性错误（在数据库'test'中）。
DBCC执行完毕。如果 DBCC输出了错误信息，请与系统管理员联系。
E．设置数据库为正常状态
sp_dboption'test','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
F．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure'allow updates',0
go
reconfigure with override
go
上面的语句操作步骤有点问题：
应该如下：
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
好了，本文到此结束，如果可以帮助到大家，还望关注本站哦！