Linux之pmap命令

Posted on 2011 年 11 月 03 日 by 惜分飞

观察数据库发现，ora_dbw进程占用内存非常高，感觉很奇怪，然后询问高手，通过pmap命令发现，该进程是几乎具有了整个sga的句柄，所以显示占用的内存非常大，其实自己私有的很小

[oracle@DB1 ~]$ top -c

top – 23:06:02 up 553 days, 21:46, 1 user, load average: 0.62, 0.58, 0.47

Tasks: 365 total, 1 running, 364 sleeping, 0 stopped, 0 zombie

Cpu(s): 0.7%us, 0.3%sy, 0.0%ni, 98.3%id, 0.5%wa, 0.0%hi, 0.2%si, 0.0%st

Mem: 24666528k total, 24504356k used, 162172k free, 9192k buffers

Swap: 24579440k total, 3864056k used, 20715384k free, 18728188k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

2270 oracle 15 -1 20.1g 1.1g 1.1g S 2.7 4.7 147:10.01 oracleora9i (LOCAL=NO)

4334 oracle 14 -1 20.1g 1.7g 1.7g S 1.3 7.4 3:08.38 oracleora9i (LOCAL=NO)

5491 oracle 15 -1 20.2g 14g 14g S 1.3 62.1 699:54.55 ora_dbw1_ora9i

9682 oracle 15 0 12868 1296 820 R 1.3 0.0 0:00.14 top -c

18552 oracle 14 -1 20.1g 1.7g 1.7g S 1.3 7.2 2:43.74 oracleora9i (LOCAL=NO)

29977 oracle 14 -1 20.1g 2.1g 2.1g S 1.3 9.1 4:50.87 oracleora9i (LOCAL=NO)

SQL> show parameter sga;

NAME TYPE VALUE

———————————— ———– ——————————

lock_sga boolean FALSE

pre_page_sga boolean FALSE

sga_max_size big integer 20G

sga_target big integer 20G

[oracle@DB1 ~]$ pmap

Usage: pmap [-x | -d] [-q] pid…

-x show details

-d show offset and device number

-q quiet; less header/footer info

-V show the version number

[oracle@DB1 ~]$ pmap -d 5491

5491: ora_dbw1_ora9i

Address Kbytes Mode Offset Device Mapping

0000000000400000 100412 r-x– 0000000000000000 008:00005 oracle

000000000680f000 544 rwx– 000000000620f000 008:00005 oracle

0000000006897000 148 rwx– 0000000006897000 000:00000 [ anon ]

000000001f2f7000 596 rwx– 000000001f2f7000 000:00000 [ anon ]

0000000060000000 20971520 rwxs- 0000000000000000 000:00009 [ shmid=0x0 ]

0000000580000000 2048 rwxs- 0000000000000000 000:00009 [ shmid=0x8001 ]

0000003b44a00000 112 r-x– 0000000000000000 008:00001 ld-2.5.so

……

00002b293c72b000 64 rwx– 0000000000000000 000:00011 zero

00002b293c73b000 64 rwx– 0000000000000000 000:00011 zero

00002b293c74b000 64 rwx– 0000000000000000 000:00011 zero

00002b293c75b000 3840 —– 0000000000b2a000 000:00011 zero

00007fff710f7000 84 rwx– 00007ffffffea000 000:00000 [ stack ]

ffffffffff600000 8192 —– 0000000000000000 000:00000 [ anon ]

mapped: 21145976K writeable/private: 19316K shared: 20973572K

[oracle@DB1 ~]$ pmap -x 5491

5491: ora_dbw1_ora9i

Address Kbytes RSS Anon Locked Mode Mapping

0000000000400000 100412 – – – r-x– oracle

000000000680f000 544 – – – rwx– oracle

0000000006897000 148 – – – rwx– [ anon ]

000000001f2f7000 596 – – – rwx– [ anon ]

0000000060000000 20971520 – – – rwxs- [ shmid=0x0 ]

0000000580000000 2048 – – – rwxs- [ shmid=0x8001 ]

……

00002b293c73b000 64 – – – rwx– zero

00002b293c74b000 64 – – – rwx– zero

00002b293c75b000 3840 – – – —– zero

00007fff710f7000 84 – – – rwx– [ stack ]

ffffffffff600000 8192 – – – —– [ anon ]

—————- —— —— —— ——

total kB 21145976 – – –

Address:进程所占的地址空间

Kbytes 该虚拟段的大小

RSS 设备号（主设备：次设备）

Anon 设备的节点号，0表示没有节点与内存相对应

Locked 是否允许swapped

Mode 权限：r=read, w=write, x=execute, s=shared, p=private(copy on write)

Mapping: bash 对应的映像文件名

10.2.0.x升级到10.2.0.5.5

