如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
DBCC CHECKDB 命令用以检测数据库中所有对象的物理和逻辑完整性，其包含如下操作
- 对数据库运行DBCC CHECKALLOC
- 对数据库运行DBCC CHECKTABLE检测数据库中的每一张表和视图
- 对数据库运行DBCC CHECKCATALOG
- 验证每个INDEXED VIEW的内容
- 验证使用FILESTREAM存放有varbinary(max)数据的文件系统目录和表的元数据之间的连接一致性
- 验证数据库中的Service Broker数据
语法如下：
DBCC CHECKDB
[ ( database_name | database_id | 0
[ , NOINDEX
| , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]
) ]
[ WITH
{
[ ALL_ERRORMSGS ]
[ , EXTENDED_LOGICAL_CHECKS ]
[ , NO_INFOMSGS ]
[ , TABLOCK ]
[ , ESTIMATEONLY ]
[ , { PHYSICAL_ONLY | DATA_PURITY } ]
[ , MAXDOP = number_of_processors ]
}
]
]
REPAIR_ALLOW_DATA_LOSS 选项会让CHECKDB命令尝试修复所有检查出的错误。这些修复可能导致丢失数据：
REPAIR_ALLOW_DATA_LOSS选项是被SQL SERVER官方支持的特性，但使用该特性可能导致数据丢失或不一致。官方推荐在有备份的情况下，优先使用备份恢复数据。
微软官方总是建议用户从一个已知可用的备份中恢复数据，这是针对DBCC CHECKDB出现错误后的主流应对方法。REPAIR_ALLOW_DATA_LOSS选项仅在无任何有效备份的情况下考虑使用。对于特定的错误，可能只用使用REPAIR_ALLOW_DATA_LOSS选项修复；例如清除部分行、数据页来解决问题。对于这些被清除的数据而言，用户无法再访问它们，也不再可能恢复，用户可能也搞不清楚丢了哪些数据。因此，参考约束可能在这些清除后变得不准确，典型的情况是外键可能不再启用或维护。当使用REPAIR_ALLOW_DATA_LOSS后，用户需要自行人工去检查这些外键。
在做修复前，建议先对数据文件做备份。包括主要数据文件.mdf,二级数据文件.ndf和所有的日志文件.ldf，以及其他文件包括full text catalog,文件流目录，内存优化数据等。
在做具体修复前，建议将数据库置入EMERGENCY模式，并在该模式下对重要的表数据做抽取保存。
Comment