SQL数据库置疑解决方案(原因、预防、修复)附图

S Q L数据库置疑解决方案(原因、预防、修复)附图-CAL-FENGHAI-(2020YEAR-YICAI)_JINGBIANSQL数据库置疑解决方案一、数据库置疑产生的原因1、SQL Server所在分区空间是否够？数据库文件大小是否达到最大文件限制？FAT32的格式只支持4G以内的文件。

2、数据库文件损坏或被非正常删除时出现这种情况。

3、病毒防火墙的扫描也会引起数据库置疑。

4、当SQL Server启动时，将会尝试获得对数据库文件的排他访问权，如果此时该文件被其他程序占用，或者遗失，数据库将会被标记为置疑。

5、电脑非法关机也会造成数据库置疑。

6、电脑磁盘有坏道有可能造成数据库置疑。

二、数据库置疑的预防1、数据库存放的盘符，空间是否够大，经常检查盘符的空间。

2、数据库存放的盘符的格式设置为NTFS格式。

3、进行病毒清除时，尽量把SQL服务停掉，再进行检查。

4、尽量减少非正常关机。

5、建议客户购买后备电源。

6、给客户实施软件之后一定要做好自动备份。

7、建议客户每隔一定时间手动备份一次。

三、数据库置疑的修复1、正常的备份、SQL数据库恢复方式正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。

卸下数据库的命令：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是数据库日志文件。

Sqlserver 数据库823错误（置疑）的解决方案一、SQL-Server数据库置疑：1、异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。

2、异常分析：关于823错误的SQL-SERVER 中的帮助：================================错误823严重级别24消息正文在文件%4的偏移量，%3的索引，%2过程中，检测到I/O 错误%1。

解决办法：准备工作：①停止sql server服务，找到置疑库的mdf，ldf文件复制出来，这里假设叫kmcyV51_data.mdf(ldf)，并与企业管理器中删除该数据库；②用KM安装包下db_setup.exe建立一个空库（名称和质疑数据库名一致kmcyv51），选择服务器节点，右键停止数据库服务，把损坏的数据库文件kmcyv51_Data.mdf覆盖刚才新建数据库目录下，同时删除kmcy_v51_log.LDF文件；右键节点启动数据库服务，发现数据库名kmcyv51后面有“置疑”字样。

打开SQL自带查询分析器，在master数据库分别执行如下SQL语句：（注意更改数据库名）use masterexec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表开关*/update sysdatabases set status=32768 where name = 'kmcyv51' /* 设置紧急状态*/sp_dboption 'kmcyv51', 'single user', 'true' /*启用单用户*/DBCC REBUILD_LOG ('kmcyv51','E:\km软件_data\KmcyV51_Log.LDF') /* 重建LDF文件*/update sysdatabases set status=28 where name= 'kmcyv51' /* 设置正常状态*/--或者update sysdatabases set status = 16 where name = 'kmcyv51'RESTORE DATABASE kmcyv51 WITH RECOVERY /* 恢复数据库*/exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 关闭修改系统表开关*/sp_dboption 'kmcyv51', 'single user', 'false' /* 关闭单用户模式*/如果问题依然存在，最笨的一个方法就是新建另一个数据库，把原数据库各个表的数据导出到新建数据库表中。

SQLServer2000数据库置疑的解决方法sql2000中MSDB数据库置疑状态的解决方法问题:我的SQL Server 2000的MSDB数据库，因为不正常关机，造成了置疑状态，请问采用什么方法能够弥补,解决方法一:你可以采用以下的代码进行修复: USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='msdb' Gosp_dboption 'msdb', 'single user', 'true'GoDBCC CHECKDB('msdb')Goupdate sysdatabases set status =28 where name='msdb' Gosp_configure 'allow updates', 0reconfigure with overrideGosp_dboption 'msdb', 'single user', 'false'Go解决方法二:MSDB数据库解决过程难点:由于MSDB数据库不能删除，将其文件拷出来，再次附加数据库，但新的不能同名，遇到了困难。

附加数据库不能叫MSDB，也就是1:先停止整个数据库，将该数据库的文件msdbdata.mdf和msdblog.ldf拷贝粘贴出来到另一个目录下。

2:将以上的文件再拷贝到另一个目录下，也就是说复制两次。

