그리드 인프라스트럭처는 RAC 데이터베이스의 토대이며, 노드 멤버십 관리와 RAC가 필요로 하는 클러스터 간 통신 인프라를 제공한다. 그런 다음 RAC에서 데이터베이스 저장 옵션으로 오라클이 선호하는 ASM을 살펴보았다. ASM은 모든 물리적 데이터베이스 구조를 저장하는 데 사용되는 클러스터 환경을 지원하는 완성도 높은 논리 볼륨 관리자다. 오라클 역시 ASM을 강력하게 밀고 있다. ASM을 사용하지 않더라도 이 기술에 대해 자세히 알아두는 것이 좋다. ASM은 다른 논리 볼륨 관리자와 유사한 기술을 사용하기 때문에 개념을 이해하기 쉽다.
_90

설계자와 개발자에게 있어 가장 중요한 주제는 장애에 관계없이 애플리케이션의 지속적인 가용성을 보장하는 것이다. RAC는 뛰어난 고가용성 옵션을 제공하지만, 애플리케이션이 RAC를 최대한 활용할 수 있도록 하려면 약간의 노력이 필요하다. 서드파트 도구를 사용하는 애플리케이션보다는 자체 개발한 애플리케이션에 RAC를 적용하는 것이 쉬운 편이다. 특히 소스 코드에 대한 접근이 불가능하고, 애플리케이션에 대한 RAC 사용이 서드파티 벤더와 합의되어 있지 않을 때 그러하다. FAN 프레임워크가 게시하는 이벤트를 활용하기 위해 연결 풀을 사용할 수 없는 패키지화된 애플리케이션이라면, OCI 라이브러리를 사용하는 애플리케이션에서 제공되는 세션 모드의 TAF를 사용하여 최소한의 장애 복구 능력을 제공할 수 있을 것이다.
_138

ASM은 여러 가지 측면에서 리눅스의 LVM과 비슷하지만, ASM은 볼륨 그룹과 논리 볼륨을 유지 관리하거나 파일 시스템에서 커널 전환을 위한 시스템 콜 등의 오버헤드가 없다. 그리고 ASM의 추가 장점은 기본적으로 클러스터링을 지원한다는 것이다. 11.2 버전에서 가장 근본적인 변화는 그리드 인프라스트럭처에 ASM이 통합된 것이다. 11.1과 10.2의 모범 사례 문서는 이제 쓸모가 없어졌으며, RAC에서 더 이상 ASM을 별도로 설치할 필요가 없어졌다.
_678

업계에서 애플리케이션과 워크로드 통합(consolidation)은 세계적인 추세이며, 바로 여기가 RAC가 주목받을 수 있는 분야다. 통합 프로젝트가 성공하기 위해서는 이러한 애플리케이션이 함께 공존할 수 있도록 적절한 메커니즘이 존재해야 한다. 관리자는 오라클이 서비스하는 애플리케이션에 대한 중요도 수준을 정의할 수 있어야 하며, 중요도가 떨어지는 애플리케이션이 중요도가 더 높은 애플리케이션의 자원을 빼앗아서는 안 된다.
_737

오라클 11g RAC 데이터베이스 환경의 성능 모니터링에서 가장 핵심은 이들 인프라를 활용하는 도구이다. 따라서 우리는 오라클 엔터프라이즈 관리자(EM) 데이터베이스 컨트롤이라는 표준 오라클 그래픽 인터페이스 환경을 사용한 성능 모니터링을 다룰 것이다. 또한, AWR 보고서와 ASH 보고서를 통해 수집된 성능 데이터를 검토한 후 ADDM(Automatic Database Diagnostic
Monitor) 사용에 관해 살펴보고, AWR SQL 보고서를 사용하여 개별 구문의 성능을 분석해볼 것이다. 더불어 SQL*Plus를 사용한 성능 모니터링을 다루고, 마지막으로 ADR(Automatic Diagnostic Repository)을 이용한 성능 모니터링 기능과 장애 진단에 관해서 몇 가지 살펴볼 것이다.