Posted on 2011 年 11 月 03 日 by 惜分飞

一、数据库10.2.0.x升级到10.2.0.5.5步骤

1、升级数据库到10.2.0.5.0

执行8202632升级补丁中的./runInstaller

执行dbua

2、升级opatch

使用6880880补丁替换原$ORACLE_HOME/OPatch目录

3、升级数据库到10.2.0.5.5

使用补丁12827745，执行$ORACLE_HOME/OPatch/opatch apply ./12827745

执行数据库升级

cd $ORACLE_HOME/rdbms/admin

sqlplus /nolog

SQL> CONNECT / AS SYSDBA

SQL> STARTUP

SQL> @catbundle.sql psu apply

SQL> — Execute the next statement only if this is the first
PSU applied for 10.2.0.5 or this is the first PSU applied since 10.2.0.5.3.

SQL> @utlrp.sql

SQL> QUIT

二、升级过程中出现错误

1、opatch版本过低

严重:OPatch invoked as follows: 'apply ./ '

信息:

Oracle 主目录 : /opt/oracle/product/10.2.0/db_1

主产品清单: /opt/oracle/oraInventory

从 : /etc/oraInst.loc

OPatch 版本 : 10.2.0.4.9

OUI 版本 : 10.2.0.5.0

OUI 位置 : /opt/oracle/product/10.2.0/db_1/oui

日志文件位置 : /opt/oracle/product/10.2.0/db_1/cfgtoollogs/
opatch/opatch2011-11-03_12-43-59下午.log

Patch 12827745 requires OPatch version 10.2.0.5.0.

The OPatch version being used (10.2.0.4.9) doesn't meet the minimum version
required by the patch(es). Please download latest OPatch from My Oracle Support.

信息:系统无任何变化, OPatch 不会尝试还原系统

[oracle@node1 12827745]$ $ORACLE_HOME/OPatch/opatch version

Invoking OPatch 10.2.0.4.9

OPatch Version: 10.2.0.4.9

OPatch succeeded.

处理办法：升级opatch

下载补丁p6880880_102000_Linux-x86-64，备份原来$ORACLE_HOME/OPatch，然后用下载的补丁替换

[oracle@node1 opatch]$ $ORACLE_HOME/OPatch/opatch version

Invoking OPatch 10.2.0.5.1

OPatch Version: 10.2.0.5.1

OPatch succeeded.

2、检测补丁是否冲突

[oracle@node1 12827745]$ $ORACLE_HOME/OPatch/opatch \
>prereq CheckConflictAgainstOHWithDetail -phBaseDir ./

Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1

PREREQ session

Oracle 主目录 : /opt/oracle/product/10.2.0/db_1

主产品清单: /opt/oracle/oraInventory

从 : /etc/oraInst.loc

OPatch 版本 : 10.2.0.5.1

OUI 版本 : 10.2.0.5.0

OUI 位置 : /opt/oracle/product/10.2.0/db_1/oui

日志文件位置 : /opt/oracle/product/10.2.0/db_1/cfgtoollogs/
opatch/opatch2011-11-03_13-50-44下午.log

Patch history file: /opt/oracle/product/10.2.0/db_1/
cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

3、CheckActiveFilesAndExecutables failed

[oracle@node1 12827745]$ $ORACLE_HOME/OPatch/opatch apply

Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1

Oracle 主目录 : /opt/oracle/product/10.2.0/db_1

主产品清单: /opt/oracle/oraInventory

从 : /etc/oraInst.loc

OPatch 版本 : 10.2.0.5.1

OUI 版本 : 10.2.0.5.0

OUI 位置 : /opt/oracle/product/10.2.0/db_1/oui

日志文件位置 : /opt/oracle/product/10.2.0/db_1/
cfgtoollogs/opatch/opatch2011-11-03_13-39-44下午.log

Patch history file: /opt/oracle/product/10.2.0/db_1/
cfgtoollogs/opatch/opatch_history.txt

ApplySession 将中间补丁程序 '12827745' 应用到 OH '/opt/oracle/product/10.2.0/db_1'

Running prerequisite checks…

Prerequisite check "CheckActiveFilesAndExecutables" failed.

The details are:

Following executables are active :

/opt/oracle/product/10.2.0/db_1/bin/oracle

在先决条件检查期间 ApplySession 失败:
Prerequisite check "CheckActiveFilesAndExecutables" failed.

系统无任何变化, OPatch 不会尝试还原系统

OPatch failed with error code 74

解决办法：关闭数据库相关程序

[oracle@node1 12827745]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 – Production on Thu Nov 3 13:52:31 2011

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> !

[oracle@node1 ~]$ lsnrctl stop

[oracle@node1 ~]$ emctl stop dbconsole

4、@catbundle.sql psu apply报错

ORA-04045: errors during recompilation/revalidation of IS1OGG.DDLREPLICATION

