索引碎片处理-索引重建过程中处理时报异常错误[无法进行大容量加载、违反唯约束等]

[幻影时空]

今有一问题困惑，到处 求助，希望大家可以帮忙分析且提供指导意见。谢谢。


情况描述：现有 单表行数约2.5亿条，数据文件占用 约 100G左右，索引文件占20G左右。

由于日常会有大量数据新增，且还会有定期数据物理删除，容易产生些 索引碎片，有一个日常定期的索引重建操作，
使用 ALTER INDEX ..... REBUILD 语句。

但近期 因前段时间 有遇到过 磁盘容量过满无日志空间等一些错误情况导致，数据库文件有些错误，现在 进行 聚集索引重建时，会报错：无法进行大容量加载。大容量数据流被错误地指定为已排序，或者数据违反了由目标表施加的唯一性约束。

——————

现使用方法的详情：

ALTER INDEX [PK_JW_Order] ON [dbo].[JW_Order] REBUILD PARTITION = ALL WITH ( ONLINE = ON, SORT_IN_TEMPDB = ON )

报错详情：

无法进行大容量加载。大容量数据流被错误地指定为已排序，或者数据违反了由目标表施加的唯一性约束。下面两行的排序顺序不正确: 第一行的主键: (xxxx001)，第二行的主键: (xxx002)。

————————


对于这情况，网上 似乎 可查到的 资料 过少。 也有看到资料说，可用 DBCC CHECKDB 进行修复，但 之间因文件出时时，是使用过 DBCC CHECKDB 修复的， 由于整个库文件过大，且需要使用单用户模式，且尝试 修复过程太久，所以之前只尝试了一次之后， 这错误修复之后仍然还有的，

暂时还未使用 DBCC CHECKTABLE （或 DBCC DBREINDEX） 进行指定 表 和 索引重新尝试（这些修复方式，因需要 设置 为单用户处理的模式，暂时还未进行二次尝试哦）。

我的问题：
（1）
不确定 DBCC DBREINDEX 修复的原理 和 ALTER INDEX ..... REBUILD 是否有差异？

（2）
对于 “下面两行的排序顺序不正确 第一行的主键: (xxxx001)，第二行的主键: (xxx002) “ 报错的信息，应该如何处理？ 把这两主键数据删除，但也未起到使用哦？

（3）
如果还有其它方法，还有什么最有效的可以处理到呢？
（表重建和导数据可能性不大，表数据的实时性数据量很大，数据记录过大，导数据过程无法解决时效问题）

[shinger126]

表里面的索引或者数据已经错误，首先尝试dbcc dbreindex 这个不用设置单用户模式，如果这个命令修复不了，那就是数据错误了，必须用dbcc CHECKTABLE方式来修复，也就是说必须用单用户模式。 alter index rebuild仅重建索引，不会动索引文件。dbcc dbreindex会重建索引文件

[吉普赛的歌]

光数据文件就 100GB ， 索引 20 GB， 已经是一个非常惊人的数据量了。 但一般情况下没必要。 救急， 临时处理： 创建一新表， 将数据导过去， 再加上索引。 长久的改善方法： 分三个表： 1。当前表， 只保留今天的数据， 2。近期表，只保留3个月或半年的数据； 3。历史表， 只保留近期表之后的数据。 分开之后， 近期表和历史表再做好分区， 历史表中长期不用的数据转移到其它库或其它表。

[OwenZeng_DBA]

@幻影时空 1.数据库是什么版本的。、 2.但近期 因前段时间 有遇到过 磁盘容量过满无日志空间等一些错误情况导致，数据库文件有些错误 。 数据库文件有什么错误。 3.尝试对数据库进行备份 ，然后把备份还原到其他的测试环境再进行修复，根据结果再进行下面的步骤

[幻影时空]

好的，谢谢各位提供的方法和帮助，我先尝试一下 ，DBCC DBREINDEX 的方案， 现确实 结构上存在问题， 主要是历史的结构问题没有把库分开，新版中已经处理了，但老版本还得再兼容保留过度一些时间。 ——————

引用 4 楼 z10843087 的回复:

@幻影时空 1.数据库是什么版本的。、 2.但近期 因前段时间 有遇到过 磁盘容量过满无日志空间等一些错误情况导致，数据库文件有些错误 。 数据库文件有什么错误。 3.尝试对数据库进行备份 ，然后把备份还原到其他的测试环境再进行修复，根据结果再进行下面的步骤

———— 现在数据库是 2008 R2 的（最近几年 服务器没法停机，就没有升级到新版本，涉及到多台版本 兼容问题，也就没敢大胆升级了）， 当时出错的主要原因是因为 日志 突然占满磁盘，日志和文件在同一个磁盘上当时已经无空间可删除，且日志的容量也无法回收可删除，可能 表出错导致 SQLSERVER 自动重启了，然后 大文件 在重启之后它需要恢复中，但恢复状态过程中 因为日志 磁盘占满无法 “恢复成功”（启动成功） ，然后日志文件也无法清除，腾不出空间来， 数据就无法成功恢复到使用状态。 所以当时 应急采用的办法是 脱离数据库 ，再另重新 新建了一个同名的数据库， 再用脱机的办法把 旧的 数据库文件覆盖 到新创建的库文件上，这样 日志文件变小的方案，再把再用 DBCC CHECKDB 把数据库修复恢复过来，成功启动了，但 恢复日志有很多表有产生错误， （我看过 当时的日志，主要 还是有很多 (1)重复键值的错误 （2） 数据和索引行不匹配） 然后 出错的 其它表已经好了，目前就只有这一个索引的问题还存在。 也是因为修复到最后还是因为磁盘容易问题， 可能还有些没修复好。 现在容量问题已经解决到了，只是错误还在需要修复中。 —————— 嗯，好的，也谢谢哦，我先 尝试一下，后续有 结果，我再 继续 补充上来！

[zjcxc]

分表或者 PARTITION，不然就用 ONLINE=OFF 的 REBUILD 方式

[OwenZeng_DBA]

@幻影时空 磁盘满的话，就在其他盘加一个数据文件，这样新的数据可以写到其他的盘符。磁盘满了导致数据库重启，这个我都没遇到过。

[幻影时空]

目前 正在尝试 的是 DBCC DBREINDEX 方案， 两天重试报错： —————— 因为发现对象名称 'dbo.JW_Order 和索引名称 'PK_JW_Order' 有重复的键，所以 CREATE UNIQUE INDEX 语句终止。重复的键值为 (158477180074026371)。 [SQLSTATE 23000] (错误 1505) 语句已终止。 —————— 此任务在每天凌晨重试一次，遇到两次的 报错“有重复键”，可是我根据错误提示的 键值实际去重复只能找到一条记录的，并没有重复？ 那么补充问题 （1） 这个键值 怎么产生的（ 索引是聚集索引的主键，但不是增长值，是自定义的唯一值） （2）除了此办法，类似这样的大量 可有什么方法 可以快速 找除其它剩余 可能 有错误的键值？我现在只能每天重试一次 DBCC DBREINDEX ，然后 根据报错的值 强制删除一次数据。