业务流.常见问题.表#TM_BF_INSTENTRYALL#中读取的数据,出现重复主键(归档并发)

栏目:云星空知识作者:金蝶来源:金蝶云社区发布:2024-09-16浏览:1

业务流.常见问题.表#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 ```

业务流程——归档重复的数据修复工具.rar


白忙活了,还是一样,不知道是哪个环节出了问题

业务流.常见问题.表#TM_BF_INSTENTRYALL#中读取的数据,出现重复主键(归档并发)

【场景】业务流常见错误,上查、下查、全流程跟踪、下推保存报错,错误信息![image.webp](/download/010066abb8ab00154fc9b11287d83e96281b...
点击下载文档
确认删除?
回到顶部
客服QQ
  • 客服QQ点击这里给我发消息