v$sql和v$sqlarea视图的区别

v$sql和v$sqlarea视图：
    v$sqlarea和v$sql两个视图的不同之处在于，v$sql中为每一条SQL保留一个条目，而v$sqlarea中根据sql_text进行group by，通过version_count计算子游标的个数。
v$SQL视图介绍：
    v$sql视图列举了共享SQL区（Shared SQL Area）中的SQL统计信息，这个视图中的信息未经分组，每个SQL指针都包含一条独立的记录。这个视图的字段如下：
SQL_TEXT： VARCHAR2(1000)           SQL文本的前1000个字符 
SHARABLE_MEM： NUMBER               占用的共享内存大小(单位：byte) 
PERSISTENT_MEM： NUMBER             生命期内的固定内存大小(单位：byte) 
RUNTIME_MEM： NUMBER                 执行期内的固定内存大小 
SORTS： NUMBER                   完成的排序数 
LOADED_VERSIONS： NUMBER           显示上下文堆是否载入，1是0否 
OPEN_VERSIONS： NUMBER             显示子游标是否被锁，1是0否 
USERS_OPENING： NUMBER             执行语句的用户数 
FETCHES： NUMBER                   SQL语句的fetch数。 
EXECUTIONS： NUMBER                 自它被载入缓存库后的执行次数 
USERS_EXECUTING： NUMBER             执行语句的用户数 
LOADS： NUMBER                     对象被载入过的次数 
FIRST_LOAD_TIME： VARCHAR2(19)         初次载入时间 
INVALIDATIONS： 无效的次数 
PARSE_CALLS： 解析调用次数 
DISK_READS： 读磁盘次数 
BUFFER_GETS： 读缓存区次数 
ROWS_PROCESSED： 解析SQL语句返回的总列数 
COMMAND_TYPE： 命令类型代号 
OPTIMIZER_MODE： VARCHAR2(10)       SQL语句的优化器模型 
OPTIMIZER_COST： 优化器给出的本次查询成本 
PARSING_USER_ID： 第一个解析的用户ID 
PARSING_SCHEMA_ID： 第一个解析的计划ID 
PARSING_SCHEMA_NAME： 最初创建子游标的用户名称
KEPT_VERSIONS： 指出是否当前子游标被使用DBMS_SHARED_POOL包标记为常驻内存 
ADDRESS： RAW(4 | 8)         当前游标父句柄地址 
TYPE_CHK_HEAP： 当前堆类型检查说明 
HASH_VALUE： 缓存库中父语句的Hash值 
PLAN_HASH_VALUE： 数值表示执行计划的hash值。 
CHILD_NUMBER： number   子游标号，sql解析时，产生的子游标
MODULE： 在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_MODULE设置的模块名称。 
ACTION： 在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_ACTION设置的动作名称。 
SERIALIZABLE_ABORTS： 事务未能序列化次数 
OUTLINE_CATEGORY： 如果outline在解释cursor期间被应用，那么本列将显示出outline各类，否则本列为空 
CPU_TIME： 解析/执行/取得等CPU使用时间(单位，毫秒) 
ELAPSED_TIME： 解析/执行/取得等消耗时间(单位，毫秒) 
OUTLINE_SID： outline session标识 
CHILD_ADDRESS： 子游标地址
SQLTYPE： 指出当前语句使用的SQL语言版本 
REMOTE： 指出是否游标是一个远程映象(Y/N) 
OBJECT_STATUS： 对象状态(VALID or INVALID) 
IS_OBSOLETE： 当子游标的数量太多的时候，指出游标是否被废弃(Y/N) 

常用列：

Column Datatype   Descrption
SQL_TEXT VARCHAR2(1000) 当前SQL指针的前1000个字符（也就是说这里记录的SQL是不完整的）
EXECUTIONS NUMBER 执行次数
DISK_READS NUMBER 这个子指针Disk Read的次数
BUFFER_GETS NUMBER 这个子指针的Buffer Gets数量
OPTIMIZER_MODE VARCHAR2(10) SQL执行的优化器模式
OPTIMIZER_COST NUMBER SQL执行成本
HASH_VALUE NUMBER 在Library Cache中父指针的Hash Value值

例子：
--同样的sql，在执行多次后，物理读 逻辑读 执行次数是如何增加的
set autotrace traceonly 
select count(*) from test.t2;
第一次执行：
Execution Plan
----------------------------------------------------------
Plan hash value: 3321871023
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   288   (1)| 00:00:04 |
|   1 |  SORT AGGREGATE     |       |     1 |                 |                   |
|   2 |   TABLE ACCESS FULL| T2   | 72143 |   288   (1)| 00:00:04 |
-------------------------------------------------------------------
Statistics
----------------------------------------------------------
        224  recursive calls
          0  db block gets
       1055  consistent gets
       1028  physical reads
          0  redo size
        528  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          4  sorts (memory)
          0  sorts (disk)
          1  rows processed
select a.SQL_ID,sql_text,a.ADDRESS,hash_value,executions,disk_reads,optimizer_mode,buffer_gets,
a.PARSING_SCHEMA_NAME,a.CHILD_NUMBER
from v$sql a where sql_text='select count(*) from test.t2';  

   SQL_ID SQL_TEXT ADDRESS HASH_VALUE EXECUTIONS DISK_READS OPTIMIZER_MODE BUFFER_GETS PARSING_SCHEMA_NAME CHILD_NUMBER
1 d4yp2ktfzs9ku select count(*) from test.t2 0000000089C99258 1576805978 1 1028 ALL_ROWS 1055 SYS 0

第二次执行： 

这里存在疑问，set autotrace traceonly 后面的sql实际上，在数据库后台是真实执行了的，为什么第一次执行的sql，使用了物理读，第二次执行还会有物理读呢？（理论上，第二次执行，已经把数据缓存在内存中）

