This gallery contains 7 photos.
作为新一代dba(包括我),很少有机会能够接触到ORACLE 8.0.5数据库.今天无意中获得该版本软件安装包,赶紧安装截图出来和大家分享. ORACLE 8.0.5完整安装截图下载oracle_8.0.5_install_pic
Oracle 8.0.5 安装过程截图
Monthly Archives: 五月 2012
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
