ORACLE RAC 記憶體SGA,PGA配置超過300G的問題

huangdazhu發表於2017-05-02
在PC伺服器發展到今天,在伺服器記憶體方面早已經超越了小型機的記憶體配置。在一般的ORACLE 伺服器上面,配置512G,1T,2T的記憶體是比較常見的事情。
但是在做ORACLE RAC的時候,特別是在進行安裝的時候,在配置ORACLE記憶體大於300G的時候,需要注意一些問題,需要把一些預設的引數進行修改。。

在一次ORACLE效能問題中從AWR報告上看gcs drm freeze in enter server mode、gc cr block congested 、gc current grant busy佔比較大的比例,這些都與DRM特性有關

所以需要關閉一些特性。可以參照ORACLE的官方文件
https://support.oracle.com/epmos/faces/DocumentDisplay?id=1619155.1&_adf.ctrl-state=1daet72ccg_241&_afrLoop=224951496521940


Best Practices and Recommendations for RAC databases with SGA size over 100GB (Doc ID 1619155.1) To BottomTo Bottom

In this Document

Purpose
Scope
Details
  Database - RAC/Scalability Community

References


APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.3 and later
Information in this document applies to any platform.

PURPOSE

The goal of this note is to provide best practices and recommendations to users of Oracle Real Application Clusters (RAC) databases using very large SGA (e.g. 100GB) per instance (note that RAC assumes homogeneously sized SGAs across the cluster). This document is compiled and maintained based on Oracle's experience with its global RAC customer base.

This is not meant to replace or supplant the Oracle Documentation set, but rather, it is meant as a supplement to the same. It is imperative that the Oracle Documentation be read, understood, and referenced to provide answers to any questions that may not be clearly addressed by this note.

All recommendations should be carefully reviewed by your own operations group and should only be implemented if the potential gain as measured against the associated risk warrants implementation. Risk assessments can only be made with a detailed knowledge of the system, application, and business environment.

As every customer environment is unique, the success of any Oracle Database implementation, including implementations of Oracle RAC, is predicated on a successful test environment. Oracle Support has identified 100 GB as a baseline for large SGA's that would benefit from the recommendations provided in this note. However, this is just a baseline, and it is possible for similar(but smaller) SGA's to benefit from these recommendations. It is thus imperative that any recommendations from this note are thoroughly tested and validated using a testing environment that is a replica of the target production environment before being implemented in the production environment to ensure that there is no negative impact associated with the recommendations that are made


SCOPE

This article applies to all new and existing RAC implementations.

This is for RAC databases only as most of the parameters listed in here are for RAC Database only.

DETAILS

 Note that the recommendations presented in this note are a result of the experience from working on databases with SGA of 1 TB and 2.6 TB.

Also, the databases with SGA of 100GB and 300GB also benefited from the recommendations

init.ora parameters:

a.      Set _lm_sync_timeout to 1200 
           Setting this will prevent some timeouts during reconfiguration and DRM. It's a static parameter and rolling restart is supported.


b.      Set _ksmg_granule_size to 134217728
           Setting this will cut down the time needed to locate the resource for a data block. It's a static parameter and rolling restart is supported.

c.      Set shared_pool_size to 15% or larger of the total SGA size.
        For example, if SGA size is 1 TB, the shared pool size should be at least 150 GB. It's a dynamic parameter.

d.      Set _gc_policy_minimum to 15000
        There is no need to set _gc_policy_minimum if DRM is disabled by setting _gc_policy_time = 0. _gc_policy_minimum is a dynamic parameter, _gc_policy_time is a static parameter and rolling restart is not supported. To disable DRM, instead of _gc_policy_time, _lm_drm_disable should be used as it's dynamic.

e.      Set _lm_tickets to 5000
        Default is 1000.   Allocating more tickets (used for sending messages) avoids issues where we ran out of tickets during the reconfiguration. It's a static parameter and rolling restart is supported. When increasing the parameter, rolling restart is fine but a cold restart can be necessary when decreasing.

f.      Set gcs_server_processes to the twice the default number of lms processes that are allocated.
        The default number of lms processes depends on the number of CPUs/cores that the server has, 
        so please refer to the gcs_server_processes init.ora parameter section in the Oracle Database Reference Guide 
        for the default number of lms processes for your server.  Please make sure that the total number of lms processes 
        of all databases on the server is less than the total number of CPUs/cores on the server.  Please refer to the Document 558185.1 
        It's a static parameter and rolling restart is supported.




 

Following patches are recommended:

11.2.0.3.5 DB PSU or above is highly recommended to address known issues with large SGA sizes.





For SGA that is larger than 4 TB and for Linux platform,
BUG 18780342 - LINUX SUPPORT FOR > 4TB SGA

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/28869493/viewspace-2138280/,如需轉載,請註明出處,否則將追究法律責任。

相關文章