Oracle 并行服务器介绍 Chao_ping@163.com

Agenda 1。什么是并行服务器： －－OPS的体系结构和实现机理 2。为什么要使用并行服务器： －－OPS系统的可以带来哪些优点 3。 使用并行服务器的注意点 －－针对OPS系统的优化 4。具体实例研究 －－OPS系统优化实例 5。讨论

一。什么是并行服务器 Oracle并行服务器是利用多个节点的计算能力来增强服务器性能，提高服务器的可用性而推出的一种技术。 它充分利用了多个节点的处理能力，允许系统处理单个节点处理不了的任务量，并且可以减少处理大任务所需要的时间。

OPS实现方法－1：Cluster

OPS实现方法－1：Cluster 实现： 所有节点共享相同的磁盘阵列，每个节点有自己的CPU，内存，本地磁盘，每个节点之间采用高速互联设备 优点： 可用性更高，单个节点失败不影响系统可用性 增加节点容易 在实际中被广泛采用

OPS实现方法－2：MPP 节点 MPP 体系结构：以高速总线互联 High Performance Switch Twin Twin - - tailed tailed connections connections 本地磁盘 2 2 - - 18 18 Copyright 觹 Oracle Corporation, 1998. All rights reserved.

OPS实现方法－2：MPP 实现： 每个节点有自己单独的磁盘，节点通过Virtual DiskLayer来存取别的节点的数据 优点： 1。对于某些能够有效分割的应用非常合适 2。节点数据不受磁盘阵列的限制 3。磁盘阵列可以非常大

Cluster结构的OPS实现 关键组件： 高速互联总线 节点1 节点2 1.Cluster Manager 2.分布式锁管理器(DLM) OPS Instance A 关键组件： OPS Instance B IPC IPC 高速互联总线 Cluster Manager Comm. Layer Comm. Layer Cluster Manager Shared Disk Driver Shared Disk Driver 节点1 节点2 1.Cluster Manager 2.分布式锁管理器(DLM) 3.节点之间的通信机制 4.磁盘子系统

二。为什么要使用并行服务器 使用OPS系统具有下面几个优点： 高可用性(HA) 高伸缩性(Scale Up) 系统性能提升（Speed Up） 对用户程序透明 减少管理上的负担

1.高可用性：24×7 OPS的解决方案： 节点软件失败 节点硬件失败(N-1个节点失败) 外围设备，电源，网络 操作系统，数据库实例，中间层 节点硬件失败(N-1个节点失败) 外围设备，电源，网络 一个实例恢复期间允许用户在别的节点上操作 最终用户感觉不到实例/单节点失败 （采用OCI接口编程)

Fail over 只要有一个节点存活，就可以保持可用性 如果使用合适的编程方法，可以做到TAF（Transparent Application Failover) 要做到更快的Failover,可以预先同时连接到两个节点 Tnsnames.ora

2。高伸缩性 随着事务数目的增加、数据量的增加和连接用户，单个节点已经处理不过来 通过使用OPS系统，通过简单的增加节点就可以达到要求，原有的节点不必废弃，可以保留投资 某些大型任务不是单个节点能够处理的，而大型机过于昂贵，OPS是理想选择 使用OPS系统，可以加快某些大型任务的响应时间，处理更大的数据量

高伸缩性（2） 单节点系统 并行系统 Hardware 100% Task Time Hardware Time 200% Task

3。性能的提升 注： 这种情况只是对某一类应用而言 单结点系统 并行服务器 Hardware 100% Task Time Hardware

4。对用户程序透明 在原来普通Oracle上开发的程序可以直接移植到OPS系统上直接运行 要达到更加好的运行效果，应用应该对OPS进行优化

5。减少管理上的负担 只需要管理一个数据库，而不是多个 在Oracle8开始，提供了GV$视图，可以在单个节点上检查整个OPS系统 新的管理工具都智能识别OPS系统，如OEM，DBCA, OUI等。

三。使用并行服务器面临的问题和具体解决方案 1。OPS系统的特有概念/面临的问题： 同步 DLM（Distributed Lock Manager） PCM Lock (Parallel Cache Management Lock) PING, False PING 2。解决方案 ：尽量减少PING和False PING 进行适当的应用分割和用户分割 进行适当的表分割 合理配置表空间，数据文件 尽量使用sequence 合理分配PCM Lock和Non-PCM Lock

同步 关键： 同一个时间，只允许一个实例拥有某一资源的修改权 同步就是指OPS系统中不同节点之间并发任务的协调：如对Data Block，Dictionary Cache，Row Cache，SCN的同步 OPS系统使用DLM和PCM Lock,Non-PCM Instance Lock来实现资源的同步 成功应用OPS系统的关键是减少同步所需的成本，包括合理分割应用，合理分割表数据，合理配置锁参数

DLM（分布式锁管理器）

续:DLM DLM是在OPS环境下，用来协调多个节点对共享资源的并发访问的。所有Oracle进程要访问共享资源，都必须和DLM打交道 接收来自server进程的请求 记录某一资源的当前用户 当资源可用时通知Server进程 当别的进程需要某一资源时，通知当前用户释放资源 和OPS节点的LCKn进程通信，

