ORA-20002: Version of statistics table APPLSYS.FND_STATTAB is too old.

在将9i的统计信息导入11g时遇到错误ORA-20002,提示统计信息表版本过旧。解决方案是通过执行DBMS_STATS.UPGRADE_STAT_TABLE升级统计表,例如:EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('DBMGR','FWYSTAT')。此问题与11g的内部兼容性有关,需要升级以使9i的执行计划在11g中被正确识别。" 83177502,7883705,NPDP认证详解:费用、考试与备考,"['NPDP', '产品经理', '认证考试', '职场发展', '职业技能']

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天在收集9i的统计信息导入到11g是发现无法兼容的问题。

SQL> begin

  2    dbms_stats.import_table_stats(ownname => 'REINSUDATA' ,tabname =>  'FAC_ENDORSE' , stattab => 'FWYSTAT' ,statown =>  'DBMGR') ;

  3  end ;

  4  /

begin

*

ERROR at line 1:

ORA-20002: Version of statistics table DBMGR.FWYSTAT is too old.  Please try

upgrading it with dbms_stats.upgrade_stat_table

ORA-06512: at "SYS.DBMS_STATS", line 11013

ORA-06512: at "SYS.DBMS_STATS", line 12396

ORA-06512: at line 2

 

真的很奇怪,导出的统计信息居然无法导入,还提示要更新一下。

上metalink上查了一下,居然是11g的内部兼容问题,9i的执行计划在11g上识别不了,必须更新一下才能识别。

Cause
This is part of the 11g interoperatibility requirements. Note 452783.1, step 13: "Upgrade the database instance" includes the following:

"When upgrading all statistics tables, note that Oracle Applic

<think>好的,我现在需要解决用户遇到的Oracle数据库错误,主要是ORA-01031权限不足和ORA-06512在DBMS_SNAPSHOT包中的问题。首先,我需要回顾用户提供的引用内容,看看有没有相关的线索。 根据引用[1]和[2],用户在执行DBMS_MVIEW.REFRESH时遇到了ORA-01031错误,这说明当前用户没有足够的权限来刷新物化视图。ORA-06512指出了错误发生的位置,具体是在DBMS_SNAPSHOT包的某个行数。这可能意味着用户需要被授予特定的系统权限,比如CREATE MATERIALIZED VIEW或者ALTER ANY MATERIALIZED VIEW。另外,可能还需要检查物化视图所属用户的权限,确保有权限访问基表。 接下来,引用[3]提到了JOB异常和ORA-06512,可能与权限或存储过程有关。引用[4]涉及到数据泵的问题,但当前用户的问题主要集中在物化视图刷新上,所以暂时可以忽略数据泵相关的错误。 首先,我会建议用户检查当前执行刷新操作的用户是否具有必要的权限。可能需要授予CREATE MATERIALIZED VIEW或者更具体的权限,比如在物化视图上的SELECT权限。此外,如果物化视图属于另一个用户(如user_a),则需要确保当前用户有权限访问该物化视图,并且基表的SELECT权限也被正确授予。 另外,用户可能需要直接授予EXECUTE权限在DBMS_SNAPSHOT或DBMS_MVIEW包上,因为有时候即使有系统权限,如果没有包的执行权限,也会导致问题。例如,执行DBMS_MVIEW.REFRESH可能需要EXECUTE ON DBMS_MVIEW。 然后,检查物化视图的定义,确认基表的权限是否正确。如果基表属于其他用户,可能需要通过角色授予权限,但Oracle在存储过程中有时不继承角色权限,所以最好直接授予给用户。 还有可能需要检查是否在创建物化视图时使用了QUERY REWRITE权限,特别是如果物化视图用于查询重写的话。此外,检查用户是否有足够的表空间配额,避免因为空间不足导致错误,但这里的主要错误是权限问题,所以配额可能不是主要原因。 如果用户被授予了必要的权限,但仍然遇到问题,可能需要检查是否存在同义词问题,或者物化视图的依赖对象是否有权限问题。例如,物化视图可能引用了其他用户的表、视图或函数,这些都需要显式授权。 总结步骤应该是:授予系统权限、授予对象权限、检查包的执行权限、验证基表权限、检查角色权限的继承问题,最后考虑其他可能的原因,比如存储过程权限或环境配置。 最后,生成相关问题,帮助用户进一步排查其他可能的错误,比如角色权限的问题、如何查看现有权限、处理存储过程中的权限问题等。</think>### 解决方案:ORA-01031权限不足与ORA-06512错误处理 #### 1. 检查系统权限 **问题根源**:执行`DBMS_MVIEW.REFRESH`或操作物化视图时,用户需具备以下权限: - `CREATE MATERIALIZED VIEW`:创建/刷新物化视图的权限 - `ALTER ANY MATERIALIZED VIEW`:修改其他用户的物化视图权限 - `SELECT`权限:访问基表的权限[^1][^2] **操作步骤**: ```sql -- 以SYSDBA身份登录后执行 GRANT CREATE MATERIALIZED VIEW TO user_a; GRANT ALTER ANY MATERIALIZED VIEW TO user_a; GRANT SELECT ON base_table TO user_a; -- 替换为实际基表名 ``` #### 2. 验证包执行权限 **问题根源**:若用户缺少`DBMS_SNAPSHOT`或`DBMS_MVIEW`包的`EXECUTE`权限,会触发ORA-01031错误。 **操作步骤**: ```sql GRANT EXECUTE ON SYS.DBMS_SNAPSHOT TO user_a; GRANT EXECUTE ON SYS.DBMS_MVIEW TO user_a; ``` #### 3. 检查对象所有权 **问题根源**:若物化视图属于其他用户,需显式授予权限: ```sql -- 以物化视图所有者身份执行 GRANT SELECT ON mv_demo TO user_a; -- 替换为实际物化视图名 ``` #### 4. 处理角色权限问题 **问题根源**:Oracle存储过程不继承角色权限,需直接授予用户。 **验证方法**: ```sql -- 查看用户权限 SELECT * FROM USER_SYS_PRIVS; SELECT * FROM USER_TAB_PRIVS; ``` #### 5. 其他可能原因 - **QUERY REWRITE权限**:若物化视图用于查询重写,需授予`QUERY REWRITE`权限: ```sql GRANT QUERY REWRITE TO user_a; ``` - **表空间配额**:确保用户有足够空间配额: ```sql ALTER USER user_a QUOTA UNLIMITED ON tablespace_name; ``` --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值