学习动态性能表 第三篇-(1)-v$sql

本文涉及的产品
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
简介: 学习动态性能表 第三篇-(1)-v$sql  V$SQL中存储具体的SQL语句。   一条语句可以映射多个cursor,因为对象所指的cursor可以有不同用户(如例1)。如果有多个cursor(子游标)存在,在V$SQLAREA为所有cursor提供集合信息。
 

学习动态性能表

第三篇-(1)-v$sql 

V$SQL中存储具体的SQL语句。

  一条语句可以映射多个cursor,因为对象所指的cursor可以有不同用户(如例1)。如果有多个cursor(子游标)存在,在V$SQLAREA为所有cursor提供集合信息。

1

这里介绍以下child cursor

user A: select * from tbl

user B: select * from tbl

大家认为这两条语句是不是一样的啊,可能会有很多人会说是一样的,但我告诉你不一定,那为什么呢?

这个tblA看起来是一样的,但是不一定哦,一个是A用户的, 一个是B用户的,这时他们的执行计划分析代码差别可能就大了哦,改下写法大家就明白了:

select * from A.tbl

select * from B.tbl

  在个别cursor上,v$sql可被使用。该视图包含cursor级别资料。当试图定位session或用户以分析cursor时被使用。

  PLAN_HASH_VALUE列存储的是数值表示的cursor执行计划。可被用来对比执行计划。PLAN_HASH_VALUE让你不必一行一行对比即可轻松鉴别两条执行计划是否相同。

V$SQL中的列说明:

l         SQL_TEXTSQL文本的前1000个字符

l         SHARABLE_MEM:占用的共享内存大小(单位:byte)

l         PERSISTENT_MEM:生命期内的固定内存大小(单位:byte)

l         RUNTIME_MEM:执行期内的固定内存大小

l         SORTS:完成的排序数

l         LOADED_VERSIONS:显示上下文堆是否载入,10

l         OPEN_VERSIONS:显示子游标是否被锁,10

l         USERS_OPENING:执行语句的用户数

l         FETCHESSQL语句的fetch数。

l         EXECUTIONS:自它被载入缓存库后的执行次数

l         USERS_EXECUTING:执行语句的用户数

l         LOADS:对象被载入过的次数

l         FIRST_LOAD_TIME:初次载入时间

l         INVALIDATIONS:无效的次数

l         PARSE_CALLS:解析调用次数

l         DISK_READS:读磁盘次数

l         BUFFER_GETS:读缓存区次数

l         ROWS_PROCESSED:解析SQL语句返回的总列数

l         COMMAND_TYPE:命令类型代号

l         OPTIMIZER_MODESQL语句的优化器模型

l         OPTIMIZER_COST:优化器给出的本次查询成本

l         PARSING_USER_ID:第一个解析的用户ID

l         PARSING_SCHEMA_ID:第一个解析的计划ID

l         KEPT_VERSIONS:指出是否当前子游标被使用DBMS_SHARED_POOL包标记为常驻内存

l         ADDRESS:当前游标父句柄地址

l         TYPE_CHK_HEAP:当前堆类型检查说明

l         HASH_VALUE:缓存库中父语句的Hash

l         PLAN_HASH_VALUE:数值表示的执行计划。

l         CHILD_NUMBER:子游标数量

l         MODULE:在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_MODULE设置的模块名称。

l         ACTION:在第一次解析这条语句是通过调用DBMS_APPLICATION_INFO.SET_ACTION设置的动作名称。

l         SERIALIZABLE_ABORTS:事务未能序列化次数

l         OUTLINE_CATEGORY:如果outline在解释cursor期间被应用,那么本列将显示出outline各类,否则本列为空

l         CPU_TIME:解析/执行/取得等CPU使用时间(单位,毫秒)

l         ELAPSED_TIME:解析/执行/取得等消耗时间(单位,毫秒)

l         OUTLINE_SIDoutline session标识

l         CHILD_ADDRESS:子游标地址

l         SQLTYPE:指出当前语句使用的SQL语言版本

l         REMOTE:指出是否游标是一个远程映象(Y/N)

l         OBJECT_STATUS:对象状态(VALID or INVALID)

l         IS_OBSOLETE:当子游标的数量太多的时候,指出游标是否被废弃(Y/N)

第三篇-(2)-V$SQL_PLAN 2007.5.28

  本视图提供了一种方式检查那些执行过的并且仍在缓存中的cursor的执行计划。

  通常,本视图提供的信息与打印出的EXPLAIN PLAN非常相似,不过,EXPLAIN PLAN显示的是理论上的计划,并不一定在执行的时候就会被使用,但V$SQL_PLAN中包括的是实际被使用的计划。获自EXPLAIN PLAN语句的执行计划跟具体执行的计划可以不同,因为cursor可能被不同的session参数值编译(如,HASH_AREA_SIZE)

V$SQL_PLAN中数据可以:

l         确认当前的执行计划

l         鉴别创建表索引效果

l         寻找cursor包括的存取路径(例如,全表查询或范围索引查询)

l         鉴别索引的选择是否最优

