来源：网海拾贝
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’;
版权声明： 原创作品，应许转载，转载时请务必以超链接伎俩标明文章 原始情由 、作者信息和本声明。不然将追究法律责任。