查询v$lock缓慢和direct path write temp等待

v$lock是常用的enqueue lock队列锁动态性能视图,不管是用户自己部署的监控脚本也好、还是enterprise manager都多少会使用到该V$LOCK视图, 但是在10g中遇到了v$lock查询缓慢的问题, 例如下面的查询会等待较多direct path write temp等待事件:

 

 

select count(*) from v$lock; 

  COUNT(*) 
---------- 
       163 

Elapsed: 00:00:60.90 

Execution Plan 
---------------------------------------------------------- 
Plan hash value: 2384831130 

-------------------------------------------------------------------------------------- 
| Id  | Operation               | Name       | Rows  | Bytes | Cost (%CPU)| Time     | 
-------------------------------------------------------------------------------------- 
|   0 | SELECT STATEMENT        |            |     1 |    50 |     1 (100)| 00:00:01 | 
|   1 |  SORT AGGREGATE         |            |     1 |    50 |            |          | 
|*  2 |   HASH JOIN             |            |     1 |    50 |     1 (100)| 00:00:01 | 
|   3 |    MERGE JOIN CARTESIAN |            |   100 |  3800 |     0   (0)| 00:00:01 | 
|*  4 |     FIXED TABLE FULL    | X$KSUSE    |     1 |    19 |     0   (0)| 00:00:01 | 
|   5 |     BUFFER SORT         |            |   100 |  1900 |     0   (0)| 00:00:01 | 
|   6 |      FIXED TABLE FULL   | X$KSQRS    |   100 |  1900 |     0   (0)| 00:00:01 | 
|   7 |    VIEW                 | GV$_LOCK   |    10 |   120 |     0   (0)| 00:00:01 | 
|   8 |     UNION-ALL           |            |       |       |            |          | 
|*  9 |      FILTER             |            |       |       |            |          | 
|  10 |       VIEW              | GV$_LOCK1  |     2 |    24 |     0   (0)| 00:00:01 | 
|  11 |        UNION-ALL        |            |       |       |            |          | 
|* 12 |         FIXED TABLE FULL| X$KDNSSF   |     1 |    64 |     0   (0)| 00:00:01 | 
|* 13 |         FIXED TABLE FULL| X$KSQEQ    |     1 |    64 |     0   (0)| 00:00:01 | 
|* 14 |      FIXED TABLE FULL   | X$KTADM    |     1 |    64 |     0   (0)| 00:00:01 | 
|* 15 |      FIXED TABLE FULL   | X$KTATRFIL |     1 |    64 |     0   (0)| 00:00:01 | 
|* 16 |      FIXED TABLE FULL   | X$KTATRFSL |     1 |    64 |     0   (0)| 00:00:01 | 
|* 17 |      FIXED TABLE FULL   | X$KTATL    |     1 |    64 |     0   (0)| 00:00:01 | 
|* 18 |      FIXED TABLE FULL   | X$KTSTUSC  |     1 |    64 |     0   (0)| 00:00:01 | 
|* 19 |      FIXED TABLE FULL   | X$KTSTUSS  |     1 |    64 |     0   (0)| 00:00:01 | 
|* 20 |      FIXED TABLE FULL   | X$KTSTUSG  |     1 |    64 |     0   (0)| 00:00:01 | 
|* 21 |      FIXED TABLE FULL   | X$KTCXB    |     1 |    64 |     0   (0)| 00:00:01 | 
--------------------------------------------------------------------------------------

direct path write temp
direct path write temp
direct path write temp
................

 

 

显然仅返回100多条记录的v$LOCK视图的查询不该这么慢,也不该由SORT或HASH造成大量的临时空间使用, 究其根本还是FIXED TABLE即X$的内部表上的统计信息不准确导致的执行计划使用,通过使用RULE HINT可以马上获得较好的性能:

 

 

select /*+ RULE */ count(*) from v$LOCK;

  COUNT(*) 
---------- 
       190 

Elapsed: 00:00:00.18

Execution Plan 
---------------------------------------------------------- 
Plan hash value: 2026431807 

