JES Migration遇到的一个Login问题

故事是这么发生的：

1. 在OAT的环境，连的是OAT的Oracle10G Server，Login Performance很好，非常顺畅。

 

2. 在Preprod的环境，做Drill（上线前的试验）的时候，连的是Production的Oracle10G Server，Login Performance很好，非常顺畅。

 

3. 上线的时候，连的是Production的Oracle10G Server，Login Performance非常差。

 

问题：

1. 为什么OAT没有这个问题？

 

2. Drill也是连真正的Production DB，为什么没有问题？

 

3. 为什么在上线的时候，出现这个问题？

 

原因：

1. OAT，Drill，Prod连的都是同一个版本的Oracle10G，DBA做的操作一样，但是没有导入Stat Table的Data。

 

2. OAT和Drill没有出现问题，是因为Oracle10G有个新机制，对数据经常有增，删，改的表和索引有一个定期维护机制。OAT和Drill的时候，虽然没有导入Stat Table，但是由于OAT跑过多次，Drill的时候，Oracle的定时器已经跑过一次，也gen了些stat出来。

 

3. Prod是导完data马上进行测试的，此时定时器根本没有跑过，Oracle10G需要一个full scan才能产生相应的stat data，但是因为scan的data数据量非常大，造成的现象就是一login，由于没有stat table data，后台就在scanning，导致login的performance非常差，从而导致system fallback。

 

解决办法：

当然是DBA需要把Stat table的data也一并从旧production db导入导新production db。

 

感想：

虽然root cause不是development team引入的，但是作为一个project team，DBA的操作需要有人verify，development team有自己的project leader和manager，需要对control不了的地方更加细心和细致。

 

注：

由于team组成人员比较复杂，development team和dba team是独立分开的，不管是逻辑上，还是物理上（其实就是两岸三地既性质了），职责分得很开，一个系统的上线，就是两岸三地的成员聚在一起各司其职，但同时，也引入了development team的project leader和project manager control不了development team以外的resource的操作的情况，有点类似于vendor mode。