请各位大大帮忙解答一个tt cache group的问题

loveleana

我猜,nocode可能是这个意思:
      如果要修改主键时,就设置passthrough,使当前会话的SQL传递到ORACLE执行.
修改完后,重新load,把passthrough再设置回原来的值,commit;OK,修改完成.
      不过好像ttOptSetFlag只能设置这个参数是否可以手动修改.不能直接设置值的.
to tom_111
      我觉得,DBA,在我们公司,是比较空的了,系统稳定后,只要偶尔循检下表空间,文件系统啥的.
    ...羡慕....希望我以后也能成为DBA.呵呵

nocode

原帖由 loveleana 于 2007-11-30 22:53 发表
我猜,nocode可能是这个意思:
      如果要修改主键时,就设置passthrough,使当前会话的SQL传递到ORACLE执行.
修改完后,重新load,把passthrough再设置回原来的值,commit;OK,修改完成.
      不过好像ttOptSetF ...

你说对了一半。
ttOptSetFlag不是参数，是TT内置的一个存储过程，用法是
call ttOptSetFlag('passthrough',3);
你只需在一个修改主键的事务的最开始加上这句就可以了。因为你的usermanaged cache group用的双向复制，所以
不需要你重新load，几分钟后（你没有指定刷新时间，因此缺省会比较长）自动刷新到TT的这个cache group中。
而且passthrough也不需要你在改回去，因为ttOptSetFlag在事务级生效，你commit之后自然就会变回以前的passthrough级别。
如果还不明白等我上班后给你作个例子好了，最近我在休假，呵呵。你可不要认为DBA都很空呀，DBA的压力很大，出现问题冲在
最前面的都是DBA，而且平时可不光只是看看表空间那么简单。

另外，想对tom_111说一句，DBA不应该只是给开发人员打扫垃圾，向这样的问题首先应该让开发人员调整自己的应用，
频繁或大批量的修改主键本身是不可取的，否则主键就失去意义了。当然如果确实无法避开，解决办法肯定会告诉开发人员，
还要告诉他们这样做的缺点，至于怎么选择是开发人员的事情，但DBA要有自己的决断，而且应该是强势的一方，毕竟数据库
归DBA管，怎么用也应该DBA说了算才对。

loveleana

nocode大大,我是这样测试的:
1.autocommit 0;
2.call ttOptGetFlag('passthrough');显示当前级别是2
3.call ttOptSetFlag('passthrough',3);这时没反应,passthrough还是2,可能是我的ODBC设置问题.
4.call ttOptSetFlag('passthrough',1);
5.passthrough 3;
6.update xxxxx
7.load cache group xx where (主键 in (xxx)) commit every 0 rows parallel 2;
8.passthrough 2;
9.commit;

    如果usmanaged cache group设置autorefresh,会在Oracle端建触发器,感觉很怪,如果是计费/帐务系统的表,
一般都不会在上面建触发器的吧?
   不过你上班后,如果方便的话,给我个例子看看吧,谢谢了.我们公司的某个系统,可能会用到TT,现在在选型,
在altibase和tt间选,所以我想先学习下TT,不过没抓到什么诀窍,文档都是英文的,看起来比较吃力.

   我还想问下ropagate,DurableCommits,Isolation是什么意思?


我现在只是小小的PSO(类似售后维护这样的),DBA,是我的目标呢,有更好的职业发展前途,就算很忙,也觉得值
呀.是不是?以后可能还会有cache administrator这种职业呢.

nocode

原帖由 loveleana 于 2007-12-2 00:55 发表
nocode大大,我是这样测试的:
1.autocommit 0;
2.call ttOptGetFlag('passthrough');显示当前级别是2
3.call ttOptSetFlag('passthrough',3);这时没反应,passthrough还是2,可能是我的ODBC设置问题.
4.call ttOptSetFlag('passthrough',1);
5.passthrough 3;
6.update xxxxx
7.load cache group xx where (主键 in (xxx)) commit every 0 rows parallel 2;
8.passthrough 2;
9.commit;

    如果usmanaged cache group设置autorefresh,会在Oracle端建触发器,感觉很怪,如果是计费/帐务系统的表,
一般都不会在上面建触发器的吧?
   不过你上班后,如果方便的话,给我个例子看看吧,谢谢了.我们公司的某个系统,可能会用到TT,现在在选型,
在altibase和tt间选,所以我想先学习下TT,不过没抓到什么诀窍,文档都是英文的,看起来比较吃力.

   我还想问下ropagate,DurableCommits,Isolation是什么意思?


我现在只是小小的PSO(类似售后维护这样的),DBA,是我的目标呢,有更好的职业发展前途,就算很忙,也觉得值
呀.是不是?以后可能还会有cache administrator这种职业呢.

我个人觉得usermanaged cache group设置为autorefresh才体现出了这种类型cache group的价值。如果你只想单向传递数据，
用SWT或AWT就行了。
我做了一个小测试，你可以看下：

Command> create usermanaged cache group usercache
> autorefresh mode incremental
>             interval 10 seconds
> from readtab (
> a number not null primary key,
> b varchar2(31),
> propagate);

Command> load cache group usercache commit every 256 rows;
4 cache instances affected.

Command> select * from readtab;
< 1, hello >
< 2, world >
< 3, Hello >
< 4, Again >
4 rows found.

Command> update readtab set a=5 where a=1;
1000: Cannot set primary key columns to different values
The command failed.
这时候是失败的，
Command> autocommit 0;

Command> call ttOptSetFlag('passthrough',3);

Command> update readtab set a=5 where a=1;
1 row updated.

Command> commit;

Command> select * from readtab;
< 1, hello >
< 2, world >
< 3, Hello >
< 4, Again >
4 rows found.
可以看到，执行成功了，但为什么没有变化呢，过10秒在看：
Command> select * from readtab;
< 2, world >
< 3, Hello >
< 4, Again >
< 5, hello >
4 rows found.
Command>
oracle端已经把数据反向刷新回来了。
你是联通还是移动的人呢？呵呵。我觉得帐务数据还是不要用实时同步的方式，这种方式更适合查询为主，更新很小的系统，AWT个人觉得更适合帐务系统这种更新频繁处理量大的应用。但既然是异步就很可能出现两端数据不一致，所以要通过其他一些手段来控制。

propagate在TT这里的大概意思就是把TT的数据传到oracle。
DurableCommits和Isolation你说的是ODBC里的定义吧，前者是表示是否在事务提交时把log落到磁盘，缺省好些是0，不实时落地。好处是效率更高，缺点是可能会丢数据。后者叫隔离级别，这个讲起来比较复杂，是数据库的一个基本概念，设置的目的主要为了找到一个性能与一致性的平衡点，你可以上网搜搜，一般用默认的read-committed就行，serializable级别高，但会造成性能降低。