原文链接：http://www.dbaleet.org/how_to_take_systemstate_dump_on_exadata_cell/
有经验的Oracle DBA都知道， 在Oracle数据库上分析挂起（hang）或者性能问题有两大利器：hanganalyze和systemstate dump。在Exadata上不仅仅DB节点可以做systemstate dump，Cell节点同样也可以做Systemstate dump。 在cell端的systemstate dump主要用于诊断cell节点核心进程cellsrv的异常，例如内存CPU占用率高，cellsrv挂起的并在cell节点的alert中有报RS-7445 CELLSRV HUNG的错误。
Cell节点的systemstate dump有两种方法：
方法一. 利用 cell event （推荐）
cell event是在Oracle内部都未公开的用于诊断和调试（debug）cell软件的一系列事件。相信随着时间的推移，越来越多的event会逐渐露出水面。（我也会在blog公开一些cell events的使用方法）
在cellcli运行alter cell events = “immediate cellsrv.cellsrv_statedump(2,0)”命令就会生成一个cell systemstate dump的trace文件。
CellCLI> alter cell events = "immediate cellsrv.cellsrv_statedump(2,0)"
Dump sequence #1 has been written to /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/log/diag/asm/cell/sinacel01/trace/svtrc_25081_91.trc
Cell sinacel01 successfully altered
这里的2猜测是statedump的level。当然在根据mos上的描述，此参数为0的用法也是可以的。
CellCLI> alter cell events = "immediate cellsrv.cellsrv_statedump(0,0)"
Dump sequence #2 has been written to /opt/oracle/cell11.2.4.4.2_LINUX.X64_111221/log/diag/asm/cell/sinacel01/trace/svtrc_15481_71.trc
Cell dm01cel01 successfully altered
方法二. 利用kill传递一个SIGUSR2信号量
1. 查找cellsrv进程的进程号；
# ps -ef | grep "/opt.*/cellsrv " | grep -v grep
root 25081 25080 0 May24 ? 00:22:07 /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/cellsrv/bin/cellsrv 100 5000 9 5042
2. 利用kill传递SIGUSR2信号量到cellsrv进程；（注意： 请不要去掉-12或者使用12以外的其它任何数字）
# kill -12 25081
3. 查找systemstate dump文件的位置；
# cd /var/log/oracle/diag/asm/cell/sinacel01/trace/
# ls -ltr | grep -i "system stat" *
svtrc_25081_0.trc:2011-06-07 10:39:06.047034*: CELLSRV System State Dump Start
svtrc_25081_0.trc:2011-06-07 10:39:06.923062*: CELLSRV System State Dump End
4. 确认cellsrv进程没有被kill；
# ps -ef | grep "/opt.*/cellsrv " | grep -v grep
root 25081 25080 0 May24 ? 00:23:02 /opt/oracle/cell11.2.2.2.0_LINUX.X64_101206.2/cellsrv/bin/cellsrv 100 5000 9 5042
Comment