当前位置：首页 > 问答 > 正文

ORA-14129报错原因和解决办法，关于UNIQUE约束必须加INCLUDING INDEXES的坑，远程帮你搞定

黎家
问答
2026-01-08 21:00:03
5

ORA-14129这个错误，说白了就是你在删除一个表分区的时候，数据库不让你删，不行！这个分区上有一个独一无二的约束，但这个约束的索引是存放在表外面的，你得用‘INCLUDING INDEXES’这个选项来删才行”，听起来有点绕，我们把它拆开,用一个生活中的例子来讲明白。

想象一下，你有一个大仓库，这个仓库就是你数据库里的表，为了管理方便，你把仓库分成了好几个区域，比如A区放家电，B区放家具，这些区域就是分区。

你给整个仓库立了个规矩：所有入库的商品，它的序列号绝对不能重复，这就是一个唯一约束，为了确保这个规矩能被严格执行，你需要一个非常厉害的管理员，他的工作就是每当有新货进来，他就去查一遍整个仓库的记录，确保这个新序列号从来没出现过，这个管理员，就是唯一索引,索引是约束能够生效的底层保障。

关键点来了：这个管理员（索引）他在哪里办公？

有两种情况：

本地管理员（局部索引）：你在每个分区（A区、B区）里都安排了一个小管理员，他们只负责自己区域内的序列号不重复，同时也协同工作，确保跨区域的序列号也不重复，这种情况下，管理员是“嵌入”在每个分区里的。
总部管理员（全局索引）：你只聘请了一个总管理员，他在仓库总部有一个独立的办公室，任何货物进出任何一个分区,都必须先经过他这个总部办公室的登记和核查。

ORA-14129错误就出在第二种情况——“总部管理员”模式。

ORA-14129报错原因和解决办法，关于UNIQUE约束必须加INCLUDING INDEXES的坑，远程帮你搞定

你觉得A区（一个分区）旧了，想把它拆掉（删除分区），如果你直接下令“拆掉A区！”，数据库就懵了，它会想：“等等！A区虽然要拆了，但那个负责核查全仓库序列号的总管理员，他的工作记录里还包含着A区的所有数据呢！如果把A区直接拆了，总管理员那边的记录就对不上了，整个序列号查重系统就乱套了，这风险太大了，我不能执行！”

数据库为了保持数据的一致性，干脆就阻止你这个操作，并抛出ORA-14129错误，它是在提醒你：“你要删除分区可以，但你必须同时处理好那个‘总部管理员’（全局索引）的问题。”

怎么解决呢？办法就是听从数据库的建议，使用 INCLUDING INDEXES 子句。

回到我们的例子，这就好比你在下达“拆掉A区”的命令时，额外加一句：“把总管理员办公室里所有关于A区的记录也一并清理掉！” 这样，整个操作就是完整的、安全的。

对应的SQL语句就是这样：

ORA-14129报错原因和解决办法，关于UNIQUE约束必须加INCLUDING INDEXES的坑，远程帮你搞定

ALTER TABLE 你的表名 DROP PARTITION 你要删除的分区名 INCLUDING INDEXES;

当你加上了 INCLUDING INDEXES，数据库就知道你意图明确，它就会在删除分区数据的同时，也把这个分区在全局索引中对应的条目清理干净，这样，唯一约束的系统在分区删除后依然是完整、一致的。

这里有个非常重要的“坑”你需要知道：

使用 INCLUDING INDEXES 的代价是，整个全局索引会被重建,这意味着什么呢？

继续上面的例子，你清理掉总管理员关于A区的记录，并不是只撕掉几页纸那么简单，相当于这个总管理员要把剩下的B区、C区等所有区域的记录，按照最新的情况重新誊写一遍，整理成一个新的、干净的总账本，这个过程就是索引重建。

对于一个大表（仓库非常巨大）重建全局索引是一个非常耗时、消耗大量系统资源（CPU、I/O）的操作，在重建期间，会对表的DML操作（插入、删除、更新）性能产生显著影响，甚至可能导致锁等待,影响其他业务。

ORA-14129报错原因和解决办法，关于UNIQUE约束必须加INCLUDING INDEXES的坑，远程帮你搞定

这就是“UNIQUE约束必须加INCLUDING INDEXES的坑”：你虽然解决了删除分区的问题，但可能不经意间引发了一次性能风暴。

有没有更好的办法来规避这个坑呢？

有的,主要有两种思路：

分区级唯一索引（局部索引）：这是从设计上根本解决问题的方法，在创建表和唯一约束时，就将其指定为局部的，这样每个分区都有自己的索引片段，删除一个分区时，直接丢弃对应的局部索引片段即可，完全不影响其他分区，速度极快，资源消耗极小，这就像每个分区都有自己的管理员，拆掉A区，只需要解雇A区的管理员就行了，总部纹丝不动,但这要求你的唯一约束键必须包含分区键。
先失效，再删除，后重建：如果表已经建成，唯一约束是全局的，又不得不删分区，想避免在业务高峰时重建索引带来的冲击，可以采用这个步骤：
- 第一步：先将全局索引设置为不可用（UNUSABLE），这步很快。
```
ALTER INDEX 你的全局索引名 UNUSABLE;
```
- 第二步：这时就可以没有负担地删除分区了，因为索引已经失效，数据库不会再去检查它。
```
ALTER TABLE 你的表名 DROP PARTITION 你要删除的分区名;
```
- 第三步：在业务低峰期，再单独重建索引。
```
ALTER INDEX 你的全局索引名 REBUILD;
```
  这个方法将一次性的巨大资源消耗，转移成了可控的、可以安排在闲时进行的操作。

ORA-14129是一个安全机制错误，提醒你删除分区时要注意维护全局索引的一致性，最直接的解决方法是加 INCLUDING INDEXES，但要注意它会导致索引重建，可能影响性能，最优解是在表设计阶段就优先使用局部唯一索引，对于现存的大表，可以采用“失效-删除-重建”的策略来平滑操作，理解了索引和约束的关系,你就能更好地驾驭分区表的管理工作。