1024，搞点事

914fcc7ad57defa7868c3be1ca7fb4f5.jpg

首先祝各位IT行业从业者，1024节日快乐。本文将以戏谑的态度，写一些我干过或遇到的糗事或者听说过的一些牛事，先叠个甲，本文内容为演绎内容，如有撞车，纯属不幸。

全表update

第一件是我自己干的糗事，这是发生在我某个前东家，记得是一个错误数据变更的需求，也不知道当天是什么情况脑抽了，在写update语句的时候没有写where条件，还直接在Navicat上点了执行。当我反应过来的时候已经跑了几秒了，立即点击了终止。

在这件事情上好的是：一是表足够大，十几秒跑不完全表更新；二是数据库没有开启自动提交；三是执行终止及时，没有涉及造成影响的锁表和回滚。因此结果算是不幸中的万幸，但还是被惊出了一身汗。从那以后我做任何操作的时候，都会严格多次确认才会动手。

主机名写错

其实这不算是我做的，是另一个主机工程师干的傻事。背景是一套RAC需要增加一个节点，由于这套RAC维护主责不在我这，主机配置就由另一个主机工程师配置，我协助执行GI和DB层面的节点添加操作。解决完各种参数配置问题和软件包问题后，GI的节点添加操作也算是正式开始了，但是到执行root.sh操作时，在执行clvufy的时候报错了，多次执行未果，由于割接时间有限且对原有节点运行无影响，因此放弃了操作。

在第二天对所有操作日志检查和操作复检后最终发现，新增节点的主机名配置和/etc/hosts中的不一致，简单来说就是：

主机名配置：  xxx_xxx_xxx_04
/etc/hosts:  xxx-xxx-xxx-04

使用/etc/hosts的配置添加节点，但是实际操作过程中又调用了本机主机名导致了无法通过/etc/hosts正确解析主机，导致clvufy执行失败。

养蛊

在某次技术沟通中，听到被人讲的，也不知道是不是真的。在某些客户那，如果发现了小问题或者隐患（且方便甩锅的），是不会在第一时间反馈并处理的，一般会等这些问题变得比较大的时候，再去以救世主的拯救客户，转身离去，看起来还挺帅的。当然如果遇到不方便甩锅的但需要处理的小问题或者隐患，偶尔也会听到说，这个问题太简单了，找别人处理吧。

说真的，我以前也提到过是否只有在处理严重故障才能凸显技术价值，我认为是不是的。包括在和首席的交流中，最让我惊讶的是首席公司是以稳定来评判IT工作的，比如每年故障不超过3次就不会扣绩效，如果没出问题还有嘉奖（很难）。但是在很多场合的实际操作中，稳定代表着平淡，平淡也就是不出彩，到这里也就不用我多说了。

大表不分区

在Oracle数据库中，统计信息相关的自动维护任务的理论大家其实都很清楚，但是当表足够大且没有分区的时候，数据库就会因为可能会为了避免统计信息收集因时间过久或资源消耗过大而跳过这些大表。统计信息长期不更新带来性能劣化的可能性，对数据库的影响还是蛮大的，最近我这里也因为这个问题出现过好几次突发的性能问题（好在都是Exadata，表象没那么明显）。当然这也是我日常优化相关数据库技术支持工作不到位，需要加强的地方。 解决这一问题方法无外乎以下几种方案：

• 未分区大表变更为分区表，这需要考虑实现的方式方法是否优雅
• 对于Oracle 19c之后的版本，考虑开启实时统计信息更新功能
• 在业务非高峰期，用合理的方式更新统计信息
• …

总结

1024，祝广大IT从业者节日快乐。 老规矩，不知道写了些啥。