紧急求救,数据库无法附加,错误823!

[yzmb]

由于数据库今天崩掉,找出来的数据实体在附加时出错,错误823!
请高手帮忙!

[liangCK]

帮顶.有分吗?

[bqb]

没有碰到过，以下网上找的，不知道对你有没有帮助！

错误823解决办法
一、SQL-Server附加数据库时失败。
1、异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。
2、异常分析：关于823错误的 SQL-SERVER 中的帮助：
================================
错误 823
严重级别 24
消息正文
在文件 "%4!" 的偏移量 %3! 处的 %2! 过程中，检测到 I/O 错误 %1!。

解释
Microsoft SQL Server 在对某设备进行读或写请求时遇到 I/O 错误。该错误通常表明磁盘问题。但是，错误日志中在错误 823 之前记录的其它核心消息应指出涉及了哪个设备。
3、解决办法：
在SQL-Server企业管理器中，新建同名数据库（这里假设为Test）后，停止数据库，把损坏的数据库文件Data.mdf和Test_log.LDF覆盖刚才新建数据库目录下的Data.mdf和Test_log.LDF，同时删除Test_log.LDF文件；启动数据库服务，发现数据库名Test后面有“置疑”字样。不要紧，打开SQL自带查询分析器，分别执行如下SQL语句：
--第一、
exec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */
--第二、
update sysdatabases set status=32768 where name='数据库名' /* 设置数据库状态 */
--第三、
DBCC REBUILD_LOG ('数据库名','E:\database\1204_Log.LDF') /* 重建LDF文件 */
--第四、
update sysdatabases set status=0 where name='数据库名' /* 重置数据库状态 */
--第五、
restore database 数据库名 WITH RECOVERY /* 恢复数据库 */
--第六、
exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */
按照此方法操作，应该能修复数据库正常访问了。如果问题依然存在，最笨的一个方法就是新建另一个数据库，把原数据库（Test）各个表的数据导出到新建数据库表中。

[-狙击手-]

按楼上的办法一试

或在有完全备份的前提下用ldf文件进行数据库的恢复

/*--说明：
下面的代码演示了如何利用日志还原功能，将主数据库中的数据变化及时反馈到备用数据库中
备用数据库的数据可以随时用于查询，但不能被更新（备用数据库只读）。
--*/

--首先,创建一个演示用的数据库(主数据库)
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登录用户名
--"密码"中输入该用户的密码
--确定
--同样的方法设置 SQLSERVERAGENT

4.在A机器上完成对B机器BAK目录的映射

5.查询分析器中执行下面的语句,检验是否成功:
  exec master..xp_cmdshell 'dir 映射的盘符'

6.A服务器上做备份计划

备注:创建一个新的用户只是为了让MSSQLSERVER服务的启动帐户与共享目录的有效访问同名且密码相同,这样才能通过验证(所以你也可以用其他有效的用户来代替,只需要满足用户名和密码相同,并且拥有足够的权限)

[中国风]

这是SQL2000常遇到的错误，楼主按照以下方法修复，修复完，检查一下数据库是否已完全修复，没完全修复时最低都可导出数据，要用数据库生成一个空库脚本，把修复数据库的数据用DTS导入到新库。。。

由于种种原因，我们如果当时仅仅备份了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里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
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 输出了错误信息，请与系统管理员联系。[brown][/i]
说明您的其他程序正在使用该数据库，如果刚才您在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

[netcup]

最好找到完全备份和之后的日志。否则都比较麻烦

[w2jc]

从备份恢复，
否则只有照楼上诸位的方法试试了

[elvis_gao]

没遇到过，帮顶顶

[JXDED]

顶，好文件

[JXDED]

问题解决了，真是爽