ORA-04064: not executed, invalidated

ORA-04064: not executed, invalidated package body "IS1OGG.DDLREPLICATION"

ORA-06508: PL/SQL: could not find program unit being called: "IS1OGG.DDLREPLICATION"

ORA-06512: at line 870

ORA-04064: not executed, invalidated package body "IS1OGG.DDLREPLICATION"

ORA-06508: PL/SQL: could not find program unit being called: "IS1OGG.DDLREPLICATION"

ORA-06512: at line 870

ORA-04045: errors during recompilation/revalidation of IS1OGG.DDLREPLICATION

ORA-04064: not executed, invalidated

ORA-04064: not executed, invalidated package body "IS1OGG.DDLREPLICATION"

ORA-06508: PL/SQL: could not find program unit being called: "IS1OGG.DDLREPLICATION"

ORA-06512: at line 870

ORA-04064: not executed, invalidated package body "IS1OGG.DDLREPLICATION"

ORA-06508: PL/SQL: could not find program unit being called: "IS1OGG.DDLREPLICATION"

解决方法：关闭ogg的ddl捕获

因为ddl捕获触发器，导致这些操作失败

ddl_disable.sql

升级完成后，开启ddl捕获触发器

ddl_enable.sql

三、opatch主要命令解释

1、查看升级是否成功

[oracle@node1 ~]$ $ORACLE_HOME/OPatch/opatch lsinv -bugs_fixed|grep PSU

ENCAPSULATED BY EXCEPTION HANDLING

9952230 12827745 Thu Nov 03 13:55:42 CST 2011 DATABASE PSU 10.2.0.5.1 (INCLUDES CPUOCT2010)

10248542 12827745 Thu Nov 03 13:55:42 CST 2011 DATABASE PSU 10.2.0.5.2 (INCLUDES CPUJAN2011)

11724962 12827745 Thu Nov 03 13:55:42 CST 2011 DATABASE PSU 10.2.0.5.3 (INCLUDES CPUAPR2011)

12419392 12827745 Thu Nov 03 13:55:42 CST 2011 DATABASE PSU 10.2.0.5.4 (INCLUDES CPUJUL2011)

12827745 12827745 Thu Nov 03 13:55:42 CST 2011 DATABASE PSU 10.2.0.5.5 (INCLUDES CPUOCT2011)

2、检测补丁是否冲突

[oracle@node1 12827745]$ $ORACLE_HOME/OPatch/opatch prereq \
>CheckConflictAgainstOHWithDetail -phBaseDir ./

Invoking OPatch 10.2.0.5.1

Oracle 中间补丁程序安装程序版本 10.2.0.5.1

PREREQ session

Oracle 主目录 : /opt/oracle/product/10.2.0/db_1

主产品清单: /opt/oracle/oraInventory

从 : /etc/oraInst.loc

OPatch 版本 : 10.2.0.5.1

OUI 版本 : 10.2.0.5.0

OUI 位置 : /opt/oracle/product/10.2.0/db_1/oui

日志文件位置 : /opt/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/
opatch2011-11-03_13-50-44下午.log

Patch history file: /opt/oracle/product/10.2.0/db_1/
cfgtoollogs/opatch/opatch_history.txt

Invoking prereq "checkconflictagainstohwithdetail"

Prereq "checkConflictAgainstOHWithDetail" passed.

OPatch succeeded.

3、预演补丁实施

opatch apply -report

4、卸载补丁

opatch rollback -id 8350262

块修改跟踪特性(Block Change Tracking)

Posted on 2011 年 11 月 03 日 by 惜分飞

有一服务器有1T左右的数据，备份策略是(1+2)*2（1全备，2增量备份，备份保留2周期）的备份策略，随便增量备份减少了备份的体积，但是增量备份的时间，基本上和全备无差别，都是要近6小时（包括压缩）。这里没有完全体现出增量备份的强大之处，因为没有开启块修改跟踪，无论是增量备份还是全备都需要扫描所有的数据块。虽然网上说开启块修改跟踪可能会会触发一些bug，但是我找了下，10.2.0.4以后块修改跟踪还是比较稳定的，所以决定开启块修改跟踪功能，节约增量备份时间，提高系统性能。

一、开启块修改跟踪

[oracle@node1 bdump]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 – Production on Thu Nov 3 11:13:54 2011

Connected to:

Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> alter database enable block change tracking using file

2 '/opt/oracle/oradata/ecp/Oracle_change.trace';

Database altered.

SQL> set long 200

SQL> col filename for a50

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

ENABLED /opt/oracle/oradata/ecp/Oracle_change.trace 11599872

SQL> !/opt/oracle/oradata/ecp/Oracle_change.trace

/bin/bash: /opt/oracle/oradata/ecp/Oracle_change.trace: 权限不够