------------------------------------------------- 
| Id  | Operation                  | Name       | 
------------------------------------------------- 
|   0 | SELECT STATEMENT           |            | 
|   1 |  SORT AGGREGATE            |            | 
|   2 |   MERGE JOIN               |            | 
|   3 |    SORT JOIN               |            | 
|   4 |     MERGE JOIN             |            | 
|   5 |      SORT JOIN             |            | 
|   6 |       FIXED TABLE FULL     | X$KSQRS    | 
|*  7 |      SORT JOIN             |            | 
|   8 |       VIEW                 | GV$_LOCK   | 
|   9 |        UNION-ALL           |            | 
|* 10 |         FILTER             |            | 
|  11 |          VIEW              | GV$_LOCK1  | 
|  12 |           UNION-ALL        |            | 
|* 13 |            FIXED TABLE FULL| X$KDNSSF   | 
|* 14 |            FIXED TABLE FULL| X$KSQEQ    | 
|* 15 |         FIXED TABLE FULL   | X$KTADM    | 
|* 16 |         FIXED TABLE FULL   | X$KTATRFIL | 
|* 17 |         FIXED TABLE FULL   | X$KTATRFSL | 
|* 18 |         FIXED TABLE FULL   | X$KTATL    | 
|* 19 |         FIXED TABLE FULL   | X$KTSTUSC  | 
|* 20 |         FIXED TABLE FULL   | X$KTSTUSS  | 
|* 21 |         FIXED TABLE FULL   | X$KTSTUSG  | 
|* 22 |         FIXED TABLE FULL   | X$KTCXB    | 
|* 23 |    SORT JOIN               |            | 
|* 24 |     FIXED TABLE FULL       | X$KSUSE    | 
-------------------------------------------------

 

 

针对上述问题考虑为FIXED TABLE收集统计信息,可以使用DBMS_STATS.GATHER_FIXED_OBJECTS_STATS标准存储过程,特别是对于版本升级上来的数据库,特别需要考虑执行该存储过程更新FIXED TABLE STATISTICS:

 

 

SQL> set timing on;
SQL> exec DBMS_STATS.GATHER_FIXED_OBJECTS_STATS;

PL/SQL procedure successfully completed.

Elapsed: 00:01:24.87

 

 

GATHER_FIXED_OBJECTS_STATS

 

Create fixed table statistics
Directly after catupgrd.sql has been completed
This will speed up processing for recompilation with utlrp.sql
Create fixed table statistics again after a week with regular production workload
This task should be done only a few times per year

10.2.0.1 db console启动失败问题一例

帮网友诊断10.2.0.1数据库安装后配置EM的问题一例,主要是在EM启动过程中遇到了错误,日志如下:

2009-7-7 20:11:39 oracle.sysman.emcp.EMConfig perform
严重: 启动 Database Control 时出错
有关详细资料, 请参阅 oracle\product.2.0\db_1\cfgtoollogs\dbca\orcl\emConfig.log 中的日志文件。
2009-7-7 20:11:39 oracle.sysman.emcp.EMConfig perform
配置: Stack Trace:
oracle.sysman.emcp.exception.EMConfigException: 启动 Database Control 时出错
	at oracle.sysman.emcp.EMDBPostConfig.performConfiguration(EMDBPostConfig.java:569)
	at oracle.sysman.emcp.EMDBPostConfig.invoke(EMDBPostConfig.java:181)
	at oracle.sysman.emcp.EMDBPostConfig.invoke(EMDBPostConfig.java:150)
	at oracle.sysman.emcp.EMConfig.perform(EMConfig.java:155)
	at oracle.sysman.assistants.util.em.EMConfiguration.run(EMConfiguration.java:430)
	at java.lang.Thread.run(Thread.java:534)

出现错误的java stack call是EMDBPostConfig说明em db repository 已经完成配置在尝试启动EM,但此时出现了问题。

实际造成该问题的有多种可能性,这里列举最常见的几种:

1. 杀毒软件或者防火墙造成的,这里建议在安装windows期间彻底关闭杀毒类软件和Windows自带的防火墙
2. EM使用的端口已经被其他软件所占用,建议使用netstat命令诊断,或另择网络端口
3. Windows主机名以”U”字母开头

针对第三种可能性,可以在MOS上找到Note <Problem: Startup: Db Control 10.2.0.1 Fails To Start when the hostname begins with the letter “u”>:

