Oracle – 第21页 – Database SOS

拷贝windows中datafile header方法(ocopy)

在很多时候,我们需要对数据文件的头部进行分析,但是因为人不在本地,数据文件本身很大,网络又不好.这个时候我们可能要求对方传过来文件文件的头部几M即可.在unix/linux中可以使用dd实现该需求;在win中可以使用ocopy实现该需求.dd实现请参考:dd操作数据文件;这里讲win下面实现方法:
ocopy语法

D:\>ocopy
OCOPY v2.0 - Copyright 1989-1993 Oracle Corp.  All rights reserved.
Usage:
    ocopy from_file [to_file [a | size_1 [size_n]]]
    ocopy -b from_file to_drive
    ocopy -r from_drive to_dir

ocopy拷贝数据文件header

D:\>ocopy  E:\oracle\oradata\xifenfei\SYSAUX01.DBF d:\sysaux.dbf 20480 1
D:\SYSAUX.DBF
OCOPY - Write error.
--忽略(未找到原因)
D:\>dir sysaux*
 驱动器 D 中的卷没有标签。
 卷的序列号是 000B-FBCB
 D:\ 的目录
2012/05/07  22:28             1,024 SYSAUX.DB2
2012/05/07  22:28             1,024 SYSAUX.DB3
2012/05/07  22:28             1,024 SYSAUX.DB4
2012/05/07  22:28             1,024 SYSAUX.DB5
2012/05/07  22:28             1,024 SYSAUX.DB6
2012/05/07  22:28             1,024 SYSAUX.DB7
2012/05/07  22:28             1,024 SYSAUX.DB8
2012/05/07  22:28             1,024 SYSAUX.DB9
2012/05/07  22:28        20,971,520 SYSAUX.DBF
               9 个文件     20,979,712 字节
               0 个目录 28,771,282,944 可用字节
--SYSAUX.DBF是我们需要的文件

上传到linux中bbed验证

[oracle@xifenfei ~]$ bbed
Password:
BBED: Release 2.0.0.0.0 - Limited Production on Fri May 25 08:31:12 2012
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
************* !!! For Oracle Internal Use only !!! ***************
BBED> set filename '/home/oracle/sysaux.dbf'
        FILENAME        /home/oracle/sysaux.dbf
BBED> set blocksize 8192
        BLOCKSIZE       8192
--从win中拷贝的数据库,第一个block非bbed有效块
BBED> set block 2
        BLOCK#          2
BBED> map
 File: /home/oracle/sysaux.dbf (0)
 Block: 2                                     Dba:0x00000000
------------------------------------------------------------
 Data File Header
 struct kcvfh, 360 bytes                    @0
 ub4 tailchk                                @8188
BBED> map /v
 File: /home/oracle/sysaux.dbf (0)
 Block: 2                                     Dba:0x00000000
------------------------------------------------------------
 Data File Header
 struct kcvfh, 360 bytes                    @0
    struct kcvfhbfh, 20 bytes               @0
    struct kcvfhhdr, 76 bytes               @20
    ub4 kcvfhrdb                            @96
    struct kcvfhcrs, 8 bytes                @100
    ub4 kcvfhcrt                            @108
    ub4 kcvfhrlc                            @112
    struct kcvfhrls, 8 bytes                @116
    ub4 kcvfhbti                            @124
    struct kcvfhbsc, 8 bytes                @128
    ub2 kcvfhbth                            @136
    ub2 kcvfhsta                            @138
    struct kcvfhckp, 36 bytes               @140
    ub4 kcvfhcpc                            @176
    ub4 kcvfhrts                            @180
    ub4 kcvfhccc                            @184
    struct kcvfhbcp, 36 bytes               @188
    ub4 kcvfhbhz                            @224
    struct kcvfhxcd, 16 bytes               @228
    word kcvfhtsn                           @244
    ub2 kcvfhtln                            @248
    text kcvfhtnm[30]                       @250
    ub4 kcvfhrfn                            @280
    struct kcvfhrfs, 8 bytes                @284
    ub4 kcvfhrft                            @292
    struct kcvfhafs, 8 bytes                @296
    ub4 kcvfhbbc                            @304
    ub4 kcvfhncb                            @308
    ub4 kcvfhmcb                            @312
    ub4 kcvfhlcb                            @316
    ub4 kcvfhbcs                            @320
    ub2 kcvfhofb                            @324
    ub2 kcvfhnfb                            @326
    ub4 kcvfhprc                            @328
    struct kcvfhprs, 8 bytes                @332
    struct kcvfhprfs, 8 bytes               @340
    ub4 kcvfhtrt                            @356
 ub4 tailchk                                @8188
--数据块拷贝出来正常

sql_id和hash value的部分转换

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：sql_id和hash value的部分转换

从oracle 10g开始引进了sql_id，在老版本的oralce中,要表明一条sql,一般使用hash value，而在10g及其以后版本中一般建议使用sql_id,从9i的sp和10g的awr中也可以看出.对于Library Cache对象,Oracle使用MD5算法进行哈希,生成一个128位的Hash Value,其中低32位作为HASH VALUE显示,SQL_ID则取了后64位.既然hash value和sql_id之前存在着这样的关系,那么我们就可以通过函数实现两者的部分转换(因为最终取值长度不同,所以不能完全转换)
1.查询sql_id和hash value

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
SQL> select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')
  2  "www.xifenfei.com" from dual;
