ORA-07445[dbgrmqmqpk_query_pick_key()+0f88]

alert发现如下错误ORA-07445[dbgrmqmqpk_query_pick_key()+0f88]

Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xB38F0000000049]
[PC:0x100213C08, dbgrmqmqpk_query_pick_key()+0f88]
Errors in file /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_m000_7602504.trc  (incident=579300):
ORA-07445: exception encountered: core dump [dbgrmqmqpk_query_pick_key()+0f88] [SIGSEGV] [ADDR:0xB38F0000000049]
[PC:0x100213C08] [Address not mapped to object] []
Incident details in: /oracle/diag/rdbms/sgerp5/sgerp5/incident/incdir_579300/sgerp5_m000_7602504_i579300.trc

trace文件部分信息

Dump file /oracle/diag/rdbms/sgerp5/sgerp5/incident/incdir_579300/sgerp5_m000_7602504_i579300.trc
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /oracle/product/11.1.0/db_1
System name:	AIX
Node name:	sgerp5
Release:	1
Version:	6
Machine:	00C8F0564C00
Instance name: sgerp5
Redo thread mounted by this instance: 1
Oracle process number: 138
Unix process pid: 7602504, image: oracle@sgerp5 (m000)
--确定是m000进程出现异常,而该进程是awr收集统计信息进程MMON的子进程
*** 2012-05-11 03:52:35.200
*** SESSION ID:(752.5029) 2012-05-11 03:52:35.200
*** CLIENT ID:() 2012-05-11 03:52:35.200
*** SERVICE NAME:(SYS$BACKGROUND) 2012-05-11 03:52:35.200
*** MODULE NAME:(MMON_SLAVE) 2012-05-11 03:52:35.200
*** ACTION NAME:(Auto-Purge Slave Action) 2012-05-11 03:52:35.200
Dump continued from file: /oracle/diag/rdbms/sgerp5/sgerp5/trace/sgerp5_m000_7602504.trc
ORA-07445: exception encountered: core dump [dbgrmqmqpk_query_pick_key()+0f88] [SIGSEGV] [ADDR:0xB38F0000000049]
[PC:0x100213C08] [Address not mapped to object] []
----- Incident Context Dump -----
Address: 0x1104bdb68
Incident ID: 579300
Problem Key: ORA 7445 [dbgrmqmqpk_query_pick_key()+0f88]
Error: ORA-7445 [dbgrmqmqpk_query_pick_key()+0f88] [SIGSEGV] [ADDR:0xB38F0000000049] [PC:0x100213C08]
[Address not mapped to object] [] [] []
[00]: dbgexExplicitEndInc [diag_dde]
[01]: dbgeEndDDEInvocationImpl [diag_dde]
[02]: dbgeEndDDEInvocation [diag_dde]
[03]: ssexhd []
[04]: 47dc []<-- Signaling
[05]: dbgrmqmfs_fetch_setup [ams_comp]
[06]: dbgrmqmf_fetch_real [ams_comp]
[07]: dbgrmqmf_fetch [ams_comp]
[08]: dbgrip_fetch_record [ami_comp]
[09]: dbgrip_relation_iterator [ami_comp]
[10]: dbgripricm_rltniter_wcbf_mt [ami_comp]
[11]: dbgripdrm_dmldrv_mt [ami_comp]
[12]: dbghmm_delete_info_records []
[13]: dbghmo_purge_hm_schema []
[14]: dbgrupipscb_hm_pgsvc_cbf [diag_adr]
[15]: dbgruppm_purge_main [diag_adr]
[16]: dbkrapg_auto_purge [rdbms_adr]
[17]: kewraps_auto_purge_slave []
[18]: kebm_slave_main []
[19]: ksvrdp [ksv_trace]
[20]: opirip []
[21]: opidrv []
[22]: sou2o []
[23]: opimai_real []
[24]: main []
[25]: __start []
MD [00]: 'SID'='752.5029' (0x3)
MD [01]: 'ProcId'='138.46' (0x3)
MD [02]: 'PQ'='(0, 1336679546)' (0x7)
MD [03]: 'Client ProcId'='oracle@sgerp5.7602504_1' (0x0)

MOS关于该问题记录
问题原因

This is due to Bug 9390347 fixed in 12.1 & 11.2.0.2, where a core dump can occur
in module dbgrmqmqpk_query_pick_key() whilst purging HM contents from ADR.

解决方案

- Either install our 11.2.0.2 patchset
- Or download and apply Patch 9390347 if available for your version/platform.
- On Windows, you can also install Bundle Patch 11.1.0.7.31 or above.
There is no workaround to this error, however the error is not serious and does not cause any harm to your database.

常驻连接池(Database Resident Connection Pool)

一.介绍常驻连接池(Database Resident Connection Pool，Oracle DRCP)
数据库驻留连接池是Oracle Database 11g的一个新特性，专门为了解决在需要支持大量连接的环境对可扩性的迫切需求而设计的。数据库驻留连接池把数据库服务器进程和对话汇合起来(这样的组合称之为池服务器)，通过从单主机或不同主机发出的多个应用软件进程的连接进行共享。由一个连接代理(Connection Broker)进程控制着数据库后台进程中的池服务器。连接代理会持续的连接客户并对客户进行验证。当需要进行某种数据库活动时，客户将请求连接代理提供池服务器，使用完毕后再将它们释放以供其他客户重新使用。当池服务器处在使用当中时，相当于一台专用服务器。对于来自常驻通道中的客户端连接请求，连接代理会为其选择一个合适的池服务器，并把客户端请求交给该池服务器处理，不再干涉。此后客户通过和该池服务器的直接对话来完成所有的数据库活动。当客户完成请求任务释放池服务器后，连接代理将重新接管该池服务器。

二.什么时间使用DRCP
1 使用较小内存的、大量的客户端连接
2 客户端应用是相似的，可以共享或重用会话
3 客户端占用数据库连接的周期相当短
4 会话不需要跨客户请求
5 客户端有众多的主机与进程

三.Dedicated Servers,Shared Servers与DRCP的内存需求和区别对比
一般情况下，由于每个会话需要消耗400k的内存，每个进程需要消耗4m的内存，现在我们以DRCP的pool size是100，shared server的shared server进程是100为例，假如有5000个客户端连接到这些环境，则这些主机的内存分配如下：

A Dedicated Server
Memory used = 5000 X (400 KB + 4 MB) = 22 GB
B Shared Server
Memory used = 5000 X 400 KB + 100 X 4 MB = 2.5 GB
Out of the 2.5 GB, 2 GB is allocated from the SGA
.
C Database Resident Connection Pooling
Memory used = 100 X (400 KB + 4 MB) + (5000 X 35KB)= 615 MB