SQL> !

[oracle@node1 ~]$ ll /opt/oracle/oradata/ecp/Oracle_change.trace

-rw-r—– 1 oracle oinstall 11600384 11-03 11:05 /opt/oracle/oradata/ecp/Oracle_change.trace

[oracle@node1 ~]$ ps -ef|grep ctwr|grep -v grep

oracle 2771 1 0 11:05 ? 00:00:00 ora_ctwr_ecp

[oracle@node1 bdump]$ tail -11 /opt/oracle/admin/ecp/bdump/alert_ecp.log

Thu Nov 03 11:05:47 CST 2011

alter database enable block change tracking using file

'/opt/oracle/oradata/ecp/Oracle_change.trace'

Thu Nov 03 11:05:47 CST 2011

Block change tracking file is current.

Starting background process CTWR

CTWR started with pid=18, OS id=2771

Block change tracking service is active.

Thu Nov 03 11:05:48 CST 2011

Completed: alter database enable block change tracking using file

'/opt/oracle/oradata/ecp/Oracle_change.trace'

通过这些都可以看出来，开启块修改跟踪功能，会启动CTWR进程，并且修改的块号会被记录到指定文件中

二、关闭块改变跟踪

SQL> alter database disable block change tracking;

Database altered.

SQL> col filename for a50

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

DISABLED

SQL> !

[oracle@node1 bdump]$ ll /opt/oracle/oradata/ecp/Oracle_change.trace

ls: /opt/oracle/oradata/ecp/Oracle_change.trace: 没有那个文件或目录

[oracle@node1 bdump]$ ps -ef|grep ctwr|grep -v grep

[oracle@node1 bdump]$ tail -8 /opt/oracle/admin/ecp/bdump/alert_ecp.log

Thu Nov 03 11:14:06 CST 2011

alter database disable block change tracking

Thu Nov 03 11:14:07 CST 2011

Block change tracking service stopping.

Thu Nov 03 11:14:07 CST 2011

Stopping background process CTWR

Deleted file /opt/oracle/oradata/ecp/Oracle_change.trace

Completed: alter database disable block change tracking

通过这些都可以看出来，关闭块修改跟踪功能，会关闭CTWR进程，并且删除跟踪文件（Linux系统会删除，Window不会）

三、块修改跟踪文件重命名

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

ENABLED /opt/oracle/oradata/ecp/Oracle_change.trace 11599872

SQL> alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

2 to '/opt/oracle/oradata/ecp/Oracle_change.trace_new';

alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

ERROR at line 1:

ORA-01511: error in renaming log/data files

ORA-19771: cannot rename change tracking file while database is open

SQL> shutdown immediate

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Total System Global Area 1610612736 bytes

Fixed Size 2096632 bytes

Variable Size 385876488 bytes

Database Buffers 1207959552 bytes

Redo Buffers 14680064 bytes

Database mounted.

SQL> alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

2 to '/opt/oracle/oradata/ecp/Oracle_change.trace_new';

Database altered.

SQL> alter database open;

Database altered.

SQL> SELECT * FROM v$block_change_tracking;

STATUS FILENAME BYTES

———- ————————————————– ———-

ENABLED /opt/oracle/oradata/ecp/Oracle_change.trace_new 11599872

[oracle@node1 bdump]$ tail -100 /opt/oracle/admin/ecp/bdump/alert_ecp.log |more

Thu Nov 03 11:22:34 CST 2011

alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

to '/opt/oracle/oradata/ecp/Oracle_change.trace_new'

Completed: alter database rename file '/opt/oracle/oradata/ecp/Oracle_change.trace'

to '/opt/oracle/oradata/ecp/Oracle_change.trace_new'

Thu Nov 03 11:22:40 CST 2011

alter database open

Thu Nov 03 11:22:40 CST 2011

CHANGE TRACKING is enabled for this database, but the

change tracking file can not be found. Recreating the file.

Change tracking file recreated.

Block change tracking file is current.

[oracle@node1 bdump]$ ll /opt/oracle/oradata/ecp/Oracle_change.trace*

-rw-r—– 1 oracle oinstall 11600384 11-03 11:22 /opt/oracle/oradata/ecp/Oracle_change.trace

-rw-r—– 1 oracle oinstall 11600384 11-03 12:05 /opt/oracle/oradata/ecp/Oracle_change.trace_new

数据库在open状态下不能修改，所以必须把数据库重启至mount状态才能够修改，如果库不能重启，那么可以先关闭原块修改跟踪功能，再开启块修改跟踪功能。
两种方法比较：
1、都会重新建立一个跟踪文件
2、如果是重命名，老的跟踪文件不会自动被删除，需要人工删除
3、推荐使用关闭跟踪功能，然后在重新制定跟踪文件开启跟踪功能