sqlserver数据库被质疑(suspect)的解决方案

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 server数据库被置疑解决方法（The SQL Server database is thesolution to doubt）First, make sure that you have backed up the.Mdf and.Ldf files.2. create a database with the same name in SQL Server, and then stop the SQL Server service.3. overwrite the.Mdf and.Ldf files of the new database with the original.Mdf and.Ldf files.4. restart the SQL Server service, which should see the database in doubt (Suspect) state.5. in the SQL query analyzer, execute the following command to allow updating of the system tables:Use masterGoSp_configure 'allow updates', 1Reconfigure with overrideGo6. place this database as an emergency mode:Update, sysdatabases, set, status = 32768, where, name='db_name'Go7. check the errors in the database using the DBCC CHECKDB command:DBCC CHECKDB ('db_name')GO8. if the DBCC CHECKDB command fails, go to the tenth step, or you will first set the database in a single user mode, and then try to fix it:Sp_dboption'db_name',' single user ',' true 'DBCC CHECKDB ('db_name', REPAIR_ALLOW_DATA_LOSS)GOIf the DBCC CHECKDB ("db_name", "REPAIR_ALLOW_DATA_LOSS") command is prompted to indicate that the database is not in a single user mode, restart the SQL Server service, and then proceed with the attempt.9. if the DBCC CHECKDB ('db_name', REPAIR_ALLOW_DATA_LOSS) command fails, go to the tenth step, otherwise the database error will be repaired successfully:Rerun the DBCC CHECKDB ('db_name') command to make sure there are no errors in the database.Clear the query status of the database:sp_resetstatus'db_name'Clear the single user mode state of the database:sp_dboption'db_name',' single user ',' false 'Restart the SQL Server service and, if everything is OK, the database has been successfully restored.10. if the above steps do not solve the problem, please refer to the document in the attached file and try to restore the data in the database by rebuilding the transaction log.If you have only MDF files, the problem is more complex, and we need to rebuild the transaction log directly:1. create a database with the same name in SQL Server, and then stop the SQL Server service.2. overwrite the new.Mdf file with the original LDF file and delete the log file (.Ldf).3. start the SQL Server service and set the database as an emergency mode (ibid.: steps 5 and 6).4. stop and restart the SQL Server service.5. perform the following commands to rebuild the database log file: (here is an example that you will need to use your actual database name)DBCC REBUILD_LOG ('cas_db','D:\cas_db\cas_db_Log.LDF')6. reset the database to a single user mode.The Sql Server database is the solution to doubtEnvironment WIN2000, SQL, server2kProblem: when a database is generally updated, queries are suddenly "doubted" and cannot be used any moreYou can't solve the problem by dealing with it yourself:1, close the SQL Server database, the corresponding database.Mdf.Ldf file moved to other directories, delete the original database2. Start the SQL Server database and create a new database with the same name,3, close the SQL Server database, with the original database.Mdf.Ldf file overwrite new database corresponding file. The problem still exists, it doesn't work.Search for information and solve problems through results online:1, close the SQL Server database, will be questioned database file (.Mdf.Ldf) copy back up.2. Open the SQL Server database and create a new database with the same name,3, close the SQL Server database and overwrite the new database's same name file with the backup.Mdf file4. Open the SQL Server database and execute the following statement in the query analyzer, allowing direct modification of the system directoryUse masterGoSp_configure,'allow, updates', 1GoReconfigure with overrideGoUpdate, sysdatabases, set, status=-32768, where, dbid=DB_ID ('newdb')5. Rebuild the new database logDBCC rebuild_log ('newdb','C:\Program, Files\Microsoft, SQL, Server\MSSQL\Data\newdb_log.ldf')With this step in progress, you may find that the data is ina read-only / offline / state, and proceed to the following operation6, DBCC checkDBCC CHECKDB ('newdb')When you go to this section, you may find that there are errors. You can look at some of the data tables of the prompt. If it is not a critical table, you can let go first.7, set the database as a normal stateSp_dboption,'newdb','dbo, use, Only','false'8, close the database directly modify permissions, do not allow direct modification of the system directorySp_configure,'allow, updates', 0GoReconfigure with overrideGoOf course, my data did not recover at the first step. I've done it all over again, and my database has been restored to normal, and I feel very happy.Total feel, personal feeling, the database was questioned,should be because the database log is too large, the database log has reached 15G. But I'm not sure yet. Keep studying.Come on.SQL2000 database query solution 2009-03-21 09:12 follows the following steps:1. create a new database with the same name2. stop SQL server again3. overwrite the new database file with the same name by using the backup database MDF file4. restart SQL Server5., when you open the enterprise manager, the new database of the same name will appear doubt, first ignore, execute the following statement (pay attention to modify the database name)USE MASTERGOSP_CONFIGURE,'ALLOW, UPDATES', 1, RECONFIGURE, WITH, OVERRIDEGO"UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='database name'GoSp_dboption 'database name', ''single user' ',''true''GoDBCC CHECKDB ('database name')Go"Update sysdatabases set status =28 where name='database name'GoSp_configure,'allow, updates', 0, reconfigure, with, overrideGoSp_dboption 'database name', ''single user' ',''false''GoDatabase query recovery classic/********************************************************** ******** this kind of fault is usually caused by disk read and write problems.* the following statement is the SQL that fixes the database of the headquarters. If you need to fix the database of the segment, change'hbposv5'to'hbposv5_branch'* supermarket star system is implemented directly* shortcut, Invoicing series, pleasechange'hbposv5'to'isd2001v3', and if it is subsection, change to'isd2001v3_branch'* business series, please change'hbposv5'to'isd2001v4', if the segment, changed to'isd2001v4_branch'*********************************************************** *******/Please perform the following statements in the query analyzer. Disconnect all other database connections before execution. It's better to disconnect the network cableUSE masterGoSingle user modeEXEC, sp_dboption,'hbposv5','single, user','TRUE'Go-- database checkingDBCC CHECKDB ('hbposv5')Go- if you return the result with a red prompt text that indicates an error in the database, you need to fix it-- database repairDBCC CHECKDB ('hbposv5', repair_rebuild)GoAgain, database check, and if there is no red prompt text in the return result, the repair is successful;DBCC CHECKDB ('hbposv5')GoOtherwise it means higher levels of repair are required. Try changing the'repair_rebuild'of the repair statementto'repair_allow_data_loss', and then check the database again.- if there are any errors that have not been repaired,Before you quit, be sure to execute the following statement and return to the multi-user modeEXEC, sp_dboption,'hbposv5','single, user','FALSE'GoDatabase query processingStep 1:Create a new database named as the name of the original database.Step 2:Stop SQL ServerStep 3:Replace the old database's MDF file with the corresponding MDF file of the new database and delete the LDF file.Step 4:Restart the SQL Server service, and then run the following command:Use MasterGoSp_configure,'allow, updates', 1Reconfigure with overrideGoBegin tranUpdate, sysdatabases, set, status = 32768, where, name='hbposv5'--Verify, one, row, is, updated, before, committingCommit tranStep 5:Stop SQL and restart the SQL Server service,Then run the following command:DBCC TRACEON (3604)DBCC REBUILD_LOG('db_name','c:\mssql7\data\hbposv5_log.ldf')GoStep 6:Stop SQL, then restart the SQL Server service, and then run: Use masterUpdate, sysdatabases, set, status = 8, where, name ='hbposv5'GoSp_configure,'allow, updates', 0Reconfigure with overrideGoStep 7:Run DBCC CHECKDB (hbposv5) to check the integrity of the databaseNote: all must be replaced with the actual database name.。

