这两天搞得满头是包,系统集成部的人来以后说是做那个增量抽取的方案,结果发现原来那个设计方案完全不可行,花了快一个月时间,七八万块钱买设备结果说不行就不行了,把项目经理也是搞的满头包,数据库停机了好几次.搞得我们也没法做事情,本来就因为要重新初始化整个数据仓库搞得数据库繁忙不堪,cpu几乎都是满负荷的,IO也快撑不住了,wio已经达到40了.数据库停机一次我们就要中断所有事情,整个项目进度进展缓慢,已经拖后好几天了,哎.不过数据库停了也正好休息一下,,
陌生心情
周末,在加班,最近项目组的工作有些混乱,没有以前那种大家齐心做事情的感觉了,大家都有点得过且过的心理,事情差不多就好了,计划没完成也就那样,没完成就没完成,有点大锅饭的感觉,干多干少一个样,干好干坏一个样.昨天的测试是一场灾难,回来小廖的心情很不好,说从今开始让我负责项目的内部管理工作,怎么讲呢,这个事情也没那么简单,小魏他也做的很认真,是太相信我们了吧.只是问我们改好了没有,说改好了就没有再去检查,所以这次错误都要他担当责任,其实有几个事情也是我的责任,我还以为是个普通培训而已,没有太在意,有几个关键数据算法有大幅改动,我没有同步所有数据,只更新了主界面而已,导致多处查出来的数据不一致,同期往期的算法改动以后导致时间还未到数据库中就有数据.有几个房产数据是我没有去验证,我只是看了下主要的税收申报和征收数据而已,我明知道有错但是没有更新数据,今天来小魏说要辞职,不想干了,太累,对BI这个也不太感兴趣,这个原因当然有,主要的应该还是昨天的事情,今天来开玩笑说晓辉要请客呀,升官了嘛,管理这方面已直是他负责.他也是默认的项目经理人选,都说要辞职了自然就没心思再做事情了,超黄又去支援税管员平台去了,现在ETL数据这方面就我一个人做,量大,事情又多,不知道我能不能承担起来.
简单的存储过程.检查表的每一个字段的count.
create or replace procedure test(ownername in varchar2,tablename in varchar2) is
type vref is ref cursor;
cur_col_cnt vref;
col_name varchar2(50);
sqltext varchar2(200);
colname varchar2(50);
cnt varchar2(50);
cursor cur_colname is
select COLUMN_NAME from all_tab_columns where owner=ownername AND TABLE_NAME=tablename;
begin
open cur_colname;
loop
fetch cur_colname into col_name;
exit when cur_colname%notfound;
sqltext:=’select ‘||col_name||’, count(1) from ‘||ownername||’.’||tablename||’ group by ‘||col_name;
dbms_output.put_line(sqltext);
open cur_col_cnt for sqltext;
loop
fetch cur_col_cnt into colname,cnt ;
exit when cur_col_cnt%notfound;
dbms_output.put_line(colname||’:’||cnt);
end loop;
close cur_col_cnt;
end loop;
close cur_colname;
end test;
informatica性能调优小结
使用informatica做ETL的时候,大表(超千万)的性能十分值得关注,每秒输出行数至少要上千在实际项目中才开始有可用性,
简单的说是下面几点
1
目标表可先禁用不必要索引,加快插入速度,一般只留下主键的unique所有就可以了.
2
源表使用过滤条件减少行数.必要的时候可分批导入.过滤条件必须要加索引.如果多个条件使用联合索引.对源表sql最好事先explain plan一下.因为oralce自动选择的索引很可能不是我们希望的最优选择,必要的在sql中加上hint .如/*+index(表名 索引名)*/来提示oracle使用我们指定的索引,这个事情在表建有多个索引的时候经常会发生
3
lookup大表的话必须使用sql override ,限制sql条件.注释掉默认的order by字句,为lookup组件设置cache size,和index cache size.一般来讲一百万左右的数据100MB的cache就可以了.index一般设为cache的一般即可,在设cache的时候好像最大只能设300MB左右.再大就会报错,而且如果lookup数据量很小的话设大缓存也会报错,如果lookup的表数据量很小最好cache不要设置超过50MB,Lookup cache persistent 一般建议选中.如果这个lookup需要执行多次.而lookup的表不变的话.这个像是根据代码去名称.或是取一个属性可大幅加快执行速度.
4
aggregator组件.joiner组件,尽量使用sorted input ,并且指定cache大小.最大设到500Mb左右.注意etl服务器是32位cpu的话一个session最大只能使用2G内存,这个2G是手工设定的cache容量加(Maximum Memory Allowed For Auto Memory Attributes和Maximum Percentage of Total Memory Allowed For Auto Memory Attributes中的较小值)
5
组件尽量服用.都设为resuable
6
选择update else insert是在update失败以后insert到数据库.在update strategy组件前先lookup目标表.确定好这条数据是update还是insert到目标表,会比更新失败再插入快,插入数据会提高5倍左右.
使用informatica计算同期往期值
在数据仓库往小集市的时候,经常要计算某一个指标的同期往期值,这个确实是不太好做.做同期往期确实让人头痛.
在多维数据库essbase中计算同期往期是非常方便.写一个计算脚本即可,essbase以一种类似指针的方式计算同期往期值,要在oracle中用sql出计算同期往期的语句也不是不可能.但是比较麻烦.倘若放在前端brio中计算那更是麻烦.开始的时候是在informatica中以lookup的方式取出某一个指标的同期往期值,事实上这个可以实现.也经过考验,但是有个缺点就是速度较慢.无数次的lookup在数据量上千万行的表中速度慢到每秒仅能处理10行数据,前几天在做几个大表.从4个表中取出数据做计算.每个表中都有四五千万行的数据,再使用lookup方式我都不敢想像性能会低到什么程度,突然有个想法,逆向来做,某年某月的指标值其实就是下个月的往期值,下年的同期值,在etl过程中写数据的时候把目标表复制3份,直接就把数据给存储到相应的时间.这样一条数据会以3个不同的时间存往3个相应的同期,往期,当期字段.经过这样改造,同期往期计算在etl中简单完成.对于千万级的表处理可达到几千条数据每秒的输出速度.基本能满足项目需要.