整体方法：通过nmon或者其他类似工具的监控记录，分析跑批各个阶段的服务器资源消耗，从阶段划分的角度，观察和分析可能存在的大的问题。

对于可能出现的搞CPU或者高IO的情况，我们希望留存数据库进程的堆栈，和SQL情况进行深入分析。下面是记录方法：

# 1. 用一个脚本，监测dmserver进程CPU占用，超过既定值时，进行特定操作
## 1）获取数据库堆栈 
## 2）获取当时的活动会话情况

cat go.2
while true
do
# 注意：1）用到了 top ，那么只能用at模拟后台运行，或者直接前台运行；nohup的方式，top命令是无输出的；
# 2）这里grep dcr是因为是DSC集群，如果是单机，要注意这里的几个grep的写法，要进行调整；
# 3）最后的awk print $1是因为top取的cpu，有小数，在if里面无法进行判断，这里通过awk阶段成整数
 flag_cpu=`top -bc -n 1|grep dmserver|grep dcr|awk '{print $9}'|awk -F"." '{print $1}'`

if [ "$flag_cpu" -gt 2500 ];then
 sh psp
 sh get.all.sql.sh
fi
echo $flag_cpu
sleep 3
done


--2. 依赖的两个脚本
#这是获取堆栈的脚本
cat psp
#!/bin/bash
nsamples=1
sleeptime=0
#这里是让这个脚本在bin下直接运行，然后可以自动获取pid；只是为了偷懒
pid=$(pidof $PWD/dmserver)
ss=$(date +%F%H%M%S.dmserver.t)
for x in $(seq 1 $nsamples)
do
 gdb -ex "set pagination 0" -ex "thread apply all bt" -batch -p $pid
 sleep $sleeptime
done >$ss
cat $ss|awk '
BEGIN { s=""; }
/^Thread/ { print s;s=""; }
/^#/ { if (s!=""){ s=s","$4} else { s=$4} }
END {print s}
' | sort | uniq -c |sort -r -n -k 1,1
#这是获取活动会话的脚本
cat get.all.sql.sh
flag=`date +%F%H%M%S`
#注意：这里要在dmserver的bin目录运行，同时，要注意修改用户名和密码以及端口号
./disql SYSDBA/SYSDBA:11236 <<eof
set pagesize 0
spool $0.$flag.log
gs;
spool off
eof

通过下面命令，调度起来监控：
at now + 1 min
sh go.2
ctrl+D

然后就可以进行跑批测试了，跑批结束后，可以通过下面命令进行堆栈分析（也是在dmserver的bin目录下运行）：

#grep可以根据自己的实际需求修改
for rs in `ls -lorth *.dmserver.t|grep 'Jul 3 1[89]'|awk '{print $NF}'`;do echo $rs;sh go.2 $rs;done; >all.log
#其中依赖的脚本1为：
cat go.2
a=`sh psp2 $1*|grep --color=auto _cop | awk '{print $1"+}'`;echo $a"0"|bc
a=`sh psp2 $1*|grep --color=auto root_get | awk '{print $1"+}'`;echo $a"0"|bc
sh psp2 $1*|grep -v root_get|grep --color=auto cop
echo
echo '------------------------'
echo
sh psp2 $1*|grep --color=auto cop|grep --color=auto root_get
#其中依赖的脚本2为：
cat psp2
cat $1|awk '
BEGIN { s=""; }
/^Thread/ { print s;s=""; }
/^#/ { if (s!=""){ s=s","$4} else { s=$4} }
END {print s}
' | sort | uniq -c |sort -r -n -k 1,1

其他：
脚本里面用到的gs过程，可以参考这个文章里面找到：
数据库的几个常规巡检 | 公用存储过程，帮助我们快速了解数据库状态 | 工具包

下面是几个常见热点：
1. 7月3日19点00分28秒的堆栈记录，其中活动会话298个，root_get根页冲突的0个，最突出的瓶颈是在进行dcmd_info_set_begin，有165个活动会话是在做这个事情，和enable_monitor参数有关。

2. 堆栈中活动会话301个，root_get根页冲突的12个，最突出的瓶颈是在进行buf_enter，有263个活动会话是在做这个事情，回表时的缓冲区冲突有关（可以考虑优化sql中的回表操作符、使用更小的页大小、更多的buffer_pools）。

3. 堆栈中活动会话181个，root_get根页冲突的0个，最突出的瓶颈是在进行slog_add_data_for_async，有126个活动会话是在做这个事情，这个和SQL日志记录有关，需要适当放大sqllog.ini中的参数。