Tunnable Kernel Parameters

Redhat 9.0
你要做的主要调整是共享内存和信号量的大小SHMMAX,SEMMNI,SEMMSL等.这些参数的路径在：
/proc/sys/kernel/shmmax
/proc/sys/kernel/sem

or dirctly change /etc/sysctl.conf

For HP Unix
swlist to check os patch
swlist -l bundle
kmtune to check kernel parameters' value
use /usr/sbin/sam to change kernel parameters

frequently used tmadmin commands

[TESTING]What is Stress Testing

压 测测试主要是看并发请求量很大的情况下检验系统的稳定性和可用性,并得到不同压力时的响应时间等数据.当然有专业的测试软件,比如Load Runner等.其实也可以自己去做,比如写一个客户端程序,在里面开指定数目的进程,每个进程去调用服务,就达到了模拟多客户端的目的.

DB Transaction controlling

如果事务控制在服务端，首先要在tpsvrinit()中连接数据库，在tpsvrdone()中断开连接，这些查一下以前的，然后再事务开始的地方使用 tpbegin(30,0），之后可以进行update,insert之类的操作，完成后使用tpcommit(),一定要检查一下tpcommit（） 的返回值，如果是-1则事务提交失败。
如果在客户端控制事务，服务端：首先要在tpsvrinit()中连接数据库，在tpsvrdone()中断开连接，之后可以进行update,insert之类的操作，然后正常返回tpreturn（）
客户端：首先tpbegin(30,0),然后tpcall(),如果tpcall()成功，tpcommit(),
这样做，比较消耗资源，但能从客户端控制多数据源的数据同步更新。

这个问题有点复杂：
1. TUXEDO中的XA,客户端和服务端都是可以tpcommit()的，因为在内部是tpcall("..TMS",..),事务的提交和回滚走的是另一条通道，另一个SESSION，这才是XA的魅力。
2. 如果用XA的话，要在UBB中配置TMS及其OPENINFO,在程序中要用tpopen()/tpclose()
3. 在X/OPEN的规范上，ORACLE又申明了动态XA的规范，但TUXEDO不怎么支持，如果RM文件中switch结构用xaoswd而不是xaosw就会也出这个问题。

请教：采用xa方式与oracle数据库连接，数据库的数据不能及时刷新，怎么回事？
谢谢各位了！我的问题终于解决了，原来是我在RM文件中用了xaoswd了

Throughput

[QUE]不能全部处理并发的客户端，请求是什么原因？

我现在用20个客户端连接服务器请求，可是服务器只处理了其中的16个，4个在等候，这是什么原因，我的LICENCE是足够大的了，而且我的UBB中的 配置文件中的MAXWSCLIENTS=70，已经足够大，应该不会有问题，请大家帮忙，
说说都有那方面的原因会造成这样的情况？
怎么来看到底服务器正在处理了多少个请求？有多少请求在等待？
用哪个命令来看？
还有客户端请求由哪个服务来处理？
请大家帮忙，谢谢大家！

MAXWSCLIENTS=70 只是最大的连接数，而LICENCE限制的是并发处理数，如果LICENCE=5的话，你的client可以连接70个，但同时处的只有5个，按照你说的 你的LICENCE可能是16个，如果你用的是开发的LICENCE他大部分都是LICENCE=5，如果LICENCE数目不够了你可以在ULOG中发 现BBL报4727的错误
4727
ERROR: Exceeded 110% of TUXEDO System Binary Licensed User Count (val/val), val hour val minutes val seconds left before DBBL lockout occur

命令:tmadmin -v
其中有Maxusers *
这个*就是你的LICENCE数

TUXEDO对客户端能进来多少，有好几道门。
1. 连接WSL/WSH，看你的WSL中-m,-M,-x够不够；(-M)*(-x)是在WSL监听这边能接入的最大数了
2. WSH接到后，会校验LICENSE，看是否越过，一般能到110％，但90%时就开始报警
3. 上面都OK了，WSH开始在BBL中注册登记该客户端，由于BBL启动时，分配的是静态数组（大小来自于UBB），所以最多可登记的就是MAXWSCLIENTS
4. 但由于SERVER和CLIENT共享同一个大数组，SERVER多了，也挤的CLIENT没地注册，要MAXACCESSER>MAXWSCLIENTS+MAXSERVERS

你的license没有问题,不会有这个限制的.看看你的UBB的其它几个参数,例如MAXACCESSERS,WSL的-m -M -x等,看这些有没有限制.如果这些都没有问题的话,那你再看看你的service启了多少份,处理一个请求是不是要很久?你说得查看命令,就是 tmadmin下面的了,psr可以看到正在处理请求的service,pclt可以看到client的状态,pq可以看到server队列的情况. Hope this helps.

你还是看看你的ubbconfig中的server启动的个数，和MAXACCESSES的配置。限制可能在这里

ATMI和CORBA的区别

其实我不怎么了解CORBA，但是我们项目用到相关的，就说一点。简单的说，ATMI是用作事务处理，短小快速的那种，这里大家多是讨论这方面的。另外 BEA也有CORBA的产品，我们用WLE 5.x，据他们工程师说是很老的东东，但是能用就好。还有就是TUX 8也有CORBA，看文档吧，呵呵。我们用CORBA来进行后台调用，都是些涉及读写文件，以及长时间、大数据量的操作，例如和银行之间的托收处理和导历史数据等。同事封装了一个和WEB的接口，可以在java前台调用COBRA,然后调具体的程序，挺有意思，叫easycorba，和easycics的函数声明一样。

ATMI是TUXEDO专有的接口
CORBA是一种开放的标准,编程模型和ATMI不一样
ATMI应该比CORBA快,但CORBA比ATMI更开放

Difference between FML and VIEW

FML象个表，可以不断的加Fadd。VIEW象个结构。
FML中可以包含另一FML。它还可以包含CARRAY等。
FML占用的资源比VIEW多，效率比VIEW低。

但是我们的程序一直用FML，谁知道哪天又要对某个FIELD进行Fadd操作呢。而且感觉VIEW可以做的FML都可以。
可能要大数据量的情况，FML和VIEW才有比较吧。

三个主要区别：
1、VIEW象C的STRUCT，可以用C语法操作，FML只能用专门的API操作
2、FML可以动态分配大小，传输时可以压缩空间，VIEW不行
3、VIEW的内存空间是按照C里STRUCT顺序分配的，FML内存空间对程序员透明

BEA文档里的定义：
FML is a set of C language functions for defining and manipulating storage structures called fielded buffers, that contain attribute-value pairs called fields. The attribute is the field's identifier, and the associated value represents the field's data content.

About WSH memory

Using MSSQ or not ?

“BEA好像不建议用MSSQ，因为很多Service共用一个Queue，而Queue空间是操作系统分配的规定大小空间，不会动态分配。多个Service多个请求时，MSSQ的Queue很容易满。这样请求被拒绝的几率就大。”
关于这个，我有不同的看法。首先我接触的BEA工程师没有建议不用。而且这个确实可以提高性能，我们现在主要的server都起了几份（2－12之间是推荐的）。而且从理论上讲也是有可以理解的。没有MSSQ时，每个server一个队列，用户接收请求和返回结果。客户端和server一对一，这时你可以将一个server启多份但不是MSSQ，因为每个server都有自己的队列，用tmadmin->pq看一下，更糟的是所有的请求几乎都是发给多个同名server中的一个，其它都闲着，就没有起多份的意义了。用了MSSQ（顺便可以加一个返回队列，是很有必要的，用于将请求和返回分开）之后，多个server共用一个请求队列（在pq里可以看到，你可以自己命名），都从这个队列取请求去处理，就像在食堂有几个师傅在卖饭，但是只有一条队，比一个师傅一条队还是要快些的。psr的时候你会看到每个server处理的数目是比较平均的，我有一次做了40，000笔交易，起10个，几乎都是4000 个。在一个server处理的时候，其它空闲的server可以继续接受请求。队列满的快是客户端的量大，并发快，不是server的关系，当然 server处理快就不会堵塞。这一点和oracle的MTS的原理惊人的相似，oracle说这种模式相比专用服务器模式可以增加客户端数目。

TUXEDO LICENSE的说明资料

BEA公司对TUXEDO中间件的使用许可（License）控制的是同时与TUXEDO服务器连接的并发客户端的数量，即每秒种同时用tpinit()连接到TUXEDO服务器调用服务做交易的客户端数目。需要说明的常见问题有几点：
l Tuxedo License数目与后台的应用有多少个服务无关，Tuxedo只控制用户数，不控制应用服务的数目和类型。
l Tuxedo License数目与后台的应用服务器主机的数目、型号、性能高低无关。用户升级主机无须更换License
l Tuxedo License中的并发用户License主要根据应用的并发交易量来确定，此处“交易”的概念是业务角度的交易，即指客户端发起的业务交易，而不是指后台运行的服务程序。一个交易包含客户端程序的一次服务器连接过程所调用的所有服务。比如用户的一次联机缴费交易，可能包括运行多个后台服务程序。
l Tuxedo License中的并发用户License与总的终端连接数无直接关系，对于常见的应用模型，BEA可以提供一些仅供参考的并发百分比经验值，比如某类应用一般的并发用户率为30%-35%。

一般来说，一个基于TUXEDO的三层应用所需要的TUXEDO Licenses数目主要取决于以下几个因素：
业务量大小，既用户在单位时间内预期的行为次数。
业务模型，包括影响业务量变化的因素和各种业务的组成模型。
高峰时的业务量放大因子、系统配置富裕量因子。
若干年内用户数增长百分比和系统功能扩展的因素。

installation tuxedo under Linux

cp /bin/gunzip /bin/uncompress

Chins dev2dev 2004 Article awards (Final)

China dev2dev 2004 Article Awards(all)

Oracle XA and TP Monitor FAQ