| 목적 |
| 범위 |
| 상세 내역 |
| 1. 최신 Patchset Update (PSU) 를 적용하라 |
| 2. UDP 버퍼 크기가 적당한 지 확인하라 |
| 3. 모든 10.2 와 11.1 클러스터에는 DIAGWAIT 값을 13으로 설정하라 |
| 4. 리눅스 환경에서는 HugePages를 구현하라 |
| 5. OS Watcher 및 Cluster Health Monitor를 구현하라 |
| 6. OS설정에 대해서는 Best Practice를 따르라 |
| 7. AIX 플랫폼에서 과도한 페이징/스와핑 이슈를 방지하기 위해, 적절한 APAR가 제대로 설정돼 있는 지 확인하라 |
| 8. NUMA 패치를 적용하라 |
| 9. 윈도우즈의 비상호적 데스크탑 힙 메모리 (noninteractive Desktop Heap)를 늘려라 |
| 10. RACcheck 유틸리티를 수행해라 |
| 11. NTP를 slewing 옵션으로 설정하라. |
| 참고 |
적용 대상:
Oracle Database - Enterprise Edition - 버전 10.2.0.1 to 11.2.0.3 [릴리즈 10.2 to 11.2]
이 문서의 내용은 모든 플랫폼에 적용됩니다.
목적
Many RAC instability issues are attributed to a rather short list of commonly missed Best Practices and/or Configuration issues. The goal of this document it to provide a easy to find listing of these commonly missed Best Practices and/or Configuration issues with the hope to prevent instability caused by these issues.
범위
이 문서의 내용은 RAC이 구현된 모든 환경에 적용된다.
상세 내역
1. 최신 Patchset Update (PSU) 를 적용하라
적용 가능한 플랫폼: 모든 플랫폼
이유?: PSU는 CPU 패치 계획을 좀더 향상시키기 위해 10.2.0.4 이상 버전에서 도입되었다. PSU는 분기마다 출시되며 최근의 CPU를 포함하고 있고 거기에 추가적으로, 운영 환경의 안정화에 중요하다고 여겨지는 개별패치(fix)들을 포함하고 있다. 만약 신규 설치건이라면, 반드시 해당 버전의 가장 최신 PSU를 적용해야 한다. 기존 시스템의 경우, 지속적이고 정기적으로 최신의 PSU를 적용하는 방식으로 운영 환경을 유지보수 하도록 계획해야 한다. 오라클 Support에 문의되고 버그로 판명되는 이슈들중에는 최신의 PSU에서 이미 해결된 알려진 버그인 경우가 많다. 그리고, 윈도우즈 환경에서는 누적 번들 패치가 PSU보다는 좀더 자주 출시가 되는데, 이 경우의 최신의 PSU는, PSU 출시 분기 동안에 나왔던 윈도우즈 번들 패치에 포함된다. .
추가 정보: PSU에 관한 더 많은 정보는 아래 문서들을 참조하라:
Document 854428.1 Intro to Patch Set Updates (PSU)
Document 1082394.1 11.2.0.X Grid Infrastructure PSU Known Issues
Document 756671.1 Oracle Recommended Patches -- Oracle Database
Document 161549.1 Oracle Database, Networking and Grid Agent Patches for Microsoft Platforms
2. UDP 버퍼 크기가 적당한 지 확인하라
적용 가능한 플랫폼: Windows를 제외한 모든 플랫폼
이유?: 인터커넥트(interconnect)는 RAC 데이터베이스에서 생명선과 같다. 그러나 UDP send/receive 버퍼에 할당된 버퍼 공간이 적당치 않다면 인터커넥트 성능에 상당히 영향을 끼치며, 이것은 곧 클러스터 안정성에 문제가 될 수 있다.
추가 정보: 적절한 UDP 버퍼 크기 산정을 위한 더 많은 정보는 아래 문서들을 참조하라:
Document 181489.1 Tuning Inter-Instance Performance in RAC and OPS
Document 563566.1 gc lost blocks diagnostics
3. 모든 10.2 와 11.1 클러스터에는 DIAGWAIT 값을 13으로 설정하라
적용 가능한 플랫폼: Windows를 제외한 모든 플랫폼
이유?: 10gR2 (10.2.x)와 11gR1 (11.1.x)에서 OPROCD 데몬을 위한 기본 마진값은 겨우 500 밀리세컨드 (0.5초)이다. 이 마진은 매우 바쁜 시스템의 경우 너무 작은 값이며 그로 인해 과부하시 가짜 리부팅 (false reboot)이 발생할 수 있다. diagwait 설정을 13으로 변경하는 것은 OPROCD의 마진을 10,000 밀리세컨드 (10초)로 변경해주며 이는 곧 바쁜 시스템에 대해 가짜 리부팅 상황을 피하게끔 충분한 마진을 부여하는 것이다. 게다가, diagwait 설정은, 만약 reboot이 발생하는 경우에 추가 디버깅해볼 수 있는 정보를 trace 화일에 쓰는 시간을 좀더 부여하게끔 해준다. 이 변경은 patchset에는 포함될 수 없다. 그 이유는 클러스터 전체의 중단이 필요하기 때문입니다. 모든 10gR2 와 11gR1 클러스터에서는 이 값을 13으로 설정할 것을 강력히 권고하는 바이다. 새로 설치하는 경우라면 인스톨 직후에 이 diagwait 값을 변경해야 한다. 기존에 설치된 시스템의 경우는 다운타임을 계획해서 필히 적용해야 한다. 현재 설정은 아래 명령어로 확인할 수 있다:
추가 정보: DIAGWAIT에 관한 더 많은 정보는 아래 문서들을 참조하라:
Document 559365.1 Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions
Document 567730.1 Changes in Oracle Clusterware on Linux with the 10.2.0.4 Patchset
4. 리눅스 환경에서는 HugePages를 구현하라
적용 가능한 플랫폼: 모든 LINUX 64-Bit 플래폼
이유?: HugePages를 구현하면 리눅스 환경에서 커널의 성능이 크게 향상된다. 이는, 더 많은 메모리를 가지고 있는 시스템의 경우 특히 그렇다. 일반적으로 12GB RAM 이상을 가진 시스템의 경우, HugePages를 적용하기에 적합한 대상이다. 더 많은 RAM을 가진 시스템일수록 HugePages 활성화를 통해서 얻는 이득이 많다. 왜냐하면 시스템이 가진 메모리가 많을 수록 커널이 그만한 양의 메모리에 대해 page table을 맵핑하고 유지해야 하는 작업량이 증가하기 때문이다. HugePages를 활성화하는 것은 커널이 관리해야 할 page수를 줄여주기 때문에 시스템이 훨씬 효율적으로 동작할 수 있게 해준다. 만약 HugePages가 활성화돼 있지 않다면, 경험적으로 봤을 때 커널이 오라클 클러스터웨어나 Real Application Clusters 데몬보다 선점하면서 인스턴스 또는 노드 eviction을 일으키는 사례가 종종 나타난다.
추가 정보:
Document 361323.1 HugePages on Linux: What It Is... and What It Is Not...
Document 401749.1 Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration
5. OS Watcher 및 Cluster Health Monitor를 구현하라
적용 가능한 플랫폼s: 모든 플랫폼
이유?: 안정성 측면과 직접 관련은 없지만, OS Watcher와 Cluster Health Monitor는 OS 상태 및 노드 및 인스턴스 eviction을 유발하는 잠재적 근본 원인을 규명하는 데 있어 매우 유용한 툴이다. 어떤 문제가 처음 발생한 이후 그 문제를 진단할 수 있는 적절한 데이터가 있다면 그 자료를 확보하는 것은 문제 원인을 규명하는 시간을 단축하게끔 해주며, 그렇게 함으로써 향후 장애를 예방할 수 있을 것이다. 이런 종류의 대부분의 3rd party 데이터 수집툴은 수집 주기가 너무 길며 (예를 들어, 5분 또는 그 이상), 그 툴들의 자료를 해석하기가 어렵거나 적절한 데이터를 수집하지 않는 경우도 있다. OS Watcher는 30초 (기본값) 간격으로 기본적인 OS 정보를 수집하는 매우 간단하고 가벼운 툴이다. Cluster Health Monitor는, 모든 플랫폼에 쓸 수 있는 것은 아니지만, 좀더 세부 수준까지 실시간으로 데이터를 수집함으로써 OS Watcher를 보완한다. 어떤 이슈에 대해 보다 빠른 진단과 디버깅을 수월하게 하는데 있어, 이 유틸리티들을 하나 또는 둘다 항상 모든 클러스터 노드에서 수행해 두는 것은 매우 중요한다.
추가 정보:
Document 301137.1 OS Watcher User Guide
Document 1328466.1 Cluster Health Monitor (CHM) FAQ
Document 580513.1 How To Start OSWatcher Black Box Every System Boot (Linux specific)
6. OS설정에 대해서는 Best Practice를 따르라
(시스템 안정화를 위한 메모리 튜닝에 관한 백서로서, 오라클과 IBM이 공동 작업함)
적용 가능한 플랫폼: 모든 AIX 버전
이유?: 백서 Oracle Real Application Clusters on IBM AIX Best practices in memory tuning and configuring for system stability는 양 벤더의 상호 경험치에 기반한 최적 사례를 함께 테스트하고 엮은 매우 좋은 문서이다. 경험적으로 RAC/AIX 클러스터에서 안정성 문제의 대부분은 이 문서에서 권고한대로 설정하여 해결할 수 있었다. AIX 버전 6.1은 이런 많은 권고안들을 기본값으로 포함하고 있으나, 이 설정들은 OS버전 또는 오라클 버전에 상관없이 모든 RAC 클러스터 상에서 확인돼야 한다.
추가 정보:
백서 다운로드: http://www.oracle.com/technetwork/database/clusterware/overview/rac-aix-system-stability-131022.pdf
Document 811293.1 RAC Assurance Support Team: RAC Starter Kit and Best Practices (AIX)
7. AIX 플랫폼에서 과도한 페이징/스와핑 이슈를 방지하기 위해, 적절한 APAR가 제대로 설정돼 있는 지 확인하라
적용 가능한 플랫폼: 모든 AIX 버전
이유?: 경험적으로 이 사안은 AIX환경에 영향을 미치는 매우 흔한 이슈이다. 이 이슈의 본질상, 이 문제에 민감한 사람이라면 완전히 시스템 hang이 되는 상황을 경험했을 것이다. RAC이 아닌 환경에서는 이것은 인위적 개입 없이는 계속 시스템 hang 상황에 빠져 있게 된다. 그러나 RAC 환경에서는 해당 노드의 응답 없음으로 인해 노드 eviction 상황으로 전개된다.
추가 정보: 이 문제에 대한 추가 정보는, 오라클 문서 Document 1088076.1 Paging Space Growth May Occur Unexpectedly on AIX Systems With 64K (medium) Pages Enabled 를 확인하라
8. NUMA 패치를 적용하라
적용 가능한 플랫폼: 모든 플랫폼
이유?: 10.2.0.4 과11.1.0.7 RDBMS 패치셋에는, NUMA (OS와 하드웨어 종속적)를 지원하는 플랫폼 상에서는 NUMA 최적화가 활성화돼 있었다. (NUMA를 지원하는 시스템 상의) RDBMS 코드내에 이 NUMA가 활성화 돼 있어서 데이터베이스의 성능 저하와 불안정을 야기하는 버그가 되어 왔었다. 10.2.0.4 과11.1.0.7에 NUMA 최적화와 관련있는 증상/이슈에 대한 전체 목록이 Document 759565.1에 나와 있다. 만약 10.2.0.4 또는 11.1.0.7 을 운영하고 있다면, NUMA관련 이슈를 적극적으로 해결하기 위해 Patch 8199533 를 적용할 것을 강력히 권고하는 바이다.
9. 윈도우즈의 비상호적 데스크탑 힙 메모리 (noninteractive Desktop Heap)를 늘려라
적용 가능한 플랫폼: Windows 플랫폼
이유?: 윈도우즈 클러스터에서 비상호적 데스크탑 힙 메모리의 기본 크기가 충분치 않음이 확인되었다. 이는 애플리케이션 연결성 이슈 및 클러스터의 일반적인 불안정(hang 및 crash)을 초래한다. 이 이슈에 대해 적극적으로 대처하기 위해, 비상호적 데스크탑 힙 메모리를 1MB까지 늘려줄 것을 권고한다. 권고치 1MB 보다 크게 늘려주는 것은, 마이크로소프트 측의 관여 없이는 수행하지 말아야 한다.
추가 정보: 비상호적 데스크탑 힙 메모리를 어떻게 조정할 수 있는 지에 대한 설명은 Document 744125.1에서 볼 수 있다.
10. RACcheck 유틸리티를 수행해라
적용 가능한 플랫폼: Linux (x86 and x86_64), Solaris SPARC 그리고 AIX (bash shell 환경)
이유?: RACcheck은 Real Application Clusters (RAC), 오라클 클러스터웨어 (CRS), Automatic Storage Management (ASM), 그리고 Grid Infrastructure (GI) 에서 다양하고 중요한 설정 정보들을 살펴볼 수 있도록 개발된 RAC 설정 감사툴이다. 이 유틸리티는, RAC Assurance 개발/지원팀에서 유지 관리되고 있는 일련의 RAC/오라클 클러스터웨어 Best Practice와 Starter Kit 문서 (Document 810394.1 참조)에서 정의된 Best Practice 와 성공 요소들을 점검하는데 이용할 수 있다. RACcheck가 지원되는 플랫폼에서 RAC을 운영하고 있는 고객이라면 클러스터 안정성에 영향을 줄 수 있는 잠재적인 설정 이슈를 식별하기 위해서 이 툴을 활용할 것을 독려하는 바이다.
추가 정보: RACcheck에 대한 더 많은 정보 및 이 유틸리티를 내려받기 위한 링크는 Document 1268927.1에서 확인할 수 있다.
11. NTP를 slewing 옵션으로 설정하라.
적용 가능한 플랫폼: 모든 Linux 및 Unix 플랫폼.
이유?: slew 옵션이 없는 경우는 시간 불일치가 특정 임계치(플랫폼마다 다름)를 넘어설 때 NTP가 시스템 글럭을 앞으로 또는 뒤로 건너뛸 수 있다. 뒤로 시간을 많이 건너 뛰게 되면 클러스터웨어는 checkin이 없다고 보고 노드 eviction을 하게 될 수도 있다. 이러한 이유로, eviction 상황을 방지하기 위해 클럭이 시간을 동기시킬 수 있도록 NTP를 slew time (speed up 또는 speed down)으로 설정할 것을 강력히 권고하는 바이다. 각 플랫폼에서 NTP time slewing을 어떻게 구현하는 지, 아래 각 플랫폼별 RAC and Oracle Clusterware Best Practices and Starter Kit 문서를 참조하라 (아래).
'ORACLE > RAC' 카테고리의 다른 글
| IBM General Parallel File System (GPFS) 3.2-3.5, 4.1 and Oracle RAC (문서 ID 1376369.1) (0) | 2015.09.06 |
|---|---|
| Convert Oracle RAC to single instance (0) | 2014.08.15 |
| 오라클 single to RAC (1) | 2014.03.12 |
| Steps to Remove Node from Cluster When the Node Crashes Due to OS/Hardware Failure and cannot boot up (Doc ID 466975.1) (0) | 2014.02.22 |
| TAF (Transparent Application Failover)란 무엇인가? (0) | 2013.06.14 |
