> oerr ora 12041
12041, 00000, "cannot record ROWIDs for index-organized table \"%s\".\"%s\""
// *Cause: Index-organized tables do not have ROWIDs. Therefore a materialized
// view log that records the ROWIDs of an index-organized table
// could not be created.
// *Action: Do not include the WITH ROWID option when using the
// CREATE MATERIALIZED VIEW command and do not include the ADD ROWID
// option when using the ALTER MATERIALIZED VIEW command if the master
// table is index-organized.
其实碰到问题的时候，办法总比困难多。有很多的方式来解决,如果处理得当，就会避免很多后续的问题。
比如今天开发反馈在测试环境导入一个dump的时候 碰到了如下的错误。这个问题是很常见的。
Export file created by EXPORT:V11.02.00 via conventional path
IMP-00013: only a DBA can import a file exported by another DBA
IMP-00000: Import terminated unsuccessfully
基本有两种思路，一种是赋予dba权限，另外一种是赋予imp_full_database的权限。
通过错误的字面意思，是需要赋予dba的权限。如果这样做，就很被动了，因为目前测试环境有几十个，分别归属不同的开发小组，他们会根据需求导入对应的dump，这个dump是直接从现场环境中传过来的，导出的时候就直接用了dba的权限，所以在导入的时候就出了上面的错误。如果我们这次赋予了dba权限，那么这个用户就存在一定的风险，如果开发做了超出权限之外的操作，那就会造成一些不明不白的问题，所以如果赋予了dba权限，那么在dump导入之后就需要revoke dba权限。如果dba每次都去跟踪这些操作就显得有些“多余”了。所以就陷入一个很尴尬的境地，权限放开出问题是dba，不给权限导不了dump还是dba的问题。如果能够一劳永逸的解决问题就太好了。
这个时候如果我们细细的琢磨一下这个问题，就会发现，其实我们直接赋予imp_full_database的权限就够了。不用直接动用dba权限。
这个imp_full_database的权限目前来看也是安全的。如果开发拿到这个权限，还真干不了什么其他的操作。
所以目前为止我们可以认为imp_full_database的权限已经足够应付这个问题，不需要大动干戈，做吃力不讨好的事情。
事情到目前为止还没有完，真实的情况是过了一段时间又出现了问题。这次是在现场测试环境中碰到了，问题的原因是因为在开发测试环境中会有一些数据字典相关的数据。如果把各个模块的数据字典数据合并起来，就是一个dump文件了，根据流程这个dump文件需要在生产中部署。结果在现场的测试环境中就发现了这个问题。
这个问题说大也大，说下也小，当时有个哥们的处理思路就是生产环境中直接加个imp_full_database的权限就可以了。我当时就拒绝了。客户的环境中的任何权限，他们都有监控，我们不能在没有得到许可的情况下私自改动。
那个哥们当时也有点急了。
Man...
its just a privilege
otherwise we have to work again
you can revoke it
after my confirmation
我给他解释了一番，如果我们现在在哪个环境中碰到了问题，就这么修，那么现场测试环境也有几十套，我们也要一套一套这么修吗。况且现场环境中会不断的增加新的测试环境，没次新增一个，客户都会找到我说，你们的环境有问题，这样就把问题又推给dba了。到了生产，如果我们放了一马，私自修改了权限，那么从生产中导出的dump文件都需要这个权限，又得修。所以就是错误的连锁反应了。他听了听，也确实有道理就把测试环境中的那个权限给revoke了之后，重新导出了一个dump。直到一年多过去了，也没有听说过生产中导入dump有问题。
所以对于这个问题的归纳就是，赋予imp_full_database权限，也不能一概而论，要根据需要来。要不就会画蛇添足。开发，测试，dba都工作相安无事才是真的好。
