业务流.常见问题.表#TM_BF_INSTENTRYALL#中读取的数据,出现重复主键(归档并发)
【场景】业务流常见错误,上查、下查、全流程跟踪、下推保存报错,错误信息
![image.webp](/download/010066abb8ab00154fc9b11287d83e96281b.webp)
【可能原因】业务流程归档到文件异常,目前原因暂不确定;出现该异常后,应该是出现一大批数据都出问题,目前可通过工具修复
【说明】由于涉及数据修复,建议如果是手工修复的话,把整篇文章读明白再做处理,不然数据出问题的话很难调整
【工具部署】
<0>工具文件目录
![image.webp](/download/0100455c527e8710407690aa2c70a4bb2ffb.webp)
<1>表单部署,将dym和dymx文件导入到系统
![Image_20230117111222.webp](/download/0100d646924f4ea345f1a924896e62fe32bf.webp)
<2>表单发布,将发布脚本导入可默认发布到系统管理-其他,或者可自行发布;
![Image_20230117111544.webp](/download/0100a07b1a57c1444a359525e13113c820fb.webp)
<3>插件部署,将Tmp.BusinessFlow.Tool.dll放到应用服务器下(一般的,新增插件应该会默认生效,不需重启)
![Image_20230117120059.webp](/download/0100948a160850b847a487dee4d6150bd5f0.webp)
【工具使用案例】
<0>先确认是否是归档问题
```sql
select fbackuptime,min(flogid) as minId,max(flogid) as maxId from t_bf_instarchivelog group by fbackuptime
order by fbackuptime
```
一般的归档服务不会并发,内码应该是不会在一个批次中交叉
![Image_20230117121059.webp](/download/01001b3a9d7609d14488838b42045948283d.webp)
放到excel中,比对内码是否交叉,用当前最小值减上一行最大值
![Image_20230117122001.webp](/download/01004f1c23a74aa84d7f8167af21e035e5f1.webp)
通过筛选工具,查找是否存在为负数的,存在则代表出现交叉,如下图所示
![Image_20230117122105.webp](/download/010077858f1ed2b743c984ffc7074d6c1c0d.webp)
<1>本案只解决<0>这类场景的问题,针对<0>的数据,找到两个重复的时间,并定义其区间
定义两个查询区间,分别只查询这一批次的数据,一般的可使用(秒)区间,针对并发冲突过快的可使用毫秒区间
本例中冲突时间为
2022/11/09 00:00:00.923
2022/11/09 00:00:02.487
<2>工具操作步骤
a)根据<1>得到的时间,计算两个时间区间用作查询,确保,查询的数据是单独的批次
打开修复工具,填入批次的时间区间
![Image_20230117134320.webp](/download/0100a678f31b5cd44c6d9a0a7a3bc3ce66a6.webp)
```sql
--查询批次 2022/11/09 00:00:00.923
SELECT FFILEID FROM T_BF_ARCHIVEFILES WHERE FCREATETIME >= '2022/11/09 00:00:00' AND FCREATETIME<= '2022/11/09 00:00:01'
--查询批次 2022/11/09 00:00:02.487
SELECT FFILEID FROM T_BF_ARCHIVEFILES WHERE FCREATETIME >= '2022/11/09 00:00:02' AND FCREATETIME<= '2022/11/09 00:00:03'
```
![Image_20230117134411.webp](/download/01005058ff40b5644677b906537e4ab6004c.webp)
<2>分别查询两次,把查询的结果导入到页签【比对文件内码】,点击比对文件检查是否重复,检查比对重复结果
![Image_20230117140808.webp](/download/01008b1850e4324546268c90a0a0dff977d7.webp)
<3>如果是第一次运行,可以借助此步骤验证,确认数据是否重复
![Image_20230117140928.webp](/download/010001856845a4a1437891b4e78a7f584679.webp)
如果要比对真实的文件内容,可通过gzip->xml格式化,提取真实的文件数据
![1673935861867.webp](/download/0100e87016cd29eb4ff9adb2181a55016d25.webp)
![Image_20230117141230.webp](/download/01003e81429aab0f47c9a7c233655b3f5dda.webp)
<4>点击导出去除脏数据脚本,生成修复sql;建议在系统空闲时,公有云的提运维单部署,私有云的在数据库执行
脚本逻辑:创建备份表-》备份脏数据-》删除脏数据
注意1:由于备份脏数据的脚本的备份逻辑是没有索引的(select * from t_Bf_InstArchiveLog where FFILEID = XXX),所以如果这个表数据很多的话运行会非常慢(遇到过一个客户执行1个小时)
注意2:脚本中仅针对有关联的文件的脏数据做处理,部分脏数据没有关联单据,不受影响不做处理
注意3:脚本中若有todo的,则需要手工修复,脚本仅能在脚本标注
注意4:建议使用时小时间作为批次1,大时间作为批次2,即使生成重复也不会导致两个数据均被删除,仅仅删除大时间的批次
![Image_20230117142119.webp](/download/01002b473906700b49f4bab2fac04c9fa031.webp)
【说明】
<1>第一版组件仅处理文件完全一致的逻辑,当生成的内部文件存在顺序打乱时第一版无效;建议使用第二版
<2>当t_bf_instarchivelog 表过大时,由于备份逻辑使用ffileid关联,没有索引,因此数据量较大时会出现修复脚本执行1个小时,
建议先在空闲时增加以下索引并重建索引优化,而后在进行数据修复
```sql
--ksql
IF NOT EXISTS (SELECT 1 FROM KSQL_INDEXES WHERE KSQL_INDNAME = 'IDX_BF_INSTARCHIVELOG_FFILEID') CREATE INDEX IDX_BF_INSTARCHIVELOG_FFILEID ON T_BF_INSTARCHIVELOG ( FFILEID );
--sqlserver
IF NOT EXISTS (SELECT 1 FROM (SELECT sysobjects.NAME AS TABLE_NAME, sysindexes.NAME AS INDEX_NAME FROM sysobjects INNER JOIN sysindexes ON sysindexes.ID = sysobjects.ID) AS KSQL_INDEXES WHERE INDEX_NAME = 'IDX_BF_INSTARCHIVELOG_FFILEID')
BEGIN
CREATE INDEX IDX_BF_INSTARCHIVELOG_FFILEID ON T_BF_INSTARCHIVELOG (FFILEID)
END
```
白忙活了,还是一样,不知道是哪个环节出了问题
业务流.常见问题.表#TM_BF_INSTENTRYALL#中读取的数据,出现重复主键(归档并发)
【场景】业务流常见错误,上查、下查、全流程跟踪、下推保存报错,错误信息![image.webp](/download/010066abb8ab00154fc9b11287d83e96281b...
点击下载文档
本文2024-09-16 18:32:53发表“云星空知识”栏目。
本文链接:https://wenku.my7c.com/article/kingdee-k3cloud-22865.html
您需要登录后才可以发表评论, 登录登录 或者 注册
最新文档
热门文章