运维反馈部分客户在升级过程中，升级脚本报错，错误信息为：
ORA-01720:不存在'SYS.DUAL'的授权选项
而这些报错的视图都有一个特性，都使用了DUAL表
出问题后客户DBA第一时间介入排查但未找到解决方案导致客户只能回退版本，无法正常升级。
在收到该问题反馈后，第一时间进行百度，但是实际上百度上的答案均无法解决客户的问题。根据现场描述，在本地模拟最终分析出问题原因。
根据用户反馈，程序共有两个用户分别是查询用户和更新用户，查询用户用于运维，更新用户则用于升级和程序的连接。
因此为了演示用户的错误发生原因，需要使用PBB和PBB1两个用户来演示。其中PBB代表更新用户，PBB1代表查询用户。
首先为PBB和PBB1用户赋权，一般来说为了正常执行，用户必须要有
Connect 和resource两个角色的权限
grant connect to PBB;
grant resource to PBB;
grant connect to PBB1;
grant resource to PBB1;
由于涉及到视图，因此更新用户PBB1还需要create view的权限用于创建视图
grant create view to PBB;
然后查看报错脚本发现均是由 from dual的视图引起，因此创建模拟脚本并执行创建视图
create or replace view v_pbb as Select DUMMY from dual;
然后将V_PBB视图赋予给PBB1用户，在赋予权限前首先在生产上通过以下语句查询可以得知用户赋予了对象哪些权限
select * from dba_tab_privs where TABLE_NAME LIKE '%V_PBB%'
客户生产的赋权就像上图一样，所以我们需要用使用DBA或者更高权限的用户赋权，从这里其实就能看出客户存在过度赋权的情况。为了模拟过度赋权执行以下命令
grant all on pbb.V_PBB to pbb1;
最后执行升级脚本
create or replace view v_pbb as Select DUMMY from dual;
结果出错了，并且错误和反馈的一致。
这是为什么呢？
这就得从DUAL说起，首先DUAL是SYS用户下的一张表，我们平时select * from dual是通过公共同义词来访问的。为了查询同义词的底层表你必须拥有对表的查询权限，而这个权限已经包含在connect角色中了，所以一旦你被赋予了connect角色你也就拥有了对这张表的查询权限。有且仅有查询权限
当我们用DBA或者更高权限的用户将PBB的V_PBB视图赋予给PBB1时，因为客户使用了ALL，所以PBB1因此得到了V_PBB的所有操作权限。
但是当我们重新在PBB用户下替换这个视图的时候也就意味着在PBB刷新了给予PBB1的权限，但是这时候无法完成赋权，因为PBB想将DUAL的所有权限赋值给PBB1，但是PBB本身只有SELECT 权限，而不包含其他权限。所以导致视图的替换就无法完成。所以这时候就抛出ora-01720:不存在'SYS.DUAL'的授权选项的错误了
为了解决这个问题非常简单，只要移除视图V_PBB除SELECT以外的权限即可。或者删除V_PBB视图然后重新创建也可以，因为删除的时候所有赋权也会一并移除，当然之后千万别忘记重新赋予SELECT权限。
所以这个问题实际上是客户赋权引起的一个问题，而在正确的赋权情况下，from dual的视图是不应该被赋予select以外权限的。
需要特别注意的是经过多个版本的测试发现11.2.0.4之前的版本可以通过错误的方式赋权（即上面的错误在11.2.0.4之前的版本是不会报错的），但是11.2.0.4以及之后的版本是不允许错误赋权的，客户的版本刚好是11.2.0.4
