ORA-29882报错权限不够执行indextype，远程帮忙修复问题过程分享

ORA-29882报错权限不够执行indextype，远程帮忙修复问题过程分享

这个ORA-29882错误的解决过程，是我前几天远程帮一个朋友处理他们数据库问题时遇到的，整个过程有点曲折，最后发现原因挺隐蔽的，所以觉得有必要分享一下,希望能帮到遇到类似情况的人。

那天下午，朋友在线上着急地找我，说他们在测试环境做一个功能升级，脚本跑着跑着就卡住了，数据库抛出了一个ORA-29882错误，他发来了错误的截图，完整的信息是“ORA-29882: 无法在索引组织表上创建域索引”或者与INDEXTYPE相关的权限不足，他告诉我，他们的脚本是要在一个特定的表上创建一个“域索引”，这种索引不是普通的B树索引,而是用了某种特定的索引类型。

朋友说他们已经检查了执行脚本的那个数据库用户，确认这个用户确实拥有“CREATE ANY INDEX”系统权限，照理说创建索引的权限是够的，但他们一试再试，每次都停在同一个报错上，项目进度被卡住了,所以很着急。

我让他先通过远程软件共享了屏幕，我让他重新执行了一遍那个出错的CREATE INDEX语句，错误信息再次弹出，确认是ORA-29882，我的第一反应和朋友一开始的想法一样：是不是权限没给够？虽然有了CREATE ANY INDEX,但创建域索引可能还需要一些特殊的权限。

我让他用DBA账号登录数据库，查询了一下数据字典，我让他执行了一个查询，查看那个特定的INDEXTYPE（索引类型）的归属和权限情况，查询语句大概是这样的：（来源：根据数据库数据字典视图ALL_INDEXTYPES, DBA_INDEXTYPES）SELECT owner, indextype_name FROM all_indextypes WHERE indextype_name = '他们用的索引类型名';，结果发现，这个INDEXTYPE属于另一个用户,比如叫SCOTT。

这时，问题的关键点开始浮现了，创建域索引的过程，不仅仅是调用CREATE INDEX那么简单，它背后会去执行这个INDEXTYPE所有者（SCOTT用户）所定义的一些方法或函数，执行操作的用户不仅需要创建索引的权限,还需要有权限去执行那个属于SCOTT用户的特定对象。

我让朋友检查当前操作的用户是否被显式授予了执行这个INDEXTYPE的权限，他查了一下，说没有直接授予，这很可能就是问题的根源了，我指导他用DBA账号执行了一条授权语句：（来源：Oracle官方文档关于INDEXTYPE的EXECUTE权限说明）GRANT EXECUTE ON scott.他们用的索引类型名 TO 当前操作用户名;，授权成功后,我们满怀希望地让朋友再次执行创建索引的脚本。

错误依旧！还是那个ORA-29882，这就有点奇怪了，权限明明已经授予了，为什么还不行？我们一度怀疑是不是授权没生效，或者需要重新登录，在尝试重新连接会话后,问题依然存在。

看来问题比想象的要复杂，我静下心来想了想，创建域索引可能是一个比较“重”的操作，它可能不仅需要执行INDEXTYPE的权限，在索引组织表这种特殊的表上操作，可能还需要一些底层对象的权限，我让朋友再次仔细查看了一下这个INDEXTYPE的详细信息,特别是它的实现方式。

经过更深入的排查，（来源：通过查询DBA_INDEXTYPE_OPERATORS等视图关联分析）我们发现这个INDEXTYPE在底层依赖了一个或多个特定的操作符或者类型，而这些对象同样属于SCOTT用户，也就是说，执行用户需要一整套相关的权限,而不仅仅是对INDEXTYPE本身的EXECUTE权限。

我让朋友尝试性地将SCOTT用户下与这个INDEXTYPE相关的一系列核心对象（比如特定的对象类型、操作符等）的EXECUTE权限，都批量授予当前的操作用户，为了确保万无一失，我们甚至尝试了授予一个较大的权限包（这是在测试环境，生产环境要谨慎），授权语句类似于：GRANT EXECUTE ON scott.相关对象1 TO 当前用户; GRANT EXECUTE ON scott.相关对象2 TO 当前用户; ... 这样执行了好几条。

完成这一系列授权后，我们再次尝试创建索引，这次，命令行提示符安静地跳转，没有出现红色的错误信息！朋友赶紧查询了一下索引是否创建成功，结果显示索引已经安然无恙地建立在了那个表上,问题终于解决了。

回顾整个过程，这个ORA-29882报错的根本原因在于权限的“深度”，对于普通的索引，可能一个CREATE ANY INDEX就够了，但对于域索引这种复杂对象，它像一棵大树，有主干（INDEXTYPE本身）也有根系（它所依赖的其他数据库对象），执行用户必须拥有对整个“权限树”的访问能力，缺一不可，最初我们只解决了主干的权限（EXECUTE ON INDEXTYPE），却忽略了它依赖的根系权限，所以导致了第二次失败，这次远程协助的经历再次提醒我们，处理数据库权限问题，一定要有耐心，要考虑到权限的继承和依赖关系，层层深入,才能找到最终的解药。