3:选择数据库右击鼠标 --》所有任务--》附加数据库将复制出的一个备份文件附加上去，其中，数据库名称叫MSDB1，用户是SA或ADMINISTRATOR。

4:将MSDB1数据库备份，备份成一个文件，当时我的叫MSDB。

SQl数据库状态为置疑,只读\脱机\紧急模式时的解决办法SQl数据库状态为置疑,只读\脱机\紧急模式时的解决办法2010-05-08 18:44这是SQL2000常遇到的错误，楼主按照以下方法修复，修复完，检查一下数据库是否已完全修复，没完全修复时最低都可导出数据，要用数据库生成一个空库脚本，把修复数据库的数据用DTS导入到新库。

A．建立一个供恢复使用的数据库我们使用默认方式建立一个供恢复使用的数据库(如iBusinessWork)。

可以在SQL Server Enterprise Manager 里面建立。

B．停掉数据库服务器。

C．调整数据库与日志文件.将刚才生成的数据库的日志文件iBusinessWork_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件iBusinessWork_data.mdf。

D．启动数据库服务器。

此时会看到数据库iBusinessWork的状态为“置疑”。

这时候不能对此数据库进行任何操作。

E．设置数据库允许直接操作系统表。

use mastergosp_configure 'allow updates',1goreconfigure with overridegoF．设置iBusinessWork为紧急修复模式update sysdatabases set status=-32768 where dbid=DB_ID('iBusinessWork')关闭打开企业管理器，此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表G．下面执行真正的恢复操作，重建数据库日志文件dbcc rebuild_log('iBusinessWork','E:\Microsoft SQL Server\Data\iBusinessWork_log.ldf')执行过程中，如果遇到下列提示信息：服务器: 消息5030，级别16，状态1，行 1未能排它地锁定数据库以执行该操作。

数据库损坏和置疑修复方案一、数据库置疑和损坏产生原因Sql Server数据库本身依赖于操作系统、文件读写存储等环境，数据库经常因为操作系统、异常关机、异常终止退出或者SQL Server数据库本身的机制问题均会导致数据库无故损坏，其中数据库置疑或者损坏的主要原因如下：1.数据库主文件和日志文件被移除或者更改了名称，数据库目录下找不到数据库物理文件2.事务日志问题，日志文件误删除，或者日志文件过大，磁盘空间不足3.突然断电或者数据库读写过程中强制关机，导致数据文件损坏4.硬盘损坏，导致数据读写错误5.病毒，或者其他原因造成数据库置疑二、数据库置疑和损坏修复方案以方象3000主数据fdbmis为例1.数据库主文件和日志文件被移除或者更改了名称，数据库目录下找不到数据库物理文件，导致数据库置疑3000数据库文件存在目录一般为：D：\DATA文件下的FDbMis_Data.MDF和FDbMis_Log.LDF，现在，先将两个文件移除D：\DATA文件夹，当前情况下启动网络服务程序报错如下启动软件报错进行正确设置后，还是重复这个错误。

这时进入企业管理器发现fdbmis显示置疑状态，然后用数据库分离和附加数据库。

去数据库目录下查找发现没有FDbMis_Data.MDF和FDbMis_Log.LDF。

或者更改为其他名称了。

这时的解决办法是：找到被移除的物理文件，拷贝到正确的目录下，或者将更改了的名称改回来，放到正确的目录下之后，然后将sql server服务管理器停止，重新启动一下就可以了。

2.事务日志问题，日志文件误删除，或者日志文件过大，磁盘空间不足，导致数据库置疑（1）磁盘空间不足，可通过释放磁盘空间暂时解决。

日志文件过大，可以先将sql server服务管理器停止，然后将日志文件删除，启动sql server服务管理器。

这时fdbmis数据库显示置疑状态。

下面设置数据库允许直接操作系统表。

用以下语句实现：use mastergosp_configure 'allow updates',1goreconfigure with overridego（2）设置fdbmis为紧急修复模式update sysdatabases set status =-32768 where dbid=db_id('fdbmis')此时，可以在企业管理器中看到数据库为“紧急模式”。

Sql数据库质疑处理方法1.首先停止sql服务、将质疑的数据库文件复制到其他盘进行备份、备份完之后将质疑数据库删除掉然后启动sql服务重新安装建立一个新的数据库。

