sql数据库修复,如何恢复修复MSSQL数据库的MDF文件

sql数据库修复,如何恢复修复MSSQL数据库的MDF文件详细介绍

本文目录一览： SQL数据库文件如何进行恢复

MS Sql Server数据库因其使用方便、易于操作的特点，是最为广泛是用的数据库类型之一，尤其是中小型企业及个人的首选。一般情况下，由于数据文件的破坏，造成数据库无法正常工作，症状现象通常是：在附加数据库时，出现错误代码823错误，在这种情况下，SQL数据库数据恢复显然是重中之重。一般而言，我们有三种最常见的方式方式恢复sql数据库。第一是手动找回。 这对懂电脑技术的人而言，可能是最为简单的一种方式，通常需要不到五分钟便可以搞定，但对于没有什么电脑基础的人来说，不要轻易去尝试，以免造成数据库数据的永久性删除丢失。第二采用相应的数据库修复软件进行恢复。这也是较为常见的一种方式。就是通过寻找一款适合的sql数据库恢复软件，通过这种软件的提示操作自己来完成整个数据库的找回，这种方式使用人群比较广泛一些。比如迅龙数据恢复软件，无敌数据恢复软件等等。第三通过专业的数据恢复公司找回。相对以上两种方式，这种方式花费比较贵，但是安全性最高。毕竟数据库丢失数据不比普通的文件删除，其中有着较大的利害关系。如果你遇到了上述问题，这个时候不妨来找上海天盾数据恢复中心解决问题！经过长期的实践，天盾数据恢复中心积累了宝贵的数据恢复经验。采用了上海天盾数据恢复机构最新的“无损恢复”程序，技术专家对服务器设备上丢失的文件进行深度的扫描，有95%的成功率能将之彻底还原。 除此还可提供服务器数据恢复，硬盘数据恢复，raid数据恢复，mac苹果数据恢复，二次开盘恢复等服务以及数码照片恢复软件，手机数据恢复软件等软件。SQL数据库文件如何进行恢复标签：

如何恢复修复MSSQL数据库的MDF文件

欢迎进入Windows社区论坛，与300万技术人员互动交流 >>进入 如果备份的数据库有2个文件，分别是.LDF 和 .MDF，打开企业管理器，在实例上右击---所有任务--附加数据库，然后选择那个.MDF文件，就可以了。 或者在查询分析器中输入： sp_attach_db "数据库名称" 欢迎进入Windows社区论坛，与300万技术人员互动交流 >>进入 如果备份的数据库有2个文件，分别是.LDF 和 .MDF，打开企业管理器，在实例上右击---所有任务--附加数据库，然后选择那个.MDF文件，就可以了。 或者在查询分析器中输入：sp_attach_db "数据库名称","路径\文件名.ldf","路径\文件名.MDF"SQL Server数据库备份有两种方式，一种是使用BACKUP DATABASE将数据库文件备份出去，另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式。下面将主要讨论一下后者的备份与恢复。本文假定您能熟练使用SQL Server Enterprise Manager(SQL Server企业管理器)和SQL Server Quwey Analyser(SQL Server查询分析器)1、正常的备份、恢复方式正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。卸下数据库的命令：Sp_detach_db 数据库名连接数据库的命令：Sp_attach_db或者sp_attach_single_file_dbs_attach_db [@dbname =] 'dbname', [@filename1 =] 'filename_n' [,...16]sp_attach_single_file_db [@dbname =] 'dbname', [@physname =] 'physical_name'使用此方法可以正确恢复SQL Sever7.0和SQL Server 2000的数据库文件，要点是备份的时候一定要将mdf和ldf两个文件都备份下来，mdf文件是数据库数据文件，ldf是数据库日志文件。例子：假设数据库为test，其数据文件为test_data.mdf，日志文件为test_log.ldf。下面我们讨论一下如何备份、恢复该数据库。卸下数据库：sp_detach_db 'test'连接数据库：sp_attach_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf'sp_attach_single_file_db 'test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_data.mdf'C++Builder 研究 - http://www.ccrun.com/article.asp?i=986&d=oxit072、只有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里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。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里面恢复，也可以使用如下语句完成

如何修复SQL数据库置疑

　　步骤如下：