www.xifenfei.com
-------------------
2012-05-26 01:05:39
SQL> select sql_id,hash_value from v$sql where sql_text like
  2  'select * from dual';
SQL_ID        HASH_VALUE
------------- ----------
a5ks9fhw2v9s1  942515969

2.oracle自带函数转换sql_id to hash value

SQL> select dbms_utility.SQLID_TO_SQLHASH('a5ks9fhw2v9s1') hash_value FROM DUAL;
HASH_VALUE
----------
 942515969

3.自己编写函数sql_id to hash value

SQL> CREATE OR REPLACE FUNCTION sql_id_2_hash_value (sql_id VARCHAR2)
  2     RETURN NUMBER
  3  IS
  4     l_output   NUMBER := 0;
  5  BEGIN
  6         SELECT TRUNC (
  7                   MOD (
  8                      SUM (
  9                         (INSTR ('0123456789abcdfghjkmnpqrstuvwxyz',
 10                                 SUBSTR (LOWER (TRIM (sql_id)), LEVEL, 1))
 11                          - 1)
 12                         * POWER (32, LENGTH (TRIM (sql_id)) - LEVEL)),
 13                      POWER (2, 32)))
 14           INTO l_output
 15           FROM DUAL
 16     CONNECT BY LEVEL <= LENGTH (TRIM (sql_id));
 17     RETURN l_output;
 18  END;
 19  /
函数已创建。
SQL> select sql_id_2_hash_value('a5ks9fhw2v9s1') hash_value FROM DUAL;
HASH_VALUE
----------
 942515969

4.hash value 转换为部分 sql_id

SQL> CREATE OR REPLACE FUNCTION hash_value_2_sql_id (p_hash_value NUMBER)
  2     RETURN VARCHAR2
  3  IS
  4     l_output   VARCHAR2 (8) := '';
  5  BEGIN
  6     FOR i
  7        IN (    SELECT SUBSTR (
  8                          '0123456789abcdfghjkmnpqrstuvwxyz',
  9                          1
 10                          + FLOOR (
 11                               MOD (p_hash_value / (POWER (32, LEVEL - 1)), 32)),
 12                          1)
 13                          sqlidchar
 14                  FROM DUAL
 15            CONNECT BY LEVEL <= LN (p_hash_value) / LN (32)
 16              ORDER BY LEVEL DESC)
 17     LOOP
 18        l_output := l_output || i.sqlidchar;
 19     END LOOP;
 20
 21     RETURN l_output;
 22  END;
 23  /
函数已创建。
SQL> select hash_value_2_sql_id(942515969) from dual;
HASH_VALUE_2_SQL_ID(942515969)
--------------------------------------------------------
2v9s1

参考:http://blog.tanelpoder.com/2009/02/22/sql_id-is-just-a-fancy-representation-of-hash-value/

找出 alter system kill session 'sid,serial#' kill 掉的数据库会话对应进程

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：找出 alter system kill session 'sid,serial#' kill 掉的数据库会话对应进程

当我们使用alter system kill session ‘sid,serial#’ 在数据库中kill掉某个会话的时候,如果你观察仔细会发现v$session.paddr发生了改变,从而是的不能直接通过关联v$process.add找出spid,然后进行其他操作.本文提供三种方法找该种情况下spid的方法.
数据库版本

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 Linux: Version 11.2.0.3.0 - Production
NLSRTL Version 11.2.0.3.0 - Production

会话1

SQL> select sid, SERIAL#,paddr from v$session where
  2  sid=(select sid from v$mystat where rownum=1);
       SID    SERIAL# PADDR
---------- ---------- --------
       133         53 35FE16F4

会话2

SQL> select sid, SERIAL#,paddr from v$session where
  2  sid=(select sid from v$mystat where rownum=1);
       SID    SERIAL# PADDR
---------- ---------- --------
       143         21 35FE2D3C

会话3

SQL> alter system kill session '133,53';
System altered.
SQL> alter system kill session '143,21';
System altered.
SQL> select sid, SERIAL#,paddr,status from v$session where sid in(133,143);
       SID    SERIAL# PADDR    STATUS
---------- ---------- -------- ----------------
       133         53 3547A3F4 KILLED
       143         21 3547A3F4 KILLED

证明alter system kill session后,v$session中的paddr发生了改变,这个时候如果需要找出原来的spid,不能使用v$session.paddr和v$process.addr关联获得

找出kill掉的spid方法1

SQL> select spid, program from v$process
  2      where program!= 'PSEUDO'
  3      and addr not in (select paddr from v$session)
  4      and addr not in (select paddr from v$bgprocess)
  5      and addr not in (select paddr from v$shared_server);
