本次要给客户作一个演示，所以环境都是临时搭建的。具体环境如下：DB：Oracle9i, 内存：512M，xpsp2cognos：cognos8.3，内存：2G，xpsp2，硬盘：WD3200AAJS-08L7A0数据：主表2......
本次要给客户作一个演示，所以环境都是临时搭建的。
具体环境如下：
DB： Oracle9i, 内存：512M，xpsp2
cognos：cognos8.3，内存：2G，xpsp2，硬盘：WD3200AAJS-08L7A0
数据：
主表28w，明细：200w(3个月)，字典表4个，分别为 700,122,131,4
日期粒度到天
第一步：
现象：在transformer中执行建cube后就没有反应了，DB Server CPU等都没有什么反应。
实验了很多，把抽取数据的SQL那出来，单独在SQLPLUS中执行也如此。
哪怕是只去前100行数据，也是没有反应。实验了很多，也没有反应。
原因：查看数据表，发现索引不全，字典表是临时建的，没有索引。
给所有表加索引，给所有外键关联的键值加索引。
在次执行前100行数据，2，3秒内就能出来。
结论：索引是必要的。忘记了，你就等吧
第二步：
现象：在transformer中执行建cube后就没有反应了，DB Server CPU等都没有什么反应。和第一步中没有多大区别
原因：打开OEM，查看session，发现session长时间操作，很慢，读取block一个个读取，剩余时间居然是n天
查看内存参数配置，oracle默认的配置很低。经过多次尝试，参数调整结果如下图：
db Buffer：200
sort_area_size:10M , 默认居然是512K
pga：512M，默认大概48M
一开始调整后连入的session的uga都不大，后来在网上查到一位大侠测试结果，说一个uga大约相当于pga的 6% ,所以吧pga调整到512M
这样，session的uga大约能达到40M左右
share pool size：256M
临时表空间一定要有足够的地方，这个例子发现临时表空间大约用到了3G的样子
调整是逐步的，每次调整后，都发现28w的表的扫描能快上不少，最后调整的结果是执行这个结果大约在5分钟可以完成。
结论：olap的参数和trans的参数还是要有一定区别的，尤其是在建cube的时候，是少并发，大数据量读取，所以各种参数一定要跟上。
1/4 1 2 3 4 下一页 尾页 |
