ESSBASE的使用及优化
这是essbase的上手使用说明
ESSBASE的使用及性能优化
计算脚本相关
Essbase中，一个指标可以通过计算公式调用自己得到，用@SHIFT函数实现。
如：
B C
-------
B1 C1
B2 C2
B3 C3
…
其中，C2=C1+B2;C3=C2+B3 …
那么，指标C就可用公式：@SHIFT(C,-1)+B来实现。
数据加载不进的问题，某个维存在空值的情况，或事实表数据没有清洗干净，报错如下：
不选时间维的计算公式：
IF(@ISGEN("sj",1))
#MISSING;
ELSE
qmqsye-bqxzqs;
ENDIF;
ESSBASE求百分比指标：
number%number->Year->Market->Product->Scenario;
求同期值公式：
IF(@ISGEN("D_Date",6))
(@MDSHIFT(set01, -36,"D_Date",@GENMBRS ("D_Date",6)));
ELSEIF(@ISGEN("D_Date",5))
(@MDSHIFT(set01, -12,"D_Date",@GENMBRS ("D_Date",5)));
ELSEIF(@ISGEN("D_Date",4))
(@MDSHIFT(set01, -4, "D_Date",@GENMBRS ("D_Date",4)));
ELSEIF(@ISGEN("D_Date",3))
(@MDSHIFT(set01, -2, "D_Date",@GENMBRS ("D_Date",3)));
ELSEIF(@ISGEN("D_Date",2))
(@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",2)));
ENDIF;
求前期值公式：
IF(@ISGEN("D_Date",7))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",7));
ELSEIF(@ISGEN("D_Date",6))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",6));
ELSEIF(@ISGEN("D_Date",5))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",5));
ELSEIF(@ISGEN("D_Date",4))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",4));
ELSEIF(@ISGEN("D_Date",3))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",3));
ELSEIF(@ISGEN("D_Date",2))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",2));
ENDIF;
国税求同期值公式：
IF (@ISGEN ("时间",5)) "去年同期欠缴税额"=@PRIOR ("本期欠缴税额",365,@genmbrs("时间", 5));
ELSEIF (@ISGEN ("时间",4)) "去年同期欠缴税额"=@PRIOR("本期欠缴税额",12,@genmbrs("时间", 4));
ELSEIF (@ISGEN ("时间",3)) "去年同期欠缴税额"=@PRIOR ("本期欠缴税额", 4,@genmbrs("时间", 3));
ELSEIF (@ISGEN ("时间",2)) "去年同期欠缴税额"=@PRIOR ("本期欠缴税额",1,@genmbrs("时间", 2));
ENDIF;
国税求前期值公式：
IF (@ISGEN ("时间",5)) "上期欠缴税额"=@PRIOR ("本期欠缴税额",1,@genmbrs("时间", 5));
ELSEIF (@ISGEN ("时间",4)) "上期欠缴税额"=@PRIOR("本期欠缴税额",1,@genmbrs("时间", 4));
ELSEIF (@ISGEN ("时间",3)) "上期欠缴税额"=@PRIOR ("本期欠缴税额", 1,@genmbrs("时间", 3));
ELSEIF (@ISGEN ("时间",2)) "上期欠缴税额"=@PRIOR ("本期欠缴税额",1,@genmbrs("时间", 2));
ENDIF;
Unix下后台启动和停止Essbase服务
启动命令：
nohup ESSBASE password -b &
停止方法：
手动：交互式，在esscmd中用shutdownserver命令，根据系统提示完成。
脚本：echo "login essadmin password on localhost;alter system shutdown;exit;" | essmsh –i
HP-UX下配置Essbase连本机Oracle 8i的ODBC
配置环境
HP-UX
IBM DB2 Olap Sever7.1
Oracle817
配置.profile
将Oracle的.profile文件环境变量内容copy到essadmin的.profile文件。
[注]：根据实际情况修改至.profile文件正确，不要引起两个.profile文件间内容的冲突。
例如：
export ARBORPATH=/essbase
export SHLIB_PATH=$SHLIB_PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export PATH=$PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export ODBCINI=/essbase/.odbc.ini
PATH=$ORACLE_HOME/bin:$PATH;export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib64;export LD_LIBRARY_PATH
ORACLE_BASE=/oracle;export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/ora817;export ORACLE_HOME
NLS_LANG="AMERICAN_AMERICA.ZHS16CGB231280"
ORA_TERM=hp;export ORA_TERM
ORACLE_SID=DW;export ORACLE_SID
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data;export ORA_NLS33
SHLIB_PATH=$ORACLE_HOME/lib:/usr/lib:$SHLIB_PATH;export SHLIB_PATH
TMPDIR=/oracle/tmp
umask 022
配置关于oracle的odbc
得到.odbc.ini文件模板
运行$ARBORPATH下的inst-sql.sh，将在$ARBORPATH下生成.odbc.ini文件。
配置.odbc.ini
vi .odbc.ini，编辑得到类似如下内容：
[ODBC Data Sources]
dw=INTERSOLV 3.11 Oracle 8 Driver
[dw]
Driver=/essbase/dlls/ARor815.sl
Description=Oracle8
ServerName=dw
[ODBC]
Trace=0
TraceFile=odbctrace.out
TraceDll=/essbase/dlls/odbctrac.sl
InstallDir=/essbase/dlls
[注]：默认的Driver为ARor813.sl，对于oracle817数据库，Driver应改为ARor815.sl。
测试
用Essbase的终端(Application Manager)测试odbc是否配通。
小结
配置HPUX下Essbase连本机Oracle的ODBC，比较简单，不用像Informix安装Client端，直接使用Essbase自带的driver。只需修改.profile和.odbc.ini文件。
AIX下配置Essbase到本机DB2的ODBC过程
整个过程分为两个步骤：
配置ODBC：
以下是万佳BI项目Essbase for AIX的ODBC的配置过程：
在万佳BI项目中，配置从DB2到Essbase的ODBC过程如下：
3．以admin登录（如果Essbase的user为admin），编辑admin用户的.profile文件，加入如下部分：
. /db2system/db2inst1/sqllib/db2profile（与DB2的安装路径有关）
export ARBORPATH=/essbase（essbase的安装路径）
export LIBPATH=$LIBPATH:$ARBORPATH/bin:$ARBORPATH/dlls
export PATH=$PATH:$ARBORPATH/bin:$ARBORPATH/dlls
#export ODBCINI=/home/admin/.odbc.ini
（以上部分的第一句最重要，最后一句可以不要）
4。logout并再次login用户admin，运行/essbase/inst-sql.sh；
提问：intersolv or IBM-DB2?
选择：DB2
5。编辑admin用户下（/home/admin/）的.odbc.ini文件，确保有如下部分：
例：
[ODBC Data Sources]
DWCN=IBM DB2 ODBC Driver
[DWCN]
Driver=/db2system/db2inst1/sqllib/lib/db2.o（与DB2的安装路径有关）
Description=DB2
Host=aixf85（主机名）
Database=dwcn（数据库名）
#Username=db2inst1（用户名，可不输入）
#Password=（此外即使输入口令也无用）
6。在命令行下运行：
su - admin
ESSBASE password
7。在NT客户端打开Application manager，在任意一个正常的Database上建立一个新的rule，并用此rule的open sql去测试以上对ODBC配置的正确性。
Catalog DB：
上面的过程完成之后，如果直接使用，对于数据量小的load data过程偶而可以正确完成，但对于大数据量的load data过程不能正确完成，系统提示网络方面的错误（如图所示）。
我认为，出现这个问题是因为同一台主机上共存DB2和Essbase，在.odbc.ini中指定的数据源是直接到本机数据库中找到的，而不是通过网络。这种通讯方式是Essbase不能接受的。试想如果DB2和Essbase分别装在不同的机上，在Essbase这台机上最终势必要配置连到目标DB的ODBC（也就是配置.odbc.ini文件），该ODBC中的数据源指定的DB就一定要通过网络了，也就是说这个目标DB是Essbase这台机器认识的（一般是安装了该种DB产品的客户端），这就要首先建立连到目标DB的ODBC。因此，如果DB2和Essbase在同一机上的时候，就少了这一个过程。
因此，还必须做如下方面的工作：
1.db2 catalog tcpip node vgsznode(新的节点名) remote 168.1.6.152(IP地址) server 50000(端口号)；
2.db2 catalog db dwcn as szdc(dwcn的别名) at node vgsznode；
3.编辑Essbase用户下的.odbc.ini文件，将数据源的名字指定为szdc。
通过如上操作，就相当于通过网络建立了一个连到DB2的ODBC。这样，以后在Essbase中open SQL的时候就要选szdc了。
Essbase的一些初级问题
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文件损坏的问题。就目前我们的认识程度来说，大概是这样的吧。
Essbase中Database的备份与恢复的经验
Essbase数据的备份不同于一般的数据库系统。数据库有成熟的备份机制，可以离线备份、在线备份、增量备份，并且还有回滚（roll back）等等数据保护机制，保证数据的实时性与正确性。而Essbase的备份机制相比就要差很多，它是一种文件系统，说到备份，其实就是备份相应的数据与系统文件。
对于任何一个database来说，.otl和.rul文件是可以不受路径限制进行备份和恢复的。但用这些文件恢复的database只是恢复了database的结构（outline和rule），没有恢复数据。有时，我们备份与恢复是希望保留数据的。
带数据Essbase模型的备份与恢复，适用于本机database的备份与恢复，也适用于不同主机间数据的移植（不同主机的Essbase安装路径很可能不同）。
带数据Essbase模型的备份与恢复，分为源与目的database的路径相同与不同两种情况，不论什么情况，备份与恢复的方法一律相同。
我们知道，每个database的索引与数据文件默认是放在APP下该database所在的文件夹下的。如果用户没有改变这个路径，备份与恢复问题就变得非常简单了：
方法一
1. unload你想备份的database；
2. 复制该database的文件夹；
3. 在目的端重建相同名称的APP以及你要恢复的database，并unload db；
4. 用你已经复制的database文件夹覆盖新建的database的文件夹；
5. load db，成功！
方法二
如果源database指定了数据存放的路径，备份与恢复就相应变得复杂起来，不仅要备份源database文件夹，还要备份相应的索引和数据文件。具体作法如下：
1. unload你想备份的database；
2. 复制该database的文件夹；
3. 在目的端重建相同名称的APP以及你要恢复的database，并unload db；
4. 用你已经复制的database文件夹覆盖新建的database的文件夹；
5. 复制源database的索引和数据文件夹；
6. 在目的机硬盘上（与源database的索引及数据文件所在的盘符相同，如果没有，可以用虚拟盘的方法，用subst命令。例：subst H: e:H）建立与目的机上该database所在路径相同的路径，并将已复制的源database索引和数据的文件夹粘贴到此处；
7. 打开application manager，在该database的菜单database/setting/storage中设置location为源database的盘符；
8. load db，成功！
影响模型数据易忽略的两点
未更新视图！如果某模型的加载视图是一个多层的视图，若只对上层视图进行了改动，而最下层的视图没有重新组织，加载计算后的结果就会出现问题。因此，总结一下得出结论，如果一个view的数据源的结构发生了变化，就一定要重新建立view。
注意用union all，而不是union！主题数据加载的时候，如果数据来源于多个表，一定要注意union语句的写法，否则会造成数据丢失。
关于Essbase的加载、计算的优化
设计，设计，还是设计
1. 在outline中选定适当的dense/sparse维及其顺序、设定动态计算
2. 组织加载数据
3. 设定各种Cache
4. 设定Commit Blocks
5. 其它调整
6. ……
以上简要说明了对于一个Essbase模型来说，如何去优化加载、计算的性能。重要性按以上的递减顺序排列。
对于一个设计得较差的模型来说，性能调优的意义是不大的，因此，模型的设计是最为关键的。
在outline中，对于dense/sparse维的选择是至关重要的。一定要根据实际情况、根据经验，做许多测试，最终选择一种最优的设置方案。这一步比较重要，它对将来模型的稳定性、速度、数据量等等都有直接影响。在dense/sparse已经确定的情况下，一般要将dense维按照成员数由多到少的顺序放在最上面，而sparse维按照成员数由少到多的顺序放在下面。另外，如果有属性维，则一定要放在最下面。一定不要忘了对可以设置动态计算的dense维设置动态计算，这样对提高计算性能和减小数据量都很有帮助。尽量不要对sparse维设置动态计算，因为它会在加载时影响许多blocks。
组织加载数据。尽量精简加载表的结构或使用加载view。在数据加载的open sql中的order by对加载的性能影响非常大。大家在做的应用的时候可以做些实验。以我们的模型supstk为例，当时也做了order by，只不过是按sparse维从小到大的顺序，用时5个小时左右；但重新按sparse维从大到小的顺序order by后，加载只用时78分钟！可见这一因素对性能影响之大。
各种cache值的设置，对于模型的性能影响也非常之大。其中影响最大的莫过于calculator cache。对于这个cache的设置附录中有详细说明。当然，这些经验都利益于Essbase提供的两个PDF文档，如果有时间，建议大家多看看，确实很有用。此外，对于Index Cache、Data Cache和Data File Cache也一定要做相应设置！
如果内存很多，模型很大，建议Commit Blocks设置为10000，这是个经验数值。不过我感觉这个参数的设置对性能的影响不是太大。大家可以试试其它值。
下面具体分部分地进行介绍：
Database的设计
最重要是dense，sparse的设置。维设置的不同，可能会大大影响到加载计算的性能。设置因每个模型的维个数、数据情况而有不同。原则是使density/block number最大。如何知道各个维的density和block number？有一个简易的方法，使用的前提条件是已经知道database的数据源和部分真实数据。以下是示例：
假定database有两个dense维，三个sparse维
cells1 = _select count(*) from fact_table
block size = dense1_ * dense2
block number = _select count(*) as "block number" from (_select 1 from fact_table group by sparse1,sparse2,sparse3) a
density = cells/(block number_ * block size)
其中，fact_table是已对所有维group by的最终的事实表，dense1和dense2分别是dense维的成员数（不包括动态计算），
block number*block size等于潜在最多的cell，而上述cells1的值等于实际存在的cell数，两者相除就等于加载后计算前的density，而模型计算完成后，一般来说density会有所增大。
知道了各个维的密度后，可以确定维的排列顺序。应当把dense维放在sparse上面，dense维和sparse又分别从小到大地排列，使整个Otl看来像两个叠加的三角形。
尽可能地让dense维的个数和sparse维的个数持平。让block size保持在1k~100k内。
Database设计是否合理，还可以用加载、计算、查询的速度来衡量，因此，可以先定义好几种结构，用少量测试数据测试。
一般data block size越大，计算越快而查询越慢。
设计的好坏对加载计算的快慢有很大影响。所以，尽量不要让你的维有一个超过1000 children的成员；尽量减少维的个数；尽量减少维成员数，特别是那些成员数本来就少的维；将Measure这个成员设为label only。。。
加载
由于在Unix下是区分大小写的，因此，在加载计算等的脚本中的“app”、“db”与“rul”名必须与服务器application manager中的完全相同，否则就会出现load app失败、load db失败或加载数据不会找到rule file的情况。
加载前必须将事实表按照维字段Group By。
当加载大数据量的模型时，必须注意性能优化。优化前后的加载时间可以相差好几倍。优化示例如下：
假设database有三个sparse维S1，S2，S3，分别对应事实表字段也是S1，S2，S3，它们在Otl中的排列是S1->S2->S3。当你建rule file时，选择Open SQL后，在SQL框写_select_ * from fact_table order by S3,S2,S1。请留意黑体部分，Order By的是稀疏维，顺序是Otl中稀疏维排序的倒序。我作了测试，一个数据量达到1000万的模型，本来加载时间是3.5小时，加了黑体部分后，变为40分钟，而且数据量越大效果越明显。
参数的设置。
选中一个database，看settings，翻到storage页，其中有三个重要参数：index cache 、data file cache、data cache。当数据量很大时，将他们加大10～20倍，否则加载时间将是非常惊人的。不过需要注意的是，设置的数值不能太大，首先它们的总和不能大于你的系统现在剩余内存，否则效果可能适得其反；再就是如果他们中有一个的数值太大，例如data file cache超过1G，加载很可能会出现错误，数据库会毁坏。
计算
首先，计算的性能很大程度上依赖于database的维设计。一个糟糕的设计可以让任何的tuning失去意义。设计和计算应该是个循环的过程，即不断地用计算检测设计的合理性。
mutiple bitmap的使用。
Database的计算可以使用两种bitmap，single bitmap和multiple bitmap。bitmap用来在计算时追踪当前member的children的值，因为essbase的运算大部分是children的值的向上聚合，而使用了multiple bitmap使追踪速度加快，也就加快了计算的速度。使用的方法如下：
计算是否使用Mutiple Bitmap与Calc Cache的大小有关。假设database有三个sparse 维S1、S2、S3，在Otl的排列是S1->S2->S3。如果要使用Mutiple Bitmap，
calc cache in byte >= S1_ * S2_ * （2 + ParentNumber） / 8
database的Calc Cache应大于等于这个数才可以使用Mutiple Bitmap。其中，ParentNumber是你的Database中任何一个Member所拥有的最大Parent数。除非有Share Member，ParentNumber一般是1。如果有Share Member并且最多Share了X次，那么ParentNumber就是1+X。
但是，虽然IBM的许多文档都说Mutiple Bitmap的计算比Single Bitmap的计算好的多，它仍然与模型的结构有很大的关系。如果不管什么结构都坚定不移地使用Multiple Bitmap，效果可能是相反的，即可能Single比Multiple还快，尤其是Block Number很多的时候。我的经验是：当错误使用了Mutiple时，它的速度比Single会慢2～10倍。此时，可以适当增大block size，减少block number。虽然Tuning很麻烦，不过当正确使用了Mutiple Bitmap时，它的性能比所有结构的Single Bitmap计算都要好。
对计算有影响的参数
在加载部分提到的三个cache 对计算也起了同样重要的作用，不过使用也要非常小心。
当加载的数据都在level0上时，可以选择在settings->general页的aggregate missing value，可以使计算速度提高1%~30%。
Settings->transaction页的commit point可以设为10000。
当database只需计算一次时，可以将计算中的clearupdatestatus关掉：set clearupdatestatus off。这样可以省掉一些更新data block状态的操作。
动态计算的使用。
将measure上的一些有公式的member设为动态计算。
将dense维的parent成员设为动态计算。它会降低查询速度，不过当服务器的CPU够快，影响不大。
不建议使用稀疏维的动态计算。因为它牵涉的Data Block太多，会大大影响查询的速度。应该仔细地衡量计算与查询的关系。如果计算实在太慢，又存在某些density很低、成员数很少的稀疏维，那么可以将它设为动态计算。
维修改
影响维修改的最大因素是otl和数据文件的大小。Otl的影响原因很明显，而数据文件之所以也有影响是因为每增加一个成员或改变一个成员的属性（parent、别名等），它对应的data block都会随之变化，essbase就在改变data block这个操作上花费时间，就算不用改变data block，也在查找data block的过程中花费了时间。经验：一个database，无数据时作维修改3分钟，当数据文件10G时，维修改45分钟。
通过Rule File的维修改不能删除成员。
当维修改时，如果改变了某些有数据的成员的parent，那么它对应的data block也就设为了dirty的状态。由于维修改可能会改变data block，当智能化计算开启时，下次的计算要重新计算这些data block。
分区
建议使用transparent类型的分区。因为它实现简单有效，并且适用于绝大多数的情况。相比下，link类型分区比较麻烦；replicate类型分区传输数据太慢。
在area页上，指定的是源和目标的对应数据块。数据块大小相同就行了，两边的维不必相同。不同的维和指标要在mapping 中指出。示例：
源的维和指标： dim1,dim2,dim3,measure1,measure2
目标的维和指标：dimA,dimB,measureA。
源area 目标area 源mapping 目标mapping
(@idescendants(dim1) @idescendants(dim2) @idescendants(dim3)
“measure1””measure2”) (@idescendants(dimA) @idescendants(dimB)
“measureA”) Dim3 void
Measure1 measureA
Measure2 void
备份与恢复
为什么要备份？
当数据量比较大，处理的时间比较长时，database有可能毁坏。尤其是像万佳BI这种需要每日进行计算的database，如果没有备份而出现问题，那么所有的数据都要重新计算，耗费时间太长。
毁坏的原因？
1、数据库在加载、计算、维修改时出现异常情况，如断电、系统DOWN机、人为杀掉进程等。当一个application Load起来时，系统中会有一个Esssvr的进程，而它下面的database Load起来后都归Esssvr管理。这类事故的实质就是非法中止了Esssvr进程，在这个进程中正在加载、计算、维修改（不包括查询数据）的所有database会毁坏。
2、Essbase的内核错误。当数据量很大，加载、计算时间很长时就有可能出现数据库毁坏的情况。出现的症状一般是一些类似的Log：invalid block header；illegal block type等。为了避免，请注意以下事项：index cache、data file cache、data cache不可设得太大；模型的density不能太小，最好在5%以上；加载计算大数据量时记得将各个cache加大，否则时间过长。这个错误其实是Essbase的Bug，IBM公司在Essbase的fix4说明文档中“号称”已经解决了此问题，但是似乎依然存在，所以它一直没有得到根除。唯一的办法就是在建模和处理模型时多加小心了。
备份和恢复方法。
1、备份。将database unload；将database的所有文件copy到别的文件夹，所有文件包括：otl所在文件夹里的文件和数据文件。IBM的文档里提到了beginarchive的命令，其实不必要，它也只是给出了需要备份的文件列表而已。
2、恢复。示例：
有一个备份db1，原本属于application app1，数据文件在F盘。现在将它恢复到Essbase系统中。确定Essbase中已经有app1和db1；将db1 unload；将db1的otl所处文件夹的所有文件删除，将备份里的otl文件夹的文件copy到db1的文件夹里；将db1原来的数据文件删除（如果原来的数据文件不是和otl一起存放）；将备份的数据文件copy到F盘的路径：F:$ArborPathappapp1db1下，$ArborPath是Essbase的除掉盘符的安装路径。
注意：备份前后的app名字都必须保持一样；数据文件的路径不必完全一样，即备份前后的Essbase安装路径不必完全一样，但是盘符必须一样。
HP-UX下安装DB2 OLAP Server（ESSBASE）
用ioscan -funCdisk查看光驱的dev名称；
mount -o cdcase /dev/dsk/c0t2d0 /cdrom
其中，/dev/dsk/c0t2d0为前面命令看到的设备名。此命令保证mount后ls看到的是小写字母的文件名。以下为简要的安装过程：
1.建立essbase用户（essadmin）和组（ess）；
2.用essadmin安装essbase for HP-UX至路径/essbase下（先建立足够空间的文件系统）；
3.安装完成后，安装补丁（先解包：tar -xvf hpux7.tar）；
4.测试essbase服务能否正常启动；
5.cp /home/informix/etc/odbc.ini /essbase/.odbc.ini；
6.配置essadmin的.profile文件：
cp /essbase/essbaseenv.doc(补丁应用前)或/essbase/essbaseenv.sh(补丁应用后)中有用信息至/essbase/.profile中；
加入：export ODBCINI=/essbase/.odbc.ini
加入：数据库的配置信息，即informix的.profile文件中关于我们所关心的数据库信息的部分
加入：SHLIB_PATH中（essbase的信息已经存在）加入关于informix的odbc驱动程序所在的路径（先确认此路径是否正确）
配置后信息大致如下：
export ARBORPATH=/essbase
export SHLIB_PATH=$SHLIB_PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export PATH=$PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export ODBCINI=/essbase/.odbc.ini
export INFORMIXDIR=/informix
export INFORMIXSERVER=dw
export PATH=$PATH:$INFORMIXDIR/bin
export ONCONFIG=onconfig.dw
export SHLIB_PATH=/home/informix/lib/cli:/home/informix/lib/esql:$SHLIB_PATH
7.配置ODBC：
修改/essbase/.odbc.ini文件，测试，至正确。
配置后信息大致如下：
[ODBC Data Sources]
Infdrv28=INFORMIX 2.8 32-BIT
ceb_dw=INFORMIX 2.8 32-BIT
;
; Define ODBC Database Driver's Below - Driver Configuration Section
;
[ceb_dw]
Driver=/extra/informix/lib/cli/iclis09b.sl（注意文件名是否正确）
Description=INFORMIX 3.3 32-BIT（此驱动即为上面所示文件）
Database=ceb_dw
LogonID=dwtest
pwd=dwtest
Servername=dw
CursorBehavior=0
CLIENT_LOCALE=en_us.8859-1
DB_LOCALE=en_us.8859-1
TRANSLATIONDLL=/extra/informix/lib/esql/igo4a304.sl
[ODBC]
Trace=0
TraceFile=/tmp/odbctrace.out
InstallDir=/extra/informix
注意：Essbase的安装与操作系统的Kernel参数有很大的关系
Kernel参数的修改：
选中sam-Kernel Configuration-Configurable Parameters-Actions(菜单)-Apply Tuned Parameter Set...-General OLTP/Database Server System（或其它）
重启机器。
有时，使用系统提供的模板并不一定能达到Essbase的要求，有可能必须手工修改核心参数。
如果要继续安装JAVA需要如下操作：
cp ARBORPATH/bin/jrte_hp_ess.tar到tmp目录，再用tar xvf *.tar解开。
用sam的进行安装。
将essjava.sh下内容cp到.profile下。
在HPUX上安装Essbase的一个问题及解决方法
1.安装过程中出现如下错误：
./setup.sh[57]: ulimit: The specified value exceeds the user's allowable limit.
The user limit on this server is too low to run the OLAP installation.
The installer was not able to _update the user limit. Please add the
following to your profile file and log out and back into the server
to _update the user limit setting.
ADD TO YOUR PROFILE FILE:
ulimit -s 32000
Unsetting JAVA_HOME and JREHOME for this session.
经分析确认，这是系统核心参数maxssiz及maxssiz_bit64（堆栈段）设置太小的缘故。将其加大即可。maxssiz最大可到400M左右，我设成了256M，即：0x010000000；maxssiz_bit64可大些，我设成了1G，即：0x040000000。重构内核后重启系统。
2.建立用户时选用的shell方式不同，安装过程遇到的问题也不同：
如果选sh，就会出现上面的错误，安装不能继续下去；
选ksh，安装时会出现：
./setup.sh[15]:ulimit:bad option(s)
./setup.sh[56]:test:argument expected
./setup.sh[60]:test:argument expected
然后可以继续下去，但会出现coredump的错误。看来，我们还是选择sh为好。
AIX下Essbase 8.1的安装
划分相应的磁盘空间，建立文件系统；
创建用户和组：essadmin/olap（用户名、组名可自行决定）；
设置正确的权限关系等；
上传安装文件和补丁；
以上工作完成后，以essadmin用户登录进行安装，安装过程大体如下：
装补丁：
修改.profile文件：
将essbaseenv.sh中的三句加入到.profile中；
运行.profile文件（. .profile），启动essbase服务（ESSBASE password）
系统安装完成启动服务后，用Application manager去测试，如果正常，则安装成功。（如果出现：“unrecognized command”的错误提示，是因为server的版本低于客户端的版本。）
[@more@]ESSBASE的使用及优化
这是essbase的上手使用说明
ESSBASE的使用及性能优化
计算脚本相关
Essbase中，一个指标可以通过计算公式调用自己得到，用@SHIFT函数实现。
如：
B C
-------
B1 C1
B2 C2
B3 C3
…
其中，C2=C1+B2;C3=C2+B3 …
那么，指标C就可用公式：@SHIFT(C,-1)+B来实现。
数据加载不进的问题，某个维存在空值的情况，或事实表数据没有清洗干净，报错如下：
不选时间维的计算公式：
IF(@ISGEN("sj",1))
#MISSING;
ELSE
qmqsye-bqxzqs;
ENDIF;
ESSBASE求百分比指标：
number%number->Year->Market->Product->Scenario;
求同期值公式：
IF(@ISGEN("D_Date",6))
(@MDSHIFT(set01, -36,"D_Date",@GENMBRS ("D_Date",6)));
ELSEIF(@ISGEN("D_Date",5))
(@MDSHIFT(set01, -12,"D_Date",@GENMBRS ("D_Date",5)));
ELSEIF(@ISGEN("D_Date",4))
(@MDSHIFT(set01, -4, "D_Date",@GENMBRS ("D_Date",4)));
ELSEIF(@ISGEN("D_Date",3))
(@MDSHIFT(set01, -2, "D_Date",@GENMBRS ("D_Date",3)));
ELSEIF(@ISGEN("D_Date",2))
(@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",2)));
ENDIF;
求前期值公式：
IF(@ISGEN("D_Date",7))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",7));
ELSEIF(@ISGEN("D_Date",6))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",6));
ELSEIF(@ISGEN("D_Date",5))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",5));
ELSEIF(@ISGEN("D_Date",4))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",4));
ELSEIF(@ISGEN("D_Date",3))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",3));
ELSEIF(@ISGEN("D_Date",2))
@MDSHIFT(set01, -1, "D_Date",@GENMBRS ("D_Date",2));
ENDIF;
国税求同期值公式：
IF (@ISGEN ("时间",5)) "去年同期欠缴税额"=@PRIOR ("本期欠缴税额",365,@genmbrs("时间", 5));
ELSEIF (@ISGEN ("时间",4)) "去年同期欠缴税额"=@PRIOR("本期欠缴税额",12,@genmbrs("时间", 4));
ELSEIF (@ISGEN ("时间",3)) "去年同期欠缴税额"=@PRIOR ("本期欠缴税额", 4,@genmbrs("时间", 3));
ELSEIF (@ISGEN ("时间",2)) "去年同期欠缴税额"=@PRIOR ("本期欠缴税额",1,@genmbrs("时间", 2));
ENDIF;
国税求前期值公式：
IF (@ISGEN ("时间",5)) "上期欠缴税额"=@PRIOR ("本期欠缴税额",1,@genmbrs("时间", 5));
ELSEIF (@ISGEN ("时间",4)) "上期欠缴税额"=@PRIOR("本期欠缴税额",1,@genmbrs("时间", 4));
ELSEIF (@ISGEN ("时间",3)) "上期欠缴税额"=@PRIOR ("本期欠缴税额", 1,@genmbrs("时间", 3));
ELSEIF (@ISGEN ("时间",2)) "上期欠缴税额"=@PRIOR ("本期欠缴税额",1,@genmbrs("时间", 2));
ENDIF;
Unix下后台启动和停止Essbase服务
启动命令：
nohup ESSBASE password -b &
停止方法：
手动：交互式，在esscmd中用shutdownserver命令，根据系统提示完成。
脚本：echo "login essadmin password on localhost;alter system shutdown;exit;" | essmsh –i
HP-UX下配置Essbase连本机Oracle 8i的ODBC
配置环境
HP-UX
IBM DB2 Olap Sever7.1
Oracle817
配置.profile
将Oracle的.profile文件环境变量内容copy到essadmin的.profile文件。
[注]：根据实际情况修改至.profile文件正确，不要引起两个.profile文件间内容的冲突。
例如：
export ARBORPATH=/essbase
export SHLIB_PATH=$SHLIB_PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export PATH=$PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export ODBCINI=/essbase/.odbc.ini
PATH=$ORACLE_HOME/bin:$PATH;export PATH
LD_LIBRARY_PATH=$ORACLE_HOME/lib64;export LD_LIBRARY_PATH
ORACLE_BASE=/oracle;export ORACLE_BASE
ORACLE_HOME=$ORACLE_BASE/ora817;export ORACLE_HOME
NLS_LANG="AMERICAN_AMERICA.ZHS16CGB231280"
ORA_TERM=hp;export ORA_TERM
ORACLE_SID=DW;export ORACLE_SID
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data;export ORA_NLS33
SHLIB_PATH=$ORACLE_HOME/lib:/usr/lib:$SHLIB_PATH;export SHLIB_PATH
TMPDIR=/oracle/tmp
umask 022
配置关于oracle的odbc
得到.odbc.ini文件模板
运行$ARBORPATH下的inst-sql.sh，将在$ARBORPATH下生成.odbc.ini文件。
配置.odbc.ini
vi .odbc.ini，编辑得到类似如下内容：
[ODBC Data Sources]
dw=INTERSOLV 3.11 Oracle 8 Driver
[dw]
Driver=/essbase/dlls/ARor815.sl
Description=Oracle8
ServerName=dw
[ODBC]
Trace=0
TraceFile=odbctrace.out
TraceDll=/essbase/dlls/odbctrac.sl
InstallDir=/essbase/dlls
[注]：默认的Driver为ARor813.sl，对于oracle817数据库，Driver应改为ARor815.sl。
测试
用Essbase的终端(Application Manager)测试odbc是否配通。
小结
配置HPUX下Essbase连本机Oracle的ODBC，比较简单，不用像Informix安装Client端，直接使用Essbase自带的driver。只需修改.profile和.odbc.ini文件。
AIX下配置Essbase到本机DB2的ODBC过程
整个过程分为两个步骤：
配置ODBC：
以下是万佳BI项目Essbase for AIX的ODBC的配置过程：
在万佳BI项目中，配置从DB2到Essbase的ODBC过程如下：
3．以admin登录（如果Essbase的user为admin），编辑admin用户的.profile文件，加入如下部分：
. /db2system/db2inst1/sqllib/db2profile（与DB2的安装路径有关）
export ARBORPATH=/essbase（essbase的安装路径）
export LIBPATH=$LIBPATH:$ARBORPATH/bin:$ARBORPATH/dlls
export PATH=$PATH:$ARBORPATH/bin:$ARBORPATH/dlls
#export ODBCINI=/home/admin/.odbc.ini
（以上部分的第一句最重要，最后一句可以不要）
4。logout并再次login用户admin，运行/essbase/inst-sql.sh；
提问：intersolv or IBM-DB2?
选择：DB2
5。编辑admin用户下（/home/admin/）的.odbc.ini文件，确保有如下部分：
例：
[ODBC Data Sources]
DWCN=IBM DB2 ODBC Driver
[DWCN]
Driver=/db2system/db2inst1/sqllib/lib/db2.o（与DB2的安装路径有关）
Description=DB2
Host=aixf85（主机名）
Database=dwcn（数据库名）
#Username=db2inst1（用户名，可不输入）
#Password=（此外即使输入口令也无用）
6。在命令行下运行：
su - admin
ESSBASE password
7。在NT客户端打开Application manager，在任意一个正常的Database上建立一个新的rule，并用此rule的open sql去测试以上对ODBC配置的正确性。
Catalog DB：
上面的过程完成之后，如果直接使用，对于数据量小的load data过程偶而可以正确完成，但对于大数据量的load data过程不能正确完成，系统提示网络方面的错误（如图所示）。
我认为，出现这个问题是因为同一台主机上共存DB2和Essbase，在.odbc.ini中指定的数据源是直接到本机数据库中找到的，而不是通过网络。这种通讯方式是Essbase不能接受的。试想如果DB2和Essbase分别装在不同的机上，在Essbase这台机上最终势必要配置连到目标DB的ODBC（也就是配置.odbc.ini文件），该ODBC中的数据源指定的DB就一定要通过网络了，也就是说这个目标DB是Essbase这台机器认识的（一般是安装了该种DB产品的客户端），这就要首先建立连到目标DB的ODBC。因此，如果DB2和Essbase在同一机上的时候，就少了这一个过程。
因此，还必须做如下方面的工作：
1.db2 catalog tcpip node vgsznode(新的节点名) remote 168.1.6.152(IP地址) server 50000(端口号)；
2.db2 catalog db dwcn as szdc(dwcn的别名) at node vgsznode；
3.编辑Essbase用户下的.odbc.ini文件，将数据源的名字指定为szdc。
通过如上操作，就相当于通过网络建立了一个连到DB2的ODBC。这样，以后在Essbase中open SQL的时候就要选szdc了。
Essbase的一些初级问题
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文件损坏的问题。就目前我们的认识程度来说，大概是这样的吧。
Essbase中Database的备份与恢复的经验
Essbase数据的备份不同于一般的数据库系统。数据库有成熟的备份机制，可以离线备份、在线备份、增量备份，并且还有回滚（roll back）等等数据保护机制，保证数据的实时性与正确性。而Essbase的备份机制相比就要差很多，它是一种文件系统，说到备份，其实就是备份相应的数据与系统文件。
对于任何一个database来说，.otl和.rul文件是可以不受路径限制进行备份和恢复的。但用这些文件恢复的database只是恢复了database的结构（outline和rule），没有恢复数据。有时，我们备份与恢复是希望保留数据的。
带数据Essbase模型的备份与恢复，适用于本机database的备份与恢复，也适用于不同主机间数据的移植（不同主机的Essbase安装路径很可能不同）。
带数据Essbase模型的备份与恢复，分为源与目的database的路径相同与不同两种情况，不论什么情况，备份与恢复的方法一律相同。
我们知道，每个database的索引与数据文件默认是放在APP下该database所在的文件夹下的。如果用户没有改变这个路径，备份与恢复问题就变得非常简单了：
方法一
1. unload你想备份的database；
2. 复制该database的文件夹；
3. 在目的端重建相同名称的APP以及你要恢复的database，并unload db；
4. 用你已经复制的database文件夹覆盖新建的database的文件夹；
5. load db，成功！
方法二
如果源database指定了数据存放的路径，备份与恢复就相应变得复杂起来，不仅要备份源database文件夹，还要备份相应的索引和数据文件。具体作法如下：
1. unload你想备份的database；
2. 复制该database的文件夹；
3. 在目的端重建相同名称的APP以及你要恢复的database，并unload db；
4. 用你已经复制的database文件夹覆盖新建的database的文件夹；
5. 复制源database的索引和数据文件夹；
6. 在目的机硬盘上（与源database的索引及数据文件所在的盘符相同，如果没有，可以用虚拟盘的方法，用subst命令。例：subst H: e:H）建立与目的机上该database所在路径相同的路径，并将已复制的源database索引和数据的文件夹粘贴到此处；
7. 打开application manager，在该database的菜单database/setting/storage中设置location为源database的盘符；
8. load db，成功！
影响模型数据易忽略的两点
未更新视图！如果某模型的加载视图是一个多层的视图，若只对上层视图进行了改动，而最下层的视图没有重新组织，加载计算后的结果就会出现问题。因此，总结一下得出结论，如果一个view的数据源的结构发生了变化，就一定要重新建立view。
注意用union all，而不是union！主题数据加载的时候，如果数据来源于多个表，一定要注意union语句的写法，否则会造成数据丢失。
关于Essbase的加载、计算的优化
设计，设计，还是设计
1. 在outline中选定适当的dense/sparse维及其顺序、设定动态计算
2. 组织加载数据
3. 设定各种Cache
4. 设定Commit Blocks
5. 其它调整
6. ……
以上简要说明了对于一个Essbase模型来说，如何去优化加载、计算的性能。重要性按以上的递减顺序排列。
对于一个设计得较差的模型来说，性能调优的意义是不大的，因此，模型的设计是最为关键的。
在outline中，对于dense/sparse维的选择是至关重要的。一定要根据实际情况、根据经验，做许多测试，最终选择一种最优的设置方案。这一步比较重要，它对将来模型的稳定性、速度、数据量等等都有直接影响。在dense/sparse已经确定的情况下，一般要将dense维按照成员数由多到少的顺序放在最上面，而sparse维按照成员数由少到多的顺序放在下面。另外，如果有属性维，则一定要放在最下面。一定不要忘了对可以设置动态计算的dense维设置动态计算，这样对提高计算性能和减小数据量都很有帮助。尽量不要对sparse维设置动态计算，因为它会在加载时影响许多blocks。
组织加载数据。尽量精简加载表的结构或使用加载view。在数据加载的open sql中的order by对加载的性能影响非常大。大家在做的应用的时候可以做些实验。以我们的模型supstk为例，当时也做了order by，只不过是按sparse维从小到大的顺序，用时5个小时左右；但重新按sparse维从大到小的顺序order by后，加载只用时78分钟！可见这一因素对性能影响之大。
各种cache值的设置，对于模型的性能影响也非常之大。其中影响最大的莫过于calculator cache。对于这个cache的设置附录中有详细说明。当然，这些经验都利益于Essbase提供的两个PDF文档，如果有时间，建议大家多看看，确实很有用。此外，对于Index Cache、Data Cache和Data File Cache也一定要做相应设置！
如果内存很多，模型很大，建议Commit Blocks设置为10000，这是个经验数值。不过我感觉这个参数的设置对性能的影响不是太大。大家可以试试其它值。
下面具体分部分地进行介绍：
Database的设计
最重要是dense，sparse的设置。维设置的不同，可能会大大影响到加载计算的性能。设置因每个模型的维个数、数据情况而有不同。原则是使density/block number最大。如何知道各个维的density和block number？有一个简易的方法，使用的前提条件是已经知道database的数据源和部分真实数据。以下是示例：
假定database有两个dense维，三个sparse维
cells1 = _select count(*) from fact_table
block size = dense1_ * dense2
block number = _select count(*) as "block number" from (_select 1 from fact_table group by sparse1,sparse2,sparse3) a
density = cells/(block number_ * block size)
其中，fact_table是已对所有维group by的最终的事实表，dense1和dense2分别是dense维的成员数（不包括动态计算），
block number*block size等于潜在最多的cell，而上述cells1的值等于实际存在的cell数，两者相除就等于加载后计算前的density，而模型计算完成后，一般来说density会有所增大。
知道了各个维的密度后，可以确定维的排列顺序。应当把dense维放在sparse上面，dense维和sparse又分别从小到大地排列，使整个Otl看来像两个叠加的三角形。
尽可能地让dense维的个数和sparse维的个数持平。让block size保持在1k~100k内。
Database设计是否合理，还可以用加载、计算、查询的速度来衡量，因此，可以先定义好几种结构，用少量测试数据测试。
一般data block size越大，计算越快而查询越慢。
设计的好坏对加载计算的快慢有很大影响。所以，尽量不要让你的维有一个超过1000 children的成员；尽量减少维的个数；尽量减少维成员数，特别是那些成员数本来就少的维；将Measure这个成员设为label only。。。
加载
由于在Unix下是区分大小写的，因此，在加载计算等的脚本中的“app”、“db”与“rul”名必须与服务器application manager中的完全相同，否则就会出现load app失败、load db失败或加载数据不会找到rule file的情况。
加载前必须将事实表按照维字段Group By。
当加载大数据量的模型时，必须注意性能优化。优化前后的加载时间可以相差好几倍。优化示例如下：
假设database有三个sparse维S1，S2，S3，分别对应事实表字段也是S1，S2，S3，它们在Otl中的排列是S1->S2->S3。当你建rule file时，选择Open SQL后，在SQL框写_select_ * from fact_table order by S3,S2,S1。请留意黑体部分，Order By的是稀疏维，顺序是Otl中稀疏维排序的倒序。我作了测试，一个数据量达到1000万的模型，本来加载时间是3.5小时，加了黑体部分后，变为40分钟，而且数据量越大效果越明显。
参数的设置。
选中一个database，看settings，翻到storage页，其中有三个重要参数：index cache 、data file cache、data cache。当数据量很大时，将他们加大10～20倍，否则加载时间将是非常惊人的。不过需要注意的是，设置的数值不能太大，首先它们的总和不能大于你的系统现在剩余内存，否则效果可能适得其反；再就是如果他们中有一个的数值太大，例如data file cache超过1G，加载很可能会出现错误，数据库会毁坏。
计算
首先，计算的性能很大程度上依赖于database的维设计。一个糟糕的设计可以让任何的tuning失去意义。设计和计算应该是个循环的过程，即不断地用计算检测设计的合理性。
mutiple bitmap的使用。
Database的计算可以使用两种bitmap，single bitmap和multiple bitmap。bitmap用来在计算时追踪当前member的children的值，因为essbase的运算大部分是children的值的向上聚合，而使用了multiple bitmap使追踪速度加快，也就加快了计算的速度。使用的方法如下：
计算是否使用Mutiple Bitmap与Calc Cache的大小有关。假设database有三个sparse 维S1、S2、S3，在Otl的排列是S1->S2->S3。如果要使用Mutiple Bitmap，
calc cache in byte >= S1_ * S2_ * （2 + ParentNumber） / 8
database的Calc Cache应大于等于这个数才可以使用Mutiple Bitmap。其中，ParentNumber是你的Database中任何一个Member所拥有的最大Parent数。除非有Share Member，ParentNumber一般是1。如果有Share Member并且最多Share了X次，那么ParentNumber就是1+X。
但是，虽然IBM的许多文档都说Mutiple Bitmap的计算比Single Bitmap的计算好的多，它仍然与模型的结构有很大的关系。如果不管什么结构都坚定不移地使用Multiple Bitmap，效果可能是相反的，即可能Single比Multiple还快，尤其是Block Number很多的时候。我的经验是：当错误使用了Mutiple时，它的速度比Single会慢2～10倍。此时，可以适当增大block size，减少block number。虽然Tuning很麻烦，不过当正确使用了Mutiple Bitmap时，它的性能比所有结构的Single Bitmap计算都要好。
对计算有影响的参数
在加载部分提到的三个cache 对计算也起了同样重要的作用，不过使用也要非常小心。
当加载的数据都在level0上时，可以选择在settings->general页的aggregate missing value，可以使计算速度提高1%~30%。
Settings->transaction页的commit point可以设为10000。
当database只需计算一次时，可以将计算中的clearupdatestatus关掉：set clearupdatestatus off。这样可以省掉一些更新data block状态的操作。
动态计算的使用。
将measure上的一些有公式的member设为动态计算。
将dense维的parent成员设为动态计算。它会降低查询速度，不过当服务器的CPU够快，影响不大。
不建议使用稀疏维的动态计算。因为它牵涉的Data Block太多，会大大影响查询的速度。应该仔细地衡量计算与查询的关系。如果计算实在太慢，又存在某些density很低、成员数很少的稀疏维，那么可以将它设为动态计算。
维修改
影响维修改的最大因素是otl和数据文件的大小。Otl的影响原因很明显，而数据文件之所以也有影响是因为每增加一个成员或改变一个成员的属性（parent、别名等），它对应的data block都会随之变化，essbase就在改变data block这个操作上花费时间，就算不用改变data block，也在查找data block的过程中花费了时间。经验：一个database，无数据时作维修改3分钟，当数据文件10G时，维修改45分钟。
通过Rule File的维修改不能删除成员。
当维修改时，如果改变了某些有数据的成员的parent，那么它对应的data block也就设为了dirty的状态。由于维修改可能会改变data block，当智能化计算开启时，下次的计算要重新计算这些data block。
分区
建议使用transparent类型的分区。因为它实现简单有效，并且适用于绝大多数的情况。相比下，link类型分区比较麻烦；replicate类型分区传输数据太慢。
在area页上，指定的是源和目标的对应数据块。数据块大小相同就行了，两边的维不必相同。不同的维和指标要在mapping 中指出。示例：
源的维和指标： dim1,dim2,dim3,measure1,measure2
目标的维和指标：dimA,dimB,measureA。
源area 目标area 源mapping 目标mapping
(@idescendants(dim1) @idescendants(dim2) @idescendants(dim3)
“measure1””measure2”) (@idescendants(dimA) @idescendants(dimB)
“measureA”) Dim3 void
Measure1 measureA
Measure2 void
备份与恢复
为什么要备份？
当数据量比较大，处理的时间比较长时，database有可能毁坏。尤其是像万佳BI这种需要每日进行计算的database，如果没有备份而出现问题，那么所有的数据都要重新计算，耗费时间太长。
毁坏的原因？
1、数据库在加载、计算、维修改时出现异常情况，如断电、系统DOWN机、人为杀掉进程等。当一个application Load起来时，系统中会有一个Esssvr的进程，而它下面的database Load起来后都归Esssvr管理。这类事故的实质就是非法中止了Esssvr进程，在这个进程中正在加载、计算、维修改（不包括查询数据）的所有database会毁坏。
2、Essbase的内核错误。当数据量很大，加载、计算时间很长时就有可能出现数据库毁坏的情况。出现的症状一般是一些类似的Log：invalid block header；illegal block type等。为了避免，请注意以下事项：index cache、data file cache、data cache不可设得太大；模型的density不能太小，最好在5%以上；加载计算大数据量时记得将各个cache加大，否则时间过长。这个错误其实是Essbase的Bug，IBM公司在Essbase的fix4说明文档中“号称”已经解决了此问题，但是似乎依然存在，所以它一直没有得到根除。唯一的办法就是在建模和处理模型时多加小心了。
备份和恢复方法。
1、备份。将database unload；将database的所有文件copy到别的文件夹，所有文件包括：otl所在文件夹里的文件和数据文件。IBM的文档里提到了beginarchive的命令，其实不必要，它也只是给出了需要备份的文件列表而已。
2、恢复。示例：
有一个备份db1，原本属于application app1，数据文件在F盘。现在将它恢复到Essbase系统中。确定Essbase中已经有app1和db1；将db1 unload；将db1的otl所处文件夹的所有文件删除，将备份里的otl文件夹的文件copy到db1的文件夹里；将db1原来的数据文件删除（如果原来的数据文件不是和otl一起存放）；将备份的数据文件copy到F盘的路径：F:$ArborPathappapp1db1下，$ArborPath是Essbase的除掉盘符的安装路径。
注意：备份前后的app名字都必须保持一样；数据文件的路径不必完全一样，即备份前后的Essbase安装路径不必完全一样，但是盘符必须一样。
HP-UX下安装DB2 OLAP Server（ESSBASE）
用ioscan -funCdisk查看光驱的dev名称；
mount -o cdcase /dev/dsk/c0t2d0 /cdrom
其中，/dev/dsk/c0t2d0为前面命令看到的设备名。此命令保证mount后ls看到的是小写字母的文件名。以下为简要的安装过程：
1.建立essbase用户（essadmin）和组（ess）；
2.用essadmin安装essbase for HP-UX至路径/essbase下（先建立足够空间的文件系统）；
3.安装完成后，安装补丁（先解包：tar -xvf hpux7.tar）；
4.测试essbase服务能否正常启动；
5.cp /home/informix/etc/odbc.ini /essbase/.odbc.ini；
6.配置essadmin的.profile文件：
cp /essbase/essbaseenv.doc(补丁应用前)或/essbase/essbaseenv.sh(补丁应用后)中有用信息至/essbase/.profile中；
加入：export ODBCINI=/essbase/.odbc.ini
加入：数据库的配置信息，即informix的.profile文件中关于我们所关心的数据库信息的部分
加入：SHLIB_PATH中（essbase的信息已经存在）加入关于informix的odbc驱动程序所在的路径（先确认此路径是否正确）
配置后信息大致如下：
export ARBORPATH=/essbase
export SHLIB_PATH=$SHLIB_PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export PATH=$PATH:$ARBORPATH/bin:$ARBORPATH/dlls
export ODBCINI=/essbase/.odbc.ini
export INFORMIXDIR=/informix
export INFORMIXSERVER=dw
export PATH=$PATH:$INFORMIXDIR/bin
export ONCONFIG=onconfig.dw
export SHLIB_PATH=/home/informix/lib/cli:/home/informix/lib/esql:$SHLIB_PATH
7.配置ODBC：
修改/essbase/.odbc.ini文件，测试，至正确。
配置后信息大致如下：
[ODBC Data Sources]
Infdrv28=INFORMIX 2.8 32-BIT
ceb_dw=INFORMIX 2.8 32-BIT
;
; Define ODBC Database Driver's Below - Driver Configuration Section
;
[ceb_dw]
Driver=/extra/informix/lib/cli/iclis09b.sl（注意文件名是否正确）
Description=INFORMIX 3.3 32-BIT（此驱动即为上面所示文件）
Database=ceb_dw
LogonID=dwtest
pwd=dwtest
Servername=dw
CursorBehavior=0
CLIENT_LOCALE=en_us.8859-1
DB_LOCALE=en_us.8859-1
TRANSLATIONDLL=/extra/informix/lib/esql/igo4a304.sl
[ODBC]
Trace=0
TraceFile=/tmp/odbctrace.out
InstallDir=/extra/informix
注意：Essbase的安装与操作系统的Kernel参数有很大的关系
Kernel参数的修改：
选中sam-Kernel Configuration-Configurable Parameters-Actions(菜单)-Apply Tuned Parameter Set...-General OLTP/Database Server System（或其它）
重启机器。
有时，使用系统提供的模板并不一定能达到Essbase的要求，有可能必须手工修改核心参数。
如果要继续安装JAVA需要如下操作：
cp ARBORPATH/bin/jrte_hp_ess.tar到tmp目录，再用tar xvf *.tar解开。
用sam的进行安装。
将essjava.sh下内容cp到.profile下。
在HPUX上安装Essbase的一个问题及解决方法
1.安装过程中出现如下错误：
./setup.sh[57]: ulimit: The specified value exceeds the user's allowable limit.
The user limit on this server is too low to run the OLAP installation.
The installer was not able to _update the user limit. Please add the
following to your profile file and log out and back into the server
to _update the user limit setting.
ADD TO YOUR PROFILE FILE:
ulimit -s 32000
Unsetting JAVA_HOME and JREHOME for this session.
经分析确认，这是系统核心参数maxssiz及maxssiz_bit64（堆栈段）设置太小的缘故。将其加大即可。maxssiz最大可到400M左右，我设成了256M，即：0x010000000；maxssiz_bit64可大些，我设成了1G，即：0x040000000。重构内核后重启系统。
2.建立用户时选用的shell方式不同，安装过程遇到的问题也不同：
如果选sh，就会出现上面的错误，安装不能继续下去；
选ksh，安装时会出现：
./setup.sh[15]:ulimit:bad option(s)
./setup.sh[56]:test:argument expected
./setup.sh[60]:test:argument expected
然后可以继续下去，但会出现coredump的错误。看来，我们还是选择sh为好。
AIX下Essbase 8.1的安装
划分相应的磁盘空间，建立文件系统；
创建用户和组：essadmin/olap（用户名、组名可自行决定）；
设置正确的权限关系等；
上传安装文件和补丁；
以上工作完成后，以essadmin用户登录进行安装，安装过程大体如下：
装补丁：
修改.profile文件：
将essbaseenv.sh中的三句加入到.profile中；
运行.profile文件（. .profile），启动essbase服务（ESSBASE password）
系统安装完成启动服务后，用Application manager去测试，如果正常，则安装成功。（如果出现：“unrecognized command”的错误提示，是因为server的版本低于客户端的版本。）
[@more@]ESSBASE的使用及优化
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16396910/viewspace-1029063/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/16396910/viewspace-1029063/
3129
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