SPID                                             PROGRAM
------------------------------------------------ ------------------------------
14260                                            oracle@xifenfei (L001)
14256                                            oracle@xifenfei (L000)
15300                                            oracle@xifenfei (TNS V1-V3)
14179                                            oracle@xifenfei (D000)
15318                                            oracle@xifenfei (TNS V1-V3)
14252                                            oracle@xifenfei (N000)
SQL> !ps -ef|grep 15300|grep -v grep
oracle   15300 14052  0 03:22 ?        00:00:00 oracleora11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
SQL> !ps -ef|grep 15318|grep -v grep
oracle   15318 15315  0 03:22 ?        00:00:00 oracleora11g (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

找出kill 掉的spid 方法2

SQL> SELECT s.username,s.status,
  2  x.ADDR,x.KSLLAPSC,x.KSLLAPSN,x.KSLLASPO,x.KSLLID1R,x.KSLLRTYP,
  3  decode(bitand (x.ksuprflg,2),0,null,1)
  4  FROM x$ksupr x,v$session s
  5  WHERE s.paddr(+)=x.addr
  6  and bitand(ksspaflg,1)!=0;
USERNAME   STATUS           ADDR       KSLLAPSC   KSLLAPSN KSLLASPO                   KSLLID1R KSLL DE
---------- ---------------- -------- ---------- ---------- ------------------------ ---------- ---- --
           ACTIVE           35FD5990          6         26 14121                             0      1
           ACTIVE           35FD6FD8          1         69 14055                             0      1
           ACTIVE           35FD8620          1         69 14055                             0      1
           ACTIVE           35FD9C68          1         69 14055                             0      1
           ACTIVE           35FDB2B0          8         27 15300                             0      1
           ACTIVE           35FDC8F8         12         36 15300                             0      1
           ACTIVE           35FDDF40          1         69 14055                             0      1
           ACTIVE           35FDF588          1         69 14055                             0      1
           ACTIVE           35FE3860          7         26 14236                             0      1
           ACTIVE           35FE4EA8          1         69 14224                             0      1
           ACTIVE           35FE64F0         63          2 14311                           377 EV   1
           ACTIVE           35FEA7C8          3         26 14155                           258 EV   1
           ACTIVE           35FE9180         59          2 14248                           378 EV   1
           ACTIVE           35FE9CA4         12          2 14603                             0      1
           ACTIVE           35FD64B4          1         69 14055                             0      1
           ACTIVE           35FD7AFC          2         27 14055                             0      1
           ACTIVE           35FD9144          2         27 15300                             0      1
           ACTIVE           35FDA78C          3         26 14171                             0      1
           ACTIVE           35FDBDD4         17          2 15255                             0      1
           ACTIVE           35FDD41C         22         26 14155                             0      1
           ACTIVE           35FDEA64         52         26 14155                             0      1
           ACTIVE           35FE4384          1         69 14224                             0      1
           ACTIVE           35FE59CC          1         69 14224                             0      1
           ACTIVE           35FEB2EC          2          2 14248                             0      1
           ACTIVE           35FEC934         11         26 14121                             0      1
SYS        ACTIVE           35FEF5C4          4         16 14117                             0
                            35FE0BD0          1         69 14055                             0
                            35FE865C          1         69 14117                             0
                            35FE7B38          1         69 14117                             0
                            35FE16F4          1         26 14155                             0
                            35FD4E6C          0          0                                   0
                            35FE00AC          2        279 14117                             0
                            35FE2D3C          0          0                                   0
                            35FE7014          2        335 14117                             0
--挑选username和status为null的会话
SQL> select spid,program from v$process where addr in (
  2  '35FE0BD0',
  3  '35FE865C',
  4  '35FE7B38',
  5  '35FE16F4',
  6  '35FD4E6C',
  7  '35FE00AC',
  8  '35FE2D3C',
  9  '35FE7014'
 10  );
SPID                                             PROGRAM
------------------------------------------------ ------------------------------
                                                 PSEUDO
14179                                            oracle@xifenfei (D000)
14183                                            oracle@xifenfei (S000)
15300                                            oracle@xifenfei (TNS V1-V3)
15318                                            oracle@xifenfei (TNS V1-V3)
14252                                            oracle@xifenfei (N000)
14256                                            oracle@xifenfei (L000)
14260                                            oracle@xifenfei (L001)
8 rows selected.
--同样可以发现spid 15300和15318的进程已经在数据库中被kill掉

找出kill掉的spid方法3(11g特有)

SQL> select  spid,program  from v$process where addr in
  2  (select creator_addr from v$session where sid in(133,143));
SPID                                             PROGRAM
------------------------------------------------ ------------------------------
15300                                            oracle@xifenfei (TNS V1-V3)
15318                                            oracle@xifenfei (TNS V1-V3)

找出kill掉的spid方法4(11g特有)

SQL> select * from V$DETACHED_SESSION;
      INDX PG_NAME                                                             SID    SERIAL#        PID
---------- ------------------------------------------------------------ ---------- ---------- ----------
         0 DEFAULT                                                             143         21         21
         1 DEFAULT                                                             133         53         19
SQL> select spid,program from v$process where pid in(21,19);
SPID                                             PROGRAM
------------------------------------------------ ------------------------------
15300                                            oracle@xifenfei (TNS V1-V3)
15318                                            oracle@xifenfei (TNS V1-V3)

Process OS id : xxxxx alive after kill

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：Process OS id : xxxxx alive after kill

Process OS id : xxxxx alive after kill警告

Mon May 21 04:55:06 2012
Shutting down instance (immediate)
License high water mark = 373
Mon May 21 04:55:06 2012
Stopping Job queue slave processes
Mon May 21 04:55:06 2012
Job queue slave processes stopped
All dispatchers and shared servers shutdown
Mon May 21 04:55:14 2012
Process OS id : 9922 alive after kill
Errors in file
Mon May 21 04:55:16 2012
Process OS id : 8159 alive after kill
Errors in file /oracle/admin/resultdb/udump/resultdb_ora_14639.trc
Mon May 21 04:55:17 2012
Process OS id : 8285 alive after kill
Errors in file /oracle/admin/resultdb/udump/resultdb_ora_14639.trc
Mon May 21 04:55:33 2012
ALTER DATABASE CLOSE NORMAL

错误原因

On some platforms it takes some time to kill processes--AIX being one of those platforms
There have been previous reports of shutdown taking time on AIX and after all Oracle waits were taken out of
the picture it was determined to be due to the way the kill command is implemented on that platform.
Bug 4931101 ERRORS IN ALERT LOG DURING SHUTDOWN

处理建议

Ignore the error  as all processes will be closed and shutdown will complete successfully.

补充说明
本次出问题的数据库是运行在 linux 平台上的 10.2.0.3

主键表插入数据不提交,外键表插入数据被阻塞

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：主键表插入数据不提交,外键表插入数据被阻塞

有客户和我说:他在含主外键的表中实验发现,在主表数据未提交,然后在外键表插入该数据数据时,出现外键表hang住现象.我开始以为是不同的会话,根据oracle数据库的一致性原则,应该新会话在外键表中不能知道这个记录的存在,直接报错.
可是我实验结果证明:外键表会被阻塞.分析原因如下：
模拟环境

SQL> create table t_p(id number primary key,name varchar2(100));
Table created.
SQL> create table t_f(fid number primary key,pid number, foreign key(pid) references  t_p(id));
Table created.
--会话1
SQL> insert into t_p values(1,'xifenfei');
1 row created.
SQL> commit;
Commit complete.
--会话2
SQL> insert into t_f values(1,1);
1 row created.
SQL> commit;
--会话1
SQL> insert into t_p values(2,'XIFENFEI');
1 row created.
--会话2
SQL> insert into t_f values(2,2);
--hang住

通过实验发现,当主键数据没有提交,然后在外键表中插入该数据外键数据时,该条记录会处于hang住状态(等待),那是什么原因导致了这个等待呢？对会话2做一个10046的trace,发现如下

*** 2012-05-17 17:25:41.757
WAIT #3065187488: nam='enq: TX - row lock contention' ela= 27002895 name|mode=1415053316 usn<<16
| slot=262151 sequence=588 obj#=-1 tim=1337246741756917
EXEC #3065187488:c=4000,e=27004456,p=0,cr=2,cu=14,mis=0,r=0,dep=0,og=1,
plh=0,tim=1337246741757690
ERROR #3065187488:err=1013 tim=1337246741757751
STAT #3065187488 id=1 cnt=0 pid=0 pos=1 obj=0 op='LOAD TABLE CONVENTIONAL
(cr=0 pr=0 pw=0 time=12 us)'
WAIT #3065187488: nam='SQL*Net break/reset to client' ela= 581 driver
id=1650815232 break?=0 p3=0 obj#=-1 tim=1337246741782587
WAIT #3065187488: nam='SQL*Net message to client' ela= 2 driver id=1650815232
#bytes=1 p3=0 obj#=-1 tim=1337246741782668

通过这个trace发现,是因为TX锁导致了外键表上的插入操作被阻塞.出现该问题的原因
有两种可能:1.两次插入(主键表和外键表分别插入)在主键表上有不兼容锁;2.外键表上有不兼容性锁.

使用oradebug跟踪会话

oradebug setmypid
--EVENT 10704跟踪锁的使用情况
oradebug EVENT 10704 trace name context forever,level 10
--插入数据操作
oradebug EVENT 10704 trace name context off
oradebug TRACEFILE_NAME

跟踪主键表插入数据

*** 2012-05-17 19:05:52.410
ksqgtl *** TM-00012892-00000000 mode=3 flags=0x401 timeout=21474836 ***
ksqgtl: xcb=0x343c0e54, ktcdix=2147483647, topxcb=0x343c0e54
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:05:52.411
ksucti: init txn DID from session DID
ksqgtl:
        ksqlkdid: 0001-0013-0000000F
*** 2012-05-17 19:05:52.429
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0013-0000000F
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0013-0000000F
ksqgtl: RETURNS 0
*** 2012-05-17 19:05:52.430
ksqgtl *** TM-00012894-00000000 mode=3 flags=0x401 timeout=21474836 ***
ksqgtl: xcb=0x343c0e54, ktcdix=2147483647, topxcb=0x343c0e54
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:05:52.430
ksucti: init session DID from txn DID:
ksqgtl:
        ksqlkdid: 0001-0013-0000000F
*** 2012-05-17 19:05:52.430
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0013-0000000F
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0013-0000000F
ksqgtl: RETURNS 0
*** 2012-05-17 19:05:52.431
ksqgtl *** TX-00050019-00000307 mode=6 flags=0x401 timeout=0 ***
ksqgtl: xcb=0x343c0e54, ktcdix=2147483647, topxcb=0x343c0e54
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:05:52.431
ksucti: init session DID from txn DID:
ksqgtl:
        ksqlkdid: 0001-0013-0000000F
*** 2012-05-17 19:05:52.431
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0013-0000000F
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0013-0000000F
ksqgtl: RETURNS 0
SQL> SELECT TO_NUMBER(12892,'xxxxxxx') from dual;
TO_NUMBER(12892,'XXXXXXX')
--------------------------
                     75922
SQL> SELECT TO_NUMBER(12894,'xxxxxxx') from dual;
TO_NUMBER(12894,'XXXXXXX')
--------------------------
                     75924
SQL> select object_name from dba_objects where object_id in(75922,75924);
OBJECT_NAM
----------
T_P
T_F

通过锁使用情况跟踪可以知道,在主键表插入一条记录时,先在主键表获得TM锁,然后外键表获得TM锁,最后主键表获得TX MODE=6的锁。

跟踪外键表插入数据

*** 2012-05-17 19:49:24.912
ksqgtl *** TM-00012892-00000000 mode=3 flags=0x401 timeout=21474836 ***
ksqgtl: xcb=0x343a45e8, ktcdix=2147483647, topxcb=0x343a45e8
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:49:24.912
ksucti: init txn DID from session DID
ksqgtl:
        ksqlkdid: 0001-0015-00000064
*** 2012-05-17 19:49:24.913
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0015-00000064
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0015-00000064
ksqgtl: RETURNS 0
*** 2012-05-17 19:49:24.913
ksqgtl *** TM-00012894-00000000 mode=3 flags=0x401 timeout=21474836 ***
ksqgtl: xcb=0x343a45e8, ktcdix=2147483647, topxcb=0x343a45e8
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:49:24.913
ksucti: init session DID from txn DID:
ksqgtl:
        ksqlkdid: 0001-0015-00000064
*** 2012-05-17 19:49:24.913
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0015-00000064
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0015-00000064
ksqgtl: RETURNS 0
*** 2012-05-17 19:49:24.913
ksqgtl *** TX-0002001f-0000034a mode=6 flags=0x401 timeout=0 ***
ksqgtl: xcb=0x343a45e8, ktcdix=2147483647, topxcb=0x343a45e8
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:49:24.913
ksucti: init session DID from txn DID:
ksqgtl:
        ksqlkdid: 0001-0015-00000064
*** 2012-05-17 19:49:24.914
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0015-00000064
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0015-00000064
ksqgtl: RETURNS 0
*** 2012-05-17 19:49:24.914
ksqgtl *** TX-00050019-00000307 mode=4 flags=0x10021 timeout=21474836 ***
ksqgtl: xcb=0x343a45e8, ktcdix=2147483647, topxcb=0x343a45e8
        ktcipt(topxcb)=0x0
*** 2012-05-17 19:49:24.914
ksucti: init session DID from txn DID:
ksqgtl:
        ksqlkdid: 0001-0015-00000064
*** 2012-05-17 19:49:24.914
*** ksudidTrace: ksqgtl
        ktcmydid(): 0001-0015-00000064
        ksusesdi:   0000-0000-00000000
        ksusetxn:   0001-0015-00000064
*** 2012-05-17 19:49:24.914
ksqcmi: TX,50019,307 mode=4 timeout=21474836

从这里可以发现:先在主键表和外键表上加上TM锁,然后外键表获得TX MODE=6的锁(这边成功,因为该表上未有其他级别不兼容锁),再需要在主键表上获得TX MODE=4(表结构共享锁+所有记录共享锁),但是这个时候,发现该锁上已经在主键表插入数据未提交的时候,已经含有了TX MODE=6的锁,从而使得TX MODE=4无法获得,从而使得外键表插入数据处于阻塞状态.

ORA-07445 [ACCESS_VIOLATION] [UNABLE_TO_READ] []

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORA-07445 [ACCESS_VIOLATION] [UNABLE_TO_READ] []

alert中发现ORA-07445错误
ORA-07445: exception encountered: core dump [PC:0x7FFF65D0] [ACCESS_VIOLATION] [ADDR:0xFFFFFFFF] [PC:0x7FFF65D0] [UNABLE_TO_READ] []错误,导致数据库down掉

Mon May 14 14:34:34 2012
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFF] [PC:0x7FFF65D0, {empty}]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_p001_1280.trc:
ORA-07445: exception encountered: core dump [PC:0x7FFF65D0] [ACCESS_VIOLATION]
[ADDR:0xFFFFFFFF] [PC:0x7FFF65D0] [UNABLE_TO_READ] []
Mon May 14 14:34:35 2012
Trace dumping is performing id=[cdmp_20120514143435]
Mon May 14 14:35:10 2012
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFF] [PC:0x7FFF65D0, {empty}]
Errors in file d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_1072.trc  (incident=164712):
ORA-07445: exception encountered: core dump [PC:0x7FFF65D0] [ACCESS_VIOLATION]
[ADDR:0xFFFFFFFF] [PC:0x7FFF65D0] [UNABLE_TO_READ] []
ORA-12080: Buffer cache miss for IOQ batching
Incident details in: d:\app\administrator\diag\rdbms\orcl\orcl\incident\incdir_164712\orcl_smon_1072_i164712.trc

