MS (DBCC CHECKDB)Sql Server 数据库或表修复

DBCC CHECKDB 数据库或表修复MS Sql Server 提供了很多数据库修复的命令，当数据库质疑或是有的无法完成读取时可以尝试这些修复命令。

1. DBCC CHECKDB重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。

use masterdeclare @databasename varchar(255)set @databasename='需要修复的数据库实体的名称'exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)dbcc checkdb(@databasename,REPAIR_REBUILD)exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态然后执行DBCC CHECKDB('需要修复的数据库实体的名称') 检查数据库是否仍旧存在错误。

注意：修复后可能会造成部分数据的丢失。

2. DBCC CHECKTABLE如果DBCC CHECKDB 检查仍旧存在错误，可以使用DBCC CHECKTABLE来修复。

use 需要修复的数据库实体的名称declare @dbname varchar(255)set @dbname='需要修复的数据库实体的名称'exec sp_dboption @dbname,'single user','true'dbcc checktable('需要修复的数据表的名称',REPAIR_ALLOW_DATA_LOSS)dbcc checktable('需要修复的数据表的名称',REPAIR_REBUILD)------把’ 需要修复的数据表的名称’更改为执行DBCC CHECKDB时报错的数据表的名称exec sp_dboption @dbname,'single user','false'3. 其他的一些常用的修复命令DBCC DBREINDEX 重建指定数据库中表的一个或多个索引用法：DBCC DBREINDEX (表名,’’) 修复此表所有的索引。

dbcc checkdb语句
DBCC CHECKDB语句是用于对SQL Server数据库进行完整性检查和诊断的命令。

该命令检查数据库中的所有对象，并查找任何潜在的问题或损坏。

它可以帮助数据库管理员检测并修复数据文件中的错误，以及检查表、索引、约束等对象的一致性。

使用DBCC CHECKDB语句可以检查数据库的物理和逻辑完整性。

它会扫描数据库中的所有分配的页，并对每个分配的页执行一些检查。

数据库管理员可以指定是否要修复任何发现的错误。

DBCC CHECKDB语句的一些常见的选项和参数包括：
1. REPAIR_ALLOW_DATA_LOSS：该选项用于指定在修复过程中是否允许删除数据，可能会导致数据丢失。

在执行此选项之前，务必进行备份以防数据丢失。

2. ALL_ERRORMSGS：该选项用于在检查过程中显示所有错误消息。

3. NO_INFOMSGS：该选项用于在检查过程中禁止显示信息消息。

4. PHYSICAL_ONLY：该选项用于仅检查数据库的物理完整性，而不执行逻辑检查。

这可以提高检查速度。

DBCC CHECKDB语句是维护和管理SQL Server数据库的重要工具之一。

它提供了对数据库完整性的全面检查，并能够帮助管理员及时发现并修复潜在的问题。

建议定期运行该命令，以确保数据库的健康和稳定性。

请注意，在使用DBCC CHECKDB语句之前，务必进行适当的准备工作，如备份数据库和查看相关文档。

此外，建议在以生产环境中使用此命令之前，在测试环境中先进行测试以避免意外情况的发生。

SQL Server数据库异常是常见的技术问题，以下是一些可能的解决方法：
检查错误日志：SQL Server的错误日志是解决问题的关键。

出现异常时，首先应查看错误日志，了解详细的错误信息。

备份和恢复：定期备份数据库是预防数据丢失的有效方法。

如果出现数据损坏或丢失，可以尝试使用备份进行恢复。

检查数据库连接：确保应用程序能够正常连接到SQL Server。

如果连接出现问题，可以检查网络连接、防火墙设置、SQL Server配置等。

优化查询性能：如果查询性能下降，可能是因为表结构不合理、索引失效、数据量过大等。

可以考虑优化查询语句、重建索引、清理历史数据等。

检查磁盘空间：SQL Server数据库需要足够的磁盘空间。

如果磁盘空间不足，可能导致数据库无法正常运行。

需要定期检查服务器磁盘空间，并及时清理不必要的文件。

更新和修复：如果是SQL Server的bug导致的异常，可能需要安装最新的补丁或升级到新版本。

同时，也可以考虑使用修复工具来修复数据库损坏。

联系技术支持：如果自己无法解决问题，可以联系Microsoft的技术支持或社区寻求帮助。