解决SQLServer2008数据库质疑（挂起）问题Step1.执行语句，改变数据库状态EXEC SP_RESETSTATUS'Your DBName'GOStep2:重置数据库状态之后,我们就应该对质疑的数据库执行DBCC CHECKDB命令,查看下为什么数据库会出现质疑状态.DBCC CHECKDB('Your DBName')WITH NO_INFOMSGS,ALL_ERRORMSGSGoStep3:找到原因之后,那么就好解决了.看报错信息中,已说明了PK中存在重复值.首先,将每个索引的脚本导出为sql文件.之后再将表中主键栏位里的duplicate的行删除掉Step4:现在最好再立即执行下DBCC CHECKDB命令确认下是否还有错误信息.之后确认没有,那么再将之前索引的脚本创建进去.Step5:在Index创建完毕之后,立即执行下DBCC CHECKDB命令确认下是否还有错误信息.确认无误,那么就需要立即对数据库执行一次完全备份作业.针对SQL2000挂起情况进行修复Step1:设置数据库为紧急模式Use Mastersp_configure'allow updates',1reconfigure with overrideGOUPDATE sysdatabases SET status=32768where name='TEST'GOStep2:停止数据库服务通过Windows服务或者SQLServer管理器.Step3:把原始数据库的数据文件DBNAME_DAT.MDF,DBNAME_LOG.LDF移走Step4:启动SQL Server服务Step5.重新建立一个同名的数据库TEST；USE masterGOCREATE DATABASE TESTON(NAME=DBNAME_DAT,FILENAME='C:',SIZE=10,FILEGROWTH=5)LOG ON(NAME='DBNAME_LOG',FILENAME='g:',SIZE=5MB,FILEGROWTH=5MB)GOStep6:设置数据库运行在单用户的模式:USE MASTERGOALTER DATABASE TEST SET SINGLE_USERGOStep7:停掉SQL服务Step8:把原来的数据文件再覆盖回来Step9:启动SQL Server服务Step10:设置数据库为紧急模式Use Mastersp_configure'allow updates',1reconfigure with overrideGOUPDATE sysdatabases SET status=32768where name='TEST'GOStep11:修复数据库错误DBCC CHECKDB('TEST',REPAIR_ALLOW_DATA_LOSS)Step12.恢复数据库为多用户模式USE MASTERGOALTER DATABASE TEST SET MULTI_USERGOStep13.恢复SQLSERVER原始的配置USE MATERGOUPDATE sysdatabases SET status=4194320where name='TEST'GOStep14:配置SQLSERVER不允许更新系统表USE MASTERGOsp_configure'allow updates',0reconfigure with overrideGOStep15:重新启动MSSQLSERVER服务,最好重新启动操作系统.Step16:备份数据库特殊情况:不知道为什么，质疑修复后，数据库恢复正常了。

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种重启服务--------------------------------------------------日志文件丢了，建一个日志文件--------------------------------------------------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数据库置疑
1.数据库安全问题
为了保护数据库，需要确保数据库中的信息不被恶意攻击、篡改或盗窃，从而避免造成不可挽回的损失。

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

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

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

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

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

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

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