分析trace文件

Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
Windows Server 2003 Version V5.2 Service Pack 2
CPU                 : 8 - type 586, 4 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:4892M/8189M, Ph+PgF:5638M/9795M, VA:925M/4095M
Instance name: orcl
Redo thread mounted by this instance: 1
Oracle process number: 12
Windows thread id: 1072, image: ORACLE.EXE (SMON)
--以上信息得出操作系统和数据库版本2003 sp2+oracle11g(11.1.0.6 32位)
Dump continued from file: d:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_smon_1072.trc
ORA-07445: exception encountered: core dump [PC:0x7FFF65D0] [ACCESS_VIOLATION]
[ADDR:0xFFFFFFFF] [PC:0x7FFF65D0] [UNABLE_TO_READ] []
ORA-12080: Buffer cache miss for IOQ batching
========= Dump for incident 164712 (ORA 7445 [PC:0x7FFF65D0]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0xFFFFFFFF] [PC:0x7FFF65D0, {empty}]
--这里的ORA-07445 [ACCESS_VIOLATION][UNABLE_TO_READ]根据经验结合这里的32位的环境,
--怀疑是sga使用的内存太多,ORACLE数据库不能读SGA相关内存导致
--在trace中找出相关参数配置.
[0004]: processes=300
[0004]: sessions=335
[0004]: __shared_pool_size=1124073472
[0004]: __large_pool_size=8388608
[0004]: __java_pool_size=16777216
[0004]: __streams_pool_size=251658240
[0004]: streams_pool_size=251658240
[0004]: sga_target=0
[0004]: __sga_target=1887436800
[0004]: memory_target=3145728000
[0004]: memory_max_target=4722786304
[0004]: db_block_size=8192
[0004]: __db_cache_size=478150656
[0004]: __shared_io_pool_size=0
[0004]: compatible=11.1.0.0.0
[0004]: log_buffer=8851456
[0004]: __pga_aggregate_target=780140544
--这里可以看到sga_target分配了内存为1887436800=1.7578125G
--pga_aggregate_target分配了780140544=0.7265625G
--两者内存之和大于2G,超过了32位ORACLE默认限制

