引言：
这是我碰到的一个比较好玩的问题，这个稍微有点标题党了，虽然根本原因并不是时区问题，但是时区也间接导致了影响了业务。
问题现象：
晚上我下班刚到家，就接到电话说有套慢了，现场值班的工程师帮忙看了下，发现有会话堵塞，当时是把堵塞源头会话干掉了，就恢复了服务。我当时还挺纳闷，这个库其实日常交易量不大，维护的同事反馈最近也没做活动，系统也没做变更，就是前天晚上部署了个清理分区表的脚本。当时有点懵，第二天上班再分析吧。
问题分析：
头天晚上，值班工程师已经把堵塞会话的sid发我了，我直接带入万能sql。查出了这个会话其实是系统自动执行的一个PLSQL，从18：00开始执行的，最长的一个sql执行了一个1个半小时。
看一下最长的这个SQL：cwd06tnwfx32c
查看SQL文本内容，该SQL正在对一个表的索引进行cleanup，这种系统自动吊起的合并索引的情况，一般是在凌晨发起，现在看最早是在18:00发起的。这个时候业务也没有进入低峰呢，执行这种DDL语句，很显然会对联机交易有较大影响。
那为啥数据库会自动维护索引呢？
首先这个自动维护索引可以解释，这是oracle 12c中的一个新特性，oracle12c以后，对于drop或者truncate分区表的分区后，同时语句中使用了update indexes，并不会立即进行索引的维护动作，此时索引不会失效，oracle会异步的进行索引维护，通过一个调度任务PMO_DEFERRED_GIDX_MAINT_JOB进行维护索引。
那为啥时间点是18：00点呢？通过查看这个调度任务，发现吊起时间是02：00AM（凌晨2点）,这没毛病，那后面那个PST8PDT是个什么鬼？
百度一下：
PST-Pacific Standard Time太平洋标准时间[加拿大及美国太平洋标准时间。PST是美国西部城市通用的标准时间，以旧金山的时间为准。PST8PDT就是西8区，就是比国际时间慢8小时。中国统一是东8区，比国际时间快8小时。
有木有，这货竟然是美国西8区的凌晨2点，跟中国差着16个小时呢，可不就是我们的下午18点吗？你凌晨2点是业务低峰，我下午18点可还是高峰啊。
在MOS库里找了一圈，找到了一篇文档说明如何调整这个时区的问题(Doc ID 2703783.1）。按照这个操作就ok了。
总结：
一通分析下来，并不是一个什么原理性的问题，不过oracle这个延迟重建索引的操作还是挺坑的，人家做清理分区的操作肯定是在业务低峰，本来就想立马重建索引，你还非得延迟做，这不掉坑里了么。。。