　　停止SQL服务管理器，将原数据文件拷贝进行备份，然后将原数据库删除；启动SQLServer服务，创建一个新的数据库，命名为原来数据库的名字；停止SQLServer服务，用备份出来的老数据库的MDF文件替换新数据库相应的MDF文件，并把新数据库相应的LDF文件删除；重新启动SQLServer服务，然后运行命令；停止SQL然后重新启动SQLServer服务，然后运行命令；运行hbfsv8检查数据库的完整性；进行数据库修复；修复成功后，返回多用户模式。

如何恢复SQLServer2000损坏的数据库文件

SQL Server2000中，如果数据库文件（非系统数据库文件）遇到错误的时候，我们该怎么办。以下是笔者以前的笔记。仅适用于非master,msdb的数据库。说明如下：1 建一个测试数据库test(数据库类型为完全)2 建一个表，插入点记录create table a(c1 varchar(2))goinsert into a values('aa')goinsert into a values('bb')go3 作完全备份，到文件test_1.bak4 在作一点修改insert into a values('cc')gocreate table b(c1 int)goinsert into b values(1)goinsert into b values(2)go5 shutdown 数据库服务器6 用ultraedit编辑数据库文件test_data.mdf,随便修改点字节内容,相当于数据库遭到致命的损坏。7 启动数据库，并且运行企业管理器，点开数据库，看到test变成灰色，而且显示置疑。8 运行isql -SLocalhost -Usa -P1> backup log test TO DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKUP est_2.bak' WITH NO_TRUNCATE2>go已处理 2 页，这些页属于数据库 'test' 的文件 'TEST_Log'（位于文件 1 上）。BACKUP LOG 操作成功地处理了 2 页，花费了 0.111 秒（0.087 MB/秒）。9 进行恢复最老的完全备份1> RESTORE DATABASE test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKUP est_1.bak' WITH NORECOVERY2> go已处理 96 页，这些页属于数据库 'test' 的文件 'TEST_Data'（位于文件 1 上）。已处理 1 页，这些页属于数据库 'test' 的文件 'TEST_Log'（位于文件 1 上）。RESTORE DATABASE 操作成功地处理了 97 页，花费了 0.107 秒（7.368 MB/秒）。10 恢复最近的日志1> RESTORE LOG test FROM DISK='D:Program FilesMicrosoft SQL ServerMSSQLBACKUP est_2.bak' WITH RECOVERY2> go已处理 2 页，这些页属于数据库 'test' 的文件 'TEST_Log'（位于文件 1 上）。RESTORE LOG 操作成功地处理了 2 页，花费了 0.056 秒（0.173 MB/秒）。数据已经完全恢复了，可以使用了。select * from ago总结，DBA应该有一个完善的数据库备份计划。本例中，如果没有一个完全备份的话，数据库的恢复就不可能 当sql server数据库崩溃时如何恢复？ 任何数据库系统都无法避免崩溃的状况，即使你使用了clustered，双机热备??仍然无法完全根除系统中的单点故障，何况对于大部分用户来说，无法承受这样昂贵的硬件投资。所以，在系统崩溃的时候，如何恢复原有的宝贵数据就成为一个极其重要的问题了。在恢复的时候，最理想的情况就是你的数据文件和日志文件都完好无损了，这样只需要sp_attach_db，把数据文件附加到新的数据库上即可，或者在停机的时候把所有数据文件(一定要有master等)都copy到原有路径下也行，不过一般不推荐这样的做法，sp_attach_db比较好，虽然麻烦许多。但是呢，一般数据库崩溃的时候系统是未必能有时间把未完成的事务和脏页等写入磁盘的，这样的情况sp_attach_db就会失败。那么，寄期望于dba制定了一个良好的灾难恢复计划吧。按照你的恢复计划，还原最新的完全备份，增量备份或者事务日志备份，然后如果你的活动事务日志还能读得出来的话，恭喜你！你可以还原到崩溃前的状态。一般的单位都是没有专职的dba的，如果没有可用的备份，更可能是最近一次备份的时间过于久远而导致不可接受的数据损失，而且你的活动事务日志也处于不可用的状态，那就是最麻烦的情况了。不幸的很的是，一般数据库崩溃都是由于存储子系统引起的，而这样的情况是几乎不可能有可用的日志用于恢复的。那么就只好试一下这些方案了。当然，是要求至少你的数据文件是存在的，要是数据文件、日志文件和备份都没有了的话，别找我，你可以到楼顶上去唱“神啊，救救我吧”。首先，你可以试一下sp_attach_single_file_db，试着恢复一下你的数据文件，虽然能恢复的可能性不大，不过假如这个数据库刚好执行了一个checkpoint的话，还是有可能成功的。如果你没有好到有摸彩票的手气，最重要的数据库没有像你期盼的那样attach上去，不要气馁，还是有别的方案的。我们可以试着重新建立一个log，先把数据库设置为emergency mode，sysdatabases的status为32768 就表示数据库处于此状态。不过系统表是不能随便改的，设置一下先use mastergosp_configure 'allow updates', 1reconfigure with overridego然后update sysdatabases set status = 32768 where name = ''现在，祈求满天神佛的保佑吧，重新建立一个log文件。成功的机会还是相当大的，系统一般都会认可你新建立的日志。如果没有报告什么错误，现在就可以松一口气了。虽然数据是恢复了，可是别以为事情就算完成了，正在进行的事务肯定是丢失了，原来的数据也可能受到一些损坏。先把sql server 重新启动一下，然后检查你的数据库吧。先设置成单用户模式，然后做dbccsp_dboption '', 'single user', 'true'dbcc checkdb('')如果没有什么大问题就可以把数据库状态改回去了，记得别忘了把系统表的修改选项关掉。update sysdatabases set status = 28 where name = '' --当然你的数据库状态可能不是这个，自己改为合适的值吧。也可以用sp_resetstatusgosp_configure 'allow updates', 0reconfigure with overridegocheckdb的时候可能报告有一些错误，这些错误的数据你可能就只好丢弃了。checkdb有几种修复选项，自己看着用吧，不过最后你可能还是得用repair_allow_data_loss，完成所有修复。chekcdb并不能完成所有的修复，我们需要更进一步的修复，用dbcc checktable对每一个表做检查吧。表的列表可以用sysobjects里面得到，把objectproperty是istable的全部找出来检查一下吧，这样能够基本上解决问题了，如果还报告错误，试着把数据select into到另一张表检查一下。这些都做完了之后，把所有索引、视图、存储过程、触发器等重新建立一下。dbcc dbreindex也许可以帮你一些忙。数据库日志文件丢失时的恢复步骤，描述我误删除了数据库的事务日志文件(.ldf)之后，如何经过各种尝试恢复数据库的。但是不少网友在处理“数据库置疑”的实践过程中，又产生了许多新的疑问。我还是总结一下出现的几种情况，以供参考。2.Zach的灵验脚本Zach说他每次遇到这种数据库置疑情况，就运行下面这个脚本，屡试不爽：======================================================--before running any script, run the following to set the master database to allow updatesUSE masterGOsp_configure 'allow updates', 1GORECONFIGURE WITH OVERRIDEGO--Run the following scriptUPDATE master..sysdatabases SET status = status ^ 256 WHERE name = 'Database_Name'--Run the following scriptexec SP_resetstatus Database_Name--stop and start the MSDTC at this stage--After the procedure is created, immediately disable updates to the system tables:exec sp_configure 'allow updates', 0GORECONFIGURE WITH OVERRIDEGO=====================================从上面可以看出，处理置疑的基本步骤还是我那篇文章中说的(注意我使用的字体颜色)：执行 sp_configure 以允许对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置；数据库重置紧急模式；执行sp_resetstatus关闭数据库的置疑标志，但是原封不动地保持数据库的其它选项（只有系统管理员才能执行）。执行该过程后，立即重启 SQL Server服务；执行 sp_configure 以禁止对系统表进行更新，然后用 RECONFIGURE WITH OVERRIDE 语句强制实施该配置。status ^ 256的意思就是：Constant Value DescriptionSQLDMODBStat_Suspect 256 Database integrity is suspect for the referenced database.不同的是，有时候丢失了数据库日志文件，额外需要以下步骤：? 把应用数据库设置为Single User模式；? 做DBCC CHECKDB；才可以。但是几位网友的实践结果就是这个DBCC CHECKDB执行失败。一位网友yang说：“但是 DBCC CHECKDB就是执行不了，总是说“该数据库处于回避恢复模式”。我已经试了很多次了，就是改变不了这个状态。”还有一位Rui执行DBCC CHECKDB时报错：“Server: Msg 943, Level 14, State 1, Line 1 Database 'his_yb' cannot be opened because its version (539) is later than the current server version (515).”对于Yang，可能他没有一步一步做，。我的切身体会是，把应用数据库设置为Single User模式后就可以做DBCC CHECKDB。之后呢，也许SQL Server重启后自动检查数据库是否正常。但是数据应该是可以读出来的，至少可以被DTS Wizard读出来的。这时候的数据库还存在问题，比如我的组件使用数据库时，报告说：“发生错误：-2147467259,未能在数据库 'XXX' 中运行 BEGIN TRANSACTION，因为该数据库处于回避恢复模式。”对于Rui，他碰到的那个错误Server: Msg 943, Level 14, State 1, Line 2Database 'XXXX' cannot be opened because its version (536) is later thanthe current server version (515).这表明Rui正试图：从一个SQL Server 2000(version 539,536之类的)的数据库备份恢复到一个SQL Server 7.0中或者把一个SQL Server 2000(version 539,536之类的)的数据库attach到一个SQL Server 7.0中，这是不允许的。如果你必须使用这个SQL Server 2000的数据备份，那么请您首先把这个备份倒入SQL Server 2000，最后用DTS把数据库从SQL Server 2000上transfer到SQL Server 7.0上。 您可能感兴趣的文章:修复断电等损坏的SQL 数据库快速修复损坏的MySQL数据库MySQL数据库INNODB表损坏修复处理过程分享mysql数据库索引损坏及修复经验分享master数据库损坏的解决办法有哪些

