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哪里去了?

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值