ORA-14322报错咋整啊，默认分区重复导致数据库出问题远程帮你修复

ORA-14322报错咋整啊，默认分区重复导致数据库出问题远程帮你修复

朋友,碰到ORA-14322这个错误，你先别慌，这事儿我遇到过不少，说白了就是数据库里分区表的一个“默认分区”闹了双胞胎，系统不知道该听谁的了，这就像一个大柜子，你专门留了个抽屉放“其他所有杂项”，结果不小心做了两个一模一样的“杂项抽屉”，系统往里放东西的时候就懵圈了，只能给你弹个错误提示。

这个错误是啥意思？（来源：Oracle官方文档对ORA-14322的解释） 简单讲，ORA-14322错误的意思是：在你试图对一个分区表进行分裂分区、添加分区等操作时，系统检测到你的表定义中存在不止一个MAXVALUE分区（也就是我们常说的默认分区或最后分区），一个分区表只能有一个“包罗万象”的最终分区，多了就会打架，这个错误通常不会在你建表的时候出现，而是在后续维护分区时不小心操作失误引发的。

为啥会出现这个问题？（来源：常见的数据库维护操作场景） 最常见的原因是这样的：

1. 手滑误操作：你可能之前已经为表添加过一个MAXVALUE分区了，但时间一长给忘了，然后某次处理数据，比如觉得某个分区太大了想切分一下，或者想再手动加一个分区，结果一不小心，又创建了一个MAXVALUE分区，系统在执行你的命令前会检查分区结构，一查发现“哎？怎么已经有个默认分区了，你现在又要弄一个？”，于是果断报错14322。
2. 脚本或工具的逻辑问题：有时候我们会用一些自动化的脚本或者图形化工具来管理分区，如果这些脚本或工具的逻辑不够严谨，比如在每次添加分区前没有先检查是否已存在默认分区，也可能导致重复创建。

远程帮你修复的思路是啥？（来源：基于Oracle分区表管理原理的常规解决方法） 远程修复的核心，就是我指导你，你动手（或者授权我通过安全通道操作），因为涉及到直接修改数据库核心结构，我们必须非常小心，目标是：保留一个正确可用的默认分区，干净利落地删除那个多余的。

整个修复过程,说白了就是一场“寻宝+打扫”的游戏，步骤如下：

第一步：稳住，先确认问题（看图说话） 我们得先亲眼看看是不是真的有两个“双胞胎”分区，不能光凭报错就蛮干，需要你（或我远程连接后）在数据库里执行一个查询语句，这个语句会列出你这张出问题的表的所有分区信息，特别是关注那个分区边界条件为“MAXVALUE”的。 执行的SQL语句大概是这样的（你需要把你的表名替换成实际出问题的表名）： SELECT partition_name, high_value FROM user_tab_partitions WHERE table_name = '你的表名' ORDER BY partition_position; 执行完后，我们会看到一列分区的名字和它们的上限值，你会在结果里清晰地看到两个（或多个）分区的HIGH_VALUE字段显示为“MAXVALUE”，这就坐实了ORA-14322的病因，记下这两个分区的名字，比如一个叫P_LAST，一个叫P_MAX，我们后面要用。

第二步：制定作战计划（决定留谁删谁） 现在我们知道有两个多余的，但不能随便删，因为默认分区里可能已经存放了一些数据了，我们需要决定保留哪一个，删除哪一个，原则是：

• 保留那个没有数据或者数据无关紧要的？ 不对，应该优先保留那个肯定包含了所有未被其他分区覆盖的数据的分区，后创建的那个可能是个空壳子，但也不绝对。
• 更稳妥的办法是,检查这两个分区里到底有没有数据，我们再执行一个查询，分别查一下这两个嫌疑分区的数据行数： SELECT COUNT(*) FROM 你的表名 PARTITION (分区名称1); SELECT COUNT(*) FROM 你的表名 PARTITION (分区名称2); 这样，我们就知道哪个分区是真正在“干活”的，我们会保留那个有数据的分区，删除那个空的分区，如果两个都有数据，那就比较麻烦了，需要进一步分析数据是否重复、能否合并，但这种情况极少见，绝大多数情况下都是一个有数据一个空。

第三步：小心驶得万年船（备份！备份！备份！） 在动刀之前，哪怕有99.9%的把握，也必须备份，这不是小题大做，特别是如果那个要删除的分区里有数据，虽然我们检查是空的，但万一有极少数数据呢？最保险的做法是，导出一份这个表的数据，可以用Oracle的数据泵工具或者其他导出方式，跟你领导或同事确认一下你们常用的备份方法，有了备份，心里就彻底踏实了，就算操作失误，也能瞬间恢复。

第四步：执行清理操作（删除多余分区） 情况明朗了，备份也做了，可以动手了，使用SQL命令删除那个多余的、最好是空着的默认分区，命令如下： ALTER TABLE 你的表名 DROP PARTITION 要删除的分区名称; 如果这个分区是空的，这个命令会执行得飞快，如果系统提示分区非空不允许删除（虽然我们查了是空的，但可能遇到特殊锁或者延迟），你可能需要加上UPDATE INDEXES参数来避免索引失效，或者更强制一些的选项，但这都是后话了，大部分情况直接DROP就行。

第五步：验货，确保问题解决 删除之后，别以为就完了，再执行第一步的那个查询语句，看看现在是不是只剩下一个MAXVALUE分区了，尝试执行一下之前引发报错的那个操作（比如分裂分区），看看是否还报ORA-14322错误，如果顺利执行，那么恭喜你，这个问题就圆满解决了！

总结一下 整个处理ORA-14322的过程，其实就是个细致的排查活：确认问题 -> 分析情况 -> 备份数据 -> 执行操作 -> 验证结果，远程修复的核心在于清晰的沟通和准确的指令执行，你作为在现场的人，需要清晰地反馈查询结果，而我作为指导方，需要根据你的反馈给出下一步的精确指令。

最后再啰嗦一句,数据库操作无小事，尤其是这种分区表的结构变更，平时养成良好的记录习惯，比如给分区起个清晰的名字，记录下重要的结构变更，就能在很大程度上避免这类“双胞胎”问题的发生，希望这个解释能帮到你！