UBB 配置

1 机器名怎么找？

在 windows machine 中machine name = 大写的机器名字(控制面板中的机器名字)！一定要记住大写机器

名，还有就是如果你的机器名字不是一个字符串的话，比如下面的情况jian yi

这个机器名，你需要在UBB 中写成这样的形式“JIAN YI” 。

在 unix ：            machine name = uname –n 。

2 TUXEDO 版本6.5 和8.0 可以混用吗？

可以应用的。

1.低联高(6.5--->8.0) : 在WSL中加入-t 即可

如:CLOPT="-A -t -- -n //vt8000:3345

2. 高联低(8.0--->6.5),除了设置环境变量WSNADDR=//host:port 外, 还应设

WSINTOPPRE71 = yes

3 TUXEDO 与ORACLE 不采用XA 方式连接，怎么在

UBB 文件中写？

不采用 XA 的ubbconfig 跟正常情况一样写。没有TMS 组(ＯＰＥＮＩＮＦＯ、

TMSNAME

等),没有TLOG 的信息。例如：

检查你的 ubbconfig 配置文件，机器名是否和你的主机名相同。

win***: set 查看COMPUTER NAME，注意区分大小写。

unix： uname -n 查看。

5 MSSQ 配置问题？

反面声音：

“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 说这种模式

相比专用服务器模式可以增加客户端数目。

6 Tuxedo MP 方式的切换说明

环境：master： LMID app_server1

1. 管理的切换

（实现方法：在UBB 文件的*RESOURCES 部分的MASTER 写法如下：

MASTER app_server1,app_server2）

1．正常情况下切换：

在 slave 机器上，tmadmin---> master

系统会提示是否切换，输入y，回车，就可以把DBBL 切换过来

如果想切换回来，可以在master 机器上，tmadmin---> master

系统会提示是否切换，输入y，回车，就可以把DBBL 切换过来

2．slave 机器出现问题，tuxedo shutdown 后，机器重新启动情况下切换：

在 master 机器上，tmadmin-----> rco app_server1 app_server2

pcl app_server2

tmboot –y 会把 app_server2 上的server 启动起来

注：也可以使用tmboot –s <app_server2 上serve r 的名字> 把 app_server2 上的

server 启动起来

3．Master 机器出现问题，tuxedo shutdown 后，机器重新启动情况下切换：

在 slave 机器上，tmadmin-------> master

系统会提示是否切换，输入y，回车，就可以把DBBL 切换过来

在 slave 机器上，tmadmin-----> rco app_server2 app_server1

pcl app_server1

tmboot –y 会把 app_server1 上的server 启动起来

注：也可以使用tmboot –s <app_server1 上server 的名字> 把 app_server1 上的

server 启动起来，此时，slave 机器是master，如果想切换到master 机器上，参

照1 种的方法

4．两台机器连接出现问题，恢复以后：

在 master 机器上，tmadmin-----> rco app_server1 app_server2

2. 组的切换

（实现方法：在UBB 文件的*RESOURCES 部分的MASTER 写法如下：

OPTIONS LAN,MIGRATE在 UBB 文件的*GROUPS 部分的MASTER 写法如下：

GROUP1

LMID= app_server1, app_server2 GRPNO=1 OPENINFO=NONE

）

1．正常情况下切换：

在主机上把要切换的组停掉：

在 slave 机器上，tmadmin---> migg GROUP1

2．master 机器出现问题，组的切换：

首先把该机器切换成主机（方法在前面）

在 slave 机器上，tmadmin-----> pcl app_server1

tmboot –g GROUP1 会把 app_server2 上的GROUP1 启动起来

3．如果是要把组反方向切换（上面的配置要作相应的修改）：

在 master 机器上，tmadmin-----> pcl app_server2

tmboot –g groupname 会把 app_server1 上的groupname 启动起来

说明：采用MP 完全可以实现高可用性

7 如何在不同的机器上实现 simpapp？以及探讨一下c/s

and B/s 的各自有缺点。

第一个问题。你把ubbconfig 的配置文件更改一下， 在machine 加入

MAXWSCLIENTS 参数，在server 段加入WSL server。具体可以参加以前发的

贴子，或察看文档。在client 配置WSNADDR=//serverIP:port.

第二个:其实tuxedo 是OLTP 应用处理的最佳选择产品。至于产品升级，可

以使用tuxedo 的功能，将升级作为自动的。那么通过网络完成升级功能，不需

要人工干预。也是可以做到的。只不过方式有人工有程序实现，与B/S 的thin client

不一样。但是tuxedo 的一些功能b/s 是不能替代的

8 防火墙＋端口映射的配置问题和不安装客户端打包

1、在服务端的ubbconfig 中的WSL加入-H 参数。例如：

例如： WSL = ... - n //10.54.0.51:9001 -H //123.100.1.90:MMMM -p 9001 -P 9011

不过需要在防火墙上至少开 M 个端口。

2、不安装客户端直接打包了TUXEDO 的文件并配置环境变量，但是，需要把$TUXDIR/local 目录下的message 文件给打包上。否则不能报告

正确的错误信息。提示什么：$TUXDIR=NULL 等错误信息。

