biee_cache缓存.doc_第1页
biee_cache缓存.doc_第2页
biee_cache缓存.doc_第3页
biee_cache缓存.doc_第4页
biee_cache缓存.doc_第5页
已阅读5页,还剩2页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

OBIEE Cache缓存在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 SQLCall SAPurgeAllCache(); -Purge all the cacheCall 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:OracleBIDatacache 500 MB;MAX_ROWS_PER_CACHE_ENTRY = 100000; / 0 is unlimited sizeMAX_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, -一般为1UpdateTime 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。 参考:/research/shujucangku/200901/124443.htmlOBIEE Cache is enabled, but why is the query not cached?Repeatedly customers pose the question OBIEE cache is enabled, but why is the query not cached? The reason why the queries are not cache can be of many reasons. Some of the reasons are: /Non-cacheable SQL function: If a request contains certain SQL functions, OBIEE will not cache the query. The functions are CURRENT_TIMESTAMP, CURRENT_DATE, CURRENT_TIME, RAND, POPULATE. OBIEE will also not cache queries that contain parameter markers. Non-cacheable Table: Physical tables in the OBIEE repository can be marked non-cacheable. If a query makes a reference to a table that has been marked as non-cacheable, then the results are not cached even if all other tables are marked as cacheable. Query got a cache hit: In general, if the query gets a cache hit on a previously cached query, then the results of the current query are not added to the cache. Note: The only exception is the query hits that are aggregate roll-up hits, will be added to the cache if the nqsconfig.ini parameter POPULATE_AGGREGATE_ROLLUP_HITS has been set to Yes. Caching is not configured: Caching is not enabled in NQSConfig.ini file. Result set too big: The query result set may have too many rows, or may consume too many bytes. The row-count limitation is controlled by the MAX_ROWS_PER_CACHE_ENTRY nqsconfig.ini parameter. The default is 100,000 rows. The query result set max-bytes is controlled by the MAX_CACHE_ENTRY_SIZE nqsconfig.ini parameter. The default value is 1 MB. Note: the 1MB default is fairly small. Data typically becomes bigger when it enters OBIEE. This is primarily due to Unicode expansion of strings (a 2x or 4x multiplier). In addition to Unicode expansion, rows also get wider due to : (1) column alignment (typically double-word alignment), (2) nullable column representation, and (3) pad bytes. Bad cache configuration: This should be rare, but if the MAX_CACHE_ENTRY_SIZE parameter is bigger than the DATA_STORAGE_PATHS specified capacity, then nothing can possibly be added to the cache. /Query execution is cancelled: If the query is cancelled from the presentation server or if a timeout has occurred, cache is not created. /bbs OBIEE Server is clustered: Only the queries that fall under “Cache Seeding” family are propagated throughout the cluster. Other queries are stored locally. If a query is generated using OBIEE Server node 1, the cache is created on OBIEE Server node 1 and is not propagated to OBIEE Server node 2 Oracle BI提供的缓存机制可以帮助用户提高对数据的访问速度,大大减少查询的访问时间。在后台数据库发生数据更新后,缓存中的数据就变得陈旧,这时就需要更新缓存中的数据。OBIEE提供了两种清除缓存的方法,自动的和手动的方式。1.手动方式 在管理工具下打开缓存管理器,这里会列出每个用户的缓存使用情况,你可以选中想要清除的缓存项,然后在编辑下点击purge,这样相应的缓存就会被清除,这种方式是需要人工参与的。2.自动方式 在Administrat

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

最新文档

评论

0/150

提交评论