首先需要确定哪个(些)WebLogic的进程导致了异常高CPU占用率,做法是在发生高占用率情况时捕捉Thread Dump,然后找到服务器Thread Dump中的高占用率线程(这一过程视所在平台而所不同,该过程可能包括若干步骤)

Solaris平台上探查

  1. 使用以下命令捕捉哪些线程(LWPID)正在使用CPU:prstat -L -p 1 1 //找到CPU占用最高的PID
  2. 使用以下命令获得LWPID到(十进制)PID的映射:pstack //找到PID对应的THREAD,然后将其转换成16进制的nid
  3. 使用以下命令获得服务Thread Dump:kill -3 // 与16进制的NID对比

AIX平台上探查

  1. 找到正在使用CPU的线程ID(thread id,tid) : ps -mp -o THREAD //找到cp值最高的tid
  2. 使用以下命令获得服务Thread Dump:kill -3

然后使用以下步骤进行探查

  1. 使用以下命令在服务上进行dbx:dbx -a
  2. 在dbx中,使用以下命令获得所有线程的列表:thread
  3. 在输出线程列表中,找到高占用率的TID及其号码($t形式的号码)
  4. 在dbx中,使用以下命令获得详细的线程信息:th info
  5. 在”general”输出中,找到pthread_t(十六进制)值
  6. 从进程中分离:detach(重要);
  7. 在服务器Thread Dump中找到像:native ID:这样的十六进制pthread_t号码
  8. 确定该线程执行的哪一项任务导致了异常高CPU占用率.

Linux平台上探查

  1. 找到正在使用CPU的线程ID(pid): top -Hp -d 1 -n 1 //找到$CPU占用 最高的pid
  2. 使用以下命令获得服务器Thread Dump:kill -3

然后使用以下步骤进行探查

使用了Sun JDK,需将那个(些)内核线程号(pid)转换成16进制的值,在Thread Dump信息信息中搜索nid等于该值的线程即可,如下:

"ExecuteThread: '14' for queue: 'weblogic.kernel.Default'" daemon prio=1 tid=0x09d11df0 nid=0xa2b

由于JVM使用的glibc版本等原因,Sun HotSpot JVM 1.4.2 update 11(包含该版本)的threaddump信息中不包含nid,这时需要升级Sun HotSpot JVM 1.4.2 update 11的小版本即可,如: update 12,在1.4.2这个大版中,也是从这个版本开始支持发生OutOfMemoryError故障时生成HeadDump文件的。

使用了JROCKIT,只接拿那个(些)内核线程号(pid) 的值,在Thread Dump信息信息中搜索tid等于该值的线程即可(从 JRockit 的 70SP4RP2 和 81SP2RP1 以后的版本起,就可实现此映射,Linux下WebLogic Server自带的JRockit R26.3就是在他们之后的版本),因为JRockit JVM的Thread Dump信息中不包含nid的值,不过JRockit JVM提供一个更简单的tid,等于那个(些)内核线程号(pid)的值,而且是十进制的,无需进行进制转换。如下:

"ExecuteThread: '14' for queue: 'weblogic.kernel.Default'" id=25 idx=0x32 tid=2603 prio=5 alive, in native, daemon

描述

搭建RAC测试环境,使用openfiler 做独立的共享存储服务器。配置完openfiler iscsi服务后在RAC node1上运行iscsiadm discovery参数是报如下错误:

[root@racnode1 ~]# iscsiadm -m discovery -t sendtargets -p 10.10.10.200 
iscsiadm: No portals found 
[root@racnode1 ~]#

使用telnet命令检查openfiler端口开放情况发现3260端口已经开放

[root@racnode1 ~]# telnet 10.10.10.200 3260 
Trying 192.168.12.100… 
Connected to 192.168.12.100. 
Escape character is ‘^]’.

解决方法

在openfiler主机修改/etc/initiators.deny文件。将文件中全部行注释掉。如下:

做完上面操作后到node1运行iscsiadm discovery命令得到正确返回结果。

1. 安装 iSCSI(启动器)服务
就 Oracle Enterprise Linux 5 来说,默认情况下不会安装 Open-iSCSI iSCSI 软件启动器

rpm -qa --queryformat "%{NAME}-%{VERSION}-%{RELEASE} (%{ARCH})\n"| grep iscsi-initiator-utils
rpm -Uvh iscsi-initiator-utils-*

