본문 바로가기

Database Cloud Storage The Essential ASM

Chapter 03. ASM Instances

Oracle Database 10g부터 Oracle Database의 두 가지 유형은 관계형 데이터베이스 관리 시스템(RDBMS)과 
자동 스토리지 관리(ASM)입니다. ASM 인스턴스는 SGA (Shared Global Area) 및 Oracle 데이터베이스 인스턴스와 
관련된 대부분의 표준 백그라운드 프로세스가 있다는 점에서 모든 Oracle 데이터베이스 인스턴스와 유사합니다.
ASM 인스턴스는 데이터베이스를 마운트하지 않고 대신 디스크 그룹을 마운트합니다.
이 장에서는 ASM 인스턴스 아키텍처에 중점을 둡니다.
 
ASM 인스턴스는 클라이언트에 대한 ASM 파일의 레이아웃을 설명하는 메타 데이터를 관리합니다.
데이터베이스는 이러한 클라이언트 중 하나입니다. ASM 메타 데이터는 ASM이 디스크 그룹을 제어하는​​데 사용하는 정보입니다.
ASM 메타 데이터는 디스크 그룹 자체에 있으며 다음 정보를 포함합니다.
• 디스크 그룹에 속한 디스크
• 디스크 그룹에서 사용 가능한 공간의 양
• ASM 디스크의 블록 할당 상태
• 디스크 그룹에있는 파일의 파일 이름
• 디스크 그룹 데이터 파일 범위의 위치
• 원자 적으로 변경되는 메타 데이터 블록에 대한 정보를 기록하는 리두 로그
• ADVM 볼륨 정보
 
ASM 인스턴스는 파일이 열리거나 생성 될 때 RDBMS 인스턴스 및 다른 클라이언트에 익스텐트 맵을 제공하고, 
이후 RDBMS 인스턴스는 익스텐트 맵을 기반으로 디스크를 읽고 직접 기록합니다. ASM 인스턴스가 입출력 (I/O) 경로에 없습니다.
데이터베이스 인스턴스는 ASM 인스턴스와 직접 통신하는 ASM 파일의 내용에만 액세스하여 이러한 파일의 레이아웃에 대한 정보를 얻습니다.
이것은 데이터베이스 포 그라운드 프로세스에 의한 파일 작성 또는 파일 확장과 같이 ASM 개입이 필요한 특정 조작 중에 발생합니다.
이 경우 데이터베이스 포어 그라운드는 ASM 인스턴스와 직접 통신하여 작업을 조정합니다(2 장에서 다룹니다).
각 데이터베이스 인스턴스는 모든 파일 조작에 대한 재 연결의 오버 헤드를 피하기 위해 ASM 인스턴스에 대한 연결 풀을 유지 보수합니다.
또한 RDBMS 인스턴스는 ASM 메타 데이터를 직접 업데이트하지 않습니다. ASM 메타 데이터는 ASM 인스턴스에 의해서만 관리되고 작성됩니다.
 
ASM 인스턴스 관리
ASM은 주어진 노드에서 ASM을 사용하는 모든 데이터베이스의 볼륨 관리자입니다.
따라서 노드의 데이터베이스 인스턴스 수에 관계없이 노드 당 하나의 ASM 인스턴스 만 필요합니다.
ASM 인스턴스는 다양한 버전의 RDBMS 인스턴스를 지원할 수 있습니다.
ASM은 이제 Grid Infrastructure 스택의 일부이므로 Clusterware뿐만 아니라 ASM도 스택에서 가장 높은 버전이어야합니다.
ASM 인스턴스 클러스터링은 통합 스토리지 풀을 만드는 핵심 요소입니다.
Real Application Clusters (RAC) 라이센스는 ASM 인스턴스를 클러스터링하는 데 필요하지 않습니다.
클러스터 환경에서 클러스터링 된 노드 당 하나의 ASM 인스턴스가 있으며 ASM 인스턴스는 피어 투 피어 (peer-to-peer) 방식으로 서로 통신합니다.
이 피어 - 투 - 피어 통신은 글로벌 enqueue 서비스 (GES), 글로벌 캐시 서비스 (GCS) 및 글로벌 리소스 디렉토리 (GRD)와 같은 
RAC Cache Fusion 인프라 (RDBMS 인스턴스와 유사 함)를 활용합니다.
ASM 인스턴스는 디스크 상태 변경, 디스크 그룹 멤버쉽 변경 및 ASM 클러스터 멤버쉽과 같은 디스크 그룹에 대한 변경 사항을 확인하거나 
전달하기 위해 다른 ASM 인스턴스에 메시지를 보냅니다.
ASM의 DLM (distributed lock manager) 트래픽은 일반적으로 최소이며 RDBMS 연결 처리량에 영향을주지 않습니다.
 
ASM 인스턴스 시작
11gR2 이전 릴리스에서는 SQL * Plus, Oracle Enterprise Manager (EM) 
또는 srvctl 명령 (Oracle Clusterware를 사용하는 경우)을 사용하여 ASM 인스턴스를 시작할 수 있습니다.
그러나 11gR2에서 ASM 인스턴스는 독립 실행 형 서버의 그리드 인프라 스트럭처 
또는 클러스터의 그리드 인프라 스트럭처의 고 가용성 서비스(HAS) 프로세스에 의해 그리드 인프라 스트럭처 스택의 일부로 시작됩니다.
ASM 인스턴스는 init.ora 파일에서 INSTANCE_TYPE = ASM 매개 변수 세트로 시작됩니다. 
마찬가지로 RDBMS 인스턴스는 INSTANCE_TYPE = RDBMS(기본값)로 식별됩니다.
다음 쿼리는 ASM 인스턴스에서 실행될 때 ASM 인스턴스임을 나타냅니다.
 
[ASM SQL] 
SELECT INSTANCE NAME FROM V$INSTANCE;
 