3、直接用的动态库的函数，编译时没有什么-W 参数了.

这种情况，在制作动态库的时候已经暗示把-w 参数给使用了。因为你使用了ws

方式的lib 库或者ws 方式的dll 了。

9 WSL 和WSH 的关系

1- 如果连接数会很多，应该多起几个WSH（因为连接数太多，WSH 数目少则

会成为系统数据转发的瓶颈），如果能够人为管理的话，在不同的网点分配不同

WSL 地址（启动多个WSL的情况下），可以适当地分担WSL的负载；

2- 应用的 service/server 分配的原则应该是最大化共享资源、最小化系统开销、

并尽量避免瓶颈，没有最好理论方案，根据具体的系统硬件、软件性能、应用的

具体情况具体安排吧。假如所有的service 都在一个server 实现，而其中一个

service 特别繁忙，那么其他的service 都要等待此service，这时我认为应该把这

个service 单独实现比较好；如果是8 个service 分布的8 个server 中，那么比较

便于维护和程序调试，我比较主张同一类的service 分布在同一个server 中，因

为开发时毕竟同一类的功能是由一个人来负责的，这样开发、维护时比较方便，

系统逻辑也清楚些。如果操作系统和硬件不是很强的话，启动太多进程那么会大

大增加系统开销，瓶颈就转移到操作系统了。还是具体情况具体分析，要靠实践

中的测试数据来证明真理吧。

10 Service 的合并问题

如果你的机器硬件允许，可以不需要合并多个service 到一个server。可以一

个service 就是一个server。然后多启动几个server。另外，你的连接网点（电脑

终端）多，可以多启动几个WSL.减少连接的阻塞。

因为你的服务不多，就8 个，可以这样做。如果服务很多，机器硬件内存

等少，可以合并N 个service 到一个server。那么合并也要讲究原则的。

11 TUXEDO LICENS 的估算

交易频率(F1)：平均每个用户的处理时间为约60 秒即1 分钟

交易后台处理时间(T)：4~5 秒（包括多个TUXEDO 服务完成时间和数据打包来

回传输时间），平均为4。

高峰瞬间业务放大因子(F2)：通常为5~10，平均为7

总的并发用户连接数和服务数目的比例为：(T:F1) * F2=(4:60)*7，约1:2。

即如果系统要支撑 120 个终端请求，需要至少60 个License。

需要指出的是：

1．这种估算方法的准确程度比较依赖于应用的实现方法和对性能的准确了解上。

2．无法估算来自Internet 和其他系统接口的服务请求所需要的License 数目，这些请求的并发连接数需要另外估算。

12 关于 tmloadcf 的问题

ubbsimple 文件在最后一行后面必须要跟一个空白行，否则tmloadcf 就会出

错。

13 tuxedo 负载均衡

1。如果是会话的话应该也没有问题，因为建立会话的时候，client 和那个server

之间应该有context 之类的东西就可以标示和相互找到了。因为文档没有提到说

会话方式server 不能启多份。（要是那样就很没劲 :） ）。我们会话用得很少，

你可以试一下。

2。TUXEDO 的负载均衡大致可以分为两种，单机的和多机。单机的就是多个

server 分担来均衡，我的那篇文章主要说这个，并做了些测试。至于多机的前面

有一个朋友贴了关于MP 的很好的帖子，还有WSNADDR 配两个进行轮询等办

法。

3。在只有一个client 多次调用时，我的测试结果是如果MSSQ，还是会分担到

多个，但是多Q 多server 就不会，你也可以试一下。这是一个区别。

4。在MP 的时候，优先用本地的server，再考虑remote 的，因为这样少了网络

的开销，当然，这其中也要考虑每个server 当前的负载。

14 TUXEDO_XA 的使用方法

使用 TUXEDO XA 需要做以下几件事

以下以 ORACLE V815 为例：

1． 修改%TUXDIR%\udataobj\RM 文件，在RM 文件中指定数据库提供的XA

库。

2． 编译 TMS（全局交易管理服务）

命令：buildtms –o TMS_ORA –r Oracle_XA

3．COPY TMS_ORA 到%TUXDIR\bin 目录下(或者放到$APPDIR)

4．在UBBCONFIG 中配置TLOG 日志和TMS_ORA 服务

5． 编译 UBBCONFIG

命令：tmloadcf -y UBBCONFIG

7． 创建 TLOG（交易日志）

命令：tmadmin

10． 启动 TUXEDO

11． 检查是否正常

1） 检查 TMS_ORA 是否启动

命令：tmadmin

查看 TMS_ORA 是否启动。

2） 用程序检查是否正常

如果 TUXEDO 和ORACLE 连接正常那么对数据库的操作将会成功。

如果连接不正常，请检查ULOG日志，定位错误。

15 tuxedo 能否与Ms Sql Server 相连呢？

16 jolt 的配置问题

一般 jolt 需要配置两个进程,一个是jsl,一个是 jrepsvr,如下：

其中 jrepository（用来存放服务端需要发布的服务列表及参数信息）需要生成，

需要在服务端启动tuxwsvr,wlisten,然后在客户端

访问服务端 jolt 目录下的html,然后就可以配置服务端发布的服务。