Execution Plan
----------------------------------------------------------
Plan hash value: 3321871023
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   288   (1)| 00:00:04 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T2   | 72143 |   288   (1)| 00:00:04 |
-------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1032  consistent gets
       1027  physical reads
          0  redo size
        528  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
    SQL_ID SQL_TEXT ADDRESS HASH_VALUE EXECUTIONS DISK_READS OPTIMIZER_MODE BUFFER_GETS PARSING_SCHEMA_NAME CHILD_NUMBER
1 d4yp2ktfzs9ku select count(*) from test.t2 0000000089C99258 1576805978 2 2055 ALL_ROWS 2087 SYS 0

第三次执行：
 Execution Plan
----------------------------------------------------------
Plan hash value: 3321871023
-------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |      |     1 |   288   (1)| 00:00:04 |
|   1 |  SORT AGGREGATE    |      |     1 |            |          |
|   2 |   TABLE ACCESS FULL| T2   | 72143 |   288   (1)| 00:00:04 |
-------------------------------------------------------------------
Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       1032  consistent gets
          0  physical reads
          0  redo size
        528  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
 
    SQL_ID  SQL_TEXT ADDRESS HASH_VALUE EXECUTIONS DISK_READS OPTIMIZER_MODE BUFFER_GETS PARSING_SCHEMA_NAME CHILD_NUMBER
1 d4yp2ktfzs9ku select count(*) from test.t2 0000000089C99258 1576805978  3 2055 ALL_ROWS 3119 SYS 0

相关视图 v$sqlarea
v$sqlarea视图也是非常重要的一个视图，在Oracle 9iR2的文档中，Oracle这样定义这个视图：v$sqlarea列出了共享SQL区（Shared SQL Area）中的SQL统计信息，这些SQL按照SQL文本的不同，每条会记录一行统计数据。注意这里所说的是“按照SQL文本”来进行区分，也就是说这个视图的信息可以看作是根据SQL_TEXT进行的一次汇总统计。

v$sqlarea视图的主要字段如下：
Column   Datatype Description
SQL_TEXT VARCHAR2(1000) 当前指针的前1000个字符
VERSION_COUNT NUMBER Cache中这个父指针下存在的子指针的数量
EXECUTIONS NUMBER 总的执行次数，包含所有子指针执行次数的汇总
DISK_READS NUMBER 所有子指针的Disk Reads总和
BUFFER_GETS NUMBER 所有子指针的Buffer Gets总和
OPTIMIZER_MODE VARCHAR2(10) SQL执行的优化器模
HASH_VALUE NUMBER 父指针的Hash Value


例子:

文本相同的SQL语句，在数据库中的意义可能完全不同。比如数据库中存在两个用户test和ceshi，两个用户各拥有一张数据表t4，t4表中的数据完全不一样。那么来测试下，这样的情况下，v$sql视图是如何记录的。

create table test.t4 as select * from test.t2;
create table ceshi.t4 as select * from test.t2;
SQL> conn test/test;
Connected.
SQL> select count(*) from t4;
Execution Plan
----------------------------------------------------------
Plan hash value: 405148644
------------------------------------------------------------------
| Id  | Operation          | Name | Rows  | Cost (%CPU)| Time     |
-------------------------------------------------------------------
|   0 | SELECT STATEMENT   |        |     1 |   288   (1)| 00:00:04 |
|   1 |  SORT AGGREGATE     |         |     1 |                  |                  |
|   2 |   TABLE ACCESS FULL| T4   | 68679 |   288   (1)| 00:00:04 |
-------------------------------------------------------------------
Note
-----
   - dynamic sampling used for this statement (level=2)
Statistics
----------------------------------------------------------
         28  recursive calls
          0  db block gets
       1099  consistent gets
       1027  physical reads
          0  redo size
        528  bytes sent via SQL*Net to client
        523  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

ceshi用户执行sql
SQL> select count(*) from t4;
v$sql视图查询结果：
select a.SQL_ID,sql_text,a.ADDRESS,hash_value,executions,disk_reads,optimizer_mode,buffer_gets,
a.PARSING_SCHEMA_NAME,a.CHILD_NUMBER
from v$sql a where sql_text='select count(*) from t4';  

    SQL_ID  SQL_TEXT  ADDRESS HASH_VALUE EXECUTIONS DISK_READS    OPTIMIZER_MODE BUFFER_GETS PARSING_SCHEMA_NAME CHILD_NUMBER
1 7mx2ntc452hap select count(*) from t4 0000000091AE33A0 139542869 1 1027 ALL_ROWS 1099 TEST 0
2 7mx2ntc452hap select count(*) from t4 0000000091AE33A0 139542869 2 0 ALL_ROWS 2134 CESHI 1

v$sqlarea视图查询结果：
select b.SQL_ID,sql_text,b.ADDRESS,b.HASH_VALUE,executions,disk_reads,buffer_gets,b.PARSING_SCHEMA_NAME,version_count
from v$sqlarea b where sql_text='select count(*) from t4';  

    SQL_ID   SQL_TEXT  ADDRESS  HASH_VALUE EXECUTIONS DISK_READS BUFFER_GETS PARSING_SCHEMA_NAME VERSION_COUNT
1 7mx2ntc452hap select count(*) from t4 0000000091AE33A0 139542869 3 1027 3233 CESHI 2

在这个视图中，Oracle将v$sql中的sql_text相同的2个子指针合并起来，执行次数等信息也都进行了累计，version_count也显示为2，这就是v$sqlarea的聚合作用。


这里存在疑问，PARSING_SCHEMA_NAME的值，在v$sql中有2个值，在v$sqlarea中只有一个，test用户的sql哪里去了?