ASM 인스턴스는 일반적으로 +ASM으로 명명되며 RAC 구성에서 ASM 시스템 식별자 (SID)는 +ASMx 인스턴스로 명명됩니다. 
여기서 x는 인스턴스 번호를 나타냅니다. ORACLE_SID 환경 변수는 다음과 같이 설정할 수 있습니다.
$ export ORACLE_SID=+ASM1
 
INSTANCE_TYPE = ASM 매개 변수가 설정되면 Oracle 초기화 루틴에 신호하여 RDBMS 인스턴스가 아닌 ASM 인스턴스를 시작합니다.
11gR2 Grid Infrastructure 소프트웨어 스택을 ASM과 함께 스토리지 관리자로 설치하면 
Oracle Universal Installer (libc)는 libknlopt.a에서 asm_on을 연결하고 ASM이 사용되지 않으면 asm_off를 반대로 연결합니다.
이 연결 항목은 INSTANCE_TYPE의 기본값을 제어합니다.
ASM SPFILE을 디스크 그룹에 저장하려면 asm_on을 활성화해야합니다. 
인스턴스가 매개 변수 파일에 액세스하기 전에 인스턴스가 ASM 인스턴스임을 알아야하기 때문입니다.
다음은 libknlopt.a에 링크 된 내용을 보여줍니다. kfon.o는이 Oracle 실행 파일에서 ASM이 활성화되었음을 나타냅니다.
 
[grid]$ ar -t $ORACLE_HOME/rdbms/lib/libknlopt.a
 
ASM 인스턴스 중지
ASM 종료 프로세스는 SQL*Plus 또는 srvctl stop asm 명령에서 SHUTDOWN 명령을 실행할 때 시작됩니다.
ASM 인스턴스를 종료하기 전에 ASM 인스턴스를 사용하는 모든 데이터베이스 인스턴스를 종료하고 
ASM Dynamic Volume Manager(Oracle ADVM) 볼륨에 마운트 된 모든 파일 시스템을 마운트 해제하는 것이 좋습니다.
Oracle Cluster Registry (OCR) 또는 투표 파일이 디스크 그룹에 저장되어있는 경우 노드의 Clusterware를 종료하는 과정에서 
ASM 인스턴스를 종료하여 디스크 그룹 만 마운트 해제 할 수 있습니다. Clusterware를 종료하려면 crsctl stop crs를 실행하십시오.
다음 목록은 각 모드에서의 SHUTDOWN 모드와 ASM 인스턴스의 동작을 설명합니다.
• NORMAL 절 : ASM은 모든 디스크 그룹을 순서대로 분리하고 ASM 인스턴스를 종료하기 전에 진행중인 SQL이 완료되기를 기다립니다.
인스턴스가 종료되기 전에 ASM은 현재 연결된 모든 사용자가 인스턴스와의 연결을 끊기를 기다립니다.
데이터베이스 인스턴스가 ASM 인스턴스에 연결되어 있으면 SHUTDOWN 명령은 오류를 반환하고 ASM 인스턴스를 실행 상태로 둡니다.
NORMAL이 기본 종료 모드입니다.
• IMMEDIATE 또는 TRANSACTIONAL 절 : 모든 디스크 그룹을 순서대로 분리하고 ASM 인스턴스를 종료하기 전에 진행중인 SQL이 완료되기를 기다립니다.
ASM은 현재 인스턴스에 연결된 사용자가 연결을 기다리지 않습니다.
데이터베이스 인스턴스가 ASM 인스턴스에 연결되어 있으면 SHUTDOWN 명령은 오류를 반환하고 ASM 인스턴스를 실행 상태로 둡니다.
ASM 인스턴스에는 트랜잭션이 없으므로 TRANSACTIONAL 모드는 IMMEDIATE 모드와 동일하게 작동합니다.
• ABORT 절 : ASM 인스턴스는 순서대로 디스크 그룹을 분리하지 않고 즉시 종료됩니다.
이로 인해 다음 ASM 시작시 복구가 발생합니다.
데이터베이스 인스턴스가 ASM 인스턴스에 연결되어 있으면 데이터베이스 인스턴스가 중단됩니다.
ACFS 파일 시스템이 현재 Oracle ADVM 볼륨에 마운트되어 있으면 먼저 해당 파일 시스템을 마운트 해제해야합니다.
그렇지 않으면 응용 프로그램에 I/O 오류가 발생하고 ASM 저장 영역이 분리되기 전에 ACFS 사용자 데이터 및 메타 데이터가 
저장 영역에 기록되지 않을 수 있습니다.
 
ASM 인스턴스 액세스 인증
ASM 인스턴스에는 데이터 딕셔너리가 없으므로 ASM 인스턴스에 연결하는 유일한 방법은 
세 가지 시스템 권한 (SYSASM, SYSDBA 또는 SYSOPER) 중 하나를 사용하는 것입니다.
ASM 인스턴스에 연결하는 세 가지 모드가 있습니다.
• 운영 체제 인증을 사용한 로컬 연결
• 암호 인증을 사용한 로컬 연결
• 암호 인증을 사용하는 Oracle Net Services를 통한 원격 연결
 
ASM 및 데이터베이스 인스턴스에는 디스크 그룹에 대한 읽기/쓰기 운영 체제 액세스 권한이 있어야합니다.
예를 들어, ASM 인스턴스와 데이터베이스 인스턴스는 관련 ASM 디스크 그룹을 구성하는 디스크에 대해 동일한 읽기 및 쓰기 권한을 가져야합니다.
Linux 및 UNIX 시스템의 경우 이는 일반적으로 공유 Linux 및 UNIX 그룹 구성원 (OSASM 그룹)을 통해 제공됩니다.
Windows 시스템에서 ASM 서비스는 관리자로 실행해야합니다.
 
