Sql数据库MDF数据文件数据库恢复

EXEC sp_attach_db @dbname = 'dbname',
@filename1 = 'd:\dbname_Data.MDF',
@filename2 = 'd:\dbname_log.ldf' 

sp_attach_single_file_db @dbname = 'dbname'
  , @physname = 'physical_name'
  dbname:即要还原的数据库名字。
  Physname:即物理文件名。
  Physical_name:即.mdf文件路径。

数据库 : mssql server 2000 企业版
问题描述: 数据库置疑。数据库备份文件损坏。将数据库物理文件(*.mdf)拷贝出来 ,使用数据库附加功能,附加失败。
提示错误:
服务器: 消息 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 filesmicrosoft sql servermssqldatatest_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

 

时间: 2024-10-14 11:54:41

Sql数据库MDF数据文件数据库恢复的相关文章

oracle数据文件,恢复数据库问题

问题描述 oracle数据文件,恢复数据库问题 一直用的mysql,今天老板突然给我一个oracle的文件,说让我恢复oracle数据库,表示搞不定请教诸位.

oracel中只有rman全备,丢失conrol,redo,数据文件的恢复

本文为模拟测试,主要步骤如下: 1.对测试数据库进行rman全备(nocatalog 模式) 2.删除oradata\orcl目录下所有文件 3.使用rman进行恢复. 详细步骤如下: 1.对测试数据库进行rman全备 C:\Documents and Settings\xGss2000>rman nocatalog target / 恢复管理器: Release 10.2.0.1.0 - Production on 星期日 8月 14 00:06:16 2011 Copyright (c) 1

探索ORACLE之RMAN_07单个数据文件丢失恢复

探索ORACLE之RMAN_07单个数据文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com   备份的终极目的是为了更好的将数据恢复和还原过来,在前面的章节中我们已经重点谈完了RMAN的备份,实际上也穿插的谈了些复杂的完整恢复.当然在这节当中我们将会由浅入深的详细谈谈在几种不同情况下的数据库恢复. 1.     数据文件的丢失恢复 1.1    在wwl表空间上创建5张表,并添加数据. SQ

[20151023]linux下删除数据文件的恢复细节2

[20151023]linux下删除数据文件的恢复的一些细节问题(补充).txt --以前曾经写过一篇关于 --链接:http://blog.itpub.net/267265/viewspace-763969/ --里面提到实际上这种方式对于生产系统不是很合适,而且生产系统情况非常复杂,不可能出现删除数据文件时没有事务产生. --这种方式仅仅适合no archivelog的模式(没有办法的选择),我当时还提到这种方式一定要快,因为我的测试执行 alter system --checkpoint;

[20151028]linux下删除数据文件的恢复细节4

[20151028]linux下删除数据文件的恢复细节4 --前几天一直在做删除数据文件的恢复测试,中间遇到许多问题自己无法解决,从我个人讲我不主张使用句柄的方式来恢复,而更愿意 --使用rman的方式,这种情况仅仅适合非归档模式. --前几天的测试非常混乱,我自己都不知道为什么在删除数据文件的情况下有时候执行alter system checkpoint数据库会直接crash,有 --时候为什么有不会.我再把整个恢复过程做一个总结: 1.测试环境: SCOTT@test> @ &r/ver

[20130614]linux下删除数据文件的恢复的一些细节问题.txt

[20130614]linux下删除数据文件的恢复的一些细节问题.txt 前天看了链接:http://space.itpub.net/26015009/viewspace-763506 我仅仅做一些测试以及补充,以及注意的细节问题,实际上最好的方法依旧是使用rman备份恢复. 1.测试环境: --session 1 SQL> @ver BANNER --------------------------------------------------------------------------

【故障处理】DG环境主库丢失归档情况下数据文件的恢复

[故障处理]DG环境主库丢失归档情况下数据文件的恢复 1  BLOG文档结构图     2  前言部分   2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① BBED的编译 ② BBED修改文件头让其跳过归档从而可以ONLINE(重点) ③ OS命名格式转换为ASM的命名格式 ④ DG环境中备库丢失数据文件的情况下的处理过程(重点) ⑤ 数据文件OFFLINE后应立即做一次RECOVER操作 ⑥ BBED环境

[20151025]linux下删除数据文件的恢复细节3

[20151025]linux下删除数据文件的恢复细节3.txt --以前曾经写过一篇关于 --链接:http://blog.itpub.net/267265/viewspace-763969/ --里面提到实际上这种方式对于生产系统不是很合适,而且生产系统情况非常复杂,不可能出现删除数据文件时没有事务产生. --这种方式仅仅适合no archivelog的模式(没有办法的选择),我当时还提到这种方式一定要快,因为我的测试执行 alter system --checkpoint;,数据库直接cr

SQL SERVER 监控数据文件增长情况

   在项目前期评估数据库的增长情况,然后根据数据库数据量的增长情况来规划存储的分配其实是一件比较麻烦的事情.因为项目没有上线,用什么来评估数据库的数 据增长情况呢? 如果手头没有实际的数据,我们只能从表的数量以及预计一天的数据增长情况来预估数据增长量.当然这里猜测的成分较大.这个是非常不靠谱,也是不准确的.当 然我们可以监控测试环境的数据库大小的增长情况来评估数据增长情况.我们可以监控数据库大小的变化来估计生产环境的数据增长情况.当然生产环境和测试环境 的区别还是蛮大的.但是这样比那种瞎猜式的