我上个礼拜提了个问题, 问如何建立自动更新的table
结果很多论坛的同学给我说建立materilized view.
于是我就把我的项目里面的最终的5个view全部改为materilized view.
问题出现了
一开始如果是死的数据,的确速度很快
但是当开始链接到客户端的时候
因为查询量很大(银行系统)
我设置是1个小时自动更新
在自动更新的时候
整个服务器瘫痪了,我们用的是main frame,结果我们和他们的dba用了一个下午才恢复过来
后来我们把整个materilized view改成了用trigger 触发的table问题才解决.
要知道我们测试是接上了一个镜像服务器,里面数据才20%东北美的数据,一共是120万条记录.
所以希望大家吸取我的教训啊~~~~

解决方案 »

  1.   

    的确不能一棒子打死
    但是,很多跨国公司,包括银行在内,都不会使用materilized view
    因为materilized view 的刷新时间是固定的,一般为一个小时或者半个小时一次
    例如我这次的项目是credit suisse,这个还不是商业银行,只是投资银行,每分钟的数据库的查询量是以千数的
    所以在数据库到点更新的时候,这个负荷是很大的.
    一般银行数据库都做有冗余系统,但是尽管这样,我们那台服务器还是崩溃了但是如果你的数据库查询量不是很大的话,那么materilized view是个不错的选择例外,credit suisse 的DBA说,如果update 的量大的话连trigger都不能用.
    因为触发会太过于频繁,服务器也会吃不消
    具体该怎么办,我明天再去问问看.我因为这次的失误,被老板骂了一顿~~~~~~
    因为我没有通知他们的DBA我们用的是materilized view.
      

  2.   


    我们也做银行,materilized view一般用在一天一刷或一月一刷,
    对于银行一小时一刷是不现实的.
      

  3.   

    我不知道楼上的银行的系统要求是什么
    这次瑞士信贷的要求是live system
    他们以前根本就不用view,全是table,每天晚上12点,系统自动运行scripts 一遍
    但是他们现在的要求是要即时信息
    所以我们开始都给他们建的view,但是实在是太复杂了,所以查询速度很慢
    他们给我们的sample数据就是6万多,实际数据再加3个零
    到了客户的地方,数据多的吓死
    那个数据库服务器,几长排大黑衣柜,连开关都找不到,开了洋荤了
    呵呵,扯远了