Sql Server数据库被置疑解决方法首先确认已经备份了.mdf和.ldf文件。

2.在SQL Server中新建一个同名的数据库，然后停止SQL Server服务。

3.用原有的.mdf和.ldf文件覆盖新建数据库对应的.mdf和.ldf文件。

4.重新启动SQL Server服务，这是应该会看到这个数据库处于置疑（Suspect）状态。

5.在SQL查询分析器中执行以下命令，以允许更新系统表：use mastergosp_configure‘allow updates’,1reconfigure with overridego6.将这个数据库置为紧急模式：update sysdatabases set status=32768where name= 'db_name'go7.使用DBCC CHECKDB命令检查数据库中的错误：DBCC CHECKDB(‘db_name’)GO8.如果DBCC CHECKDB命令失败，请转至第10步，否则先将数据库置为单用户模式，再尝试对其进行修复：sp_dboption'db_name',’single user’,’true’DBCC CHECKDB(‘db_name’,REPAIR_ALLOW_DATA_LOSS)GO如果在执行DBCC CHECKDB(‘db_name’, REPAIR_ALLOW_DATA_LOSS)命令时提示说数据库未处于单用户模式状态的话，则重新启动SQL Server服务，然后继续尝试。

9.如果DBCC CHECKDB(‘db_name’,REPAIR_ALLOW_DATA_LOSS)命令失败，请转至第10步，否则若成功修复了数据库中的错误：重新执行DBCC CHECKDB(‘db_name’)命令，确认数据库中已没有错误存在。

清除数据库的置疑状态：sp_resetstatus'db_name'清除数据库的单用户模式状态：sp_dboption'db_name',’single user’,’false’重新启动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')--重建日志文件，--通常重建的日志文件放在与其它数据库文件相同目录下。

SQLSERVER2024数据库可疑的解决步骤
1、调整数据库的权限控制：限制对数据库的访问权限，并加强对相关权限的管理，以防止不法利用或者滥用权限。

2、建立备份规则：定期做备份，以防止数据库受损每周、每月或者按照其他定期，都要做定期备份，保留关键数据，以应付突发状况。