ASM에 대한 권한 정보
ASM을 설치하는 동안 모든 사용자에 대해 하나의 운영 체제 그룹을 사용하거나 시스템 권한을 분할하여 데이터베이스 관리자, 
스토리지 관리자 및 데이터베이스 운영자 각각이 별개의 운영 체제 권한 그룹을 가질 수 있습니다.
별도의 운영 체제 권한 그룹을 작성하든 하나의 그룹을 사용하여 모든 시스템 권한에 운영 체제 인증을 제공하든 관계없이 
SYSASM을 사용하여 ASM 인스턴스를 관리해야합니다. SYSDBA 권한은 ASM 인스턴스를 관리하는 데 사용할 수 없습니다.
SYSDBA 권한을 사용하여 ASM 인스턴스에서 관리 명령을 실행하면, 부적절한 권한으로 인해 오류가 발생합니다.
SYSDBA 권한은 데이터베이스가 디스크 그룹에 액세스하는 데 사용됩니다.
ASM 인스턴스를 모니터링하기 위해 설치 중에 생성되는 적절한 권한이 있는 사용자(예:SYSDBA 권한이 있는 ASMSNMP)를 사용하는 것이 좋습니다.
SYSASM으로 ASM 인스턴스에 연결하면 사용 가능한 모든 ASM 디스크 그룹 및 관리 기능에 대한 전체 액세스 권한이 부여됩니다.
 
ASM 사용자를위한 하나의 운영 체제 그룹 사용
시스템 액세스 권한을 별도의 운영 체제 그룹으로 나누지 않으려면 하나의 운영 체제 그룹을 OSDBA, OSOPER 및 OSASM ASM 권한으로 
액세스 권한이 부여 된 그룹으로 지정할 수 있습니다. 이 모든 것에 대한 기본 운영 체제 그룹 이름은 대개 dba이며, 일반적으로 기본 구성을 
위해 해당 그룹이 선택됩니다.
 
Table 3-1 shows an example of a Linux deployment without separated privileges for ASM users
 
ASM 사용자를 위한 별도의 운영 체제 그룹 사용
별도의 운영 체제 그룹을 ASM의 권한에 대한 운영 체제 인증 그룹으로 지정할 수 있습니다.
다음 목록에서는 ASM에 대한 별도의 운영 체제 인증 그룹과 해당 구성원에게 부여 된 권한에 대해 설명합니다.
• OSASM 그룹 :이 그룹에는 ASM 인스턴스에 대한 관리 권한을 제공하는 SYSASM 권한이 부여됩니다.
예를 들어, 그룹은 asmadmin 일 수 있습니다.
• ASM 그룹 용 OSDBA :이 그룹에는 ASM에 저장된 SYSDBA 권한이 부여되어 ASM에 저장된 데이터에 대한 액세스 권한이 부여됩니다.
이 그룹에는 OSASM 그룹의 권한 하위 집합이 있습니다.
별도의 관리자 권한을 구현할 때 dba와 같이 데이터베이스 인스턴스에 대해 선택한 그룹과 다른 ASM 인스턴스에 대한 OSDBA 그룹을 선택하십시오.
예를 들어, 그룹은 asmdba 일 수 있습니다.
• ASM 그룹 용 OSOPER :이 그룹에는 ASM 인스턴스에 대한 SYSOPER 권한이 부여됩니다.이 권한은 시작, 종료, 마운트, 마운트 해제 및 디스크 그룹 검사와 같은 작업을 제공합니다.
이 그룹에는 OSASM 그룹의 권한 하위 집합이 있습니다.
예를 들어, 그룹은 asmoper 일 수 있습니다.
별도의 ASM 및 데이터베이스 관리자 임무를 구현할 때,이 구성에는 다른 그룹 및 다른 소프트웨어 소유자가 필요합니다.
암시적으로 이 구현에서는 OSASM과 OSDBA가 다른 그룹이어야합니다.
이 구성의 경우 ASM 용 OSDBA 그룹을 생성해야하며 데이터베이스 인스턴스는 ASM 인스턴스에 액세스하기 위해 해당 그룹의 멤버여야합니다.
Oracle Grid Infrastructure로 구성된 설치에서 Oracle Clusterware 데이터베이스 에이전트가 데이터베이스로 실행되기 때문에 
ASM 사용자 (그리드와 같은)는 Oracle Database OSDBA 그룹 (dbal 또는 dba2)의 구성원 일 필요는 없습니다 SYSDBA를 사용하여 데이터베이스에 연결할 수 있습니다.
그러나 Oracle Restart 구성에서 ASM 사용자 (그리드)는 모든 데이터베이스의 OSDBA 그룹 (dbal, dba2 등)의 구성원이어야합니다.
Oracle Restart 소프트웨어가 ASM 사용자 (그리드)로 실행되고이 사용자는 CONNECT / AS SYSDBA 인증을 사용하여 데이터베이스를 
시작하고 중지 할 수 있어야하므로이 요구 사항이 필요합니다. 또한 운영 체제 디스크 장치의 소유자는 ASM 소프트웨어의 소유자와 동일해야합니다.
표 3-2에서는 ASM 사용자에 대해 별도의 운영 체제 권한 그룹을 사용하는 Linux 배포의 예를 보여줍니다.
 
Role/Software Owner                                     User     Group/Privilege
ASM administrator/Oracle Grid Infrastructure home   oracle     dba/SYSASM, SYSDBA, SYSOPER
Database administrator 1 home 1/Database             oracle  dba/SYSASM, SYSDBA, SYSOPER
Database administrator 2 home 2/Database             oracle  dba/SYSASM, SYSDBA, SYSOPER
Operating system disk device owner                     oracle  dba
TABLE 3-1. One Operating System Group and One Set of Privileges for All ASM Users
 
