数据库置疑解决方法

关于数据库置疑之后连接不上解决办法技术支持三组[维护经验]2003-3-19 16:22:43关于数据库置疑之后连接不上解决办法数据库在使用的过程中，突然处于置疑状态，用通常连接数据库的三种方式连接都失败。

连接时详细错误为“错误9003：LSN无效。

该LSN是传递给数据库‘UFDATA_001_2003’中的日志扫描操作的”此种情况是因为数据库的日志文件崩溃。

碰见此类数据库日志文件出错的情况，用户数据如果又没有备份，想把数据恢复回来。

请按如下六步操作,假设用户出现置疑的数据库名为UFDATA_001_2003，（帐套为001）文件名为ufdata.mdf和ufdata.ldf.1)新建帐套130，路径为F:\data\2)停止SQL的服务，删除F:\data\zt130\2003下ufdata.mdf和ufdata.ldf,把原001帐套下的ufdata.mdf拷贝回F:\data\zt130\2003目录下3）重新启动SQL，此时数据库处于置疑状态。

4）在查询分析器里执行如下语句-----sp_configure 'allow updates', 1goreconfigure with overridegouse mastergoupdate sysdatabases set status = 32768where name = 'UFDATA_130_2003'gosp_configure 'allow updates', 0goreconfigure with override5）重新启动SQL service服务。

此时数据库已连接上，处于紧急模式。

只能用SQL语句在查询分析器里读出数据，不能进行其他任何操作。

6）在查询分析器里执行如下语句use masterdbcc rebuild_log( 'ufdata_130_2003', 'F:\data\ZT130\2003\ufdata.ldf')此时就重建了日志文件，数据库可以使用了。

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是数据库日志文件。

数据库置疑详解本期概述●本文档适用于k/3与MS SQL SERVER的应用。

●学习完本文档以后，可以对由数据库置疑引起的K/3帐套登录异常现象有初步的了解。

版本信息●本文件使用须知著作权人保留本文件的内容的解释权，并且仅将本文件内容提供给阁下个人使用。

对于内容中所含的版权和其他所有权声明，您应予以尊重并在其副本中予以保留。

您不得以任何方式修改、复制、公开展示、公布或分发这些内容或者以其他方式把它们用于任何公开或商业目的。

任何未经授权的使用都可能构成对版权、商标和其他法律权利的侵犯。

如果您不接受或违反上述约定，您使用本文件的授权将自动终止，同时您应立即销毁任何已下载或打印好的本文件内容。

著作权人对本文件内容可用性不附加任何形式的保证，也不保证本文件内容的绝对准确性和绝对完整性。

本文件中介绍的产品、技术、方案和配置等仅供您参考，且它们可能会随时变更，恕不另行通知。

本文件中的内容也可能已经过期，著作权人不承诺更新它们。

如需得到最新的技术信息和服务，您可向当地的金蝶业务联系人和合作伙伴进行咨询。

著作权声明著作权所有2008金蝶软件（中国）有限公司。

所有权利均予保留。

文档内容从本页开始目录第一章数据库质疑的解决方法 (3)1.1 数据库质疑的现象及原因分析 (3)1.2 数据库分离与附加操作 (4)1.2.1 常规解决方案 (4)1.2.2 异常解决方案 (6)第一章数据库质疑的解决方法1.1 数据库质疑的现象及原因分析我们知道，K/3的运行需要数据库的支持，如果数据库出现故障，轻则可能导致K/3运行错误，无法打开K/3软件，重则可能造成数据的丢失。

当K/3的帐套数据库出现故障，我们登录K/3的帐套管理时，可能会报错：“当前帐套的系统账号无效，请在帐套属性中更改”，如图1-1所示。

图1-1当登录K/3主控台时，可能会报：“无法建立数据连接”之类的错误，如图1-2所示。

图1-2此时，打开SQL SERVER的企业管理器，可以发现该帐套对应的数据库文件出现‘置疑’的状态，如图1-3所示图1-3为什么数据库会出现置疑的状态呢？可能有以下几种原因：1.数据库服务器意外重启，导致程序非正常退出；2.错误的删除日志；3.硬件(HD)损坏,造成日志和数据文件写错误；4.硬盘的空间不够,比如日志文件过大；这些情况都有可能导致数据库故障，从而使数据库不能正常运行。

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

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。