2.停止sql服务然后用备份出来的数据库后缀名为MDF的文件替换新的MDF文件。

且删除掉后缀名为LDF的文件3.启动sql服务4.执行下列语句：Use Mastergosp_configure 'allow updates', 1reconfigure with overridegobegin tranupdate sysdatabases set status = 32768 where name = '数据库名'--Verify one row is updated before committingcommit trango5.停止sql再重新启动sql服务，然后运行下列语句：use mastergoDBCC TRACEON(3604)DBCC REBUILD_LOG('数据库名称','D:\Program Files\Microsoft SQL Server\MSSQL\Data\数据库名称_log.ldf')--（注：在这里输入自己的数据库路径）Go6.停止sql然后重新启动sql服务，然后运行下列语句：use mastergoupdate sysdatabases set status = 8 where name = '数据库名称'gosp_configure 'allow updates', 0reconfigure with overridego7. 运行dbcc checkdb(db_name) 检查修复好的质疑数据库是否正常。

SQl数据库状态为置疑,只读\脱机\紧急模式时的解决办法SQl数据库状态为置疑,只读\脱机\紧急模式时的解决办法2010-05-08 18:44这是SQL2000常遇到的错误，楼主按照以下方法修复，修复完，检查一下数据库是否已完全修复，没完全修复时最低都可导出数据，要用数据库生成一个空库脚本，把修复数据库的数据用DTS导入到新库。

A．建立一个供恢复使用的数据库我们使用默认方式建立一个供恢复使用的数据库(如iBusinessWork)。

可以在SQL Server Enterprise Manager 里面建立。

B．停掉数据库服务器。

C．调整数据库与日志文件.将刚才生成的数据库的日志文件iBusinessWork_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件iBusinessWork_data.mdf。

D．启动数据库服务器。

此时会看到数据库iBusinessWork的状态为“置疑”。

这时候不能对此数据库进行任何操作。

E．设置数据库允许直接操作系统表。

use mastergosp_configure 'allow updates',1goreconfigure with overridegoF．设置iBusinessWork为紧急修复模式update sysdatabases set status=-32768 where dbid=DB_ID('iBusinessWork')关闭打开企业管理器，此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表G．下面执行真正的恢复操作，重建数据库日志文件dbcc rebuild_log('iBusinessWork','E:\Microsoft SQL Server\Data\iBusinessWork_log.ldf')执行过程中，如果遇到下列提示信息：服务器: 消息5030，级别16，状态1，行 1未能排它地锁定数据库以执行该操作。

SQL数据库置疑解决方案一、数据库置疑产生的原因1、SQL Server所在分区空间是否够？数据库文件大小是否达到最大文件限制？FAT32的格式只支持4G以内的文件。

2、数据库文件损坏或被非正常删除时出现这种情况。

3、病毒防火墙的扫描也会引起数据库置疑。

4、当SQL Server启动时，将会尝试获得对数据库文件的排他访问权，如果此时该文件被其他程序占用，或者遗失，数据库将会被标记为置疑。

5、电脑非法关机也会造成数据库置疑。

6、电脑磁盘有坏道有可能造成数据库置疑。

二、数据库置疑的预防1、数据库存放的盘符，空间是否够大，经常检查盘符的空间。

2、数据库存放的盘符的格式设置为NTFS格式。

3、进行病毒清除时，尽量把SQL服务停掉，再进行检查。

4、尽量减少非正常关机。

5、建议客户购买后备电源。

页脚内容16、给客户实施软件之后一定要做好自动备份。

7、建议客户每隔一定时间手动备份一次。

三、数据库置疑的修复1、正常的备份、SQL数据库恢复方式正常方式下，我们要备份一个数据库，首先要先将该数据库从运行的数据服务器中断开，或者停掉整个数据库服务器，然后复制文件。

卸下数据库的命令：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是数据库日志文件。

例子：假设数据库为pdm，其数据文件为pdm_data.mdf，日志文件为pdm_log.ldf。

