用Oracle并行查询发挥多CPU的威力

用Oracle并行查询发挥多CPU的威力[@more@]

用Oracle并行查询发挥多CPU的威力

来源: 作者: 发布时间:2007-04-13

用Oracle并行查询发挥多CPU的威力

在一个单独之服务器中安装更多之CPU成为目前之一个趋势。使用对称多处理服务器(SMP)之情况下,一个Oracle服务器拥有8个、16个或32个CPU以及几吉比特RAM之SGA都不足为奇。
Oracle跟上了硬件发展之步伐,提供了很多面向多CPU之功能。从Oracle8i开始,Oracle在每个数据库函数中都实现了并行性,包括SQL访问(全表检索)、并行数据操作和并行恢复。对于Oracle专业版之挑战是为用户之数据库配置尽可能多之CPU。

在Oracle环境中实现并行性最好之方法之一是使用Oracle并行查询(OPQ)。我将讨论OPQ是如何工作之和怎样用它来提升大之全表检索之响应时间以及调用并行事务回滚等等。

使用OPQ

当在Oracle中进行一次合法之、大型之全表检索时,OPQ能够极大之提高响应时间。通过OPQ,Oracle将表划分成如图A所示之逻辑块。

图 A

11L43319343023418.jpg

由OPQ划分之表

一旦表被划分成块,Oracle启用并行之子查询(有时称为杂务进程),每个子查询同时读取一个大型表中之一块。所有子查询完毕以后,Oracle将结果会传给并行查询调度器,它会重新安排数据,如果需要则进行排序,并且将结果传递给最终用户。OPQ具有无限之伸缩性,因此,以前需要花费几分钟之全表检索现在之响应时间却不到1秒。

OPQ严重依赖于处理器之数量,通过并行运行之所以可以极大之提升全表检索之性能,其前提就是使用了N-1个并行进程(N=Oracle服务器上CPU之数量)。

必须注意非常重要之一点,即Oracle9i能够自动检测外部环境,包括服务器上CPU之数量。在安装时,Oracle9i会检查服务器上CPU之数量,设置一个名为cpu_count之参数,并使用cpu_count作为默认之初始化输入参数。这些初始化参数会影响到Oracle对内部查询之处理。

下面就是Orale在安装时根据cpu_count而设置之一些参数:

fast_start_parallel_rollback
parallel_max_servers
log_buffer
db_block_lru_latches

参数

让我们进一步看看CPU之数量是如何影响这些参数之。

参数fast_start_parallel_rollback

Oracle并行机制中一个令人兴奋之处是在系统崩溃时调用并行回滚得能力。当Oracle数据库发生少有之崩溃时,Oracle能自动检测未完成之事务并回滚到起始状态。这被称为并行热启动,而Oracle使用基于cpu_count之fast_start_parallel_rollback参数来决定未完成事务之秉性程度。

并行数据操纵语言(DML)恢复能够在Oracle数据库崩溃后极大之加快其重新启动之速度。此参数之默认值是系统CPU数量之两倍,但是一些DBA们认为应该将这个值设置为cpu_count之四倍。

参数parallel_max_servers_parameter

Oracle一个显著之加强是自动决定OPQ并行之程度。由于Oracle清楚服务器中CPU之数量,它会自动分配合适之子进程之数量来提升并行查询之响应时间。当然,会有其它之外部因素,比如表之划分以及磁盘输入/输出子系统之布局等,但是根据cpu_count来设置parallel_max_servers参数将给Oracle一个合理之依据来选择并行之程度。

由于Oracle之并行操作严重依赖服务器上CPU之数量,parallel_max_servers会被设置成服务器上CPU之数量。如果在一台服务器上运行多个实例,则默认值太大了,会导致过度之页面交换和严重之CPU负担。并行之程度还依赖于目标表中分区之数量,因此parallel_max_servers应该设置成足够大以允许Oracle为每个查询选择最佳数量之并行子查询。

参数log_buffer

参数log_buffer定义了供即刻写入redo日志信息之保留RAM之数量,这个参数受cpu_count之影响。Oracle推荐log_buffer最大为cpu_count乘以500KB或128KB。CPU之数量对于log_buffer来说非常重要,因为Oracle会生成多日志写入(LGWR)进程来异步释放redo信息。

log_buffer是Oracle中最易误解之之RAM参数之一,通常存在下面几个配置错误:

log_buffer被设置得太高(例如,大于1MB),这回引起性能问题,因为大容量之结果会使得写入同步进行(例如,日志同步等待事件非常高)。log_buffer不是db_block_size之倍数。在之Oracle9i中,log_buffer应该是2048字节之倍数。

参数db_block_lru_latches

LRU锁之数量是在Oracle数据库内部用来管理数据库缓冲之,这严重依赖于服务器上CPU之数量。

很多聪明之Oracle9i之DBA使用多冲数据缓冲(例如db_32k_cache_size),他们推荐将这个未公开声明之参数重设置为默认之最大值。db_block_lru_latches参数在Oracle8i中使用得很多,但是在Oracle9i中变成了一个未公开声明之参数,因为Oracle现在根据数据库拥有之CPU数量设置了一个合理之默认值。

db_block_lru_latches默认被设置为服务器上cpu_count之一半(例如服务器上只有一个Oracle数据库)。Oracle推荐db_block_lru_latches千万不要超过cpu_count之两倍或三倍,或db_block_buffers之五十分之一。

如果使用多缓冲池则这种计算方法有一个问题,因为不能控制分配给每个数据缓冲池之锁之数量。如果db_writers参数大于1,则默认值或许显得太小。

加强服务器

Oracle数据库总是在提升性能,根据外部服务器环境检测cpu_count和基本参数设置之能力对于Oracle软件来说是一个重要之加强。

随着更多之Oracle系统转移到SMP上来,当客户要采取增强措施并将众多之数据库转移到拥有32个或64个CPU之巨大服务器上来之时候,这些参数显得愈发重要。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/620862/viewspace-970110/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/620862/viewspace-970110/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值