四.使用DRCP时，当实例有活动pooled server，有以下限制：
1 不能shutdown database;
2 不能停掉DRCP;
3 不能用database link连接到不同实例的DRCP;
4 不能使用Advanced Security Option (ASO)，比如encryption等

五.客户端如何连接到DRCP
如果是专用服务器连接，则SERVER=DEDICATED，如果是DRCP连接，则SEVER=POOLED。如果要指定客户端请求到DRCP，则客户端的tnsnames.ora中的连接字符串必须指定连接类型是POOLED，配置方式如下所示：

ORA11G_P =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))
    )
    (CONNECT_DATA =
     (SERVER=POOLED)  --注意
      (SERVICE_NAME = ora11g)
    )
  )

说明：
1)如果在tnsnames.ora中指定了SERVER=POOLED，但并没有在实例中启动DRCP，则当客户请求连接时，DB会报ORA-12520错误。
2)11g的客户端才可以使用DRCP，如果10g的客户端在tnsnames.ora中指定了SERVER=POOLED，则连接时报ORA-56606。

六.DRCP配置/查询
1.DRCP启动/关闭

--查看当前DRCP状态
SQL> select CONNECTION_POOL,status from dba_cpool_info;
CONNECTION_POOL                STATUS
------------------------------ --------------------------------
SYS_DEFAULT_CONNECTION_POOL    INACTIVE
--启动DRCP
SQL> execute dbms_connection_pool.start_pool;
PL/SQL procedure successfully completed.
SQL> select CONNECTION_POOL,status from dba_cpool_info;
CONNECTION_POOL                STATUS
------------------------------ --------------------------------
SYS_DEFAULT_CONNECTION_POOL    ACTIVE
--关闭DRCP
SQL> exec dbms_connection_pool.stop_pool
PL/SQL procedure successfully completed.
SQL> select CONNECTION_POOL,status from dba_cpool_info;
CONNECTION_POOL                STATUS
------------------------------ --------------------------------
SYS_DEFAULT_CONNECTION_POOL    INACTIVE

2.修改DRCP参数

--dbms_connection_pool.configure_pool
exec dbms_connection_pool.configure_pool(
	POOL_NAME=>'SYS_DEFAULT_CONNECTION_POOL',
	minsize=>10,
	maxsize=>100,
	INCRSIZE=>10,
	SESSION_CACHED_CURSORS=>50,
	inactivity_timeout=>3000,
	max_think_time=>100,
	MAX_USE_SESSION=>10000,
	MAX_LIFETIME_SESSION=>36000
   );
--dbms_connection_pool.alter_param
exec dbms_connection_pool.alter_param(
	POOL_NAME=>'SYS_DEFAULT_CONNECTION_POOL',
	PARAM_NAME=>'MINSIZE',
	PARAM_VALUE=>'2');

3.DRCP视图

DBA_CPOOL_INFO
displays configuration information about all Database Resident Connection Pools in the database.
V$CPOOL_STATS
displays information about the Database Resident Connection Pool statistics for an instance
V$CPOOL_CC_STATS
displays information about the connection class level statistics for
the Database Resident Connection Pool per instance.
V$CPOOL_CONN_INFO
displays connection information about each connection to the connection broker.
V$CPOOL_CC_INFO
displays information about the pool-to-connection class mapping for
the Database Resident Connection Pool per instance.

七.DRCP相关进程

oracle   11715     1  0 21:38 ?        00:00:00 ora_n000_ora11g
oracle   11719     1  0 21:38 ?        00:00:00 ora_l000_ora11g
oracle   11723     1  0 21:38 ?        00:00:00 ora_l001_ora11g
oracle   11727     1  0 21:38 ?        00:00:00 ora_l002_ora11g
oracle   11731     1  0 21:38 ?        00:00:02 ora_l003_ora11g
oracle   12490     1  0 21:57 ?        00:00:00 ora_l004_ora11g
oracle   12494     1  0 21:57 ?        00:00:00 ora_l005_ora11g
oracle   12498     1  0 21:57 ?        00:00:00 ora_l006_ora11g
oracle   12502     1  0 21:57 ?        00:00:00 ora_l007_ora11g
oracle   12506     1  0 21:57 ?        00:00:00 ora_l008_ora11g
oracle   12510     1  0 21:57 ?        00:00:00 ora_l009_ora11g
oracle   12514     1  0 21:57 ?        00:00:01 ora_l010_ora11g
oracle   12518     1  0 21:57 ?        00:00:00 ora_l011_ora11g
oracle   12522     1  0 21:57 ?        00:00:00 ora_l012_ora11g
oracle   12526     1  0 21:57 ?        00:00:00 ora_l013_ora11g
oracle   12530     1  0 21:57 ?        00:00:00 ora_l014_ora11g
oracle   12534     1  0 21:57 ?        00:00:00 ora_l015_ora11g
oracle   12538     1  0 21:57 ?        00:00:00 ora_l016_ora11g
oracle   12542     1  0 21:57 ?        00:00:00 ora_l017_ora11g
oracle   12546     1  0 21:57 ?        00:00:00 ora_l018_ora11g
oracle   12550     1  0 21:57 ?        00:00:00 ora_l019_ora11g
ora_n000_ora11g
Connection Broker Process
ora_l000_ora11g
Pooled Server Process(Handles client requests in Database Resident Connection Pooling)

提高短连接性能方法测试

创建测试脚本
通过在三个会话中同时执行test_login.sh脚本,模拟当数据库多个短连接情况性能

[oracle@xifenfei tmp]$ more test_login.sh
#!/bin/bash
echo "start login database `date`*********" >>/tmp/test_1.log
e=2000
for((i=1;i<=$e;i=i+1))
do
/tmp/login_oracle.sh
done
echo "end login database `date`*********" >>/tmp/test_1.log
[oracle@xifenfei tmp]$ more login_oracle.sh
#!/bin/bash
sqlplus chf/xifenfei@ORA11G_P<<XFF>/dev/null
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
exit
XFF
--ORA11G_P根据不同的测试情景指定不同名称

情况1:一个监听情况下

start login database Tue May  1 18:03:32 CST 2012*********
start login database Tue May  1 18:03:35 CST 2012*********
start login database Tue May  1 18:03:37 CST 2012*********
end login database Tue May  1 18:08:20 CST 2012*********
end login database Tue May  1 18:08:25 CST 2012*********
end login database Tue May  1 18:08:26 CST 2012*********
--计算2000个会话登录/查询/推出时间
4:48
4:40
4:49

