Sybase12.5数据库进程OmniServer的产生及清除

2011.11重庆的校讯通数据库据运维人员反映，在易博龙里看到有个通过sa进入的访问master的OmniServer进程占用很大的资源，影响了数据库的性能，通过查看数据库后台日志，没有发现关于此进程的任何信息，进行google上查找关于OmniServer进程的来源。在google搜索到两个非常有价值的链接：

其中里面有部分关键信息给了我提示：

The OmniServer-#### entries from sysprocesses represent a dataserver-to-dataserver call (eg, RPC, proxy table reference).

xp_cmdshell is a call out to the OS and would therefore not connect directly to the dataserver.

--------------------

If KPLUS_PROD is also the name of your local dataserver (where you obtained the sysprocesses output) then you could be 

looking at a reference to a loopback server process (eg, accessing MDA tables).

--------------------

For completeness ...

Technically the OmniServer-#### entries could represent connections from any openserver program that connects to the 

local dataserver with a program name of 'OmniServer-####' (where #### represents some sort of id or counter within the 

openserver program).

This is a moot point if you know that KPLUS_PROD *is* in fact a Sybase dataserver.

上面的关键字：RPC, proxy table 以及 you could be looking at a reference to a loopback server process (eg, accessing MDA tables).

提示我这个进程涉及到了RPC以及代理表proxy table的访问，后面这句英文含义是，你可以查查看一个涉及到loopback server的进程在访问MDA  tables，

在继续分析查找到MDA关键字含义：'MDA' is short for 'Monitoring Data Access', 'Monitoring and Diagnostics for ASE', 'Monitoring and Diagnostic Agent' or 'Monitoring and Diagnostic Access', depending on who you ask. As 'monitoring' seems to be a common denominator, the MDA tables are also referred to as 'monitoring tables' (although they're not normal tables, but in fact proxy tables mapped to native RPCs inside ASE). 

至此，问题原因我基本已了然于胸，重庆校讯通sybase数据库服务器，以前为了抓取性能低下的sql脚本，特地添加了loopback server以及在master库中安装了MDA表。

详细操作请参见我的blog:

      SYBASE ASE各个版本的语句监控实现

       http://blog.csdn.net/xujinyang/article/details/6871023

后来在抓取脚本完毕后，通过sybase技术文档的说明，配置参数：

sp_configure 'enable monitoring',0 --关闭了监控的运行

go

没有预料到的是，loopback server还产生了OmniServer进程继续在消耗着数据库服务的资源。

接着先关闭了所有当初为了monitoring而打开的，相关的开关选项：

sp_configure 'SQL batch capture',0

go

sp_configure 'statement statistics active',0

go

sp_configure 'per object statistics active',0

go

sp_configure "object lockwait timing",0

go

sp_configure "process wait events",0

go

sp_configure "wait event timing",0

go

sp_configure "deadlock pipe active",0

go

sp_configure "errorlog pipe active",0

go

sp_configure 'statement pipe active',0

go

sp_configure "plan text pipe active",0

go

sp_configure 'sql text pipe active',0

go

在到易博龙上观察，发现OmniServer进程还是存在啊，于是干脆删除了loopbase server，结果OmniServer进程终于消失了，在此感叹"尽信书，则不如无书”，没有这样的实际经历，不会发现单单关闭monitoring 相关的开关选项还是不够的这个认知。

--------------------------------