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的最大理由）
尝试解决：
把上次的结果清掉，我没有测试调整维度处理对话框中的处理选项，只是把两个维度的属性作了调整，强制重新发布，这样上次处理的结果将被删掉，这个维度全部重新处理,问题得到解决。
之后再想调整处理属性发现不论用什么方式处理，即便是以前失败的处理方式，也没有再发生问题...调整处理选项参数的方法只能等待下次问题再现的时候了，可能是明天也可能是很久以后:(