sqlserver2000 mdf或ldf其中一个损坏。想新建一个同名数据库进行恢复，新建同名数据库失败。
不知道该如何解决这个问题，而且不能使用更改数据库名的办法。真是愁人以下是修复数据库的方法，我就是在新建数据库的这一步走不通了。
2. 新建同名数据库，使用原数据库文件覆盖后，强行修复。步骤如下(1). 停止数据库服务，移走原数据库文件，启动数据库服务后新建同名数据库，生成的数据库文件名要与原数据库文件名相同。并且新数据库日志文件所在目录最好与原数据库日志文件所在目录相同。(2). 停止数据库服务，将原数据库文件覆盖新数据库文件，重启数据库服务，此时发现数据库处于不可用状态。(3). 执行如下T-SQL：USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
ALTER DATABASE DbName SET EMERGENCY
GO
sp_dboption 'DbName', 'single user', 'true'
GO
DBCC CHECKDB('DbName','REPAIR_ALLOW_DATA_LOSS')
GO
ALTER DATABASE DbName SET ONLINE
GO
sp_configure 'allow updates', 0 reconfigure with override
GO
sp_dboption 'DbName', 'single user', 'false' GO 其中DBCC CHECKDB('DbName','REPAIR_ALLOW_DATA_LOSS') 是关键，主要是数据校验。特别提醒的是，第二步要求新数据库日志文件与原数据库日志文件处于同一目录，就是因为这个语句，假如2者不在同一目录，并且原数据库日志文件所在目录下没有同名日志文件，则此语句执行不通过，数据库恢复也就不会成功。此为鄙人在恢复过程中所遇到的问题，所幸根据error message加以分析后将新建的数据库日志附加copy一份到原数据库日志文件所在目录下。恢复成功后为了是数据文件与日志文件处于同一目录，将数据文件与日志文件copy到同一目录下后采用附加方式恢复。
不知道该如何解决这个问题，而且不能使用更改数据库名的办法。真是愁人以下是修复数据库的方法，我就是在新建数据库的这一步走不通了。
2. 新建同名数据库，使用原数据库文件覆盖后，强行修复。步骤如下(1). 停止数据库服务，移走原数据库文件，启动数据库服务后新建同名数据库，生成的数据库文件名要与原数据库文件名相同。并且新数据库日志文件所在目录最好与原数据库日志文件所在目录相同。(2). 停止数据库服务，将原数据库文件覆盖新数据库文件，重启数据库服务，此时发现数据库处于不可用状态。(3). 执行如下T-SQL：USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GO
ALTER DATABASE DbName SET EMERGENCY
GO
sp_dboption 'DbName', 'single user', 'true'
GO
DBCC CHECKDB('DbName','REPAIR_ALLOW_DATA_LOSS')
GO
ALTER DATABASE DbName SET ONLINE
GO
sp_configure 'allow updates', 0 reconfigure with override
GO
sp_dboption 'DbName', 'single user', 'false' GO 其中DBCC CHECKDB('DbName','REPAIR_ALLOW_DATA_LOSS') 是关键，主要是数据校验。特别提醒的是，第二步要求新数据库日志文件与原数据库日志文件处于同一目录，就是因为这个语句，假如2者不在同一目录，并且原数据库日志文件所在目录下没有同名日志文件，则此语句执行不通过，数据库恢复也就不会成功。此为鄙人在恢复过程中所遇到的问题，所幸根据error message加以分析后将新建的数据库日志附加copy一份到原数据库日志文件所在目录下。恢复成功后为了是数据文件与日志文件处于同一目录，将数据文件与日志文件copy到同一目录下后采用附加方式恢复。
数据库的脚本创建一个新的数据库,并将数据导进去就行了.USE MASTER
GOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
GOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的数据库名'
Gosp_dboption '置疑的数据库名', 'single user', 'true'
GoDBCC CHECKDB('置疑的数据库名')
Goupdate sysdatabases set status =28 where name='置疑的数据库名'
Gosp_configure 'allow updates', 0 reconfigure with override
Gosp_dboption '置疑的数据库名', 'single user', 'false'
Go方法二事情的起因：昨天，系统管理员告诉我，我们一个内部应用数据库所在的磁盘空间不足了。我注意到数据库事件日志文件XXX_Data.ldf文件已经增长到了3GB，于是我决意缩小这个日志文件。经过收缩数据库等操作未果后，我犯了一个自进入行业以来的最大最愚蠢的错误：竟然误删除了这个日志文件！后来我看到所有论及数据库恢复的文章上都说道：“无论如何都要保证数据库日志文件存在，它至关重要”，甚至微软甚至有一篇KB文章讲如何只靠日志文件恢复数据库的。我真是不知道我那时候是怎么想的？！这下子坏了！这个数据库连不上了，企业管理器在它的旁边写着“(置疑)”。而且最要命的，这个数据库从来没有备份了。我唯一找得到的是迁移半年前的另外一个数据库服务器，应用倒是能用了，但是少了许多记录、表和存储过程。最终成功恢复的全部步骤如下：设置数据库为紧急模式
停掉SQL Server服务；把应用数据库的数据文件XXX_Data.mdf移走；重新建立一个同名的数据库XXX；停掉SQL服务；把原来的数据文件再覆盖回来；运行以下语句，把该数据库设置为紧急模式；运行“Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGo”执行结果：DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。接着运行“update sysdatabases set status = 32768 where name = 'XXX'”执行结果：（所影响的行数为 1 行）重启SQL Server服务；运行以下语句，把应用数据库设置为Single User模式；运行“sp_dboption 'XXX', 'single user', 'true'”执行结果：命令已成功完成。做DBCC CHECKDB；运行“DBCC CHECKDB('XXX')”执行结果：'XXX' 的 DBCC 结果。'sysobjects' 的 DBCC 结果。对象 'sysobjects' 有 273 行，这些行位于 5 页中。'sysindexes' 的 DBCC 结果。对象 'sysindexes' 有 202 行，这些行位于 7 页中。'syscolumns' 的 DBCC 结果。………运行以下语句把系统表的修改选项关掉；运行“sp_resetstatus "XXX"gosp_configure 'allow updates', 0reconfigure with overrideGo”执行结果：在 sysdatabases 中更新数据库 'XXX' 的条目之前，模式 = 0，状态 = 28（状态 suspect_bit = 0），没有更新 sysdatabases 中的任何行，因为已正确地重置了模式和状态。没有错误，未进行任何更改。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。重新建立另外一个数据库XXX.Lost；DTS导出向导
运行DTS导出向导；复制源选择EmergencyMode的数据库XXX，导入到XXX.Lost；选择“在SQL Server数据库之间复制对象和数据”，试了多次，好像不行，只是复制过来了所有表结构，但是没有数据，也没有视图和存储过程，而且DTS向导最后报告复制失败；所以最后选择“从源数据库复制表和视图”，但是后来发现，这样总是只能复制一部分表记录；于是选择“用一条查询指定要传输的数据”，缺哪个表记录，就导哪个；视图和存储过程是执行SQL语句添加的。这样，XXX.Lost数据库就可以替换原来的应用数据库了。
CREATE DATABASE db
ON PRIMARY(
NAME='db_data',
FILENAME= 'c:\db_data.mdf')
LOG ON(
NAME='db_log',
FILENAME ='c:\db.ldf')
GO--创建表
CREATE TABLE db.dbo.ta(id int)
INSERT db.dbo.ta SELECT id FROM sysobjects
GO
--做文件组备份
BACKUP DATABASE db TO DISK='c:\db.bak' WITH FORMAT--备份后,再做数据处理
CREATE TABLE db.dbo.tb(id int)
INSERT db.dbo.tb SELECT id FROM sysobjects
GO/*--下面演示了破坏数据文件的处理，这些操作在操作系统中进行1. 停止SQL Server服务(msqlserver服务)
2. 删除文件 c:\db_data.ndf (模拟破坏)
3. 重新SQL Server服务,此时数据库DB置疑
--*/
GO--下面演示了如何恢复数据
--首先要备份当前日志
BACKUP LOG db TO DISK='c:\db_log.bak' WITH FORMAT,NO_TRUNCATE
--利用文件组备份恢复破坏的文件
RESTORE DATABASE db FROM DISK='c:\db.bak' WITH NORECOVERY
--还原到日志点
RESTORE LOG db FROM DISK='c:\db_log.bak' WITH RECOVERY
--显示已经恢复的数据
SELECT COUNT(*) FROM db.dbo.ta
SELECT COUNT(*) FROM db.dbo.tb
GO--删除测试
DROP DATABASE db
标题：Log Explorer for SQL Server v4.0.2的下载地址和使用说明
作者：爱新觉罗·毓华
时间：2008-07-14
地点：新疆乌鲁木齐
资料来源：http://topic.csdn.net/u/20090305/00/849723bf-74ad-495f-8fc6-22d2108beb10.html?seed=1633183628
*/1、Lumigent Log Explorer for SQL Server v4.0.2 特别版下载地址
http://down.chinaz.com/soft/7887.htm
Log Explorer for SQL Server 4.2 注册码
wv5rc-uxvpz-e33-nr4694qs2 2、Log Explorer for SQL Server v4.0.2
安装完毕后，注册该程序(压缩文件有注册机)
打开log explorer file=>attach log file->选择服务器和登陆方式->connect->
选择数据库->attach->左面对话框中browse->view log->就可以看到log记录了
点击“View DDL Commands”里面就有很多drop table 命令
点击下面的“undo”按钮是生成表结构的语句(create table ....)
点击下面的“Salvage”按钮是生成插入语句的(insert into ...values....)
想恢复的话: 右键log记录 undo transation->选择保存文件名和路径->然后打开该文件到查询分析器里执行T-sql代码就可以了 例如 如果log是delete table where ...的话,生成的文件代码就是insert table .... log explorer使用的几个问题
1)、对数据库做了完全、差异和日志备份
备份时选用了删除事务日志中不活动的条目
再用Log explorer打试图看日志时
提示No log recorders found that match the filter，would you like to view unfiltered data
选择yes，就看不到刚才的记录了
如果不选用了删除事务日志中不活动的条目
再用Log explorer打试图看日志时，就能看到原来的日志
2)、修改了其中一个表中的部分数据，此时用Log explorer看日志，可以作日志恢复
3)、然后恢复备份，(注意:恢复是断开log explorer与数据库的连接，或连接到其他数据上，
否则会出现数据库正在使用无法恢复)
恢复完后，再打开log explorer 提示No log recorders found that match the filter，would you like to view unfiltered data
选择yes，就看不到刚才在2中修改的日志记录，所以无法做恢复.
4)、不要用SQL的备份功能备份,搞不好你的日志就破坏了.
正确的备份方法是:
停止SQL服务,复制数据文件及日志文件进行文件备份.
然后启动SQL服务,用log explorer恢复数据
5)、如果你的数据库的日志恢复模型是simple,那就不可能用log explorer恢复
6)、Log explorer必须安装在要恢复数据库的sql server服务器上,或者在sql server服务器上安装服务端,在操作的电脑上安装客户端进行数据恢复 3、如果数据量比较大的话,使用磁带机和集群的话，安装了正版的VERITAS ，恢复数据是比较好的方法。
下面是该软件重要的新功能:
1)、灾难恢复演习(Disaster Recovery Fire Drill)--能够自由测试、规划和检验灾难恢复计划，而不会中断生产过程。
2)、集群模拟器(Cluster Simulator)--可测试应用故障切换方案，以验证应用的可用性，确认应用是否根据计划的故障切换策略和应用需求，迁移到最适当的服务器。
3)、全局集群选件(Global Cluster Option)--当可用性要求从本地迁移到广域灾难恢复时，能够快速、轻松地升级到任何体系结构。
4)、即时访问复制数据--在复制数据的同时，能够即时访问数据，只占用客户的部分可用存储容量。
5)、卷复制顾问工具(Volume Replicator Advisor)--准确地分析带宽需求，确保应用得到优化。
4、几点恢复数据心得:
1)、平时需要做好双机热备份,日备份，月备份，年备份，数据复制，异常记录等工作，在数据丢失的情况下才能做到心中不急。
2)、如果硬盘损害错误，或者误删除数据库的时候，可以考虑用Easyrecovery或者Recover4all等软件恢复删除或者受到损害的文件，再恢复数据。
3)、如果实在遇到自然因素，网络又断开了复制操作的情况下，建议只有手工"造取"一批数据出来弥补丢失数据，一般选取类似纬度(如时间、区域等)的数据。
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
下面的代码演示了如何利用日志还原功能，将主数据库中的数据变化及时反馈到备用数据库中
备用数据库的数据可以随时用于查询，但不能被更新（备用数据库只读）。
--*/--首先,创建一个演示用的数据库(主数据库)
CREATE DATABASE Db_test
ON
( NAME = Db_test_DATA,
FILENAME = 'c:\Db_test.mdf' )
LOG ON
( NAME = Db_test_LOG,
FILENAME = 'c:\Db_test.ldf')
GO--对数据库进行备份
BACKUP DATABASE Db_test TO DISK='c:\test_data.bak' WITH FORMAT
GO--把数据库还原成备用数据库(演示主数据库与这个备用数据库之间的同步)
RESTORE DATABASE Db_test_bak FROM DISK='c:\test_data.bak'
WITH REPLACE,STANDBY='c:\db_test_bak.ldf'
,MOVE 'Db_test_DATA' TO 'c:\Db_test_data.mdf'
,MOVE 'Db_test_LOG' TO 'c:\Db_test_log.ldf'
GO--启动 SQL Agent 服务
EXEC master..xp_cmdshell 'net start sqlserveragent',no_output
GO--创建主服务器数据训与备用服务器数据库之间同步的作业
DECLARE @jogid uniqueidentifier
EXEC msdb..sp_add_job
@job_id = @jogid OUTPUT,
@job_name = N'数据同步处理'--创建同步处理步骤
EXEC msdb..sp_add_jobstep
@job_id = @jogid,
@step_name = N'数据同步',
@subsystem = 'TSQL',
@command = N'
--主数据库中进行日志备份
BACKUP LOG Db_test TO DISK=''c:\test_log.bak'' WITH FORMAT--备用数据库中还原主数据库的日志备份(应用主数据库中的最新变化
--实际应该时主数据库备份与备用数据库的还原作业应该分别在主服务器和备用服务器上建立，并且备份文件应该放在主服务器和备用都能访问的共享目录中
RESTORE LOG Db_test_bak FROM DISK=''c:\test_log.bak'' WITH STANDBY=''c:\test_log.ldf''',
@retry_attempts = 5,
@retry_interval = 5--创建调度(每分钟执行一次)
EXEC msdb..sp_add_jobschedule
@job_id = @jogid,
@name = N'时间安排',
@freq_type=4,
@freq_interval=1,
@freq_subday_type=0x4,
@freq_subday_interval=1,
@freq_recurrence_factor=1-- 添加目标服务器
EXEC msdb.dbo.sp_add_jobserver
@job_id = @jogid,
@server_name = N'(local)'
GO--通过上述处理,主数据库与备用数据库之间的同步关系已经设置完成
--下面开始测试是否能实现同步--在主数据库中创建一个测试用的表
CREATE TABLE Db_test.dbo.TB_test(ID int)
GO--等待1分钟30秒（由于同步的时间间隔设置为1分钟,所以要延时才能看到效果）
WAITFOR DELAY '00:01:30'
GO--查询一下备用数据库,看看同步是否成功
SELECT * FROM Db_test_bak.dbo.TB_test/*--结果:
ID
----------- （所影响的行数为 0 行）
--*/--测试成功
GO--最后删除所有的测试
DROP DATABASE Db_test,Db_test_bak
EXEC msdb..sp_delete_job @job_name=N'数据同步处理'
GO
/*===========================================================*//*--服务器档机处理说明
使用这种方式建立的数据库同步，当主数据库不可用时（例如，主数据库损坏或者停机检修）
可以使用以下两种方法使备用数据库可用。
--*/--1. 如果主数据库损坏，无法备份出最新的日志，可以直接使用下面的语句使备用数据库可读写（丢失最近一次日志还原后的所有数据）。
--RESTORE LOG Db_test_bak WITH RECOVERY
--2. 如果主数据库可以备份出最新日志，则可以使用下面的语句。
--先备份主数据库的最新的事务日志
--BACKUP LOG Db_test TO DISK=''c:\test_log.bak'' WITH FORMAT
--再在备用数据库中恢复最新的事务日志，并且使备用数据库可读写（升级为主数据库）
--RESTORE LOG Db_test_bak FROM DISK='c:\test_log.bak'简单地说:
1. 你的sql服务要使用指定的windows用户登陆, 而不能使用"本地系统帐户"
2. 用于登陆sql服务的用户要求对共享目录具有所有权限
3. 如果你的电脑没有加入到域, 还必须保证源和目标服务器的sql服务设置的登陆用户是一样的(用户名和密码都一样)网络备份主要是权限设置问题, 参考下面的备份文件共享目录权限设置方法去解决目录的共享权限就可以了下面假设是假设A服务器上的数据库备份到B服务器上的共享目录权限设置(两台服务器应该在局域网内,允许目录共享访问)::1.机器A,B创建一个同名的windows用户,用户组设置为administrators,并设置相同的密码,做为备份文件夹文件夹的有效访问用户,操作:
我的电脑
--控制面板
--管理工具
--计算机管理
--用户和组
--右键用户
--新建用户
--建立一个隶属于administrator组的登陆windows的用户2.在B机器器上,新建一个共享目录,做为备份文件的存放目录,操作:
我的电脑--D:\ 新建一个目录,名为: BAK
--右键这个新建的目录
--属性--共享
--选择"共享该文件夹"
--通过"权限"按纽来设置具体的用户权限,保证第一步中创建的用户具有对该文件夹的所有权限
--确定
3.设置 MSSQLSERVER 及 SQLSERVERAGENT 服务的启动用户
开始--程序--管理工具--服务
--右键 MSSQLSERVER
--属性--登陆--选择"此账户"
--输入或者选择第一步中创建的windows登录用户名
--"密码"中输入该用户的密码
--确定
--同样的方法设置 SQLSERVERAGENT4.在A机器上完成对B机器BAK目录的映射5.查询分析器中执行下面的语句,检验是否成功:
exec master..xp_cmdshell 'dir 映射的盘符'6.A服务器上做备份计划备注:创建一个新的用户只是为了让MSSQLSERVER服务的启动帐户与共享目录的有效访问同名且密码相同,这样才能通过验证(所以你也可以用其他有效的用户来代替,只需要满足用户名和密码相同,并且拥有足够的权限)