ASM 관리를위한 SYSASM 권한
SYSASM은 SYSDBA 데이터베이스 관리 권한과 ASM 저장 영역 관리 권한을 분리 할 수있는 시스템 권한입니다.
SYSASM 특권 액세스는 OSASM 그룹으로 지정된 운영 체제 그룹의 b 버쉽에 의해 부여됩니다.
이는 OSDBA 및 OSOPER 운영 체제 그룹으로 지정된 그룹의 구성원 자격을 통해 부여 된 시스템 권한 인 SYSDBA 및 SYSOPER 권한과 유사합니다.
이러한 모든 시스템 권한에 대해 하나의 그룹을 지정하거나 각 운영 체제 권한에 대해 별도의 그룹을 지정할 수 있습니다.
또한이 장 뒷부분의 "ASM 용 암호 파일 인증"에서 설명한대로 SYSASM 권한에 암호 파일 인증을 부여 할 수도 있습니다.
SQL*Plus에서 암호 인증을 사용하여 SYSASM으로 로컬로 연결하려면 다음 문을 사용하십시오.
 
Role/Software Owner                                 User     Group/Privilege
ASM administrator/Oracle Grid Infrastructure home    grid     asmadmin(OSASM)/SYSASM
                                                            asmdba(OSDBA for ASM)/SYSDBA
                                                            asmoper(OSOPER for ASM)/SYSOPER
                                                            dba1, dba2,...(OSDBA for the databases
                                                            when in an Oracle Restart configuration)
Database administrator 1/Database home 1             oracle1 asmdba(OSDBA for ASM)/SYSDBA
                                                            oper1(OSOPER for database 1)/SYSOPER
                                                            dba1 (OSDBA for database 1)/SYSDBA
Database administrator 2/Database home 2             oracle2 asmdba(OSDBA for ASM)/SYSDBA
                                                            oper2(OSOPER for database 2)/SYSOPER
                                                            dba2(OSDBA for database 2)/SYSDBA
Operating system disk device owner                    grid     asmadmin(OSASM)
표 3-2. ASM 사용자를위한 별도의 운영 체제 그룹 및 권한
 
$ sqlplus "SYS AS SYSASM"
Enter password:
 
SQL*Plus에서 암호 인증을 사용하여 원격으로 SYSASM에 연결하려면 다음 문을 사용하십시오.
 
$ sqlplus sys@\"myhost.mydomain.com:1521/+ASM\" AS SYSASM
Enter password:
 
이전 예에서 +ASM은 ASM 인스턴스의 서비스 이름입니다.
SQL*Plus에서 운영 체제 인증을 사용하여 ASM 인스턴스에 SYSASM으로 로컬로 연결하려면 다음 문을 사용하십시오.
 
$ sqlplus / AS SYSASM
 
ASM 구성 요소 관리를위한 SYSDBA 권한
SYSDBA로 연결하여 SQL*Plus 또는 ASMCMD 명령을 사용하여 데이터베이스와 연관된 ASM 구성 요소를 관리 할 수 있습니다. 
SYSDBA 권한으로 SQL 또는 ASMCMD 조작을 실행할 때 ASM 인스턴스가 아닌 데이터베이스 인스턴스에 연결하십시오.
SYSDBA로 데이터베이스 인스턴스에 연결하면 ASM 특권 세트가 제한됩니다.
예를 들어, SYSDBA 권한으로 연결된 경우 디스크 그룹을 만들 수 없습니다.
SYSDBA로 데이터베이스 인스턴스에 연결되면 ASM 작업은 다음으로 제한됩니다.
• 파일, 별칭, 디렉터리 및 템플릿 만들기 및 삭제
• 다양한 ASM 인스턴스 뷰 검사
• 이 사용자가 만든 파일에서 조작하거나 다른 사용자가 명시 적으로 액세스 권한을 부여한 파일에만 액세스합니다
• ASM 파일 액세스 제어를 다른 사용자에게 부여
 
SYSASM 권한으로 사용자 생성
SYSASM으로 ASM 인스턴스에 로그인 할 때 CREATE USER 및 GRANT SQL 문의 조합을 사용하여 SYSASM 권한이있는 사용자를 작성할 수 있습니다.
또한 REVOKE 명령을 사용하여 사용자로부터 SYSASM 특권을 취소 할 수 있으며 DROP USER 명령을 사용하여 암호 파일에서 사용자를 제거 할 수 있습니다.
 
NOTE
이 명령은 로컬 ASM 인스턴스에 대해서만 암호 파일을 갱신합니다.
다음 예제에서는 새 사용자로 식별 된 사용자에 대해 이러한 SQL 작업을 수행하는 방법을 설명합니다.
 
REM create a new user, then grant the SYSASM privilege
[SQL] CREATE USER marlie IDENTIFIED by marlie_passwd ;
[SQL] GRANT SYSASM TO marlie;
 
REM connect the user to the ASM instance
[SQL] CONNECT marlie AS SYSASM;
Enter password:
 
REM revoke the SYSASM privilege, then drop the user
[SQL] REVOKE SYSASM FROM marlie;
[SQL] DROP USER marlie;
 
ASM 암호 파일에서 사용자의 마지막 권한을 취소하면 Oracle Database 암호 파일에서와 같이 사용자가 자동으로 삭제되지 않습니다.
ASM 암호 파일에서 권한이 없는 사용자를 삭제하려면 DROP USER를 실행해야합니다.
 
ASM에 대한 운영 체제 인증
OSASM 그룹으로 지정된 운영 체제 그룹의 구성원은 SYSASM 시스템 권한에 대한 운영 체제 인증을 제공합니다.
OSASM은 ASM을 위해 독점적으로 제공됩니다. 초기에 ASM을 설치하는 사용자 만이 해당 권한에 대해 별도의 운영 체제 그룹을 
사용하는 경우 OSASM 그룹의 구성원입니다. 그러나 다른 사용자를 추가 할 수 있습니다.
OSASM 그룹의 구성원은 SYSASM 권한을 사용하여 연결하고 해당 ASM 인스턴스가 관리하는 모든 디스크 그룹에 대한 관리 액세스를 
포함하여 ASM에 대한 모든 액세스 권한을 가지고 있습니다. Linux 및 UNIX 시스템에서 dba는 ASM 용 OSASM, OSOPER 및 
OSDBA로 지정된 기본 운영 체제 그룹입니다. Windows 시스템에서 ora_dba는 OSASM, OSOPER 및 OSDBA로 지정된 기본 이름입니다.
SQL*Plus 명령, ASMCMD 명령 및 ASMCA는 운영 체제 인증을 사용합니다.
 