PCM Lock Non-PCM Instance Lock PCM Lock(parallel Cache Management Lock): 控制数据文件中各个Block和Lock之间的对应关系 通过gc_files_to_locks和gc_rollback_locks参数来设定 Non-PCM Instance Lock: 控制对数据文件，控制文件SGA的并发访问 比如DFS queue locks, DFS locks 两个队列记录这些信息：granted queue, convert queue

获得各类锁所需的时间 锁的种类 获得锁需要的时间 相对时间 Latch 1分钟 Local Enqueue 1毫秒 16小时 Instance Locks 或者Global Enqueue 0.1秒 69天

PCM Lock的类型 根据是否releasable分为Fixed 和Releasable lock 根据Lock和Block对应关系，分为fine grain和hashed lock Releasable Fixed Fine grain Hashed

PCM Lock 节点2 节点1 block1 Block3 Dml/select row4 Block2 PCM Lock ：一个Lock保护两个Block

PING和False Ping Ping： False Ping： 关键在于在OPS环境下，同一时间只允许一个实例修改某个Block。 R/R,R/W,W/R,W/W：只有的一种情况下不会发生Ping的现象。 8i引入了Cache Fusion技术可以减轻ping带来的影响 False Ping： 关键在于PCM Lock不是一个锁Lock一个Block。 如果采用fine grain lock就可以消除false Ping。

DML操作和 Ping - Instance 1 Instance 1 5 Instance 2 Instance 2 IDLM memory area 4 6 15 7 IDLM IDLM 14 8 13 16 3 17 Shared global area Shared global area 1 2 LCK LCK 2 1 9 11 18 Server Server DBWR process process 10 19 OPS database -

DML操作和 Ping（2） 节点2上的server进程检查本地的SGA，看是否已经以Exclusive模式拥有它将要DML的那个Block的PCM Lock。如果已经得到这个Lock，则跳到第16步。 节点2上的Server进程给LCK进程发消息，表示需要以Exclusive模式拥有某个Block的Lock LCK 进程向DLM发出请求，要求获得该Block上的Exclusive Lock。 节点2上的DLM进程检查锁状态，如果没有发现，则 让别的节点上的DLM进程检查状态 DLM进程最后发现是节点1上的某个server进程拥有该Block的Lock 节点2上的DLM向节点1上的DLM进程发消息，请求获得该Block的Lock 节点1上的DLM进程收到请求，向本级的LCK进程发出消息，别的机器请求该Lock。 节点1上的LCK进程向DBWR进程发出命令，把该Block的胀数据写入到磁盘

DML操作和 Ping（3） 10. 节点1上的DBWR接到命令，把脏数据写回到磁盘 11. 节点1上的DBWR进程向LCK进程发消息，表示已经完成任务 12. 节点1上的LCK进程修改SGA里面该Block的Lock状态 13. 节点1上的LCK进程向DLM进程报告，已经释放该锁，别的节点可以使用该锁了。 14. 节点1上的DLM告诉节点2上的DLM，表示它已经释放了该Block上的LCK， 15. 节点2上的DLM更新该进程PGA里面该Block的Lock状态， 16. 节点2上的DLM进程通知LCK进程，表示允许它现在Lock该Block 17. 节点2上的LCK进程更新SGA里面该Block的状态 18. 节点2上的LCK进程通知原来那个请求的Server进程，表示已经获得了它需要的Lock. 19. 节点2上的Server进程现在可以从磁盘读取该Block的数据，并且可以对它进行修改了

不同类型应用程序的可伸缩性 操作类型 May not scale Data warehousing Low Internet Applications with large databases 数据的可分割程度 Departmentalized applications OLTP with data partitioning High Scale well 操作类型 No changes Heavy changes

2.解决方案 进行适当的应用分割和用户分割 进行适当的表分割 合理配置表空间，数据文件 尽量使用sequence 合理分配PCM Lock和Non-PCM Lock Oracle8i/9i Cache Fusion

进行适当的应用分割 DSS类型(R/R)： 非常适合，不必专门对OPS进行特别的设计和优化 OLTP类型，具体分析： 按照各个模块的不同，分别连接到不同节点 按照用户性质的不同，分别连接到不同节点 最好是在进行应用程序设计的时候，就对OPS应用进行适当的考虑

表分割 表分割的策略： 用Freelist Groups对数据进行分割 用分区表进行数据分割

用Freelist Groups进行分割 优点： 缺点： 通用性好，从Oracle7到8i都支持 必须重新建表才能进行修改 进行导入导出之后，Freelist, Freelist group信息丢失 手工allocate extent的话，HWM增加，全表扫描时间增加

用表分区技术进行分割 优点： 可以把不同分区放到不同的表空间/物理磁盘上，减少PING同时，还可以平衡IO 缺点： 只能用于Oracle8及以上版本 需要单独购买Partition Option

