测试一下grant 语句对于SQL执行计划的影响。
Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, Automatic Storage Management, OLAP, Data Mining
and Real Application Testing options

SQL> create table b as select * from dba_objects;

Table created.


SQL> select /* lala*/ count(*) from b;

  COUNT(*)
----------
     76147


SQL>  select sql_id,
  2          address,
  3          hash_value,
  4          executions,
  5          loads,
  6          version_count,
  7          invalidations,
  8          parse_calls,
  9          plan_hash_value
10    from v$sqlarea
11   where sql_text like '%lala%'
12     and sql_text not like '%v$sqlarea%';

SQL_ID        ADDRESS          HASH_VALUE EXECUTIONS      LOADS VERSION_COUNT INVALIDATIONS PARSE_CALLS PLAN_HASH_VALUE
------------- ---------------- ---------- ---------- ---------- ------------- ------------- ----------- ---------------
5vhdjcd09hhuj 000000142EEBE120 1083720529          1          1             1             0           1       749587668

SQL> select address,operation,to_char(timestamp,'HH24:MI:SS') from v$sql_plan where plan_hash_value= 749587668;

ADDRESS          OPERATION                                                    TO_CHAR(
---------------- ------------------------------------------------------------ --------
000000142EEBE120 SELECT STATEMENT                                             10:58:16
000000142EEBE120 SORT                                                         10:58:16
000000142EEBE120 TABLE ACCESS                                                 10:58:16


SQL>  grant select on b to rho;

Grant succeeded.

SQL>  select sql_id,
  2          address,
  3          hash_value,
  4          executions,
  5          loads,
  6          version_count,
  7          invalidations,
  8          parse_calls,
  9          plan_hash_value
10    from v$sqlarea
11   where sql_text like '%lala%'
12     and sql_text not like '%v$sqlarea%';

SQL_ID        ADDRESS          HASH_VALUE EXECUTIONS      LOADS VERSION_COUNT INVALIDATIONS PARSE_CALLS PLAN_HASH_VALUE
------------- ---------------- ---------- ---------- ---------- ------------- ------------- ----------- ---------------
5vhdjcd09hhuj 000000142EEBE120 1083720529          1          1             1             1           1       749587668

SQL> select address,operation,to_char(timestamp,'HH24:MI:SS') from v$sql_plan where plan_hash_value= 749587668;

ADDRESS          OPERATION                                                    TO_CHAR(
---------------- ------------------------------------------------------------ --------
000000142EEBE120 SELECT STATEMENT                                             10:58:16
000000142EEBE120 SORT                                                         10:58:16
000000142EEBE120 TABLE ACCESS                                                 10:58:16

SQL> select /* lala*/ count(*) from b;

  COUNT(*)
----------
     76147

SQL>  select sql_id,
  2          address,
  3          hash_value,
  4          executions,
  5          loads,
  6          version_count,
  7          invalidations,
  8          parse_calls,
  9          plan_hash_value
10    from v$sqlarea
11   where sql_text like '%lufei%'
12     and sql_text not like '%v$sqlarea%';

SQL_ID        ADDRESS          HASH_VALUE EXECUTIONS      LOADS VERSION_COUNT INVALIDATIONS PARSE_CALLS PLAN_HASH_VALUE
------------- ---------------- ---------- ---------- ---------- ------------- ------------- ----------- ---------------
5vhdjcd09hhuj 000000142EEBE120 1083720529          1          2             1             1           1       749587668

SQL>  select address,operation,to_char(timestamp,'HH24:MI:SS') from v$sql_plan where plan_hash_value= 749587668;

ADDRESS          OPERATION                                                    TO_CHAR(
---------------- ------------------------------------------------------------ --------
000000142EEBE120 SELECT STATEMENT                                             11:00:49
000000142EEBE120 SORT                                                         11:00:49
000000142EEBE120 TABLE ACCESS                                                 11:00:49

以下都会引起硬解析

1. SQL语句没有使用绑定变量，这样SQL每次执行都要解析。
2. SQL长时间没有执行，被刷出SHARED POOL，再次执行时需要重新解析。
3. 在SQL引用的对象（表、视图等）上执行了DDL操作，甚至是结构发生了变化，比如建了一个索引。
4. 对SQL引用的对象进行了权限更改。
5. 重新分析/收集SQL引用的表和索引，或者表和索引统计信息被删除。
6. 修改了与优化器相关的部分参数。
7. 刷新了共享池。
8. 重启数据库也会使所有SQL全部重新解析