情况2:三个监听,客户端配置tns负载均衡

--监听配置
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))
    )
  )
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
     (GLOBAL_DBNAME = ora11g)
     (ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/db_1)
     (SID_NAME = ora11g)
    )
  )
ADR_BASE_LISTENER = /u01/oracle
LISTENER1 =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1522))
    )
  )
SID_LIST_LISTENER1 =
  (SID_LIST =
    (SID_DESC =
     (GLOBAL_DBNAME = ora11g)
     (ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/db_1)
     (SID_NAME = ora11g)
    )
  )
ADR_BASE_LISTENER1 = /u01/oracle
LISTENER2 =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1523))
    )
  )
SID_LIST_LISTENER2 =
  (SID_LIST =
    (SID_DESC =
     (GLOBAL_DBNAME = ora11g)
     (ORACLE_HOME = /u01/oracle/oracle/product/11.2.0/db_1)
     (SID_NAME = ora11g)
    )
  )
ADR_BASE_LISTENER2 = /u01/oracle
--tns配置
ORA11G_M =
  (DESCRIPTION =
      (LOAD_BALANCE=ON)
      (FAILOVER=ON)
      (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))
       (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1522))
       (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1523))
       (LOAD_BALANCE = yes)
    )
    (CONNECT_DATA =
     (SERVER=DEDICATED)
      (SERVICE_NAME = ora11g)
    )
  )
--测试结果
start login database Tue May  1 17:51:45 CST 2012*********
start login database Tue May  1 17:51:49 CST 2012*********
start login database Tue May  1 17:51:51 CST 2012*********
end login database Tue May  1 17:55:58 CST 2012*********
end login database Tue May  1 17:56:06 CST 2012*********
end login database Tue May  1 17:56:09 CST 2012*********
--计算2000个会话登录/查询/推出时间
4:13
4:17
4:18

情况2:使用常驻连接池DRCP(11g新特性)

--启动默认DRCP
SQL> exec dbms_connection_pool.start_pool();
PL/SQL procedure successfully completed.
--tns配置
ORA11G_P =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.10)(PORT = 1521))
    )
    (CONNECT_DATA =
     (SERVER=POOLED)  --注意
      (SERVICE_NAME = ora11g)
    )
  )
--执行结果
start login database Tue May  1 18:19:58 CST 2012*********
start login database Tue May  1 18:20:01 CST 2012*********
start login database Tue May  1 18:20:03 CST 2012*********
end login database Tue May  1 18:23:16 CST 2012*********
end login database Tue May  1 18:23:19 CST 2012*********
end login database Tue May  1 18:23:21 CST 2012*********
--计算2000个会话登录/查询/推出时间
3:16
3:18
3:19

总结
如果在数据库短连接过程中发现监听是瓶颈的时候,可以考虑使用多个监听+tns 负载均衡,从一定程度上缓解监听瓶颈.如果是11g数据库可以考虑使用其心功能DRCP,从而很大程度上提高短连接过程中数据库的效率.因为DRCP还属于11g的新功能稳定性不知道如何?使用该功能前,请一定要做好相关测试工作.如有可能还是建议从应用层面尽可能的使用长连接,提高数据库会话效率.

shared pool latch 等待事件

shared pool latch相关描述

The shared pool latch is used to protect critical operations when allocating
and freeing memory in the shared pool.
If an application makes use of literal (unshared) SQL then this can severely
limit scalability and throughput. The cost of parsing a new SQL statement is
expensive both in terms of CPU requirements and the number of times the library
cache and shared pool latches may need to be acquired and released. Before Oracle9,
there was just one such latch for the entire database to protect the allocation of
memory in the library cache. In Oracle9, multiple children were introduced to relieve
contention on this resource.

减少shared pool latch方法

Avoid hard parses when possible, parse once, execute many.
Eliminate  literal SQL so that same sql is shared by many sessions.
Size the shared_pool adequately to avoid reloads
Use of MTS (shared server option) also greatly influences the shared pool latch.

查询未绑定sql

--9i
SELECT substr(sql_text,1,40) "SQL",
         count(*) ,
         sum(executions) "TotExecs"
    FROM v$sqlarea
   WHERE executions < 5
   GROUP BY substr(sql_text,1,40)
  HAVING count(*) > 30
   ORDER BY 2
  ;
--10g及其以后版本
SET pages 10000
SET linesize 250
column FORCE_MATCHING_SIGNATURE format 99999999999999999999999
WITH c AS
     (SELECT  FORCE_MATCHING_SIGNATURE,
              COUNT(*) cnt
     FROM     v$sqlarea
     WHERE    FORCE_MATCHING_SIGNATURE!=0
     GROUP BY FORCE_MATCHING_SIGNATURE
     HAVING   COUNT(*) > 20
     )
     ,
     sq AS
     (SELECT  sql_text                ,
              FORCE_MATCHING_SIGNATURE,
              row_number() over (partition BY FORCE_MATCHING_SIGNATURE ORDER BY sql_id DESC) p
     FROM     v$sqlarea s
     WHERE    FORCE_MATCHING_SIGNATURE IN
              (SELECT FORCE_MATCHING_SIGNATURE
              FROM    c
              )
     )
SELECT   sq.sql_text                ,
         sq.FORCE_MATCHING_SIGNATURE,
         c.cnt "unshared count"
FROM     c,
         sq
WHERE    sq.FORCE_MATCHING_SIGNATURE=c.FORCE_MATCHING_SIGNATURE
AND      sq.p                       =1
ORDER BY c.cnt DESC

查询数据库整体解析情况

select to_char(100 * sess / calls, '999999999990.00') || '%' cursor_cache_hits,
to_char(100 * (calls - sess - hard) / calls, '999990.00') || '%' soft_parses,
to_char(100 * hard / calls, '999990.00') || '%' hard_parses
from ( select value calls from v$sysstat where name = 'parse count (total)' ),
( select value hard from v$sysstat where name = 'parse count (hard)' ),
( select value sess from v$sysstat where name = 'session cursor cache hits' );

参考:Note 62143.1 Troubleshooting: Tuning the Shared Pool and Tuning Library Cache Latch

cache buffer lru chain latch等待事件

cache buffer lru chain latch官方解释

The cache buffer lru chain latch is acquired in order to introduce a new block into the buffer cache
and when writing a buffer back to disk, specifically when trying to scan the LRU (least recently used) chain
containing all the dirty blocks in the buffer cache.

cache buffer lru chain latch可能原因