对表空间数据文件的考虑 把只读数据放入只读表空间 把表和索引放到不同的表空间 把只有一个节点存取的数据放到一个数据文件里面 根据表分区的结果，把属于不同实例存取的数据放到不同的表空间里面 把由不同实例存取的数据文件放到不同的物理磁盘上 定义标准的RAW设备大小

合理使用Sequence 合理设置Cache Size 使用Sequence来产生主键 例子：产生主键的两种方法的比较： 1. SELECT MAX_ID INTO i_MAX_ID_out FROM MAX_ID WHERE TABLE_NAME = i_TABLE_NAME AND AREA_ID = i_AREA_ID FOR UPDATEe ; 2.IF i_table_name='ADDR' THEN SELECT addr_id_seq.nextval INTO o_max_id FROM DUAL; 合理设置Cache Size

PCM Lock和Non-PCM Instance lock的配置 首先要对应用和表进行适当的分割 根据表空间和数据文件的特性来分配PCM Lock数目 对只读表/主要为读的表分配较少的Lock 如果整个表空间为只读，只需给这个表空间一个锁就够了 对于DML频繁的表，而且应用/表分割不完全的数据文件/表空间，分配较多的锁 总是在gc_files_to_locks里面为每个数据文件指定锁的数目

Oracle8i Cache Fusion Select Node A Node B Database buffers 高速互联设备 Node A Node B Data transfer BSP Select Database buffers Database buffers Svr 对于R/W类型的PING， 可以通过节点之间的高速互联设备 直接从Lock一方传送到Read一方 数据文件

四－OPS系统优化实例 系统大概情况 分析当前系统瓶颈所在 考虑优化方案 实施及主要改进

系统概况 系统属于OLTP/DSS混合系统，主要为OLTP性质 有大约250个并发连接用户 有5个主要模块，模块之间耦合比较紧密 两个小型机，分别为2G内存，4个CPU 模块，用户随机连接到两个节点 系统反应过慢，用户抱怨不绝

确定系统瓶颈所在 尝试用单节点运行，反应和原来双节点相差不远，说明OPS的Scale Up很差，Speed Up更加不用说了。 检查V$SESSION_WAIT,V$SYSSTAT,发现主要等待事件是OPS特有的，V$LOCK_ACTIVITY，发现有过多的锁的转换过程 在典型运行时间做了一个report，分析结果是需要对OPS进行优化 在此之前已经对系统进行过一次优化，但是没有考虑到OPS的情况

进一步对瓶颈进行定位 检查GV$PING等OPS视图，确定那些PING现象最严重的表 检查Freelist wait事件，确定哪些表需要加大Freelist groups 检查False ping情况，发现也比较严重 检查数据文件的PCM Lock的分布，发现无论使用如何，都是同样数目的锁数目

考虑优化方案 应用程序的各个模块耦合太紧密，应用分割较难，考虑主要使用表分割，结合应用分割 鉴定一张表（MAX_ID)用来产生很多表的唯一主键，竞争特别严重，改用sequence来产生主键，消除竞争。 对PING现象严重的表进行考察，发现其中有一个列是所有表都有的，而且可以作为分割的关键列 对那些Freelist等待较多的表，用SQL*Navigator倒出建表语句，用exp倒出表的数据，修改Freelist groups参数，重新建表，导入数据 Consistent Read特别严重，考虑使用Oracle 8i版本，引入Cache Fusion技术，减少PING带来的负面影响

考虑优化方案 进一步考虑如何进行表分割 版本为Oracle8.0.6，使用表分区技术 经过仔细应用和表分析，决定根据其中的某个列AREA_ID来分割。使用range partition，AREA_ID属于1－3的分割到分区1，4－8的分割到分区2，分区分别放到两个不同的表空间。 根据AREA_ID的不同，让AREA_ID在1－3的用户连接到节点1，4－8的连接到节点2。 其中某个模块比较独立，让所有这个模块的用户都连接到第一个节点。

实施及主要结果 MAX_ID表已经丢弃不用，改用sequence，不再产生PING的情况 由于表分割的结果，已经把不同节点要存取得数据放到两个独立的表空间，因此采用hashed fixed lock，修改初始化参数gc_files_to_locks。检查V$PING等视图，PING和FALSE PING现象得到很有效的缓解 对一些Lookup表，放到只读表空间，用一个PCM Lock 检查V$SESSION_WAIT, ，和对系统作report，等待事件基本是db file sequential read， OPS事件(如DFS Lock acquisition, DFS enqueue Lock acquisition，Lock Element Cleanup,DFS Lock Convert等) 也减少很多，FALSE PING基本消失 升级到oracle8i尚未进行，因此Cache Fusion的好处不能看到

其他注意事项 在每个实例的init.ora里面指定thread, instance_number,rollback_segs, 下列参数必须在所有实例上相同 gc_files_to_locks gc_rollback_locks log_archive_format （推荐一致） 每个实例必须自己的回滚段和重做日志 重做日志、控制文件和数据文件必须放到裸设备上

讨论