在处理SQL Server数据库异常时，应保持冷静，根据错误信息进行排查。

同时，预防总比治疗更重要，平时应做好数据库的维护和管理，避免出现异常。

SQLSERVER数据库修复⽅法（数据库变为可疑）
在使⽤SQL Server 2008数据库时发现数据库被标记为可疑，查看⽹上的资料终于找到了解决办法，接下来我们就来介绍解决⽅法。

解决⽅法：
当数据库发⽣这种操作故障时，可以按如下操作步骤可解决此⽅法，打开数据库⾥的Sql 查询编辑器窗⼝，运⾏以下的命令。

1、修改数据库为紧急模式
ALTER DATABASE数据库名称SET EMERGENCY
2、使数据库变为单⽤户模式
ALTER DATABASE数据库名称SET SINGLE_USER
3、修复数据库⽇志重新⽣成，此命令检查的分配，结构，逻辑完整性和所有数据库中的对象错误。

当您指
定“REPAIR_ALLOW_DATA_LOSS”作为DBCC CHECKDB命令参数，该程序将检查和修复报告的错误。

但是，这些修复可能会导致⼀些数据丢失。

DBCC CheckDB (数据库名称 , REPAIR_ALLOW_DATA_LOSS)
4、使数据库变回为多⽤户模式
ALTER DATABASE数据库名称SET MULTI_USER
也可以这样做：
1：重新建⽴⼀个，⼀样的数据库，路径名称，⽂件都⼀样。

2：关掉SQL Server服务；
3：把源⽂件COPY过来；
4：开启SQL Server服务，这样问题同样就解决了。

数据库修复步骤
1.将已破坏的老数据库更名如Baddb_Data.Mdf ==>Baddb_Data.Md_ ,并在原来位置新建一同
名数据库如Baddb_Data.Mdf .
2. 停止SQL, 将新数据库更名(Baddb_Data.Mdf ==> Baddb_Data.Md2),
待修复老数据库更名为原先名称Baddb_Data.Md_ ==> Baddb_Data.Mdf
3.启动SQL , 并进入查询分析器中, 执行如下命令:
USE MASTER
sp_configure 'allow', 1
reconfigure with override
update sysdatabases set status = 32768 where name = 'Baddb'
4. 把LDF文件改名，再执行
DBCC REBUILD_LOG ('Baddb', 'E:\posdb\Baddb_Log.LDF' )
5. 恢复数据库紧急模式
update sysdatabases set status = 0 where name = 'Baddb'
6. 执行
restore database Baddb WITH RECOVERY
sp_configure 'allow', 0
reconfigure with override
7. 检查数据库看看有没有错误, 应该可以看到数据了
DBCC CHECKDB ('Baddb')
如以上还是不行，试把数据库设为紧急模式，再把数据导出到一个新的数据库(如有坏区)。

寒山sql数据库修复中心/由于种种原因，我们如果当时仅仅备份了mdf 文件，那么恢复起来就是一件很麻烦的事情了。

如果您的mdf 文件是当前数据库产生的，那么很侥幸，也许你使用sp_attach_db 或者sp_attach_single_file_db 可以恢复数据库，但是会出现类似下面的提示信息设备激活错误。

物理文件名'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。

已创建名为'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。

但是，如果您的数据库文件是从其他计算机上复制过来的，那么很不幸，也许上述办法就行不通了。

你也许会得到类似下面的错误信息服务器: 消息1813，级别16，状态2，行 1 未能打开新数据库'test'。

CREATE DATABASE 将终止。

设备激活错误。

物理文件名'd:\test_log.LDF' 可能有误。

怎么办呢？别着急，下面我们举例说明恢复办法。

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

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

B．停掉数据库服务器。

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

D．启动数据库服务器。

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

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

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

此操作可以在SQL Server Enterprise Manager 里面选择数据库服务器，按右键，选择“属性”，在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。

SQL Server数据库修复语句在SQL Server中，数据库可能会遇到各种问题，比如损坏、不一致或者出现其他错误，这时就需要使用修复语句来修复数据库。

本文将介绍一些常见的SQL Server数据库修复语句，帮助大家解决数据库问题。

1. 使用DBCC CHECKDB命令检查数据库的一致性DBCC CHECKDB是SQL Server中用于检查数据库一致性的命令。