2. 配置 iSCSI(启动器)服务

验证 iscsi-initiator-utils 程序包已经安装完毕之后,启动 iscsid 服务,并使其在系统引导时自动启动。我们还将配置 iscsi 服务在系统启动时自动启动,自动登录到所需的 iSCSI 目标。

service iscsid start
chkconfig iscsid on
chkconfig iscsi on

现在 iSCSI 服务已经启动,下面使用 iscsiadm 命令行接口发现网络存储服务器上的所有可用目标,以检验配置是否正常工作:

iscsiadm -m discovery -t sendtargets -p openfiler

3. 手动登录到 iSCSI 目标

此时,iSCSI 启动器服务已经启动,系统已能够从网络存储服务器中发现可用目标。下一步是手动登录每个可用目标,这可以使用 iscsiadm 命令行接口完成。注意,我必须指定网络存储服务器的 IP 地址而非其主机名,我认为必须这么做,因为上述发现使用 IP 地址显示目标。

iscsiadm -m node -T iqn.2018-06.io.predictech:racdb.data -p 10.10.10.200 -l

4. 配置自动登录

下一步是确保在计算机引导(或 iSCSI 启动器服务启动/重启)时,客户端将自动登录到上面列出的每个目标。

iscsiadm -m node -T iqn.2018-06.io.predictech:racdb.data -p 10.10.10.200 --op update -n node.startup -v automatic

1. 查看进程的长事务,得到XID

GGSCI (rhelv1.localdomain) 72> send extract EG1_G21A,showtrans
Sending SHOWTRANS request to EXTRACT EG1_G21A ...
Oldest redo log file necessary to restart Extract is:
Redo Log Sequence Number 14, RBA 4447248
------------------------------------------------------------
XID:                  5.0.780
Items:                1
Extract:              EG1_G21A
Redo Thread:          1
Start Time:           2017-07-02:10:09:13
SCN:                  0.965762 (965762)
Redo Seq:             14
Redo RBA:             4447248
Status:               Running

此处得到的 XID 为 5.0.780 -> 5

2. 根据 XID 查找正在进行的事务,定位SQLID

select * from gv$transaction where xidusn=5;
select sid,serial#,event,machine,sql_id,seconds_in_wait,prev_sql_id,module,program,action from gv$session where taddr='50E8F800';

此处得到的 sql_id 为:fbwuc1mnwch12

3. 根据 SQLID 定位具体的 SQL 内容

select hash_value, address,executions,buffer_gets, disk_reads,round(buffer_gets/decode(executions, 0, 1, executions), 1) avg_gets,round(disk_reads/decode(executions, 0, 1, executions), 1) avg_disk,
last_load_time,module,sql_fulltext from v$sqlarea where sql_id='&sql_id';

Oracle GoldenGate 在复制源端的事务时依赖于重做日志然后去捕获数据,因此在启动 Oracle GoldenGate 进程之前,必须在源端配置重做日志相关的操作。

1. 开启数据库级别附加日志

Oracle 强烈建议源端数据库运行在归档模式之下,以获取所有的事务,防止数据的丢失。

-- 查询配置,两项均需要为YES
SELECT supplemental_log_data_min, force_logging FROM v$database;
-- 如果有返回结果为NO的话
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE FORCE LOGGING;
-- 再次查询结果是否是YES
SELECT supplemental_log_data_min, force_logging FROM v$database;
-- 切换归档日志
ALTER SYSTEM SWITCH LOGFILE;

2. 开启用户级别附加日志

Oracle GoldenGate 支持用户级别的附加日志,在其它的案例中,这项操作是可选的,但如果没有开启用户级别附加日志,就必须开启表级别附加日志

ADD SCHEMATRANDATA schema [ALLCOLS | NOSCHEDULINGCOLS]

2.1. ALLCOLS 非计算开型附加日志
2.2. NOSCHEDULINGCOLS 参数仅仅用于非集成模式的复制进程,这是用户级别的附加日志的最小需求

3. 开启表级别附加日志

当没有使用用户级别的附加日志时,需要开启表级别的附加日志

ADD TRANDATA [container.]schema.table [, COLS (columns)] [, NOKEY] [, ALLCOLS | NOSCHEDULINGCOLS]