SQL恢复master数据库方法只有mdf文件的数据库如何恢复

首先先和大家讲一讲SQL Server恢复master数据库方法，具体步骤如下第一步：复制model.mdf、mastlog.ldf、model.mdf、modellog.ldf、msdbdata.mdf、msdblog.ldf文件。从X:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\Templates至X:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA注：以上“X:\Program Files\Microsoft SQL Server”为SQL Server的安装目录。以下的“C:\Program Files\Microsoft SQL Server”为系统盘下的目录第二步：定位并执行安装命令1. 首先找到安装命令：C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Release\setup.exe2. 执行命令如果只是Windows身份验证模式，只需要如下语法即可： 代码如下:setup /ACTION=REBUILDDATABASE /QUIET /INSTANCENAME=

/SQLSYSADMINACCOUNTS=

如果是复合身份验证模式，则需要使用/SAPWD参数提供sa的密码： 代码如下:setup /ACTION=REBUILDDATABASE /QUIET /INSTANCENAME=

/SQLSYSADMINACCOUNTS=

/SAPWD=

我安装时设置的是复合认证模式，SQL Server系统管理员帐号是administrators组，sa密码是123456。并且就一个默认实例：MSSQLSERVER。所以在命令行执行如下命令： 代码如下:setup /ACTION=REBUILDDATABASE /QUIET /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=administrators /SAPWD=123456第三步：执行完毕后没有任何提示信息（不管成功与否），但是可以马上在C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\Summary.txt中查看安装日志。最后，在Sql Server Configuration Manager中启动SQL Server服务成功。在处理过程中出现了这种情况SQL恢复数据库又该怎么办？只有mdf文件时,应当如何进行恢复，即有log文件的数据库如何恢复SQL恢复数据库具体实现步骤：1、新建一个同名数据库。2、停止数据库服务，覆盖新建的数据库主文件（小技巧：最好放在同一个磁盘里面，把新建的数据库主文件删掉或移开，再把要恢复的数据库主文件剪切过去，这样就可以节省时间。）3、启动数据库服务，数据库变为置疑或可疑状态。然后在查询分析器中运行：alter database 无日志文件的数据库名称 set emergency设置为紧急状态。4、再运行：alter database 无日志文件的数据库名称 set single_user或者：Sp_dboption '无日志文件的数据库名称', 'single user', 'true'设置为单用户模式。5、检查并重建日志文件，运行：dbcc checkdb('无日志文件的数据库名称',REPAIR_ALLOW_DATA_LOSS)这个时间比较长。耐心等待！如果有错误提示，再运行：dbcc checkdb('无日志文件的数据库名称',REPAIR_REBUILD)进行修复。如果没有错误，可以跳过。6、恢复成多用户模式alter database 无日志文件的数据库名称 set multi_user或者：Sp_dboption '无日志文件的数据库名称', 'single user', 'false'刷新数据库，你就可以看到已经修复好的数据库了。

