缓存在obiee里面有三级缓存:
DB缓存->OBIEE Server缓存->Presentation 缓存（web的ie缓存）
1）对于DB缓存，就是sql的解析问题，可以通过更改sql来完成，对于到obiee上就是更改request或者filter，只要最终生成sql和之前不同即可。这是DB的缓存机制。
2）对于OBIEE机制里面的缓存，详细内容后面总结，现在tips里面就说如何清除。
方法1.登录admin tool，manager->cache->select->purge
方法2.登录web，在setting->Administration->Issue SQL
Call SAPurgeAllCache(); --Purge all the cache
Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );
Call SAPurgeCacheByQuery('select lastname, firstname from employee where salary > 100000' );
Call SAPurgeCacheByDatabase( 'DBName' );
方法3.做一个bat文件，里面的内容就是
nqcmd -d AnalyticsWeb -u Administrator -p Administrator -s purge.txt
当然purge.txt里面的内容就和方法二里面的一样了。
3）对于Web缓存，就简单的多了，出问题了，自己点击报表左下角的刷新按钮或者在modify页面里面时，results下的刷新按钮就可。
OBIEE缓存：1.用途 2.设置（admin tool，config）3.缓存方式 4.缓存重用的情况 5.ibot的seed cache 6.缓存思考
1.OBIEE的缓存和以前的各种缓存意义一样，都是为了运行效率的提高，对于一些重复使用率高的报表，解析到后台就是sql，可以一次使用，然后缓存到server中，如果在
有效时间内有相同或类似请求的时候就会直接返回结果，或者只经过presentation端的处理即可返回结果。
2.在admin tool里面的物理层，对于每个表General属性，有Cacheable选项，子项还有1.（never expires）缓存永不过期 2.（persistence time）缓存保留时间
对于数据量小而且数据更新频率较高的表，不需缓存。
在nsconfig.ini(OracleBI/Server/Config)里面有cache项，首先enable。子项有：
1).DATA_STORAGE_PATHS 毫无疑问，就是cache文件存储的地方。
2).MAX_ROWS_PER_CACHE_ENTRY 每个cache了条目最多有多少行。如果某个查询超出了设定值，该查询将无法cache。
3).MAX_CACHE_ENTRY_SIZE 每个cache条目的最大size，如果超出了，同上。
4).MAX_CACHE_ENTRIES 最多多少个cache条目。
5).POPULATE_AGGREGATE_ROLLUP_HITS:默认情况下，如果新的查询中aggregate使用了cache的话，那么不会加入到cache中，但是该选项覆盖默认选项，加入cache。
NQConfig.ini
[ CACHE ]
ENABLE = YES;
DATA_STORAGE_PATHS = "e:/OracleBIData/cache" 500 MB;
MAX_ROWS_PER_CACHE_ENTRY = 100000; // 0 is unlimited size
MAX_CACHE_ENTRY_SIZE = 1 MB;
MAX_CACHE_ENTRIES = 1000;
POPULATE_AGGREGATE_ROLLUP_HITS=YES;
在server运行期间，某查询第一次执行会做cache，在新的查询产生的时候，他会先去确认是否有cache可用，当可用的时候，该cache条目的Last Used会更新，而新查询也无须在发送查询到DB，直接由OBIEE Server返回结果，无cache可用时会加入到cache中去，当cache里面所有的条目超出MAX_CACHE_ENTRIES时，会按照LRU(least recently used)算法将Last Used最早的拿出去，这就可能导致将最常用的而现在没用的查询给清除掉。
上面问题就需要ibot 的For seeding cache。
3. OBIEE还提供一种事务表（event table）的方式来动态追踪表的变化来决定Cache是否purge。表结构如下：
create table UET (
UpdateType Integer not null, --一般为1
UpdateTime date DEFAULT SYSDATE not null, --最新的更新时间，必须唯一
DBName char(40) null,
CatalogName varchar(40) null,
SchemaName varchar(40) null,
TableName varchar(40) not null,
Other varchar(80) DEFAULT NULL
);
原理：当DB中表数据发生变化（如etl过程导致）之后，会由DB的trigger向事务表插入一条记录来表示某table的最后更新时间(UpdateTime)，然后OBIEE会每隔一定时间会去Check该表数据，如果检测到某表的updatetime在上次和本次检查时间之间，则purge掉该表的cache。在下次查询时候重建cache。
操作：1.建表，字段名可以不同，顺序必须相同，建议时间系统的script。
2.建相应trigger
3.import into Admin tool/Physical Table(确保有读写权限)该表不需要亦不会cache
3.Admin Tool/tools/utilities/Oracle BI Event Table/Event Table <----->Polling frequency：不小于10min，若小于10min，则可以cancel cache。
4.缓存重用的情况，这问题好像不是很重要。
大约列一下：（前提：Cache中的Base查询(A)，新查询(B)）
B的查询列是A查询列的子集。
B的where条件是基于A的条件。
B的查询列可以通过A的结果汇总得到。
A的查询有distinct，B的没有，其他一直也无法走cache。
所以在Seed Cache的时候要，1.select list里面都是单值，没有表达式，2.没有where条件，3.对于cost大的且重用较多的
Hints:当MAX_CACHE_ENTRY_SIZE设置大于DATA_STORAGE_PATHS下的实际值的时候，会导致cache失败。
当OBIEE的request中包含如下函数：CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIME, RAND, POPULATE的时候，不会cache。
当一个查询超时或者取消的话，不会产生cache。
当查询返回行数过多或者size过大。
当作offline或者online的开发的时候，最好清掉cache。
当dynamic repository variable变化的时候，其相关的cache都会自动清掉。可利用于For seeding cache之前的purge cache（？）
(When the Oracle BI Server refreshes repository variables, it will examine business models to determine if they reference those repository variables. If they do, the Oracle BI Server purges all cache for those business models.)
在seed cache的时候，个人认为可以通过usage tracking抓取使用最多的sql来做cache。
参考：http://www.dmresearch.net/research/shujucangku/200901/124443.html