刚要下班了，值班同事在群里发了一个告警提示，说是业务需要协助解决ORA-01625，某个模块的查询功能异常，一跑就报错，当时看了这个问题，我直觉是肯定是临时空间不足，加下就好了，因为刚到公司楼下，所以就在群里说了下“我回去处理下”，正好一个领导还没下班就主动提出就临时加了下空间，我们的工作环境还是十分和谐，领导相当nice. 出于习惯自己维护的库总要再看看，发现临时空间已经释放了，使用率几乎是0，所以想当然认为问题解决了。 晚上8:30值班同事又发出协助申请，还是那个问题。此时我就有些疑虑，这个系统之前从没有出过问题，今天反复报错临时表空间不足，到底是什么吃了这么多临时空间呢？找到业务联系电话，问了今天做了什么操作，那个模块什么功能导致的。业务的活法很“云淡风轻”，就是把业务表做个“备份”，就是将大表改名，再创建一个同名新表，注意这里是同名新表，然后将少量数据insert回同名新表，达到瘦表的目的，他们认为这样SQL性能会更好，也备份了数据。我隐约感到应该是执行计划走错了，既然这个故障可以很快复现，我就让业务重新跑那个SQL，经过监控发现temp120G的空间几分钟就被吃完了，而看到这个执行计划之后，问题很清楚了。
从 执行计划看，两个表走了笛卡尔，后面是一个sort操作，这就难怪temp空间很快被吃完。
那为什么Oracle会选择性能这样差的执行计划呢，我随后查了表的统计信息都是0条，问题已经很清楚了，因为用户表是新建，但是没有统计信息，表的nuw_rows是 0 ，Oracle认为我走笛卡尔积效率挺高的，成本很低，其实这些表里有200万左右的数据，此时问题很好解决了，随后收集了10%的统计，然后再看执行计划如下
此时Oracle选择了hash，此时对temp的消耗计划可以忽略了，然后我让业务再运行那条SQL，技术瞬间就完成了，为了安全期间，我将所有业务操作的表都收集了10%的统计，这个问题就算是解决了
给我的启示：
1 对于任何问题不能轻易下判断，要有证据。
2 对于业务的操作要了解清楚，很多时候他们不了解Oracle优化器的运行机制，主观操作往往带来灾难。
3 对于业务管理和运维管理分开的单位，务必做好上层的沟通，业务变动好通知下运维部门，这样可以大限度减少性能或故障的发生。