Problem: Startup: Db Control 10.2.0.1 Fails To Start when the hostname begins with the letter "u" 
Applies to:
Enterprise Manager for RDBMS - Version: 10.2.0.1 and later   [Release: 10.2 and later ]
Symptoms
The dbconsole 10.2.0.1 is created with emca.The repository creation completes successfully and the
dbconsole is created and configured without any error.
The last phase of emca is to start the dbconsole.
The standalone agent is started successfully but the dbconsole fails to start.
The file $ORACLE_HOME/cfgtoollogs/emca/sid/emca*.log shows:
===================================================
05/11/2005 23:07:49 oracle.sysman.emcp.util.PlatformInterface serviceCommand
CONFIG: Waiting for service 'OracleDBConsoleAMITAL' to fully start
05/11/2005 23:07:59 oracle.sysman.emcp.EMConfig perform
SEVERE: Error starting Database Control
Refer to the log file at
d:\oracle\product\10.2.0\db_1\cfgtoollogs\emca\amital\emca_2005-11-05_10-55-42-PM.log for more
details.
05/11/2005 23:07:59 oracle.sysman.emcp.EMConfig perform
CONFIG: Stack Trace:
oracle.sysman.emcp.exception.EMConfigException: Error starting Database Control
at oracle.sysman.emcp.EMDBPostConfig.performConfiguration(EMDBPostConfig.java:569)
at oracle.sysman.emcp.EMDBPostConfig.invoke(EMDBPostConfig.java:181)
Cause
This issue can be reproduced on all windows platforms which name begins with the letter u.
This issue has been logged in the following bug:
Bug:4714774 DBCONSOLE DOES NOT WORK HAVING A HOSTNAME STARTING WITH "U"
This bug will be fixed in the patchset 10.2.0.2
Solution
Download and apply the RDBMS patchset 10.2.0.2 once/if available or
To enable the dbconsole to start successfully, follow the steps listed below:
1. Save the file $ORACLE_HOME\host_SID\sysman\config\emd.properties to emd.properties.orig
2. Update the file $ORACLE_HOME\host_SID\sysman\config\emd.properties, replacing \ with / in the
following line:
For example change:
omsRecvDir=d:\oracle\product\10.2.0\db_1\ukp001_db0\sysman\recv
to
omsRecvDir=d:/oracle/product/10.2.0/db_1/ukp001_db0l/sysman/recv
3. Stop and restart the DB Control 
Hdr: 4714774 10.2.0.1 EMCP 10.2.0.1 PRODID-1370 PORTID-912
Abstract: DBCONSOLE DOES NOT WORK HAVING A HOSTNAME STARTING WITH "U"
Problem Description
-------------------
this seems to be releated to bug 3610052.
Having a hostname like u1234, install rdbms10.2.
start dbconsole will take 4-5 min. Even if the service is shown as started,
dbconsole java processes stops and restarts.
Environment Information
-----------------------
Test Case Step-by-Step Instructions
-----------------------------------
1. rename the hostanme to uXYZ....
2. install 10.2 rdbms into its own oraclehome
3. strt listener, create a database using dbca.
4. access the dbconsole page shows: "page cannot be displayed"
Check the dbconsole java process in taksmanager , you will easily see, that
it is coninously restarting. dbconsole service is shown as "started".
Test Case Location
------------------
not needed easy to reproduce
Diagnostic Analysis
-------------------
run the java command from file emd.nohup file, this will show something like:
java...Exception...
Malformed \uxxxx encoding.
and a java stack trace.
I assume that this problem will always happen, having a "\u" in the path for
the dbconsole
Performance
-----------
NLS Information
---------------
Patches
-------
Log Files Location
------------------
Reproducibility
---------------
everytime, only on windows platforms:
w2k w2003, windowsXP
URL
---
not needed
Did you test with the latest version?
-------------------------------------
yes
Available Workarounds
---------------------
Change the hostname from uXYZ to UXYZ,
do
set ORACLE_SID=
emca -config dbcontrol db -reposrecreate 
Related Bugs
------------
3610052
Hdr: 6313490 10.2.0.1.0 CONSOLE 10.2.0.1.0 PRODID-1370 PORTID-215 4714774
Abstract: 10.2.0.1DBCONSOLE IN A DB CREATED FROM IAS INSTALL FAILS TO START
Problem Description
-------------------
The dbconsole 10.2.0.1.0 creating is failing while starting the dbconsole
dbconsole in a db created from iAS install.
as per the logs:-
SEVERE: Error starting Database Control
Refer to the log file at
D:\oracle\product\10.2.0\db_1\cfgtoollogs\emca\mmds\emca_2007-06-19_09-47-70-A
M.log for more details.
Jun 19, 2007 9:58:17 AM oracle.sysman.emcp.EMConfig perform
CONFIG: Stack Trace:
oracle.sysman.emcp.exception.EMConfigException: Error starting Database
Control at
oracle.sysman.emcp.EMDBPostConfig.performConfiguration(EMDBPostConfig.java:569
) at oracle.sysman.emcp.EMDBPostConfig.invoke
Environment Information
-----------------------
dbconsole in a db created from iAS install.
db console 10.2.0.1.0 on Microsoft Windows Server 2003
The 10g application server version  is 10.1.2.0.2. to include January 2007
database and application server CPUs.
Applied the  database CPU patch and after that reconfigured the Dbconsole .
Now it doesn't get configured .Db console generating core dump
Test Case Step-by-Step Instructions
-----------------------------------
Test Case Location
------------------
Diagnostic Analysis
-------------------
Stopped the application server service and then started the dbcosnole .But
still getting the error
D:\oracle\product\10.2.0\db_1\BIN>emctl status dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
Oracle Enterprise Manager 10g is not running.
------------------------------------------------------------------
Logs are generated in directory 
Asked him to move the file from Oracle_Home>/_/emctl.pid file
to another location . Now the dbconsole is started:-
>emctl start dbconsole
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
Starting Oracle Enterprise Manager 10g Database Control ...The
OracleDBConsoleMM
DS service is starting...................The OracleDBConsoleMMDS service was
started successfully.
D:\oracle\product\10.2.0\db_1\BIN>emctl upload
Oracle Enterprise Manager 10g Database Control Release 10.2.0.1.0
EMD upload error: uploadXMLFiles skipped :: OMS version not checked yet..
Asked him to Edit the file
ORACLE_HOME>\oc4j\j2ee\home\applications\dms\WEB-INF\web.xml
Still the dbconsole is not getting started .