查询MOS发现[1341681.1]
该错误原因

This is a resource issue (memory in particular). 32-bit windows systems,
are limited to 2GB of addressable memory so if you are on this platform
it's likely you are simply exceeding the capabilities of the 32bit operating system.

解决建议

First recommendation :
If you have not already done so, add the /3GB switch to your boot.ini file and reboot the server. The
boot.ini will be located in the root directory on the drive where windows is installed. The switch, /3GB,
is placed at the end of the line that executes the WinNT loading process.
This will allow applications such as oracle access to 3Gb or memory instead of 2Gb.
Example:
[operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="Windows NT Server Version 4.00" /3GB
 Second recommendation :
You do not want to increase memory target. If anything, this should be decreased.
You are limited to under 2GB of addressable memory on 32bit windows (the limit is actually about 1.85GB).
This is for both SGA and PGA memory for all instances; you have to reduce the SGA size for the instance.
The recommendation is to reduce sga_target, memory_target, and memory_max_target.

ORACLE在AIX中产生SOFTWARE PROGRAM ABNORMALLY TERMINATED警告原因

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：ORACLE在AIX中产生SOFTWARE PROGRAM ABNORMALLY TERMINATED警告原因

数据库中发现如下错误
该错误的解决方案:ORA-07445[dbgrmqmqpk_query_pick_key()+0f88]

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)
*** 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] []

