本来养的是一盆芦荟，结果被我浇水浇多了烂根死了。我严重怀疑是买的时候就已经烂根了。以我从小养花的经验，还不至于这样吧。
     当时还从一朋友家拿回一盆仙人球，里面有一些胭脂花的籽，我赶紧把他们种在这个花盆里，没想过几天就发芽长出来了。实在太多，就留了三颗苗。
    看着它们一天天长大，绿油油的，一颗比一颗绿。工位上阳光少，我只好把它们房子窗台上，接收阳光的洗礼。同事都问，这是啥花，是草吧，怎么一直不开花呀。
     这是胭脂花，会开花的，只不过在窗台上阳光太少了，瞧瞧他们，都扭弯了身子去吸收那一点点阳光，谁让我们的窗台受光时间短腻。
     一天两天....记不得过了多久，我依旧浇水，捉虫。前些天因为长了很多虫，我把叶子都给剪掉了，光秃秃的。同事们依旧笑着问，这草啥时开花。我答曰，会的，很快就会的。
   又一个周六的早上，就是今天，早上去体检，回来也不想干活，再次去窗台看望他们的时候，竟然发现有了花骨朵，藏在顶部的叶子里面。哈哈。终于要开花了。赶紧浇水。瞧瞧土都干了，叶子也有些蔫了。
   相信过不了过久，这美丽的胭脂花就会盛开。还特意去baidu了一胭脂花的照片，不错哦。其实以前也种过，那是在乡下，不用这么费劲每天浇水。   

  

  eucp前台一直很慢，但是分行使用自己的eucp连接过来就很快，所以基本排除是由于后台的问题。一直比较纳闷是由于eucp系统使用虚拟机的原因，或者是采用几年前的淘汰机器而速度很慢。问过公司的人，得到的解释就是一直就是这么慢，没有人知道原因，也没有人愿意给我解释。
但是周三开始，很慢很慢，业务测试的说联动交易根本就是跑不起来，我进去一看，确实是。只好去找大牛解决。大牛又是看前后台日志，发现后台的时间是1秒内即给予响应，所以基本排除后台的原因，清除前台日志，清楚一些垃圾文件，看系统开销，霹雳扒拉敲一大堆命令，甚至又是替换数据库文件，还是纹丝没有改变多少。最后让我用分行的数据文件替换试试，可能是数据文件受到破坏。
     幸好和分行科技的关系还不错，分行科技还正好有事在rtx上找我，顺便让他打包发给我，接收，上传，解压，aa登录试之，操作同样的交易，哈哈，简直太快了，和分行的eucp一样快，看来果然是数据库的原因。当然啦，覆盖之前我把原来的数据文件给备份了。
这样我需要恢复到原来的数据库，先把原来的数据给导出，然后解压分行的数据文件，然后再导入原数据文件。幸好前段时间做过数据库的数据移植，如法炮制。靠，理论永远是理论，两个数据库的表竟然不一致，分行好多数据库表没有，也不知道这些数据库表是否有用。晕啊。晚上还要去健身呢，那个着急啊。
从3点多折腾到6点半，终于倒完数据，缺少的表暂时不管。nnd的，发现竟然还是那么慢。期间磁盘空间不足，只要把备份放到我本机上。把数据文件下载到本地后，我想去看看确实的表里面都是啥东西，所以用winrar打开，发现有几个数据文件很大，双击最大的一个一看，里面出现一些20050101的东西，我猜想这可能是日志之类的，一般与日期相关的记录大都是日志之类的，磁盘空间不够啊，所以只能去数据库里面把这些数据删除之，反正有备份，可以恢复嘛。然后还发现柜员表也很大，于是删除之。然后再导入上次倒给分行分行的柜员表。登录做交易，发现竟然好了很多。心理激动之，可能是柜员表数据量太大了，7万条，现在就几百条，速度肯定快了。既然这样，我在原来的数据库基础上删除柜员表数据不就可以了吗。但是，很失望，使用原来的数据库还是不行，难道非得我一个表数据一个表的导入的吗？使用新库老数据，update statistics 做不了，提示一些表找不到，我郁闷死了，时间已经到了7点半了，tnnd，不管了。明天早上早点来弄吧，大不了重新恢复原数据库。

   回去健身之，练得脱衣服的力气都没有了，晚上睡觉的时候，翻来覆去，好像一整晚都没有怎么睡着，周五早上早早到公司。这时候突然想会不会跟索引有关系，查看前台的柜员表，果然没有索引，而后台对应的表有几个索引，哈哈，估计是索引的问题。于是马上找对应的sql文件，很快就找到了对应的索引建立sql，于是拷贝之，建立索引。速度快了很多，大功告成，顺便把88和199的前台都弄了一遍，但是发现好像没有200提高的速度快，不管了，让他们想用吧。
   唉，但是凄凉的是，10点多的时候测试的反应前台又不行了，乱码，我再去登录，根本就进不去了。找老大，同样也telnet不上去，ping可以，也不知道啥原因。估计是虚拟机down了。于是去机房，打电话给大牛，大牛说他可以登录，太奇怪了。我赶紧回工位，登录，果然可以，不过出现其他一些错误。我替换数据库，可以登录了，交易也可以了。但是过一会有不行了。唉。反反复复。最后我放弃之。晚上吃饭遇到大牛，他说他啥也没有弄，我估计是机房在整网络啥的，因为这几天电源啥的有问题。
   今天加班，事情不多，我想也没有人在机房弄啥东西，所以我重新开始思考。建里索引后，把数据全部导入后速度还是那么慢。那是什么原因呢？我回想那天速度很快的时候我都做啥了？对，还删除了一个表的数据。我赶紧再做一遍。果然，速度快了很多，一个联动，用不了一秒钟的时间，而以前，起码得1分钟。哈哈。在88和199上试之，果然也是这样。终于成功解决。太有成就感了。

   说了这么多废话，总结如下：
（1）eucp原开发者考虑不周，测试的时候，数据量少时，一点问题都没有。而后来随着交易量变大，以及柜员增多时，特别是并发柜员操作时，就很慢了。而且在每个支行一个eucp，每个支行柜员也没有几个，所以发现不了问题。
（2）至于在测试系统中发现问题，越来越慢，大家都以为是机器的原因，使用的人大都为业务或者测试人员不懂得什么原因，新接手的人也不知道其架构。所以只有忍受。
（3）遇到问题还是需要慢慢分析原因，弄清楚整个流程，其实只要明白流程，就很容易找出原因：在前台提交的时候，就很慢，然后才提示发送到后台，而后台的反应在1秒内，所以主要是前台的原因，那么在提交的时候都做啥了呢？现在看来是去检查了柜员表判断权限啥的，还有登记日志bts_apjda。然后再发送后台。具体还有哪些，现在也不明白。
（4）而当初判断为柜员表索引的问题，实际是先删除了bts_apjda的数据，再然后建的索引，这样登录会很快，但是交易还是比较慢。所以有些东西被其他一些表面的东西给隐藏了。
   所以以后查问题一定要深究其原因，其实有时候不是不愿意，是没有资料，大家都过于忙，所以也得过且过。反正是以后不用的系统了。不知道生产上遇到过这样的问题没有？毕竟有些分行营业部业务量很大，而且柜员也不少。等周一问问他们科技的。