为了提高性能，我们对Oracle数据库本身提供的方法和方案进行了许多补偿测试
主要包括：
共享服务器模式(MTS )。
集群技术(Clustering )、RAC
分区
并行处理(主要是并行查询)
Oracle提供的这些特性确实用于改善性能，但我们往往忽视对自己应用特性的分析，认为它们是否适合我们。
最近，通过深入了解这方面的知识，我们发现我们以前有过一些错误的认识。 我觉得我需要。 需要大家一起改变这个误会。
在分析之前，请明确我们的应用特性。
数据库APP应用大致分为OLAP和OLTP:在线事务分析(数据仓库)和在线事务处理(事务APP应用)
我们的应用系统，其应用特性主要是在线事务处理，并且包含少量的数据仓库特性。
1 .共享服务器(MTS )。
默认情况下，Oracle使用专用服务器模式。 这意味着用户连接进程对应于服务器进程。
我记得在一家大医院刚开办的时候，我们尝试过MTS .听说MTS连接了更多的客户端，而没有增加内存和CPU，所以结果并不理想。
MTS有问题吗？ 不，是因为我们不知道关于MTS的事。 不是有问题，不是在这种情况下做这件事的。
通常，只有在并发连接数超过操作系统支持时，才建议使用MTS。 否则，必须使用默认的专用服务器模型。
也就是说，在专用服务器模式下，连接数过多会占用额外的操作系统进程，因此只有在需要超过操作系统允许连接数的并发APP应用时才需要考虑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可以同时支持共享服务器和专用服务器模式，并且可以指定一个会话使用专用服务器，另一个会话使用共享服务器。
2 .集群技术(RAC )。
realapplicationclusters (RAC )，我们所说的双机容错是一种RAC。
集群技术的优势是横向扩展性能，提供高可用性。
32位操作系统有4G内存限制，一些Unix系统(和非高级Windows版本)有CPU数量限制。
集群技术通过聚集多台机器共同工作，横向打破了这一限制
通过RAC在一台服务器上配置一个实例，在多台机器上配置一个实例服务集，客户端与之连接。
虽然我们有时会对客户说负载平衡，但实际上这是单方面的，RAC的主要对象是CPU和内存负载平衡。
未平衡磁盘I/o负载。 (当然，磁盘I/o可以通过Raid或NAS实现。 ）
RAC的另一个优点是提高了可用性。 也就是说，一台服务器损坏不会影响正常使用。 (请注意，不是数据存储介质。
与负载平衡一样，它提高了数据层以上的可用性，但不是全部。 数据坏了也没用。
(数据层，是指Oracle数据保护还是存储硬件)
但是RAC在带来好处的同时，也带来了性能的影响。
为了全局调整数据缓存并确保连接到每个实例的用户看到的缓存数据一致，请将以下三个冲突扩展到：
1 .缓存冲突
2.I/o过多
3 .摇滚
也就是说，如果这些问题存在，使用RAC会导致更大的问题。 例如，由于SQL未使用绑定变量而发生缓存冲突，使用RAC则更严重。
总之，服务器的CPU满了之后，内存
也加到极限了,而并发用户还在不断增长,或者你对故障停机时间要求非常高,RAC无疑是你应该选择的.3.分区
Oracle的分区用途在于把大的表或索引分成小的片段,以便更容易管理.
我们以前可能错误的认为分区就是fast=true,可以提高速度,也在肿瘤和儿科做过这方面的试验.
实际上,在事务处理系统中,分区一般不能加快查询速度(某些情况下可能会减少对共享资源的争用).
Oracle的分区特性,主要是针对数据仓库来设计的,也就是说你的某张表如果有100G的大小,最好使用分区,好处有以下三个方面:
1.提高可用性
分区的原理就是分而治之,如果一张表划分为多个分区,其中一个分区所在的介质出了问题,不影响整个表的其它分区数据的访问.
2.易于管理
在数据仓库下,表分成小的片断,更容易批量的删除,碎片整理,以及一些并行处理.
3.提高性能
这方面,通过分区来达到是最困难的,必须经过周密的计算来安排分区数据.
分区的规划是复杂的,拿我们产品应用来说,一般查询涉及到多个表,多个索引,
假设我们把病人费用记录,药品收发记录,病人医嘱记录这类大表建立分区.
显然,范围分区对我们提升性能用处不大,散列分区才是我们查询需求的,但大多数数据的散列又不够集中.
再加上,这些表上的索引这么多,常用的ID,时间类索引就不少,
很少有人能做到把它们全部进行全局分区或准确的进行范围分区(实际上可能根本无法按需求进行多个索引的范围分区).
如果查询经常涉及多个索引,如何保证用到的每个索引都在一个分区上,如果不是,必然扫描多个分区,增加逻辑I/O和CPU时间,从而增加查询时间.
(数据分布在不同物理存储介质的情况,在下面的并行处理中再讨论)
再来看一下,某些情况下可能会减少对共享资源的争用是指什么,是指并行修改和更新会更快.
仔细分析,我们分区的原则是什么?一般最常用的可能是按时间段进行范围分区,这样,修改和更新绝大多数还是在同一个分区上进行,
所以对减少共享资源的争用这方面,基本没有什么效果.
(有按科室ID进行散列分区的对应的唯一应用需求吗?有基于列表分区(典型特征值)的对应的唯一应用需求吗?基本上没有.)
分区主要从并行的角度来提高性能,但事务处理系统本身应用特性决定了它不适合这种技术.
也就是说,针对我们产品的事务处理应用特点,根本没有必要采用分区技术.
4.并行处理
根据我们的应用特点,主要分析并行查询.一般要求配合分区特性,多CPU硬件.
自Oracle 8.1.6起,增加了一个自动调节并行查询的选项:PARALLEL_AUTOMATIC_TUNING=TRUE
在相应的表上设置PARALLEL参数,Oracle就会在适当的时候自动并行化该表上的操作.
并行查询对事务处理系统基本上没有用.
因为并行查询的设计是针对数据仓库中的单用户完全消耗100的资源而做的.
而事务处理中,往往有很多并发用户,他们争用共用资源,所以你想办法让一个用户占用所有的资源是适得其反.
以上就是我对Oracle性能的一些常见解决方案的学习理解,希望能帮助大家对这些专题形成正确的理解.