分类目录归档：Oracle

CACHE BUFFERS CHAINS等待事件

发表于 2012 年 5 月 9 日 由 惜分飞

关于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)

发表在 Oracle性能优化 | 评论关闭

xdb组件中关于ftp/http监听

发表于 2012 年 5 月 8 日 由 惜分飞

发现监听进程监听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中默认不启用.所以为了你的数据库安全,如果不使用这些功能,建议手工关闭

发表在 Oracle 监听 | 评论关闭

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

发表于 2012 年 5 月 7 日 由 惜分飞

数据库版本

--目标端
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的方式屏蔽这个,但是我测试均未成功)

发表在 Oracle | 一条评论