l         决定是否最优化选择的详细执行计划(如,nested loops join)如开发者所愿。

  本视图同时也可被用于当成一种关键机制在计划对比中。计划对比通常用于下列各项发生改变时:

l         删除和新建索引

l         在数据库对象上执行分析语句

l         修改初始参数值

l         rule-based切换至cost-based优化方式

l         升级应用程序或数据库到新版本之后

  如果之前的计划仍然在(例如,从V$SQL_PLAN选择出记录并保存到oracle表中供参考),那么就有可能去鉴别一条SQL语句在执行计划改变后性能方面有什么变化。

注意:

Oracle公司强烈推荐你使用DBMS_STATS包而非ANALYZE收集优化统计。该包可以让你平行地搜集统计项,收集分区对象(partitioned objects)的全集统计,并且通过其它方式更好的调整你的统计收集方式。此处,cost-based优化器将最终使用被DBMS_STATS收集的统计项。浏览Oracle9i Supplied PL/SQL包和类型参考以获得关于此包的更多信息。

不过,你必须使用ANALYZE语句而非DBMS_STATS进行统计收集,不涉及cost-based优化器,就像:

·使用VALIDATELIST CHAINED ROWS子句

·在freelist blocks上收集信息。

V$SQL_PLAN中的常用列:

 

除了一些新加列,本视图几乎包括所有的PLAN_TABLE列,那些同样存在于PLAN_TABLE中的列拥有相同的值:

l         ADDRESS:当前cursor父句柄位置

l         HASH_VALUE:在library cache中父语句的HASH值。

ADDRESSHASH_VALUE这两列可以被用于连接v$sqlarea查询 cursor-specific 信息。

l             CHILD_NUMBER:使用这个执行计划的子cursor

ADDRESS,HASH_VALUE以及CHILD_NUMBER可被用于连接v$sql查询子cursor信息。

l         OPERATION: 在各步骤执行内部操作的名称,例如:TABLE ACCESS

l         OPTIONS: 描述列OPERATION在操作上的变种,例如:FULL

l         OBJECT_NODE: 用于访问对象的数据库链接database link 的名称对于使用并行执行的本地查询该列能够描述操作中输出的次序。

l         OBJECT#: 表或索引对象数量

l         OBJECT_OWNER: 对于包含有表或索引的架构schema 给出其所有者的名称

l         OBJECT_NAME: 表或索引名

l         OPTIMIZER: 执行计划中首列的默认优化模式;例如,CHOOSE。比如业务是个存储数据库,它将告知是否对象是最优化的。

l         ID: 在执行计划中分派到每一步的序号。

l         PARENT_ID: ID 步骤的输出进行操作的下一个执行步骤的ID

l         DEPTH: 业务树深度(或级)

l         POSITION: 对于具有相同PARENT_ID 的操作其相应的处理次序。

l         COST: cost-based方式优化的操作开销的评估,如果语句使用rule-based方式,本列将为空。

l         CARDINALITY: 根据cost-based方式操作所访问的行数的评估。

l         BYTES: 根据cost-based方式操作产生的字节的评估,。

l         OTHER_TAG: 其它列的内容说明。

l         PARTITION_START: 范围存取分区中的开始分区。

l         PARTITION_STOP: 范围存取分区中的停止分区。

l         PARTITION_ID: 计算PARTITION_STARTPARTITION_STOP这对列值的步数

l         OTHER: 其它信息即执行步骤细节,供用户参考。

l         DISTRIBUTION: 为了并行查询,存储用于从生产服务器到消费服务器分配列的方法

l         CPU_COST: 根据cost-based方式CPU操作开销的评估。如果语句使用rule-based方式,本列为空。

l         IO_COST: 根据cost-based方式I/O操作开销的评估。如果语句使用rule-based方式,本列为空。

l         TEMP_SPACE: cost-based方式操作(sort or hash-join)的临时空间占用评估。如果语句使用rule-based方式,本列为空。

l         ACCESS_PREDICATES: 指明以便在存取结构中定位列,例如,在范围索引查询中的开始或者结束位置。

l         FILTER_PREDICATES: 在生成数据之前即指明过滤列。

CONNECT BY操作产生DEPTH列替换LEVEL伪列,有时被用于在SQL脚本中帮助indent PLAN_TABLE数据

V$SQL_PLAN中的连接列

  列ADDRESS,HASH_VALUECHILD_NUMBER被用于连接V$SQLV$SQLAREA来获取cursor-specific信息,例如,BUFFER_GET,或连接V$SQLTEXT获取完整的SQL语句。

Column View                                                                            Joined                      Column(s)

ADDRESS, HASH_VALUE                                        V$SQLAREA        ADDRESS, HASH_VALUE

ADDRESS,HASH_VALUE,CHILD_NUMBER        V$SQL         ADDRESS,HASH_VALUE,CHILD_NUMBER

ADDRESS, HASH_VALUE                                                    V$SQLTEXT          ADDRESS, HASH_VALUE