可以使用以下命令来检查指定数据库的一致性问题：```DBCC CHECKDB('数据库名')```这个命令会检查数据库对象的物理和逻辑一致性，包括索引、数据页、数据链路等内容。

如果发现问题，会输出错误信息并尝试修复。

需要说明的是，在运行此命令之前，建议先备份数据库，以免造成数据丢失。

2. 修复损坏的数据页如果DBCC CHECKDB命令检查出了数据页损坏的问题，可以使用以下语句修复：```DBCC PAGE('数据库名', 1, 数据页号, 数据页修复选项)```其中，数据页号是需要修复的数据页的页号，数据页修复选项包括3种：0表示不执行修复，1表示尝试逻辑级别的修复，2表示尝试物理级别的修复。

根据实际情况选择修复选项。

3. 使用修复命令修复数据库如果数据库无法自动修复，可以使用修复命令手动修复数据库。

修复数据库的命令如下：```DBCC CHECKDB('数据库名', REP本人R_REBUILD)```修复操作会尝试重建损坏或不一致的索引，并进行一些其他的一致性检查和修复。

但需要注意的是，该操作可能会导致数据丢失或者数据库不一致，使用前务必确认已经备份了数据库。

4. 使用备份和还原来修复数据库如果数据库问题较为严重，以上方法无法修复，可以尝试使用备份和还原来修复数据库。

需要备份数据库：```BACKUP DATABASE 数据库名 TO 磁盘路径```将备份文件还原到一个新的数据库中：```RESTORE DATABASE 新数据库名 FROM 磁盘路径```这种方法可以将数据库还原到一个较为稳定的状态，但需要注意备份和还原的时机，避免数据丢失。

SQL Server 日志损坏造成整个数据库损坏的修复版本：V1.0作者：知行合一邮箱：409629442@时间：2014/9/29一、问题说明由于用户的数据库某张表比较大，大约有1000万条记录，数据库管理员在非业务时间对这个表进行删除清理，删除操作持续了1个小时左右，到工作时间，仍然没有正常结束。

前端用户反应应用系统比较慢后，数据库管理员对删除操作进行终止，终止时仍然无法正常终止。

最后，数据库管理员不得已对数据库进行重启，重启后发现数据库已经无法正常打开。

由于用户比较急，就用一个比较老的备份进行了恢复。

我们赶赴现场后，原先的数据库已经被删除，但用户已经针对原先的数据库文件和日志文件进行了拷贝。

我们把备份的数据库文件拷贝到异机进行附加，总是报错，提示无法读取日志文件。

具体报错如下：The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.Msg 1813, Level 16, State 2, Line 2通过上面的报错可知，数据库的日志文件发生了损坏，这时已经不能通过简单的附加方式进行恢复，也无法通过无日志附加的方式进行附加，因为这时数据库处在一个不一致的状态。

二、环境介绍操作系统：Windows 2008 R2SQL server: SQL Server 2008 SP1数据文件路径：注：数据文件后面为数据文件的file_id,file_id 可以通过sys.master_files进行查看三、处理过程由于这时数据库已经无法正常打开（已经没有对应的数据库，或数据库状态错误，查看不了任何属性信息），所以我们必须重新创建同名的数据库，然后用备份的数据文件覆盖新创建的数据文件。

sqlserver数据库修复语句
嘿，朋友们！咱今天就来讲讲 SQL Server 数据库修复语句那些事儿。

你知道吗，这数据库就好比是一个大宝藏，有时候可能会出点小毛病，这时候就得靠修复语句来拯救啦！比如说，当数据库出现一些奇怪的
错误提示，就好像一个人突然生病了一样，得赶紧想办法治好呀！
“DBCC CHECKDB”，这可是个厉害的家伙呢！就像医生手里的听
诊器，能帮我们找出数据库的问题所在。

比如说，“DBCC CHECKDB (your_database_name)”，这就像是在对数据库进行一次全面的体检。

还有“ALTER DATABASE SET SINGLE_USER”，这就像是给数据
库这个大房间上了一把锁，让其他人暂时不能进来，我们好专心地给
它疗伤呀！然后再进行修复操作。

哎呀呀，这修复语句可真是太重要啦！想象一下，如果没有这些语句，那我们的数据库出了问题可咋办呀？就像人病了没有药一样难受呢！我们得好好掌握这些语句，就像战士握紧手中的武器一样，随时
准备应对数据库的各种状况。