errpt错误说明
在产生7445错误的同时观察aix系统错误日志发现SOFTWARE PROGRAM ABNORMALLY TERMINATED错误

sgerp5_[oracle]-->errpt -aj A924A5FC
---------------------------------------------------------------------------
LABEL:          CORE_DUMP
IDENTIFIER:     A924A5FC
Date/Time:       Fri May 11 03:52:55 BEIST 2012
Sequence Number: 471
Machine Id:      00C8F0564C00
Node Id:         sgerp5
Class:           S
Type:            PERM
WPAR:            Global
Resource Name:   SYSPROC
Description
SOFTWARE PROGRAM ABNORMALLY TERMINATED
Probable Causes
SOFTWARE PROGRAM
User Causes
USER GENERATED SIGNAL
        Recommended Actions
        CORRECT THEN RETRY
Failure Causes
SOFTWARE PROGRAM
        Recommended Actions
        RERUN THE APPLICATION PROGRAM
        IF PROBLEM PERSISTS THEN DO THE FOLLOWING
        CONTACT APPROPRIATE SERVICE REPRESENTATIVE
Detail Data
SIGNAL NUMBER
           6
USER'S PROCESS ID:
               7602504
FILE SYSTEM SERIAL NUMBER
          14
INODE NUMBER
           0      367648
CORE FILE NAME
/oracle/diag/rdbms/sgerp5/sgerp5/cdump/core_7602504/core
PROGRAM NAME
oracle
STACK EXECUTION DISABLED
           0
COME FROM ADDRESS REGISTER
sskgmcrea 0
PROCESSOR ID
  hw_fru_id: 1
  hw_cpu_id: 2
ADDITIONAL INFORMATION
skgdbgcra 224
??
ksdbgcra 3D0
ssexhd 978
??
Symptom Data
REPORTABLE
1
INTERNAL ERROR
SYMPTOM CODE
PCSS/SPI2 FLDS/oracle SIG/6 FLDS/skgdbgcra VALU/224

错误原因

This error is logged when a software program abnormally ends and causes a core dump. Users might
not be exiting applications correctly, the system might have been shut down while users were
working in application, or the user's terminal might have locked up and the application stopped
1)这里也就是说如果oracle进程在aix机器上异常终止,并且产生了一个core dump文件,
  就会出现SOFTWARE PROGRAM ABNORMALLY TERMINATED警告信息