ASM에 대한 비밀번호 파일 인증
ASM의 암호 파일 인증은 로컬 및 원격 모두에서 작동 할 수 있습니다.
암호 파일 인증을 사용하려면 ASM에 대한 암호 파일을 작성해야합니다.
Oracle Enterprise Manager가 ASM에 원격으로 연결할 수있게하려면 암호 파일이 필요합니다.
ASM 저장 영역 옵션을 선택하면 ASMC는 ASM 디스크 그룹을 구성 할 때 초기 사용자 (SYS 및 ASMSNMP)와 함께 ASM에 대한 암호 파일을 작성합니다.
다른 사용자를 암호 파일에 추가하려면 "ASM에 대한 권한 정보"에서 설명한대로 CREATE USER 및 GRANT 명령을 사용할 수 있습니다.
ASMCA를 사용하지 않고 ASM 인스턴스를 구성하는 경우, 수동으로 암호 파일을 작성하고 Sys 사용자에게 SYSASM 특권을 부여해야합니다.
SQL*Plus 명령과 Oracle Enterprise Manager는 암호 파일 인증을 사용합니다.
 
ASM 및 ASM SPFILE
Grid Infrastructure 11gR2부터 ASM 서버 매개 변수 파일 (SPFILE)을 ASM 디스크 그룹에 저장할 수 있습니다.
ASM에 SPFILE을 저장하는 주요 이점은 관리가 쉽고 간단하다는 것입니다. 이것은 특히 클러스터 된 경우에 중요합니다.
ASM 구성. 원시 저장 영역 (원시 LUN)이 SPFILE 저장에 필요합니다. Oracle Universallnstaller(OUI)가 
Grid Infrastructure 스택을 설치하면 ASM 서버 매개 변수 파일이 자동으로 생성되어 기본 디스크 그룹에 저장됩니다.
ASM SPFILE은 ASM에 저장되고 ASM은 SPFILE을 시작해야하기 때문에 흥미로운 "닭고기 및 계란"패러다임을 제시합니다.
그리드 플러그 앤 플레이 (GPnP) 프로파일은 ASM 부트 스트랩에서 ASM SPFILE을 발견하는 데 핵심적인 역할을합니다.
이것은 다음 ASM 로그의 출력에 표시됩니다.
 
3-3 ASM alert.log
 
GPnP 프로파일은 $CRS_HOME/gpnp/peer/profile/profile.xml에 저장됩니다.
ASM 디스크 문자열은 GPnP profile.xml에 나열됩니다.
초기화 매개 변수 파일의 위치는 GPnP 프로파일에 지정됩니다.
시작과 동시에 ASM은 GPnP 프로파일을 구문 분석하여 ASM 디스크 문자열을 가져옵니다.
디스크 헤더 정보는이 디스크에 SPFILE이 있는지와 할당 단위가 SPFILE인지 여부를 표시합니다.
ASM은 디스크 헤더를 읽고 SPFILE 익스텐트가있는 디스크를 찾고 그 익스텐트를 메모리로 읽습니다.
SPFILE은 작기 때문에 전체적으로 Allocation Unit (AU)에 포함됩니다.
ASM은 SPFILE을 읽고 인스턴스를 시작합니다.
위치가 GPnP 프로파일에 설정되어 있지 않으면 검색 순서가 다음과 같이 바뀝니다.
• Oracle ASM 인스턴스 홈의 SPFILE
예를 들어 Oracle ASM 용 SPFILE은 Linux 환경의 Oracle Grid Infrastructure 홈에 다음과 같은 기본 경로가 있습니다.
$ ORACLE_HOME/dbs/spfile+ASM.ora
• Oracle ASM 인스턴스 홈의 PFILE
 
ASM SPFILE 관리
Clusterware 파일과 함께 OATA 디스크 그룹에 ASM SPFILE을 배치하는 것이 좋습니다.
ASFI 디스크 그룹에 SPFILE을 저장하려면 디스크 그룹에 대해 COMPATIBLE.ASM 디스크 그룹 속성을 11.2 이상으로 설정해야합니다.
이 설정이 완료되면 ASM SPFILE을 생성, 복사 또는 디스크 그룹으로 이동할 수 있습니다.
SQL CREATE SPFILE 문을 사용하여 ASM 인스턴스에 연결될 때 ASM SPFILE을 작성할 수도 있습니다.
ASMCMO는 SPFILE의 관리 기능을 지원하도록 향상되었습니다.
예를 들어 ASMCMO는 ASM SPFILE을 백업 (spbackup), 복사 (spcopy) 또는 이동 (spmove)하는 데 사용할 수 있습니다.
 
spcopy 및 spmove 명령은 OS에서 ASM으로 또는 ASM에서 OS로 ASM 디스크 그룹간에 파일을 복사 / 이동하는 데 사용할 수 있습니다.
spbackup은 SPFILE의 백업 사본 (버전)을 생성합니다.
이 백업 사본 파일은 표준 ASM 파일로 취급됩니다. 즉, SPFILE로 식별되지 않으므로 spmove 및 spcopy 명령으로 관리 할 수 없습니다.
ASMCMD cp 명령 만이이 백업 SPFILE을 처리 할 수 있습니다.
SPFILE이 복사되거나 이동되면 새 위치에서 SPFILE 또는 PFILE을 선택하기 위해 ASM 인스턴스를 재시작해야합니다.
SPFILE이 포함 된 디스크 그룹은 삭제할 수 없습니다. 디스크 그룹을 삭제하기 전에 SPFILE을 다른 위치로 이동해야합니다.
spcopy / spmove 명령은 ASM 인스턴스를 11g 릴리스 1에서 11g 릴리스 2로 업그레이드 한 후 매우 편리합니다.
다음 예는 이것을 보여줍니다. 이 예제는 ASM 11g Release 2 인스턴스가 11.1에서 업그레이드되었다고 가정합니다.
디스크 그룹에 SPFILE을 작성하려면 다음 단계를 수행하십시오.
 