总之，SQL Server 数据库修复语句就是我们的得力助手，能让我们
的数据库一直健康地运行下去。

所以呀，一定要认真学习和运用这些
语句哦！。

SQLserver2000数据库修复办法总结Praymid 戴华倪总结步骤如下：1、检测数据库，使用命令（Dbcc checkdb）拿到数据库后附加到本地SQLserver使其运行，打开企业管理器，查看它。

同时打开查询分析器，在里面输入Dbcc checkdb 检测数据库命令然后回车即可以看到数据库的分析资料看到问题，评注：拿到问题先不要盲目的卸载SQLServer，本次因为新手，上手后就把数据库卸载，这样就耗费了一天的时间，过没有任何作用，测试服务器的完整性可以拿一个好的数据库做对比，自己可以建一个“test”，如果测试数据库运行正常，则不需要对服务器做任何改动。

千万不要改动系统，麻烦会更大。

提示：错误会以红色显示。

2、简单修复：命令：dbcc checkdb输入以下两句尝试修复。

DBCC CHECKDB('AIS20110120172605',repair_allow_data_loss)DBCC CHECKDB('AIS20110120172605',repair_rebuild)不管他究竟哪里错了，先用这两句试试一般的索引系统文件丢失，SQLserver 都可以解决这个问题，基本就差不多了。

但是对于主键索引损坏，这个命令基本修不好，所以对一个满身是伤的数据库，他可以修复70%。

注：修复时系统提示必须要在单用户模式下才可以生效，用户可以去企业管理器，对要修理的数据库：右击属性—选项—限制访问—单用户。

也可以使用以下语句实现：ALTER DATABASE AIS20110420091143 SET single_USERGO 改为单用户ALTER DATABASE AIS20110420091143 SET MULTI_USERGO 改为多用户。

继续使用dbcc checkdb检测，如果继续报错。

再次运行：DBCC CHECKDB('DataBasename') with NO_INFOMSGS,PHYSICAL_ONLY然后再运行：DBCC CHECKDB(' DataBasename ',repair_allow_data_loss) WITH TABLOCK 再次运行:DBCC CHECKDB('DB name') 系统显示修复成功，说明本次问题主要由索引等数据库系统本身问题引起，这样的修复可能会导致数据丢失，但是绝对不会是大批丢失，基本没有影响。

SQL Server数据库损坏及修复方法经常使用SQL Server数据库的朋友都知道，作为一个数据库，它就不可避免会出现各种损坏情况，如果因为一时的不注意而出现数据库损坏问题，大家就得不偿失了。

所以，在大家使用SQL Server数据库的同时，也要了解SQL Server数据库可能会出现的各种损坏问题，当出现数据库损坏问题后，用户可以及时的对其进行修复，挽回自身的损失。

今天，我们就一起来了解一下数据库出现损坏问题的一些原因，以及对损坏数据库的一些修复对策，希望能对大家的SQL Server数据库修复工作带来一定的帮助。

在SQL Server数据库的使用过程中，更新数据，数据都需要首先在内存中的Buffer Pool 驻留，然后通过CheckPoint和Lazy Writer等过程将内存中的数据持久化到磁盘。

在这个过程中，数据脏页由内存写入持久化的IO子系统，在此期间，按照IO子系统的不同，数据可能经过几层不同的结构，在这过程中，硬件环境会受到很多方面的影响，比如说电压是否稳定、断电、温度过高或过低、潮湿程度等，而软件方面，由于软件都是人写的，因此就可能存在BUG，这些都可能导致数据页在传输过程中出现错误。

此外，影响磁盘的因素也包括电压是否稳定、灰尘等因素，这些也有可能引起磁盘坏道或整体损坏。

上面提到的所有因素都可以被归结为IO子系统。

因此，造成数据损坏的情况绝大部分是由IO子系统引起的。

当然，除了这些，另外还有很多原因会导致SQL Server数据库损坏问题，比如通过编辑器等手动编辑数据文件、数据库中还有需要Redo和Undo的事务时（也就是没有Clean Shutdown）删除了日志文件（通常会导致数据库质疑）等等。

对于SQL Server数据库出现的损坏问题，一些对该数据库比较了解，专业知识比较多的朋友可能会考虑使用冗余数据进行恢复，所谓的冗余数据包括热备、冷备、和暖备，这里就不对这几种恢复方法进行介绍了，有兴趣的朋友可以上网查找相关的资源进行尝试。