数据库损坏和置疑修复方法为了修复数据库损坏，可以采取以下方法：1.备份恢复：如果有最新的备份文件，可以通过备份文件进行恢复。

恢复时应注意将损坏的数据库与备份文件进行比对，避免将损坏的数据库文件恢复到备份文件上。

2.日志文件恢复：数据库管理系统通常会有日志文件来记录数据的修改操作，使用日志文件可以恢复损坏的数据库。

通过日志文件，可以找到最近一次正常操作的记录，并恢复到该记录之后的状态。

3.数据库修复工具：数据库管理系统通常都提供了数据库修复工具，可以用于修复损坏的数据库。

修复工具能够检测数据库的完整性，并修复数据文件中的错误或者丢失的数据。

4.数据库重建：如果无法通过备份恢复或通过修复工具修复数据库，可以尝试重建数据库。

重建数据库可以通过创建新的数据库，然后将数据从旧数据库中导出并导入到新数据库中，实现数据的恢复。

5.异地备份：在数据库损坏之前，应该做好数据的备份工作，并将备份数据存储在其他地方。

这样即使数据库发生损坏，也能够通过备份数据进行恢复。

在修复数据库损坏时，需要注意以下几点：1.数据库损坏后，必须立即停止对数据库的操作，以免进一步损坏数据。

2.在使用数据库修复工具时，应该对数据库进行完整备份，以防修复过程中出现意外情况。

3.在修复过程中，应该小心操作，避免进一步损坏数据库文件或数据。

4.在数据库损坏修复完成后，应该对数据库进行全面的测试，以确保数据库的完整性和可用性。

5.定期进行数据库维护和优化工作，以减少数据库损坏的可能性。

总之，数据库损坏是一种常见的情况，但通过备份恢复、日志文件恢复、修复工具、数据库重建等方法，可以有效修复损坏的数据库。

在数据库损坏修复过程中，需要小心操作，避免进一步损坏数据。

同时，定期进行数据库维护和优化工作，可以减少数据库损坏的发生。

处理数据库置疑的方法处理数据库置疑的方法先分离数据库企业管理器--右键置疑的数据库--所有任务--分离数据库然后备份你的置疑数据库的文件,再按下面的步骤处理:1.新建一个同名的数据库2.再停掉sql server3.用置疑数据库的文件覆盖掉这个新建的同名数据库，只覆盖mdf文件，日志文件不要覆盖4.再重启sql server5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，打开查询分析器执行下面的语句（注意修改其中的数据库名)重建日志文件，经过修复后数据就可以正常分离并附加了，语句中“C:\置疑的同名数据库名_Log.ldf”是重建日志日志文件存放路径，在重建日志后，最好将数据库分离并将重新创建的日志文件拷贝到数据库文件所在目录，再重新进行附加。

--重建日志文件，修复损坏的日志USE MASTERSP___RE 'ALLOW __',1 __GURE WITH __EGOUPDATE __BASES SET STATUS =__ WHERE NAME='置疑的同名数据库名'Godbcc rebuild_log('置疑的同名数据库名','C:\置疑的同名数据库名_Log.ldf')GOupdate sysdatabases set status =28 where name='置疑的同名数据库名'Gosp_configure 'allow updates', 0 reconfigure with overrideGo6、数据库修复后还需要进行数据库检测，看是否存在一些错误，数据库检测需要用DBCC __命令，如下：DBCC __('置疑的同名数据库名')如果检测到错误，需要进行修复，但修复数据库需要在单用户模式下，请使用以下语句,ALTER __E 置疑的同名数据库名SET SINGLE_USER WITH __K __TEDBCC __ ('置疑的同名数据库名',REPAIR___)GOALTER __E 置疑的同名数据库名SET MULTI_USER WITH __K __TEGO如果还有错误，执行下面的语句DBCC __ ('数据库名',REPAIR_ALLOW_DATA_LOSS )-------(执行一次如果还有错误，可以多执行几次)7、有时通过DBCC __能够修复数据库中的错误，但有时不能修复，可能需要对单个有问题的数据表进行修复，需要使用DBCC __BLE('有问题的数据表名',REPAIR___) 命令，详细请看联机帮助8、DBCC __命令介绍检查指定数据库中的所有对象的分配和结构完整性。

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（数据库）运行恢复操作。

