中国最大的web开发资源网站及技术社区，
在csdn上写了一篇关于mts的文章后收到了一些网友的mail或是留言,他们还有好多关乎于mts的一些问题。与piner,fenng,biti及其它的一些网友在聊天中,他们都对使用mts有些不赞同,那天与oracle的工程师交流中他也是有些反对,不过在我的实际应用过程中虽遇到了一些问题,但总体mts还是让我很满意的,使我的一台oracle server在peak time的内存利用率由95%降到了78%,而且应用的速度还很不错。如下我便以问题的形式对mts再进行几点补充。
1、在oracle server调整为mts方式后,一些客户端出现了连不上oracle server的状况,大部分报的错为tns-12509,如何解决？
回答：
在实际过程中是存在着这方面的情况,我总结了一下,大部是由oracle8 的client引起的,就是那些配服务名还得挂着个.world的那种客户端,其实解决起来很简单,只需要把tnsname.ora这个文件中你的那个服务名配置的"sid="改成"service_name=",这就ok了。
2、我使用了成都迈普公司的"隧道网关"这种产品,以前在dedicated方式是好好的,可是改成mts后,为什么client死活连不是oracle的server呢？
回答：
其实我们公司也用了这种产品,在mts应用之初也遇到了这个问题。出现这个问题的原因为迈普的这种产品只为监测静态的端返回,它认为oracle的监听端口即为返回端口,实际在mts中不是这样的,多进行几次连接,用netstat -n在客户端观看一下就会明白,mts返回的端口是动态的,所以迈普的这个产品就不好用了。解燃眉之急的办法可以这样：在mts客户端配置"服务名"时,请求个dedicate的连接,即使用server = dedicated选项,这就把问题解决了。
3、如何跟踪一下mts的dispatcher和shared server进程?
回答：
这需用到诊断事件了,dispatcher的诊断事件号为10248,shared server的为10249,如下以shared server为例简单说一下,假定s015的操作系统的进程号为13161.
sql>conn sys/pass as sysdba
sql>oradebug setospid 13161
sql>oradebug tracefile_name --看一下跟踪文件的名称
sql>oradebug event 10249 trace name context forever, level 10
也可以在init<sid>.ora中加入如下两行完成trace:
event="10248 trace name context forever, level x" -- dispatchers
event="10249 trace name context forever, level x" -- shared servers
4、如何在mts中设置ipc
回答：
如下的配置样例来自metalink
listener.ora:
=============
listener=
(address_list=
(address=
(protocol=ipc)
(key=<sid name>)
)
(address=
(protocol=ipc)
(key=<alias in tnsnames.ora for the sid>)
)
)
connect_timeout_listener=10
startup_wait_time_listener=0
sid_list_listener=
(sid_list=
(sid_desc=
(sid_name=<sid name>)
(oracle_home=<home directory path for oracle>)
)
)
地址列表中可以使用其它的协议,加入应的地址。这个例子完全是一个ipc的例子
tnsnames.ora:
=============
<alias>=
(description=
(address=
(protocol=ipc)
(key=<sid name>)
)
(connect_data=
(sid=<sid name>)
)
)
init.ora entries for mts:
=========================
mts_dispatchers="ipc,2"
mts_servers=1
mts_max_dispatchers=6
mts_max_servers=3
mts_service=<sid name>
mts_listener_address="(address=(protocol=ipc)(key=<sid name>))"
5、如何查看一下某个shared_server正在忙什么？
回答：
其实这与dedicated方式的查看方法是一样的,还以s015为例,它的spid为13161,使用如下的sql便可查
出：
select a.username,
a.machine,
a.program,
a.sid,
a.serial#,
a.status,
c.piece,
c.sql_text
from v$session a,
v$process b,
v$sqltext c
where b.spid=13161
and b.addr=a.paddr
and a.sql_address=c.address(+)
order by c.piece
6、我在unix看到一个shared server的进程占用了大量的cpu资源,通过select addr from v$process where spid=<os process pid>查到进程的address,而select * from v$session where paddr=<paddr>确没的结果,所以我无法得知我的这个shared server在忙什么,我该怎么办呢？
回答：
select status from v$circuit
where circuit in
(
select circuit from v$shared_server
where paddr=<your paddr>
)
如果status的返回是eof,说明实际这个shared server已经掉死了,你可以把它在操作系统上清除掉了：
eg:
oracle$kill -9 <shared server's pid>
你不用担心kill掉会有什么大的影响,其它几分钟之后,pmon会为你把这个shared server进程给重新启动的。
7、如何在非down库的情况下恢复到dedicate的连接方式,及启用更多的dispatcher?
回答：
7.1关掉:
sql>alter system set mts_dispatchers='tcp,0';
7.2启用更多的dispatcher
sql>alter system set mts_dispatchers='tcp,40';
部分内容参照metalink的note:47684.1