SQLServer2000数据库崩溃后的补救措施

SQL Server 2000数据库崩溃后的补救措施:
　　案例描述：
　　SQL Server 2000数据库崩溃后，重装数据库前的准备：
　　1.三个系统库（master,msdb,model）的完全备份:
　　2.两个用户数据库(user01,user02)的备份（周日的完全备份+除周日外每天的差异备份）:
　　三个系统数据库是早期备份的，之间没有更新过帐号信息，没有增减过饕档鹊取?
　　两个用户数据库在上周日晚做过完全备份（user01.bak和user02.bak）
　　需求：一次性恢复到用户数据库最后一个备份前的状态。
　　下文中，我们将介绍一下常规的恢复过程:
　　1. 备份可用的数据, 包含所有系统数据库和用户数据库的数据文件和日志文件(*.mdf/ldf/ndf)
　　2. 卸载原来的安装
　　3. 系统表查找和删除所有的MSSQLServer项
　　4. 磁盘上删除安装SQL SErver产生的所有文件
　　5. 重新安装SQL Server，所需安装的补丁的版本要求保持与备份系统数据库时安装的补丁版本一致
　　6. 单用户模式下恢复master数据库
　　7. 恢复其他系统数据库
　　8. 恢复用户数据库
　　此外，我们还可以尝试用下面的方法：
　　假如你的时间比较充裕,而且想尽量恢复数据到最近的时间点, 可以在上述步骤中做以下的尝试：
　　1. 首先，将第6,7两个步骤改为:
　　a. 停止MSSQL服务
　　b. 用步骤1备份的系统数据库的数据文件和日志文件替换安装后生成的系统数据库的对应文件
　　c. 建立与SQL Server系统崩溃之前一样的用户数据库的存放目录, 并且把用户数据库文件按原来的位置存放
　　d. 启动MSSQL服务
　　e. 如果MSSQL服务成功, 在企业管理看看用户数据库有没有置疑, 如果没有置疑, 则其他操作都不用做了, 数据已经恢复
　　注意事项:
　　在具体操作以上的步骤b之前, 先备份准备覆盖的文件。
　　2. 如果步骤1的尝试不成功, 则再做下面的尝试, 把步骤8修改为下面的:
　　a. 停止MSSQL服务
　　b. 用备份的文件还原被覆盖的文件
　　c. 尝试用附加的方式恢复用户数据库
　　d. 如果成功, 则修复各用户数据库中的孤立用户
　　恢复过程会涉及到的一些具体处理 1. 恢复系统数据库:
　　在SQL Server数据库中，系统信息存储在系统数据库中，主要的系统数据库包括：
　　master-从整体上控制用户数据库和SQL Server操作，在创建了任何用户定义的对象后，都要备份它
　　model-为新数据库提供模版和原型
　　msdb-包含了有关作业、报警及操作员等信息
　　假如包含系统数据库的介质已经改变，则必须重建系统数据库，如果你目前仍然可以启动SQL Server服务，则可以通过RESTORE语句从系统数据库的备份中恢复数据库。
　　如果master坏了，不能启动系统,可以按照下面步骤进行恢复
　　(1)重建系统数据库 运行c:\mssql7\binn\rebuildm.exe，按照提示进行即可，
　　过程中需要系统数据库样本的路径，可在安装光盘中找到；
　　(2)重建系统数据库后，启动SQL Server服务，用系统数据库的备份恢复数据库
　　就行了通常恢复顺序为master->msdb->model
　　在恢复master的备份时要注意：必须在单用户(single user)模式下进行
　　进入单用户模式的方法：
　　a. 在命令行模式下输入：sqlservr -c -f -m或者输入sqlservr -m
　　其中：-c 可以缩短启动时间，SQL Server 不作为Windows NT的服务启动
　　-f 用最小配置启动SQL Server
　　-m 单用户模式启动SQL Server
　　b. 可以在控制面板-服务-MSSQLServer的启动参数中输入-c -f -m或者输入-m,点击开始
　　(3)进行master数据库的恢复
　　a. 直接进入查询分析器,有个提示不要理会它
　　输入恢复语句进行数据库恢复:
　　RESTORE DATABASE master from disk='c:\具体的备份文件名'
b. 或者用这个,在命令提示符下输入,注意大小写
　　使用"windows身份验证"的,输入:isql /E
　　使用"sql server和windows身份验证"的,输入:isql /U"用户名" /P"密码"
　　然后在出现的提示符下输入(注意1>,2>是提示符):
　　1>RESTORE DATABASE master from disk='c:\具体的备份文件名'
　　2>GO
　　2. 还原数据库的具体步骤:
　　(1) 恢复最近一次的完整备份
　　企业管理器--右键"数据库"--所有任务--还原数据库
　　--"还原为数据库库"中输入还原后的数据库名,设为:test
　　--还原选择"从设备"--选择设备--添加--添加你的备份文件
　　--确定,回到数据库还原的界面
　　--"还原备份集",选择"数据库--完全"
　　--选项--将"移至物理文件名"中的物理文件名修改为你的数据文件要存放的文件名
　　--如果要还原的数据库已经存在,选择"在现有数据库上强制还原"
　　--"恢复完成状态",选择"使数据库不再运行，但能还原其它事务日志"
　　--确定 --或用SQL语句:
　　RESTORE DATABASE 数据库名
　　FROM DISK = 'c:\你的完全备份文件名'
　　WITH NORECOVERY
　　(2)恢复完全备份后, 最近一次的差异备份(如果有的话)
　　企业管理器--右键"数据库"--所有任务--还原数据库
　　--"还原为数据库库"中选择数据库名:test
　　--还原选择"从设备"--选择设备--添加--添加你的备份文件
　　--确定,回到数据库还原的界面
　　--"还原备份集",选择"数据库--差异"
　　--"恢复完成状态",选择"使数据库不再运行，但能还原其它事务日志"
　　--确定
　　--或用SQL语句:
　　--或用SQL语句:
　　RESTORE DATABASE 数据库名
　　FROM DISK = 'c:\你的差异备份文件名'
　　WITH NORECOVERY
　　
(3)按时间先后, 恢复差异备份后(如果没有差异备份,则是完全备份)的所有日志备份
　　企业管理器--右键"数据库"--所有任务--还原数据库
　　--"还原为数据库库"中选择数据库名:test
　　--还原选择"从设备"--选择设备--添加--添加你的备份文件
　　--确定,回到数据库还原的界面
　　--"还原备份集",选择"事务日志"
　　--"恢复完成状态"
　　如果是恢复最后一个日志文件,选择"使数据库可以继续运行，但无法还原其它事务日志"
　　否则选择"使数据库不再运行，但能还原其它事务日志"
　　--确定
　　--或者使用SQL语句:
　　RESTORE DATABASE 数据库名
　　FROM DISK = 'c:\你的日志文件名'
　　WITH RECOVERY
　　3. 解决孤立用户:
　　(1) 查看某个数据库的孤立用户:
　　USE 库名
　　EXEC sp_change_users_login 'Report'
　　(2)自动修复某个孤立的用户:
　　USE 库名
　　EXEC sp_change_users_login 'Auto_Fix', '孤立用户名', NULL, '密码'
　　--假如密码指示用户对应的登录不存在时, 系统自动建立登录, 为登录分配密码。