方法四： 释放另一个磁盘驱动器上的磁盘空间。 将可用磁盘空间不足的文件组中的数据文件移动到第一步所指的磁盘驱动器上。 执行 sp_detach_db 分离数据库。 执行 sp_attach_db 附加数据库，指向被移动的文件。

步骤1：创建一个新的数据库，命名为原来数据库的名字。

步骤2：停止SQL Server步骤3：把老数据库的MDF文件替换新数据库的相应的MDF文件，并把LDF 文件删除。

步骤4：重新启动SQL Server服务，然后运行如下命令：Use MasterGosp_configure 'allow updates', 1reconfigure with overrideGobegin tranupdate sysdatabases set status = 32768 where name = 'db_name'--Verify one row is updated before committingcommit tran步骤5：停止SQL然后重新启动SQL Server服务，然后运行如下命令：DBCC TRACEON（3604）DBCC REBUILD＿LOG（'db_name','c:\mssql7\data\dbxxx_3.ldf'）Go步骤6：停止SQL然后重新启动SQL Server服务，然后运行：use masterupdate sysdatabases set status = 8 where name = 'db_name'Gosp_configue 'allow updates', 0reconfigure with overrideGo步骤7：运行dbcc checkdb(db_name) 检查数据库的完整性注：都要替换成真实的数据库名字。

s ql附加数据库时提示823错误2008-12-26 09:10朋友单位有台电脑的数据库ufdata_001_2008状态为置疑，我断开再附加时提示如下图所示说明，附加时失败，错误823。

原因分析：出现这种情况可能是由于电脑忽然断电或者异常关机造成的。

处理数据库置疑的方法先分离数据库企业管理器--右键置疑的数据库--所有任务--分离数据库然后备份你的置疑数据库的文件,再按下面的步骤处理:1.新建一个同名的数据库2.再停掉sql server3.用置疑数据库的文件覆盖掉这个新建的同名数据库，只覆盖mdf文件，日志文件不要覆盖4.再重启sql server5.此时打开企业管理器时新建的同名数据库会出现置疑，先不管，打开查询分析器执行下面的语句（注意修改其中的数据库名)重建日志文件，经过修复后数据就可以正常分离并附加了，语句中“C:\置疑的同名数据库名_Log.ldf”是重建日志日志文件存放路径，在重建日志后，最好将数据库分离并将重新创建的日志文件拷贝到数据库文件所在目录，再重新进行附加。

--重建日志文件，修复损坏的日志USE MASTERGOSP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDEGOUPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的同名数据库名'Godbcc rebuild_log('置疑的同名数据库名','C:\置疑的同名数据库名_Log.ldf')GOupdate sysdatabases set status =28 where name='置疑的同名数据库名'Gosp_configure 'allow updates', 0 reconfigure with overrideGo6、数据库修复后还需要进行数据库检测，看是否存在一些错误，数据库检测需要用DBCC CHECKDB命令，如下：DBCC CHECKDB('置疑的同名数据库名')如果检测到错误，需要进行修复，但修复数据库需要在单用户模式下，请使用以下语句, ALTER DATABASE 置疑的同名数据库名SET SINGLE_USER WITH ROLLBACK IMMEDIATEGODBCC CHECKDB ('置疑的同名数据库名',REPAIR_REBUILD)GOALTER DATABASE 置疑的同名数据库名SET MULTI_USER WITH ROLLBACK IMMEDIATEGO如果还有错误，执行下面的语句DBCC CHECKDB ('数据库名',REPAIR_ALLOW_DA TA_LOSS )-------(执行一次如果还有错误，可以多执行几次)7、有时通过DBCC CHECKDB能够修复数据库中的错误，但有时不能修复，可能需要对单个有问题的数据表进行修复，需要使用DBCC CHECKTABLE('有问题的数据表名',REPAIR_REBUILD) 命令，详细请看联机帮助8、DBCC CHECKDB命令介绍检查指定数据库中的所有对象的分配和结构完整性。