SQL数据库置疑解决方案(原因分析、预防措施、修复方法)附图
sql2000数据库置疑修复
方法一:
1.停止SQL Server的服务,然后备份MS SQL Server的安装目录下的\data子目录. 注意:整个目录目录备份或只备份data目录下置疑数据库的两个文件,一个数据文件dbname_data.mdf,一个dbname_log.ldf(也有可能非此命名),同时查看磁盘空间是否有足够的空间；
8.运行dbcc checkdb(db_name) 检查数据库的完整性 修复数库
注：都要把 dbname 替换成真实的数据库名字。
2.启用SQL Server的服务。打开查询分析器(Query Analyzer)的工具,以用户sa登录；
3.输入如下指令后点工具栏上的绿色箭头运行(快捷键F5)， use master go sp_resetstatus dbname go
4.运行完毕后退出此工具,停止SQL Server的服务.
5.在MS SQL Server的安装目录下，有一个\data子目录，其中存放数据文件，包括SQL Server和本系统的数据文件，删除置疑数据库的日志文件dbname_log.ldf(也有可能非此命名).
6.启动SQL Server的服务.
7.打开企业管理器(Enterprise Manager)的工具,查看数据库(database)节点下的dbname是否恢复。
4.停止SQL Server 的服务,再重新启动SQL Server 服务.
5.打开SQL Server 的查询分析器(Query Analyzer),以用户 sa 登录。输入如下指令后点工具栏上的绿色箭头运行，运行完毕后退出此工具: use master go DBCC DBRECOVER (dbname) go
SQL拯救置疑
工作中已经碰到两次这种情况了，想想还是应该把他记录下来，利人利己。
通常这个问题是由于硬盘空间不够或硬盘读写错误造成的。
问题现象：数据库后面有“置疑”字样，查看系统事务日记出现以下错误：错误1---------------------------------------------错误: 823，严重度: 24，状态: 2I/O error 23(数据错误 (循环冗余检查)。
) detected during read at offset0x00000000200000 in file 'C:\Program Files\Microsoft SQLServer\MSSQL\Data\Jiapei_Data.MDF'.错误2---------------------------------------------错误: 3313，严重度: 21，状态: 2恢复数据库 'Jiapei' 的日志中记录的操作时出错。
出错位置在日志记录 ID (274:377:2)。
错误3---------------------------------------------错误: 3313，严重度: 21，状态: 2Error while redoing logged operation in database 'Jiapei'. Error at log record ID (274:377:2).数据库可以分离，但分离后无法附加，附加时出现“823”号错误。
解决方法：1、新建一同名数据库（文件名，文件组都和原来的一样），然后停止数据库服务，用原来文件替换新建的数据库文件，启动数据库，该数据库被设为suspect(质疑)2、把数据库改成紧急模式：sp_configure 'allow', 1reconfigure with overrideupdate sysdatabases set status = 32768 where name = '数据库名'3、把LDF文件改名，再执行DBCC REBUILD_LOG ('数据库名', 'E:\fdzz\database\fdzz1204_Log.LDF' )4、恢复数据库紧急模式update sysdatabases set status = 0 where name = '数据库名'执行restore database 数据库名 WITH RECOVERYsp_configure 'allow', 0reconfigure with override5、然后用DBCC CHECKDB ('数据库名')看看有没有错误6、如果上面还是不行，试试吧数据库设为紧急模式，应该可以看到数据了，在把数据导出到一个新的数据库。
数据库置疑_及修复
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' /* 关闭单用户模式*/如果问题依然存在，最笨的一个方法就是新建另一个数据库，把原数据库各个表的数据导出到新建数据库表中。
用友软件SQL数据库置疑修复文档
用友软件SQL数据库置疑修复文档背景2021年4月，发现公司用友软件的SQL数据库出现了一些置疑的情况，例如数据表数据不一致等问题。
经过初步调查，发现是由于数据库在一段时间内没有正常备份导致的问题。
因此，需要对数据库进行修复工作，以确保数据的完整性和准确性。
修复步骤1. 备份数据库在进行修复工作前，首先要备份数据库，以免操作失误导致数据丢失。
可以使用SQL Server Management Studio等工具来进行数据库备份。
2. 查找问题点查找问题点是修复工作的核心。
可以通过以下步骤进行操作：1.使用SQL Server Management Studio查看数据表的结构和数据；2.比对不同时间点的数据表数据，查找数据不一致的点；3.查看SQL Server的日志文件，查找异常的SQL语句。
通过以上步骤可以发现置疑的数据表以及具体出现问题的时间点和SQL语句。
3. 进行修复操作修复操作需要严格按照以下步骤进行：1.暂停所有与数据库相关的应用程序；2.使用SQL Server Management Studio等工具，逐条运行SQL语句，对数据表进行修复；3.重启所有与数据库相关的应用程序。
在进行修复工作前，需要对每一条SQL语句进行仔细的检查和确认，确保语句正确无误，否则可能导致数据更加混乱。
4. 检查修复效果修复操作完成后，需要进行检查，以确保修复效果符合预期。
可以通过以下步骤进行操作：1.使用SQL Server Management Studio查看数据表的结构和数据；2.比对不同时间点的数据表数据，查看修复效果；3.重启所有与数据库相关的应用程序，查看是否存在问题。
如果修复后仍存在问题，则需要重新查找问题点，并进行修复操作，直到修复效果符合预期。
注意事项在进行数据库修复工作时，需要注意以下几点：1.备份数据库是重要的保证，不能忽视；2.SQL语句需要仔细检查，以免操作失误导致数据问题更加严重；3.修复操作需要停止所有与数据库相关的应用程序，确保数据准确性。
SQL数据库置疑的解决方法
SQL2000数据库置疑的解决方法首先,在任何操作之前,必须要备份数据库(重要)一、分离数据库1、点击“程序》Microsoft SQL Server》企业管理》”，打开企业管理器2、展开服务器组，然后展开服务器，选中要分离的数据库3、点击鼠标右键“所有任务》分离数据库”，出现如下窗口4、点击确定，该选定的数据库就被分离。
5.分离后,把原数据库里面.MDF（主数据文件）.LDF（事务日志文件）这两个文件复制到目标盘下,例:D盘下注意事项，只有“使用本数据库的连接”数为0时，该数据库才能分离。
所以分离数据库时尽量断开所有对要分离数据库操作的连接，如果还有连接数据库的程序，会出现数据库的连接状态窗口，显示正在连接此数据库的机器以及名称，点击清除按钮将从服务器强制断开现有的连接。
二、附加数据库1、在附加数据库之前,首先要移动数据库文件在附加数据库之前，您必须将与数据库关联的 .MDF（主数据文件）.LDF（事务日志文件）这两个文件复制到目标硬盘下，或是同一服务器的不同硬盘目录下。
这两个文件一般位于C：\Program Files\Microsoft SQL Server\MSSQL\Data目录下。
2、点击“程序》Microsoft SQL Server》企业管理》”，打开企业管理器3、展开服务器组，然后展开服务器4、右击"数据库"，然后选择“所有任务》附加数据库”，弹出窗口5、输入要附加的数据库的MDF名称。
如果不确定文件位于何处，单击浏览（"..."）搜索。
若要确保指定的 MDF 文件正确，请单击"验证"。
在"附加为"框内，输入数据库的名称。
数据库名称不能与任何现有数据库名称相同。
指定数据库的所有者6、单击"确定"按钮。
新附加的数据库的数据库节点即创建在"数据库"文件夹中重启双机1.此时数据库分离,附加完成,必须重启一次双机修复置疑1,双机重启后,数据库置疑下面所有修复置疑的语法，在没有特别提到时，默认数据库都请选择（Master）数据库）2,修复置疑（必须在SQL的查询分析器中才能进行数据修复置疑工作）A、打开查询分析器，当数据置疑之后在查询分析器中是看不到置疑的数据库名称的，所以进入查询分析器之后，所选数据库默认（Master）数据库即可。
SQL置疑数据库处理方法
SQL置疑数据库处理方法：1.新建一个同名的数据库。
2.停掉sql server(注意不要分离数据库)。
3.用原数据库（质疑的那个）的数据文件覆盖掉这个新建的数据库文件。
（以上1、2、3步骤是针对把质疑数据库文件放到另外的计算机处理的情况，如果就在本机处理，可以省略，但在处理前一定要注意备份数据库文件。
）4.再重启sql server。
5.此时打开企业管理器时会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)。
USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOUPDATE 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 overrideGosp_dboption '置疑的数据库名', 'single user', 'false'Go6.完成后一般就可以访问数据库中的数据了；这时，数据库本身一般还要问题，解决办法是利用数据库的脚本创建一个新的数据库，并将数据导进去就行了，或者把数据库导成一个新库来代替旧库，先把数据导出，然后重启计算机后再导入就OK了。
步骤如下：企业管理器--右键你的数据库--所有任务--导出数据（导入数据）--目标标数据库选择新建--选择"在两个sql数据库之间复制对象和数据"--把"包含扩展属性"选上,其他的根据需要选择--最后完成。
数据库损坏和置疑修复方案
数据库损坏和置疑修复方案一、数据库置疑和损坏产生原因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数据库置疑解决方案(原因、预防、修复)附图
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。
SqlServer数据库（可疑）解决办法4种
SqlServer数据库（可疑）解决办法4种重启服务--------------------------------------------------日志文件丢了，建一个日志文件--------------------------------------------------SQL SERVER 2005 数据库状态为“可疑”的解决方法--MyDB为修复的数据名USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOALTER DATABASE MyDB SET EMERGENCYGOsp_dboption 'MyDB', 'single user', 'true'GODBCC CHECKDB('MyDB','REPAIR_ALLOW_DATA_LOSS')GOALTER DATABASE MyDB SET ONLINEGOsp_configure 'allow updates', 0 reconfigure with overrideGOsp_dboption 'MyDB', 'single user', 'false'GO-------------------------------------------------当数据库发生这种操作故障时，可以按如下操作步骤可解决此方法，打开数据库里的Sql 查询编辑器窗口，运行以下的命令。
1、修改数据库为紧急模式ALTER DATABASE Zhangxing SET EMERGENCY2、使数据库变为单用户模式ALTER DATABASE Zhangxing SET SINGLE_USER3、修复数据库日志重新生成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。
SQL数据库置疑解决方法
SQL数据库置疑解决方法
一、SQL数据库置疑
1.数据库安全问题
为了保护数据库，需要确保数据库中的信息不被恶意攻击、篡改或盗窃，从而避免造成不可挽回的损失。
2.数据库可靠性问题
可靠性是指数据库系统必须在不同的时间片段可靠运行，即使是在发生系统故障的情况下，用户也能够一直获取服务。
只有数据库系统可靠性良好，才能够实现数据库系统的高安全性要求。
3.数据库性能问题
要满足用户的需求，必须保证数据库服务器能够达到最佳性能，避免出现数据库访问运行缓慢的问题，以及查询数据库时出现的查询延时、查询次数多等问题。
4.数据库维护问题
数据库系统是一个复杂的系统，在日常运行中难免会出现数据库系统故障、业务变更需求等情况。
数据库系统维护对于保证系统可靠性，提高系统性能至关重要。
1.数据库安全问题
（1）做好安全设置，为数据库设置正确的授权，只允许拥有访问权限的用户进行访问，并设置访问日志，记录访问和更改的用户，以及操作的时间等信息。
（2）定期备份数据库，将备份数据存放到安全的位置。
MSSQL数据库置疑的说明及修复方法
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.数据备份与恢复：定期对数据库进行备份，以防止数据丢失。
在发现问题时，可以通过恢复备份数据的方式来解决。
这种方法可以保证数据的完整性，但需要小心处理备份数据的存储和保护。
2.数据库监控：通过监控数据库系统的运行状态，例如CPU利用率、内存使用量、磁盘IO等指标，及时发现潜在的问题，并采取相应的措施来解决。
可以使用各种数据库监控工具和系统来实现自动监控。
3.性能优化：通过对数据库系统进行性能优化，提高系统的响应速度和吞吐量，以减少潜在的问题。
可以通过调整数据库参数、索引优化、SQL语句优化等方式来优化性能。
此外，还可以通过分析和监控数据库运行时的性能指标，发现性能瓶颈，并采取相应的措施来解决。
4.数据一致性检查：定期对数据库中的数据进行一致性检查，以确保数据的准确性和完整性。
可以通过比较多个副本之间的数据来检查数据的一致性，还可以通过执行一些自定义的数据一致性检查程序来检查数据的完整性。
5.数据冲突解决：当多个用户同时对数据库进行更新时，可能会出现数据冲突的问题。
这种情况下，可以采用乐观锁或悲观锁的方式来解决。
乐观锁是通过在更新操作之前检查数据是否被修改来解决数据冲突，悲观锁则是在更新操作期间锁定相应的数据，以防止其他用户同时更新。
6.异常处理：当数据库发生异常或错误时，需要及时采取相应的措施来处理。
可以通过异常处理机制来捕获和处理数据库异常，例如对异常日志进行分析，排查原因，并采取相应的措施来解决。
7.数据库监督与审计：对数据库的操作进行监督和审计，以确保数据的安全性和合规性。
可以通过审计日志、访问控制列表等方式对数据库进行监督，及时发现潜在的问题，防止未授权的访问和数据泄露。
综上所述，数据库置疑处理方法包括数据备份与恢复、数据库监控、性能优化、数据一致性检查、数据冲突解决、异常处理以及数据库监督与审计等。
SQL2005数据库质疑图文解决办法
各位亲们，
本人也不容易，给力支持支持！
谢谢哦！
数据库质疑决解办法
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数据库置疑状态的解决方法
数据库置疑状态的解决方法问题：我的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.BAK。
5：选择置疑的数据库MSDB，选择恢复数据库，将刚才备份出来的数据库强行恢复到MSDB。
SQL数据库置疑解决方法
SQL数据库置疑解决方法
条件：原库的.mdf 文件是完好的即可。
(注意：数据最好有多个备份)
请在SQL Server的查询分析器中按以下步骤执行
假设数据库名为: db (如果您的数据库名不是db,需要更改以下语句中相应的db为您的数据库名称)
0.建立一个空库，然后将有数据的.mdf文件复制过来
覆盖现有的空库的.mdf文件。
1.把数据库设成紧急状态:
然后在SQL查询分析器中，选到master数据库，输入以下语句执行（一条一条执行）
sp_configure 'allow',1
reconfigure with override
update sysdatabases set status=32768 where name='db'
2.重建日志文件（请将路径换成你的数据文件路径）
D:\MSSQL$PROD\Data\为存放数据库文件的路径
db _log2.ldf为一个新的不存在的文件，在执行以下语句时将自动建立
dbcc rebuild_log(' db','D:\MSSQL$PROD\Data\ db _log2.ldf')
3.取消紧急模式（一条一条执行）
update sysdatabases set status=0 where name=' db'
restore database db with recovery
sp_configure 'allow',0
reconfigure with override
4.重起sql server
5.ok。
解决sql数据库被质疑的故障
在实际的管理中经常会遇到 机，前者的 G1/0/1 和后者的 在该设备上。在 SW2 上创建
AP 无法关联到 WLC 的问题。 Fa 0/1 通过 Trunk 连接。无 VLAN 10 和 VLAN 20，其地址
实际上，有很多因素都会导 线 控 制 器 WLC 的 Port1 和 范 围 分 别 为 172.16.1.0/24
当 指 定“REPAIR_ALLOW_ D A T A _ L O S S ”来 作 为 D B C C CHECKDB 命令参数，该程序将
检 查 和 修 复 报 告 的 错 误，但 是，这 些 修 复 可 能 会 导 致 一 些数据丢失。
DBCC CheckDB (Perf_db , REPAIR_ALLOW_DATA_LOSS)
盘空间不够或 硬盘读写错误， 异常关机等原 因 导 致 SQL 数
心（IMC），客户端安装终端认
据 库 被 质 疑，经 过 反 复 尝 试
证 程 序 进 行 上 网 认 证。iMC
解决方法如下。
（智能管理中心）依赖数据库，
打开数据库里的 SQL 查
目前 iMC 在 Windows 环境下
询 编 辑 器 窗 口，运 行 以 下 命
【上接第157页】 行 时 间 过 长 就 要 终 止 执 行，改 用 手 动 修 改 成单用户模式，方法很简单 ：在 Perf_db 数据库右键单击选属 性，在弹出的对话框中选择“选 项”之后在右边的选项中找到 “限 制 访 问”，在 下 拉 框 中 选 择 “SINGLE_USER”之后确定。
3. 修复数据库日志重新 生 成，此 命 令 检 查 的 分 配、结 构、逻辑完整性和所有数据库 中的对象错误。
支 持 SQL 2005 和 SQL 2008
数据库置疑修复
软件无法登录，提示登录失败或者无法连接到数据库，打开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' 的日志已重建，这表示修复置疑成功，如果没有这个提示，则可能是无法修复。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SQL数据库置疑解决方案
一、数据库置疑产生的原因
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_db
s_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。
下面我们讨论一下如何备份、恢复该数据库。
卸下数据库：sp_detach_db 'pdm'
连接数据库：sp_attach_db 'pdm','C:\Program Files\Microsoft SQL
Server\MSSQL\Data\pdm_data.mdf','C:\Program Files\Microsoft SQL Server\MSSQL\Data\pdm_log.ldf'
sp_attach_single_file_db 'pdm','C:\Program Files\Microsoft SQL
Server\MSSQL\Data\pdm_data.mdf'
2、只有mdf文件的恢复技术
由于种种原因，我们如果当时仅仅备份了mdf文件，那么恢复起来就是一件很麻烦的事情了。
如果您的mdf文件是当前数据库产生的，那么很侥幸，也许你使用
sp_attach_db或者sp_attach_single_file_db 可以恢复数据库，但是会出现类似下面的提示信息
设备激活错误。
物理文件名 'C:\Program Files\Microsoft SQL
Server\MSSQL\data\pdm_Log.LDF' 可能有误。
已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\ pdm_log.LDF' 的新日志文件。
但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。
你也许会得到类似下面的错误信息
服务器: 消息 1813，级别 16，状态 2，行 1 未能打开新数据库 'pdm'。
CREATE DATABASE 将终止。
设备激活错误。
物理文件名 'd:\pdm_log.LDF' 可能有误。
怎么办呢？别着急，下面我们举例说明恢复办法。
现在我从其他机器上拷贝回来了数据库文件pdm_Data.MDF到本计算机上，存放到了E盘的一个文件夹里A．我们使用SQL Server企业管理器建立一个供恢复使用的数据库‘pdm’，存放在E盘（不要与拷贝回来的数据库放到一个文件夹就行）。
B．停掉数据库服务器。
C．将刚才生成的数据库的日志文件pdm_log.ldf删除，用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件pdm_data.mdf。
D．启动数据库服务器。
此时会看到数据库pdm的状态为“置疑”。
这时候不能对此数据库进行任何操作。
E．设置数据库允许直接操作系统表。
此操作可以在SQL Server Enterprise Manager里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页
面中将“允许对系统目录直接修改”一项选中。
也可以用‘SQL查询分析器’执行如下语句来实现。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
F．设置pdm为紧急修复模式，运行‘SQL查询分析器’执行如下语句来实现。
update sysdatabases set status=-32768 where dbid=DB_ID('pdm')
此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表，但是仅仅有系统表
G．下面执行真正的恢复操作，重建数据库日志文件
dbcc rebuild_log('pdm','E:\pdm_log.ldf')
执行过程中，如果遇到下列提示信息：
服务器: 消息 5030，级别 16，状态 1，行 1 未能排它地锁定数据库以执行该操作。
DBCC 执行完毕。
如果 DBCC 输出了错误信息，请与系统管理员联系。
说明您的其他程序正在使用该数据库，如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了pdm库的系统表，那么退出SQL Server Enterprise Manager就可以了。
正确执行完成的提示应该类似于：
警告: 数据库 'pdm' 的日志已重建。
已失去事务的一致性。
应运行 DBCC CHECKDB 以验证物理一致性。
将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。
如果 DBCC 输出了错误信息，请与系统管理员联系。
此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。
此时可以访问数据库里面的用户表了。
H．验证数据库一致性（数据库较大时会耗费一些时间，此步可省略）
dbcc checkdb('pdm')
一般执行结果如下：
CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 'pdm' 中）。
DBCC 执行完毕。
如果 DBCC 输出了错误信息，请与系统管理员联系。
I．设置数据库为正常状态
sp_dboption 'pdm','dbo use only','false'
如果没有出错，那么恭喜，现在就可以正常的使用恢复后的数据库啦。
J．最后一步，我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。
因为平时直接操作系统表是一件比较危险的事情。
当然，我们可以在SQL Server Enterprise Manager里面恢复，也可以使用如下语句完成
sp_configure 'allow updates',0
go
reconfigure with override
go
会出现以下信息，此时就可以正常使用数据库了。