欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

OBIEE清除缓存

程序员文章站 2022-05-24 08:40:28
...

问题:

由于底层事实表的基础上又增加了聚合表,聚合表是利用kettle去定时聚合的。不过很有可能聚合表还没将数据聚合OK时(因为聚合的时间可能比较长),用户已经进行了查询,导致了缓存,以后即使聚合完成了,在不清除缓存的情况,依然查不到最新的数据。

 

方案一:在用户反馈查询不到最新数据时,手动的利用admin Tool中的cache管理工具,进行清除缓存。

 

评估:

1,用户反馈才知道要清除缓存。这样带来的用户体验不好。

2,界面上管理还是挺方便的。可以指定清除哪张表,或者全选进行清除,也可以清除某个用户的缓存。

 

方案二:OBIEE提供了一种事件表(event table)的机制,

该表的结构如下:

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
);

利用 admin Tool中tool->utilities->oracle BI Event Tables指明BIEE需要轮询的表,这里即为UET,可以为多张。

 

在ETL过程结束后,向该事件表中插入一条记录,记录那张表的数据进行了更新,OBIEE会每隔一定时间会去Check该表数据,如果检测到某表的updatetime在上次和本次检查时间之间,则purge掉该表的cache。相应事件表里的记录也会被清除掉。在下次查询时候重建cache.

 

评估:

1,这样就要求kettle聚合完成一张表后,就要像该表写入一行记录。同时还得新建一张表。

2,需要在kettle的聚合的最后加入一条sql执行语句。增加了维护成本。

3,同时时间上还需要等待biee轮询时间到了,数据才会更新。一般biee建议,轮询时间大于10分钟,时间太短,就没必要对某张表做缓存了。所以缓存的更新不是及时的。

4,间隔的轮询,在某种程度上对数据库造成了查询压力。

 

注:我在本地按照这种方式测试没有成功,要么报:“查询表失败”,要么就报“错误的模式”的错误。网上查了说"错误的模式"要求必须按照odbc 3.5的方式import事件表到rpd中。但是我的import方式就是这个,依然错误。很诡异。试了好几次,不行。很费解。

有一篇网上的文章写得蛮全的,可以参考下:

http://gerardnico.com/wiki/dat/obiee/event_table

 

方法三:

还可以通过调用nqcmd的方式,发出相关指令。

在windows下有一个odbc client的工具,可以在界面上发出指令。

支持的指令如下:

登录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' );

 

在linux下了,没有界面的话,就只能用命令的方式了:

nqcmd -d tsa -u jianchen -pjianchen -s testCleanCache.sql

testCleanCache.sql该文件的内容如下:

 call SAPurgeCacheByTable('tsamysql','tsa','','tsa_dim_hour')};--表示清除某一张表的缓存

 

评估:

1,该方式依然需要在kettle的聚合过程结尾,执行该命令

2,与方案二比,无需新建表的支持,而且不用轮询,这样没有对数据的查询压力。

3,及时看到缓存更新的效果

4,需要维护相应的执行脚本,不过只要合理管理,应该还是OK的。可以等几张表聚合完成后,再执行几条命令(几条命令放到一个隶属于同一个聚合任务的文件中),这样可以减少维护成本。

 

注:该方案在linux和windows都是可行的。在这里有一个小插曲,由于我们为了缓解数据库的访问压力,所以搞了两个presentation service,对应到的dsn分别为tsa,tsa2,对应不同的rpd,rpd的信息基本一致,除了一个指定访问主库,一个指定访问备库。

我当时只调用了更新tsa的缓存,发现没有效果。当时差点放弃了,因为虽然是两个presentation service,但是他们指向的是同一个catalog,当时以为cache的数据是放在OracleBIData的下面,以为只要清除掉之后,大家都应该会更新数据的。当时怀疑,是不是只清除了tsa的缓存,后来还是试了下,就又更新了tsa2--

nqcmd -d tsa2 -u jianchen -pjianchen -s testCleanCache.sql
如此发现缓存立马被清除了。由此可见,biee的缓存是跟rpd绑定的。
所以如果有人跟我是一样的情况的话,一定要清除两次哦。
综合:
方案二,我测试不成功。
以方案三为主,基本能够满足大部分情况,除非在自己手动补数据的过程中,需要清除缓存的话,可以结合界面工具,自己去操作一把,速度也蛮快的。

查阅文档,具体的支持三种粒度清除缓存:

  • SAPurgeCacheByQuery. Purges a cache entry that exactly matches a specified query. For example, using the following query, you would have a query cache entry that retrieves the names of all employees earning more than $100,000:

    select lastname, firstname from employee where salary > 100000;

    The following call programmatically purges the cache entry associated with this query:

    Call SAPurgeCacheByQuery('select lastname, firstname from employee where salary > 100000' );

  • SAPurgeCacheByTable. Purges all cache entries associated with a specified physical table name (fully qualified) for the repository to which the client has connected. This function takes up to four parameters representing the four components (database, catalog, schema and table name proper) of a fully qualified physical table name. For example, you might have a table with the fully qualified name of DBName.CatName.SchName.TabName. To purge the cache entries associated with this table in the physical layer of the Siebel Analytics repository, execute the following call in a script:

    Call SAPurgeCacheByTable( 'DBName', 'CatName', 'SchName', 'TabName' );

    • Nulls passed as input parameters to SAPurgeCacheByTable serve as wild cards. For example, specifying a database name but leaving the catalog, schema and table names null will direct the function to purge all entries associated with the specified database.
    • Similarly, specifying a table name but leaving database, catalog and schema names null directs the function to purge all cache entries associated with the specified table name. If multiple databases, catalogs or schemas have tables with the specified name, the function will purge all cache entries associated with any of those tables.

      CAUTION:  Leaving all input parameters null directs the function to purge all cache entries associated with the repository.

  • SAPurgeAllCache. Purges all cache entries. The following is an example of this call:

    Call SAPurgeAllCache();