5月17日投产总结

5月17日投产总结

日常坑:long类型引发的血案

战狼让我从生产备份一份pctp用户表回来，我导出了一份直接把测试delete all了，然后导入，有个long类型不给插表：illegal use of long datatype。转来转去最后也就入了个字符串的，但里面的内容全没了。
于是想回退，闪回：
select* from pctp as of timestamp to_timestamp(to_date(‘2023-05-17 16:45:00’,‘yyyy-mm-dd hh24:mi:ss’))，闪回没问题，但是查表还是报同一个错；
最后查到是long列不能直接迁移到另一个包含long列的表，否则会报上述错误。可采用间接方式，构架一个中间表，对应原表的long列为clob；把原表数据先成功插入到中间表，再把中间表的数据插入到包含long列的表。
即：long——clob——long
即：create table 中间表(a clob)
insert into 中间表 (select s1,s2,to_lob(long1),to_lob(long2),s3 from 源表名)

最后不知怎么是这么结尾的：
alter table pctp_userlist enable row movement;
flashback table pctp to_timestamp(to_date(‘2023-05-17 16:45:00’,‘yyyy-mm-dd hh24:mi:ss’))

流平台

上周尝试发现sftpfile用户对当前目录没有写权限；这周一联系系统组处理，结果发现这个用户已经对这个home/data/etran/send有删除权限了。然而实际删不了，是因为当前目录是etran目录，当初启动etran节点、创建目录等都是随意用root、sysop等特权用户操作的，所以目录、文件夹都是管理员权限，sftpfile用户的删除权限无法对这些目录、文件生效。赵经理一把将整个send改成sftpfile的用户，里边所有东西就能用sftpfile删除了。但是，问题是这个etran节点是特权用户启动的，需要通过变更手段换成sftpfile用户启动，这样源源不断送过来的文件才是sftpfile的权限。

变更操作

1、上来ps-ef|grep etran，2、查找并停掉流平台对应的节点，3、切换sftpfile用户，4、在此用户下启动流平台的节点；这样，后续文件都是sftpfile的隶属了。

然而很简单的事情，也用了很多个小时

首先前人起了个非常坑的名字叫p_sz_sbob；测试环境也没这个节点，之前这个项目测试上都是人工拖进来文件做流平台入表的；配置文件只能看出来收发ip、端口等信息，也判断不了；此时只能通过生产的etran平台去搜ip，再看节点、收发目录，才知道哪个节点是流平台的。可是系统组下班了没人了。所幸排除法剩下蒙对了p_sz_sbob这个奇葩名字。
接着通过管理员进去sbob下边，停掉了节点；然后su-sftpfile进入其命令模式，再去启动etran。一顿操作猛如虎，一看etran原地杵。没文件入库。
咋回事呢？原来是sftpfile在sbob节点下并没有sh运行启动命令的权限，启动失败了。要先chown -R sftpfile：users/目录，赋予权限再启动。
这时候启动成功了，已经用了半个小时。

然后也不报错，也没运行结束，最后去拿下来批量服务器的日志，也没有任何蛛丝马迹，只有人工停止xxl的日志和启动xxl的日志，没有任何运行日志。

最后，怎么排查都没找到问题，去查了下目标表大小，count了一下好久没出来才发现不简单，最后有8亿条数。日期有索引，发现从2022年11月至今就没有成功执行过删除表数据的逻辑。本应该保留两天的表，硬生生保留了半年的数据。

然后企图跑删除的存过去清理，卡死。单独delete语句拎出来，卡死。想drop掉表重建，卡死。这里又快两个钟过去了。

然后⭐哥过来说了句，为什么不rename掉这张表，然后建立一张一样的表呢？结果瞬间就搞定了。后边复制的建立索引的句子提示索引名字重复了，我们去改旧表索引，卡死…最后不管旧的了，把新表搞好，流平台个人数据满血复活。留下一个尾巴就是为何去年迁移到linux后，这张表的数据一直没得到定时清理，从而导致insert语句性能越来越差，最后推动我们改bin文件的sqlloader入库，也入不动，才发现这个问题？

mis重启

大家为了重启留下来，缺都在打饥荒、王者、魔兽，真正十点多重启结束，各单位只验证了十分钟左右就结束了，又玩游戏到两点。我的信息网倒是两台门户、四台应用都无需跟随mis去重启。