如何恢复和修复MS SQL数据库的MDF文件[2]

　　怎么办呢?别着急 下面我们举例说明恢复办法
　　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 　　go 　　reconfigure with override 　　go
　　F 设置test为紧急修复模式
　　update sysdatabases set status= 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 )
　　执行过程中 如果遇到下列提示信息
　　服务器: 消息 级别 状态 行
　　未能排它地锁定数据库以执行该操作
　　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 发现了 个分配错误和 个一致性错误(在数据库 test 中)
　　DBCC 执行完毕 如果 DBCC 输出了错误信息 请与系统管理员联系
　　I 设置数据库为正常状态
　　sp_dboption test dbo use only false
　　如果没有出错 那么恭喜 现在就可以正常的使用恢复后的数据库啦
　　J 最后一步 我们要将步骤E中设置的 允许对系统目录直接修改 一项恢复 因为平时直接操作系统表是一件比较危险的事情 当然 我们可以在SQL Server Enterprise Manager里面恢复 也可以使用如下语句完成
以下是引用片段 　　sp_configure allow updates 　　go 　　reconfigure with override 　　go

lishixinzhi/Article/program/SQL/201311/16354

SQL Server的文件恢复技术

　　SQL Server有两种备份方式 一种是使用BACKUP DATABASE将数据库文件备份出去 另外一种就是直接拷贝数据库文件mdf和日志文件ldf的方式 本文中 我们将主要介绍一下后者的备份与恢复 (本文中假定您目前已经能够熟练使用Server企业管理器和SQL Server查询分析器)
　　 正常的备份 恢复方式
　　正常方式下 我们要备份一个数据库 首先要先将该数据库从运行的数据服务器中断开 或者停掉整个数据库服务器 然后复制文件
　　卸下数据库的命令
　　Sp_detach_db 数据库名