想查看或者修改LRU+LRUW的进程，始终要持有cache buffers lru chain latch。
若在此过程中发生争用，则要等待latch:cache buffers lru chain 事件。
总结出来如下两种情况会导致cache buffers lru chain latch:
1.进程欲读取还没有装载到内存上的块时，通过查询LRU 列分配到所需空闲缓冲区，在此过程中需要cache buffers lru chain latch。
2.DBWR 为了将脏缓冲区记录到文件上，查询LRUW 列，将相应缓冲区移动到LRU 列的过程中也要获得cache buffers lru chain latch。
2.1)DBWR在如下情况下将脏缓冲区记录到文件里。
2.2)Oracle 进程为了获得空闲缓冲区，向DBWR 请求记录脏缓冲区时；
2.3)Oracle进程为执行Parallel Query 或Tablespace Backup，Truncate/Drop 等工作，请求记录相关对象的脏缓冲区时；
2.4)周期性或管理上的原因检查点（checkpointing）被执行时。
2.5)Oracle 为了保障将通过FAST_START_MTTR_TARGET（或LOG_CHECKPOINT_TIMEOUT）指定的时间的恢复，周期性执行检查点。
2.6)管理员执行检查点命令或根据日志文件切换，也会发生检查点。

cache buffers lru chain latch争用的最重要的原因是过多请求空闲缓冲区。低效的SQL语句是过多请求空闲缓冲区的最典型情况，若多个会话同时执行低效的SQL语句，则在查询空闲缓冲区过程中和记录脏缓冲区的过程中，为了获取buffers lru chain latch发生争用。多个会话同时扫描不同表或索引时，发生cache buffers lru chain latch争用的概率高。多个会话将各不相同的块载入到内存过程中，确保空闲缓冲区的请求会增多，因此发生对工作组争用的概率将提高。特别是因为数据修改频繁，以至于脏缓冲区数量多，正因此DBWR 因为检查点而查询LRUW 列的次数频繁，所以cache buffers lru chain latch争用将更加严重。cache buffers lru chain latch争用的另一个重要特点就是伴随着物理I/O。若是低效的索引扫描引起的问题，则同时发生db file sequential read 等待和lru chain latch争用；若是不必要的全表扫描引起的问题，则同时发生db file scattered read 等待和lru chain latch争用。事实上，cache buffers chains latch争用和cache buffers lru chain latch争用同时发生的情况较多，因为复杂的应用程序将复合地应用上述模式。data buffer过小或检查点周期过短时，也会增加cache buffers lru chain latch争用；但是现在的数据库的data buffer都不会太小,而检查点周期一般使用缺省值，所以通常定位cache buffers lru chain latch的原因还是在低效的SQL语句上

CACHE BUFFERS CHAINS等待事件

关于CACHE BUFFERS CHAINS描述

CACHE BUFFERS CHAINS latch is acquired when searching for data blocks cached in the buffer cache.
Since the Buffer cache is implemented as a sum of chains of blocks, each of those chains is protected
by a child of this latch when needs to be scanned. Contention in this latch can be caused by very heavy
access to a single block. This can require the application to be reviewed.

产生CACHE BUFFERS CHAINS原因

The main cause of the cache buffers chains latch contention is usually a hot block issue.
This happens when multiple sessions repeatedly access one or more blocks that are protected
by the same child cache buffers chains latch.

CACHE BUFFERS CHAINS 处理方法
1) Examine the application to see if the execution of certain DML and SELECT statements can be reorganized to eliminate contention on the object.

处理方法如下:
--通过报告确定latch: cache buffers chains 等待
Top 5 Timed Events                                      Avg    %Total
~~~~~~~~~~~~~~~~~~                                      wait   Call
Event                          Waits        Time (s)    (ms)   Time   Wait Class
------------------------------ ------------ ----------- ------ ------ ----------
latch: cache buffers chains          74,642      35,421    475    6.1 Concurrenc
CPU time                                         11,422           2.0
log file sync                        34,890       1,748     50    0.3 Commit
latch free                            2,279         774    340    0.1 Other
db file parallel write               18,818         768     41    0.1 System I/O
-------------------------------------------------------------
--找出逻辑读高sql
SQL ordered by Gets         DB/Inst:  Snaps: 1-2
-> Resources reported for PL/SQL code includes the resources used by all SQL
statements called by the code.
-> Total Buffer Gets:   265,126,882
-> Captured SQL account for   99.8% of Total
                            Gets                CPU      Elapsed
Buffer Gets    Executions   per Exec     %Total Time (s) Time (s)  SQL Id
-------------- ------------ ------------ ------ -------- --------- -------------
   256,763,367       19,052     13,477.0   96.8 ######## ######### a9nchgksux6x2
Module: JDBC Thin Client
SELECT * FROM SALES ....
     1,974,516      987,056          2.0    0.7    80.31    110.94 ct6xwvwg3w0bv
SELECT COUNT(*) FROM ORDERS ....
--逻辑读大对象
Segments by Logical Reads
-> Total Logical Reads:     265,126,882
-> Captured Segments account for   98.5% of Total
           Tablespace                      Subobject  Obj.       Logical
Owner         Name    Object Name            Name     Type         Reads  %Total
---------- ---------- -------------------- ---------- ----- ------------ -------
DMSUSER    USERS      SALES                           TABLE  212,206,208   80.04
DMSUSER    USERS      SALES_PK                        INDEX   44,369,264   16.74
DMSUSER    USERS      SYS_C0012345                    INDEX    1,982,592     .75
DMSUSER    USERS      ORDERS_PK                       INDEX      842,304     .32
DMSUSER    USERS      INVOICES                        TABLE      147,488     .06
          -------------------------------------------------------------
处理思路：
1.Look for SQL that accesses the blocks in question and determine if the repeated reads are necessary.
  This may be within a single session or across multiple sessions.
2.Check for suboptimal SQL (this is the most common cause of the events)
 look at the execution plan for the SQL being run and try to reduce the
 gets per executions which will minimize the number of blocks being accessed
 and therefore reduce the chances of multiple sessions contending for the same block.

Note:1342917.1 Troubleshooting ‘latch: cache buffers chains’ Wait Contention

2) Decrease the buffer cache -although this may only help in a small amount of cases.

3) DBWR throughput may have a factor in this as well.If using multiple DBWR’s then increase the number of DBWR’s.

4) Increase the PCTFREE for the table storage parameters via ALTER TABLE or rebuild. This will result in less rows per block.