2)用户登录系统没有正常退出,而系统被关闭
3)用户强制终止一个一个lock,而导致进程停止

本次AIX日志警告原因:由于进程7602504异常终止(ORA-07445错误)并且产生了 /oracle/diag/rdbms/sgerp5/sgerp5/cdump/core_7602504/core dump 文件,从而有了AIX中的SOFTWARE PROGRAM ABNORMALLY TERMINATED警告信息

常驻连接池(Database Resident Connection Pool)

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：常驻连接池(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)

使用dblink导致的/+ OPAQUE_TRANSFORM /

联系：手机/微信(+86 17813235971) QQ(107644445)

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

关于linux中oracle用户进程占用内存猜测

联系：手机/微信(+86 17813235971) QQ(107644445)

标题：关于linux中oracle用户进程占用内存猜测

本文是针对linux下面显示oracle用户进程占用大量内存的一个猜想性说明,希望各位专家和我一起继续探讨该问题
ORACLE用户进程占用私有内存分析
top命令结果

[oracle@ora02 31500]$ top -c
top - 12:13:16 up 254 days, 12:14,  2 users,  load average: 1.53, 1.62, 1.33
Tasks: 293 total,   3 running, 290 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.4% us,  0.8% sy,  0.0% ni, 94.7% id,  1.1% wa,  0.0% hi,  0.0% si
Mem:   4147172k total,  4129724k used,    17448k free,    20348k buffers
Swap:  4192956k total,   217772k used,  3975184k free,  2575320k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12505 oracle    17   0 1561m 972m 970m R  100 24.0   3:45.89 oracletxzldb (LOCAL=NO)
12475 oracle    16   0 1561m 931m 929m S    4 23.0   4:08.65 oracletxzldb (LOCAL=NO)
12477 oracle    16   0 1561m 945m 942m S    2 23.3   3:36.92 oracletxzldb (LOCAL=NO)
12479 oracle    16   0 1561m 944m 941m S    2 23.3   4:27.29 oracletxzldb (LOCAL=NO)
12483 oracle    16   0 1561m 939m 937m R    2 23.2   3:49.00 oracletxzldb (LOCAL=NO)
12493 oracle    16   0 1561m 958m 955m S    2 23.7   3:35.35 oracletxzldb (LOCAL=NO)

补充说明:

VIRT	进程使用的虚拟内存总量
RES	进程使用的、未被换出的物理内存大小
SHR	共享内存大小

通过这里可以得出几个信息
12505进程实际使用内存情况:972-970=2M
12505进程%MEM:972*1024/4147172=0.24000162
12505进程在数据库中占用内存

SQL> select PGA_ALLOC_MEM/1024/1024 MEM from v$process where spid=12505;
       MEM
----------
1.90997028

通过这里可以看出12505进程实际上是占用了970M的共享内存,占用2M的PGA内存

ORACLE用户进程占用共享内存分析
分析12505进程的当前进程状态

[oracle@ora02 31500]$ cd /proc/12505
[oracle@ora02 12505]$ cat status
Name:   oracle
State:  S (sleeping)
SleepAVG:       92%
Tgid:   12505
Pid:    12505
PPid:   1
TracerPid:      0
Uid:    501     501     501     501
Gid:    502     502     502     502
FDSize: 32
Groups: 501 502
VmSize:  1599004 kB    <--使用内存(包括虚拟内存)总量1599004/1024=1561.52734和top中VIRT基本吻合
VmLck:         0 kB
VmRSS:    996132 kB    <--实际使用内存996132/1024 =972.785156和top看到RES基本吻合
VmData:      832 kB
VmStk:       120 kB
VmExe:     37307 kB
VmLib:      4641 kB
StaBrk: 0ad6e000 kB
Brk:    0adf2000 kB
StaStk: bffff850 kB
ExecLim:        ffffffff
Threads:        1
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000006005203
SigCgt: 00000001c9802cfc
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000

pmap命令分析