sql2000中MSDB数据库置疑状态的解决方法问题：我的SQL Server 2000的MSDB数据库，因为不正常关机，造成了置疑状态，请问采用什么方法能够弥补？解决方法一：你可以采用以下的代码进行修复：USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='msdb'Gosp_dboption 'msdb', 'single user', 'true'GoDBCC CHECKDB('msdb')Goupdate sysdatabases set status =28 where name='msdb'Gosp_configure 'allow updates', 0reconfigure with overrideGosp_dboption 'msdb', 'single user', 'false'Go解决方法二：MSDB数据库解决过程难点：由于MSDB数据库不能删除，将其文件拷出来，再次附加数据库，但新的附加数据库不能叫MSDB，也就是不能同名，遇到了困难。

1：先停止整个数据库，将该数据库的文件msdbdata.mdf和msdblog.ldf拷贝粘贴出来到另一个目录下。

2：将以上的文件再拷贝到另一个目录下，也就是说复制两次。

3：选择数据库右击鼠标 --》所有任务--》附加数据库将复制出的一个备份文件附加上去，其中，数据库名称叫MSDB1，用户是SA或ADMINISTRATOR。

4：将MSDB1数据库备份，备份成一个文件，当时我的叫MSDB。

SQL数据库置疑解决方法
一、SQL数据库置疑
1.数据库安全问题
为了保护数据库，需要确保数据库中的信息不被恶意攻击、篡改或盗窃，从而避免造成不可挽回的损失。

2.数据库可靠性问题
可靠性是指数据库系统必须在不同的时间片段可靠运行，即使是在发生系统故障的情况下，用户也能够一直获取服务。

只有数据库系统可靠性良好，才能够实现数据库系统的高安全性要求。

3.数据库性能问题
要满足用户的需求，必须保证数据库服务器能够达到最佳性能，避免出现数据库访问运行缓慢的问题，以及查询数据库时出现的查询延时、查询次数多等问题。

4.数据库维护问题
数据库系统是一个复杂的系统，在日常运行中难免会出现数据库系统故障、业务变更需求等情况。

数据库系统维护对于保证系统可靠性，提高系统性能至关重要。

1.数据库安全问题
（1）做好安全设置，为数据库设置正确的授权，只允许拥有访问权限的用户进行访问，并设置访问日志，记录访问和更改的用户，以及操作的时间等信息。

（2）定期备份数据库，将备份数据存放到安全的位置。

怎样修复SQLSERVER数据库置疑问题(doc 8页)你可以看到在SQLSERVER 的ERROR LOG 和OS的应用程序日志中应该有1105的错误信息:SQL Server事务日志可能会被填满，这会阻止之后的数据库操作，包括UPDATE，DELETE，INSERT 和CHECKPOINT。

事务日志填满会导致1105错误:Can't allocate space for object syslogs in database dbname becausethe logsegment is full。

If you ran out of space in syslogs，dumpthe transaction log。

Otherwise use ALTER DATABASE orsp_extendsegment to increase the size of the segment。

这种现象可能出现于任何一个数据库中，包括Master和TempDB。

一些难以预见的因素可能消耗日志空间。

例如:一个大型事务，尤其像批量数据更新、插入或删除。

一个未提交的事务。

检查点处理程序截除时所需的带宽过大。

截除时超过阈值上述各种条件互相作用的结果。

用于发布的标记事务没有被日志读取程序读走下面是修复的步骤和收缩日志的步骤:1.在命令提示符下运行以下命令启动SQL Server：SQLSERVER -f -m备注：-m 开关以单用户模式启动SQL Server。

在单用户模式下，只能成功建立一个连接。

请注意是否有任何其他客户机或服务可能会在您通过SQL Server 查询分析器建立连接前使用那个连接。

2. 重置置疑数据库的状态。

sp_resetstatus 'database_name')GO--更改该数据库以添加一个1GB 大小的新日志文件ALTER DATABASE db_nameADD LOG FILE( NAME = db_name_log2,FILENAME = 'F:MSSQLDatadb_name_log2.ldf',SIZE = 1000MB,FILEGROWTH = 20MB),GO4. 停止并重新启动SQL Server:用新的数据文件或日志文件所提供的额外空间，SQL Server 应该能完成数据库的恢复。

MSSQL数据库置疑的说明及修复方法✧M SSQL 官方对suspect（‘置疑’，SQL2005中文为‘可疑’）状态的解释：“至少主文件组可疑或可能已损坏。

在SQL Server 启动过程中无法恢复数据库。

