以下是我删除客户16进制物理文件以及修复的全过程

1 丶故事的起因是什么呢,是因为客户觉得数据库一个小设置的问题,文件的小版本不要阿拉波数字,因为数据库的文件ID转编16进制,文档ID转编码之后指向物理文件的文件夹编号;

2丶问题就在这,简直恐怖,领导让备份一下物理文件再操作,其实这部分改的是数据库的数据,物理文件其实没有任何相关的操作;

3丶我如实备份了,但是工具自带的备份报错了,丢失了物理文件,但是数据的物理文件备份没开?????????

4丶当时我觉得问题不大,数据没了可以恢复嘛;;;;;;然后天就塌了,客户服务器重启了,数据恢复的文件所有的层级结构全丢了;只剩下光秃秃的文件,我拿什么去补?????????????

5丶然后天秀操作就开始了,因为文档ID对应的物理文件指向逻辑,那么我批量根据这个逻辑创建文件的层级,这个很简单

根据报错:查询到文件的名称,导出这些错误,然后excel分列一下,把关键的文件名称参数输出出来,然后批量生成查询语句,把数据库这些文件的文档ID找到导出,这样就具有了数据的文档ID参数

第二步,根据文档ID转16进制,批量把这批文档ID转换成物理文件的文件夹名字,也就是16进制物理文件夹的文件名

第三步,根据文件夹末尾的参数,批量把这批文件夹归类0-9 ,a-f,

第四步比较难,因为在PDM内,物理文件夹内没有模型数据那么是导不出来的,这个会影响后面的操作

那么第五步,就是创建一个空的三维模型,sldprt,asm,drw,然后识别这些文件的后缀名称,是哪个类型,把他作为参数,根据这个参数批量在创建的物理文件夹内复制进去,这个比较难代码逻辑比较多,当时也还行

第六步,把这个物理文件夹全部导入到客户的服务器内,再打开PDM,进行检出,那么就不会报错了

关键的一步来了,恢复的数据不仅层级丢了,数据也损坏了,天塌了,该死的重启服务器

剩下来的方案就是找客户的本地缓存,万幸的是,客户从来不删除缓存

找到报错的文件名称,批量生成PDM客户端视图层级,根据对应路径参数,生成的层级,把报错数据全部检出,然后把我们的层级数据替换进去

完美,当时后续还需要跟进