TimesTen 应用层数据库缓存学习：14. 用户自定义(User Managed)缓存
在TimesTen中，read-only, AWT, SWT都属于系统管理的缓存组，而User managed cache group则是用户自定义的缓存组。
When TimesTen manages operations for user managed cache groups, it connects to the Oracle database using the current user’s credentials as the user name and the OraclePwd connection attribute as the Oracle password. TimesTen does not connect to the Oracle database with the cache administration user name and password set with the ttCacheUidPwdSet built-in procedure for user managed cache group operations.
可以定义的属性为:
- READONLY，缺省为可写
- 同步PROPAGATE ，缺省为不同步到Oracle
- AUTOREFERSH
- LOAD CACHE GROUP, REFRESH CACHE GROUP, and FLUSH CACHE GROUP
User Managed缓存组仍然需要主键。
补充一点，User Managerd缓存组的Propagate行为和SWT是一致的，都是先在Oracle中提交，然后在TimesTen中提交。
如果Oracle中失败，则TimesTen端需要手工rollback；如果Oracle中成功而TimesTen中失败，需要手工将TimesTen中的数据补齐，例如用ttCachePropagateFlagSet。
描述如下：
Since the operations in the transaction are applied to tables in both the TimesTen and Oracle databases, the process for committing is as follows:
After the operations are propagated to the Oracle database, the commit is first attempted in the Oracle database.If an error occurs when applying the operations on the tables in the Oracle database, then all operations are rolled back on the tables on the Oracle database. If the commit fails in the Oracle database, the commit is not attempted in the TimesTen database and the application must roll back the TimesTen transaction. If the user tries to execute another statement, an error displays informing them of the need for a rollback. As a result, the Oracle database never misses updates committed in TimesTen.
If the commit succeeds in the Oracle database, the commit is attempted in the TimesTen database.
If the transaction successfully commits on the Oracle database, the user’s transaction is committed on TimesTen (indicated by the commit log record in the transaction log) and notifies the application. If the application ends abruptly before TimesTen informs it of the success of the local commit, TimesTen is still able to finalize the transaction commit on TimesTen based on what is saved in the transaction log.
If the transaction successfully commits on the Oracle database and a failure occurs before returning the status of the commit on TimesTen, then no record of the successful commit is written into the transaction log and the transaction is rolled back.If the commit fails in TimesTen, an error message is returned from TimesTen indicating the cause of the failure. You then need to manually resynchronize the cache tables with the Oracle Database tables.
了解User Manager缓存组的结果可以借助于SQL Developer，见下图：
其中，all tables readonly类似于只读缓存组，Propagate all tables类似于AWT，而varies from table to table则完全是自定义了。
all tables readonly
和read only缓存组不同的一点是，如果缓存组涉及多表，则可以单独指定某些表为readonly。
SQL>
CREATE TABLE active_customer
(custid NUMBER(6) NOT NULL PRIMARY KEY,
name VARCHAR2(50),
addr VARCHAR2(100),
zip VARCHAR2(12),
region VARCHAR2(12) DEFAULT 'Unknown');
SQL> grant select on active_customer to cacheadm;
Grant succeeded.
insert into active_customer values(1, 'A', 'Beijing', '100036', 'CHINA');
insert into active_customer values(2, 'B', 'Shanghai', '122222', 'CHINA');
commit;
cacheadm>
CREATE DYNAMIC USERMANAGED CACHE GROUP "UM_DRO"
FROM
"TTHR"."ACTIVE_CUSTOMER" (
"CUSTID" NUMBER(6) NOT NULL,
"NAME" VARCHAR2(50 BYTE) ,
"ADDR" VARCHAR2(100 BYTE),
"ZIP" VARCHAR2(12 BYTE) ,
"REGION" VARCHAR2(12 BYTE) ,
PRIMARY KEY("CUSTID"), READONLY
)
AGING LRU ON
cacheadm>cachegroups
Cache Group CACHEADM.UM_DRO:
Cache Group Type: User Managed (Dynamic)
Autorefresh: No
Aging: LRU on
Root Table: TTHR.ACTIVE_CUSTOMER
Table Type: Read Only
1 cache group found.
tthr>select * from active_customer;
0 rows found.
tthr>select * from active_customer where custid = 1; <- 满足dynamic load
< 1, A, Beijing, 100036, CHINA >
1 row found.
tthr>insert into active_customer values(3, 'C', 'Guangzhou', '133333', 'CHINA');
8225: Table ACTIVE_CUSTOMER is read only
The command failed.Propagate all tables
和SWT缓存组很类似，无需rep agent，在propagate时，直接利用schema用户访问Oracle，因此也无需再Oracle中赋予更新的权限给cache admin用户。
CREATE USERMANAGED CACHE GROUP "UM_AWT"
FROM
"TTHR"."ACTIVE_CUSTOMER" (
"CUSTID" NUMBER(6) NOT NULL,
"NAME" VARCHAR2(50 BYTE) ,
"ADDR" VARCHAR2(100 BYTE),
"ZIP" VARCHAR2(12 BYTE) ,
"REGION" VARCHAR2(12 BYTE) DEFAULT 'Unknown',
PRIMARY KEY("CUSTID"), PROPAGATE
)
cacheadm>cachegroups;
Cache Group CACHEADM.UM_AWT:
Cache Group Type: User Managed
Autorefresh: No
Aging: No aging defined
Root Table: TTHR.ACTIVE_CUSTOMER
Table Type: Propagate
1 cache group found.
cacheadm>
cacheadm>load cache group UM_AWT where custid = 1 commit every 256 rows;
1 cache instance affected.
cacheadm>load cache group UM_AWT commit every 256 rows;
1 cache instance affected.
tthr>select * from active_customer;
< 1, A, Beijing, 100036, CHINA >
< 2, B, Shanghai, 122222, CHINA >
2 rows found.
tthr>insert into active_customer values(3, 'C', 'Guangzhou', '133333', 'CHINA');
1 row inserted.
SQL> set linesize 200;
SQL> select * from active_customer;
CUSTID NAME ADDR ZIP REGION
---------- -------------------------------------------------- ---------------------------------------------------------------------------------------------------- ------------ ------------
3 C Guangzhou 133333 CHINA
1 A Beijing 100036 CHINA
2 B Shanghai 122222 CHINA
SQL> insert into active_customer values(4, 'D', 'Nanjing', '144444', 'CHINA');
1 row created.
SQL> commit;
Commit complete.
tthr>select * from active_customer where custid = 4;
0 rows found.
# 需要手工load，而不能自动refresh(因为没有定义auto refresh，见下例)
cacheadm>load cache group UM_AWT commit every 256 rows;
1 cache instance affected.
tthr>select * from active_customer where custid = 4;
< 4, D, Nanjing, 144444, CHINA >
1 row found.
varies from table to table
完全自定义，最常见的组合是Propaget+autorefresh，以及手工flush（no propagate）+ autorefresh
Propaget+autorefresh
SQL>
delete from active_customer;
insert into active_customer values(1, 'A', 'Beijing', '100036', 'CHINA');
insert into active_customer values(2, 'B', 'Shanghai', '122222', 'CHINA');
commit;
CREATE USERMANAGED CACHE GROUP "UM_FLUSH_AR"
AUTOREFRESH MODE INCREMENTAL INTERVAL 5 SECONDS
STATE ON
FROM
"TTHR"."ACTIVE_CUSTOMER" (
"CUSTID" NUMBER(6) NOT NULL,
"NAME" VARCHAR2(50 BYTE) ,
"ADDR" VARCHAR2(100 BYTE),
"ZIP" VARCHAR2(12 BYTE) ,
"REGION" VARCHAR2(12 BYTE) DEFAULT 'Unknown',
PRIMARY KEY("CUSTID"), PROPAGATE
)
cacheadm>cachegroups;
Cache Group CACHEADM.UM_AWT:
Cache Group Type: User Managed
Autorefresh: Yes
Autorefresh Mode: Incremental
Autorefresh State: On
Autorefresh Interval: 5 Seconds
Autorefresh Status: ok
Aging: No aging defined
Root Table: TTHR.ACTIVE_CUSTOMER
Table Type: Propagate
1 cache group found.
# autorefresh生效，autorefresh state 如果设为off，则看不到数据，初始化时必须手工refresh或load
tthr>select * from active_customer;
< 1, A, Beijing, 100036, CHINA >
< 2, B, Shanghai, 122222, CHINA >
2 rows found.
# propagate生效
tthr>insert into active_customer values(3, 'C', 'Guangzhou', '133333', 'CHINA');
1 row inserted.
SQL> select * from active_customer;
CUSTID NAME ADDR ZIP REGION
---------- -------------------------------------------------- ---------------------------------------------------------------------------------------------------- ------------ ------------
3 C Guangzhou 133333 CHINA
1 A Beijing 100036 CHINA
2 B Shanghai 122222 CHINA
# autorefresh生效
SQL> insert into active_customer values(4, 'D', 'Nanjing', '144444', 'CHINA');
1 row created.
SQL> commit;
Commit complete.
tthr>select * from active_customer where custid = 4;
< 4, D, Nanjing, 144444, CHINA >
1 row found.
flush（人工 propagate + no autorefresh）
这种方式是全人工方式，双向的数据传递依靠手工load/refreh和flush
flush和propagate的区别是，flush不传递delete，只传递insert和update。
可是为何这么设计呢？
Oracle的Chris Jenkins是这么解释的:
User managed cache groups do not ‘track’ changes to data within TimesTen (unlike AWT for example) so TimesTen does not knwo what data has changed. When a FLUSH is done one or more large MERGE operatiosn are performed from TimesTen to Oracle in order to insert new rows and update existing rows that have changed. Since deleted rows no longer exist in TimesTen there is no way for us to ‘propagate’ those deletes to oracle. We could of cpourse examine every row in the Oracle tabel to see if it still exists in TimesTen and if not delete it; but imagine how long that could take if the Oracle table is at all large.
User Managed Cache groups are really a special usage ‘corner case’. For most purposes AWT is what you will want to use.
确实如此，数据都在TimesTen中删除了，也就没有必要传递到后端了。
CREATE USERMANAGED CACHE GROUP "UM_FLUSH"
FROM
"TTHR"."ACTIVE_CUSTOMER" (
"CUSTID" NUMBER(6) NOT NULL,
"NAME" VARCHAR2(50 BYTE) ,
"ADDR" VARCHAR2(100 BYTE),
"ZIP" VARCHAR2(12 BYTE) ,
"REGION" VARCHAR2(12 BYTE) DEFAULT 'Unknown',
PRIMARY KEY("CUSTID")
)
8265: To use AUTOREFRESH, all the tables in the cache group must be READONLY or all the tables in the cache group must be PROPAGATE
The command failed.
cacheadm>cachegroups;
Cache Group CACHEADM.UM_FLUSH:
Cache Group Type: User Managed
Autorefresh: No
Aging: No aging defined
Root Table: TTHR.ACTIVE_CUSTOMER
Table Type: Not Propagate
1 cache group found.
cacheadm>load cache group UM_FLUSH commit every 256 rows;
4 cache instances affected.
tthr>insert into active_customer values(5, 'E', 'Changsha', '410000', 'CHINA');
1 row inserted.
cacheadm>flush cache group UM_FLUSH;
5227: Insufficient privileges error occurred while performing an Oracle operation in OCIStmtExecute(): ORA-01031: insufficient privileges rc = -1.
5055: Cannot synchronize Oracle with TimesTen. The TimesTen transaction must be rolled back.
5025: Commit failure in Oracle. Transaction must be rolled back in TimesTen.
The command failed.
# 问题来了，对于自动Propagete，由于其利用了schema user的权限，因此无需赋予cacheadm更新的权限，而这时用cacheadm执行flush操作则出现问题。
要么还是在Oracle中赋予cacheadm更新表active_customer的权限，要么赋予schema用户tthr缓存管理的权限。
tthr>flush cache group CACHEADM.UM_FLUSH;
5 cache instances affected.
# 然后在Oracle中看到了数据
SQL> select count(*) from active_customer where custid = 5;
COUNT(*)
----------
1
# 以下演示propagete不传递delete
tthr>delete from active_customer;
5 rows deleted.
tthr>flush cache group CACHEADM.UM_FLUSH;
0 cache instances affected.
SQL> select count(*) from active_customer;
COUNT(*)
----------
5
User Managed Cache Group 适用的场景
User Managed缓存组非常灵活，但其适用场景似乎比较特殊，毕竟常用的已经固化成了read-only,SWT,AWT这些system managed模式。
在 Using Oracle TimesTen Application-Tier Database Cache to Accelerate the Oracle Database 提到了一个场景：
6.7 Updatable User-Managed Cache
User-Managed Cache Groups with explicit Flush are best suited for applications with frequent updates, but infrequent business transactions.
Some applications need to execute multiple updates in the cache for best performance, but need to permanently record the final transaction in the Oracle Database. An example of such an application is an eCommerce application where the application might maintain a number of shopping carts for active users. The shopping carts will be updated repeatedly in the cache. These updates need not be propagated to the Oracle Database as they are of little value. However, once a user executes a purchase, the transaction needs to be permanently recorded in the Oracle Database.
The best configuration for such data is a User-Managed updatable Cache Group where the application issues explicit Flush requests whenever it needs to record a transaction in the Oracle Database. This configuration may be coupled with Usage-Based Aging so that abandoned shopping carts get deleted from the cache automatically.
上面的例子是购物车的例子，平时都是在内存中更改，不同步到后端，最终需要持久化时才flush到后端数据库。
Flush是如何传递数据的
$ sqlplus tthr/oracle@ttorcl
create table lru_tab(a int primary key not null, b date not null);
insert into lru_tab values(1, sysdate);
grant select, insert, update on lru_tab to cacheadm;
cacheadm>
CREATE USERMANAGED CACHE GROUP "UM_FLUSH"
FROM
"TTHR"."LRU_TAB" (
"A" NUMBER(38) NOT NULL,
"B" DATE NOT NULL,
PRIMARY KEY("A")
)
cacheadm>cachegroups;
Cache Group CACHEADM.UM_FLUSH:
Cache Group Type: User Managed
Autorefresh: No
Aging: No aging defined
Root Table: TTHR.LRU_TAB
Table Type: Not Propagate
1 cache group found.
在 cache group中插入4条数据，
tthr>select * from lru_tab;
< 1, 2016-04-18 22:50:20 >
< 2, 2016-04-18 23:01:23 >
< 3, 2016-04-18 23:01:33 >
< 4, 2016-04-18 23:01:43 >
4 rows found.
tthr>flush cache group cacheadm.um_flush;
4 cache instances affected.
在Oracle中可以看到4条数据
SQL> select * from lru_tab;
A B
---------- ---------
1 18-APR-16
2 18-APR-16
3 18-APR-16
4 18-APR-16
SQL> delete from lru_tab;
4 rows deleted.
SQL> commit;
Commit complete.
tthr>flush cache group cacheadm.um_flush;
4 cache instances affected.
在Oracle中仍可以看到这四条数据
在Oracle中更改数据
SQL> update lru_tab set B='16-APR-16';
4 rows updated.
SQL> select * from lru_tab;
A B
---------- ---------
1 16-APR-16
2 16-APR-16
3 16-APR-16
4 16-APR-16
SQL> commit;
Commit complete.
tthr>flush cache group cacheadm.um_flush;
4 cache instances affected.
在oracle中的数据发生更改
SQL> select * from lru_tab;
A B
---------- ---------
1 18-APR-16
2 18-APR-16
3 18-APR-16
4 18-APR-16
# 可以看到，由于没有依赖日志，已经传送的数据并非不会再次传送。在Flush时，会根据cache group中的数据与Oracle中的数据做merge，然后再决定是插入还是更新。由于Flush操作是依赖于MERGE操作，以下给出一个merge的例子
tthr>select * from lru_tab;
< 1, 2016-04-18 22:50:20 >
< 2, 2016-04-18 23:01:23 >
< 3, 2016-04-18 23:01:33 >
< 4, 2016-04-18 23:01:43 >
4 rows found.
tthr>create table a as select * from lru_tab;
4 rows inserted.
tthr>create table b as select * from lru_tab;
4 rows inserted.
tthr>merge into b using a on (a.a = b.a)
> when matched then update set b.b = a.b
> when not matched then insert values(a.a, a.b);
4 rows merged.
tthr>select * from b;
< 1, 2016-04-18 22:50:20 >
< 2, 2016-04-18 23:01:23 >
< 3, 2016-04-18 23:01:33 >
< 4, 2016-04-18 23:01:43 >
4 rows found.
tthr>delete from b;
4 rows deleted.
tthr>merge into b using a on (a.a = b.a) when matched then update set b.b = a.b when not matched then insert values(a.a, a.b);
4 rows merged.
tthr>select * from b;
< 1, 2016-04-18 22:50:20 >
< 2, 2016-04-18 23:01:23 >
< 3, 2016-04-18 23:01:33 >
< 4, 2016-04-18 23:01:43 >
4 rows found.
tthr>update b set b.b = 0;
2962: Inconsistent datatypes: expected DATE got NUMBER in expression (0)
The command failed.
tthr>update b set b.b = '2016-04-01';
4 rows updated.
tthr>merge into b using a on (a.a = b.a) when matched then update set b.b = a.b when not matched then insert values(a.a, a.b);
4 rows merged.
tthr>select * from b;
< 1, 2016-04-18 22:50:20 >
< 2, 2016-04-18 23:01:23 >
< 3, 2016-04-18 23:01:33 >
< 4, 2016-04-18 23:01:43 >
4 rows found.
tthr>