SQL Server数据库故障及修复方法
对于计算机专业的大学生来说，SQL Server数据库肯定不陌生吧，SQL Server数据库作为目前使用相对广泛的数据库管理系统，被很多企业所使用，给大家带来了很多的方便。

对于企业来说，SQL Server数据库的稳定性至关重要，一旦发生问题，将会带来不可估量的损失。

当SQL Server数据库出现故障时，大家该如何解决问题呢？
SQL Server数据库常见故障：
1)SQL数据库置疑
2)SQL数据库无法附加或附加报错
3)SQL数据表查询错误
4)MDF文件损坏
5)SQL数据库备份文件损坏
6)SQL数据库被标记为可疑
7)SQL数据库被误删除
8)分区被格式化，SQL数据库被恢复后还是坏的
9)一致性错误
10)错误823等等
从上面大家可以了解到，SQL Server数据库的常见故障非常多，很可能用户一个错误操作就可能造成SQL Server数据库损坏或数据丢失，当出现这些问题时，用户不要盲目对数据库进行任何操作，因为用户的错误操作可能会造成数据库进一步损坏，对于不确定的情况，用户应该将数据库交给那些专业的数据库恢复人才进行恢复，这样才能保证数据库的安全。

dbcc checkdb实例DBCC CHECKDB 是 SQL Server 中的一个非常有用的命令，用于验证数据库文件的物理和逻辑完整性。

它可以帮助数据库管理员 (DBA) 识别并解决可能存在的问题，如损坏的索引、不一致的数据等。

下面是一个关于如何使用 DBCC CHECKDB 的实例，以及对其输出的解释。

实例：假设我们有一个名为 SalesDB 的数据库，我们想检查其完整性。

我们可以在 SQL Server Management Studio (SSMS) 中执行以下 T-SQL 命令：sqlUSE SalesDB;GODBCC CHECKDB ('SalesDB', REPAIR_ALLOW_DATA_LOSS);GO在这个例子中，我们使用了 DBCC CHECKDB 命令，并指定了数据库名 SalesDB。

REPAIR_ALLOW_DATA_LOSS 是一个修复级别参数，它允许修复过程中可能导致数据丢失的操作。

这是最高级别的修复，通常在数据损坏严重且没有其他选择时使用。

输出解释：执行 DBCC CHECKDB 后，你将收到一个输出，其中包含有关数据库完整性的信息。

输出可能包括：检查摘要：显示检查的总览，包括检查的对象数和发现的问题数。

详细输出：列出每个发现的问题，包括问题类型、对象名、页号等。

修复摘要：如果执行了修复操作，这部分将显示修复的总览。

注意事项：在执行 DBCC CHECKDB 之前，最好备份数据库，以防修复过程中发生不可预见的数据损失。

如果发现严重的问题，最好在修复之前咨询经验丰富的 DBA 或数据库专家。

在生产环境中，最好在低峰时段执行 DBCC CHECKDB，因为它可能会消耗大量资源并影响性能。

通过仔细分析和理解 DBCC CHECKDB 的输出，DBA 可以更好地了解数据库的健康状况，并采取适当的措施来维护其完整性和性能。

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')--重建日志文件，--通常重建的日志文件放在与其它数据库文件相同目录下。

v1.0 可编辑可修改S Q L S e r v e系统表损坏的处理方法一、SQL SVR数据库中三张重要的系统表sysobjects：在数据库内创建的每个对象（约束、默认值、日志、规则、存储过程等）在表中占一行。

sysindexes：数据库中的每个索引和表在表中各占一行。

syscolumns：每个表和视图中的每列在表中占一行，存储过程中的每个参数在表中也占一行。

这三张表用ID（表ID）字段关联。

这三张系统表一旦损坏，与之对应数据库对象将无法访问，其作用相当于DOS中的“文件分配表”。

二、系统表损坏的症状用 DBCC CHECKDB 携带任何参数都无法修复数据库，也就是说：DBCC CHECKDB 对这个帐套根本不起作用；无法执行如下操作：select * from sysobjects 或select * from sysindexes或select * from syscolumns ；无法用SQL server DTS或其他SQL 脚本导库工具进行导库，导库的中途失败，报告：连接中断；在企业管理器或查询分析器中，部分用户数据表无法访问。

