为了提高性能,我们针对Oracle数据库本身提供了的方法或方案进行过不少的尝试，主要包括:
共享服务器模式(MTS)；
集群技术(Clustering)RAC；
分区；
并行处理(主要是并行查询)。
Oracle提供的这些特性确实是用来进行性能改善的,但我们往往忽略了对自身应用特性的分析,它们是否适合于我们。最近,通过对这方面知识的深入了解,发现我们以前存在一些错误的认识。我觉得有必要,大家一起来改变这种误解。
分析之前,先明确一下我们的应用特性。数据库应用大体可以分为OLAP和OLTP两大类,即:联机事务分析(数据仓库)和联机事务处理(事务应用)我们的应用系统,其应用特性主要是联机事务处理,又包含了少量的数据仓库特性。
1、共享服务器(MTS)
Oracle缺省用的是专用服务器模式,也就是说一个用户连接进程对应一个服务器的进程。记得某大医院刚启用的时候,我们曾经试过MTS。因为听说MTS在不增加内存和CPU的情况下连接更多的客户端,结果并不是我们预期的那样。MTS有问题吗?不是,是因为我们对MTS不了解,并不是它有问题,而是它不是用来在这种情况下做这件事的。
一般情况,只有当并发连接数超过了操作系统的支持时,才建议使用MTS,否则应该使用缺省的专用服务器模式。也就是说,在专用服务器模式下,因为多一个连接就要多消耗一个操作系统的进程,只有当并发应用需求超过操作系统的允许连接数时,才有必要考虑MTS。
如果现有系统,物理上支持100个连接的专用服务器数据库,改为使用共享服务器模式,也许支持1000个连接,但同时活动的连接可能只有100个。一般2到4个CPU的服务器,应对200到400个并发连接是足够的,如果连接增加了,可以增加CPU和内存。
MTS具有以下一些缺点:
1、共享服务器的代码路径比专用服务器长,所以它天生就比专用服务器慢。
2、存在人为死锁的可能,因为它是串行的,所有共享服务器绑定在一起(一个进程),只要一个连接阻塞,则所有用户阻塞,并且极可能死锁。
3、存在独占事务的可能,因为如果一个会话的事务运行时间过长,它独占共享资源,其它用户只能等待。(而专用服务器,每个客户端是一个会话)
4、共享服务器模式限制了某些数据库特性,例如:不能单独启动和关闭实例,不能进行介质恢复,不能使用Log Miner,不能使用,并且SQL_TRACE没有意义(因为是共享而不是当前会话的)。
MTS减少的内存实际上是专用服务器模式下每个用户连接到操作系统进程所需的内存,但它却使用SGA的Large_Pool来分配UGA,拆东墙补西墙,所减少的内存是很少的。如果用户会话的连接和断开很频繁,数据库进程的创建和删除的开销会非常大,这种情况最好采用共享服务器模式(否则,应该使用连接池技术)。所幸的是,我们产品的设计可能就考虑了这个因素,使用的是一次连接终身使用(会话生命周期内),避免了这种情况。
所以,综上所述,针对我们产品,建议采用缺省的专用服务器模式,连接不够时,通过增加硬件解决,而不是改用MTS。另外,实际上,Oracle可以同时支持共享服务器和专用服务器模式,可以指定一个会话使用专用服务器,另一个会话使用共享服务器。