找出热点对象
First determine which latch id(ADDR) are interesting by examining the number of
sleeps for this latch. The higher the sleep count, the more interesting the
latch id(ADDR) is:
SQL> select CHILD#  "cCHILD"
     ,      ADDR    "sADDR"
     ,      GETS    "sGETS"
     ,      MISSES  "sMISSES"
     ,      SLEEPS  "sSLEEPS"
     from v$latch_children
     where name = 'cache buffers chains'
     order by 5, 1, 2, 3;
Run the above query a few times to to establish the id(ADDR) that has the most
consistent amount of sleeps. Once the id(ADDR) with the highest sleep count is found
then this latch address can be used to get more details about the blocks
currently in the buffer cache protected by this latch.
The query below should be run just after determining the ADDR with
the highest sleep count.
SQL> column segment_name format a35
     select /*+ RULE */
       e.owner ||'.'|| e.segment_name  segment_name,
       e.extent_id  extent#,
       x.dbablk - e.block_id + 1  block#,
       x.tch,
       l.child#
     from
       sys.v$latch_children  l,
       sys.x$bh  x,
       sys.dba_extents  e
     where
       x.hladdr  = '&ADDR' and
       e.file_id = x.file# and
       x.hladdr = l.addr and
       x.dbablk between e.block_id and e.block_id + e.blocks -1
     order by x.tch desc ;
Example of the output :
SEGMENT_NAME                     EXTENT#      BLOCK#       TCH    CHILD#
-------------------------------- ------------ ------------ ------ ----------
SCOTT.EMP_PK                       5            474          17     7,668
SCOTT.EMP                          1            449           2     7,668
Depending on the TCH column (The number of times the block is hit by a SQL
statement), you can identify a hot block. The higher the value of the TCH column,
the more frequent the block is accessed by SQL statements.

5) Consider implementing reverse key indexes (if range scans aren’t commonly used against the segment)

xdb组件中关于ftp/http监听

发现监听进程监听8080和2100端口

--监听端口
[oracle@xifenfei ~]$ netstat -nap|grep tnslsnr
(Not all processes could be identified, non-owned process info
 will not be shown, you would have to be root to see it all.)
tcp        0      0 0.0.0.0:8080                0.0.0.0:*                   LISTEN      29866/tnslsnr
tcp        0      0 0.0.0.0:1521                0.0.0.0:*                   LISTEN      29866/tnslsnr
tcp        0      0 0.0.0.0:2100                0.0.0.0:*                   LISTEN      29866/tnslsnr
--进程名称
[oracle@xifenfei ~]$ ps -ef|grep 29866
oracle   29866     1  0 00:20 pts/0    00:00:00 /u01/oracle/9.2.0/db_1/bin/tnslsnr LISTENER -inherit

查看监听状态

[oracle@xifenfei ~]$ lsnrctl status
LSNRCTL for Linux: Version 9.2.0.4.0 - Production on 08-MAY-2012 00:26:50
Copyright (c) 1991, 2002, Oracle Corporation.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xifenfei)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 9.2.0.4.0 - Production
Start Date                08-MAY-2012 00:20:47
Uptime                    0 days 0 hr. 6 min. 3 sec
Trace Level               off
Security                  OFF
SNMP                      OFF
Listener Parameter File   /u01/oracle/9.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/oracle/9.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=8080))(Presentation=HTTP)(Session=RAW))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=2100))(Presentation=FTP)(Session=RAW))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "xffXDB" has 1 instance(s).
  Instance "xff", status READY, has 1 handler(s) for this service...
Service "xifenfei" has 2 instance(s).
  Instance "xff", status UNKNOWN, has 1 handler(s) for this service...
  Instance "xff", status READY, has 1 handler(s) for this service...
The command completed successfully
--从这里可以看出oracle的listener确实监听了8080和2100端口

查看listener.ora文件

[oracle@xifenfei ~]$ more /u01/oracle/9.2.0/db_1/network/admin/listener.ora
# LISTENER.ORA Network Configuration File: /u01/oracle/9.2.0/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = TCP)(HOST = xifenfei)(PORT = 1521))
      )
      (ADDRESS_LIST =
        (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
      )
    )
  )
SID_LIST_LISTENER =
  (SID_LIST =
    (SID_DESC =
      (SID_NAME = PLSExtProc)
      (ORACLE_HOME = /u01/oracle/9.2.0/db_1)
      (PROGRAM = extproc)
    )
    (SID_DESC =
      (GLOBAL_DBNAME = xifenfei)
      (ORACLE_HOME = /u01/oracle/9.2.0/db_1)
      (SID_NAME = xff)
    )
  )
--从中确认未监听8080和2100端口,看来这两个端口是在动态注册监听的时候加入进去的.
--我们知道oracle的xdb组件可能会启用http和ftp功能,这两个功能可能会开启响应端口,我们分析xdb组件.

查看xdb组件是否工作正常

SQL> select
  2  comp_name, status, version from
  3  DBA_REGISTRY where
  4  comp_name='Oracle XML Database';
COMP_NAME                      STATUS                 VERSION
------------------------------ ---------------------- ----------
Oracle XML Database            VALID                  9.2.0.4.0
SQL> select  count(*) from  dba_objects where owner='XDB' and status='INVALID';
  COUNT(*)
----------
         0
SQL>   show parameter dispatchers;
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ------------------------------
dispatchers                          string                 (PROTOCOL=TCP) (SERVICE=xffXDB)
max_dispatchers                      integer                5
mts_dispatchers                      string                 (PROTOCOL=TCP) (SERVICE=xffXDB)
mts_max_dispatchers                  integer                5
--查询证明xdb组件应该工作正常

查看xdb中ftp和http启动相关端口

SQL> select dbms_xdb.GETFTPPORT() from dual;
select dbms_xdb.GETFTPPORT() from dual
       *
ERROR at line 1:
ORA-00904: "DBMS_XDB"."GETFTPPORT": invalid identifier
SQL> select dbms_xdb.GETHTTPPORT() from dual;
select dbms_xdb.GETHTTPPORT() from dual
       *
ERROR at line 1:
ORA-00904: "DBMS_XDB"."GETHTTPPORT": invalid identifier
--9i中为提供上述查询端口的相关程序.
SQL> set long 10000
SQL> set pagesize 0
SQL> SELECT dbms_xdb.cfg_get FROM dual;
--从中找到类此这样记录,确实ftp启用2100端口,http启用8080端口
     <ftpconfig>
        <ftp-port>2100</ftp-port>
        <ftp-listener>local_listener</ftp-listener>
        <ftp-protocol>tcp</ftp-protocol>
        <session-timeout>6000</session-timeout>
     </ftpconfig>
     <httpconfig>
        <http-port>8080</http-port>
        <http-listener>local_listener</http-listener>
        <http-protocol>tcp</http-protocol>
        <session-timeout>6000</session-timeout>
        <server-name>XDB HTTP Server</server-name>
     </httpconfig>