数据库不可用。

需要用户另外执行操作来解决问题。

”✧S QL Server 数据库置疑通常由于以下几种情况导致：1、因SQL服务意外退出导致数据库置疑，例如突然断电导致数据库日志文件损坏，下次启动后数据库变为置疑状态。

2、数据库文件所在的磁盘分区没有可用空间，导致恢复数据库的操作不能完成，数据库变为置疑状态。

3、数据库文件组已满，这种情况通常发生在MSDE或SQL 2005 Express，因为它们对数据库文件限制了大小，不超过2G或4G；当单个的数据库文件接近2G或4G很容易出现数据库置疑的情况；另外，当数据库文件所在磁盘分区格式为FAT32时，也有可能出现这种情况，FAT32格式的磁盘分区单个文件不能超过4G，当单个的数据库文件接近4G很容易出现数据库置疑的情况。

4、数据库文件设置为不自动增长，或设置为自动增长但限制了文件大小。

5、此外，其它非法的操作也有可能导致数据库置疑。

✧以下提供几种解决V3数据库置疑的办法：解决客户那里出现数据库置疑通常使用第一或第二种方法，解决问题时请根据实际情况处理提示：按以下方法修复数据库后，还需要用户密切观察一下V3服务器是否能正常运行、服务器是否有出错；查看服务器是否有出错可以右击服务管理器－‘工具’－‘日志’，在弹出的事件日志窗口中，查看应用程序日志中是否有OSERVER3的错误信息；如果有出错信息可能会出现数据收集不完整等问题，请即时联系我们解决。

问题一：SQL 2005 数据库置疑的解决方法SQL SERVER 2005，数据库置疑，可以尝试通过以下办法解决：--第一步：新建查询，执行以下SQL 语句；USE masterGOSP_CONFIGURE'ALLOW UPDATE',GORECONFIGURE WITH OVERRIDEGOALTER DATABASE OCULAR3 SET EMERGENCY--设置OCULAR3为紧急模式GOSP_DBOPTION'OCULAR3','SINGLE USER','TRUE'--设置OCULAR3为单用户模式GO--第二步：继续执行以下SQL语句DBCC CHECKDB('OCULAR3')--检查数据库的结构完整性，可能需要比较长时间GO--第三步：继续执行以下SQL语句DBCC CHECKDB('OCULAR3','REPAIR_ALLOW_DATA_LOSS')--修复数据库，可能需要比较长时间；执行到这一步，如果提示需要在单用户模式下运行，那么可以重启一下SQL SERVER服务再执行；GO--第四步:SP_DBOPTION'OCULAR3','SINGLE USER','FALSE'--设置OCULAR3为多用户模式GOALTER DATABASE OCULAR3 SET ONLINE--设置OCULAR3为正常模式GOSP_CONFIGURE'ALLOW UPDATE',0GORECONFIGURE WITH OVERRIDEGO--第五步：继续执行以下SQL语句DBCC CHECKDB('OCULAR3')–再次检查数据库的结构完整性GO问题二：SQL SERVER 2000，因为断电导致数据库被破坏而置疑，可以通过以下办法解决：--第一步：新建查询，执行以下SQL 语句；USE masterGOSP_CONFIGURE'ALLOW UPDATE',1GORECONFIGURE WITH OVERRIDEGO--设置数据库为紧急模式UPDATE sysdatabases SET status= 32768 WHERE name='OCULAR3'GOSP_DBOPTION'OCULAR3','SINGLE USER','TRUE'--设置OCULAR3为单用用户模式GO--第二步：继续执行以下SQL语句DBCC REBUILD_LOG('OCULAR3','d:\ocular3_log_log.ldf')--重建日志文件，--通常重建的日志文件放在与其它数据库文件相同目录下。

各位亲们，
本人也不容易，给力支持支持！
谢谢哦！
数据库质疑决解办法
1.打开开始菜单——所有程序——Microsoft SQL Server 2005——SQL Server Management Studio
如图划黑框的内个：
2.单击打开SQL Server Management Studio，点击连接
打开左边下拉框里面的数据库，找到后面显示黄色括号里面可疑的内个,点击打开，然后点击最左上角的新建查询，把下面语句复制上去
ALTER DA TABASE damiwan_Code SET EMERGENCY
ALTER DA TABASE damiwan_Code SET SINGLE_USER
DBCC CheckDB (damiwan_Code, REPAIR_ALLOW_DA TA_LOSS)
ALTER DA TABASE damiwan_Code SET MULTI_USER
上面damiwan_Code 是我的数据库别跟我填写一样。