可能是因为Windows上主机名以”U”字母开头后导致相关路径发生了转义。

可以通过在cmd中输入hostname来确认Windows上的主机名。

给出了2种解决方案:

1.升级到10.2.0.2以上版本,目前推荐的是10.2.0.5 Patch set; 版本10.2.0.1到10.2.0.3上的bug太多了..

2.修改$ORACLE_HOME\host_SID\sysman\config\emd.properties中的内容,将omsRecvDir变更改成使用斜杠而非反斜杠的路径形式,并重启EM.

Oracle内部错误ORA-600:[1112]

以下为ORA-600[1112]内部错误的相关诊断信息:

ERROR:
ORA-600 [1112] [a] [b] [c] [d] [e]
VERSIONS:
versions 7.3 to 9.2
DESCRIPTION:
ORA-600 [1112] is getting raised while trying to add a
row cache enqueue to a transaction state object during
lookup of the default tablespace number during table
creation.
FUNCTIONALITY:
STATE OBJECT MANAGEMENT
IMPACT:
PROCESS FAILURE
NON CORRUPTIVE - No underlying data corruption.
Bug 2489130 - OERI:1112 can occur while dumping PROCESSSTATE informatio (Doc ID 2489130.8)
Bug 4126973: ORA-600[504] AND ORA-600[1112] OCCURED WHEN GETTING "ERRORSTACK"
Base Bug 2489130
Bug 3954753: ORA-600 [1112] AND SESSION CRASH
The cause for the ORA-00600 [1112] appears due to Bug 2489130
This error can occur on dumping of process state which is what occurred here.
The primary issue is the WAITED TOO LONG FOR A ROW CACHE ENQUEUE LOCK!
This then triggers a system state and process state to be dumped due to nature of the problem.
The ORA-00600 [1112] gets dumped out when process state is done.
Stack for trace very similar to Bug 2489130 and this is only known bug on 9.2 like this with a fix.
A fix for bug 2489130 is included in the 9.2.0.7 patchset.
Recommend applying 9.2.0.8 patchset to have this and other bug fixes.
This would only prevent the ORA-00600 [1112] from occurring on state dumps.
The primary row cache issue still to be investigated by performance team.

Trace obtained enqueue information by set event 10704

Oracle事件10704可以帮助我们了解队列Enqueue的使用情况,使用方法如下:

[oracle@rh2 bdump]$ oerr ora 10704
10704, 00000, "Print out information about what enqueues are being obtained"
// *Cause:  When enabled, prints out arguments to calls to ksqcmi and
//          ksqlrl and the return values.
// *Action: Level indicates details:
//   Level: 1-4: print out basic info for ksqlrl, ksqcmi
//          5-9: also print out stuff in callbacks:  ksqlac, ksqlop
//          10+: also print out time for each line
SQL> oradebug setmypid;
Statement processed.
SQL> oradebug event 10704 trace name context forever,level 10;
Statement processed.
SQL> lock  table tm in share mode;
Table(s) Locked.
SQL> oradebug tracefile_name;
/s01/admin/G10R2/udump/g10r2_ora_28400.trc
ksqgtl *** CU-9fec6e30-00000000 mode=6 flags=0x10 timeout=300 ***
ksqgtl: no transaction
ksqgtl: use existing ksusetxn DID
ksqgtl:
ksqlkdid: 0001-0017-00000008
*** 2011-05-07 21:17:16.139
*** ksudidTrace: ksqgtl
ksusesdi:   0000-0000-00000000
ksusetxn:   0001-0017-00000008
ksqgtl: RETURNS 0
*** 2011-05-07 21:17:16.160
ksqrcl: CU,9fec6e30,0
ksqrcl: returns 0
*** 2011-05-07 21:17:23.884
ksqgtl *** CU-9fec69f8-00000000 mode=6 flags=0x10 timeout=300 ***
ksqgtl: no transaction
ksqgtl: use existing ksusetxn DID
ksqgtl:
ksqlkdid: 0001-0017-00000008
*** 2011-05-07 21:17:23.884
*** ksudidTrace: ksqgtl
ksusesdi:   0000-0000-00000000
ksusetxn:   0001-0017-00000008
ksqgtl: RETURNS 0
*** 2011-05-07 21:17:23.898
ksqrcl: CU,9fec69f8,0
ksqrcl: returns 0
*** 2011-05-07 21:17:23.899
ksqgtl *** TM-0000d06b-00000000 mode=4 flags=0x401 timeout=21474836 ***
ksqgtl: xcb=0xa69d0a00, ktcdix=2147483647, topxcb=0xa69d0a00
ktcipt(topxcb)=0x0
*** 2011-05-07 21:17:23.899
ksucti: init txn DID from session DID 0001-0017-00000008
ksqgtl:
ksqlkdid: 0001-0017-00000008
*** 2011-05-07 21:17:23.899
*** ksudidTrace: ksqgtl
ktcmydid(): 0001-0017-00000008
ksusesdi:   0000-0000-00000000
ksusetxn:   0001-0017-00000008
ksqgtl: RETURNS 0

该10704事件可以配合10046事件一起诊断异常的队列锁问题,记以录之!

Oracle常用诊断事件清单

事件 说明 例子
Event 10013 – Monitor Transaction Recovery 在Startup时跟踪事务恢复 ALTER SESSION SET EVENTS ‘10013 trace name context forever, level 1’;
Event 10015 – Dump Undo Segment Headers- 在事务恢复后做Dump回退段头信息 ALTER SESSION SET EVENTS ‘10015 trace name context forever, level 1’;
Event 10032 – Dump Sort Statistics Dump排序的统计信息 ALTER SESSION SET EVENTS ‘10032 trace name context forever, level 10’;
Event 10033 – Dump Sort Intermediate Run Statistics 排序过程中,内存排序区和临时表空间的交互情况 ALTER SESSION SET EVENTS ‘10033 trace name context forever, level 10’;
Event 10045 – Trace Free List Management Operations FREELIST的管理操作 ALTER SESSION SET EVENTS ‘10045 trace name context forever, level 1’;
Event 10046 – Enable SQL Statement Trace 跟踪SQL,有执行计划,邦定变量和等待的统计信息,level 12最详细。 ALTER SESSION SET EVENTS ‘10046 trace name context forever, level 12’; 

LEVEL定义如下:

1:SQL 语句,执行计划和执行状态

4:1的内容加上绑定变量信息

8:1的信息加上等待事件信息

12:1+4+8

Event 10053 – Dump Optimizer Decisions 在分析SQL语句时,Dump出优化器所做的选择,级别level 1最详细 ALTER SESSION SET EVENTS ‘10053 trace name context forever, level 1’; 