　　连接数据库的命令
　　Sp_attach_db或者sp_attach_single_file_db s_attach_db [@dbname =] ′dbname′ [@filename =] ′filename_n′ [ ] sp_attach_single_file_db [@dbname =] ′dbname′ [@physname =] ′physical_name′
　　使用此方法可以正确恢复SQL Sever 和SQL Server 的数据库文件 要点是备份的时候一定要将mdf和ldf两个文件都备份下来 mdf文件是数据库数据文件 ldf是数据库日志文件
　　例子
　　假设数据库为test 其数据文件为test_data mdf 日志文件为test_log ldf 下面我们讨论一下如何备份 恢复该数据库
　　卸下数据库
　　sp_detach_db ’test’
　　连接数据库
　　sp_attach_db ’test’ ’C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data mdf’ ’C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log ldf’sp_attach_single_file_db ’test’ ’C:Program FilesMicrosoft SQL ServerMSSQLDatatest_data mdf’
　　 只有mdf文件的恢复技术
　　由于种种原因 我们如果当时仅仅备份了mdf文件 那么恢复起来就是一件很麻烦的事情了
　　如果您的mdf文件是当前数据库产生的 那么很侥幸 也许你使用sp_attach_db或者sp_attach_single_file_db可以恢复数据库 但是会出现类似下面的提示信息
　　设备激活错误 物理文件名 ’C:Program FilesMicrosoft SQL ServerMSSQLdatatest_Log LDF’可能有误
　　已创建名为’C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log LDF’的新日志文件
　　但是 如果您的数据库文件是从其他计算机上复制过来的 那么很不幸 也许上述办法就行不通了 你也许会得到类似下面的错误信息
　　服务器: 消息 级别 状态 行
　　未能打开新数据库 ’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’ go reconfigure with override go
　　F 设置test为紧急修复模式
　　update sysdatabases set status= where dbid=DB_ID(’test’)
　　此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读置疑脱机紧急模式”可以看到数据库里面的表 但是仅仅有系统表
　　G 下面执行真正的恢复操作 重建数据库日志文件
　　dbcc rebuild_log(’test’ ’C:Program FilesMicrosoft SQL ServerMSSQLDatatest_log ldf’)
　　执行过程中 如果遇到下列提示信息
　　服务器: 消息 级别 状态 行
　　未能排它地锁定数据库以执行该操作
　　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发现了 个分配错误和 个一致性错误(在数据库 ’test’ 中)
　　DBCC执行完毕 如果DBCC输出了错误信息 请与系统管理员联系
　　I 设置数据库为正常状态
　　sp_dboption ’test’ ’dbo use only’ ’false’
　　假如没有出错 现在你就可以正常的使用恢复后的数据库啦
　　J 最后一步 我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复 因为平时直接操作系统表是一件比较危险的事情 当然 我们可以在SQL Server Enterprise Manager里面恢复 也可以使用如下语句完成
lishixinzhi/Article/program/SQLServer/201311/22357

如何修复 SQL 数据库置疑？

SQL数据库修复大师6.6 是一款功能强大的数据修复工具\x0d\x0a对修复 SQL 数据库置疑 823错误 无损\x0d\x0a\x0d\x0a支持对SQL 2000 SQL2005 SQL2008 的mdf文件进行修复 支持数据库日志（LDF）生成 直接附加\x0d\x0a对数据库823错误 质疑错误 效果最佳 完美支持中文记录\x0d\x0aSQL 2000 2005 2008 数据库修复工具，修复系统表损坏 索引损坏 823报错 日志报错等各种故障