1.背景
前段时间,利用v$sql分析过一个项目的数据流程。发现对v$sql的一些字段理解的一知半解。
实质是对Oracel的sql执行机制理解不深。
把相关的总结一下。
2.v$sql的定义
Column | Datatype | Description |
---|---|---|
|
| First thousand characters of the SQL text for the current cursor |
|
| All characters of the SQL text for the current cursor |
|
| SQL identifier of the parent cursor in the library cache |
|
| Amount of shared memory used by a cursor. If multiple child cursors exist, then the sum of all shared memory used by all child cursors. |
|
| Fixed amount of memory used for the lifetime of an open cursor. If multiple child cursors exist, then the fixed sum of memory used for the lifetime of all the child cursors. |
|
| Fixed amount of memory required during execution of a cursor. If multiple child cursors exist, then the fixed sum of all memory required during execution of all the child cursors. |
|
| Sum of the number of sorts that were done for all the child cursors |
|
| Number of child cursors that are present in the cache under this parent |
|
| Number of child cursors that are present in the cache and have their context heap loaded |
|
| Number of child cursors that are currently open under this current parent |
|
| Number of users that have any of the child cursors open |
|
| Number of fetches associated with the SQL statement |
|
| Total number of executions, totalled over all the child cursors |
|
| Total number of executions performed by parallel execution servers ( |
|
| Number of times this cursor was fully executed since the cursor was brought into the library cache. The value of this statistic is not incremented when the cursor is partially executed, either because it failed during the execution or because only the first few rows produced by this cursor are fetched before the cursor is closed or re-executed. By definition, the value of the |
|
| Total number of users executing the statement over all child cursors |
|
| Number of times the object was loaded or reloaded |
|
| Timestamp of the parent creation time |
|
| Total number of invalidations over all the child cursors |
|
| Sum of all parse calls to all the child cursors under this parent |
|
| Sum of the number of disk reads over all child cursors |
|
| Sum of the number of direct writes over all child cursors |
|
| Sum of buffer gets over all child cursors |
|
| Application wait time (in microseconds) |
|
| Concurrency wait time (in microseconds) |
|
| Cluster wait time (in microseconds) |
|
| User I/O Wait Time (in microseconds) |
|
| PL/SQL execution time (in microseconds) |
|
| Java execution time (in microseconds) |
|
| Total number of rows processed on behalf of this SQL statement |
|
| Oracle command type definition |
|
| Mode under which the SQL statement was executed |
|
| Cost of this query given by the optimizer |
|
| Optimizer environment |
|
| Hash value for the optimizer environment |
|
| User ID of the user that has parsed the very first cursor under this parent |
|
| Schema ID that was used to parse this child cursor |
|
| Schema name that was used to parse this child cursor |
|
| Number of child cursors that have been marked to be kept using the |
|
| Address of the handle to the parent for this cursor |
|
| Hash value of the parent statement in the library cache |
|
| Old SQL hash value |
|
| Numeric representation of the current SQL plan for this cursor. Comparing one |
|
| Numeric representation of the complete SQL plan for this cursor. Comparing one |
|
| Contains the name of the module that was executing when the SQL statement was first parsed as set by calling |
|
| Hash value of the module that is named in the |
|
| Contains the name of the action that was executing when the SQL statement was first parsed as set by calling |
|
| Hash value of the action that is named in the |
|
| Number of times the transaction failed to serialize, producing |
|
| If an outline was applied during construction of the cursor, then this column displays the category of that outline. Otherwise the column is left blank. |
|
| CPU time (in microseconds) used by this cursor for parsing, executing, and fetching |
|
| Elapsed time (in microseconds) used by this cursor for parsing, executing, and fetching. If the cursor uses parallel execution, then |
|
| Outline session identifier |
|
| Address (identifier) of the child cursor that was the last to be active in the group (that is, the child cursor on behalf of which statistics in |
|
| Indicates whether the cursor is remote mapped ( |
|
| Status of the cursor:
|
|
| Hash value of the literals which are replaced with system-generated bind variables and are to be matched, when |
|
| Time at which the query plan was loaded into the library cache |
|
| Indicates whether the cursor has become obsolete ( |
|
| Indicates whether the cursor is bind sensitive ( |
|
| Indicates whether the cursor is bind aware ( |
|
| Child latch number that is protecting the cursor. This column is obsolete and maintained for backward compatibility. |
|
| SQL profile used for this statement, if any |
|
| SQL patch used for this statement, if any |
|
| SQL plan baseline used for this statement, if any |
|
| Program identifier |
|
| Program line number |
|
| Signature used when the |
|
| Signature used when the |
|
| Time at which the query plan was last active |
|
| Bind data |
|
| Typecheck memory |
|
| Number of I/O bytes which can be filtered by the Exadata storage system See Also: Oracle Exadata Storage Server Software documentation for more information |
|
| Number of I/O bytes exchanged between Oracle Database and the storage system |
|
| Number of physical read I/O requests issued by the monitored SQL |
|
| Number of bytes read from disks by the monitored SQL |
|
| Number of physical write I/O requests issued by the monitored SQL |
|
| Number of bytes written to disks by the monitored SQL |
|
| Number of physical read I/O requests from Database Smart Flash Cache issued by the monitored SQL |
|
| Total number of times the child cursor has been locked |
|
| Total number of times the child cursor has been pinned |
|
| Number of uncompressed bytes (that is, size after decompression) that are offloaded to the Exadata cells See Also: Oracle Exadata Storage Server Software documentation for more information |
|
| Number of bytes that are returned by Exadata cell through the regular I/O path See Also: Oracle Exadata Storage Server Software documentation for more information |
|
| The ID of the container to which the data pertains. Possible values include:
|
|
| This columns shows whether the next execution matching this child cursor will trigger a reoptimization. The values are:
|
|
| This column shows whether all of the adaptive parts of a plan have been resolved to the final plan. Once the plan is resolved, the plan hash value and the plan displayed by
See Also: Oracle Database PL/SQL Packages and Types Reference for more information about the |
2.1 sql包含的要素
sql在Oracle看来,不是简单的sql语句,还应该包含
- sql语句
- 内存(成本)
- 执行次数(效果,被缓存的sql应该要被多次执行,否则被消耗的内存没有发挥价值)
- cost:物理读、缓存读;
- 环境:优化器配置、schema、客户端等。
3.疑问和解释
3.1 cursor、parent cursor、child cursor?
cursor:是library cache中的内存区域。sql要执行,先分配内存。
parent cursor:保存sql文本。每一个相同的sql文本对应1个parent cursor。即如果sql文本一致,会划入到1个parent cursor中。
child cursor:保存除sql文本外的其他内容。涉及sql运行原理,相同的sql文本,在schema、优化器参数、绑定变量大改时,其实本质是不一样的。child cursor就保存了这些信息。
This is by Oracle database design that you have two kinds of cursors: Parent and Child. For each SQL statement that you execute, Oracle engine will generate two cursors: parent and child cursor. Two cursors are generated because for the same SQL statement, there could be other differences like there can be different bind values or two different schema or different literals values, etc. The parent Cursor will hold the SQL statement and the child cursor will hold the information related to the differences. This essentially makes child cursor as deciding factor as to SQL statement will go for hard or soft parse.
参考:http://expertoracle.com/2017/11/17/db-tuning-basics-3-parent-and-child-cursors/
3.2 v$sql与v$sqlarea的区别
v$sql:V$SQL lists statistics on shared SQL area without the GROUP BY clause and contains one row for each child of the original SQL text entered.
是针对每个child的统计信息,顾
v$sqlarea:V$SQLAREA displays statistics on shared SQL areas and contains one row per SQL string. It provides statistics on SQL statements that are in memory, parsed, and ready for execution.
是针对每个sql文本,即parent的统计信息。
4.应用场景
4.1 应用操作对应的SQL分析
一些系统是黑盒的,没有源码,想知道数据流程,可以通过监控v$sql里缓存的sql分析。
4.2 优化类:sql统计信息的使用
1)top耗资源的进程对应的sql内容
select t.SQL_ID,
t.SERIAL#,
t.USERNAME,
t.SQL_ID,
a.SQL_TEXT,
a.SQL_FULLTEXT
from v$session t, v$process s, v$sqlarea a
where t.PADDR = s.ADDR
and s.SPID in (’18348‘)
and a.SQL_ID = t.SQL_ID;
2)查看最耗时的sql、最消耗磁盘读取的sql等。