LEVEL定义如下:

1:状态和估算信息

2:只显示估算信息

Event 10060 – Dump Predicates DUMP SQL语句中的断语信息。需要在需要DUMP的用户下创建以下表 

CREATE TABLE kkoipt_table
(c1 INTEGER,

c2 VARCHAR2(80));

断语信息会写入该表

ALTER SESSION SET EVENTS ‘10060 trace name context forever, level 1’;
Event 10065 – Restrict Library Cache Dump Output for State Object Dumps 限制对象状态DUMP的时候LIBRARY CACHE信息的详细程度
1 Address of library object only 

2 As level 1 plus library object lock details

3 As level 2 plus library object handle and library object

缺省是LEVEL 3

ALTER SESSION SET EVENTS ‘10065 trace name context forever, level level’;
Event 10079 – Dump SQL*Net Statistics- Dump SQL*NeT的统计信息 ALTER SESSION SET EVENTS ‘10079 trace name context forever, level 2’;
Event 10081 – Trace High Water Mark Changes HWM的改变 ALTER SESSION SET EVENTS ‘10081 trace name context forever, level 1’;
Event 10104 – Dump Hash Join Statistics HASH JOIN的统计信息 ALTER SESSION SET EVENTS ‘10104 trace name context forever, level 10’;
Event 10128 – Dump Partition Pruning Information 分区表调整信息 ALTER SESSION SET EVENTS ‘10128 trace name context forever, level level’; 

Level取值:

1   Dump pruning descriptor for each partitioned object

0x0002 Dump partition iterators

0x0004 Dump optimizer decisions about partition-wise joins

0x0008 Dump ROWID range scan pruning information

在9.0.1或者后面的版本,在level 2后还需要建立如下的表:

CREATE TABLE kkpap_pruning

(

partition_count    NUMBER,

iterator           VARCHAR2(32),

partition_level    VARCHAR2(32),

order_pt         VARCHAR2(12),

call_time        VARCHAR2(12),

part#             NUMBER,

subp#              NUMBER,

abs#               NUMBER

);

事件 说明 例子
Event 10200 – Dump Consistent Reads DUMP一致读的信息 ALTER SESSION SET EVENTS ‘10200 trace name context forever, level 1’;
Event 10201 – Dump Consistent Read Undo Application DUMP一致性读涉及UNDO信息的内容 ALTER SESSION SET EVENTS ‘10201 trace name context forever, level 1’;
Event 10220 – Dump Changes to Undo Header Dump出Undo头信息的改变 ALTER SESSION SET EVENTS ‘10220 trace name context forever, level 1’;
Event 10221 – Dump Undo Changes Dump Undo的改变 ALTER SESSION SET EVENTS ‘10221 trace name context forever, level 7’;
Event 10224 – Dump Index Block Splits / Deletes 索引块的分裂和D删除信息 ALTER SESSION SET EVENTS ‘10224 trace name context forever, level 1’;
Event 10225 – Dump Changes to Dictionary Managed Extents DUMP字段管理的扩展变化 ALTER SESSION SET EVENTS ‘10225 trace name context forever, level 1’;
Event 10231 全表扫描时跳过坏块,在有坏块的情况下做数据拯救时很有用 ALTER SYSTEM SET EVENTS ‘10231 trace name context forever,level 10’;
Event 10241 – Dump Remote SQL Execution 远程SQL语句的执行信息 ALTER SESSION SET EVENTS ‘10241 trace name context forever, level 1’;
Event 10246 – Trace PMON Process 跟踪PMON进程 只能修改参数,不能用ALTER SYSTEM 

event = “10246 trace name context forever, level 1”