--到这里我们可以确定是由于xdb组件中的ftp和http功能自动注册导致监听了2100和8080端口

修改xdb中监听ftp和http端口

SQL> call dbms_xdb.cfg_update(updateXML(dbms_xdb.cfg_get(),'
   2 /xdbconfig/sysconfig/protocolconfig/httpconfig/http-port/text()',8888));
Call completed.
SQL> call dbms_xdb.cfg_update(updateXML(dbms_xdb.cfg_get(),
   2 '/xdbconfig/sysconfig/protocolconfig/ftpconfig/ftp-port/text()',2222));
Call completed.
SQL> commit;
Commit complete.
SQL>  exec dbms_xdb.cfg_refresh;
PL/SQL procedure successfully completed.
SQL> exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
[oracle@xifenfei ~]$ lsnrctl status
LSNRCTL for Linux: Version 9.2.0.4.0 - Production on 08-MAY-2012 00:57:13
Copyright (c) 1991, 2002, Oracle Corporation.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xifenfei)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 9.2.0.4.0 - Production
Start Date                08-MAY-2012 00:20:47
Uptime                    0 days 0 hr. 36 min. 26 sec
Trace Level               off
Security                  OFF
SNMP                      OFF
Listener Parameter File   /u01/oracle/9.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/oracle/9.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=8888))(Presentation=HTTP)(Session=RAW))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=2222))(Presentation=FTP)(Session=RAW))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "xffXDB" has 1 instance(s).
  Instance "xff", status READY, has 1 handler(s) for this service...
Service "xifenfei" has 2 instance(s).
  Instance "xff", status UNKNOWN, has 1 handler(s) for this service...
  Instance "xff", status READY, has 1 handler(s) for this service...
The command completed successfully

xdb中ftp和http监听

SQL> alter system reset dispatchers  scope=spfile sid='*';
System altered.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area  353441008 bytes
Fixed Size                   451824 bytes
Variable Size             184549376 bytes
Database Buffers          167772160 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> show parameter dispatchers;
NAME                                 TYPE                   VALUE
------------------------------------ ---------------------- ---------
dispatchers                          string
max_dispatchers                      integer                5
mts_dispatchers                      string
mts_max_dispatchers                  integer                5
--SELECT dbms_xdb.cfg_get FROM dual;中信息
      <ftpconfig>
        <ftp-port>2222</ftp-port>
        <ftp-listener>local_listener</ftp-listener>
        <ftp-protocol>tcp</ftp-protocol>
        <session-timeout>6000</session-timeout>
      </ftpconfig>
      <httpconfig>
        <http-port>8888</http-port>
        <http-listener>local_listener</http-listener>
        <http-protocol>tcp</http-protocol>
        <session-timeout>6000</session-timeout>
        <server-name>XDB HTTP Server</server-name>
      </httpconfig>
[oracle@xifenfei dbs]$ lsnrctl status
LSNRCTL for Linux: Version 9.2.0.4.0 - Production on 08-MAY-2012 01:10:07
Copyright (c) 1991, 2002, Oracle Corporation.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xifenfei)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 9.2.0.4.0 - Production
Start Date                08-MAY-2012 00:20:47
Uptime                    0 days 0 hr. 49 min. 20 sec
Trace Level               off
Security                  OFF
SNMP                      OFF
Listener Parameter File   /u01/oracle/9.2.0/db_1/network/admin/listener.ora
Listener Log File         /u01/oracle/9.2.0/db_1/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=xifenfei)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
Service "xifenfei" has 2 instance(s).
  Instance "xff", status UNKNOWN, has 1 handler(s) for this service...
  Instance "xff", status READY, has 1 handler(s) for this service...
The command completed successfully
--证明已经关闭了xdb 组件的ftp/http监听

xdb组件中的ftp/http监听在9i数据库中,只要你安装了xdb组件,会自动启用这功能.
在10g及其11g中默认不启用.所以为了你的数据库安全,如果不使用这些功能,建议手工关闭

db2 内存监控

active databa 列表

[db2inst1@xifenfei ~]$ db2 list active databases
                           Active Databases
Database name                              = XIFENFEI
Applications connected currently           = 1
Database path                              = /home/db2inst1/db2inst1/NODE0000/SQL00003/

查看db2各个组件内存分配

[db2inst1@xifenfei ~]$ db2mtrk -i -p -v -d
Tracking Memory on: 2012/05/07 at 22:13:44
Memory for instance
   Other Memory is of size 10682368 bytes
   FCMBP Heap is of size 786432 bytes
   Database Monitor Heap is of size 327680 bytes
   Total: 11796480 bytes
Memory for database: XIFENFEI
   Backup/Restore/Util Heap is of size 65536 bytes
   Package Cache is of size 196608 bytes
   Other Memory is of size 131072 bytes
   Catalog Cache Heap is of size 65536 bytes
   Buffer Pool Heap (1) is of size 72482816 bytes
   Buffer Pool Heap (System 32k buffer pool) is of size 851968 bytes
   Buffer Pool Heap (System 16k buffer pool) is of size 589824 bytes
   Buffer Pool Heap (System 8k buffer pool) is of size 458752 bytes
   Buffer Pool Heap (System 4k buffer pool) is of size 393216 bytes
   Shared Sort Heap is of size 65536 bytes
   Lock Manager Heap is of size 10551296 bytes
   Database Heap is of size 13172736 bytes
   Application Heap (13) is of size 65536 bytes
   Application Heap (12) is of size 65536 bytes
   Application Heap (11) is of size 65536 bytes
   Application Heap (10) is of size 65536 bytes
   Application Heap (9) is of size 65536 bytes
   Applications Shared Heap is of size 196608 bytes
   Total: 99549184 bytes
Memory for agent 33
   Other Memory is of size 196608 bytes
   Total: 196608 bytes
Memory for agent 32
   Other Memory is of size 196608 bytes
   Total: 196608 bytes
Memory for agent 31
   Other Memory is of size 196608 bytes
   Total: 196608 bytes
Memory for agent 30
   Other Memory is of size 196608 bytes
   Total: 196608 bytes
Memory for agent 19
   Other Memory is of size 393216 bytes
   Total: 393216 bytes

查看内存统计(9.5及其以后版本)