1. Connect to the ASM instance. Here's an example:
$ sqlplus / as sysasm
2. Set the COMPATIBLE.ASM attribute to 11.2. This is covered in Chapter 4.
3. Create the SPFILE in ASM using the SQL CREATE SPFILE statement. 
For example, create an Oracle ASM SPFILE from the existing PFILE:
[SQL] CREATE SPFILE '+DATA/asmspfile.ora' FROM PFILE '$ORACLE_HOME/dbs/asmspfile.ora';
If an SPFILE already exists from the previous version, use spcopy to copy the SPFILE in the ASM disk group:
[ASMCMD] spcopy -u /uO1/oracle/dbs/spfile+ASM.ora +DATA/spfileASM.ora
Both the CREATE SPFILE statement and the spcopy command (using the -u flag) update the Grid Plug and Play (GPnP) profile. 
You can check the location of the ASM SPFILE in the GPnP profile with the ASMCMD spget command:
ASMCMD[+] spget +DATA/spfileasm.ora
4. Restart the Oracle ASM instance so that the instance reads the SPFILE in the new location.
ASM 백그라운드 프로세스
ASM 인스턴스가 시작되면 ASM의 작업과 관련된 모든 기본 백그라운드 프로세스가 시작됩니다.
모든 ASM 프로세스는 asm으로 시작하는 반면, RDBMS 인스턴스 프로세스는 ora로 시작합니다.
UNIX에서 ASM 프로세스는 다음 명령을 사용하여 나열 할 수 있습니다.
[grid]$ ps -ef | grep asm
다음은 보다 중요한 ASM 백그라운드 프로세스의 일부입니다.
• ARBx: 재조정 활동을 수행하는 종속 프로세스입니다 (x는 숫자 임).
• CKPT: CKPT 프로세스는 인스턴스 간 호출 (RAC에서)을 관리합니다.
• DBWR: 이 프로세스는 ASM 인스턴스의 SGA 버퍼 캐시를 관리합니다.
DBWR은 더티 버퍼 (변경된 메타 데이터 버퍼)를 ASM 버퍼 캐시에서 디스크로 기록합니다.
• GMON: 이 프로세스는 디스크 수준 작업 (드롭 / 오프라인) 관리 및 디스크 그룹 호환성 향상을 담당합니다.
• LGWR: LGWR 프로세스는 ASM 인스턴스의 ACM (Active Change Directory) 버퍼를 유지 관리하고 ACD 변경 레코드를 디스크로 플러시합니다.
• MARK: Resync Koordinator (MARK) 프로세스의 AU (Mark Allocation Unit) 프로세스는 실제로 RDBMS 인스턴스와 ASM 인스턴스에서 실행됩니다.
디스크가 오프라인 상태가 될 때 Staleness Registry에 대한 업데이트를 조정하는 핵심 프로세스이므로 (ASM 중복 디스크 그룹에서) 여기에 나열되어 있습니다.
• PMON: 이것은 ASM 인스턴스의 프로세스와 프로세스를 관리합니다.
• PSPO: 이 프로세스 spawner 프로세스는 다른 Oracle 프로세스를 생성 및 관리합니다.
• PZ9x: 이 프로세스는 병렬 슬레이브 프로세스 (x는 숫자)로, GV $ 쿼리를 대신하여 데이터를 가져 오는 데 사용됩니다.
• RBAL: 검색의 일부로 모든 장치 파일을 열고 재조정 활동을 조정합니다.
• SMON: 이 프로세스는 시스템 모니터이며 노드 모니터링을위한 Cluster Synchronization Services (CSS) 프로세스 (Oracle Clusterware)의 연결 역할을합니다.
ASM SGA 및 매개 변수 크기 조정
이 섹션에서는 ASM 인스턴스에서 일반적으로 사용되는 매개 변수에 대해 설명하고 모범 사례를 기반으로 이러한 매개 변수에 적절한 값을 
설정하는 방법에 대해 설명합니다. 데이터베이스의 크기와 작업량은 ASM 인스턴스의 크기 조정에 영향을주지 않으며 영향을 미치지 않습니다.
앞에서 설명한 것처럼 ASM에는 설정할 수있는 매개 변수의 수가 제한되어 있습니다.
허용되는 매개 변수는 다음과 같습니다. 그러나 이러한 매개 변수의 대부분은 설정할 필요가 없습니다.
Disk Group-Related Parameters
• ASM DISKGROUPS
• ASM DISKSTRING
• ASM POWER LlMIT
• ASM PREFERRED READ FAILURE GROUPS
Memoryand Instance-Related Parameters
• DB CACHE SIZE
• INSTANCE TYPE
• LARGE POOL SIZE
• SHARED POOL SIZE
• MEMORY TARGET
• MEMORY MAX TARGET
Instance Management-Related Parameters
• PROCESSES
• DIAGNOSTIC DEST
• REMOTE LOGIN PASSWORDFILE
ASM 인스턴스는 데이터베이스 인스턴스와 마찬가지로 자체 SGA 구조를 사용합니다.
다음은 ASM SGA를 구성하는 구성 요소를 보여줍니다.
• DB_CACHE_SIZE이 값은 ASM 메타 데이터 블록을 캐시하는 데 사용되는 ASM 버퍼 캐시의 크기를 결정합니다.
DB_CACHE_SIZE는 4K의 메타 데이터 블록 크기를 기반으로합니다.
이 블록 크기는 캐시 된 메타 데이터의 버퍼 페이지 크기이며 데이터베이스 블록 크기에 영향을 미치지 않습니다.
• SHARED_POOL 이것은 인스턴스를 관리하기위한 표준 메모리 사용 (제어 구조 등)에 사용됩니다.
이 값은 열린 파일 범위 맵을 저장하는데도 사용됩니다.
• LARGE_POOL LARGE_POOL 값은 대용량 페이지 할당에 사용되지만 일반적으로 SHARED_POOL이 설정된 경우에는 사용되지 않습니다.
적절한 SGA 값이 ASM 인스턴스에 대해 설정되면 다음 SQL*Plus 명령을 사용하여 확인할 수 있습니다.
[SQL] SHOW SGA
Oracle Database 11g부터 ASM은 init.ora 매개 변수 MEMORY_TARGET 및 MEMORY_MAX_TARGET을 사용하여 
AMM (Automatic Memory Management) 기능을 활용할 수 있습니다.
이 두 개의 새로운 매개 변수를 설정하면 ASM 인스턴스의 모든 Oracle 관련 메모리가 자동으로 관리 및 조정됩니다.
AMM은 메모리를 목표 메모리 크기로 조정하고, 필요에 따라 인스턴스의 SGA와 PGA (Program Global Area) 사이에서 메모리를 재분산 및 재할당합니다.
그러나 ASM 인스턴스에는 상당히 정적 인 메모리가 필요하기 때문에 Oracle 메모리 매개 변수를 설정하지 않는 것이 가장 좋습니다.
MEMORY TARGET의 기본값인 256MB는 대부분의 구성에 적합합니다. 따라서, 메모리 목표 설정 매개 변수조차도 설정할 필요가 없습니다.
NOTE
디스크 그룹, 파일 또는 디스크의 수는 실제로 ASM SGA 크기에 큰 영향을 미치지 않습니다.
그러나 GES 자원/큐 삽입을 통한 custator의 노드 수와 ASM Processes 매개 변수를 통한 
ASM에 연결하는 활성 데이터베이스의 수는 ASM SGA에 가장 큰 영향을 미칩니다.
ASM Processes 매개 변수는 데이터베이스 통합의 양에 직접 영향을 미치며 ASM 인스턴스의 SGA 크기에 영향을줍니다.
ASM Processes init.ora 매개 변수는 ASM 인스턴스에서 시작할 수있는 프로세스 수를 제한합니다. 
따라서 여러 데이터베이스가 ASM을 사용하는 데이터베이스 통합 구성을 구현하는 경우이 매개 변수를 기본값에서 수정해야 할 수 있습니다.
다음은 ASM Processes 매개 변수 설정에 대한 권장 사항입니다 (RAC 및 비 RAC 시스템 용).
11.2.0.2 ASM 구성의 경우 :
노드 당 ASM에 연결하는 데이터베이스 인스턴스가 10개 미만인 경우 다음을 사용하십시오.
50 * (노드 당 DB 인스턴스 + 1)
노드 당 ASM에 연결하는 10 개 이상의 데이터베이스 인스턴스의 경우 다음을 사용하십시오.
{50 * MIN (노드 당 db 인스턴스 수 + 11)} + {10 * MAX (#db 인스턴스 per node - 10, 0)}
11.2.0.3에서 ASM Processes 매개 변수의 기본값은 CPU 코어 * 80 + 40입니다.
CPU 코어 값은 폴링 될 때 ASM으로 다시 전송 된 번호입니다. 기본 MEMORY TARGET이 자동으로 파생됩니다.
11.2.0.2에서 11.2.0.3으로 업그레이드하는 동안 ASM에서 "memory_target is too small"오류를 방지하려면 
ASM이 적절한 기본값을 파생하도록 MEMORY TARGET을 설정 해제해야합니다.
그러나 MEMORY TARGET이 명시 적으로 설정된 경우 오류를 방지 할만큼 충분히 큰지 확인해야합니다.
고객이 MEMORY TARGET 값을 수동으로 설정하려면 다음 지침을 사용해야합니다.
• PROCESSES를 명시 적으로 설정하면 MEMORY TARGET을 다음보다 작게 설정해야합니다.
256M + 프로세스 * 132K(64비트) 또는 256M + 프로세스 * 120K(32비트)
• PROCESSES가 설정되지 않은 경우 MEMORY TARGET을 다음보다 작게 설정해야합니다 :
256M + (available_cpu_cores * 80 + 40) * 132K (64 비트) 또는 256M + (available_cpu_cores * 80 + 40) * 120K (32 비트)
MEMORY TARGET 값을 설정하려면 다음 명령을 사용하십시오.
[SQL] ALTER SYSTEM SET MEMORY_TARGET=500M;
데이터베이스 인스턴스에서 할 수있는 것처럼 MEMORY_TARGET 매개 변수의 값까지 동적으로 MEMORY_TARGET을 증가시킬 수도 있습니다.
NOTE
AMM 및 Linux HugePages는 호환되지 않습니다.
일반적으로 데이터베이스에 HugePages를 사용하는 것이 가장 좋습니다.
그러나 ASM의 경우 AMM을 계속 사용하는 것이 좋습니다.
ASM 상태 점검 모니터
11g 릴리스 1에서 Health Monitor는 Oracle Diagnosability Framework의 일부로 도입되었습니다.
이 상태 모니터에는 ASM 인스턴스 상태, 특히 디스크 그룹 및 ASM 인스턴스와 연관된 메타 데이터의 상태 점검이 포함됩니다.
상태 검사는 첫 번째 인시던트 실패시 충분한 진단을 수집합니다.
이 정보는 Enterprise Manager에서 사용할 페이로드 찾기 상태 모니터에 기록됩니다.
또한 v$hm_finding 뷰는 상태 및 손상 설명 필드를 포함하여 특정 정보와 함께 상태 검사기 이벤트가 트리거 될 때 채워집니다.
특정 오류가 발생하면 상태 검사기가 트리거됩니다.
이러한 체커는 다음을 모니터링합니다.
• 공간 부족 오류로 인한 할당 실패 ASM이 특정 디스크 그룹에 대해 공간 부족을 발견하면 공간 부족 반응성 상태 검사기가 트리거됩니다.
이 공간 부족 상태는 Oracle 오류 메시지 ORA-15041에 의해 표시됩니다.
이 메시지가 디스크 그룹에 대해 생성되면 대응 적 상태 검사기가 트리거됩니다.
• 누락 된 디스크로 인한 마운트 실패 누락 된 디스크 반응 상태 검사기는 디스크 그룹 마운트 작업 중 하나 이상의 디스크 그룹 구성원 디스크를 찾지 못하면 트리거됩니다.
이 누락 된 디스크 조건은 Oracle 오류 메시지 ORA-15042에 의해 표시되며 디스크 그룹 마운트 중에이 메시지가 생성되면 대응 상태 검사기가 트리거됩니다.
반응 검사기가 실행되면 쿼리를 실행하여이 디스크 그룹의 알려진 구성원 디스크를 확인하고 누락 된 디스크의 경로 이름을 추출합니다.
이 정보는 엔터프라이즈 관리자가 사용하기위한 상태 모니터 찾기를 생성하는 데 사용됩니다.
이것이 단일 인스턴스 구성이거나이 디스크 그룹을 마운트 할 클러스터의 첫 번째 노드 인 경우이 기능은 이미 다른 디스크에 성공적으로 마운트 된 
디스크 그룹에 따라 다르기 때문에 상태 검사기는 누락된 디스크의 경로 이름을 확인할 수 없습니다.
• 클러스터 전체의 가시성 문제로 인한 디스크 추가 / 온라인 장애 디스크 가시성 반응 상태 검사기는 사용자가 디스크 그룹에 
디스크를 추가하려고 시도 할 때 트리거되며 현재 디스크 그룹이 마운트 된 모든 노드에서 디스크를 볼 수 없습니다.
Oracle 오류 메시지 ORA-15075를 나타냅니다.
반응 검사기가 실행되면 쿼리를 실행하여 모든 활성 ASM 인스턴스에 대한 검색 세트를 결정합니다.
Health Monitor 찾기는 발견 된 디스크 목록을 포함하는 트레이스 파일의 이름으로 생성됩니다.
• 클라이언트 파일 놓기 실패 사용자가 하나 이상의 클라이언트가 현재 액세스하고있는 ASM 파일을 놓으려고하면 파일 놓치기 반응 상태 검사기가 트리거됩니다.
액세스 충돌로 인한이 파일 놓기 오류는 Oracle 오류 메시지 ORA-15028에 의해 표시됩니다.
반응 검사기가 실행되면 쿼리를 실행하여 현재 ASM 인스턴스에 연결된 데이터베이스 인스턴스와 오류가 발생한 데이터베이스 인스턴스를 확인합니다.
• 불충분 한 디스크로 인한 마운트 실패 디스크 그룹 마운트 작업 중 ASM이 디스크 그룹의 구성원 디스크를 충분히 찾지 못하면 
Insufficient Disks reactive health checker가 트리거됩니다.
이 디스크 상태는 Oracle 오류 메시지 ORA-15063에 의해 표시됩니다. 반응 검사기가 트리거되면 디스크 검색을 수행하고 검색 정보를 트레이스 파일에 씁니다.
트레이스 파일의 이름을 제공하는 상태 모니터 결과가 생성됩니다.
• 너무 많은 오프라인 디스크로 인한 마운트 실패 디스크 그룹 마운트 작업 중에 ASM이 디스크 그룹의 구성원 디스크 중 하나 이상을 찾지 못하면 
디스크 누락 상태 검사기가 트리거됩니다. 너무 많은 오프 라인 디스크 상태는 Oracle 오류 메시지 ORA-15066에 의해 표시됩니다.
이 메시지가 디스크 그룹 마운트 중에 생성되면 대응 적 상태 검사기가 트리거됩니다. 반응 검사기가 실행되면 디스크 검색을 수행하고 파트너 및 
상태 테이블 정보를로드합니다.
발견 된 디스크 목록은 발견 된 각 디스크의 파트너 디스크 목록과 함께 트레이스 파일에 기록됩니다.
이를 통해 오류의 정확한 원인을 파악할 수 있습니다. 트레이스 파일의 이름을 제공하는 상태 모니터 결과가 생성됩니다.
다음은 Health Check 트리거에 기반한 v$hm_finding의 예입니다. 이 예에서 이벤트는 "디스크 누락으로 인한 마운트 실패"이며, 
이는 ORA-15042에 의해 트리거됩니다.
3-5 ORA-15042
[SQL] select time_detected, description, damage_description 
from v$hm_finding;
클러스터의 다른 인스턴스가 이 디스크 그룹을 성공적으로 마운트 한 경우,
검사기는 gv$asm_disk를 질의하고 디스크 목록을 추적 파일에 덤프합니다.
디스크 번호를 기반으로 로컬 인스턴스에서 디스크 번호를 기반으로 어느 것이 누락되었는지에 대한 정확한 추측을 할 수 있습니다.
요약
ASM 메타 데이터는 ASM 인스턴스에 의해 관리됩니다.
ASM 인스턴스는 SGA와 일반적인 백그라운드 프로세스가 대부분 있다는 점에서 모든 Oracle 인스턴스와 유사합니다.
데이터베이스 인스턴스와 동일한 실행 파일을 사용할 수 있습니다.
ASM 인스턴스는 데이터베이스를 마운트하지 않고 대신 디스크 그룹을 마운트합니다.
ASM 인스턴스는 데이터베이스 인스턴스에서 ASM 파일을 사용할 수 있도록하는 데 필요한 메타 데이터를 관리합니다. 
ASM 인스턴스와 데이터베이스 인스턴스는 모두 모든 ASM 디스크에 액세스 할 수 있어야합니다.
ASM 인스턴스는 파일이 열리거나 생성 될 때 데이터베이스 인스턴스에 익스텐트 맵을 제공합니다.
데이터베이스 인스턴스는 Extent 맵을 기반으로 디스크를 직접 읽고 씁니다. ASM 인스턴스는 I/O 경로에 없습니다.
cs