确认SQL语句的优化计划

  下列语句显示一条指定SQL语句的执行计划。查看一条SQL语句的执行计划是调整优化SQL语句的第一步。这条被查询到执行计划的SQL语句是通过语句的HASH_VALUEADDRESS列识别。分两步执行:

1.SELECT sql_text, address, hash_value FROM v$sql

 WHERE sql_text like '%TAG%';

SQL_TEXT   ADDRESS HASH_VALUE

-------- -------- ----------

          82157784 1224822469

2.SELECT operation, options, object_name, cost FROM v$sql_plan

 WHERE address = '82157784' AND hash_value = 1224822469;

OPERATION            OPTIONS       OBJECT_NAME        COST

-------------------- ------------- ------------------ ----

SELECT STATEMENT                                         5

 SORT

    AGGREGATE

      HASH JOIN                                          5

      TABLE ACCESS   FULL          DEPARTMENTS           2

      TABLE ACCESS   FULL          EMPLOYEES             2

目录
相关文章
|
2月前
|
SQL 存储 关系型数据库
如何巧用索引优化SQL语句性能?
本文从索引角度探讨了如何优化MySQL中的SQL语句性能。首先介绍了如何通过查看执行时间和执行计划定位慢SQL,并详细解析了EXPLAIN命令的各个字段含义。接着讲解了索引优化的关键点,包括聚簇索引、索引覆盖、联合索引及最左前缀原则等。最后,通过具体示例展示了索引如何提升查询速度,并提供了三层B+树的存储容量计算方法。通过这些技巧,可以帮助开发者有效提升数据库查询效率。
180 2
|
26天前
|
SQL 数据库 UED
SQL性能提升秘籍:5步优化法与10个实战案例
在数据库管理和应用开发中,SQL查询的性能优化至关重要。高效的SQL查询不仅可以提高应用的响应速度,还能降低服务器负载,提升用户体验。本文将分享SQL优化的五大步骤和十个实战案例,帮助构建高效、稳定的数据库应用。
41 3
|
28天前
|
SQL IDE 数据库连接
IntelliJ IDEA处理大文件SQL:性能优势解析
在数据库开发和管理工作中,执行大型SQL文件是一个常见的任务。传统的数据库管理工具如Navicat在处理大型SQL文件时可能会遇到性能瓶颈。而IntelliJ IDEA,作为一个强大的集成开发环境,提供了一些高级功能,使其在执行大文件SQL时表现出色。本文将探讨IntelliJ IDEA在处理大文件SQL时的性能优势,并与Navicat进行比较。
30 4
|
27天前
|
SQL 安全 前端开发
Web学习_SQL注入_联合查询注入
联合查询注入是一种强大的SQL注入攻击方式,攻击者可以通过 `UNION`语句合并多个查询的结果,从而获取敏感信息。防御SQL注入需要多层次的措施,包括使用预处理语句和参数化查询、输入验证和过滤、最小权限原则、隐藏错误信息以及使用Web应用防火墙。通过这些措施,可以有效地提高Web应用程序的安全性,防止SQL注入攻击。
49 2
|
1月前
|
SQL 存储 缓存
如何优化SQL查询性能?
【10月更文挑战第28天】如何优化SQL查询性能?
108 10
|
1月前
|
SQL 关系型数据库 MySQL
惊呆:where 1=1 可能严重影响性能,差了10多倍,快去排查你的 sql
老架构师尼恩在读者交流群中分享了关于MySQL中“where 1=1”条件的性能影响及其解决方案。该条件在动态SQL中常用,但可能在无真实条件时导致全表扫描,严重影响性能。尼恩建议通过其他条件或SQL子句命中索引,或使用MyBatis的`<where>`标签来避免性能问题。他还提供了详细的执行计划分析和优化建议,帮助大家在面试中展示深厚的技术功底,赢得面试官的青睐。更多内容可参考《尼恩Java面试宝典PDF》。
|
26天前
|
SQL 缓存 监控
SQL性能提升指南:五大优化策略与十个实战案例
在数据库性能优化的世界里,SQL优化是提升查询效率的关键。一个高效的SQL查询可以显著减少数据库的负载,提高应用响应速度,甚至影响整个系统的稳定性和扩展性。本文将介绍SQL优化的五大步骤,并结合十个实战案例,为你提供一份详尽的性能提升指南。
45 0
|
2月前
|
SQL 监控 数据库
慢SQL对数据库写入性能的影响及优化技巧
在数据库管理系统中,慢SQL(即执行缓慢的SQL语句)不仅会影响查询性能,还可能对数据库的写入性能产生显著的不利影响
|
2月前
|
SQL 存储 数据库
SQL学习一:ACID四个特性,CURD基本操作,常用关键字,常用聚合函数,五个约束,综合题
这篇文章是关于SQL基础知识的全面介绍,包括ACID特性、CURD操作、常用关键字、聚合函数、约束以及索引的创建和使用,并通过综合题目来巩固学习。
45 1
|
2月前
|
SQL 关系型数据库 PostgreSQL
遇到SQL 子查询性能很差?其实可以这样优化
遇到SQL 子查询性能很差?其实可以这样优化
118 2