马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。如果您注册时有任何问题请联系客服QQ： 83569622 。
您需要 登录 才可以下载或查看，没有帐号？注册
x
Q：资料说block size的大小最好在8k~64k，但是实际上做出来的模型的block size往往只有几百或几十，有没有很大影响？ A：在不影响稳定的情况下，应尽量将其调大。 Q：block density和block number之间有什么关系？block density自然越大越好，但是往往它越大，block number就越多，如何平衡？ A：一定要多做测试，测database的工作性能、测稳定性。尽量将density调大，这样才能保证模型的稳定性。毕竟稳定压倒一切。 Q：在Data WareHouse中，如果串行地对多个database进行操作，例如加载数据，计算等，经常会出现错误，错误原因是无法分配内存；但是手工将每个database分开操作，过程和自动化过程完全一样，又没有错误。是不是essbase内存分配的问题？如何解决？ A：我认为这是Essbase自身对内存管理的问题。因此，在流程设计中应该避开这些问题。方法就是操作完一个database之后，就去unload它，再操作下一个。 Q：在加载数据或者计算时，如果想将它停下来，有什么办法？ A：加载的过程是没办法停下来的，强行停止会损坏模型；但计算时可以停下来，方法就是在后台窗口中按下ESC键。 Q：在模型计算中会出现类似的错误：Invalid block header: Block's numbers do not match，然后模型就无法加载或计算了，必须重建database，这是什么原因？ A：像在问题2中所说的那样，一般都是因为density太低，导致出现这个问题。 Q：计算正确完成后，出现load db过长的原因？ A：我认为原因在于Essbase对内存的管理还不完善。当一个主题计算完成之后，一些信息还未写入硬盘，第二个主题已经开始了计算。这样，前一个主题的数据遭到破坏，导致这个正常计算完成的database不能正常unloaddb。这个被破坏的文件是APP中对应database文件夹中的*.ind文件（*与该database名相同）。这个文件不同于数据文件中的索引文件，索引文件的文件名为ess00001.ind。因此，这个文件我们称之为索引之索引。这是从该文件的基本功能上引申出来的。下面具体描述一下这个文件的功能。当一个database计算完成，并对它正常unloaddb后，这个模型才算正常计算成功。此时去load该database不会有任何问题，包括重启服务或是重启计算机。对执行load database操作时，系统首先去找*.ind文件，并由它去组织数据。也就是先通过*.ind，找到索引，再找到数据。因此，*.ind被称为索引之索引。如果一个刚刚计算完成的database还没有来得及写这个*.ind文件，就开始计算下一个模型，由于系统组织内存等原因，导致*.ind文件写不成功，因此，这个模型虽然在data warehouse中显示正常计算完成，但实际不然。当用户不知情的情况下去load该database的时候，由于没有这个索引之索引文件，Essbase将根据现有的索引文件和数据文件重构*.ind文件。这个过程所需时间视乎该database的数据量大小而定。如果数据量很小，这个过程将很快，快得用户感觉不到这个过程的存在。如果database存储的数据量非常大，则这个过程将要花费大量时间。比如我们的模型goodsale，在这种情况下load要2个小时左右。以前在这个时候，看到CPU在猛烈消耗，真不知它究竟在干些什么，还真为它担心呢。不过话又说回来了，如果系统的性能足够好，模型处理的数据量也小，则不会产生*.ind文件损坏的问题。就目前我们的认识程度来说，大概是这样的吧。 | 
[复制链接]
|Archiver|小黑屋|手机版|壹佰网 ERP100
( 京ICP备19053597号-2 )
IP卡
狗仔卡
发表于 2010/1/8 14:46:41
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡
:/guzhang:/guzhang:/guzhang:/guzhang:/guzhang