登录  
 加关注
查看详情
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

li.angshan 的博客

关注数据计算领域

 
 
 

日志

 
 
 
 

RAC应用  

2009-10-29 12:02:10|  分类: oracle RAC技术 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
出现ora-04031的错误后,共享池已经完全碎片化了,此时,只能重启数据库,使数据库系统重新分配共享池,但重启数据对用户使用造成很大的不便。

 

   要了解ora-04031出现的原因,先对oracle执行sql语句的过程作一个简单的介绍:

 

    1、当数据库接收到一个sql语句时,先对这个语句执行一次哈希(hash)算法,得到一个hash

 

    2、在共享池中搜索这个hash值,如果找到,表明该语句已经被分析过,并且有完整的执行计划,跳转到第4

 

    3、如果没有找到,则首先进行一个称为parse的操作,主要是在共享池中分配内存,用于保存分析树、执行计划等,然后根据数据字典确定返回列的类型与长度(describe),并根据返回列的长度与类型申请返回结果集的内存结构(define),其中,parsedescribe这两步都要消耗共享池(shared_pool),而define这步申请的内存是在缓冲区(db_cache)

 

    4、绑定查询变量(bind),主要是将条件中的变量值替换到语句中

 

    5、执行查询并返回结果(executefetch)

 

   当数据库刚启动时,共享池是一片连续的内存区域,当有用户提交查询后,共享池逐渐消耗殆尽,这时,如果再接收到新的语句,在执行上面描述的第3步时,由于已经没有空闲的shared_pool,系统通过lru算法清除共享池中原有的一个语句,回收一块内存,如果这块内存比新语句所需内存大,则切割这片内存,一部分给新语句使用,另一部分为空闲块。显然,这种内存分配方式会导致内存块数逐渐增加,而每块内存的大小却慢慢变小。

 

   如果回收的内存比需要的内存少,则再次通过lru算法清除共享池中原有的一个语句,回收一块内存,直到回收的连续内存大小超过新语句所需的内存。如果所有能释放的内存块都释放完毕,还找不到比所需内存大的内存块,则要判断所需内存是否大于参数shared_pool_reserved_min_size所设定的大小,如果大于,则在保留区域(shared_pool_reserved)分配所需的内存大小,如果小于,则产生04031错误。由于保留区域是不释放的,因此,即使所需内存大于shared_pool_reserved_min_size所设定的大小,但保留区域已满时,同样产生04031错误。

 

   根据以上说明,可以看出,对于大型数据库应用来说,ora-04031错误是不可能完全避免的(小型应用,由于语句原型较少,所有语句都可以缓存到共享池,即可以完全避免执行上面的第3步,因此,自然不会出现这个错误),作为应用,要努力的就是尽可能减缓共享池的碎片化,并保证系统能正常使用更长时间,至少保证一个月不重启数据库时不会出现这个错误,再长时间就应该重启数据库以便让数据库重新分配共享池了。

 

   要延缓这个错误出现,就必须降低共享池碎片化的进度,有两种途径:

 

    1、加大共享池,使共享池能保留更多语句,从而减少内存重新分配的可能性。然而这会有一定副作用,首先,对于32位系统,sga1.7G的限制。对于64位的操作系统,虽然不再有这个限制,理论上可以达到4T,但数据库为了管理共享池,使用了四张系统表(sys.X$KSMSPsys.X$KSPPI,sys.X$KSPPCV,sys.X$KSMLRU)对每一个块都会在sys.X$KSMSP表中有一条记录,而每块共享池平均大小都在几K左右,严重碎片化时才几百个字节,如果共享池足够大(如4G),那么sys.X$KSMSP就会有500万以上的记录,对这张大表的任何操作都会变得非常缓慢,而任何一个不在共享池中的新语句执行都会修改sys.X$KSMSP这张表,这也是数据库运行一段时间后,性能就越来越差的原因,这时重启数据库能明显提高性能(重启数据库时系统会自动清理sys.X$KSMSP表),目前福建数据库设置的共享池是1G,可以尝试再向上调整到2G,但不建议超过2G

 

   2、使用数据库集群(rac), 数据库集群是指多台服务器节点共享磁盘阵列(数据共享),并分别独立向客户端提供服务的一种应用。由于在集群中每个节点的共享池是完全独立的,如果能将不 同的语句交给不同的节点执行,则每个节点执行的原型语句将大为减少,这样就降低了共享池交换的频率,从而使共享池碎片化过程减缓,进而延缓ora-04031错误的出现。而fmis应用能很方便地区分不同的语句原型:不同单位库操作的语句是完全不同的,前台进程与后台进程操作的语句也是完全不同的。

 

   显然,对于应用来说,第二条途径的效果将会是立杆见影的。

 二、使用rac时也需要考虑rac特有的oracle的 Cache fusion,这里也介绍一下工作原理:

  Oracle还提出了一个缓存融合的技术(Cache fusion),

  目的有两个

  1.保证缓存的一致性

  2.减少共享磁盘IO的消耗

  因此在RAC环境中多个节点保留了同一份的DB CACHE。

  缓存融合(Cache fusion)工作原理:

  1.其中一个节点会从共享数据库中读取一个block到db cache中

  2.这个节点会在所有的节点进行交叉db block copy

  3.当任何一个节点缓存被修改的时候,就会在节点之间进行缓存修改

  4.为了达到存储的一致最终修改的结果也会写到磁盘上

也 就是说使用rac的时候每个instance的dbcache同步都需要千兆网络的同步,这个流量是非常恐怖的,而且我们程序对IO的要求较高,每次写入 都必须同步dbcache的这个时间也是较慢的。以XX为例,使用rac方式exp等操作速度较单instance的速度慢最少一倍以上。因此建议在调整 为rac前慎重审核环境(包括网卡、网络交换机等)
另外就是启用rac后jdbc连接我非常同意使用手工负载均衡也就是单节点的连接方式,使用loadblance方式极力不推荐。
 

 
三、Cache fusion主要是为了保证写一致的问题,即每个数据块只能有一个主节点(master),其它节点请求这个数据块的时候,会重定向到主节点,而不是磁盘阵列
 
    但并不是所有的节点缓存都必须一样,很明显,不同节点的sga可以为不同大小.
 
    另外,Cache fusion可以强制关闭(通过设置参数gc_files_to_locks),但必须手工保证不同节点不能写同一个块
    至于您所提到的exp很慢的情况,我估计是增加了数据文件(设备),但没修改gc_files_to_locks参数导致的,注意看一下这个参数,是否包含了最后一个文件号.
  评论这张
 
阅读(124)| 评论(0)

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018