[oracle@ora02 12505]$ pmap -d 12505
12505:   oracletxzldb (LOCAL=NO)
Address   Kbytes Mode  Offset           Device    Mapping
0013f000      88 r-x-- 0000000000000000 008:00002 ld-2.3.4.so
00155000       4 r-x-- 0000000000015000 008:00002 ld-2.3.4.so
00156000       4 rwx-- 0000000000016000 008:00002 ld-2.3.4.so
00159000    1176 r-x-- 0000000000000000 008:00002 libc-2.3.4.so
0027f000       8 r-x-- 0000000000125000 008:00002 libc-2.3.4.so
00281000       8 rwx-- 0000000000127000 008:00002 libc-2.3.4.so
00283000       8 rwx-- 0000000000283000 000:00000   [ anon ]
00287000     132 r-x-- 0000000000000000 008:00002 libm-2.3.4.so
002a8000       4 r-x-- 0000000000020000 008:00002 libm-2.3.4.so
002a9000       4 rwx-- 0000000000021000 008:00002 libm-2.3.4.so
002ac000       8 r-x-- 0000000000000000 008:00002 libdl-2.3.4.so
002ae000       4 r-x-- 0000000000001000 008:00002 libdl-2.3.4.so
002af000       4 rwx-- 0000000000002000 008:00002 libdl-2.3.4.so
003b5000      56 r-x-- 0000000000000000 008:00002 libpthread-2.3.4.so
003c3000       4 r-x-- 000000000000d000 008:00002 libpthread-2.3.4.so
003c4000       4 rwx-- 000000000000e000 008:00002 libpthread-2.3.4.so
003c5000       8 rwx-- 00000000003c5000 000:00000   [ anon ]
00ba4000      72 r-x-- 0000000000000000 008:00002 libnsl-2.3.4.so
00bb6000       4 r-x-- 0000000000011000 008:00002 libnsl-2.3.4.so
00bb7000       4 rwx-- 0000000000012000 008:00002 libnsl-2.3.4.so
00bb8000       8 rwx-- 0000000000bb8000 000:00000   [ anon ]
08048000   37308 r-x-- 0000000000000000 0fd:00001 oracle
0a4b7000    8804 rwx-- 000000000246f000 0fd:00001 oracle
0ad50000     648 rwx-- 000000000ad50000 000:00000   [ anon ]
50000000 1540096 rwxs- 0000000000000000 000:00006   [ shmid=0x9000e ]
ae000000       4 r-xs- 000000005e000000 000:00006   [ shmid=0x9000e ]
ae001000    1156 rwxs- 000000005e001000 000:00006   [ shmid=0x9000e ]
ae122000       4 r-xs- 000000005e122000 000:00006   [ shmid=0x9000e ]
ae123000    2932 rwxs- 000000005e123000 000:00006   [ shmid=0x9000e ]
b79d4000    1024 rwx-- 00000000000f4000 000:0000d zero
b7ad4000     512 rwx-- 0000000000074000 000:0000d zero
b7b54000     512 rwx-- 0000000000000000 000:0000d zero
b7bd4000      36 r-x-- 0000000000000000 008:00002 libnss_files-2.3.4.so
b7bdd000       4 r-x-- 0000000000008000 008:00002 libnss_files-2.3.4.so
b7bde000       4 rwx-- 0000000000009000 008:00002 libnss_files-2.3.4.so
b7bdf000     148 rwx-- 00000000b7bdf000 000:00000   [ anon ]
b7c04000    2940 r-x-- 0000000000000000 0fd:00001 libjox9.so
b7ee3000    1088 rwx-- 00000000002de000 0fd:00001 libjox9.so
b7ff3000       8 rwx-- 00000000b7ff3000 000:00000   [ anon ]
b7ff5000       4 r-x-- 0000000000000000 0fd:00001 libskgxn9.so
b7ff6000       8 rwx-- 0000000000000000 0fd:00001 libskgxn9.so
b7ff8000       4 r-x-- 0000000000000000 0fd:00001 libskgxp9.so
b7ff9000       4 --x-- 0000000000001000 0fd:00001 libskgxp9.so
b7ffa000       4 rwx-- 0000000000001000 0fd:00001 libskgxp9.so
b7ffb000       4 r-x-- 0000000000000000 0fd:00001 libodmd9.so
b7ffc000       4 rwx-- 0000000000000000 0fd:00001 libodmd9.so
b7ffd000       4 r-x-- 0000000000000000 008:00002 libcwait.so
b7ffe000       4 rwx-- 0000000000000000 008:00002 libcwait.so
b7fff000       4 rwx-- 00000000b7fff000 000:00000   [ anon ]
bffe2000     120 rwx-- 00000000bffe2000 000:00000   [ stack ]
ffffe000       4 ----- 0000000000000000 000:00000   [ anon ]
mapped: 1599008K    writeable/private: 12944K    shared: 1544192K

补充说明:

mapped ：映射到文件的内存数量
writable/private ：进程所占用的私有地址空间数量
shared ：与其它进程共享的地址空间数量

ipcs 命令

[oracle@ora02 12505]$ ipcs -m
------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x0000cace 65536      root      666        2          0
0x4d4e5251 98305      root      644        330752     0
0x55315352 131074     root      666        4096       0
0x44525354 163843     root      644        632832     0
0x53494152 196612     root      644        1024       0
0x00005643 229381     root      666        1024       1
0x00005654 262150     root      666        1024       1
0x992ad3dc 589838     oracle    640        1581252608 595

结合pmap和ipcs分析(shmid=0x9000e)

SQL> select to_number('9000e','xxxxxxxx') from dual;
TO_NUMBER('9000E','XXXXXXXX')
-----------------------------
                       589838
SQL> select 1540096+4+1156+4+2932 from dual;
1540096+4+1156+4+2932
---------------------
              1544192
SQL> select 1581252608/1024 from dual;
1581252608/1024
---------------
        1544192

通过这里可以得出12505进程中的共享内存,主要是数据库SGA中的共享内存

补充猜测

SQL> show sga;
Total System Global Area 1561926292 bytes
Fixed Size                   453268 bytes
Variable Size             603979776 bytes
Database Buffers          956301312 bytes
Redo Buffers                1191936 bytes
SQL> select 1561926292/1024 from dual;
1561926292/1024
---------------
     1525318.64

这里显示数据库配置的sga比ipcs中配置共享内存段小,但是进程在分配总的共享内存时候,使用的是ipcs设定的内存段大小,实际使用的内存可能是sga设置大小(未得到权威资料)

分类目录归档：Oracle