填写你自己的哦
如图：
3.点击上面的√，再点击执行（数据量大，时间可能长哦），如图：
然后就ok 了如果还是不行请按照下面的操作试试
4.右击我的电脑点击管理，再点开服务和应用程序，打开SQL Server 配置管理器，点击SQL Server 2005服务，在右边的对话框里面的启动服务，右击都重新启动下。

如图：
就ok 了！！！。

寒山sql数据库修复中心/MSSQL 数据库置疑的说明及修复方法MSSQL官方对suspect（‘置疑’，SQL2005 中文为‘可疑’）状态的解释：至少主文件组可“疑或可能已损坏。

在SQL Server 启动过程中无法恢复数据库。

数据库不可用。

需要用户另外执行操作来解决问题。

”SQL Server1、数据库置疑通常由于以下几种情况导致：因SQL 服务意外退出导致数据库置疑，例如突然断电导致数据库日志文件损坏，下次启动后数据库变为置疑状态。

数据库文件所在的磁盘分区没有可用空间，导致恢复数据库的操作不能完成，数据库变为置疑状态。

数据库文件组已满，这种情况通常发生在MSDE 或SQL 2005 Express，因为它们对数据库文件限制了大小，不超过2G 或4G；当单个的数据库文件接近2G 或4G 很容易出现数据库置疑的情况；另外，当数据库文件所在磁盘分区格式为FAT32 时，也有可能出现这种情况，FAT32 格式的磁盘分区单个文件不能超过4G，当单个的数据库文件接近4G 很容易出现数据库置疑的情况。

2、3、4、5、数据库文件设置为不自动增长，或设置为自动增长但限制了文件大小。

此外，其它非法的操作也有可能导致数据库置疑。

以下提供几种解决V3 数据库置疑的办法：解决客户那里出现数据库置疑通常使用第一或第二种方法，解决问题时请根据实际情况处理提示：按以下方法修复数据库后，还需要用户密切观察一下V3 服务器是否能正常运行、服务器是否有出错；查看服务器是否有出错可以右击服务管理器－‘工具’－‘日志’，在弹出的事件日志窗口中，查看应用程序日志中是否有OSERVER3 的错误信息；如果有出错信息可能会出现数据收集不完整等问题，请即时联系我们解决。

问题一：SQL 2005 数据库置疑的解决方法SQL SERVER 2005，数据库置疑，可以尝试通过以下办法解决：--第一步：新建查询，执行以下SQL 语句；USE master GOAchao_hupu 第1 页Created on 8/31/2008 11:43:00 AMSP_CONFIGURE 'ALLOW UPDATE',1 GO RECONFIGURE WITH OVERRIDE GO ALTER DATABASE OCULAR3 SET EMERGENCY --设置OCULAR3 为紧急模式GO SP_DBOPTION 'OCULAR3','SINGLE USER', 'TRUE' --设置OCULAR3 为单用户模式GO --第二步：继续执行以下SQL 语句DBCC CHECKDB('OCULAR3') --检查数据库的结构完整性，可能需要比较长时间GO --第三步：继续执行以下SQL 语句DBCC CHECKDB('OCULAR3','REPAIR_ALLOW_DA TA_LOSS') --修复数据库，可能需要比较长时间；执行到这一步，如果提示需要在单用户模式下运行，那么可以重启一下SQL SERVER 服务再执行；GO --第四步: SP_DBOPTION 'OCULAR3','SINGLE USER', 'FALSE' --设置OCULAR3 为多用户模式GO ALTER DATABASE OCULAR3 SET ONLINE --设置OCULAR3 为正常模式GO SP_CONFIGURE 'ALLOW UPDATE',0 GO RECONFIGURE WITH OVERRIDE GO --第五步：继续执行以下SQL 语句DBCC CHECKDB('OCULAR3') –再次检查数据库的结构完整性GO问题二：SQL SERVER 2000，因为断电导致数据库被破坏而置疑，可以通过以下办法解决：--第一步：新建查询，执行以下SQL 语句；USE master GO SP_CONFIGURE 'ALLOW UPDATE',1 GO RECONFIGURE WITH OVERRIDE GO --设置数据库为紧急模式UPDATE sysdatabases SET status = 32768 WHERE name = 'OCULAR3' GO SP_DBOPTION 'OCULAR3','SINGLE USER', 'TRUE' --设置OCULAR3 为单用用户模式GO --第二步：继续执行以下SQL 语句DBCC REBUILD_LOG('OCULAR3','d:\ocular3_log_log.ldf') --重建日志文件，--通常重建的日志文件放在与其它数据库文件相同目录下。

