关于HACMP process monitor引起切换的问题
环境描述： AIX 5.3 P55A 双机HACMP环境 DB2 V9.1 数据库 HADR 主备资源组；针对主数据库资源组定义 process monitor 编制监控脚本db2_prd_mon，该脚本的功能是判断数据库连接情况，一旦连接成功返回0 如果连接不成功 sleep 30秒 计数器加1 当计数器值超过5时 返回非0值（累加期间只要连接成功则直接返回0），每30秒调用一次脚本；
脚本每次成功连接后的输出信息如下：
db2mon.sh run at Mon May 19 03:07:42 UTC 2014
[YOU HAVE NEW MAIL]
Database Connection Information
Database server = DB2/AIX64 9.1.0
SQL authorization ID = MESDBADM
Local database alias = DBMES
return code:0
注： //HA调用脚本时用date取的时间好像和系统正常时间差8个小时，其实上面这个例子是中午11点多的脚本调用
问题描述：
上面例子的脚本调用输出在“May 19 03:08:14 UTC 2014”（也就是May 19 11:08:14 UTC 2014）被调用后，日志文件再没有日志输出（就好像30秒一次的由HA自动调用的脚本压根没有被调用似的），然后于/tmp下的hacmp.out文件中发现如下开始的信息：
“May 19 11:18:39 EVENT START: server_down byq_mh1 2 db2_prd_mon” 即过了大概10分钟后，主数据库资源组直接出现了切换，而且好像还是因为db2_prd_mon脚本返回错误信息导致的（我的理解），而db2_prd_mon脚本根据之前的日志输出来看又好像将近10分钟没有被调用了啊！谁能帮我解释一下这其中我认为存在矛盾和不解的地方呢？——为什么将近10分钟没有脚本调用的痕迹即日志输出？为什么10分钟后直接提示发生server_down事件而直接切换资源组？
附：hacmp.out一些内容
May 19 11:18:39 EVENT START: server_down byq_mh1 2 db2_prd_mon
:server_down[+68] version=1.12
:server_down[+70] :server_down[+70] cl_get_path
HA_DIR=es
:server_down[+75] [ 3 -gt 3 ]
:server_down[+81] MONITOR=
:server_down[+82] STATUS=0
:server_down[+83] EXIT_STATUS=0
:server_down[+88] NODENAME=byq_mh1
:server_down[+89] ID=2
:server_down[+90] [[ 3 = 3 ]]
:server_down[+90] MONITOR=db2_prd_mon
:server_down[+95] [ ! -n ]
:server_down[+97] EMULATE=REAL
:server_down[+103] odmget -qid=2 HACMPresource
:server_down[+103] egrep name =
:server_down[+103] cut -f2 -d"
:server_down[+103] typeset RESTYPE=APPLICATIONS
:server_down[+109] [[ -z APPLICATIONS ]]
:server_down[+118] odmget -qid=2 HACMPresource
:server_down[+118] egrep value =
:server_down[+118] cut -f2 -d"
:server_down[+118] typeset APPNAME=db2_prd_app
:server_down[+121] dspmsg scripts.cat 9332 server_down: Called for APPLICATIONS db2_prd_app on node byq_m
h1n server_down APPLICATIONS db2_prd_app byq_mh1
server_down: Called for APPLICATIONS db2_prd_app on node byq_mh1
:server_down[+127] [[ -z db2_prd_mon ]]
:server_down[+132] MONITORS=db2_prd_mon
:server_down[+141] :server_down[+141] odmget -qmonitor=db2_prd_mon and name=NOTIFY_METHOD HACMPmonitor
:server_down[+141] grep value =
:server_down[+141] cut -d" -f2
NOTIFY=
:server_down[+143] :server_down[+143] cut -d -f1
:server_down[+143] echo
NOTIFY_SCRIPT=
:server_down[+143] [[ -n ]]
:server_down[+157] exit 0
May 19 11:18:39 EVENT COMPLETED: server_down byq_mh1 2 db2_prd_mon 0
HACMP Event Summary
Event: server_down byq_mh1 2 db2_prd_mon
Start time: Mon May 19 11:18:39 2014
End time: Mon May 19 11:18:40 2014
......
附监控脚本db2_prd_mon
...
LOGFILE=/tmp/db2mon.log
hour1=$(date +%H)
mint1=$(date +%M)
mint2=$((hour1 * 60))
mint3=$((mint2 + mint1))
echo "db2mon.sh run at `date`">>${LOGFILE}
if [ "$mint3" -ge 268 -a "$mint3" -lt 288 ]
then
rc=$?
echo "db2_prd_mon.sh is not running ">>${LOGFILE}
echo "return code : $rc">>${LOGFILE}
exit $rc
else
#Check database status
flag=0
num=0
###针对数据库连接的判断，5次连接不成功返回#############
while :
do
#将连接数据库后的输出信息写入日志
su - $INST_NAME -c db2 connect to $DB_NAME >>${LOGFILE}
rc=$?
if [ $rc -ne 0 ]
then
if [ $num -gt 4 ]
then
#echo "超过5次没连接上数据库报错退出!"
flag=1
break
else
#echo "计数器加1"
num=$((num+1))
fi
else
echo "数据库正常连接!"
flag=0
break
fi
sleep 30
done
#######################################################
if [ $flag -ne 0 ]
then
echo "数据库连接错误!"
echo "return code: $rc"
exit $rc
fi
su - $INST_NAME -c db2 disconnect current >/dev/null
echo "return code: $rc">>${LOGFILE}
exit $rc
fi
脚本每次成功连接后的输出信息如下：
db2mon.sh run at Mon May 19 03:07:42 UTC 2014
[YOU HAVE NEW MAIL]
Database Connection Information
Database server = DB2/AIX64 9.1.0
SQL authorization ID = MESDBADM
Local database alias = DBMES
return code:0
注： //HA调用脚本时用date取的时间好像和系统正常时间差8个小时，其实上面这个例子是中午11点多的脚本调用
问题描述：
上面例子的脚本调用输出在“May 19 03:08:14 UTC 2014”（也就是May 19 11:08:14 UTC 2014）被调用后，日志文件再没有日志输出（就好像30秒一次的由HA自动调用的脚本压根没有被调用似的），然后于/tmp下的hacmp.out文件中发现如下开始的信息：
“May 19 11:18:39 EVENT START: server_down byq_mh1 2 db2_prd_mon” 即过了大概10分钟后，主数据库资源组直接出现了切换，而且好像还是因为db2_prd_mon脚本返回错误信息导致的（我的理解），而db2_prd_mon脚本根据之前的日志输出来看又好像将近10分钟没有被调用了啊！谁能帮我解释一下这其中我认为存在矛盾和不解的地方呢？——为什么将近10分钟没有脚本调用的痕迹即日志输出？为什么10分钟后直接提示发生server_down事件而直接切换资源组？
附：hacmp.out一些内容
May 19 11:18:39 EVENT START: server_down byq_mh1 2 db2_prd_mon
:server_down[+68] version=1.12
:server_down[+70] :server_down[+70] cl_get_path
HA_DIR=es
:server_down[+75] [ 3 -gt 3 ]
:server_down[+81] MONITOR=
:server_down[+82] STATUS=0
:server_down[+83] EXIT_STATUS=0
:server_down[+88] NODENAME=byq_mh1
:server_down[+89] ID=2
:server_down[+90] [[ 3 = 3 ]]
:server_down[+90] MONITOR=db2_prd_mon
:server_down[+95] [ ! -n ]
:server_down[+97] EMULATE=REAL
:server_down[+103] odmget -qid=2 HACMPresource
:server_down[+103] egrep name =
:server_down[+103] cut -f2 -d"
:server_down[+103] typeset RESTYPE=APPLICATIONS
:server_down[+109] [[ -z APPLICATIONS ]]
:server_down[+118] odmget -qid=2 HACMPresource
:server_down[+118] egrep value =
:server_down[+118] cut -f2 -d"
:server_down[+118] typeset APPNAME=db2_prd_app
:server_down[+121] dspmsg scripts.cat 9332 server_down: Called for APPLICATIONS db2_prd_app on node byq_m
h1n server_down APPLICATIONS db2_prd_app byq_mh1
server_down: Called for APPLICATIONS db2_prd_app on node byq_mh1
:server_down[+127] [[ -z db2_prd_mon ]]
:server_down[+132] MONITORS=db2_prd_mon
:server_down[+141] :server_down[+141] odmget -qmonitor=db2_prd_mon and name=NOTIFY_METHOD HACMPmonitor
:server_down[+141] grep value =
:server_down[+141] cut -d" -f2
NOTIFY=
:server_down[+143] :server_down[+143] cut -d -f1
:server_down[+143] echo
NOTIFY_SCRIPT=
:server_down[+143] [[ -n ]]
:server_down[+157] exit 0
May 19 11:18:39 EVENT COMPLETED: server_down byq_mh1 2 db2_prd_mon 0
HACMP Event Summary
Event: server_down byq_mh1 2 db2_prd_mon
Start time: Mon May 19 11:18:39 2014
End time: Mon May 19 11:18:40 2014
......
附监控脚本db2_prd_mon
...
LOGFILE=/tmp/db2mon.log
hour1=$(date +%H)
mint1=$(date +%M)
mint2=$((hour1 * 60))
mint3=$((mint2 + mint1))
echo "db2mon.sh run at `date`">>${LOGFILE}
if [ "$mint3" -ge 268 -a "$mint3" -lt 288 ]
then
rc=$?
echo "db2_prd_mon.sh is not running ">>${LOGFILE}
echo "return code : $rc">>${LOGFILE}
exit $rc
else
#Check database status
flag=0
num=0
###针对数据库连接的判断，5次连接不成功返回#############
while :
do
#将连接数据库后的输出信息写入日志
su - $INST_NAME -c db2 connect to $DB_NAME >>${LOGFILE}
rc=$?
if [ $rc -ne 0 ]
then
if [ $num -gt 4 ]
then
#echo "超过5次没连接上数据库报错退出!"
flag=1
break
else
#echo "计数器加1"
num=$((num+1))
fi
else
echo "数据库正常连接!"
flag=0
break
fi
sleep 30
done
#######################################################
if [ $flag -ne 0 ]
then
echo "数据库连接错误!"
echo "return code: $rc"
exit $rc
fi
su - $INST_NAME -c db2 disconnect current >/dev/null
echo "return code: $rc">>${LOGFILE}
exit $rc
fi
4 同行回答
自己顶！ 收起
db2诊断日志内容截取：
2014-05-18-23.29.52.495831+480 I122887615A413 LEVEL: Warning
PID : 471290 TID : 1 PROC : db2logmgr (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Successfully archived log file S0037886.LOG to
/dbmesbackup/mesdbadm/DBMES/NODE0000/C0000086/ from
/dbmeslog/NODE0000/.
2014-05-18-23.32.20.029574+480 I122888029A413 LEVEL: Warning
PID : 471290 TID : 1 PROC : db2logmgr (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Successfully archived log file S0037887.LOG to
/dbmesbackup/mesdbadm/DBMES/NODE0000/C0000086/ from
/dbmeslog/NODE0000/.
2014-05-18-23.35.16.758579+480 I122888443A413 LEVEL: Warning
PID : 471290 TID : 1 PROC : db2logmgr (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Successfully archived log file S0037888.LOG to
/dbmesbackup/mesdbadm/DBMES/NODE0000/C0000086/ from
/dbmeslog/NODE0000/.
2014-05-19-11.18.54.489061+480 I122888857A332 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrp (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrPDoTakeover, probe:43006
MESSAGE : Info: Primary has started non-forced takeover request.
2014-05-19-11.18.54.551736+480 I122889190A321 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrp (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrPDoTakeover, probe:43002
MESSAGE : Info: Primary is switching to standby role.
2014-05-19-11.18.54.552340+480 E122889512A398 LEVEL: Event
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-878
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSwitchDbFromRuntimeToStandby, probe:50122
CHANGE : Current log position at time of Role Switch - LSN = 000000B9039B3C8A
2014-05-19-11.18.54.615546+480 E122889911A350 LEVEL: Event
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-878
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-Peer (was P-Peer)
2014-05-19-11.18.54.621924+480 I122890262A329 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrp (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrPDoTakeover, probe:43003
MESSAGE : Info: Primary has completed takeover (now standby).
2014-05-19-11.18.54.642757+480 I122890592A314 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrStartReplayMaster, probe:21251
MESSAGE : Info: Replaymaster Starting...
2014-05-19-11.18.54.643149+480 I122890907A322 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000
APPHDL : 0-875
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduStartup, probe:21151
MESSAGE : Info: HADR Startup has begun.
2014-05-19-11.18.54.643310+480 I122891230A330 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpReplayMaster, probe:300
MESSAGE : Starting Replay Master on standby.
2014-05-19-11.18.54.643472+480 I122891561A316 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrStartReplayMaster, probe:21252
MESSAGE : Info: Replaymaster request done.
2014-05-19-11.18.54.643579+480 I122891878A294 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP, probe:20302
MESSAGE : Info: Primary Finished.
2014-05-19-11.18.54.643667+480 I122892173A293 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduS, probe:20341
MESSAGE : Info: Standby Started.
2014-05-19-11.18.54.643795+480 I122892467A311 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSPrepareLogWrite, probe:10260
MESSAGE : RCUStartLsn 000000B9039B3C8A
2014-05-19-11.19.19.566994+480 E122892779A346 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpReplayMaster, probe:920
MESSAGE : ADM1602W Rollforward recovery has been initiated.
2014-05-19-11.19.19.580729+480 E122893126A389 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpReplayMaster, probe:1740
MESSAGE : ADM1603I DB2 is invoking the forward phase of the database
rollforward recovery.
2014-05-19-11.19.19.580930+480 I122893516A468 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpForwardRecovery, probe:710
DATA #1 :
Invoking database rollforward forward recovery,
lowtranlsn 000000B9039B3C8A in log file number 37889
minbufflsn 000000B8FD281707 in log file number 37884
2014-05-19-11.19.19.601445+480 I122893985A374 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlprecm, probe:2000
DATA #1 :
Using parallel recovery with 5 agents 23 QSets 92 queues and 64 chunks 收起
2014-05-18-23.29.52.495831+480 I122887615A413 LEVEL: Warning
PID : 471290 TID : 1 PROC : db2logmgr (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Successfully archived log file S0037886.LOG to
/dbmesbackup/mesdbadm/DBMES/NODE0000/C0000086/ from
/dbmeslog/NODE0000/.
2014-05-18-23.32.20.029574+480 I122888029A413 LEVEL: Warning
PID : 471290 TID : 1 PROC : db2logmgr (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Successfully archived log file S0037887.LOG to
/dbmesbackup/mesdbadm/DBMES/NODE0000/C0000086/ from
/dbmeslog/NODE0000/.
2014-05-18-23.35.16.758579+480 I122888443A413 LEVEL: Warning
PID : 471290 TID : 1 PROC : db2logmgr (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, data protection services, sqlpgArchiveLogFile, probe:3180
MESSAGE : Successfully archived log file S0037888.LOG to
/dbmesbackup/mesdbadm/DBMES/NODE0000/C0000086/ from
/dbmeslog/NODE0000/.
2014-05-19-11.18.54.489061+480 I122888857A332 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrp (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrPDoTakeover, probe:43006
MESSAGE : Info: Primary has started non-forced takeover request.
2014-05-19-11.18.54.551736+480 I122889190A321 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrp (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrPDoTakeover, probe:43002
MESSAGE : Info: Primary is switching to standby role.
2014-05-19-11.18.54.552340+480 E122889512A398 LEVEL: Event
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-878
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSwitchDbFromRuntimeToStandby, probe:50122
CHANGE : Current log position at time of Role Switch - LSN = 000000B9039B3C8A
2014-05-19-11.18.54.615546+480 E122889911A350 LEVEL: Event
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-878
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSetHdrState, probe:10000
CHANGE : HADR state set to S-Peer (was P-Peer)
2014-05-19-11.18.54.621924+480 I122890262A329 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrp (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrPDoTakeover, probe:43003
MESSAGE : Info: Primary has completed takeover (now standby).
2014-05-19-11.18.54.642757+480 I122890592A314 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrStartReplayMaster, probe:21251
MESSAGE : Info: Replaymaster Starting...
2014-05-19-11.18.54.643149+480 I122890907A322 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000
APPHDL : 0-875
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduStartup, probe:21151
MESSAGE : Info: HADR Startup has begun.
2014-05-19-11.18.54.643310+480 I122891230A330 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpReplayMaster, probe:300
MESSAGE : Starting Replay Master on standby.
2014-05-19-11.18.54.643472+480 I122891561A316 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrStartReplayMaster, probe:21252
MESSAGE : Info: Replaymaster request done.
2014-05-19-11.18.54.643579+480 I122891878A294 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduP, probe:20302
MESSAGE : Info: Primary Finished.
2014-05-19-11.18.54.643667+480 I122892173A293 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrEduS, probe:20341
MESSAGE : Info: Standby Started.
2014-05-19-11.18.54.643795+480 I122892467A311 LEVEL: Warning
PID : 659524 TID : 1 PROC : db2hadrs (DBMES) 0
INSTANCE: mesdbadm NODE : 000
FUNCTION: DB2 UDB, High Availability Disaster Recovery, hdrSPrepareLogWrite, probe:10260
MESSAGE : RCUStartLsn 000000B9039B3C8A
2014-05-19-11.19.19.566994+480 E122892779A346 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpReplayMaster, probe:920
MESSAGE : ADM1602W Rollforward recovery has been initiated.
2014-05-19-11.19.19.580729+480 E122893126A389 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpReplayMaster, probe:1740
MESSAGE : ADM1603I DB2 is invoking the forward phase of the database
rollforward recovery.
2014-05-19-11.19.19.580930+480 I122893516A468 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlpForwardRecovery, probe:710
DATA #1 :
Invoking database rollforward forward recovery,
lowtranlsn 000000B9039B3C8A in log file number 37889
minbufflsn 000000B8FD281707 in log file number 37884
2014-05-19-11.19.19.601445+480 I122893985A374 LEVEL: Warning
PID : 593962 TID : 1 PROC : db2agnti (DBMES) 0
INSTANCE: mesdbadm NODE : 000 DB : DBMES
APPHDL : 0-875
FUNCTION: DB2 UDB, recovery manager, sqlprecm, probe:2000
DATA #1 :
Using parallel recovery with 5 agents 23 QSets 92 queues and 64 chunks 收起
脚本写的不错 收起