[db2inst1@xifenfei ~]$ db2pd -dbptnmem -db xff
Database XFF not activated on database partition 0.
Option -dbptnmem is an instance scope option.  The database option has been ignored.
Database Partition 0 -- Active -- Up 0 days 00:05:30 -- Date 2012-05-07-22.16.43.375064
Database Partition Memory Controller Statistics
Controller Automatic: Y
Memory Limit:         775904 KB
Current usage:        306560 KB
HWM usage:            306816 KB
Cached memory:        78144 KB
Individual Memory Consumers:
Name             Mem Used (KB) HWM Used (KB) Cached (KB)
========================================================
APPL-XIFENFEI            40000         40000       39488
DBMS-db2inst1            31936         31936        4992
FMP_RESOURCES            22528         22528           0
PRIVATE                   6272          6272           0
LCL-p8353                  128           128           0
LCL-p8353                  128           128           0
DB-XIFENFEI             205568        205568       33664

查看内存段粗略信息
可以通过-db database 指定具体数据库

[db2inst1@xifenfei ~]$ db2pd -memset
Database Partition 0 -- Active -- Up 0 days 00:18:39 -- Date 2012-05-07-22.29.52.410789
Memory Sets:
Name         Address    Id          Size(Kb)   Key         DBP    Type   Unrsv(Kb)  Used(Kb)   HWM(Kb)    Cmt(Kb)    Uncmt(Kb)
DBMS         0x10000000 32769       31936      0xF5EDE61   0      0      4992       11648      11648      11648      20288
FMP          0x11F30000 65538       22592      0x0         0      0      2          0          192        22592      0
Trace        0x00000000 0           8510       0xF5EDE74   0      -1     0          8510       0          8510       0
--指定数据库名称
[db2inst1@xifenfei ~]$ db2pd -memset -db xifenfei
Database Partition 0 -- Database XIFENFEI -- Active -- Up 0 days 01:26:18 -- Date 2012-05-07-23.56.47.325997
Memory Sets:
Name         Address    Id          Size(Kb)   Key         DBP    Type   Unrsv(Kb)  Used(Kb)   HWM(Kb)    Cmt(Kb)    Uncmt(Kb)
XIFENFEI     0xA62E9000 1015815     205632     0x0         0      1      33664      96832      96832      96832      108800
AppCtl       0xB2BB9000 983046      40064      0x0         0      12     0          576        832        832        39232
App38        0x00000000 0           0          0x0         0      0      0          0          0          0          0
App37        0x00000000 0           0          0x0         0      0      0          0          0          0          0
App36        0x00000000 0           0          0x0         0      0      0          0          0          0          0
App35        0x00000000 0           0          0x0         0      0      0          0          0          0          0
App34        0x000E8005 950277      128        0x0         0      4      0          128        0          128        0

查看内存段具体信息

[db2inst1@xifenfei ~]$ db2pd -mempool
Database Partition 0 -- Active -- Up 0 days 00:18:48 -- Date 2012-05-07-22.30.01.008074
Memory Pools:
Address    MemSet   PoolName   Id    Overhead   LogSz       LogUpBnd    LogHWM      PhySz       PhyUpBnd    PhyHWM      Bnd BlkCnt CfgParm
0x10000AA4 DBMS     fcm        74    0          0           608414      0           0           655360      0           Ovf 0      n/a
0x100009F0 DBMS     fcmsess    77    65440      845168      1118208     845168      983040      1179648     983040      Ovf 3      n/a
0x1000093C DBMS     fcmchan    79    65440      159488      405504      159488      327680      458752      327680      Ovf 3      n/a
0x10000888 DBMS     fcmbp      13    65440      590592      860160      590592      786432      917504      786432      Ovf 3      n/a
0x100007D4 DBMS     fcmctl     73    186304     1176241     3118764     1176241     1376256     3145728     1376256     Ovf 11     n/a
0x10000720 DBMS     monh       11    122592     144003      368640      144251      327680      393216      327680      Ovf 18     MON_HEAP_SZ
0x1000066C DBMS     resynch    62    26928      104080      1703936     104080      196608      1703936     196608      Ovf 2      n/a
0x100005B8 DBMS     apmh       70    2672       459104      4325376     459636      524288      4325376     524288      Ovf 25     n/a
0x10000504 DBMS     kerh       52    112        276828      3997696     276828      327680      3997696     327680      Ovf 65     n/a
0x10000450 DBMS     bsuh       71    65408      2235556     8978432     2266560     2359296     8978432     2359296     Ovf 44     n/a
0x1000039C DBMS     sqlch      50    0          1681833     1703936     1681833     1703936     1703936     1703936     Ovf 203    n/a
0x100002E8 DBMS     krcbh      69    0          106248      65536       106352      131072      65536       131072      Ovf 14     n/a
0x10000234 DBMS     eduah      72    1904       2816016     2816048     2816016     2818048     2818048     2818048     Ovf 1      n/a
0x11F30234 FMP      undefh     59    8048       122900      22971520    122900      131072      23003136    131072      Phy 1      n/a
--指定数据库名称
[db2inst1@xifenfei ~]$ db2pd -mempool -db xifenfei
Database Partition 0 -- Database XIFENFEI -- Active -- Up 0 days 00:05:29 -- Date 2012-05-07-22.35.58.149684
Memory Pools:
Address    MemSet   PoolName   Id    Overhead   LogSz       LogUpBnd    LogHWM      PhySz       PhyUpBnd    PhyHWM      Bnd BlkCnt CfgParm
0xA62E9E28 XIFENFEI utilh      5     0          2120        24313856    2544        65536       24313856    65536       Ovf 10     UTIL_HEAP_SZ
0xA62E9CC0 XIFENFEI pckcacheh  7     29216      115799      Unlimited   117211      196608      Unlimited   196608      Ovf 4      PCKCACHESZ
0xA62E9C0C XIFENFEI xmlcacheh  93    50944      80008       20971520    80008       131072      20971520    131072      Ovf 1      n/a
0xA62E9B58 XIFENFEI catcacheh  8     0          59488       Unlimited   59488       65536       Unlimited   65536       Ovf 9      CATALOGCACHE_SZ
0xA62E99F0 XIFENFEI bph        16    114464     72118000    Unlimited   72118000    72482816    Unlimited   72482816    Ovf 535    n/a
0xA62E9888 XIFENFEI bph        16    32         782592      Unlimited   782592      851968      Unlimited   851968      Ovf 5      n/a
0xA62E9720 XIFENFEI bph        16    32         520448      Unlimited   520448      589824      Unlimited   589824      Ovf 3      n/a
0xA62E95B8 XIFENFEI bph        16    32         389376      Unlimited   389376      458752      Unlimited   458752      Ovf 2      n/a
0xA62E9450 XIFENFEI bph        16    32         323840      Unlimited   323840      393216      Unlimited   393216      Ovf 2      n/a
0xA62E939C XIFENFEI shsorth    18    0          8860        28770304    8860        65536       28770304    65536       Ovf 16     SHEAPTHRES_SHR
0xA62E92E8 XIFENFEI lockh      4     32         10487424    10616832    10487424    10551296    10616832    10551296    Ovf 1      LOCKLIST
0xA62E9234 XIFENFEI dbh        2     419040     12439291    24903680    12441635    13172736    24903680    13172736    Ovf 739    DBHEAP
0xB2BB966C AppCtl   apph       1     0          7452        1048576     7452        65536       1048576     65536       Phy 17     APPLHEAPSZ
0xB2BB95B8 AppCtl   apph       1     0          7452        1048576     7452        65536       1048576     65536       Phy 17     APPLHEAPSZ
0xB2BB9504 AppCtl   apph       1     0          7452        1048576     8864        65536       1048576     65536       Phy 17     APPLHEAPSZ
0xB2BB9450 AppCtl   apph       1     0          7452        1048576     7452        65536       1048576     65536       Phy 17     APPLHEAPSZ
0xB2BB92E8 AppCtl   apph       1     0          7726        1048576     18084       65536       1048576     65536       Phy 20     APPLHEAPSZ
0xB2BB9234 AppCtl   appshrh    20    2048       127088      20480000    144484      196608      20512768    196608      Phy 25     application shared

