SQL2005 Anerlysis Service的处理维度中一个BUG的分析

BUG的帽子虽然不能随便扣,大部分情况下,开发者行为才是不可信因素,但是我google整个中英文互联网也没有发现一个和合理的解释,姑且把它认为是BUG了

 

硬件环境:IBM 3650 4G内存

系统平台:Windows2003,SQL2005

运行环境:SQLServer2005数据库(下文称为原始库),SQLServer Anerlysis Service(下文成为SSAS)

 

描述:

无数应用库向原始库定时分发数据,SSAS通过原始库处理多维数据集。从任何角度讲都应该把原始库和ssas分开两台服务器,但是由于某些问题一直没有处理,暂不考虑他们之间负载的影响。由于以前数据量不是很大,系统稳定运行了1年多。

 

问题由来:

有两个表的数据量逐月增加,目前都为千万左右。多维数据集处理作业开始不稳定,经常失败,且频率上升。

 

问题描述1:

两个表对应的维度处理失败,开始的时候报内存超过13xxM限制。

 

解决办法1:

修改了ssas服务器配置文件和系统虚拟内存大小后稳定。

 

问题描述2:

随着数据量进一步增长,经常发生维度处理缓慢,甚至半天都无法完成,而一旦这两个维度处理成功则接下来作业正常。

 

解决办法2:

分析了好长时间,加上google,也没有发现问题所在。于是从结构和处理过程上分析。

 

分析内容:

1、两张表对应的两个维度都在键属性处理中,生成了索引完毕后数个小时没有反映,按照处理过程,这时应该处理对应的层次结构。

2、还有一个奇怪的问题:我的表中有800万数据,他在处理中读取了800万数据后,会显示已读取1600万数据,差不多翻了一倍。

3、观察OLAP数据文件,OLAP/DATA/数据库名/维度名/ 目录下的文件,这时会有两套文件存在,一套为上次成功处理的文件,一套为正在处理中的文件,文件名已递增的数字前缀区分,后面的都一样。

3.1 而这时比较两套文件会发现,目前处理中的每个文件几乎都为上次成功文件的两倍大小。

3.2 新处理文件的部分文件大小为0K,而老文件为几十M,文件名大致为 数字前缀.维度名.xxx.fact.map.xxx

3.3 终止当前响应缓慢的处理后,新的文件会被删除。

4、此时系统剩余内存大致在500M到1G之间波动,SQLSever内存使用稳定在1G多,而Msmdsrv.exe也就是ssas的进程占用内存在1G到1.5G之间波动,应该不关运行环境的事情。

 

判断:

于是很容易从逻辑上把这几个特征关联起来,操作系统还没有达到不能忍受的地步,问题出在SSAS本身。

索引生成后无法为事实表的维度生成层次结构,怀疑SQL把上次处理过的结果和本次带处理的结果叠加导致数据量翻倍。于是生成的维度文件中有大量键属性重复,而无法生成层次结构,导致几个文件无法生成一直0K,处理程序数个小时没有反映。

不解的是,这个问题不是必然发生...(这是我把它定为Bug的最大理由)

 

尝试解决:

把上次的结果清掉,我没有测试调整维度处理对话框中的处理选项,只是把两个维度的属性作了调整,强制重新发布,这样上次处理的结果将被删掉,这个维度全部重新处理,问题得到解决。

 

之后再想调整处理属性发现不论用什么方式处理,即便是以前失败的处理方式,也没有再发生问题...调整处理选项参数的方法只能等待下次问题再现的时候了,可能是明天也可能是很久以后:(

 

 

 

posted on 2008-09-11 20:53  代码王子  阅读(120)  评论(0编辑  收藏  举报

导航