数据库质疑修复总结ForSQLS...1 前言本文的步骤基于以下条件：1. SQL Server可以启动。

2. 数据库没有做有效的备份。

3. 当前用户有Sysadmin权限。

数据库质疑的原因会有多种多样，不同的suspect采用的步骤也会有所不同，以下的步骤不能适用所有的情况，但包括了一些基本的步骤。

数据库suspect是指数据库内部处于不一致的状态，很有可能会有数据丢失。

我们推荐您从“好的数据库备份”恢复。

我们这里所指的“好的数据库备份”是指：1. 在做数据库备份之前，您检查过DBCC CHECKDB没有错误。

2. 备份之后的数据库没有更改，或者更改可以忽略。

在做任何修复操作之前，请务必备份.mdf/.ndf以及.ldf文件。

2 SQL Server 2000修复步骤如果没有“好的数据库备份”，我们不能保证没有数据丢失。

以下是恢复suspect数据库（SQL Server 2000）的一般方法，供您参考。

同时在操作下列步骤之前，您可以备份质疑数据库的MDF、NDF、LDF文件，以便以下步骤恢复失败时能够回滚到原来的状态。

1. 在查询分析器中，运行如下命令将数据库置于紧急模式。

Sp_configure 'allow update', 1GoReconfigure with overrideGoBegin TranUpdate master..sysdatabases set status = 32768 where name ='<DatabaseName>’Commit Tran--此处<DatabaseName>需要替代成您出问题的数据库名字。

--以下同GoSelect * from sysdatabases--检查数据库状态是否已经变成 32768Go2. 重启SQL Server服务。

3. 如果第二步中重启服务，数据库再次进入suspect模式，请设置数据库紧急模式，使用BCP方式导出数据。

软件无法登录，提示登录失败或者无法连接到数据库，打开SQL数据库企业管理器，发现在UFDATA_001_2011数据库后面有‘置疑’字样，那么SQL数据库置疑是什么原因产生的呢？又该如何处理解决呢？一、原因分析SQL数据库置疑是数据库日志文件LDF 错误或异常造成的，一般有以下几种原因引起的：1、突然断电，非正常关机，造成日志和事务错误；2、硬件问题，特别是硬盘问题，造成日志和数据文件错误；3、硬盘的空间不够，如日志文件过大。

二、SQL数据库置疑解决办法1、首先停止SQL SERVER服务，把软件安装目录UFSMART下admin中置疑的帐套数据库源文件MDF和LDF备份出来到其他地方去，因为修复不一定成功。

2、将置疑数据库的ufdata.ldf文件删除或者重命名为ufdata1.ldf，然后启动SQL 数据库服务。

将以下脚本语句复制到查询分析器中，如下为修复数据库置疑脚本(账套号：001 年度：2011为例)。

说明：如数据库存放路径为：D:\UFSMART\Admin\ZT001\2011，执行脚本前先停止数据库服务，然后删除此路径下的ufdata.ldf文件，再启用数据库服务执行脚本。

use mastergosp_configure 'allow updates',1goreconfigure with overridegoupdate sysdatabases setstatus=-32768 wheredbid=DB_ID('UFDATA_001_2011')godbccrebuild_log('UFDATA_001_2011','D:\UFS MART\Admin\ZT001\2011\UFDATA.LDF') gosp_dboption 'UFDATA_001_2011','dbo use only','false'gosp_configure 'allow updates',0goreconfigure with overridego3、执行完置疑修复脚本后，如上图提示，数据库 'UFDATA_001_2011' 的日志已重建，这表示修复置疑成功，如果没有这个提示，则可能是无法修复。