使用dblink导致的/*+ OPAQUE_TRANSFORM */

数据库版本

--目标端
SQL> select * from v$version;
BANNER
-----------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production
PL/SQL Release 11.2.0.3.0 - Production
CORE    11.2.0.3.0      Production
TNS for 32-bit Windows: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production
--源端
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE    10.2.0.4.0      Production
TNS for Linux: Version 10.2.0.4.0 - Production
NLSRTL Version 10.2.0.4.0 - Production

目标端创建dblink

SQL> create database link dblink_xff connect to test identified by
  2  test using 'ip/mcrm';
数据库链接已创建。

dblink查询操作测试

--目标端
SQL> select count(*) from t_xifenfei@dblink_xff;
  COUNT(*)
----------
     50645
--源端
SQL> select sql_text from v$sql where lower(sql_text) like '%t_xifenfei%'
and sql_text not like '%lower(%' and sql_text not like '%OPT_DYN_SAMP%';
SQL_TEXT
-------------------------------------------------------------------
SELECT COUNT(*) FROM "T_XIFENFEI" "A1"
SELECT /*+ FULL(P) +*/ * FROM "T_XIFENFEI" P

dblink创建空表测试

--目标端
SQL> create table  chf.t_xifenfei as select * from t_xifenfei@dblink_xff where 1=0;
表已创建。
--源端
SQL> select sql_text from v$sql where lower(sql_text) like '%t_xifenfei%'
and sql_text not like '%lower(%' and sql_text not like '%OPT_DYN_SAMP%';
SQL_TEXT
----------------------------------------------------------------------------
SELECT /*+ FULL(P) +*/ * FROM "T_XIFENFEI" P

dblink创建表插入数据

--目标端
SQL> create table  chf.t_xifenfei_new as select * from t_xifenfei@dblink_xff;
表已创建。
--源端
SQL> select sql_text from v$sql where lower(sql_text) like '%t_xifenfei%'
and sql_text not like '%lower(%' and sql_text not like '%OPT_DYN_SAMP%';
SQL_TEXT
--------------------------------------------------------------------------------
SELECT /*+ FULL(P) +*/ * FROM "T_XIFENFEI" P
SELECT "OWNER","OBJECT_NAME","SUBOBJECT_NAME","OBJECT_ID","DATA_OBJECT_ID","OBJE
CT_TYPE","CREATED","LAST_DDL_TIME","TIMESTAMP","STATUS","TEMPORARY","GENERATED",
"SECONDARY" FROM "T_XIFENFEI" "T_XIFENFEI"

dblink insert select插入数据测试

--目标端
SQL> insert into chf.t_xifenfei
  2  select * from t_xifenfei@dblink_xff;
已创建 50645 行。
--源端
SQL> select sql_text from v$sql where lower(sql_text) like '%t_xifenfei%'
and sql_text not like '%lower(%' and sql_text not like '%OPT_DYN_SAMP%';
SQL_TEXT
--------------------------------------------------------------------------------
SELECT /*+ FULL(P) +*/ * FROM "T_XIFENFEI" P
SELECT /*+ OPAQUE_TRANSFORM */ "OWNER","OBJECT_NAME","SUBOBJECT_NAME","OBJECT_ID
","DATA_OBJECT_ID","OBJECT_TYPE","CREATED","LAST_DDL_TIME","TIMESTAMP","STATUS",
"TEMPORARY","GENERATED","SECONDARY" FROM "T_XIFENFEI" "T_XIFENFEI"

除掉OPAQUE_TRANSFORM 提示

--目标端
SQL> alter session set events '22825 trace name context forever, level 1' ;
会话已更改。
SQL> insert into chf.t_xifenfei
  2  select * from t_xifenfei@dblink_xff;
已创建 50645 行。
--源端
SQL> select sql_text from v$sql where lower(sql_text) like '%t_xifenfei%' and sq
l_text not like '%lower(%' and sql_text not like '%OPT_DYN_SAMP%';
SQL_TEXT
--------------------------------------------------------------------------------
SELECT /*+ FULL(P) +*/ * FROM "T_XIFENFEI" P
SELECT "OWNER","OBJECT_NAME","SUBOBJECT_NAME","OBJECT_ID","DATA_OBJECT_ID","OBJE
CT_TYPE","CREATED","LAST_DDL_TIME","TIMESTAMP","STATUS","TEMPORARY","GENERATED",
"SECONDARY" FROM "T_XIFENFEI" "T_XIFENFEI"

通过dblink的相关实验可以得出,在 insert-as-remote-select的时候,源端库上会出现/*+ OPAQUE_TRANSFORM */的hint提示.该hint的作用是:给出源端目标端要求的数据类型的明确信息(The OPAQUE_TRANSFORM hint is to help with the transformation of datatype when certain type of operations are done within the database).屏蔽盖hint的方法是设置event:22825 trace name context forever, level 1(官方文档还提供了另外两种hint的方式屏蔽这个,但是我测试均未成功)