- 浏览: 557687 次
- 性别:
- 来自: 杭州
-
文章分类
- 全部博客 (340)
- Spring (4)
- Hibernate (2)
- Linux (34)
- Oracle (145)
- Eclipse (1)
- UML (1)
- HTML&&JAVASCRIPT (11)
- JAVA (33)
- 设计模式 (1)
- 版本控制 (1)
- wrap框架 (3)
- IBATIS (5)
- Ruby (1)
- DWR (1)
- MINA (11)
- JBPM (2)
- 缓存技术 (4)
- 网络 (3)
- 应用服务器 (1)
- GWT (5)
- 杂谈 (2)
- ICE (4)
- XML (2)
- ArcGis (2)
- Flex (8)
- junit单元测试 (1)
- SNMP (1)
- 存储 (1)
- office (1)
- MongoDB (0)
- Greenplum (3)
- 管理点滴 (1)
- C++ (6)
- 网络入门 (3)
- Tomcat (7)
- JMX (0)
- webservice (1)
- Oracle的10046事件 (1)
- Library cache内部机制详解 (1)
- expdp通过dblink来导入 (1)
最新评论
-
yuanliangding：
有没有关于mock的更多知识。
基于mock对象和JUnit框架简化Spring Web组件单元测试 -
saup007：
ssh端口不是22，怎么搞呢？
Greenplum 学习笔记 -
springmvc-freemarker：
java开源项目源码实例下载
Apache上全部JAVA开源项目简介 -
bobbell：
哇塞，你真厉害，整理的非常全面。我是一个java barcod ...
Greenplum 学习笔记 -
wsj55133245513324：
这不是bug,你将日志级别从debug提升到INFO 就好了 ...
Spring,smppapi,apache mina, ssl快速实现安全的smpp(5)
使用Oracle SQL trace时需要注意的问题
http://www.it168.com 2009年11月30日 IT168网站原创 作者：IT168 老熊 编辑：晓熊 评论：1条
本文Tag： Oracle Oracle数据库管理 Oracle数据库优化
【IT168 技术文档】我们经常使用Sql Trace和10046 event来诊断Oracle数据库性能问题。而level超过1的10046事件通常称为extended sql trace，通常用于诊断确定的单个SQL、存储过程或会话的性能问题，具有如下的几个优点：
可以得到SQL执行时实际的执行计划。
可以得到SQL执行时所花时间的具体分布，CPU消耗了多长时间，多块读消耗了多长时间等等。
可以得到SQL执行时的各种与性能相关的统计数据，逻辑读、物理读、fetch次数、parse次数等等。
不仅能够用于性能测试，同时能够用于诊断正在执行的SQL或存储过程的性能。
有很多的工具用于格式化生成的trace文件，除了Oracle自带的TKPROF、Metalink Note 224270.1 Trace Analyzer，以及第三方的免费工具如orasrp，《Troubleshooting Oracle Performance》作者开发的TVD$XTAT，甚至还有商业化的软件Hotsos Profiler等。
不过前段时间在用10046事件诊断一个性能问题的时候，却让生成的结果误导了。后来仔细检查发现，在会话开启sql trace的情况下，SQL语句会重新解析，导致开启sql trace之后与开启之前相比，执行计划可能发生了变化，导致sql trace的结果不能真实地反映会话执行SQL的情况，在分析时容易发生偏差。
下面是一个测试：
测试的环境是Oracle 10.2.0.1 for Windows，不过前面提到的案例，是发生在Oracle 9i下的，所以9i和10g都有这个问题，而11g目前还没有测试过，有兴趣的朋友可以在11g上进行测试。
首先创建一个sql文件，内容为：
select /*+ testsql */ sum(value) from t1 where flag=:v_flag;
创建一个列上数据有倾斜的表：
SQL> create table t1 (value number ,flag number,pad varchar2(2000));
表已创建。
SQL> insert into t1 select rownum,mod(rownum,2000),lpad('x',1000,'x') from dba_objects;
已创建49796行。
SQL> commit;
提交完成。
SQL> insert into t1 select rownum,3000,lpad('x',1000,'x') from dba_objects where rownum<=10000;
已创建10000行。
SQL> commit;
提交完成。
SQL> create index t1_idx on t1(flag);
索引已创建。
SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>'T1',cascade=>true,method_opt=>'for all indexed columns');
PL/SQL 过程已成功完成。
SQL> select column_name,num_distinct,num_buckets from user_tab_columns where table_name='T1';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS
------------------------------ ------------ -----------
VALUE
FLAG 2030 75
PAD
select /*+ testsql */ sum(value) from t1 where flag=:v_flag;
创建一个列上数据有倾斜的表：
SQL> create table t1 (value number ,flag number,pad varchar2(2000));
表已创建。
SQL> insert into t1 select rownum,mod(rownum,2000),lpad('x',1000,'x') from dba_objects;
已创建49796行。
SQL> commit;
提交完成。
SQL> insert into t1 select rownum,3000,lpad('x',1000,'x') from dba_objects where rownum<=10000;
已创建10000行。
SQL> commit;
提交完成。
SQL> create index t1_idx on t1(flag);
索引已创建。
SQL> exec dbms_stats.gather_table_stats(ownname=>user,tabname=>'T1',cascade=>true,method_opt=>'for all indexed columns');
PL/SQL 过程已成功完成。
SQL> select column_name,num_distinct,num_buckets from user_tab_columns where table_name='T1';
COLUMN_NAME NUM_DISTINCT NUM_BUCKETS
------------------------------ ------------ -----------
VALUE
FLAG 2030 75
PAD
在创建的测试表中，FLAG列有2001个不同的值，其中，0-1999之间每个值约为25个，而有一个特殊的值3000，有10000个。收集统计信息时，在FLAG列上收集了直方图。
下面运行test.sql：
SQL> var v_flag number;
SQL> exec :v_flag:=3000;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
50005000
统计信息
-------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> var v_flag number;
SQL> exec :v_flag:=3000;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
50005000
统计信息
-------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
412 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
我们来看看SQL的执行计划：
SQL> select sql_id,hash_value,child_number,executions from v$sql where sql_text like '%testsql%' and sql_text not like '%v$sql%';
SQL_ID HASH_VALUE CHILD_NUMBER EXECUTIONS
------------- ---------- ------------ ----------
8hdvb5nwfqm8r 954944791 0 2
SQL> select * from table(dbms_xplan.display_cursor('8hdvb5nwfqm8r',0));
PLAN_TABLE_OUTPUT
---------------------------------------
SQL_ID 8hdvb5nwfqm8r, child number 0
-------------------------------------
select /*+ testsql */ sum(value) from t1 where flag=:v_flag
Plan hash value: 3724264953
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 765 (100)| |
| 1 | SORT AGGREGATE | | 1 | 17 | | |
|* 2 | TABLE ACCESS FULL| T1 | 9863 | 163K| 765 (1)| 00:00:07 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("FLAG"=:V_FLAG)
SQL> select sql_id,hash_value,child_number,executions from v$sql where sql_text like '%testsql%' and sql_text not like '%v$sql%';
SQL_ID HASH_VALUE CHILD_NUMBER EXECUTIONS
------------- ---------- ------------ ----------
8hdvb5nwfqm8r 954944791 0 2
SQL> select * from table(dbms_xplan.display_cursor('8hdvb5nwfqm8r',0));
PLAN_TABLE_OUTPUT
---------------------------------------
SQL_ID 8hdvb5nwfqm8r, child number 0
-------------------------------------
select /*+ testsql */ sum(value) from t1 where flag=:v_flag
Plan hash value: 3724264953
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 765 (100)| |
| 1 | SORT AGGREGATE | | 1 | 17 | | |
|* 2 | TABLE ACCESS FULL| T1 | 9863 | 163K| 765 (1)| 00:00:07 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("FLAG"=:V_FLAG)
可以看到，由于绑定变量窥视，SQL语句走了全表扫描，没有使用索引。
SQL> exec :v_flag:=300;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
607500
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
411 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> exec :v_flag:=300;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
607500
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
411 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
从上面的输出可以看到，在变量=300时，仍然走了全表扫描，仍然没有使用索引。
使用sqlplus创建一个新的到oracle的连接，并执行测试SQL:
开启另一个会话，
SQL> select sid,serial# from v$session where sid=(select sid from v$mystat where rownum=1);
SID SERIAL#
---------- ----------
22 153
SQL> var v_flag number;
SQL> exec :v_flag:=500;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
612500
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
411 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select sid,serial# from v$session where sid=(select sid from v$mystat where rownum=1);
SID SERIAL#
---------- ----------
22 153
SQL> var v_flag number;
SQL> exec :v_flag:=500;
SQL> set autot on stat
SQL> @test
SUM(VALUE)
----------
612500
统计信息
----------------------------------------------------------
0 recursive calls
0 db block gets
8575 consistent gets
0 physical reads
0 redo size
411 bytes sent via SQL*Net to client
384 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
从SQL执行得到的逻辑读来看，仍然是走的全表扫描。这里很明显使用索引更为合适，这就是使用绑定变量引起的副作用。
然而，如果我们打这个这个会话的10046 事件，则结果如何呢?
SQL> exec sys.dbms_system.set_ev(22,153,10046,12,'');
SQL> exec :v_flag:=410;
SQL> @test
SUM(VALUE)
----------
610250
SQL> exec sys.dbms_system.set_ev(22,153,10046,12,'');
SQL> exec :v_flag:=410;
SQL> @test
SUM(VALUE)
----------
610250
下面是trace文件的内容：
PARSING IN CURSOR #1 len=59 dep=0 uid=55 oct=3 lid=55 tim=7703132042 hv=954944791 ad='27cf5884'
select /*+ testsql */ sum(value) from t1 where flag=:v_flag
END OF STMT
PARSE #1:c=0,e=309,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=7703132037
BINDS #1:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=24 off=0
kxsbbbfp=0819ca94 bln=22 avl=03 flg=05
value=410
EXEC #1:c=15625,e=8864,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=7703164320
WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703165526
FETCH #1:c=0,e=237,p=0,cr=27,cu=0,mis=0,r=1,dep=0,og=1,tim=7703166929
WAIT #1: nam='SQL*Net message from client' ela= 187 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703168520
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=7703169851
WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703171170
WAIT #1: nam='SQL*Net message from client' ela= 421 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703172845
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=27 pr=0 pw=0 time=260 us)'
STAT #1 id=2 cnt=25 pid=1 pos=1 obj=51606 op='TABLE ACCESS BY INDEX ROWID T1 (cr=27 pr=0 pw=0 time=439 us)'
STAT #1 id=3 cnt=25 pid=2 pos=1 obj=51607 op='INDEX RANGE SCAN T1_IDX (cr=2 pr=0 pw=0 time=36 us)'
PARSING IN CURSOR #1 len=59 dep=0 uid=55 oct=3 lid=55 tim=7703132042 hv=954944791 ad='27cf5884'
select /*+ testsql */ sum(value) from t1 where flag=:v_flag
END OF STMT
PARSE #1:c=0,e=309,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=7703132037
BINDS #1:
kkscoacd
Bind#0
oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00
oacflg=03 fl2=1000000 frm=00 csi=00 siz=24 off=0
kxsbbbfp=0819ca94 bln=22 avl=03 flg=05
value=410
EXEC #1:c=15625,e=8864,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=1,tim=7703164320
WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703165526
FETCH #1:c=0,e=237,p=0,cr=27,cu=0,mis=0,r=1,dep=0,og=1,tim=7703166929
WAIT #1: nam='SQL*Net message from client' ela= 187 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703168520
FETCH #1:c=0,e=3,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=0,tim=7703169851
WAIT #1: nam='SQL*Net message to client' ela= 5 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703171170
WAIT #1: nam='SQL*Net message from client' ela= 421 driver id=1111838976 #bytes=1 p3=0 obj#=-1 tim=7703172845
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=0 op='SORT AGGREGATE (cr=27 pr=0 pw=0 time=260 us)'
STAT #1 id=2 cnt=25 pid=1 pos=1 obj=51606 op='TABLE ACCESS BY INDEX ROWID T1 (cr=27 pr=0 pw=0 time=439 us)'
STAT #1 id=3 cnt=25 pid=2 pos=1 obj=51607 op='INDEX RANGE SCAN T1_IDX (cr=2 pr=0 pw=0 time=36 us)'
可以看，mis=1，表明发生了硬解析，op=’INDEX RANGE SCAN T1_IDX 表明使用使用了索引，而op=’SORT AGGREGATE (cr=27 表明逻辑读只有27，逻辑读幅下降，的确是使用了索引。
SQL> select sql_id,hash_value,child_number,executions from v$sql where sql_text like '%testsql%' and sql_text not like '%v$sql%';
SQL_ID HASH_VALUE CHILD_NUMBER EXECUTIONS
------------- ---------- ------------ ----------
8hdvb5nwfqm8r 954944791 0 7
8hdvb5nwfqm8r 954944791 1 1
SQL> select * from table(dbms_xplan.display_cursor('8hdvb5nwfqm8r',1));
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID 8hdvb5nwfqm8r, child number 1
-------------------------------------
select /*+ testsql */ sum(value) from t1 where flag=:v_flag
Plan hash value: 1563165360
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 30 (100)| |
| 1 | SORT AGGREGATE | | 1 | 17 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| T1 | 33 | 561 | 30 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T1_IDX | 33 | | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("FLAG"=:V_FLAG)
SQL> select sql_id,hash_value,child_number,executions from v$sql where sql_text like '%testsql%' and sql_text not like '%v$sql%';
SQL_ID HASH_VALUE CHILD_NUMBER EXECUTIONS
------------- ---------- ------------ ----------
8hdvb5nwfqm8r 954944791 0 7
8hdvb5nwfqm8r 954944791 1 1
SQL> select * from table(dbms_xplan.display_cursor('8hdvb5nwfqm8r',1));
PLAN_TABLE_OUTPUT
-------------------------------------
SQL_ID 8hdvb5nwfqm8r, child number 1
-------------------------------------
select /*+ testsql */ sum(value) from t1 where flag=:v_flag
Plan hash value: 1563165360
---------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 30 (100)| |
| 1 | SORT AGGREGATE | | 1 | 17 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| T1 | 33 | 561 | 30 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T1_IDX | 33 | | 1 (0)| 00:00:01 |
---------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
3 - access("FLAG"=:V_FLAG)
从上面的输出可以看到，这条SQL已经产生了另外一个子游标(child cursor)。而查看新的子游标的执行计划，已经使用了索引。
由此，可以看出，开启sql trace之后，会话执行的SQL将不会重用未开启sql trace时生成的执行计划，而发生硬解析。由于硬解析时绑定变量窥视，将会使硬解析产生的子游标，其执行计划可能发生了变化。
在最后，我们来看看引起游标不能共享的原因是什么?
SQL> select * from v$sql_shared_cursor where sql_id='8hdvb5nwfqm8r';
SQL_ID ADDRESS CHILD_AD CHILD_NUMBER U S O O S L S E B P I S T A B D L T R I I R L I O S M U T N F A I T D L D B P C S R P T M B M R O P M F L
------------- -------- -------- ------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
8hdvb5nwfqm8r 27CF5884 27CF57A0 0 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
8hdvb5nwfqm8r 27CF5884 27CCC968 1 N N N N Y N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
SQL> select * from v$sql_shared_cursor where sql_id='8hdvb5nwfqm8r';
SQL_ID ADDRESS CHILD_AD CHILD_NUMBER U S O O S L S E B P I S T A B D L T R I I R L I O S M U T N F A I T D L D B P C S R P T M B M R O P M F L
------------- -------- -------- ------------ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
8hdvb5nwfqm8r 27CF5884 27CF57A0 0 N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
8hdvb5nwfqm8r 27CF5884 27CCC968 1 N N N N Y N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N N
从结果可以看到，STATS_ROW_MISMATCH导致了游标不能共享，Oracle文档这个列的解释是：The existing statistics do not match the existing child cursor。
在最后，使用10g的dbms_monitor包来打开会话的sql trace，测试结果完全相同。
发表评论
-
LINUX下查看CPU使用率的命令
2011-08-09 15:47 1549在系统维护的过程中，随时可能有需要查看 CPU 使用率 ... -
linux 下测试磁盘速度
2011-08-09 11:47 884hdparm -tT /dev/sda1 -
Linux个人学习小结
2010-12-11 16:03 9531：查看指定端口的进程 root用户权限 1、ps - ... -
linux启动脚本
2010-12-11 14:49 996#!/bin/bash # # chkconfig: ... -
Linux防火墙设置
2010-09-21 17:30 16631) 永久性生效，重启后不会复原 即时生效，重启后复原 ... -
采用scp命令在Linux系统之间copy文件
2010-09-03 10:33 943不同的Linux之间copy文件常用有3种方法，第一种就是ft ... -
Oracle_RAC学习笔记
2010-08-21 16:10 2307Oracle RAC Oracle：Database ... -
RedHat Linux网络配置文件
2010-08-21 10:06 1605在 Linux 系统中，TCP/IP 网络是通过若干个文本文件 ... -
Linux下的两种磁盘分区工具的使用
2010-08-21 09:53 7829今天我们来说一下如何 ... -
Linux中的LVM（逻辑卷管理）
2010-08-21 09:49 2069这几天把自己的系统 ... -
NTP时间服务器实现linux时间同步
2010-08-16 20:48 3759在linux下，我们可以通 ... -
配置第2台节点-NODE2
2010-08-10 11:38 919关闭节点1，通过vmware复制一个新节点出来，操作非常简单， ... -
Linux增加磁盘
2008-12-10 15:18 1682fdisk -l 会看到有一块新的设置,如果你先前有一块硬盘( ... -
SSH Secure 乱码
2008-11-05 12:05 1736用vi打开/etc/sysconfig/i18n文件，将 LA ... -
架设linux下最简单的VPN系统
2008-08-05 15:17 1349架设linux下最简单的VPN ... -
Linux常见的紧急情况的处理方法
2008-08-05 15:09 8531、使用急救盘组进行维 ... -
一份非常内行的Linux LVM HOWTO
2008-08-05 15:08 990作 者： 谢启发 1. ... -
Linux 安全设置手册
2008-08-05 15:07 925本文讲述了如何通过基本的安全措施，使你的Linux系统变得可靠 ... -
LVM使用手册
2008-08-05 15:06 18871 简介 1.1 什么是LVM?LVM是 Logica ... -
常用的tar和rpm命令参数列表
2008-08-05 15:05 915一. tar 1.压缩一组 ...
相关推荐
SQL Trace 和 TKPROF 是 Oracle 数据库中非常强大的性能分析工具，它们可以帮助 DBA 和开发人员深入了解数据库的运行状态，及时发现并解决性能问题。通过正确配置 SQL Trace 参数，启用 SQL Trace，以及合理使用 ...
- 若要对特定会话启用 SQL Trace，可以使用 `dbms_system.set_sql_trace_in_session` 函数，这需要知道目标会话的 SID 和 SERIAL#。 ```sql EXECUTE dbms_system.set_sql_trace_in_session(sid, serial#, true); ...
总结，10046事件与SQL_TRACE是Oracle数据库性能调优的重要工具，它可以帮助我们深入了解SQL语句的执行过程，识别性能问题，并提供解决方案。正确使用和分析SQL_TRACE信息，对于提升数据库的运行效率至关重要。
如何使用oracle提供的SQL_TRACE来跟踪sql的执行情况?Sql性能非常差的时候,oracle提供了SQL_TRACE来跟踪sql的执行情况。注：分析sql的方式比较多，还有根据优化器、sql执行计划来分析。SQL_TRACE能够将sql执行的过程...
SQL TRACE是Oracle数据库中一种强大的诊断工具，它用于收集数据库操作的详细信息，帮助DBA（数据库管理员）和开发人员定位性能问题、分析查询执行路径以及优化SQL语句。本篇文章将深入探讨SQL TRACE的原理、使用方法...
在Oracle数据库管理中，追踪（Trace）是一种重要的工具，它可以帮助数据库管理员（DBA）诊断问题、优化性能以及理解SQL语句的执行过程。Oracle提供了多种追踪手段，如会话追踪、SQL追踪等。其中，SQL_TRACE与10046...
Oracle数据库监听工具
Oracle SQL语句跟踪是数据库管理员和开发人员在优化SQL性能、定位问题或调试查询时常用的一种技术。在Oracle数据库系统中，SQL语句跟踪能够帮助我们收集关于SQL执行的详细信息，包括执行计划、资源消耗、等待事件等...
### 实现 Oracle 连接 SQL Server 的方法...需要注意的是，在实际操作过程中可能会遇到各种各样的问题，比如权限问题、网络配置等，因此建议在配置过程中仔细检查每一个步骤，并参考官方文档或寻求专业技术人员的帮助。
书中会讲解如何使用Oracle的性能分析工具，如SQL Trace、 tkprof 和AWR报告，来定位和解决慢查询的问题。此外，它还会探讨数据库的物理结构优化，如表分区、索引优化、内存管理以及I/O调优，这些都是提升数据库性能...
需要注意的是，SQL跟踪应谨慎使用，因为它会产生大量的日志，可能对系统性能造成影响。因此，通常只在需要时开启，并在问题解决后关闭。关闭SQL跟踪的方法与开启类似，只需将`TRUE`改为`FALSE`： ```sql ALTER ...
在实际使用中，SQLTracker通常与其他Oracle管理工具结合使用，如Oracle Enterprise Manager或Toad for Oracle。它可以集成到这些工具中，提供额外的跟踪和诊断功能，增强整体的数据库管理能力。 此外，SQLTracker还...
Oracle SQL和PL/SQL是数据库管理员、开发人员和数据分析师在处理Oracle数据库时最常用的工具。Oracle SQL是一种结构化查询语言，用于检索、更新、插入和删除Oracle数据库中的数据，而PL/SQL（Procedural Language/...
在需要使用加密连接时，这些参数非常重要。 了解并正确配置SQLNET.ORA文件，不仅可以提升系统的安全性，还可以优化网络通信性能，减少由于网络问题引发的故障。在实际操作中，应根据具体的网络环境和安全需求来调整...
- **SQL Trace**：通过启用SQL跟踪功能，可以收集更为详细的SQL执行轨迹信息，这对于诊断复杂的性能问题非常有帮助。 - **ASH/AWR**：活动会话历史(Active Session History)和自动工作负载资料库可以帮助追踪...
总结来说，Oracle SQL优化是一个综合性的任务，需要考虑索引、连接方式、查询结构等多个方面。理解并应用上述知识点，能够帮助你更好地管理和优化你的Oracle数据库，实现更高效的SQL执行。通过持续学习和实践，你...
Oracle SQL调优是数据库管理员和开发人员在优化数据库性能时不可或缺的一个重要技能。在这个"Oracle SQLTuning Workshop"中，虽然资料可能源自2004年，但它依然包含了许多至今仍具价值的基础知识和实践经验。以下是...
Oracle SQL 语句执行效率问题查找与解决方法 一、 Oracle SQL 语句执行效率问题查找方法 Oracle 数据库系统中， SQL 语句的执行效率问题是一个非常重要的问题。在实际应用中，我们经常会碰到一些性能不佳的 SQL ...
1. **权限问题**：在创建数据库链接时需要注意权限问题，确保连接到的目标数据库具有足够的访问权限。 2. **网络配置**：确保网络配置正确无误，Oracle服务器能够通过网络访问到SQL Server服务器。 3. **错误处理**...
其次，分析这些应用程序中的SQL语句，使用SQL_trace和tkprof等工具收集SQL语句的执行统计信息，以便进一步分析。 三、验证优化器统计信息 优化器统计信息的准确性对于生成有效的执行计划至关重要。应定期收集所有...