三、处理方法处理这种数据库，分为两个大的步骤：第一步：处理可以访问的数据表1)找出哪些表不可访问,即：系统表中哪些记录损坏；2)用SQL server DTS把能够访问的用户数据表导入一个新的DataBase 。

在导库时，不能选折(1)中不能访问的数据表。

第二步：处理不可访问的数据表：1)找出系统表中错误记录的ID；2)根据“错误记录的ID”，删除sysobjects、sysindexes、syscolumns 表错误的记录；3)根据“错误记录的ID”，重建系统表记录；4)重建完毕，如果该表可以访问，那么用DTS单独将此表导入新的DataBase。

说明：重建系统表方式不一定会成功，比如由于DISK I/O错误，如果仅仅是保存系统表的磁盘扇区出错，那么重建系统表方式可以挽回数据。

SQLServer损坏修复⽬录：⼀常见错误解读SQL Server 对数据库损坏的错误类型做了细化，在此对⼏个典型的错误作⼀下介绍。

错误信息是：“在⽂件 '%ls'中、偏移量为 %#016I64x 的位置执⾏ %S_MSG 期间，操作系统已经向 SQL Server 返回了错误 %ls。

”“The operating systemreturned error %ls to SQL Server during a %S_MSGat offset %#016I64x in file '%ls'.”例如：Msg 823, Level 24, State 3, Line 1The operating system returned error 5(Access is denied.) to SQLServer during a write at offset 0x0000000000e000 in file'FilePath\FileName'.823错误代表SQLServer在向操作系统申请某个页⾯读写的时候遇到Windows读取或写⼊请求失败。

Windows返回的错误代码和相应的⽂本会插⼊消息中。

对于读取操作，SQL Server在报出823错误之前已经重试读取请求4次。

从错误产⽣的机制可以看出，823错误是发出⼀个页⾯读写请求时发⽣的，和读写的内容没有关系。

所以823错误和SQLServer本⾝⽆关。

通常是物理⽂件损坏导致此错误，但也可能是设备驱动程序导致的。

如果某个数据⽂件上反复出现823错误，要不就是硬件设备出了问题，要不就是数据⽂件已经发⽣了⾮常严重的损坏。

这个错误基本上意味着数据页⾥的有效数据已经丢失，⼀般DBCCCHECKDB很难修复。

错误信息是：“SQLServer检测到基于⼀致性的逻辑I/O错误 %ls。

在⽂件 '%ls' 中、偏移量为 %#016I64x 的位置对数据库 ID %d 中的页%S_PGID 执⾏ %S_MSG 期间，发⽣了该错误。

寒山sql数据库修复中心/MS Sql Server 数据库或表修复数据库或表修复(DBCC CHECKDB)MS Sql Server 提供了很多数据库修复的命令，当数据库质疑或是有的无法完成读取时可以尝试这些修复命令。

1. DBCC CHECKDB 重启服务器后，在没有进行任何操作的情况下，在SQL 查询分析器中执行以下SQL 进行数据库的修复，修复数据库存在的一致性错误与分配错误。

use master declare @databasename varchar(255) set @databasename='需要修复的数据库实体的名称' exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) dbcc checkdb(@databasename,REPAIR_REBUILD) exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态然后执行DBCC CHECKDB('需要修复的数据库实体的名称') 检查数据库是否仍旧存在错误。

注意：修复后可能会造成部分数据的丢失。

2. DBCC CHECKTABLE 如果DBCC CHECKDB 检查仍旧存在错误，可以使用DBCC CHECKTABLE 来修复。

use 需要修复的数据库实体的名称declare @dbname varchar(255) set @dbname='需要修复的数据库的名称' exec sp_dboption @dbname,'single user','true' dbcc checktable('需要修复的数据表的名称',REPAIR_ALLOW_DA TA_LOSS) dbcc checktable('需要修复的数据表的名称',REPAIR_REBUILD) ------把’需要修复的数据表的名称’更改为执行DBCC CHECKDB 时报错的数据表的名称exec sp_dboption @dbname,'single user','false' 3. 其他的一些常用的修复命令DBCC DBREINDEX 重建指定数据库中表的一个或多个索引用法：DBCC DBREINDEX (表名,’’) 修复此表所有的索引。