3、合理设置数据库安全策略：根据不同的业务特点设定合理的安全策略，并及时调整安全策略，使之保持最新最安全，以防止系统暴露在安全威胁之下。

4、完善用户管理：多数情况下，系统中的可疑行为和一般用户的使用方式是不一样的，因此建立有效的用户管理，以有效检测和预防可疑行为，定期更换用户密码，加强对未经授权用户访问的保护。

5、改进数据库性能：在数据库管理系统中，很多可疑行为都是和数据库性能有关的，因此应该尽可能提高数据库性能，比如，使用存储过程和索引，减少数据库执行查询所需的时间，从而提高数据库的可用性和可靠性。

6、限制SQL语句：确保数据库系统执行的SQL语句是安全的，限制非法、未经授权的SQL语句，如禁止t-sqlIinsert语句，以避免恶意插入或删除数据，避免恶意程序的注入。

SQL SERVER2000数据库质疑的解决方法先分离数据库企业管理器--右键suspect的数据库--所有任务--分离数据库然后备份你的suspect数据库的文件,再按下面的步骤处理:1.新建一个同名的数据库2.再停掉sql server3.用suspect数据库的文件覆盖掉这个新建的同名数据库4.再重启sql server5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，执行下面的语句（注意修改其中的数据库名)USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='his222'Gosp_dboption 'test', 'single user', 'true'GoDBCC CHECKDB('test')Goupdate sysdatabases set status =28 where name='test'Gosp_configure 'allow updates', 0 reconfigure with overrideGosp_dboption 'test', 'single user', 'false'Go6.完成后一般就可以访问数据库中的数据了,这时,数据库本身一般还要问题,解决办法是,利用数据库的脚本创建一个新的数据库,并将数据导进去就行了.如果这样改不加数据库状态,你就把数据库导成一个新库来代替旧库吧企业管理器--右键你的数据库--所有任务--导出数据--目标标数据库选择新建--选择"在两个sql数据库之间复制对象和数据"--把"包含扩展属性"选上,其他的根据需要选择--最后完成如果SQL Server 因为磁盘可用空间不足，而不能完成数据库的恢复，那么SQL Server 2000 会返回错误1105 并且将sysdatabases中的status列设为置疑。

数据库置疑状态的解决方法问题：我的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。

MS-SQLSERVER数据库SUSPECT状态如何解决如何重置数据库Suppect(置疑)状态一、出现这种情况的原因如果在日常运行当中，数据库的文件或日志增长方式设为以下两种模式：1、文件不自动增长此种状态下，如果数据库中的数据或日志增长到设定的文件大小时，继续添加数据时就没有足够的空间时，MS SQL SERVER将把数据库标记为Suspect（置疑）2、文件自动增长但限制最大文件大小此种状态下，如果数据库中的数据或日志增长到设定的最大文件大小时，继续添加数据时就没有足够的空间时，MS SQL SERVER将把数据库标记为Suspect（置疑）3、文件自动增长也没限制文件大小，但存放文件的磁盘剩余空间不够了4、意外掉电，造成磁盘文件损坏5、二、解决方法：3、方法一：释放含有相关数据库日志文件的任意磁盘驱动器上的磁盘空间。

释放的磁盘空间使恢复系统可以自动地增长数据或事务日志文件。

执行sp_resetstatus 重置置疑状态。

通过执行DBCC DBRECOVER（数据库）运行恢复操作。

方法二：释放另一个磁盘驱动器上的磁盘空间。

把可用磁盘空间不足的事务日志文件移动到第一步所指的磁盘驱动器上。

执行sp_detach_db 分离数据库。

执行sp_attach_db 附加数据库，指向被移动的文件。

方法三：向置疑数据库添加一个日志文件，然后执行sp_add_log_file_recover_suspect_db 以便在数据库上运行恢复操作。

解决错误信息1105，然后使数据库联机对于任意一个含有错误信息1105 提到的文件组中文件的磁盘，释放其磁盘空间。

释放磁盘空间使得文件组中的文件可以增长。

执行sp_resetstatus 重置置疑状态。

执行DBCC DBRECOVER（数据库）运行恢复操作。

方法四：释放另一个磁盘驱动器上的磁盘空间。

将可用磁盘空间不足的文件组中的数据文件移动到第一步所指的磁盘驱动器上。

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_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。