guoyanxi
- 浏览: 276948 次
- 性别:
- 来自: 广州
-
最新评论
-
Yiwu_zh：
步骤清晰，跟着来做，真搭建好了
不过用的是10.5版本，输出有 ...
搭建简单的DB2 HADR -
luogen33：
db2备份单个表 -
gthao：
1 楼正解。。如果schema里面有内容的话，就删除不了，会报 ...
db2建立schema -
znttql：
整理的太好了 非常感谢啊
DB2 日期 时间 -
alvin198761：
能根据schame备份数据库不？？
db2备份单个表
环境：
apply运行在非target数据库上面
大概思路：
1.发现有问题的SET
2.查看apply log
3.查看相对应的source,target,table
4.查看snapshot
首先是以下SET出现问题，数据没有得到及时更新：
查询information center asn.IBMSNAP_SUBS_SET 表中的status为1的意思
-1
The replication failed. The Apply program backed out the entire set of rows it had applied, and no data was committed. If the startup parameter SQLERRCONTINUE = Y, the SQLSTATE that is returned to the Apply program during the last cycle is not one of the acceptable errors you indicated in the input file for SQLERRCONTINUE (apply qualifier.SQS).
0
The Apply program processed the subscription set successfully. If the startup parameter SQLERRCONTINUE = Y, the Apply program did not encounter any SQL errors that you indicated for the SQLERRCONTINUE startup parameter (in apply_qualifier.SQS) and did not reject any rows.
2
The Apply program is processing the subscription set in multiple cycles. It successfully processed a single logical subscription that was divided according to the MAX_SYNCH_MINUTES control column.
没有1的解释，询问L2，解释道是正在等待数据传送完成，类似于2
按照习惯，先检查apply的输出日志：
显示SQLCODE is "-964", 查询其含义
transition log full, 就是说active log full
注意，这里的log是指apply在target数据库应用数据更新的日志，所以就是目标数据库log full。
往往容易搞混，很多人去查apply目前机器上的日志
当然有另外的情况，稍后说明
查询该SET的具体信息
根据TARGET_SERVER和TARGET_ALIAS可以通过catalog查询目标机器的node和具体数据库，这里省略
在target db查看数据库的配置和相关的snapshot：
为何发生这种问题呢？
尝试查看问题表（REPORT_REPOSITORY）结构，连到目标数据库查看：
留意到有BLOB类型，看来使用大量空间的就是它了。
查看apply tail 表，看是否有对应的错误：
奇怪的是，status一直是好的（0和2），表示apply正在尝试追赶数据
尝试手动重启APPLY，尝试再同步该问题表，并观察以上各个参数
重启途中尝试更新MAX_SYNCH_MINUTES，从10分钟改成5分钟，希望能强制apply提交数据，避免-964重复发生
查看apply tail表：
这时候发现apply运行的目录马上产生大量的LOB文件
这时候，可以预见问题的发生了，如果LOB也是写log的话，目标数据库只有8G日志空间，就是LOB这个列，也远远不够用
（一般生产数据库，都是保持默认的日志写策略。同时，没有人会这么热心给你一个个列去优化，除非出了问题）
在这时观察目标数据库的日志使用情况：
再看看snapshot得到的其他信息：
这时候，可以预见apply log将出现-964了：
再看看apply tail 表
居然正常！这个也是L2也不能理解的地方。
SYNCHTIME当然也不会正常
################################一天过去了###############################################
一天后再看：
apply log:
时间间隔如此有规律，可以想象每次都是把log space吃完就返回错误
再看看apply tail表：
与apply log时间吻合
结论：
经过与L2的讨论之后，判定应用在 2011-10-06-16.59.35.330525 这个时间点对问题表有大批量的操作
同时，在这个期间，UOW没有得到有效、频繁的commit
导致单个UOW过大，从而导致目标数据库的活动日志空间撑满
解决方案：
当然不能为了单个UOW而增加30G的日志空间。
更不能姑息程序员的懒惰！（出了故障还说是5*12的支持）
PS：
之前说过大量的数据，特别是LOB数据，会导致目标数据库的日志空间撑满。
而在apply得到capture的数据后，apply则会把LOB数据以文件的方式存放在apply所在的目录。
所以要确保这个目录空间足够大。
PPS：
所有的DBA都有一个共识，就是无论你使用的是oracle还是DB2，还是什么RDBMS，反正多commit，对大家都好
PPPS：
还是老话，看上去以上的过程顺理成章，其实经过了整整10个小时的尝试和观察。
不过在这里做了梳理（也用了差不多2个小时），希望日后方便查看。
apply运行在非target数据库上面
apply instance：dpapsort@g03edzrdb001 target instance：a3insort@g03edzrdb002
大概思路：
1.发现有问题的SET
2.查看apply log
3.查看相对应的source,target,table
4.查看snapshot
首先是以下SET出现问题，数据没有得到及时更新：
dpapsort@g03edzrdb001:/home/dpapsort/torun
=> db2 "select activate, SET_NAME, STATUS, LASTSUCCESS, SYNCHTIME from asn.IBMSNAP_SUBS_SET where status=1"
ACTIVATE SET_NAME STATUS LASTSUCCESS SYNCHTIME
-------- ------------------ ------ -------------------------- --------------------------
1 RPTREP2WEB 1 2011-10-06-16.59.35.330525 2011-10-06-16.56.09.000000
dpapsort@g03edzrdb001:/home/dpapsort/torun
=> date
Fri Oct 7 19:48:46 MDT 2011
查询information center asn.IBMSNAP_SUBS_SET 表中的status为1的意思
引用
-1
The replication failed. The Apply program backed out the entire set of rows it had applied, and no data was committed. If the startup parameter SQLERRCONTINUE = Y, the SQLSTATE that is returned to the Apply program during the last cycle is not one of the acceptable errors you indicated in the input file for SQLERRCONTINUE (apply qualifier.SQS).
0
The Apply program processed the subscription set successfully. If the startup parameter SQLERRCONTINUE = Y, the Apply program did not encounter any SQL errors that you indicated for the SQLERRCONTINUE startup parameter (in apply_qualifier.SQS) and did not reject any rows.
2
The Apply program is processing the subscription set in multiple cycles. It successfully processed a single logical subscription that was divided according to the MAX_SYNCH_MINUTES control column.
没有1的解释，询问L2，解释道是正在等待数据传送完成，类似于2
按照习惯，先检查apply的输出日志：
2011-10-07-17.24.48.797176 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY".
显示SQLCODE is "-964", 查询其含义
=> db2 ? sql964 SQL0964C The transaction log for the database is full.
transition log full, 就是说active log full
注意，这里的log是指apply在target数据库应用数据更新的日志，所以就是目标数据库log full。
往往容易搞混，很多人去查apply目前机器上的日志
当然有另外的情况，稍后说明
查询该SET的具体信息
dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 "select * from asn.IBMSNAP_SUBS_SET where SET_NAME='RPTREP2WEB'" APPLY_QUAL SET_NAME SET_TYPE WHOS_ON_FIRST ACTIVATE SOURCE_SERVER SOURCE_ALIAS TARGET_SERVER TARGET_ALIAS STATUS LASTRUN REFRESH_TYPE SLEEP_MINUTES EVENT_NAME LASTSUCCESS SYNCHPOINT SYNCHTIME CAPTURE_SCHEMA TGT_CAPTURE_SCHEMA FEDERATED_SRC_SRVR FEDERATED_TGT_SRVR JRN_LIB JRN_NAME OPTION_FLAGS COMMIT_COUNT MAX_SYNCH_MINUTES AUX_STMTS ARCH_LEVEL ------------------ ------------------ -------- ------------- -------- ------------------ ------------ ------------------ ------------ ------ -------------------------- ------------ ------------- ------------------ -------------------------- ----------------------- -------------------------- ------------------------------ ------------------------------ ------------------ ------------------ ---------- ---------- ------------ ------------ ----------------- --------- ---------- RPTAPPLY2 RPTREP2WEB R S 1 SRTSTG31 SRTSTG31 SORTPW31 SORTPW31 -1 2011-10-09-00.48.42.566513 R 5 - 2011-10-06-16.59.35.330525 x'4E8E3209000000040000' 2011-10-06-16.56.09.000000 ASN - - - - - TNNN - 5 0 0801
根据TARGET_SERVER和TARGET_ALIAS可以通过catalog查询目标机器的node和具体数据库，这里省略
在target db查看数据库的配置和相关的snapshot：
a3insort@g03edzrdb002:/home/a3insort => db2 get db cfg |grep -i log Log retain for recovery status = RECOVERY User exit for logging status = YES Catalog cache size (4KB) (CATALOGCACHE_SZ) = (MAXAPPLS*5) Log buffer size (4KB) (LOGBUFSZ) = 8 Log file size (4KB) (LOGFILSIZ) = 8196 Number of primary log files (LOGPRIMARY) = 56 Number of secondary log files (LOGSECOND) = 200 --这里的log空间设置不小了，共有（56+200）*8196*4k=8G空间 a3insort@g03edzrdb002:/home/a3insort => db2 get snapshot for all on SORTPW31 > snapshot.guoyanxi a3insort@g03edzrdb002:/home/a3insort => grep -i ava snapshot.guoyanxi Log space available to the database (Bytes)= 8545509551 --看到实际空闲的也有7.9G
为何发生这种问题呢？
尝试查看问题表（REPORT_REPOSITORY）结构，连到目标数据库查看：
a3insort@g03edzrdb002:/home/a3insort
=> db2 connect to SORTPW31
Database Connection Information
Database server = DB2/LINUXZ64 9.5.6
SQL authorization ID = A3INSORT
Local database alias = SORTPW31
a3insort@g03edzrdb002:/home/a3insort
=> db2 list tables for all |grep -i REPORT_REPOSITORY
REPORT_REPOSITORY SORT T 2005-09-06-13.38.33.588317
REPORT_REPOSITORY_NEW SORT T 2005-09-10-16.51.12.699525
a3insort@g03edzrdb002:/home/a3insort
=> db2 describe table SORT.REPORT_REPOSITORY
Data type Column
Column name schema Data type name Length Scale Nulls
------------------------------- --------- ------------------- ---------- ----- ------
PUBLISH_TS SYSIBM TIMESTAMP 10 0 No
SEQUENCE_ID SYSIBM CHARACTER 3 0 No
REPORT_ID SYSIBM CHARACTER 30 0 No
REPORT_NAME SYSIBM VARCHAR 512 0 Yes
REPORT SYSIBM BLOB 62914560 0 No
5 record(s) selected.
留意到有BLOB类型，看来使用大量空间的就是它了。
查看apply tail 表，看是否有对应的错误：
dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 "select whos_on_first concat set_name,status,SQLCODE,SQLSTATE,lastrun,full_refresh,set_inserted,set_updated,set_deleted,set_reworked from asn.ibmsnap_applytrail where APPLY_QUAL='RPTAPPLY2' order by lastrun desc fetch first 30 rows only" < 1 STATUS SQLCODE SQLSTATE LASTRUN FULL_REFRESH SET_INSERTED SET_UPDATED SET_DELETED SET_REWORKED ------------------- ------ ----------- -------- -------------------------- ------------ ------------ ----------- ----------- ------------ SRPTREP2WEB 2 - - 2011-10-07-17.26.33.116850 - 56557 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-07-17.26.33.101000 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-17.26.33.060036 N 0 0 0 0 SRPTREP2WEB 2 - - 2011-10-07-14.34.22.673597 - 56477 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-07-11.42.11.645470 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-11.42.11.627289 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-07-08.34.54.296089 - 56516 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-07-08.34.54.285864 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-08.34.54.263251 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-07-05.30.35.934544 - 56559 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-07-05.30.35.911078 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-05.30.35.885605 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-07-01.58.42.982568 - 56451 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-07-01.58.42.971046 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-01.58.42.831020 N 0 0 0 0 SRPTREP2WEB -1 -911 40001 2011-10-07-00.13.11.902757 - 0 0 0 0 SRPTDEL2WEB 0 - - 2011-10-07-00.13.11.865380 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-00.13.11.763378 N 0 0 0 0 SRPTREP2WEB -1 -452 428A1 2011-10-06-21.19.25.525620 - 0 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-06-21.19.25.504677 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-06-21.19.24.942895 N 0 0 0 0 SRPTREP2WEB -1 -452 428A1 2011-10-06-20.04.51.612274 - 15078 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-06-20.04.51.597841 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-06-20.04.51.575335 N 0 0 0 0 SRPTREP2WEB 2 - - 2011-10-06-17.04.36.117466 - 56452 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-06-17.04.27.029707 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-06-17.04.18.935458 N 0 0 0 0 SRPTREP2WEB 0 - - 2011-10-06-16.59.35.843988 N 0 0 0 0 SRPTDEL2WEB 0 - - 2011-10-06-16.59.26.774660 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-06-16.59.18.619988 N 0 0 0 0
奇怪的是，status一直是好的（0和2），表示apply正在尝试追赶数据
尝试手动重启APPLY，尝试再同步该问题表，并观察以上各个参数
重启途中尝试更新MAX_SYNCH_MINUTES，从10分钟改成5分钟，希望能强制apply提交数据，避免-964重复发生
--启动时间约为机器的10-08 00:00 dpapsort@g03edzrdb001:/home/dpapsort/torun => date Fri Oct 7 23:57:12 MDT 2011 --停apply dpapsort@g03edzrdb001:/home/dpapsort/torun => nohup /home/a3insort/sqllib/bin/asnacmd apply_qual=RPTAPPLY2 control_server=SRTSTG31 stop & --update dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 "update ASN.IBMSNAP_SUBS_SET set MAX_SYNCH_MINUTES=5 where APPLY_QUAL='RPTAPPLY2'" DB20000I The SQL command completed successfully. dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 "select APPLY_QUAL ,SET_NAME ,STATUS ,LASTRUN ,MAX_SYNCH_MINUTES from ASN.IBMSNAP_SUBS_SET where APPLY_QUAL='RPTAPPLY2'" APPLY_QUAL SET_NAME STATUS LASTRUN MAX_SYNCH_MINUTES ------------------ ------------------ ------ -------------------------- ----------------- RPTAPPLY2 RPTDEF2WEB 0 2011-10-07-17.26.33.060036 5 RPTAPPLY2 RPTDEL2WEB 0 2011-10-07-17.26.33.101000 5 RPTAPPLY2 RPTREP2WEB 1 2011-10-07-17.26.33.116850 5 3 record(s) selected. --启动apply dpapsort@g03edzrdb001:/home/dpapsort/torun => nohup /home/a3insort/sqllib/bin/asnapply CONTROL_SERVER=SRTSTG31 APPLY_QUAL=RPTAPPLY2 APPLY_PATH="/home/dpapsort/torun" PWDFILE=asnpwd.aut inamsg=n &
查看apply tail表：
dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 "select whos_on_first concat set_name,status,SQLCODE,SQLSTATE,lastrun,full_refresh,set_inserted,set_updated,set_deleted,set_reworked from asn.ibmsnap_applytrail where >" 1 STATUS SQLCODE SQLSTATE LASTRUN FULL_REFRESH SET_INSERTED SET_UPDATED SET_DELETED SET_REWORKED ------------------- ------ ----------- -------- -------------------------- ------------ ------------ ----------- ----------- ------------ SRPTDEL2WEB 0 - - 2011-10-08-00.00.34.823373 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-00.00.34.809366 N 0 0 0 0 SRPTREP2WEB 2 - - 2011-10-07-17.26.33.116850 - 56557 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-07-17.26.33.101000 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-07-17.26.33.060036 N 0 0 0 0 --一切正常
这时候发现apply运行的目录马上产生大量的LOB文件
--查询10月8日产生的 dpapsort@g03edzrdb001:/home/dpapsort/torun => date Sat Oct 8 00:15:55 MDT 2011 dpapsort@g03edzrdb001:/home/dpapsort/torun => ls -atrl |grep LOB |grep "10-08" |wc -l 44952 --最终停止在8万6千个文件，共27G中 dpapsort@g03edzrdb001:/home/dpapsort/torun => ls -atrl |grep LOB |grep "10-08" |du -sm 27715 . dpapsort@g03edzrdb001:/home/dpapsort/torun => ls -atrl |grep LOB |grep "10-08" |wc -l 86588
这时候，可以预见问题的发生了，如果LOB也是写log的话，目标数据库只有8G日志空间，就是LOB这个列，也远远不够用
（一般生产数据库，都是保持默认的日志写策略。同时，没有人会这么热心给你一个个列去优化，除非出了问题）
在这时观察目标数据库的日志使用情况：
a3insort@g03edzrdb002:/home/a3insort => db2 get snapshot for all on SORTPW31 > snapshot.guoyanxi a3insort@g03edzrdb002:/home/a3insort => grep -i avail snapshot.guoyanxi Log space available to the database (Bytes)= 6748851456 --迅速减少 --最终 a3insort@g03edzrdb002:/home/a3insort => grep "Log space available to the database" snapshot.guoyanxi Log space available to the database (Bytes)= 33466620 You have new mail in /var/spool/mail/a3insort a3insort@g03edzrdb002:/home/a3insort => db2 get snapshot for all on SORTPW31 > snapshot.guoyanxi a3insort@g03edzrdb002:/home/a3insort => grep "Log space available to the database" snapshot.guoyanxi Log space available to the database (Bytes)= 8545958228 --UOW失败，全部rollback --经历约3小时，途中CPU,IO情况良好
再看看snapshot得到的其他信息：
a3insort@g03edzrdb002:/home/a3insort
=> db2 list application
Auth Id Application Appl. Application Id DB # of
Name Handle Name Agents
-------- -------------- ---------- -------------------------------------------------------------- -------- -----
SORTWAPP db2jcc_applica 46940 9.17.246.92.46156.111007170931 SORTPW31 1
DPSORTNE asnapply 19709 9.63.48.130.59173.111008064111 SORTPW31 1
SORTWAPP db2jcc_applica 29768 9.17.246.106.37012.111007105832 SORTPW31 1
SORTWAPP db2jcc_applica 33393 9.17.246.154.41820.111006125748 SORTPW31 1
DPCPSORT asncap 5814 *LOCAL.a3insort.111003050005 SORTPW31 1
DPCPSORT asncap 5794 *LOCAL.a3insort.111003050006 SORTPW31 1
SORTWAPP db2jcc_applica 11168 9.17.246.65.49996.110904033955 SORTPW31 1
DPCPSORT asncap 20957 *LOCAL.a3insort.111008070737 SORTPW31 1
DPCPSORT asncap 5825 *LOCAL.a3insort.111003050007 SORTPW31 1
SORTWAPP db2jcc_applica 45542 9.17.246.94.45198.111007163718 SORTPW31 1
DPAPSORT asnapply 7574 *LOCAL.a3insort.111003055906 SORTPW31 1
DPCPSORT asncap 5830 *LOCAL.a3insort.111003050004 SORTPW31 1
--asnapply使用的app id是19709
a3insort@g03edzrdb002:/home/a3insort
=> db2 get snapshot for application agentid 19709 > app.snap.guoyanxi
UOW log space used (Bytes) = 1710859471 --大量的log space被占用
Previous UOW completion timestamp = 10/08/2011 00:41:11.575385
Elapsed time of last completed uow (sec.ms)= 0.002934
UOW start timestamp = 10/08/2011 00:41:11.575846
--CPU时间
Total User CPU Time used by agent (s) = 438.752110
Total System CPU Time used by agent (s) = 0.000000
Host execution elapsed time = 1557.234473
--可以看到该死的程序员居然不commit!
Number of SQL requests since last commit = 102113
Commit statements = 1
这时候，可以预见apply log将出现-964了：
2011-10-08-02.54.29.936390 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY".
再看看apply tail 表
dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 select whos_on_first concat set_name,status,SQLCODE,SQLSTATE,lastrun,full_refresh,set_inserted,set_updated,set_deleted,set_reworked from asn.ibmsnap_applytrail where > 1 STATUS SQLCODE SQLSTATE LASTRUN FULL_REFRESH SET_INSERTED SET_UPDATED SET_DELETED SET_REWORKED ------------------- ------ ----------- -------- -------------------------- ------------ ------------ ----------- ----------- ------------ SRPTDEL2WEB 0 - - 2011-10-08-02.56.07.347312 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-02.56.07.329110 N 0 0 0 0 SRPTREP2WEB 2 - - 2011-10-08-00.00.34.832285 - 56626 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-00.00.34.823373 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-00.00.34.809366 N 0 0 0 0
居然正常！这个也是L2也不能理解的地方。
SYNCHTIME当然也不会正常
dpapsort@g03edzrdb001:/home/dpapsort/torun
=> db2 "select activate, SET_NAME, STATUS, LASTSUCCESS, SYNCHTIME from asn.IBMSNAP_SUBS_SET where status=1"
ACTIVATE SET_NAME STATUS LASTSUCCESS SYNCHTIME
-------- ------------------ ------ -------------------------- --------------------------
1 RPTREP2WEB 1 2011-10-06-16.59.35.330525 2011-10-06-16.56.09.000000
################################一天过去了###############################################
一天后再看：
apply log:
2011-10-08-02.54.29.936390 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-08-06.01.09.191652 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-08-09.12.04.227249 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-08-12.11.30.560552 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-08-15.16.24.835641 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-08-18.19.40.147862 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-08-21.15.56.355534 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". 2011-10-09-00.47.02.106943 <CPDOINS(C9/02)> ASN1001E APPLY "RPTAPPLY2" : "WorkerThread". The Apply program encountered an SQL error. The ERRCODE is "C90102". The SQLSTATE is "57011". The SQLCODE is "-964". The SQLERRM is "". The SQLERRP is "SQLRI039". The server name is "". The table name is "REPORT_REPOSITORY". --一直失败，每次相隔约3个小时
时间间隔如此有规律，可以想象每次都是把log space吃完就返回错误
再看看apply tail表：
dpapsort@g03edzrdb001:/home/dpapsort/torun => db2 select whos_on_first concat set_name,status,SQLCODE,SQLSTATE,lastrun,full_refresh,set_inserted,set_updated,set_deleted,set_reworked from asn.ibmsnap_applytrail where APPLY_QUAL= 1 STATUS SQLCODE SQLSTATE LASTRUN FULL_REFRESH SET_INSERTED SET_UPDATED SET_DELETED SET_REWORKED ------------------- ------ ----------- -------- -------------------------- ------------ ------------ ----------- ----------- ------------ SRPTREP2WEB -1 - - 2011-10-09-00.48.42.566513 - 56268 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-09-00.48.42.551125 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-09-00.48.42.526091 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-08-21.23.31.937023 - 56626 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-21.23.31.927683 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-21.23.31.906231 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-08-18.21.21.394640 - 56559 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-18.21.21.379054 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-18.21.21.354030 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-08-15.18.01.192603 - 56551 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-15.18.01.179879 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-15.18.01.161890 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-08-12.13.11.878571 - 56408 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-12.13.11.863796 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-12.13.11.838547 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-08-09.13.37.238808 - 56559 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-09.13.37.225786 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-09.13.37.160247 N 0 0 0 0 SRPTREP2WEB -1 - - 2011-10-08-06.02.56.674972 - 56547 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-06.02.56.662221 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-06.02.56.643343 N 0 0 0 0 SRPTREP2WEB 2 - - 2011-10-08-02.56.07.362930 - 56557 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-02.56.07.347312 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-02.56.07.329110 N 0 0 0 0 SRPTREP2WEB 2 - - 2011-10-08-00.00.34.832285 - 56626 0 86483 0 SRPTDEL2WEB 0 - - 2011-10-08-00.00.34.823373 N 0 0 0 0 SRPTDEF2WEB 0 - - 2011-10-08-00.00.34.809366 N 0 0 0 0
与apply log时间吻合
结论：
经过与L2的讨论之后，判定应用在 2011-10-06-16.59.35.330525 这个时间点对问题表有大批量的操作
同时，在这个期间，UOW没有得到有效、频繁的commit
导致单个UOW过大，从而导致目标数据库的活动日志空间撑满
解决方案：
当然不能为了单个UOW而增加30G的日志空间。
更不能姑息程序员的懒惰！（出了故障还说是5*12的支持）
PS：
之前说过大量的数据，特别是LOB数据，会导致目标数据库的日志空间撑满。
而在apply得到capture的数据后，apply则会把LOB数据以文件的方式存放在apply所在的目录。
所以要确保这个目录空间足够大。
PPS：
所有的DBA都有一个共识，就是无论你使用的是oracle还是DB2，还是什么RDBMS，反正多commit，对大家都好
PPPS：
还是老话，看上去以上的过程顺理成章，其实经过了整整10个小时的尝试和观察。
不过在这里做了梳理（也用了差不多2个小时），希望日后方便查看。
分享到：
发表评论
-
db2 redirect restore
2012-08-17 15:57 2823same machine online backup incl ... -
DB2删除冗余备份
2011-12-21 18:59 4374对于装在虚拟机上面的测试机，归档日志等备份文件往往会因为疏于管 ... -
DB2 DPF 测试环境搭建
2011-11-23 17:20 5985克服了无数小问题后，终于搭建起来测试环境了 总的教程： htt ... -
DB2 日期 时间
2011-10-27 13:46 6628/****************************** ... -
搭建简单的DB2 HADR
2011-09-17 09:52 2123简单的HADR，只用一台虚拟机，两个实例间搭建。工作量不大，一 ... -
TSM RC=0x0000006A=106
2011-09-02 23:40 1442DB2归档日志没有被TSM备份 a3inr2fb@b03c ... -
db2ilist不显示实例列表
2011-08-08 18:29 2861https://www-304.ibm.com/support ... -
更改DB2实例的fence用户的两种方法
2011-07-27 21:23 4842碰到有个DB2的实例居然实例用户和fence用户是一样的 做了 ... -
HWM小测
2011-07-12 17:16 0HWM是oracle和DB2都有的概念，概念很简单，测试一下 ... -
DB2 SMS tablespace 容器大小不等测试
2011-06-28 21:53 2763看到官方文档有这句： 引用 When all space in ... -
db2查找执行次数最多的sql
2011-06-23 21:50 3591用此方法同时能够得到cost最大的语句 --首先抓取sn ... -
migrate from win to linux(遇到的问题)
2011-06-15 21:30 2821之前写过一篇在自己虚拟机简单测试的步骤 http://guoy ... -
db2 错误查询
2011-06-14 19:00 2531关键字：DB2 SQLCODE 查看 在DB2数据库中执行S ... -
db2 恢复误删表
2011-06-03 19:02 5300oracle如果误删了表，可以很方便的flash back 最 ... -
migrate from win to linux(简单版)
2011-05-24 16:13 2178本文讲述最简单的从windows到linux的db2迁移 1. ... -
安装db2 fix pack
2011-04-20 21:45 41791.停数据库 [root@localhost univer ... -
db2 express-c 不支持fixpack
2011-04-20 20:31 1416要真的升级，就只能重装db2软件了 [root@local ... -
linux下unstalling db2
2011-04-20 17:26 1758由于enterprise版本又到期了，又不想改系统日期，所以重 ... -
被问到的问题，导出DDL（DB2）
2011-04-15 20:41 906Generate the DDL statements for ... -
与数据库同时建立的文件
2011-03-19 16:27 1061db2rhist.asc This file cont ...
相关推荐
全国大学生智能汽车竞赛自2006年起，由教育部高等教育司委托高等学校自动化类教学指导委员会举办，旨在加强学生实践、创新能力和培养团队精神的一项创意性科技竞赛。该竞赛至今已成功举办多届，吸引了众多高校学生的积极参与，此文件为智能车竞赛介绍
字卡v4.3.4 原版 三种UI+关键字卡控制+支持获取用户信息+支持强制关注 集卡模块从一开始的版本到助力版本再到现在的新规则版本。 集卡模块难度主要在于 如何控制各种不同的字卡组合 被粉丝集齐的数量。 如果不控制那么一定会出现超过数量的粉丝集到指定的字卡组合，造成奖品不够的混乱，如果大奖价值高的话，超过数量的粉丝集到大奖后，就造成商家的活动费用超支了。我们冥思苦想如何才能限制集到指定字卡组合的粉丝数，后我们想到了和支付宝一样的选一张关键字卡来进行规则设置的方式来进行限制，根据奖品所需的关键字卡数，设定规则就可以控制每种奖品所需字卡组合被粉丝集到的数量，规则可以在活动进行中根据需要进行修改，活动规则灵活度高。新版的集卡规则，在此次政府发布号的活动中经受了考验，集到指定字卡组合的粉丝没有超出规则限制。有了这个规则限制后，您无需盯着活动，建好活动后就无人值守让活动进行就行了，您只需要时不时来看下蹭蹭上涨的活动数据即可。 被封？ 无需担心，模块内置有防封功能，支持隐藏主域名，显示炮灰域名，保护活动安全进行。 活动准备？ 只需要您有一个认证服务号即可，支持订阅号借用认证服务号来做活动。如果您
出口设备线体程序详解：PLC通讯下的V90控制与开源FB284工艺对象实战指南,出口设备线体程序详解：PLC通讯与V90控制集成，工艺对象与FB284协同工作，开源学习V90控制技能,出口设备1200线体程序，多个plc走通讯，内部有多个v90,采用工艺对象与fb284 共同控制，功能快全部开源，能快速学会v90的控制 ,出口设备; 1200线体程序; PLC通讯; 多个V90; 工艺对象; FB284; 功能开源; V90控制。,V90工艺控制：开源功能快，快速掌握1200线体程序与PLC通讯
基于Arduino与DAC8031的心电信号模拟器资料：心电信号与正弦波的双重输出应用方案,Arduino与DAC8031心电信号模拟器：生成心电信号与正弦波输出功能详解,基于arduino +DAC8031的心电信号模拟器资料，可输出心电信号，和正弦波 ,基于Arduino;DAC8031;心电信号模拟器;输出心电信号;正弦波输出;模拟器资料,基于Arduino与DAC8031的心电信号模拟器：输出心电与正弦波
MATLAB口罩检测的基本流程 图像采集：通过摄像头或其他图像采集设备获取包含面部的图像。 图像预处理：对采集到的图像进行灰度化、去噪、直方图均衡化等预处理操作，以提高图像质量，便于后续的人脸检测和口罩检测。 人脸检测：利用Haar特征、LBP特征等经典方法或深度学习模型（如MTCNN、FaceBoxes等）在预处理后的图像中定位人脸区域。 口罩检测：在检测到的人脸区域内，进一步分析是否佩戴口罩。这可以通过检测口罩的边缘、纹理等特征，或使用已经训练好的口罩检测模型来实现。 结果输出：将检测结果以可视化方式展示，如在图像上标注人脸和口罩区域，或输出文字提示是否佩戴口罩。
1、文件内容：kernel-debug-devel-3.10.0-1160.119.1.el7.rpm以及相关依赖 2、文件形式：tar.gz压缩包 3、安装指令： #Step1、解压 tar -zxvf /mnt/data/output/kernel-debug-devel-3.10.0-1160.119.1.el7.tar.gz #Step2、进入解压后的目录，执行安装 sudo rpm -ivh *.rpm 4、更多资源/技术支持：公众号禅静编程坊
该文档提供了一个关于供应链管理系统开发的详细指南，重点介绍了项目安排、技术实现和框架搭建的相关内容。 文档分为以下几个关键部分： 项目安排：主要步骤包括搭建框架（1天），基础数据模块和权限管理（4天），以及应收应付和销售管理（5天）。 供应链概念：供应链系统的核心流程是通过采购商品放入仓库，并在销售时从仓库提取商品，涉及三个主要订单：采购订单、销售订单和调拨订单。 大数据的应用：介绍了数据挖掘、ETL（数据抽取）和BI（商业智能）在供应链管理中的应用。 技术实现：讲述了DAO（数据访问对象）的重用、服务层的重用、以及前端JS的继承机制、jQuery插件开发等技术细节。 系统框架搭建：包括Maven环境的配置、Web工程的创建、持久化类和映射文件的编写，以及Spring配置文件的实现。 DAO的需求和功能：供应链管理系统的各个模块都涉及分页查询、条件查询、删除、增加、修改操作等需求。 泛型的应用：通过示例说明了在Java语言中如何使用泛型来实现模块化和可扩展性。 文档非常技术导向，适合开发人员参考，用于构建供应链管理系统的架构和功能模块。
1.版本：matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
C#与VB实现欧姆龙PLC的Fins TCP通信案例源码：调用动态链接库进行数据读写，定时器与计数器数据区的简洁读写操作示例,C#与VB实现欧姆龙PLC的Fins TCP通信案例源码：调用动态链接库进行读写操作，涵盖定时器计数器数据区学习案例,C#欧姆龙plc Fins Tcp通信案例上位机源码，有c#和VB的Demo，c#上位机和欧姆龙plc通讯案例源码,调用动态链接库，可以实现上位机的数据连接，可以简单实现D区W区定时器计数器等数据区的读写，是一个非常好的学习案例 ,C#; 欧姆龙PLC; Fins Tcp通信; 上位机源码; 动态链接库; 数据连接; D区W区读写; 定时器计数器; 学习案例,C#实现欧姆龙PLC Fins Tcp通信上位机源码，读写数据区高效学习案例
可调谐石墨烯超材料吸收体的FDTD仿真模拟研究报告：吸收光谱的化学势调节策略与仿真源文件解析,可调谐石墨烯超材料吸收体：化学势调节光谱的FDTD仿真模拟研究,可调谐石墨烯超材料吸收体FDTD仿真模拟 【案例内容】该案例提供了一种可调谐石墨烯超材料吸收体，其吸收光谱可以通过改变施加于石墨烯的化学势来进行调节。 【案例文件】仿真源文件 ,可调谐石墨烯超材料吸收体; FDTD仿真模拟; 化学势调节; 仿真源文件,石墨烯超材料吸收体：FDTD仿真调节吸收光谱案例解析
RBF神经网络控制仿真-第二版
松下PLC与威纶通触摸屏转盘设备控制：FPWINPRO7与EBPRO智能编程与宏指令应用,松下PLC与威纶通触摸屏转盘设备控制解决方案：FPWINPRO7与EBPRO协同工作，实现多工位转盘加工与IEC编程模式控制,松下PLC+威纶通触摸屏的转盘设备 松下PLC工程使用程序版本为FPWINPRO7 7.6.0.0版本 威纶通HMI工程使用程序版本为EBPRO 6.07.02.410S 1.多工位转盘加工控制。 2.国际标准IEC编程模式。 3.触摸屏宏指令应用控制。 ,松下PLC; 威纶通触摸屏; 转盘设备控制; 多工位加工控制; IEC编程模式; 触摸屏宏指令应用,松下PLC与威纶通HMI联控的转盘设备控制程序解析
基于循环神经网络（RNN）的多输入单输出预测模型（适用于时间序列预测与回归分析，需Matlab 2021及以上版本）,基于循环神经网络（RNN）的多输入单输出预测模型（matlab版本2021+），真实值与预测值对比，多种评价指标与线性拟合展示。,RNN预测模型做多输入单输出预测模型，直接替数据就可以用。 程序语言是matlab，需求最低版本为2021及以上。 程序可以出真实值和预测值对比图，线性拟合图，可打印多种评价指标。 PS:以下效果图为测试数据的效果图，主要目的是为了显示程序运行可以出的结果图，具体预测效果以个人的具体数据为准。 2.由于每个人的数据都是独一无二的，因此无法做到可以任何人的数据直接替就可以得到自己满意的效果。 这段程序主要是一个基于循环神经网络（RNN）的预测模型。它的应用领域可以是时间序列预测、回归分析等。下面我将对程序的运行过程进行详细解释和分析。 首先，程序开始时清空环境变量、关闭图窗、清空变量和命令行。然后，通过xlsread函数导入数据，其中'数据的输入'和'数据的输出'是两个Excel文件的文件名。 接下来，程序对数据进行归一化处理。首先使用ma
1.版本：matlab2014/2019a/2024a 2.附赠案例数据可直接运行matlab程序。 3.代码特点：参数化编程、参数可方便更改、代码编程思路清晰、注释明细。 4.适用对象：计算机，电子信息工程、数学等专业的大学生课程设计、期末大作业和毕业设计。
旅游管理系统中的功能模块主要是实现管理员；首页、个人中心、用户管理、旅游方案管理、旅游购买管理、系统管理，用户；首页、个人中心、旅游方案管理、旅游购买管理、我的收藏管理。前台首页；首页、旅游方案、旅游资讯、个人中心、后台管理等功能。经过认真细致的研究，精心准备和规划，最后测试成功，系统可以正常使用。分析功能调整与旅游管理系统实现的实际需求相结合，讨论了Java开发旅游管理系统的使用。 从上面的描述中可以基本可以实现软件的功能： 1、开发实现旅游管理系统的整个系统程序； 2、管理员；首页、个人中心、用户管理、旅游方案管理、旅游购买管理、系统管理等。 3、用户：首页、个人中心、旅游方案管理、旅游购买管理、我的收藏管理。 4、前台首页：首页、旅游方案、旅游资讯、个人中心、后台管理等相应操作； 5、基础数据管理：实现系统基本信息的添加、修改及删除等操作，并且根据需求进行交流查看及回复相应操作。
Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪：基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构的Simulink建模与MPPT最大功率点追踪：基于功率反馈的扰动观察法调整电压方向研究,Boost二级升压光伏并网结构，Simulink建模，MPPT最大功率点追踪，扰动观察法采用功率反馈方式，若ΔP>0，说明电压调整的方向正确，可以继续按原方向进行“干扰”；若ΔP<0，说明电压调整的方向错误，需要对“干扰”的方向进行改变。 ,Boost升压;光伏并网结构;Simulink建模;MPPT最大功率点追踪;扰动观察法;功率反馈;电压调整方向。,光伏并网结构中Boost升压MPPT控制策略的Simulink建模与功率反馈扰动观察法
运行GUI版本，可二开
Deepseek相关主题资源及行业影响
WP Smush Pro 是一款专为 WordPress 网站设计的图像优化插件。 一、主要作用 图像压缩 它能够在不影响图像质量的前提下，大幅度减小图像文件的大小。例如，对于一些高分辨率的产品图片或者风景照片，它可以通过先进的压缩算法，去除图像中多余的数据。通常 JPEG 格式的图像经过压缩后，文件大小可以减少 40% – 70% 左右。这对于网站性能优化非常关键，因为较小的图像文件可以加快网站的加载速度。 该插件支持多种图像格式的压缩，包括 JPEG、PNG 和 GIF。对于 PNG 图像，它可以在保留透明度等关键特性的同时，有效地减小文件尺寸。对于 GIF 图像，也能在一定程度上优化文件大小，减少动画 GIF 的加载时间。 懒加载 WP Smush Pro 实现了图像懒加载功能。懒加载是一种延迟加载图像的技术，当用户滚动页面到包含图像的位置时，图像才会加载。这样可以避免一次性加载大量图像，尤其是在页面内容较多且包含许多图像的情况下。例如，在一个新闻网站的长文章页面，带有大量配图，懒加载可以让用户在浏览文章开头部分时，不需要等待所有图片加载，从而提高页面的初始加载速度，同时也能
Could not create share link. Missing file: C:\Users\xx\.conda\envs\omni\Lib\site-packages\gradio\frpc_windows_amd64_v0.3 1. Download this file: https://cdn-media.huggingface.co/frpc-gradio-0.3/frpc_windows_amd64.exe 2. Rename the downloaded file to: frpc_windows_amd64_v0.3 3. Move the file to this location: C:\Users\xx\.conda\envs\omni\Lib\site-packages\gradio