Event 10248 – Trace Dispatcher Processes 跟踪DISPATCHER的工作情况 event = “10248 trace name context forever, level 10”
Event 10249 – Trace Shared Server (MTS) Processes- 跟踪共享服务器的工作情况 event = “10249 trace name context forever, level 10”
Event 10270 – Debug Shared Cursors 跟踪共享CURSORS的情况 event = “10270 trace name context forever, level 10”
Event 10299 – Debug Prefetching 跟踪表数据块和索引数据块的PREFETCHING event = “10299 trace name context forever, level 1”
Event 10357 – Debug Direct Path ALTER SESSION SET EVENTS ‘10357 trace name context forever, level 1’;
Event 10390 – Dump Parallel Execution Slave Statistics 跟踪并行操作中的SLAVE的状态 ALTER SESSION SET EVENTS ‘10390 trace name context forever, level 1;
Event 10391-Dump Parallel Execution Granule Allocation 跟踪并行操作的粒度 ALTER SESSION SET EVENTS ‘10391 trace name context forever, level 2’;
Event 10393 – Dump Parallel Execution Statistics 跟踪并行操作的状态(每个SLAVE单独列出状态) ALTER SESSION SET EVENTS ‘10393 trace name context forever, level 1’;
Event 10500 – Trace SMON Process 跟踪SMON进程 event = “10500 trace name context forever, level 1”
Event 10608 – Trace Bitmap Index Creation 跟踪BITMAP索引创建的详细过程 ALTER SESSION SET EVENTS ‘10608 trace name context forever, level 10’;
Event 10704 – Trace Enqueues 跟踪锁的使用情况 ALTER SESSION SET EVENTS ‘10704 trace name context forever, level 1’;
Event 10706 – Trace Global Enqueue Manipulation 跟踪全局锁的使用情况 ALTER SESSION SET EVENTS ‘10706 trace name context forever, level 1’;
Event 10708 – Trace RAC Buffer Cache 跟踪RAC环境下的BUFFER CACHE ALTER SESSION SET EVENTS ‘10708 trace name context forever, level 10’;
事件 说明 例子
Event 10710 – Trace Bitmap Index Access 跟踪位图索引的访问情况 ALTER SESSION SET EVENTS ‘10710 trace name context forever, level 1’;
Event 10711 – Trace Bitmap Index Merge Operation 跟踪位图索引合并操作 ALTER SESSION SET EVENTS ‘10711 trace name context forever, level 1’;
Event 10712 – Trace Bitmap Index OR Operation 跟踪位图索引或操作情况 ALTER SESSION SET EVENTS ‘10712 trace name context forever, level 1’;
Event 10713 – Trace Bitmap Index AND Operation 跟踪位图索引与操作 ALTER SESSION SET EVENTS ‘10713 trace name context forever, level 1’;
Event 10714 – Trace Bitmap Index MINUS Operation 跟踪位图索引minus操作 ALTER SESSION SET EVENTS ‘10714 trace name context forever, level 1’;
Event 10715 – Trace Bitmap Index Conversion to ROWIDs Operation 跟踪位图索引转换ROWID操作 ALTER SESSION SET EVENTS ‘10715 trace name context forever, level 1’;
Event 10716 – Trace Bitmap Index Compress/Decompress 跟踪位图索引压缩和解压缩情况 ALTER SESSION SET EVENTS ‘10716 trace name context forever, level 1’;
Event 10717 – Trace Bitmap Index Compaction ALTER SESSION SET EVENTS ‘10717 trace name context forever, level 1’;
Event 10719 – Trace Bitmap Index DML 跟踪位图索引列的DML操作(引起位图索引改变的DML操作) ALTER SESSION SET EVENTS ‘10719 trace name context forever, level 1’;
Event 10730 – Trace Fine Grained Access Predicates 跟踪细粒度审计的断语 ALTER SESSION SET EVENTS ‘10730 trace name context forever, level 1’;
Event 10731 – Trace CURSOR Statements 跟踪CURSOR的语句情况 ALTER SESSION SET EVENTS ‘10731 trace name context forever, level level’; 

LEVEL定义

1     Print parent query and subquery

2     Print subquery only

Event 10928 – Trace PL/SQL Execution 跟踪PL/SQL执行情况 ALTER SESSION SET EVENTS ‘10928 trace name context forever, level 1’;
Event 10938 – Dump PL/SQL Execution Statistics 跟踪PL/SQL执行状态。使用前需要执行rdbms/admin下的tracetab.sql ALTER SESSION SET EVENTS ‘10938 trace name context forever, level 1’;
flush_cache 刷新BUFFER CACHE ALTER SESSION SET EVENTS ‘immediate trace name flush_cache’;
DROP_SEGMENTS 手工删除临时段。当这些临时段无法自动清除的时候可以手工清除 alter session set events ‘immediate trace name DROP_SEGMENTS level ts#+1’; 

ts#是指要删除临时段的表空间的ts#

 

沪ICP备14014813号

沪公网安备 31010802001379号