CHAPTER04. ASM Disks and Disk Groups

인프라를 구축하는 첫 번째 작업은 ASM 관리하에 디스크를 발견하고 배치하는 것입니다.
이 단계는 스토리지 관리자와 시스템 관리자가 함께하는 것이 가장 좋습니다.
SAN (storage area network) 환경에서는 디스크가 올바르게 식별되고 구성되어 있다고 가정합니다. 
즉, SAN 구조 내에서 적절히 구역화되거나 "LUN 마스킹"되어 운영 체제 (OS)에서 볼 수 있습니다.
이 장의 개념은 플랫폼 일반 사항이지만 Linux 또는 Solaris 플랫폼을 사용하여 예제를 구체적으로 보여줍니다.
 
1. ASM 스토리지 프로비저닝
디스크를 ASM에 추가하기 전에 스토리지 관리자는 스토리지 배열에서 디스크 세트 또는 논리 디바이스를 식별해야합니다.
디스크는 다음 중 하나 일 수 있으므로 디스크라는 용어는 느슨하게 사용됩니다.
• 전체 디스크 스핀들
• 물리적 디스크 스핀들의 파티션
• 여러 디스크에 걸친 여러 디스크 파티션 집합
• RAID (독립 드라이브 중복 배열) 그룹 세트에서 조각된 논리 장치
• NFS 파일 시스템에서 생성된 파일
앞선 장치가 생성되면 논리 장치 번호 (LUN)로 간주됩니다. 이러한 LUN은 OS에 논리 디스크로 제공됩니다.
이 책에서는 OS에 제공된 LUN이나 디스크를 일반적으로 디스크라고합니다. LUN 및 디스크라는 용어는 서로 바꿔서 사용할 수 있습니다.
DBA 및 시스템 관리자는 성능 저하없이 사용할 수 있는 최대 LUN 크기 또는 최상의 성능을 제공하는 LUN 크기에 대해 의심스러워합니다. 
예를 들어, 1TB 또는 2TB 크기의 LUN은 100GB 또는 200GB 크기의 LUN과 동일한 성능을 발휘합니까?
크기만으로는 LUN의 성능에 영향을 미치지 않습니다.
기본 하드웨어, LUN을 구성하는 디스크 수 및 LUN에 정의 된 미리 읽기 및 다시 쓰기 캐싱 정책은 차례로 LUN의 속도에 영향을줍니다.
디스크 그룹에 LUN 크기 또는 ASM 디스크 수에 대한 매직 번호는 없습니다.
성능 및 가용성을 위한 최적의 스토리지 구성에 대한 스토리지 공급 업체의 조언은 공급 업체에 따라 다를 수 있으므로 ???에 문의하십시오.
사용 가능한 데이터베이스 크기와 스토리지 하드웨어를 고려할 때, LUN 관리를 줄이기 위해 더 큰 LUN을 생성하고 가능한 경우 LUN이 
드라이브를 공유하지 않도록 별도의 스토리지 배열 RAID 세트에서 LUN을 생성하는 것이 가장 좋습니다.
스토리지 배열이 로우 엔드 범용 스토리지 유닛이고 스토리지 RAID가 사용되지 않는 경우, ASM 중복을 사용하고 전체 드라이브를 
ASM 디스크로 사용하는 것이 가장 좋습니다. 또한 ASM 디스크 크기는 디스크 그룹의 크기를 변경할 수 있는 최소 증가량입니다.
 
NOTE
12c 구성 이전의 ASM 디스크의 최대 디스크 크기는 2TB이고 최소 디스크 크기는 4MB입니다.
사용자는 12C 이전 환경에서 크기가 2TB 미만인 ASM 디스크를 작성해야합니다.
사용자가 2TB보다 큰 ASM 후보 디스크를 지정하면 다음과 같은 메시지가 표시됩니다.
 
[SQL] 
create diskgroup DATA EXTERNAL REDUNDANCY DISK
'/dev/sdg1' NAME asmdisk1,
ATTRIBUTE 'au_size'='4M',
'compatible.asm'='11.2',
'compatible.rdbms';
 
create diskgroup DATA EXTERNAL REDUNDANCY
*
ERROR at line 1 :
ORA-15018 : diskgroup cannot be created
ORA-15099 : disk '/dev/asm_dsk1' is larger than maximum size of 2097152 MBs
 
2. ASM Storage Device Configuration
이 절에서는 이전 절에서 제공된 운영 체제에 제공된 저장 장치 구성에 관련된 단계 및 고려 사항에 대해 자세히 설명합니다.
이 기능은 일반적으로 시스템 관리자 또는 ASM 관리자(즉, 루트 권한을 가진 사용자)가 수행합니다.
일반적으로 OS에 제공된 디스크는 Unix/Linux 시스템의 /dev 디렉토리에서 볼 수 있습니다.
각 OS에는 SCSI (Small Computer System Interface) 디스크 이름 지정이 있습니다.
예를 들어, Solaris 시스템에서 디스크의 SCSI 이름 형식은 cwtxdysz입니다. 
여기서 c는 제어기 번호이고, t는 대상이고, d는 LUN/디스크 번호이며, s는 파티션입니다.
파티션을 생성하는 목적은 세 가지입니다.
• OS label VTOC (볼륨 목차)를 건너 뜁니다. 운영 체제에 따라 OS 레이블에 대한 다양한 요구 사항이 있습니다. 
즉, 일부 레이블은 사용되기 전에 OS 레이블이 필요할 수도 있고 그렇지 않은 레이블도 있습니다.
예를 들어, Solaris 시스템에서 파티션 4 또는 6과 같이 디스크에 첫 번째 1MB를 건너 뛰는 파티션을 만드는 것이 가장 좋습니다.
파티션되지 않은 디스크를 실수로 잘못 사용하거나 덮어 쓸 수 있기 때문에 디스크를 사용하고 있음을 나타내는 자리 표시자를 만듭니다.
• ASM 스트라이핑과 스토리지 배열 내부 스트라이핑 사이의 정렬을 유지합니다.
목표는 ASM 파일 범위 경계를 스토리지 배열에서 수행 할 수 있는 모든 스트라이핑과 일치시키는 것입니다.
Oracle 데이터베이스는 데이터 파일에서 1MB 오프셋에 맞추어진 많은 1MB 입출력 (I/O)을 수행합니다.
불일치로 인해 I/O에 여분의 디스크가 하나씩 포함될 수 있으므로 스토리지 배열의 스트라이프와 이러한 I/O의 정렬을 잘못하면 효율성이 약간 떨어집니다.
이 정렬이 특정 I/O의 대기 시간에 영향을 미치지는 않지만 디스크 탐색 횟수를 늘려 시스템의 전체 처리량을 줄입니다.
이러한 불일치는 운영 체제와 별개입니다.
그러나 일부 운영 체제에서는 정렬을 제어하기가 더 어려워 지거나 ASM 디스크의 블록 0에 더 많은 오프셋을 추가 할 수 있습니다.
ASM 디스크에 사용되는 디스크 파티션은 스토리지에서 OS로 표시되는 LUN 내에서 1MB로 가장 잘 맞춥니다. 
ASM은 디스크 헤더를 포함하는 메타 데이터 용 디스크의 첫 번째 할당 단위를 사용합니다.
ASM 디스크 헤더 자체는 ASM에 ASM 디스크로 제공된 디스크의 블록 0에 있습니다.
ASM 디스크 범위 경계를 스토리지 배열 스트라이프에 맞추는 것은 스토리지 배열 스트라이프가 2의 거듭 제곱이면 의미가 있습니다. 
그렇지 않으면 관심이 별로 없습니다.
LUN의 블록 0에서 ASM 디스크를 시작할 수 있다면 정렬 문제가 해결되지만 일부 운영 체제 (특히 Solaris)에서는 작동하지 않습니다.
Linux에서는 블록 0에서 ASM 디스크를 시작할 수 있지만 관리자가 LUN에서 fdisk를 실행하고 ASM 디스크 헤더를 삭제할 가능성이 있습니다.
따라서 LUN의 블록 0에서 ASM 디스크를 시작하는 대신 항상 파티션을 사용하는 것이 좋습니다.
 
3. ASM Disk Device Discovery
디스크가 OS에 제공되면 ASM은 디스크를 발견해야합니다.
이를 위해서는 디스크 장치 (Unix 파일 이름)의 소유권이 루트에서 Grid Infrastructure 스택의 소프트웨어 소유자로 변경되어야합니다.
일반적으로 시스템 관리자가 이를 변경합니다.
이 예에서는 디스크 c3t19d5s4, c3t19d16s4, c3t19d17s4 및 c3t19d18s4가 식별되고 소유권이 oracle : dba로 설정됩니다.
이제 이러한 디스크를 검색하도록 ASM을 구성해야합니다.
이는 ASM init.ora 매개 변수 ASM_DISKSTRING을 정의하여 수행됩니다.
이 예에서는 다음 와일드 카드 설정을 사용합니다.
 
*.asm_diskstring='/dev/rdsk/c3t19d*S4'
 
표준 SCSI 이름 (예 : cwtxdysz 또는 /dev/sda)을 사용하는 대신 특수 파일을 사용하는 것이 좋습니다.
이 옵션은 표준 명명 규칙을 수립하고 ASM 디스크(예:asmdisk1)를 쉽게 식별 할 때 유용합니다.
이 옵션은 Linux 명령에서 mknod 또는 udev 생성 이름을 사용하여 특수 파일을 작성해야합니다.
다음은 mknod의 사용 예입니다.
c3t19d7s4라는 기존 장치 파티션에 대해 asmdisk1이라는 특수 파일을 만들려면 다음과 같이 OS 주 번호와 부 번호를 결정할 수 있습니다.
 
[root@racnode1]# ls -lL c3t19d7s4
 
NOTE
주 번호와 부 번호는 /dev 디렉토리의 장치 특수 파일과 연관되며 특수 장치 파일에 대한 user-level 요청에 의해 
액세스 될 실제 드라이버와 장치를 결정하기 위해 운영 체제에서 사용됩니다.
앞의 예는이 장치의 주 장치 번호와 부 장치 번호가 각각 32와 20임을 보여줍니다.
처음의 c는 이것이 문자 (원시) 파일임을 나타냅니다.
주 번호와 부 번호를 얻은 후 mknod 명령을 사용하여 c3t19d7s4와 연관된 문자 및 블록 특수 파일을 만듭니다.
다음과 같이 /dev 디렉토리 아래에 /dev/asmdisk라는 특수 파일을 만들 수 있습니다.
 
[root@racnode1]# mkdir /dev/asmdisk
[root@racnode1]# cd /dev/asmdisk
[root@racnode1]# mknod asmdisk1 c 32 20
Listing the special file shows the following:
[root@racnode1]# ls -l
 
이 장치는 기본 장치 c3t19d7s4와 동일한 주 번호 및 부 번호를 가지고 있습니다.
이 파티션 (또는 슬라이스)이 ASM 인스턴스에 액세스 할 수 있게하려면 이 특수 파일의 사용 권한을 적절한 oracle 사용자 사용 권한으로 변경하십시오.
 
[root@racnode1]# chown grid:asmadmin disk1
[root@racnode1]# ls -l /dev/disk
 
ASM에 의해 발견 될 모든 필수 디스크에 대해 이 단계를 반복하십시오.
이제 슬라이스는 ASM 인스턴스로 액세스 할 수 있습니다.
ASM_DISKSTRING은 /dev/asmdisk/*로 설정할 수 있습니다.
일단 발견되면 디스크를 ASM 디스크로 사용할 수 있습니다.
 
노트
/dev/asm 경로는 ACFS 구성 파일과 ADVM 볼륨을 배치하기 위해 ACFS에 예약되어 있으므로 /dev/asm 디렉토리에 
mknod 장치를 만드는 것은 좋지 않습니다. 11gR2 Clusterware 설치 또는 업그레이드 중에 root.sh 또는 
rootupgrade.sh 스크립트가 /dev/asm 디렉토리를 제거했다가 다시 만들어 원래 mknod 장치를 삭제할 수 있습니다.
대신 /dev/asmdisk와 같은 다른 디렉토리를 사용해야합니다.
ASM은 "on-disk"헤더 및 검색 기준 (ASM_DISKSTRING)을 사용하여 디스크 그룹을 구성하는 모든 필수 디스크를 검색합니다.
ASM은 해당 ASM 검색 문자열과 일치하는 디스크 만 검색합니다. ASM 디스크 탐색에는 얕은 및 깊은 두 가지 형태가 있습니다.
얕은 검색의 경우 ASM은 열 수있는 디스크를 간단히 검색합니다.
이는 적절한 권한을 가진 모든 디스크 장치에서 "ls -l"을 실행하는 것과 같습니다.
심층 탐색을 위해 ASM은 적합한 디스크 디바이스 각각을 엽니 다.
대부분의 경우, 표준 테이블 대신 *_STAT 테이블을 쿼리하는 경우를 제외하고는 ASM 발견이 중요합니다.
 
노트
클러스터 된 환경의 ASM의 경우 모든 노드에서 동일한 경로 이름이나 주 또는 보조 장치 번호를 가질 필요는 없습니다.
예를 들어, 노드 7은 /dev/rdsk/c3t7d4s4 경로가 가리키는 디스크에 액세스 할 수 있지만 node2는 동일한 장치에 대해 /dev/rdsk/c4t7d4s4를 표시 할 수 있습니다.
ASM은 디스크가 모든 노드에서 동일한 이름을 가질 필요는 없지만, 해당 인스턴스의 발견 문자열을 통해 각 ASM 인스턴스에서 동일한 디스크를 볼 수 있어야합니다.
ASM 노드간에 경로 이름이 다른 경우 필요한 조치는 검색 경로와 일치하도록 ASM_DISKSTRING을 수정하는 것입니다.
ASMLIB가 디스크 검색 및 스캔 프로세스를 처리하기 때문에 ASMLIB를 사용하는 Linux 시스템에서는 문제가되지 않습니다.
 
탐색에 성공하면 ASM 인스턴스의 V$ASM_DISK 뷰는 발견된 디스크를 반영합니다.
이후의 모든 뷰는 달리 명시하지 않는 한 RDBMS 인스턴스가 아니라 ASM 인스턴스에서 쿼리됩니다.
다음 예제에서는 정의된 ASM_DISKSTRING을 사용하여 발견된 디스크를 보여줍니다.
NAME 열은 비어 있고 GROUP_NUMBER는 0으로 설정됩니다. 디스크 그룹과 아직 연관되지 않은 디스크가 검색 되었기 때문입니다.
따라서 이름이 null이고 그룹 번호가 0입니다.
 
[SQL] 
SELECT NAME, PATH, GROUP_NUMBER FROM V$ASM DISK;
 
Exadata 환경에서 스토리지 셀의 물리적 디스크를 셀 디스크라고합니다.
그리드 디스크는 셀 디스크에서 생성되며 UBCELL 인터페이스를 통해 ASM에 제공됩니다. 
Exadata에서 디스크 그룹을 생성하는 데 사용됩니다.
Exadata에서 ASM_DISKSTRING의 기본값은 'o/*/*'입니다.
LIBCELL에 제시된 이러한 Exadata 디스크는 블록 장치로 OS에 제공되는 것이 아니라 내부 네트워크 장치로 제공됩니다. 
OS 수준에서는 볼 수 없습니다. 그러나 kfod 도구는 ASM 디스크 검색을 확인하는 데 사용할 수 있습니다.
다음은 그리드 디스크의 kfod 출력을 보여줍니다.
 
$ kfod disk=all
 
앞의 출력 결과는 다음과 같습니다.
• 그리드 디스크는 세 개의 저장 셀 (192.168.10.12,192.168.10.13 및 192.168.10.14)에서 제공됩니다.
디스크에는 디스크 그룹과 함께 회원 상태를 반영하는 다양한 헤더 상태가 있습니다.
디스크의 헤더 상태는 다음과 같습니다.
• FORMER :이 상태는 디스크가 이전에 디스크 그룹의 일부 였음을 나타냅니다.
• CANDIDATE :이 상태의 디스크를 디스크 그룹에 추가 할 수 있습니다.
• MEMBER이 상태는 디스크가 이미 디스크 그룹에 속해 있음을 나타냅니다.
디스크 그룹은 마운트되어 있거나 마운트되어 있지 않을 수 있습니다.
• PROVISIONED :이 상태는 CANDIDATE와 유사하여 디스크 그룹에 추가 할 수 있습니다.
그러나 프로비저닝 된 상태는이 디스크가 ASMLIB를 사용하여 구성되었거나 사용할 수 있음을 나타냅니다.
ASM은 디스크를 CANDIDATE로 표시하지 않습니다.
CANDIDATE가 HEADER_STATUS 인 디스크는 ASM 디스크 탐색의 평가 결과입니다.
정상적인 DROP DISK를 통해 ASM에 의해 디스크가 떨어지면 헤더 상태가 FORMER로 표시됩니다.
또한 디스크가 오프라인 상태가되어 강제로 삭제 된 경우 HEADER_STATUS는 MEMBER로 유지됩니다.
다음은 ASM 시스템에서 디스크 상태를 보기 위해 실행하는 유용한 쿼리입니다.
 
[SQL]
SELECT NAME, PATH, HEADER_STATUS, MODE_STATUS FROM V$ASM_DISK;
 
V$ASM_DISK_STAT 및 V$ASM_DISKGROUP_STAT 뷰는 V$ASM_DISK 및 V$ASM_DISKGROUP과 동일합니다.
그러나 V$ASM_DISK_STAT 및 V$ASM_DISKGROUP_STAT 뷰는 메모리에서 폴링되며 마지막 딥 디스크 검색을 기반으로합니다.
이러한 새로운 뷰는 효율적인 경량 액세스를 제공하기 때문에 EM (Enterprise Manager)은 주기적으로 디스크 수준에서 성능 통계를 쿼리하고 
상당한 오버 헤드를 발생시키지 않고 디스크 그룹 수준에서 공간 사용 통계를 수집 할 수 있습니다.
 
4. 타사 볼륨 관리자 및 ASM
권장되는 방법은 아니지만 Veritas VxVM 및 IBM LVM과 같은 호스트 볼륨 관리자는 ASM 아래에 위치 할 수 있습니다.
예를 들어, 논리 볼륨 관리자 (LVM)는 원시 논리 볼륨을 생성하고 이를 디스크로 ASM에 제공 할 수 있습니다.
그러나 타사 LVM은 호스트 기반 미러링 또는 스트라이핑을 사용하지 않아야합니다.
ASM 알고리즘은 서로 다른 디스크에 대한 I/O가 상대적으로 독립적이며 병렬로 진행될 수 있다는 가정에 기반합니다.
볼륨 관리자 가상화 기능 중 하나가 ASM 아래에서 사용되면 구성이 복잡하고 혼란스러워지며 DRL (Dirty Region Log) 유지 관리와 같이 
오버 헤드가 불필요하게 발생할 수 있습니다. DRL은 이 장에서보다 깊이있는 토론자에서 논의됩니다.
클러스터 환경에서 이러한 구성은 특히 비쌀 수 있습니다. ASM은 데이터베이스 파일에 대해 이 구성의 기능을 제공하는데 더 효과적입니다.
또한 RAC 환경에서 ASM이 타사 볼륨 관리자를 통해 실행될 경우 볼륨 관리자는 클러스터를 인식해야합니다. 
즉, 볼륨 관리자는 클러스터 볼륨 관리자 (CVM) 여야합니다.
그러나 어떤 경우에는 ASM 하에서 볼륨 관리자를 갖는 것이 합리적 일 수 있습니다.
(예 : sysadmin에 단순화 된 관리가 필요하고 디스크 할당의 추적이 필요할 때)
볼륨 관리자를 사용하여 논리 볼륨을 ASM 디스크로 만드는 경우 논리 볼륨은 LVM RAID 기능을 사용하지 않아야합니다.
 
5. NFS에서 ASM 디스크 준비
ASM은 NFS (Network File System) 파일을 ASM 디스크로 지원합니다.
ASM 스토리지 용 NFS를 준비하려면 ASM이 실행중인 서버에서 NAS NFS 파일 시스템에 액세스 할 수 있어야합니다.
다음 단계는 NFS 파일 시스템을 사용하여 ASM 디스크를 설정하고 구성하는 데 사용할 수 있습니다.
1. NAS에서 파일 시스템을 작성하십시오. NAS 서버에 따라 LUN을 생성하고 LUN에서 RAID 그룹을 생성한 다음 블록 장치에서 파일 시스템을 생성해야합니다.
2. ASM을 실행중인 호스트 서버가 액세스 할 수 있도록 NAS 파일 시스템을 반출하십시오.
이 메커니즘은 사용중인 파일러 또는 NFS 서버에 따라 다릅니다.
일반적으로 /etc/exports 파일을 사용하여 원격으로 마운트 할 NFS 파일 시스템을 지정해야합니다.
3. 호스트 서버에서 NFS 파일 시스템이 마운트 될 마운트 지점을 만듭니다.
# mkdir /oradata/asmdisks
# chown -R grid:asmadmin /oradata/asmdisks
4. /etc/fstab을 다음 항목으로 업데이트하십시오.
nfssrv1 : /u01/asmdisks/oradata/asmdisks nfs
rw, bg, hard, nointr, tcp, vers=3, timeo=600, rsize=32768, wsize=32768, actimeo=0 0 0
5. mount -a 명령을 사용하여 호스트 서버에 NFS 파일 시스템을 마운트하십시오.
6. NFS 파일 시스템 파일을 ASM 디스크로 사용할 수 있도록 초기화하십시오.
$ dd if=/dev/zero of=/oradata/asmdisks/asm_disk1 bs=1M count=1000000
적절한 수의 디스크를 구성하려면이 단계를 반복해야합니다.
7. ASM이 새로 작성된 디스크 파일을 발견 할 수 있는지 확인하십시오(즉, 사용 권한이 grid:asmadmin인지 확인하십시오).
8. OUI에서 ASM 구성을 묻는 프롬프트가 표시되면 ASM 디스크 문자열을 적절하게 설정하십시오.
올바른 NFS 마운트 옵션을 설정하는 것이 매우 중요합니다.
잘못된 마운트 옵션을 설정하면 파일 열기시 예외가 발생합니다.
이것은 다음 목록에 나와 있습니다.
RAC 및 Clusterware 코드는 쓰기 호출에 O_DIRECT 플래그를 사용하므로 데이터 쓰기는 캐시를 우회하여 
NFS 서버로 직접 이동하므로 여분의 캐싱 계층으로 인한 손상을 피할 수 있습니다.
모든 노드 (예 : 공유 라이브러리) 또는 단일 노드 (예 : 추적 파일)가 액세스하는 파일에서 읽기 전용으로 열리는 
파일 시스템 파일은 마운트 옵션 actimeo가 0보다 큰 마운트 포인트에 있을 수 있습니다.
다중 노드에서 동시에 쓰고 읽는 파일 (예 : 데이터베이스 파일, 응용 프로그램 출력 파일 및 노드간에 공유 된 원시 컴파일된 라이브러리)은 
actimeo가 0으로 설정된 탑재 지점에 있어야합니다.
이것은 stat() 호출에 대한 네트워크 라운드 트립을 저장할뿐만 아니라 호출이 완료되기를 기다릴 필요도 없습니다.
이는 특히 단일 노드에서 파일을 읽고 쓰는 경우 속도가 크게 빨라질 수 있습니다.
경고 : NFS 파일 시스템/nfs_data2가 잘못된 옵션으로 마운트되었습니다.
(rw, vers = 3, rsize = 32768, wsize = 32768, hard, proto = tcp, timeo = 600, retrans = 2, sec = sys, addr = strracnfs01-p)
경고 : 예상 NFS 마운트 옵션 : rsize> = 32768, wsize> = 32768, hard, noac / actimeo = O
 
6. Direct NFS
Oracle Database에는 Direct NFS (dNFS)를 통한 Network File System (NFS) 클라이언트가 기본적으로 지원됩니다.
Oracle Database 11gR1에 도입된 오라클 최적화 NFS 클라이언트인 dNFS는 데이터베이스 커널에 직접 구축됩니다.
dNFS는 OS를 우회하기 때문에 기본 OS NFS 클라이언트 드라이버보다 빠른 성능을 제공합니다.
또한 dNFS가 활성화되면 사용자 구성 또는 조정이 거의 필요하지 않습니다.
데이터는 사용자 공간에서 한 번만 캐시되므로 커널 공간에 두 번째 복사본이 없습니다.
또한 dNFS는 암시적 네트워크 인터페이스 로드 균형 조정을 제공합니다.
ASM은 NFS 클라이언트 기능을 Oracle Database 소프트웨어 스택에 직접 통합하는 dNFS 클라이언트를 지원합니다.
RAC 구성에 dNFS를 사용하는 경우 몇 가지 특별한 고려 사항이 필요합니다.
dNFS는 투표 파일을 저장 (실제로 액세스)하는 데 사용할 수 없습니다.
그 이유는 투표 파일에 액세스하는 방법에 있습니다.
CSS는 멀티 스레드 프로세스이며 dNFS (현재 상태)는 스레드로부터 안전하지 않습니다.
OCR 파일 및 기타 클러스터 파일 (데이터베이스 파일 포함)은 ASM 파일 I/O 작업을 사용하여 액세스됩니다.
ASM Dynamic Volume Manager(Oracle ADVM)는 현재 NFS 기반 ASM 파일을 지원하지 않습니다.
 
7. OS 플랫폼에서 ASM 디스크 준비
이 절에서는 특정 운영 체제 및 환경에 맞게 ASM을 구성하는데 필요한 특정 작업에 대해 설명합니다.
 
리눅스
Linux/Windows와 같은 Intel 기반 시스템에서는 처음 63 개의 블록이 MBR (Master Boot Record) 용으로 예약되었습니다.
따라서 첫 번째 데이터 파티션은 31.5KB 오프셋에서 시작합니다 (즉, 63 배 512 바이트는 31.5KB와 동일).
이 오프셋은 많은 스토리지 어레이의 메모리 캐시 또는 RAID 구성에 오정렬을 야기 할 수있어 I/O가 중복되어 성능이 저하 될 수 있습니다.
이러한 성능 영향은 병렬 쿼리 처리 및 전체 테이블 스캔과 같은 대용량 I/O 작업 부하에서 특히 두드러집니다.
다음은 EMC Powerpath 장치에 대해 sfdisk를 사용하여 수동으로 정렬을 수행하는 방법을 보여줍니다.
이 절차는 파티션 정렬이 필요한 모든 OS 장치에 적용 할 수 있습니다.
 
Create partition alignment of 1M
$ cat sfdisk_alignment.txt
# -
# -- Partition alignment of Data / FRA disks with 1MB offset
# Repeat lines for each device to be passed to ASM/ASMLIB
echo "2048 ,," | sfdisk -uS /dev/emcpowerb
Here's an example output:
# echo "2048 ,," | sfdisk -uS /dev/emcpowerb

To check on the partition alignment
# cat check alignment.txt
sfdisk -uS -l /dev/emcpowerb
[root@ljtcdb157 work]# ./check_alignment.txt

Check that partitions exist
# /sbin/fdisk -l /dev/emcpowerb
cat /proc/partitions

Solaris
이 절에서는 Solaris 환경에서 디스크 장치를 만드는 데 필요한 몇 가지 뉘앙스에 대해 설명합니다.
Solaris format 명령은 OS 슬라이스를 만드는 데 사용됩니다.
슬라이스 0과 2 (SMI 레이블의 경우)는 Solaris VTOC가 포함되어 있으므로 ASM 디스크로 사용할 수 없습니다.
다음은 장치에 대한 format 명령 출력 (파티션 맵)의 예입니다.

# /dev/rdsk/c2t12d29

슬라이스 4가 생성되고 4 개의 실린더를 건너 뛰므로 VTOC를 상쇄합니다.
/dev/rdsk 디렉토리에 나열된 논리 문자 장치를 사용하십시오.
이 디렉토리의 장치는 물리적 장치 파일에 대한 기호 링크입니다.
다음은 그 예입니다.

[root@racnode1]# ls -l /dev/rdsk/cOt2dOs4

To change the permission on these devices, do the following:
[root@racnode1]# chown oracle:dba ../../devices/pci@lf,4000/scsi@3/sd@2,O:e,raw

이제 ASM 인스턴스가 슬라이스에 액세스 할 수 있습니다.
ASM DISKSTRING을 /dev/rdsk/c*s4로 설정하십시오.
실제 디스크 문자열은 각 환경마다 다릅니다.

AIX
이 절에서는 AIX 용 ASM 디스크를 구성하는 방법에 대해 설명합니다. 또한 AIX 디스크를 사용할 때 필요한 몇 가지주의 사항을 권장합니다.
AIX에서 디스크는 볼륨 그룹에 처음 할당 될 때 또는 AIX chdev 명령을 사용하여 수동으로 설정 될 때 PVID (Physical Volume Identifier)가 지정됩니다.
PVID가 할당되면 물리적 디스크 및 ODM(Object Data Manager)이라고하는 AIX 서버의 시스템 오브젝트 데이터베이스에 저장됩니다.
PVID는 디스크의 처음 4KB에 상주하며 AIX lspv 명령을 사용하여 표시됩니다.
다음 목록에서 처음 두 디스크에는 할당 된 PVID가 있고 다른 디스크에는 할당되지 않았습니다.

# lspv

PVID 할당 디스크가 ASM 디스크 그룹에 통합되면 ASM은 ASM 디스크 헤더를 디스크의 처음 40 바이트에 기록하여 PVID를 덮어 씁니다.
처음에는 아무런 문제가 발생하지 않지만 이후의 재부팅시 OS는 ODM 데이터베이스와 함께 PVID를 디스크에 복원하므로 
ASM 디스크가 손상되고 잠재적으로 데이터가 손실 될 수 있습니다. 따라서 ASM이 사용할 디스크에 PVID를 포함시키지 않는 것이 좋습니다.
PVID가 있고 ASM이 디스크를 아직 사용하지 않은 경우, AIX chdev 명령을 사용하여 PVID를 지울 수 있습니다.
이와 같은 손상을 막기 위해 AIX에 기능이 추가되었습니다.
LVM 정보 블록에 쓰는 AIX 명령은 디스크가 ASM에 의해 이미 사용 중인지 판별하기 위해 추가 검사가 추가됩니다.
이 메커니즘은 이러한 디스크가 LVM에 할당되지 않도록하여 Oracle 데이터가 손상되는 것을 방지하는 데 사용됩니다.
표 4-1은이 검사가 수행되는 명령과 해당 AIX 버전을 나열합니다.
AIX 6.1 및 AIX 7.1 LVM 명령에는 Oracle에서 사용되는 AIX 장치를보다 잘 관리하는 데 사용할 수있는 새로운 기능이 포함되어 있습니다.
이 새로운 기능에는 여러 노드의 공유 디스크를보다 잘 식별하는 명령, 장치에 의미있는 이름을 할당하는 기능 및 시스템 관리자가 실수로 
디스크를 재사용하지 못하도록 디스크를 ASM에 할당 할 때 나중에 디스크를 사용할 수 있는 잠금 메커니즘이 포함됩니다.
이 새로운 기능은 해당 기능을 제공하는 최소 AIX 레벨과 함께 표 4-2에 나열되어 있습니다.
이 관리성 명령은 AIX 5.3에는 존재하지 않습니다. 다음은 디스크 잠금 및 검사 기능을 설명합니다.

[SQL] 
select name, path, mode_status, state 
from v$asm_disk 
order by name;

디스크를 보호하기 위해 ASM Lock이 사용하는 모든 원시 디스크를 잠급니다.
Oracle RAC가 클러스터에서 활성화되어있는 동안이 작업을 수행 할 수 있습니다.

[root@racnode1]# lkdev -l hdiskASMd001 -a

Then use the lspv command to check the status of the disks.
그런 다음 lspv 명령을 사용하여 디스크의 상태를 확인하십시오.

[root@racnode1]# lspv

ASM 및 다중 경로 지정
I/O 경로는 일반적으로 초기화 장치 포트, 패브릭 포트, 대상 포트 및 LUN으로 구성됩니다.
이 I/O 경로의 각 순열은 독립적인 경로로 간주됩니다.
예를 들어 각 노드에 두 개의 개별 스위치 포트에 연결된 두 개의 호스트 버스 어댑터 (HBA) 포트가 LUN에 대한 
백엔드 스토리지의 두 개의 대상 포트에 연결되어있는 경우 LUN의 8개 경로가 LUN에서 볼 수 있습니다. 
OS 관점 (두 개의 HBA 포트는 2 개의 스위치 포트와 두 개의 대상 포트를 1 번 LUN이 8 개의 경로를 겹치게합니다).
경로 관리자는 각 운영 체제 장치에 SCSI 조회 명령 (SCSUNQUIRY)을 실행하여 장치에 대한 다중 경로를 찾습니다.
예를 들어, Linux에서는 scsUd 호출이 SCSUNQUIRY 명령을 통해 SCSI 장치를 쿼리하고 중요한 제품 데이터 (VPD) 페이지 Ox80 또는 Ox83을 활용합니다.
디스크 또는 LUN은 SCSUNQUIRY 명령에 공급 업체 및 제품 식별자와 고유한 일련 번호를 포함하여 자체에 대한 정보로 응답합니다.
이 쿼리의 출력은 Ox80 또는 Ox83 페이지를 제대로 지원하는 모든 SCSI 장치에서 고유 한 값을 생성하는 데 사용됩니다
일반적으로 동일한 일련 번호를 가진 SCSUNQUIRY에 응답하는 장치는 여러 경로에서 액세스 할 수있는 것으로 간주됩니다.
경로 관리자 소프트웨어는 다중 경로 소프트웨어 드라이버도 제공합니다.
대부분의 다중 경로 드라이버는 파이버 채널 연결 SCSI-3 장치에 대한 다중 경로 서비스를 지원합니다.
이 드라이버는 하나 이상의 실제 HBA 장치에서 이름 지정 및 전송 서비스를 받습니다.
다중 경로 지정을 지원하려면 실제 HBA 드라이버가 이 드라이버에서 제공하는 다중 경로 지정 서비스를 준수해야합니다.
다중 경로 지정 도구는 다음과 같은 이점을 제공합니다.
• 다중 경로 LUN을위한 단일 블록 장치 인터페이스를 제공합니다.
• 패브릭 포트, 채널 어댑터 또는 HBA를 포함하여 I/O 경로에서 구성 요소 오류를 감지합니다.
• 경로 손실이 발생하면 이러한 도구는 I/O가 프로세스 중단없이 사용 가능한 경로로 다시 라우팅되도록합니다.
• 이벤트가 발생할 때 자동으로 다중 경로를 재구성합니다.
• 장애 조치 된 경로가 가능한 빨리 재확인되고 자동 장애 복구 기능을 제공하는지 확인합니다.
• 라운드 로빈, 대기중인 최소 I/O 및 최소 서버 속도와 같은 다양한로드 균형 조정 방법을 사용하여 성능을 극대화하도록 다중 경로를 구성합니다.
주어진 디스크에 여러 개의 경로가 정의되어 있으면 각 경로는 모두 동일한 물리적 LUN을 참조하지만 os 수준에서 고유한 경로 이름으로 표시됩니다. 
예를 들어, LUN /dev/rdsk/c3t19dls4 및 /dev/rdsklc7t22dls4가 동일한 디스크 장치를 가리킬 수 있습니다.
다중 경로 추상화는 I/O 경로 장애시 무중단 장애 조치뿐 아니라 HBA 전반에 걸쳐 I/O 로드 균형 조정을 제공합니다.
그러나 ASM은 디스크당 하나의 고유한 장치 경로만 발견 할 수 있습니다.
예를 들어 ASM_DISKSTRING이 /dev/rdsk/*인 경우 동일한 장치에 대한 여러 경로가 검색되고 ASM은 이를 설명하는 오류 메시지를 생성합니다.
일반적으로 이 SCSI 블록 계층 위에 위치하는 다중 경로 드라이버는 일반적으로 하위 경로를 가상화하는 의사 장치를 생성합니다.
예를 들어 EMC의 PowerPath의 경우 /dev/rdsk/emcpower*의 ASM_DISKSTRING 설정을 사용할 수 있습니다.
이 디스크 장치에 I/O가 발행되면 다중 경로 드라이버는 이를 인터셉트하여 기본 서브 경로에 필요한로드 균형을 제공합니다.
다중 경로 소프트웨어의 예로는 Linux Device Mapper, EMC Powerpath, DMP (Veritas Dynamic Multipathing), 
Oracle Sun Traffic Manager, HDLM (Hitachi Dynamic Link Manager), 
Windows MPIO 및 IBM SDDPCM(Subsystem Device Driver Path Control Module)이 있습니다.
또한 QLogic과 같은 일부 HBA 공급 업체는 다중 경로 지정 솔루션을 제공합니다.

노트
오라클은 이러한 다중 경로 지정 도구를 인증하거나 검증하지 않기 때문에 사용자는 다중 경로 드라이버로 ASM/ASMLIB의 공급 업체 인증을 검증하는 것이 좋습니다.
ASM은 다중 선적 기능을 제공하지 않지만 다중 경로 도구가 생성하는 경로나 장치가 fstab 시스템 호출로부터 성공적인 리턴 코드를 가져 오는 다중 경로 도구를 활용합니다.
Metalink 참고 294869.1에서는 ASM 및 다중 경로 지정에 대해 자세히 설명합니다.

Linux 장치 매퍼
장치 매퍼는 여러 장치 드라이버를 서로 쌓을 수 있는 커널 프레임 워크를 제공합니다.
이 섹션에서는 ASM, ASMLIB 또는 Udev와 관련된 장치 매퍼의 세부 사항을 설명합니다. 
이들 구성 요소는 많이 사용되기 때문입니다.
이 절에서는 ASM을 보다 효과적으로 지원하기 위해 Linux Device Mapper 및 Udev에 대한 개괄적인 개요를 제공합니다.
Linux 장치 맵퍼의 서브 시스템은 Linux 다중 경로 체인의 핵심 구성 요소입니다.
이 구성 요소는 다음과 같은 높은 수준의 기능을 제공합니다.
• 단일 저장 장치에 대한 다중 경로를 위한 단일 논리 장치 노드.
• 경로 손실이 발생하여 I/O가 사용 가능한 경로로 재라우팅되고 이로 인해 상위(사용자)계층에서 중단이 발생하지 않습니다.

장치 맵퍼는 libdevmapper 라이브러리를 사용하여 구성됩니다.
이 라이브러리는 그림 4-1과 같이 dmsetup, LVM2, 다중 경로 도구 및 kpartx와 같은 여러 모듈에서 사용됩니다.
장치 매퍼는 서로 다른 블록 장치에 대한 스택 대상 드라이버의 다양한 조합 생성을 지원하는 커널 상주 메커니즘을 제공합니다.
스택의 최상위 레벨에는 매핑된 단일 장치가 있습니다.
이 맵핑된 디바이스는 대상 디바이스에 대한 맵 정보를 libdevmapper 라이브러리 인터페이스를 통해 디바이스 맵퍼로 전달하여 디바이스 맵퍼에서 구성됩니다.
이 역할은 다중 경로 구성 도구 (나중에 설명 함)에 의해 수행됩니다.
각 매핑된 세그먼트는 시작 섹터와 길이 및 대상 드라이버 관련 개수의 대상 드라이버 매개 변수로 구성됩니다.
다음은 두 개의 블록 장치 아래에있는 다중 경로 장치의 매핑 테이블 예입니다.

o 1172123568 multipath 0 0 2 1 round-robin 0 1 1 65:208 1000 round-robin 0 1 1 65:16 1000

앞의 내용은 시작 섹터가 0이고 길이가 1172123558이며 드라이버가 다중 경로 다음에 다중 경로 지정 매개 변수임을 나타냅니다.
65 : 208 및 65:16 (major : minor)의 두 가지 장치가 이 mapper와 연결됩니다.
매개 변수 1000은 1,000개의 I/O 후에 두 번째 경로가 라운드 로빈 방식으로 사용됨을 나타냅니다.
다음은 블록 장치 아래에 하나가 있는 논리 볼륨 (LVM2) 장치에 대한 매핑 테이블의 예입니다.

o 209715200 linear 9:1 188744064

이것은 시작 섹터가 0이고 장치 9:1(major:minor)에 대한 선형 드라이버가 있는 길이가 209715200임을 나타냅니다.

Udev
이전 버전의 Linux에서는 설치시 모든 장치가 dev-FS(/dev) 파일 시스템에 정적으로 생성되었습니다.
대부분의 장치가 실제로 시스템에 연결되지 않았기 때문에 /dev 항목에 거대한 항목 목록이 생성되어 대부분 쓸모가 없었습니다.
이 방법의 또 다른 문제점은 커널이 장치를 선착순으로 할당했기 때문에 동일한 장치의 이름을 다르게 지정할 수 있었기 때문에 
발견된 첫 번째 SCSI 장치는 /dev/sda라는 이름이었고 두 번째 /dev/sdb 등이 있습니다.
Udev는 필요할 때 장치 노드를 관리하여 이 문제를 해결합니다.
또한 이름 - 장치 매핑은 장치가 검색되는 순서가 아니라 사전에 정의된 규칙 시스템을 기반으로합니다.
Udev는 커널 핫 플러그 ​​메커니즘을 사용하여 사용자 공간에 장치 파일을 만듭니다.
현재 구성의 발견은 Sysfs에서 생성된 블록 장치 노드를 탐색하여 수행됩니다.
이 파일 시스템은 블록 장치, 버스, 드라이버 등과 같은 커널 개체를 사용자 공간에 계층적으로 제공합니다.
장치 노드는 블록 장치의 요청 큐가 커널의 블록 하위 시스템에 등록 될 때 생성되는 핫 플러그 ​​이벤트에 대한 반응으로 Udev에 의해 생성됩니다.
그림 4-2와 같이 다중 경로 구현 환경에서 Udev는 다음 작업을 수행합니다.
• 경로의 추가 및 억제는 다중 경로 사용자 공간 데몬이 청취합니다.
이렇게하면 다중 경로 장치 맵이 실제 토폴로지에서 항상 최신 상태로 유지됩니다.
• 경로 추가 또는 억제 후 사용자 공간 콜백은 사용자 공간 도구 kpartx를 호출하여 장치 파티션에 대한 맵을 생성합니다.

많은 사용자가 심볼 링크를 사용하여 Udev 대신 ASM 디스크를 가리 킵니다.
우리가 얻게되는 공통적인 질문은, 디바이스 별명 지정과 관련하여 mknod 디바이스와 심볼 링크를 사용하는것 사이에 차이점(장점/단점)이 있습니까?
어느 쪽도 영구적인 이름 지정을 제공하지 않습니다.
즉, mknod 장치를 사용하면 메이저/마이너 번호에 대한 새 별칭이 생깁니다.
그러나 장치가 어떤 이유로 든 주/부 번호를 변경하면 심볼릭 링크가 부실한 것처럼 mknod 장치가 부실합니다.
지속성을 얻는 유일한 방법은 ASMLIB, ASM 또는 Udev를 사용하는 것입니다.
예를 들어 Udev에서 해당 키워드를 사용하여 mknod / block / char 장치 또는 SYMLlNK를 만들 수 있습니다.
다음은 그 예입니다.

KERNEL=="sd*", BUS=="scsi", PROGRAM=="/sbin/scsi_id -g -u -s %p", RESULT=="1360a98000686f6375575a542d6a677744" , NAME= "asmdisk1",
OWNER="root" ,GROUP= "root" ,MODE="0640"

첫 번째 예제는 sd 장치를 "asmdisk1"로 수정합니다.
두 번째 예제는 sd 장치를 그대로두고 sd 장치를 가리키는 "asmdisk1"이라는 새로운 심볼릭 링크를 만듭니다.
두 방법 모두 UUID에 의해 주어진대로 올바른 장치를 가리키고 있습니다. 분명히 한 가지 방법만 사용해야합니다.

다중 경로 구성
이제 Linux 다중 경로 작업과 관련된 다양한 도구와 모듈에 대해 이야기 했으므로, 
이 섹션에서는 Linux 다중 경로 작업을 수행하는 데 필요한 구성 단계에 대해 설명합니다.
Linux 다중 경로를 구동하는 기본 구성 파일은 /etc/multipath.conf입니다.
구성 파일은 다음 섹션으로 구성됩니다.
• 기본값 : 특정 장치 설정이 지정되지 않은 경우 속성의 기본값이 사용됩니다.
• 블랙리스트 : 다중 경로 검색에서 제외되어야하는 장비.
• Blacklist_exceptions : 블랙리스트 섹션에 나열되어 있음에도 불구하고 다중 경로 검색에 포함되어야하는 장치.
이 섹션은 일반적으로 블랙리스트 섹션에서 와일드 카드를 사용하여 많은 디스크를 제거하고 몇 개의 디스크를 수동으로 사용하려는 경우에 사용됩니다.
• 다중 경로 : 다중 경로 토폴로지를 정의하는 주요 섹션입니다. 값은 장치의 WWID (Worldwide Identifier)로 인덱싱됩니다.
• 장치 : 장치 별 설정

다음은 다중 경로 .conf 파일에서 일반적으로 사용되는 구성 매개 변수입니다(전체 목록은 시스템의 설명서 페이지를 참조하십시오).
Path-Grouping_policy :이 매개 변수는 경로 그룹 정책을 정의합니다.
가능한 값은 다음과 같습니다.
• 장애 조치 : 하나의 활성 경로가 있습니다. 이는 액티브/패시브 구성과 동일합니다.
• Multibus : 모든 경로가 하나의 우선 순위 그룹에 있으며로드 균형 조정 구성에 사용됩니다. 이것이 기본값입니다.
• Group_by_serial/group_by_prio/group_by_node_name : 경로는 usercallout 프로그램에 의해 정의되거나 
대상 노드 이름에 따라 일련 번호 또는 우선 순위에 따라 그룹화됩니다.
• Prio_callout : 경로 우선 순위 값을 얻기 위해 호출 할 기본 프로그램 및 인수.
• path_checker : 경로의 상태를 결정하는 데 사용되는 방법입니다.
• user_friendly_names : 다중 경로 장치에 할당 된 이름은 multipaths 섹션에 정의되지 않은 경우 mpath <n> 형식입니다.
• no_path_retry : 대기열이 비활성화 될 때까지 재시도 횟수를 지정하거나 즉각적인 실패(이 경우 대기열 없음)를 위해 실패 I/O를 실행하는 데 사용됩니다.
기본값은 0입니다.

다음은 RAC 클러스터 구성에 사용되는 구성 파일의 예입니다.

blacklist {
devnode "^asm/*"
devnode "ofsctl"
wwid SATA_SEAGATE_ST950009SP19KZT_
wwid SATA_SEAGATE_ST950009SP122XT_
... 이하 생략 ...

첫 번째 절에서는 asm 및 ofsctl (ACFS) 장치를 블랙리스트에 표시합니다.
또한 특정 WWIO를 사용하여 두 디스크를 블랙리스트에 추가합니다. 샘플 설정의 맥락에서 OS 디스크가 이에 해당합니다.
defaults 섹션은 이 설정에서 적용 할 수있는 일반 매개 변수를 제공합니다.
마지막으로 multipaths 섹션에는 장치에 할당 할 WWIO와 해당 별칭이 나열됩니다.
mode, uid 및 gid는 작성 후 작성된 디바이스 권한, 사용자 ID 및 그룹 ID를 각각 제공합니다.

구성 설정
multipath.conf 파일을 구성한 후 다중 경로 장치 매핑을 만들려면 /sbin/ multipath 명령을 사용하십시오.

# /sbin/multipath -v2

# ls -l /dev/mapper
brw-rw---- 1 grid asmadmin 253 , 8 Oct 29 03:19 HDD 868469527
brw-rw---- 1 grid asmadmin 253 , 8 Oct 29 03:19 HDD 966617575
# kpartx -a /dev/mapper/HDD 868469527
# kpartx -a /dev/mapper/HDD 966617575

이 예에서 장애 조치 구성에 두 개의 다중 경로 장치가 생성됩니다.
우선 순위 그룹은 활성 경로입니다.
장치 /dev/sdau는 HDD__966617575의 활성 경로이고 /dev/sdk는 수동(대기)경로입니다.
경로는 /dev/mapper 폴더에 표시됩니다.
또한 kpartx 도구를 사용하여 장치에 대한 파티션 매핑을 장치에 만들 수 있습니다.
이러한 설정이 완료되면 ASM 또는 서버의 다른 응용 프로그램에서 장치를 사용할 수 있습니다.

디스크 그룹
ASM의 기본 구성 요소는 ASM에서 최상위 수준의 데이터 구조인 디스크 그룹입니다 (그림 4-3 참조).
디스크 그룹은 본질적으로 하나의 단위로 함께 관리되는 디스크의 논리적 그룹으로 구성된 컨테이너입니다.
디스크 그룹은 논리 볼륨 관리자 (LVM) 볼륨 그룹과 비슷합니다.

디스크 그룹은 여러 Oracle 데이터베이스의 파일을 포함 할 수 있습니다.
여러 데이터베이스가 디스크 그룹을 공유하도록 허용하면 디스크 사용률이 향상되고 전체 처리량이 향상됩니다.
Oracle 데이터베이스는 동일한 ASM 인스턴스가 관리하는 여러 디스크 그룹에 파일을 저장할 수도 있습니다.
데이터베이스 파일은 하나의 디스크 그룹에만 포함될 수 있습니다.
ASM 디스크 그룹은 ASM 디스크 그룹에 고유한 자동 파일 레벨 스트라이핑 및 미러링 기능이 있다는 점에서 일반적인 LVM 볼륨 그룹과 다릅니다.
ASM 디스크 그룹내에서 생성된 데이터베이스 파일은 디스크 그룹의 모든 디스크에 동일하게 분산되어 입출력(I/O)로드가 균등합니다.

디스크 그룹 관리
ASM에는 외부,노멀,high 리던던시(Redundancy)의 세 가지 디스크 그룹 유형이 있습니다.
디스크 그룹 생성시 정의되는 디스크 그룹 유형은 ASM에 의해 수행되는 미러링의 기본 레벨을 결정합니다.
외부 중복 디스크 그룹은 ASM에서 스트리핑을 수행하고 미러링이 스토리지 배열에 의해 처리 및 관리됨을 나타냅니다.
예를 들어, 사용자가 스토리지 배열 (SAN)이 EMC VMAX 또는 Hitachi USP 시리즈인 외부 중복 디스크 그룹을 생성 할 수 있습니다.
이러한 하이 엔드 어레이의 핵심 역량이 미러링되므로 외부 리던던시가 적합합니다. 일반적인 질문은 ASM이 SAN에서 수행하는 스트리핑과 충돌하는지 여부입니다.
대답은 '아니오'입니다. ASM 스트리핑은 SAN 스트리핑을 보완합니다. ASM 이중화를 사용하면 ASM이 미러링을 수행하고 관리합니다.
ASM 중복성은 Oracle Exadata, Oracle SuperCluster 및 Oracle Database Appliance와 같은 Oracle 엔지니어링 솔루션에 사용되는 핵심 배포 전략입니다.
ASM 이중화는 저가의 상용 스토리지 또는 스트레치 클러스터를 배치 할 때도 사용됩니다.
ASM 중복에 대한 자세한 내용은 이 장 뒷부분의 "ASM 중복 및 장애 그룹"절을 참조하십시오.
다음 절에서는 외부 중복 환경에서 디스크 그룹을 만드는 방법을 중점적으로 설명합니다.

디스크 그룹 만들기
디스크 그룹 생성에는 추가 할 디스크의 유효성 검사가 포함됩니다.
디스크에는 다음 속성이 있어야합니다.
• 다른 디스크 그룹에서 이미 사용할 수 없습니다.
• 기존의 유효한 ASM 헤더가 없어야합니다.
이것을 무시하려면 FORCE 옵션을 사용해야합니다.
• Oracle 파일 헤더 (예 : RDBMS에서 작성한 파일)를 가질 수 없습니다.
이것을 무시하려면 FORCE 옵션을 사용해야합니다.
원시 장치 데이터 파일을 사용하여 ASM 디스크를 만들려고하면 다음 오류가 발생합니다.

[SQL] 
CREATE DISKGROUP DATA DISK '/dev/sdd',
create diskgroup data disk '/dev/sdd3'

ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15201: disk /dev/sda3 contains a valid RDBMS file

디스크 헤더 유효성 검증은 ASM이 이미 사용중인 데이터 디바이스를 파괴하는 것을 방지합니다.
CANDIDATE, FORMER 또는 PROVISIONED의 헤더 상태를 가진 디스크만 디스크 그룹 작성에 포함될 수 있습니다.
헤더 상태가 MEMBER 또는 FOREIGN인 디스크 그룹에 디스크를 추가하려면 디스크 그룹 작성에서 FORCE 옵션을 사용하십시오.
FORCE 옵션의 무상 사용을 방지하기 위해 ASM은 NOFORCE 옵션 사용이 실패 할 때만 허용합니다.
ORA-15034 오류(디스크 '%S'에는 FORCE 옵션이 필요 없음)가 필요하지 않을 때 FORCE를 사용하려고 시도합니다.
이전에 ASM 디스크 또는 데이터베이스 파일로 사용 된 디스크의 데이터를 겹쳐 쓰므로 매우 주의하여 FORCE 옵션을 사용하십시오.
인식 할 수 있는 헤더가 없는 디스크는 후보로 간주됩니다. "후보자"라는 영구 헤더 상태는 없습니다.
ASM이 디스크를 발견하면 디스크 그룹을 생성하는 데 사용할 수 있습니다.
ASM과 디스크 그룹 관리의 복잡성을 줄이기 위해 일반적으로 RAC 클러스터 또는 단일 ASM 인스턴스별로 두 개 이상의 디스크 그룹을 유지 관리하지 않는 것이 좋습니다.
다음은 고객이 생성한 일반적인 디스크 그룹입니다.
• DATA 디스크 그룹 여기에는 데이터 파일, 제어 파일, 온라인 리두 로그 및 증분 백업에 사용되는 변경 추적 파일과 같은 활성 데이터베이스 파일이 저장됩니다.
• FRA (Fast Recovery Area) 디스크 그룹 현재 제어 파일 및 온라인 리두 로그, 아카이브 된 리두 로그, 백업 세트 및 플래시백 로그 파일의 
다중 사본과 같은 복구 관련 파일이 생성됩니다.

하나의 DATA 디스크 그룹을 보유한다는 것은 모든 데이터베이스 파일을 저장할 수 있는 장소가 하나 밖에 없으므로 기존 파일 시스템 구성과 같이 데이터 파일을 둘러 보거나 
새로운 테이블 공간을 배치 할 위치를 결정할 필요가 없습니다. 모든 파일에 대해 하나의 디스크 그룹을 보유하면 스토리지 활용도가 높아 지므로 IT 담당자와 스토리지팀이 매우 행복해집니다.
더 많은 저장 영역 용량 또는 I/O 용량이 필요한 경우, ASM 디스크를 추가하고 이 저장 영역 풀 ​​컨테이너에 모든 데이터베이스 오브젝트의 I/O 속도를 수용 할 수 있는 스핀들이 충분한지 확인하십시오.
데이터베이스에 대해 더 높은 가용성을 제공하기 위해 데이터베이스 생성 시 빠른 복구 영역을 선택하면 제어 파일의 활성 복사본과 리두 로그 그룹의 한 구성원 집합이 빠른 복구 영역에 저장됩니다.
제어 파일 또는 추가 로그 파일의 추가 사본을 생성하여 두 디스크 그룹에 배치 할 수 있습니다.
RAC 사용자는 선택적으로 Oracle Clusterware 파일 (예 : 투표 디스크 및 Oracle Cluster Registry) 또는 ASM spfile을 저장 할 CRSDATA 디스크 그룹을 만들 수 있습니다.
이 목적으로 CRSDATA 디스크 그룹을 배포 할 때 최소한 세 가지 장애 그룹과 함께 ASM 정상 중복성을 사용해야합니다.
이는 일반적으로 Clusterware 파일에 중복성을 추가하기 위해 수행됩니다. 자세한 내용은 2장을 참조하십시오.

데이터베이스 데이터를 저장하기위한 디스크 그룹을 추가한다고해서 반드시 성능이 향상되는 것은 아닙니다.
그러나 ILM (Information Lifecycle Management) 또는 HSM (Hierarchical Storage Management) 배포에서 
계층형 스토리지 클래스를 지원하기 위해 추가 디스크 그룹을 추가 할 수 있습니다.
예를 들어, 아카이브 또는 폐기된 데이터(또는 파티션)에 대해 별도의 디스크 그룹을 생성 할 수 있으며, 
Tier1 스토리지 (RAID1)는 Tier2 스토리지 (RAID5)를 기반으로 디스크 그룹에 마이그레이션하거나 처음 배치 할 수 있습니다. 
DATA 디스크 그룹에 사용됩니다. ASM은 중복성 및 최적의 성능을 즉시 사용할 수 있는 기능을 제공합니다.
그러나 성능 및 가용성을 높이려면 다음 항목을 고려해야합니다.
• 둘 이상의 HBA 또는 초기화 장치를 사용하여 스토리지 배열에 대한 다중 액세스 경로 구현
• I/O 로드 균형 조정 및 장애 조치 기능을 제공하기 위해 이러한 여러 HBA에 다중 경로 소프트웨어를 배포합니다.
• 비슷한 크기의 디스크를 사용하는 디스크 그룹을 사용하십시오.
많은 수의 디스크를 포함하는 디스크 그룹은 광범위한 데이터 범위를 제공하므로 I/O에 대한 동시성과 핫스팟 발생을 줄입니다.
대용량 디스크 그룹은 다양한 I/O 특성 및 작업 부하를 쉽게 유지할 수 있으므로 단일 DATA 디스크 그룹을 사용하여 데이터베이스 파일, 로그 파일 및 제어 파일을 저장할 수 있습니다.
• 디스크가 4개 이상인 디스크 그룹을 사용하여 이들 디스크가 여러 백엔드 디스크 어댑터에 걸쳐 있는지 확인하십시오.
앞에서 설명한 것처럼 일반적으로 Oracle은 2 ~ 3개의 디스크 그룹을 권장하지 않습니다.
예를 들어, 일반적인 배치는 모든 백엔드 디스크 어댑터/디렉터에 걸친 DATA 디스크 그룹에 4개 이상의 디스크가 될 수 있고 FRA 디스크 그룹에 8-10 개의 디스크가 될 수 있습니다.
FRA의 크기는 저장된 내용과 얼마나 많은 양 (즉, 전체 데이터베이스 백업, 증분 백업, 플래시백 데이터베이스 로그 및 보관 로그)에 따라 다릅니다.
제어 파일의 활성 사본과 각 재실행 로그 그룹의 한 구성원은 FRA에 저장됩니다.
디스크 그룹은 SQL, EM (Enterprise Manager), ASMCMD 명령 또는 ASMCA를 사용하여 작성할 수 있습니다.
다음 예에서 스토리지 배열에 있는 4개의 디스크를 사용하여 DATA 디스크 그룹을 만들고 스토리지 배열에 의해 외부에서 중복성을 처리합니다.
다음 쿼리는 디스크 그룹에서 사용할 수있는 디스크를 나열합니다.

[SQL] 
SELECT NAME, PATH, HEADER_STATUS, STATE FROM V$ASM DISK;

c3t19d19s4 디스크 중 하나가 디스크 그룹에서 삭제되어 FORMER 상태를 나타냅니다.

[SQL] 
CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK
'/dev/rdsk/c3t19d15s4',
'/dev/rdsk/c3t19d16s4',
'/dev/rdsk/c3t19d17s4',
'/dev/rdsk/c3t19d18s4';

V$ASM_DISGROUP의 출력은 새로 생성된 디스크 그룹을 보여줍니다.
SQL> SELECT NAME, STATE, TYPE, TOTAL MB, FREE MB FROM V$ASM_DISKGROUP;

V$ASM_DISK의 출력은 디스크 그룹이 생성되면 상태 디스크를 보여줍니다.

SQL> SELECT NAME, PATH, HEADER STATUS, STATE FROM V$ASM DISK;

디스크 그룹이 성공적으로 작성되면 작성 날짜, 디스크 그룹 이름 및 중복 유형을 포함하는 메타 데이터 정보가 
디스크 그룹 내의 SGA (System Global Area) 및 각 디스크 (디스크 헤더에 있음)에 저장됩니다.
클러스터의 특정 노드에만 디스크 그룹을 마운트 할 수는 있지만 일반적으로 CRS 리소스 시작 모델링을 방해 할 수 있으므로 권장되지 않습니다.

이 디스크가 ASM 관리하에 있게되면 디스크 그룹의 모든 후속 마운트가 ASM 디스크 헤더를 다시 읽고 유효성을 검사합니다.
다음 출력은 디스크가 디스크 그룹에 통합된 후 V$ASM_DISK 뷰가 디스크 상태 변경을 반영하는 방법을 보여줍니다.

SQL> SELECT NAME, PATH, MODE_STATUS, STATE, DISK_NUMBER FROM V$ASM_DISK;

다음 출력은 디스크 그룹 생성과 디스크 이름 할당을 반영하는 ASM 경고 로그의 항목을 보여줍니다.
SQL> CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK
'/dev/rdsk/c3t19d15s4',
'/dev/rdsk/c3t19d16s4',
'/dev/rdsk/c3t19d17s4',
'/dev/rdsk/c3t19d18s4';

ASM 시작시 또는 후속 마운트시 디스크 그룹을 마운트 할 때 필요한 모든 디스크 그룹을 한 번에 마운트하는 것이 좋습니다.
이렇게하면 여러 ASM 디스크 검색 스캔의 오버 헤드를 최소화 할 수 있습니다.
Grid Infrastructure를 통해 에이전트는 데이터베이스에 필요한 디스크 그룹을 자동으로 마운트합니다.

ASM Disk Names
ASM 디스크 이름은 기본적으로 디스크 그룹 이름과 디스크 번호에 따라 할당되지만 이름은 ASM 디스크 그룹을 만들거나 디스크를 추가 할 때 사용자가 정의 할 수 있습니다.
다음 예에서는 사용자가 디스크 이름을 정의한 디스크 그룹을 만드는 방법을 보여줍니다.

SQL> CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK
'/dev/rdsk/c3t19d15s4' name VMAX diskl,
'/dev/rdsk/c3t19d16s4' name VMAX disk2,
'/dev/rdsk/c3t19d17s4' name VMAX disk3,
'/dev/rdsk/c3t19d18s4' name VMAX disk4;

디스크 이름이 제공되지 않으면 ASM은 디스크 그룹에 추가 된 각 디스크에 일련 번호가있는 디스크 이름을 동적으로 할당합니다.

SQL> CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK
’/dev/rdsk/c3t19d15s4’,
’/dev/rdsk/c3t19d16s4’,
’/dev/rdsk/c3t19d17s4’,
’/dev/rdsk/c3t19d18s4’;

ASM 디스크 이름은 DROP, ONLINE, OFFLINE 및 RESIZE DISK와 같은 디스크 관리 활동을 수행 할 때 사용됩니다.
ASM 디스크 이름은 SCSI (Small Computer System Interface) 주소와 다릅니다.
ASM 디스크 이름은 ASM 헤더에 지속적으로 저장되며 SCSI 주소 이름이 변경 되더라도 유지됩니다.
영구적 이름은 또한 RAC (Real Application Clusters) 노드에서 일관된 이름 지정을 허용합니다.
SCSI 주소 이름 변경은 어레이 재구성 및 재부팅 후에 발생합니다.
ASM이 스토리지에 액세스하는 데 사용하는 경로 이름에 디스크 번호가 영구적으로 바인딩되지 않습니다.

Disk Group Numbers
0이 아닌 가장 작은 사용 가능한 디스크 그룹 번호는 클러스터의 디스크 그룹의 첫 번째 마운트에 할당됩니다.
그러나 ASM 클러스터에서 디스크 그룹이 클러스터 노드간에 다른 순서로 마운트 된 경우에도 (지정된 디스크 그룹에 대해) 디스크 그룹 번호는 
클러스터 전체에서 일관되게 유지되지만 디스크 그룹 이름은 절대로 변경되지 않습니다.
예를 들어 노드 1에 그룹 번호 1의 dgA가 있고 그룹 번호 2의 dgB가있는 경우 노드 2가 dgB 만 마운트하면 노드 2에서 1이 사용되지 않더라도 그룹 번호 2가됩니다.

NOTE
디스크 그룹 번호는 영구적으로 기록되지 않으므로 디스크 헤더에 디스크 그룹 번호가 없습니다.
디스크 그룹 이름만 디스크 헤더에 기록됩니다.

Disk Numbers
디스크 그룹 번호는 영구적으로 기록되지 않지만 디스크 번호는 디스크 헤더에 기록됩니다.
ASM 인스턴스가 시작되면 초기화 매개 변수 ASM_DISKSTRING에 지정된 패턴과 일치하고 읽기/쓰기 액세스 권한이있는 모든 장치가 검색됩니다.
ASM 디스크 헤더가 있으면 ASM 디스크 번호를 알고 있습니다.
또한 발견되었지만 마운트 된 디스크 그룹의 일부가 아닌 디스크는 디스크 그룹 0에보고됩니다.
마운트 된 디스크 그룹의 일부가 아닌 디스크는 디스크 그룹에 추가되거나 마운트 될 때까지 디스크 그룹 0에있게됩니다.
디스크가 디스크 그룹에 추가되면 올바른 디스크 그룹과 연관됩니다.

ASM Redundancy and Failure Groups
외부 중복을 사용하지 않는 시스템의 경우 ASM은 자체 중복 메커니즘을 제공합니다.
앞에서 설명한 것처럼 중복성은 Exadata 및 Oracle Database Appliance 시스템에서 광범위하게 사용됩니다.
이 공학 솔루션은 12 장에서 다룹니다.
디스크 그룹은 장애 그룹으로 나뉘며 각 디스크는 정확히 하나의 장애 그룹에 있습니다.
장애 그룹(FG)은 연관된 구성 요소 중 하나의 장애로 인해 사용할 수 없게 된 디스크 모음입니다.
가능한 장애 구성 요소는 다음 중 하나 일 수 있습니다.
• Storage array controllers
• Host bus adapters (HBAs)
• Fibre Channel (FC) switches
• Disks
• Entire arrays, such as NFS filers
따라서 두 개의 개별 장애 그룹(지정된 디스크 그룹)의 디스크는 공통적인 장애 구성 요소를 공유하지 않아야 합니다.
디스크 그룹에 장애 그룹을 정의하면 ASM은 하나 이상의 장애 그룹에 있는 여러 디스크 또는 고 중복 디스크 그룹에 있는 2개의 FG를 동시에 장애가 발생할 수 있습니다.
ASM은 고유 한 미러링 알고리즘을 사용합니다. ASM은 디스크를 미러링하지 않습니다. 오히려 범위를 반영합니다.
ASM이 장애 그룹의 한 디스크에 파일의 기본 확장 영역을 할당하면 해당 확장 영역의 미러 사본을 다른 실패 그룹의 다른 디스크에 할당합니다.
따라서 ASM은 기본 확장 영역과 해당 미러 사본이 절대로 동일한 실패 그룹에 상주하지 않도록합니다.
각 파일은 동일한 디스크 그룹에서 서로 다른 수준의 미러링(중복성)을 가질 수 있습니다.
예를 들어, 정상적인 중복 디스크 그룹에서 적어도 세 개의 장애 그룹이있는 경우(기본)일반 중복성, 
중복성 없는 다른 파일 및 중복성이 높은 또 다른 파일(3중 미러링)을 가질 수 있습니다.
다른 볼륨 관리자와 달리 ASM에는 1차 디스크 또는 미러된 디스크의 개념이 없습니다.
결과적으로 장애 발생 시 지속적인 보호를 제공하려면 디스크 그룹에 여유 용량만 있으면 됩니다. 핫 스페어 디스크가 필요하지 않습니다.

디스크 그룹의 중복성은 파일이 양방향으로 미러링 된 경우 (최소 두 개의 장애 그룹 필요) 또는 
높음으로 3 가지 미러링을 사용하여 높은 수준의 보호를 제공 할 수 있습니다(기본값은 3 개 이상 필요) 여러 떼).
디스크 그룹을 만든 후에는 중복성 수준을 변경할 수 없습니다. 다른 리던던시를 원하면 원하는 리던던시가 있는 
다른 디스크 그룹을 생성 한 다음 데이터 파일을 Recovery Manager [RMAN] 복원, 
ASMCMD 복사 명령 또는 DBMS_FILE_TRANSFER를 사용하여 원래 디스크 그룹에서 새로 생성된 디스크 그룹으로 이동해야합니다.

NOTE
디스크 그룹 메타 데이터는 정상 또는 높은 중복성으로 항상 3중 미러링됩니다.
또한 장애 그룹에 디스크를 할당 한 후에는 다른 장애 그룹에 디스크를 재할당 할 수 없습니다.
다른 실패 그룹으로 이동하려면 먼저 현재 장애 그룹에서 삭제 한 다음 원하는 장애 그룹에 추가해야합니다.
그러나 하드웨어 구성에 따라 일반적으로 장애 그룹의 선택이 결정되므로 사용자는 일반적으로 물리적으로 이동하지 않는 한 
다른 장애 그룹에 디스크를 재할당할 필요가 없습니다.

Creating ASM Redundancy Disk Groups
다음의 간단한 예에서는 NetApp 파일러를 통해 두 개의 장애 그룹을 사용하여 일반 중복 디스크 그룹을 생성하는 방법을 보여줍니다.

[SQL]
CREATE DISKGROUP DATA_NRML NORMAL REDUNDANCY
FAILGROUP FLGRP1 DISK 
'/dev/rdsk/c3t19d3s4', 
'/dev/rdsk/c3t19d4s4',
'/dev/rdsk/c3t19d5s4', 
'/dev/rdsk/c3t19d6s4', 
'/dev/rdsk/c4t20d3s4',
'/dev/rdsk/c4t20d4s4', 
'/dev/rdsk/c4t20d5s4', 
'/dev/rdsk/c4t20d6s4'
FAILGROUP FLGRP2 DISK 
'/dev/rdsk/c5t21d3s4', 
'/dev/rdsk/c5t21d4s4',
'/dev/rdsk/c5t21d5s4', 
'/dev/rdsk/c5t21d6s4', 
'/dev/rdsk/c6t22d3s4',
'/dev/rdsk/c6t22d4s4',
'/dev/rdsk/c6t22d5s4', 
'/dev/rdsk/c6t22d6s4';

와일드 카드 구문을 사용하여 동일한 create diskgroup 명령을 실행할 수 있습니다.
[SQL] 
CREATE DISKGROUP DATA_NRML NORMAL REDUNDANCY
FAILGROUP FLGRP1 DISK '/dev/rdsk/c[34]*’
FAILGROUP FLGRP2 DISK '/dev/rdsk/c[56]*’;

이 예에서 ASM 정상적인 중복성은 저가의 상용 스토리지 배열을 통해 배치됩니다.
이 스토리지 배열에는 4 개의 내부 트레이가 있으며 각 트레이에는 4 개의 디스크가 있습니다.
격리 할 수 없는 구성 요소가 저장 장치 트레이이므로 장애 그룹 경계가 저장 장치 트레이에 대해 설정됩니다. 
즉, 각 저장 장치 트레이는 장애 그룹과 연관됩니다.

[SQL] 
CREATE DISKGROUP DATA NRML NORMAL REDUNDANCY
FAILGROUP FLGRP1 DISK 
'/dev/rdsk/c3t19d3s4', '/dev/rdsk/c3t19d4s4',
'/dev/rdsk/c3t19d5s4', '/dev/rdsk/c3t19d6s4'
FAILGROUP FLGRP2 DISK 
'/dev/rdsk/c4t20d3s4', '/dev/rdsk/c4t20d4s4',
'/dev/rdsk/c4t20d5s4' ,'/dev/rdsk/c4t20d6s4'
FAILGROUP FLGRP3 DISK 
'/dev/rdsk/c5t21d3s4', '/dev/rdsk/c5t21d4s4',
'/dev/rdsk/c5t21d5s4', '/dev/rdsk/c5t21d6s4'
FAILGROUP FLGRP4 DISK 
'/dev/rdsk/c6t22d3s4', '/dev/rdsk/c6t22d4s4',
'/dev/rdsk/c6t22d5s4', '/dev/rdsk/c6t22d6s4';

ASM and Intelligent Data Placement
짧은 스트로 킹 (RAID 0 스트라이핑과 함께)은 스토리지 관리자가 헤드 재배치 지연의 성능 영향을 최소화하기 위해 일반적으로 사용하는 기술입니다.
이 기술은 액추에이터의 동작 범위를 제한하여 탐색 시간을 줄이고 미디어 전송 속도를 높입니다.
이렇게하면 전반적인 디스크 처리량이 효과적으로 향상됩니다.
짧은 스트로 킹은 디스크 플래터의 외부 섹터 (가장 높은 트랙 밀도가있는) 만 액세스가 심한 데이터를 저장하는데 사용되도록 
드라이브를 포맷함으로써 구현되므로 전체 처리량이 가장 좋습니다. 그러나 디스크를 짧게 쓰다듬는 것은 사용 가능한 트랙의 
하위 집합을 사용하여 드라이브 용량을 제한하므로 사용 가능한 용량이 줄어 듭니다.
Oracle Database 버전 11 Release 2에서 소개 된 지능형 데이터 배치(IDP)는 
사용 가능한 용량이나 중복성을 희생시키지 않으면서 짧은 획기적인 기술을 에뮬레이트합니다.
IDP는 최적의 성능을 위해 ASM 디스크의 디스크 영역 경계를 자동으로 정의합니다.
디스크 그룹의 디스크 영역 설정을 사용하여 자주 액세스하는 데이터를 가장 바깥쪽(핫)트랙에 배치 할 수 있습니다.
또한 유사한 액세스 패턴을 가진 파일은 물리적으로 가까이에 위치하므로 대기 시간이 줄어 듭니다.
또한 IDP를 사용하면 주 또는 미러 영역을 서로 다른 핫 또는 콜드 영역에 배치 할 수 있습니다.
IDP 기능은 어레이에 의해 파티션되지 않은(예:RAID 기술 사용) JBOD(디스크 묶음)스토리지 
또는 디스크 스토리지에서 주로 작동합니다. IDP는 외부 중복성과 함께 사용할 수 있지만 
다른 파일에 거의 액세스하지 않는 동안 특정 번호의 파일에 자주 액세스하고 
낮은 번호의 블록이 높은 번호의 블록보다 더 잘 수행하는 경우에만 효과적입니다. 
외부 중복에 대한 IDP는 그리 유용하지 않을 수 있습니다.
더욱이 외부 중복에 대한 IDP는 오라클 내부 연구소에서 테스트 한 구성이 아닙니다.
IDP의 기본 영역은 COLD이므로 모든 데이터는 물리 디스크의 바깥쪽 가장자리에 있는 가장 낮은 디스크 주소에 할당됩니다.
디스크 영역 설정이 기존 파일에 대해 수정되면 새 파일 확장명만 영향을 받습니다.
기존 파일 범위는 재조정 작업이 시작될 때까지 영향을받지 않습니다.
상당한 수의 IDP 파일 정책 (기존 파일 용)이 수정 될 때 수동으로 ASM 재조정을 시작하는 것이 좋습니다.
재조정은 시스템 처리량에 영향을 줄 수 있으므로 계획된 변경 관리 작업이어야 합니다.
IDP 설정은 파일 또는 디스크 그룹 템플릿을 사용하여 지정할 수 있습니다.
디스크 그룹을 만든 후에 디스크 영역 설정을 수정할 수 있습니다.
IDP는 다음 작업 부하 및 액세스 패턴에 대해 가장 효과적입니다.
• 다른 속도로 액세스되는 데이터 파일이있는 데이터베이스의 경우.
동일한 방식으로 모든 데이터 파일에 액세스하는 데이터베이스는 IDP의 이점을 얻지 못할 것입니다.
• 사용 가능한 데이터로 충분히 채워진 ASM 디스크 그룹의 경우.
최선의 권장 사항으로 디스크 그룹은 25% 이상 가득 차 있어야합니다.
채워진 디스크 그룹이 적 으면 IDP 관리 오버 헤드가 IDP 이점을 최소화 할 수 있습니다.
• 미디어의 시작 부분과 끝 부분의 성능이 좋은 디스크의 경우.
지능형 데이터 배치는 디스크의 형상을 활용하기 때문에 JBOD (디스크 묶음)에 적합합니다.
반대로, 연결된 볼륨으로 구성된 LUN이있는 스토리지 배열은 ASM의 형상을 마스크합니다.
IDP를 구현하려면 COMPATIBLE.ASM 및 COMPATIBLE.RDBMS 디스크 그룹 속성을 11.2 이상으로 설정해야합니다.
IDP는 ASMCA 또는 다음 SQL 명령을 사용하여 구현 및 관리 할 수 ​​있습니다.
ALTER DISKGROUP은 TEMPLATE를 추가하거나 수정합니다.
• ALTER DISKGROUP은 SQL 또는 MODIFY FILE을 템플리트합니다.
이 명령에는 템플릿에서 핫/미러 샷 또는 콜드/미러 코어 영역을 설정하기위한 디스크 영역 절이 포함됩니다.

ALTER DISKGROUP data ADD TEMPLATE userdata_hot
ATTRIBUTE (
HOT
MIRRORHOT);

ALTER DISKGROUP data MODIFY FILE '+data/yoda/datafile/users.271.689156907'
ATTRIBUTE (
HOT
MIRRORHOT);

IDP는 ADVM 볼륨에도 적용됩니다. ADVM 볼륨을 작성할 때 기본 및 보조 익스텐트의 지역 위치를 지정할 수 있습니다.

# volcreate -G DATA -s lOG --primary hot --secondary cold ACFS_OH

Designing for ASM Redundancy Disk Groups
ASM 이중화를 사용하면 정상적인 이중화를 위한 두 개의 오류 그룹과 높은 이중화를 위한 세 개의 오류 그룹만 가질 수 있습니다.
앞의 예에서 디스크 파트너가 동일한 저장소 트레이에서 할당되지 않도록하기 위해 네 개의 실패 그룹이 만들어집니다.
Exadata에서 또 다른 예를 찾을 수 있습니다. 전체 프레임 Exadata에는 14 개의 실패 그룹이 있습니다.
사용자가 SAN (Storage Area Network) 배열 오류로부터 보호하기를 원할 수도 있습니다.
이는 각 어레이를 별도의 장애 그룹에 배치함으로써 수행 할 수 있습니다.
예를 들어 구성에는 두 개의 NetApp Filer와 ASM 정상 중복성의 배포가 포함될 수 있습니다. 
따라서 각 파일러, 즉 모든 논리 단위 파일러를 통해 표시된 LUN (숫자)은 ASM 실패 그룹의 일부입니다.
이 시나리오에서 ASM은 두 파일러 간의 범위를 반영합니다.
데이터베이스 관리자 (DBA)가 CREATE DISKGROUP 명령에 실패 그룹을 지정하지 않으면 실패 그룹이 각 디스크에 대해 자동으로 구성됩니다.
모든 디스크를 자체 실패 그룹에 배치하는 이 방법은 대부분의 고객에게 적합합니다. 
실제로 Oracle Database Appliance에서는 모든 디스크가 이러한 방식으로 할당됩니다.
Exadata의 경우 스토리지 그리드 디스크에 데이터베이스 서버 노드에 대한 추가 정보가 제공되므로 
이러한 서버는 사용자 개입없이 장애 그룹을 구성하는 방법을 정확하게 알고 있습니다.
실패 그룹의 선택은 데이터 가용성의 손실없이 허용되어야하는 실패의 종류에 따라 다릅니다.
적은 수의 디스크 (예 : 20 개 미만)의 경우 일반적으로 모든 디스크를 자체 장애 그룹에 넣는 것이 가장 좋습니다.
그럼에도 불구하고 스핀들 장애가 주요 문제일 때 많은 수의 디스크에 유용합니다.
단일 구성 요소 오류로 인해 여러 디스크 드라이브가 동시에 손실되지 않도록 보호하려면 명시 적 오류 그룹 지정을 사용해야합니다.
예를 들어 디스크 그룹은 여러 소형 모듈러 디스크 어레이로 구성 될 수 있습니다.
전체 모듈러 어레이에 장애가 발생해도 시스템을 계속 작동해야하는 경우 각 장애 그룹은 하나의 모듈에있는 모든 디스크로 구성되어야합니다.
한 모듈에 장애가 발생하면 해당 모듈의 모든 데이터가 중복성을 복원하기 위해 다른 모듈로 재배치됩니다.
디스크를 사용할 수 없거나 오류가 용인되어야하는 공통 하드웨어에 의존하는 경우 디스크를 동일한 실패 그룹에 배치해야합니다.
데이터가 필요한 구성 요소 오류로 다시 보호되는 한 몇 개의 오류 그룹을 갖는 것이 훨씬 낫습니다.
추가 장애 그룹을 보유하면 여러 장애를 견딜 확률이 높아집니다.
불균등한 용량의 실패 그룹은 사용 가능한 모든 스토리지의 완전한 활용을 방해하는 할당 문제를 야기 할 수 있습니다.
또한 서로 다른 크기의 장애 그룹이 있으면 디스크 공간을 낭비 할 수 있습니다.
기본 확장 영역을 할당 할 수있는 충분한 공간이있을 수 있지만 보조 확장 영역에 사용할 수있는 공간은 없습니다.
예를 들어 6개의 디스크와 3 개의 장애 그룹이 있는 디스크 그룹에서 두 개의 디스크가 각각의 개별 장애 그룹에 있고 
다른 4개의 장애 그룹이 하나의 공통 장애 그룹에 속해 있으면 할당이 매우 다릅니다.
큰 실패 그룹의 모든 2차 범위는 6개의 디스크 중 2 개에만 위치 할 수 있습니다.
큰 실패 그룹에 충분한 공간이 있어도 개별 실패 그룹의 디스크는 2차 범위로 채워지고 추가 할당을 차단합니다.
또한 쓰기에 대해서만 액세스 할 수있는 보조 확장 영역이 많이 포함되어 있거나 기본 확장 영역이있는 디스크가 실패한 경우 
가득 찬 두 디스크에 읽기 및 쓰기로드가 고르지 않게 배치됩니다.

Allocating ASM Extent Sets
ASM 중복성을 사용하면 할당된 첫 번째 파일 확장 영역이 1차 확장 영역으로 선택되고 미러된 확장 영역을 2차 확장 영역이라고합니다.
높은 중복성의 경우 두 개의 2차 범위가 있습니다. 1차 및 2차 범위의 논리적 그룹화를 범위 세트라고합니다.
디스크 그룹의 각 디스크에는 거의 동일한 수의 1차 및 2차 범위가 있습니다.
이렇게하면 모든 디스크에서 읽기 I/O 작업을 균일하게 분산시킬 수 있습니다.
Extent 세트의 모든 Extent는 서로 미러링 된 버전이므로 항상 동일한 데이터를 포함합니다.
디스크에서 블록을 읽을 때 기본 확장 영역을 읽을 수 없는 경우를 제외하고는 항상 기본 확장 영역에서 블록을 읽습니다.
기본 읽기 기능을 사용하면 데이터베이스가 1차 범위를 읽는 대신 2차 범위를 먼저 읽을 수 있습니다.
이것은 RAC 확장 클러스터 구현에 특히 중요합니다.
이 기능에 대한 자세한 내용은이 장 뒷부분의 "ASM 및 확장 클러스터"절을 참조하십시오.
블록이 파일에 기록 될 때, Extent 세트의 각 Extent는 병렬로 기록됩니다.
이를 위해서는 클라이언트에 쓰기를 승인하기 전에 모든 쓰기가 완료되어야합니다.
그렇지 않으면, 기록되지 않은면은 기록되기 전에 읽을 수 있습니다.
하나의 쓰기 I/O에 장애가 발생하면 쓰기가 승인되기 전에 읽기 측면에서 미러 측면을 사용할 수 없게 만들어야합니다.

Disk Partnering
ASM 중복 디스크 그룹에서 ASM은 기본 데이터 범위가 들어있는 디스크의 파트너인 디스크에서 데이터 사본을 미러링하여 
이중 디스크 오류(데이터 손실로 이어질 수 있음)를 방지합니다.
디스크 파트너쉽은 고 중복 디스크 그룹 또는 정상 중복 디스크 그룹의 두 디스크 사이의 대칭 관계이며 
ASM은 이러한 관계를 자동으로 생성하고 유지 관리합니다.
ASM은 디스크가 속한 장애 그룹 이외의 장애 그룹에서 디스크의 파트너를 선택합니다.
이렇게하면 실패한 그룹과 연관된 공유 리소스가 실패한 후에 손실된 디스크의 데이터 사본이 있는 디스크를 사용할 수 있습니다.
ASM은 단일 디스크의 경우 디스크 파트너 수를 8개로 제한합니다.
ASM은 자체 실패 그룹 (FLGRP1)에서 파트너 디스크를 선택하지 않았습니다. 
오히려, 다른 세 개의 실패 그룹에서 8명의 파트너가 선택되었습니다.
디스크 파트너쉽은 ASM 디스크의 손실 또는 추가가 있을 때만 변경됩니다.
디스크를 오프라인으로 전환하면 이러한 파트너 관계가 수정되지 않습니다.
디스크 파트너쉽은 9장에서 자세히 설명합니다.

Recovering Failure Groups
이제 이전 CREATE DISKGROUP DATA_NRML 명령의 예제로 돌아가 보겠습니다.
재조정을 유발하는 장애 그룹 FLGRP1에서 디스크 장애가 발생하면 장애가 발생한 디스크의 내용(데이터 익스텐트)은 
파트너 디스크의 익스텐트 사본을 사용하여 재구성됩니다. 이 파트너 디스크는 실패 그룹 FLGRP2, FLGRP3 
또는 둘 모두에서 발생합니다. 데이터베이스 인스턴스가 기본 범위가 실패한 디스크에 있었던 익스텐트에 액세스해야하는 경우 
데이터베이스는 해당 디스크에서 미러 복사본을 읽습니다.
재조정이 완료되고 디스크 내용이 완전히 재구성 된 후 데이터베이스 인스턴스는 기본 사본 읽기 전용으로 돌아갑니다.

ASM and Extended Clusters
스트레치 클러스터, 지오 클러스터, 캠퍼스 클러스터 또는 메트로 클러스터라고도하는 확장 클러스터는 기본적으로 두 데이터 센터 위치에 배치 된 RAC 환경입니다.
많은 고객들이 RAC의 이점을 활용하여 재해 복구와 긴밀한 협조를 통해 확장 된 RAC를 구현함으로써 높은 가용성을 제공합니다.
Oracle 내에서 확장 클러스터라는 용어는 모든 스트레치 클러스터 구현을 지칭하기 위해 사용됩니다.
확장 된 RAC의 거리는 수 미터에서 수십 킬로미터 사이가 될 수 있습니다.
CRS (Cluster Ready Services)-RAC 클러스터 그룹 구성원은 상호 연결을 통해 효과적으로 통신 할 수 있는 기능을 기반으로하므로 
확장된 클러스터 배포에는 저 지연 네트워크 인프라가 필요합니다. 근거리에서 광섬유 채널을 사용하는 반면, 먼 거리에서는 다크 파이버가 사용됩니다.
확장 RAC의 일반 중복 디스크 그룹의 경우 확장 클러스터의 각 사이트에 하나의 실패 그룹만 있어야합니다.
높은 중복성 디스크 그룹은 3개의 사이트가 없으면 확장 클러스터 구성에서 사용하지 않아야합니다.
이 시나리오에서는 각 사이트마다 하나의 실패 그룹이 있어야합니다. 사이트 이름을 기반으로 명시적으로 실패 그룹의 이름을 지정해야합니다.

NOTE
디스크 그룹에 비대칭 구성이 포함되어 한 사이트에서 다른 사이트보다 많은 실패 그룹이 있는 경우 
확장 영역은 원격 실패 그룹이 아닌 동일한 사이트로 미러링 될 수 있습니다.
둘 이상의 실패 그룹을 포함하는 사이트가 실패하면 전체 디스크 그룹에 대한 액세스가 손실 될 수 있습니다.

Oracle Clusterware 11g Release 2에서는 쿼럼 실패 그룹이라는 개념이 도입되었습니다.
정규 failgroup이 기본값입니다. 쿼럼 실패 그룹은 ASM 메타 데이터와 함께 단일 CSS 쿼럼 파일을 수용하는 데 사용되는 특수 유형의 장애 그룹입니다.
따라서 이 쿼럼 failgroup은 300MB 크기 여야합니다. 이러한 실패 그룹에는 사용자 데이터가 포함되어 있지 않으므로 
중복 요구 사항을 결정할 때는 쿼럼 실패 그룹을 고려하지 않습니다.
또한 V$ASM_DISKGROUP의 USABLE_FILE_MB는 QUORUM 디스크에있는 여유 공간을 고려하지 않습니다.
그러나 쿼럼 실패 그룹은 디스크 그룹을 마운트 할 때 계산됩니다.
1장은 쿼럼 장애 그룹이있는 디스크 그룹을 만드는 방법에 대해 자세히 설명합니다.

ASM Preferred Read
앞에서 설명한 것처럼 ASM은 항상 미러 된 범위 세트의 기본 사본을 읽습니다.
따라서 특정 블록에 대한 읽기는 상호 연결을 통해 원격 사이트에서 1 차 범위의 읽기를 요구할 수 있습니다.
대도시 영역 또는 광역 스토리지 네트워크를 통해 원격 디스크에 액세스하는 것은 로컬 디스크에 액세스하는 것보다 상당히 느립니다.
이는 인터커넥트에 과세되며 높은 I/O 및 네트워크 대기 시간을 초래할 수 있습니다.
이를 방지하기 위해 기본 읽기 (preferred reads) 기능을 사용하여 ASM 관리자가 로컬 읽기에 대한 실패 그룹을 지정할 수 있습니다. 
즉, 기본 읽기를 제공합니다. 기본 디스크가 있는 확장 세트가있는 보통 또는 높은 중복성이 높은 디스크 그룹에서는 온라인 상태인 경우 
기본 디스크가 읽기를 항상 만족시킵니다. 이 기능은 확장 된 클러스터 구성에 특히 유용합니다.
ASM_REFERRED_READ_FAILURE_GROUPS 초기화 매개 변수는 클러스터의 
각 노드에 대해 로컬 읽기를 제공하는 실패 그룹 이름 목록을 지정하는 데 사용됩니다.
ASM PREFERRED READ FAILURE GROUPS의 형식은 다음과 같습니다.

ASM_PREFERRED_READ_FAILURE_GROUPS = DISKGROUP_NAME.FAILUREGROUP_NAME,...

각 항목은 디스크 그룹의 이름 인 OISKCROUP_NAME과 해당 디스크 그룹 내의 실패 그룹 이름인 
FAILUREGROUP_NAME(이 두 변수를 구분하는 마침표)로 구성됩니다. 구분 기호로 쉼표를 사용하여 여러 항목을 지정할 수 있습니다.
이 매개 변수는 동적으로 변경할 수 있습니다. 기본 설정 읽기 기능은 혼합 저장 장치 구성에서도 유용 할 수 있습니다.
예를 들어 읽기 대부분의 작업 부하에서 SSD 저장소는 하나의 페일 그룹에 만들 수 있으며 
표준 디스크 드라이브는 두 번째 페일 그룹에 포함될 수 있습니다. 이러한 혼합된 구성은 SSD 스토리지가 제한된 공급 장치(어레이 내) 
또는 경제적 인 이유로 유용합니다. ASM_REFERRED_READ_FAILURE_GROUPS 매개 변수를 SSD 실패 그룹으로 설정할 수 있습니다.
쓰기는 두 실패 그룹 모두에서 발생합니다. 확장 클러스터에서 ASM_REFERRED_READ_FAILURE_GROUPS 매개 변수에 대한 설정으로 
지정한 실패 그룹은 인스턴스에 대해 로컬인 디스크만 포함해야합니다.
V$ASM_DISK는 PREFERRED_READ열에 Y가 있는 기본 디스크를 나타냅니다.

다음 예제에서는 기본 읽기 기능을 배포하는 방법과 고유한 이점 중 일부를 보여줍니다.
이 예는 ASM_PREFERRED_READJAILURE_GROUPS 매개 변수가 설정되지 않은 I/O 패턴을 보여 주며 
매개 변수 변경이 I/O에 미치는 영향을 보여줍니다.

1. Create a disk group with two failure groups:
CREATE DISKGROUP MYDATA NORMAL REDUNDANCY
-- these disks are local access from node1/remote from node2
FAILGROUP FG1 DISK '/dev/sda1', '/dev/sdb1', '/dev/sdc1'
-- these disks are local access from node2/remote from node1
FAILGROUP FG2 DISK '/dev/sdf1', '/dev/sdg1', '/dev/sdh1';

2. The I/Os are evenly distributed across all disks-that is, these are nonlocalized I/Os.

3. The following query displays the balanced IO, default for ASM configurations.
[SQL]
SELECT INST ID, FAILGROUP, SUM(READS), SUM(WRITES) 
FROM GV$ASM DISK WHERE FAILGROUP IN ('FG1','FG2') 
GROUP BY INST_ID, FAILGROUP;

NOTE
V$ASM_DISK는 ASM 메타 데이터에 대해 ASM 인스턴스가 수행하는 I/O를 포함합니다.
V$ASM_DISK_IOSTAT는 데이터베이스 단위로 I/O를 추적합니다.
이 보기는 RDBMS 인스턴스가 비 권장 디스크에 대한 입출력을 수행하지 않는지 확인하는데 사용할 수 있습니다.

4. 우선 읽기에 적합한 ASM 매개 변수를 설정하십시오.
이 매개 변수는 동적이기 때문에 디스크 그룹을 마운트 해제하거나 다시 마운트 할 필요가 없습니다.
Nodel (site1)에 대해 다음을 입력하십시오.
Enter this code for Node1(site1):
+ASM1.asm-preferred_read_failure_groups='MYDATA.FG1'

Enter this code for Node2(site2):
+ASM2.asm-preferred_read_failure_groups='MYDATA.FG2'

5. GV$ASM_DISK를 쿼리하여 매개 변수가 적용되었는지 확인하십시오.
모델에서 다음을 관찰하십시오.

[SQL]
SELECT INST_ID, FAILGROUP, NAME, PREFERRED_READ 
FROM GV$ASM_DISK
ORDER BY INST_ID, FAILGROUP;

디스크 MYDATA_0000, MYDATA_0001 및 MYDATA_0004는 FG1 장애 그룹의 일부이며 
디스크 MYDATA_0002, MYDATA_0003 및 MYDATA_0005는 장애 그룹 FG2에 있습니다.

6. 시스템에 부하를 걸고 EM 또는 V$ASM_DISK_IOSTAT를 사용하여 I/O 호출을 확인합니다.
"Reads-Total"열에는 FG1의 디스크와의 친화성이 강합니다. 이것은 FG1이 +ASM1이 실행중인 Node1에 국지적이기 때문입니다.
FG2의 원격 디스크에는 읽기가 거의 없습니다.

7. 인스턴스1이 FG2에 대해 수행하는 읽기 횟수와 인스턴스2가 FG1에 대해 수행하는 읽기 횟수를 확인하십시오.
[SQL]
SELECT INST_ID, FAILGROUP, SUM(READS), SUM(WRITES) 
FROM GV$ASM_DISK 
WHERE FAILGROUP ING('FG1','FG2') 
GROUP BY INST_ID, FAILGROUP;

Recovering from Transient and Permanent Disk Failures
이 절에서는 ASM이 정상 및 고 가용성 디스크 그룹에서 일시적 및 영구적 디스크 오류를 처리하는 방법을 검토합니다.

Recovering from Disk Failures: Fast Disk Resync
ASM Fast Disk Resync 기능은 장애 그룹의 일시적인 디스크 장애로부터 복구하는 시간을 상당히 줄입니다.
이 기능은 장애가 발생한 디스크를 파트너와 연결된 디스크와 재 동기화하여 신속하게 복구 할 수 있습니다.
Fast Disk Resync를 사용하면 복구 시간은 오류 발생 후 작성되었거나 수정 된 익스텐트 수에 비례합니다.
이 기능을 사용하면 실패한 디스크 그룹을 몇 시간에서 몇 분으로 복구하는 데 걸리는 시간을 크게 줄일 수 있습니다.
빠른 디스크 재 동기화 기능을 사용하면 장애가 발생한 디스크를 복구하고 온라인 상태로 되돌릴 수 있습니다.
이 시간 할당은 ASM 디스크 그룹 속성 DISK_REPAIR_TIME에 의해 지정됩니다.
이 속성은 ASM이 디스크를 삭제하기 전에 허용 할 수있는 디스크 정지의 최대 시간을 나타냅니다.
이 시간이 초과되기 전에 디스크가 복구되면 ASM은 사용자가 디스크를 온라인 상태로 만들 때 복구된 디스크를 다시 동기화합니다.
ALTER DISKGROUP DISK ONLINE 명령은 복구 된 디스크를 온라인 상태로 만들고 디스크 재 동기화를 시작하는 데 사용됩니다.
디스크를 오프라인으로 설정해도 파트너 관계가 변경되지는 않습니다. 재 파티셔닝은 만료 기간이 끝나면 디스크를 삭제할 때 발생합니다.
Fast Disk Resync를 사용하려면 ASM 디스크 그룹의 COMPATIBLE.ASM 및 COMPATIBLE.RDBMS 속성을 11.1.0.0 이상으로 설정해야합니다.
다음 예에서 현재 ASM 11gR2 디스크 그룹의 호환성은 11.1.0.0이고 11.2.0.3으로 수정되었습니다.
속성 변경을 확인하기 위해 V$ASM_ATTRIBUTE 뷰가 질의됩니다.

[SQL]
SELECT NAME, COMPATIBILITY, DATABASE_COMPATIBILITY 
FROM V$ASM_DISKGROUP_STAT;

[SQL]
ALTER DISKGROUP DATA SET ATTRIBUTE 'COMPATIBLE.ASM'='11.2.0.3';

[SQL]
ALTER DISKGROUP DATA SET ATTRIBUTE 'COMPATIBLE.RDBMS'='11.2.0.3';

[SQL]
SELECT NAME, VALUE FROM V$ASM ATTRIBUTE;

Oracle Database 버전 11.2.0.3과의 호환성을 올바르게 설정 한 후에 그에 따라 DISK_REPAIR_TIME 속성을 
설정할 수 있습니다. 기본 복구 시간은 12,960 초 또는 3.6 시간입니다.
가장 좋은 방법은 사이트의 운영 분류에 따라 DISK_REPAIR_TIME을 값으로 설정하는 것입니다. 즉, 디스크를 감지하고 
복구하는 평균 시간으로 설정되어야합니다. DISK_REPAIR_TIME의 값을 변경해야하는 경우 다음 명령을 입력 할 수 있습니다.

ALTER DISKGROUP DATA SET ATTRIBUTE 'DISK_REPAIR_TIME'= '4H';

DISK_REPAIR_TIME 매개 변수가 0이 아니고 ASM 디스크에 장애가 발생하면 해당 디스크는 오프라인 상태가 되지만 
삭제되지는 않습니다. 이 중단되어 있는 동안 ASM은 디스크 그룹 메타 데이터에 저장된 비트 맵을 사용하여 수정된 범위를 
추적합니다(재 동기화에 사용되는 알고리즘에 대한 자세한 내용은 9장).
ASM의 GMON 프로세스는 오프라인 디스크에 대해 마운트된 모든 디스크 그룹을 주기적으로 검사합니다(3초 마다).
GMON이 발견하면, 슬레이브 프로세스에게 타이머 값을 증가 시키도록(3초 단위로)메시지를 보내고, 타이머가 만료되면 
오프라인 디스크에 대한 드롭을 시작합니다. 이 타이머 디스플레이는 V$ASM_DISK의 REPAIR_TIMER 열에 표시됩니다.
ALTER DISKGROUP DISK OFFLINE SQL 명령 또는 EM ASM 대상 페이지를 사용하여 ASM 디스크를 예방 차원의 
유지 관리를 위해 수동으로 오프라인 상태로 만들 수도 있습니다.
다음은 SQL * Plus를 사용하여이 시나리오를 설명합니다.

[SQL] 
ALTER DISKGROUP DATA OFFLINE DISK DATA_0000 DROP AFTER 20 m;

[SQL]
SELECT NAME, HEADER_STATUS, MOUNT_STATUS, MODE_STATUS, STATE, REPAIR_TIMER 
FROM V$ASM_DISK 
WHERE GROUP_NUMBER=1;

오프라인 디스크의 MOUNT_STATUS 및 MODE_STATUS가 MISSING 및 OFFLINE 상태로 설정되고 REPAIR_TIMER가 삭제 타이머에서 
감소되기 시작합니다. 디스크가 오프라인 상태입니다.
유지 관리가 완료되면 DISKGROUP DATA ONLINE 명령을 사용하여 디스크를 온라인 상태로 만들 수 있습니다.

[SQL] 
ALTER DISKGROUP DATA ONLINE DISK DATA_0000;
or
ALTER DISKGROUP DATA ONLINE ALL;

이 문장은 최신 오래된 내용을 가지고 새로운 내용을 수 있도록 다시 온라인 모든 오프라인 디스크를 제공합니다.
재 동기화를 구현하는 방법에 대한 자세한 내용은 9장을 참조하십시오.
다음은 ASM 경고 로그에서 발췌한 것입니다. 디스크가 오프라인 상태가되고 온라인 상태가됩니다.

[SQL]
ALTER DISKGROUP DATA OFFLINE DISK DATA_0000;

디스크를 수정 한 후 다음 명령을 사용하여 디스크를 온라인 상태로 만들 수 있습니다.

[SQL]
ALTER DISKGROUP DATA ONLINE DISK DATA_OOOO;

[SQL]
SELECT NAME, HEADER_STATUS, MOUNT_STATUS, MODE_STATUS, STATE, REPAIR_TIMER 
FROM V$ASM_DISK 
WHERE GROUP_NUMBER=1;

[SQL]
ALTER DISKGROUP DATA ONLINE disk DATA_0000;

디스크가 다시 온라인 상태가되면 REPAIR_TIMER가 0으로 재설정되고 MODE_STATUS가 ONLINE으로 설정됩니다.
언뜻보기에 Fast Disk Resync 기능은 여러 논리 볼륨 관리자가 구현하는 DRL(Dirty Region Logging)대신 사용할 수 있습니다.
그러나 Fast Disk Resync와 DRL은 분명히 다릅니다. DRL은 쓰기 작업이 있는 블록을 추적하는 메커니즘입니다.
미러링된 쓰기는 DRL의 비트가 비행 중 쓰기가 있음을 나타내도록 설정되어 있지 않으면 발행 할 수 없습니다.
DRL 자체는 디스크에 있고 미러링되기 때문에 정상적인 미러 쓰기를 실행하기 전에 두 개의 DRL 쓰기가 필요할 수 있습니다.
이는 각 DRL 비트가 하나의 비트가 다중 미러 블록 쓰기를 포함하도록 데이터 블록 범위를 커버함으로써 완화됩니다.
또한 더 이상 쓰여지지 않는 블록에 대해 I/O가 DRL 비트를 지우는데 약간의 오버 헤드가 있습니다.
DRL에서 다른 비트를 설정하는 동안이 비트를 지울 수 있습니다.
호스트가 비행 중에 미러 쓰기를 수행하는 동안 죽으면 미러의 한면이 기록되고 다른면은 기록되지 않을 수 있습니다.
대부분의 응용 프로그램에서는 블록을 여러 번 읽지 않으면 동일한 데이터를 얻을 필요가 있습니다.
한 쪽이 쓰여졌지만 다른 쪽이 쓰여지지 않았다면, 다른 읽기는 다른 데이터를 얻을 수 있습니다.
DRL은 모든 블록이 미러의 양쪽에서 동일하도록 블록의 한쪽에서 다른쪽으로 복사해야하는 블록 집합을 
구성함으로써 이를 완화합니다. 일반적으로이 블록 집합은 충돌시 작성된 블록보다 훨씬 크기 때문에 복사본을 만드는데 시간이 걸립니다.
복사하는 동안 저장소를 사용할 수 없으므로 전체 복구 시간이 늘어납니다. 또한 오류로 인해 한쪽에 부분적으로 쓰기가 발생하여 
논리적 블록이 손상 될 수 있습니다. 볼륨 관리자는 어느 쪽이 좋을지 모르기 때문에 복사하면 좋은 데이터를 통해 잘못된 데이터를 쓸 수 있습니다.
다행히 ASM은 DRL을 유지할 필요가 없습니다. ASM 클라이언트는 Oracle 데이터베이스 및 ACFS를 포함하는 재시도 ASM 클라이언트를 
관리하며 중요한 경우 미러 측면이 동일하도록 데이터를 복구하는 방법을 알고 있습니다. 즉 클라이언트측 구현입니다.
항상 거울면을 동일하게 만들 필요는 없습니다. 예를 들어, 파일이 데이터베이스의 일부가 되기 전에 초기화되는 경우, 
파일이 실패한 후에 다시 초기화되므로 파일은 복구 프로세스에 중요하지 않습니다.
중요한 데이터의 경우 Oracle은 항상 시작되었지만 완료되지 않았을 수 있는 쓰기를 허용해야합니다.
리두 로그는 Oracle에서 이러한 메커니즘 중 하나의 예입니다.
Oracle은 이미 이러한 인터럽트된 쓰기를 재구성해야하므로 쓰기가 성공적으로 완료된 것처럼 보일지라도 미러의 양면을 다시 작성하는 것은 간단합니다.
오라클은 복구가 필요한 블록을 정확하게 결정할 수 있기 때문에 추가 쓰기 횟수는 적을 수 있습니다.
DRL을 사용하지 않는 또 다른 이점은 읽기에 I/O 오류를 보고하지 않는 손상된 블록을 미러의 양호한 
측면에서 복구 할 수 있다는 것입니다. 블록 손상이 발견되면 미러의 각면을 판독하여 그 중 하나가 유효한지 판별합니다.
측면이 다르며 하나가 유효하면 유효한 사본이 사용되고 양쪽에 다시 작성됩니다.
이것은 호스트 사망시 부분 쓰기를 복구 할 수 있습니다. 이 메커니즘은 복구 읽기뿐만 아니라 항상 사용됩니다.
따라서 ASM 미러 블록의 한쪽에만 영향을주는 외부 손상도 복구 할 수 있습니다.

ASM and I/O Error Failure Management
이전 섹션에서는 ASM 리던던시 디스크 그룹에서 ASM이 과도 및 영구 디스크 오류를 처리하는 것에 대해 설명하지만, 
이 섹션에서는 읽기 및 쓰기 오류와 같은 I/O 오류를 ASM이 처리하는 방법을 설명하고, 
일반적으로 외부 중복 디스크 그룹의 I/O 오류를 처리하는 방법에 대해서도 설명합니다.

일반 디스크 오류 개요
디스크 드라이브는 기계 장치이기 때문에 문제가 발생할 수 있습니다. 드라이브가 장애가 발생하거나 산발적인 I/O 오류가 발생하면 
데이터베이스 오류가 발생할 가능성이 커집니다.
장치 경로 장애를 감지하고 해결하는 기능은 HBA뿐만 아니라 경로 관리자의 핵심 구성 요소입니다. 
디스크 장치가 다음 상태에 있거나 다음과 같은 문제가 있을 수 있습니다.
• 미디어 감지 오류 : 여기에는 하드 읽기 오류 및 복구 할 수없는 위치 오류가 포함됩니다.
이 상황에서 디스크 장치는 여전히 작동 중이며 SCSI_INQUIRY 요청에 응답합니다.
• 사용량이 너무 많음 : I/O 요청으로 인해 디스크 장치가 너무 많아져서 합리적인 시간내에 SCSI_INQUIRY에 응답하지 않을 수 있습니다.
• 실패한 장치 :이 경우 디스크가 실제로 실패하고 SCSI_INQUIRY 요청에 응답하지 않으며 SCSI_INQUIRY 시간 초과가 발생하면 디스크와 경로가 오프라인됩니다.
• 경로 오류 : 디스크 장치는 손상되지 않았지만 경로 구성 요소 (예 : 포트 또는 광섬유 어댑터)가 고장났습니다.
일반적으로 SCSI 드라이버 장치가 할당된 시간 내에 호스트 메시지에 응답 할 수 없거나 메시지를 보낸 경로가 실패했기 때문에 I/O 요청이 시간 초과 될 수 있습니다.
이 경로 오류를 감지하기 위해 일반적으로 HBA는 메시지가 SCSI 드라이버로부터 수신 될 때마다 타이머를 활성화합니다.
타이머가 I/O 승인을 받지 않고 링크 다운 타임 아웃을 초과하면 링크 오류가 발생합니다.
링크 다운 이벤트가 발생하면 경로 관리자는 경로가 작동하지 않는 것으로 판단하고 대기중인 입출력 요청을 대체 경로로 재 라우팅할지 여부를 평가합니다.

ASM and I/O Failures
ASM이 I / O 실패를 처리하는 데 사용하는 방법은 I / O 실패가 발생한 컨텍스트에 따라 다릅니다.
데이터베이스 인스턴스에서 I / O 장애가 발생하면 ASM에이를 알리고 ASM은 디스크를 오프라인으로 가져갈 지 여부를 결정합니다.
ASM은 디스크 그룹의 중복성과 이미 오프라인 상태에있는 디스크의 수를 기반으로 적절한 조치를 취합니다.
ASM이 디스크 그룹을 마운트하려고하는 동안 I / O 오류가 발생하면 동작은 릴리스에 따라 다릅니다.
Oracle Database 10g Release 2에서 인스턴스가 클러스터에 디스크 그룹을 처음 마운트하는 것이 아니라면 다른 인스턴스에 의해 마운트 된 디스크 그룹에서 온라인 상태의 디스크를 오프라인으로 가져 오려고 시도하지 않습니다.
디스크를 찾을 수 없으면 마운트가 실패합니다.
여기서 논리적 근거는 문제의 디스크가 실제로 실패한 경우 실행중인 인스턴스가 디스크를 매우 빠르게 오프라인 상태로 만듭니다.
인스턴스가 "처음 마운트"된 경우 누락 된 디스크의 상태와 관련하여 문의 할 다른 인스턴스가 없으므로 누락 된 디스크를 오프라인 상태로 만듭니다.
오류가 로컬이고 디스크에 액세스 할 수없는 인스턴스에 디스크 그룹을 마운트하려면 디스크 그룹을 마운트 한 노드에서 디스크를 삭제해야합니다.
낙하 방지 명령을 사용하면 즉시 마운트가 가능합니다.
이러한 시나리오에서는 종종 ASM_DISKSTRING의 오류 또는 노드의 사용 권한 때문에 디스크가 특정 노드에서 발견되지 않습니다.
Oracle Database 11g에서는 이러한 두 가지 동작이 여전히 유효하지만 인스턴스가 디스크 그룹을 처음 마운트하는지 여부에 따라 둘 중 하나를 선택하는 대신 작동 방식이 마운트 방식에 따라 달라집니다.
예를 들어 기본값 인 디스크 그룹 MOUNT [NOFORCE] 명령을 사용하는 경우 디스크 그룹의 모든 온라인 디스크를 마운트 할 때 찾을 수 있어야합니다.
누락 된 디스크가 있거나 I / O 오류가 있으면 마운트가 실패합니다.
디스크 그룹 MOUNT FORCE는 필요에 따라 디스크를 오프라인 상태로 만들려고하지만 마운트가 완료되도록합니다.
FORCE의 과도한 사용을 방지하기 위해 MOUNT FORCE는 디스크를 오프라인으로 전환해야하는 경우에만 성공합니다.
11.2.0.3에서 MOUNT [NOFORCE]는 Exadata 및 Oracle Database Appliance에서 정상적인 이중화에 대해 하나 이상의 Failgroup을 남기거나 높은 이중화 디스크 그룹에 대해 두 개 이상의 Failgroup을 남기면 성공합니다.
ASM뿐만 아니라 데이터베이스는 I / O 실패 또는 데이터 손상을 처리하기위한 사전 대책을 취합니다.
데이터베이스가 디스크에서 데이터 블록을 읽으면 체크섬, 블록 번호 및 일부 다른 필드의 유효성을 검사합니다.
블록이 일관성 검사에 실패하면 유효한 블록 읽기를 얻기 위해 블록을 다시 읽으려고 시도합니다.
다시 읽기는 I / O 하위 시스템과 관련된 일시적인 문제를 처리하기위한 것입니다.
오라클은 개별 미러 측면을 읽어 부패를 해결할 수 있습니다.
데이터 파일의 손상된 블록의 경우 데이터베이스 코드는 미러의 각면을 읽고 좋은 복사본을 찾습니다.
올바른 복사본을 찾으면 읽기가 성공하고 올바른 복사본이 디스크에 다시 쓰여져 데이터베이스가 손상을 복구합니다. 데이터베이스가 쓰기를 수행하기 위해 적절한 잠금을 보유하고 있다고 가정합니다.
미러링이 스토리지 배열에서 수행 된 경우 (외부 중복) 판독을 위해 미러 측면을 선택하는 인터페이스가 없습니다.
이 경우 RDBMS는 동일한 블록을 다시 읽고 간단하게 최선을 다하겠습니다. 그러나 스토리지 배열의 경우이 프로세스는 원래 읽기가 손상되지 않은 한 어레이 캐시에서 동일한 데이터를 반환 할 가능성이 큽니다.
RDBMS가 양호한 데이터를 찾을 수 없으면 오류가 표시됩니다.
손상된 블록은 블록을 다시 읽으려는 반복 된 시도와 과도한 오류보고를 피하기 위해 버퍼 캐시 (캐시 관리 블록 인 경우)에 보관됩니다.
손상의 처리는 각 파일 유형 및 파일에 액세스하는 각 코드 조각마다 다릅니다.
예를 들어, RMAN 백업 중 데이터 파일 손상 처리는이 섹션에서 설명한 것과 다르며 아카이브 로그 파일 손상을 처리합니다.
ASM은 대부분의 볼륨 관리자와 마찬가지로 하드웨어를 사전에 폴링하지 않고 폴트를 찾고 있습니다.
서버는 일반적으로 이러한 폴링을 필요로하지 않을만큼 충분한 I / O 활동을합니다.
또한 ASM은 케이블이 당겨 지거나 디스크에 장애가 발생했기 때문에 I / O 오류가 발생했는지 여부를 알 수 없습니다.
오류를 반환 할시기를 결정하거나 I / O 완료를 기다리는 것을 결정하는 것은 운영 체제 (OS)의 책임입니다.
ASM은 OS가 I / O 완료를 처리하는 방법을 제어하지 않습니다.
OS는 장치 드라이버에서 몇 번 재 시도한 후에 호출자 (Oracle I / O 프로세스)에 영구 I / O 오류를 알립니다.

NOTE
Oracle Database 10g부터 디스크 장애 시 ASM은 장애가 발생한 디스크의 장애 그룹에 있는 디스크 파트너 및 다른 디스크를 폴링합니다.
이것은 ASM이 읽기 작업이 아닌 쓰기 작업 I/O 오류에서만 디스크 그룹에서 오프라인으로 디스크를 가져 오는 장애 그룹에 존재할 수 있는 
병적 문제를 효율적으로 탐지하기 위해 수행됩니다. 예를 들어, Oracle Database 10g에서 Oracle 쓰기 I/O 작업 중에 영구 디스크 I/O 오류가 
발생하면 ASM은 영향을 받은 디스크를 오프라인으로 가져와 즉시 디스크 그룹에서 삭제하므로 오래된 데이터 읽기를 방지합니다.
Oracle Database 11g에서 DISK_REPAIR_TIMER 특성이 활성화 된 경우 ASM은 디스크를 오프라인으로 가져오지만 삭제하지는 않습니다.
그러나 DISK_REPAIR_TIMER가 만료되면 ASM은 디스크를 삭제합니다.
이 기능은 이 장 앞부분의 "디스크 오류 복구:고속 디스크 재 동기화"절에서 설명합니다.
Oracle Database 11g에서 ASM (ASM 중복 디스크 그룹)은 읽기가 실패 할 경우 불량 블록을 재 매핑하려고 시도합니다.
이 재 맵핑은 쓰기로 이어져 ASM이 디스크를 오프라인으로 만들 수 있습니다.
읽기 오류의 경우 블록을 2차 범위에서 읽습니다 (정상 또는 높은 중복성에만 해당).
디스크의 파트너 디스크가 오프라인인 경우와 같이 디스크 손실로 인해 데이터가 손실되는 경우 ASM은 
자동으로 디스크 그룹을 분리하여 디스크 그룹 데이터의 무결성을 보호합니다.

NOTE
디스크 헤더 및 기타 미러되지 않은 실제 주소가 지정된 읽기에서의 읽기 실패로 인해 ASM이 디스크를 오프라인 상태로 만듭니다.

11g에서 디스크를 오프라인으로 전환하기 전에 ASM은 해당 실패 그룹의 나머지 모든 디스크의 디스크 헤더를 검사하여 능동적으로 활발하게 점검합니다.
오프라인 효율성을 위해 동일한 장애 그룹에 남아있는 모든 디스크에 장애가 발생하면 ASM은 전체 장애 그룹을 사전에 오프라인 상태로 전환합니다.
ASM은 디스크를 오프라인으로 만든 다음 여러 개의 장애 그룹에 디스크가 명백하게 고장난 경우 디스크 그룹을 분리하지 않고 디스크 그룹을 분리합니다.
또한 ASM은 장애 그룹의 디스크를 한 번에 오프라인으로 전환하여보다 효율적으로 재구성 할 수 있습니다.
하트 비트를 정상 또는 높은 중복 디스크 그룹의 파트너쉽 상태 테이블 (PST) 복사본에 쓸 수 없으면 ASM은 PST 복사본이 포함된 디스크를 오프라인으로 가져와 
PST를 동일한 디스크 그룹의 다른 디스크로 이동합니다. 외부 중복 디스크 그룹에서 하트 비트 쓰기가 실패하면 디스크 그룹이 마운트 해제됩니다.
마운트 시, 로컬 클러스터 외부의 인스턴스가 디스크 그룹을 마운트하는지 여부를 판별하기 위해 최소 6초 간격으로 두 번 읽습니다.
두 개의 읽기가 다른 내용을 표시하면 디스크 그룹이 보이지 않는 인스턴스에 마운트됩니다.
디스크 그룹이 마운트 된 후 ASM은 기록된 백 번째 I/O마다 하트 비트를 다시 읽습니다.
이것은 두 가지 문제를 해결하기 위해 수행되었습니다. 하나는 마운트 시간 확인에서 포착 할 수 없는 잠재적 경쟁 조건을 잡는 것입니다. 
둘째, 디스크 그룹이 우연히 두 개의 다른 클러스터에 마운트되어 있는지 확인하는 것입니다. 둘 다 PST에 대해 하트 비트가됩니다.
다음 예에서 ASM은 경고 로그에서와 같이 I/O 실패를 감지합니다.

-- log 내용 --
Wed May 10 08:13:47 2006
NOTE: cache initiating offline of disk 1 group 1
WARN1NG: offlining mode 3 of disk I/OxO (DATA_1_0001)
NOTE: halting all I/Os to diskgroup DATA 1
NOTE: active pin found: OxOx546d24cc
Wed May 10 08:13:52 2006
ERROR: PST-initiated MANDATORY DISMOUNT of group DATA 1

다음 경고는 ASM이 특정 디스크에서 I/O 오류를 감지했음을 나타냅니다.

WARNING: offlining mode 3 of disk I/OxO (DATA_1_0001)

이 오류 메시지는 디스크를 오프라인으로 만들려고하면 데이터가 손실되므로 ASM이 디스크 그룹을 대신 마운트 해제함을 사용자에게 경고합니다.

ERROR: PST-initiated MANDATORY D1SMOUNT of group DATA_1

동일한 디스크 (DATA_1_0001)의 문제를 나타내는 메시지도 OS 로그에 나타납니다.
많은 사용자가 실패 및 복구를 테스트하기 위해 ASM 파일에서 손상을 시뮬레이션하려고합니다.
고객이 유도하는 두 가지 유형의 고장 주입 테스트는 블록 손상 및 디스크 고장입니다.
유감스럽게도 ASM 디스크 덮어 쓰기는 디스크 오류가 아닌 손상을 시뮬레이트합니다.
디스크 덮어 쓰기는 데이터베이스 파일뿐만 아니라 ASM 메타 데이터도 손상시킵니다.
이것은 사용자가 의도한 결함 주입 테스트가 아닐 수도 있습니다.
폴트 인젝션 테스트에서 실행되는 테스트 세트를 결정하기 전에 배포된 리던던시 유형을 인식하고 있어야합니다.
블록 또는 블록 세트가 물리적으로 손상된 경우 ASM(ASM 중복 디스크 그룹에서)은 손상되지 않은 블록 하나를 찾기 위해 
손상된 블록의 모든 미러 사본을 다시 읽으려고 시도합니다. 이중화 및 손상 소스는 손상된 블록을 복구 할 때 중요합니다.
데이터가 외부 수단을 통해 ASM 외부 중복 디스크 그룹의 디스크에 기록되면 이러한 쓰기는 스토리지 배열 미러의 모든 복사본으로 이동합니다.
Unix/Linux dd 명령을 실수로 사용중인 ASM 디스크에 쓰는 경우 손상이 발생할 수 있습니다.

Space Management Views for ASM Redundancy
두 개의 V$ASM 뷰는 여유 공간 사용에 대한보다 정확한 정보 USABLE_FREE_SPACE 및 REQUIRED_MB_FREE를 제공합니다.
Oracle Database 10g Release 2에서 V$ASM_DISKGROUP에 있는 USABLE_FILE_MB 열은 미러링을 고려하여 
"안전하게"사용할 수있는 여유 공간을 나타냅니다. 열은 디스크 그룹에서 사용 가능한 공간을 보다 정확하게 볼 수 있게 해줍니다.
외부 중복성의 경우 FREE_MB 열은 USABLE_FREE_SPACE와 같습니다.
USABLE_FREE_SPACE와 함께 V$ASM_DISKGROUP에 있는 REQUIRED_MB_FREE 열은 하나 이상의 디스크 장애가 발생한 후 
중복성을 복원하기 위해 주어진 디스크 그룹에서 사용 가능한 공간의 양을 보다 정확히 나타내는데 사용됩니다.
이 열에 표시된 공간의 양은 미러링을 고려합니다. 다음 토론에서는 REQUIRED_MB_FREE가 계산되는 방법을 설명합니다.
REQUIRED_MB_FREE는 스토리지를 추가하지 않고 디스크 그룹에서 허용 할 수있는 최악의 장애가 발생한 후 중복성을 복원하기 위해 
디스크 그룹에서 사용할 수 있어야하는 공간을 나타냅니다. 최악의 장애는 영구 디스크 장애 및 디스크 손실을 의미합니다.
이 요구 사항의 목적은 중복성을 복원 할 수있는 충분한 공간이 장애 그룹에 있는지 확인하는 것입니다.
그러나 계산된 값은 배포된 ASM 중복의 유형에 따라 다릅니다.
• 두 개 이상의 장애 그룹이있는 일반 중복 디스크 그룹의 경우, 이 값은 가장 큰 실패 그룹에있는 모든 디스크의 전체 원시 공간입니다.
가장 큰 실패 그룹은 가장 큰 전체 원시 용량을 가진 그룹입니다.
예를 들어 각 디스크가 자체 실패 그룹에 있으면 값은 최대 용량 디스크의 크기가 됩니다.
정상적인 이중화에서 장애 그룹이 2개만 있는 경우 디스크 그룹의 가장 큰 디스크 크기가 REQUIRED_MB_FREE를 계산하는데 사용됩니다.
• 4개 이상의 장애 그룹이있는 높은 중복성 디스크 그룹의 경우, 이 값은 두 개의 가장 큰 실패 그룹에 있는 모든 디스크의 전체 원시 공간입니다.
장애 그룹 전체에서 디스크의 크기가 다른 경우 REQUIRED_MB_FREE 계산이 더욱 복잡해집니다.
따라서 디스크 그룹에 동일한 크기의 디스크가 있는 것이 좋습니다.
FREE_MB, REQUIRED_MIRROR_FREE_MB 및 USABLE_FILE_MB 간의 관계 때문에 USABLE_FILE_MB가 
V$ASM_DISKGROUP에 음수 값을 갖는 경우에 주의하십시오. USABLE_FILE_MB가 음수 값이면 특정 디스크 실패 시나리오에서 
모든 범위의 미러를 재구 성할 충분한 공간이 없습니다. 예를 들어, 두 개의 실패 그룹이있는 일반 중복 디스크 그룹에서 단일 디스크의 손실을 견딜 수 있는 
충분한 공간이 없으면 USABLE_FILE_MB가 음수가됩니다. 이 경우 장애가 발생한 디스크가 포함된 장애 그룹의 나머지 디스크를 강제로 제거하여 
모든 중복을 잃어 버리지 않고 사용 가능한 공간을 확보 할 수 있습니다.
USABLE_FILE_MB의 음수 값은 FREE_MB의 값에 따라 새 파일을 만들지 못할 수도 있음을 의미합니다.
다음 번에 실패하면 중복성이 감소 된 파일이 생기거나 공간 부족 상태가되어 데이터베이스를 정지시킬 수 있습니다.
USABLE_FILE_MB가 음수가 되면 디스크 그룹에 가능한 한 빨리 공간을 추가하는 것이 좋습니다.

Disk Groups and Attributes 
Oracle Database 11g는 ASM 속성의 개념을 도입했습니다.
인스턴스에 따라 다르지만 모든 디스크 그룹에 적용되는 초기화 매개 변수와 달리 ASM 속성은 디스크 그룹과 관련이 있으며 모든 인스턴스에 적용됩니다.

Attributes Overview 
ASM 디스크 그룹 속성은 V$ASM_ATTRIBUTES 뷰에 표시됩니다.
그러나 이 보기는 디스크 그룹 호환성(COMPATIBLE.ASM)이 11.1.0으로 설정 될 때까지 채워지지 않습니다.
Clusterware Database 11g Release 2에서 다음 속성을 설정할 수 있습니다.

적합성
• COMPATIBLE.ASM :이 속성은 디스크 그룹을 마운트 할 수있는 Oracle ASM 인스턴스의 최소 소프트웨어 버전을 결정합니다.
이 설정은 디스크의 ASM 메타 데이터에 대한 데이터 구조의 형식에도 영향을줍니다.
SQL CREATE DISKGROUP 문, ASMCMD mkdg 명령 또는 Oracle Enterprise Manager를 사용하여 디스크 그룹을 만드는 경우 COMPATIBLE.ASM 특성의 기본값은 10.1입니다.
• COMPATIBLE.RDBMS :이 속성은 디스크 그룹을 사용 (열거) 할 수있는 모든 데이터베이스 인스턴스의 최소 COMPATIBLE 데이터베이스 초기화 매개 변수 설정을 결정합니다.
디스크 그룹에 액세스하는 모든 데이터베이스의 COMPATIBLE 초기화 매개 변수 값이 COMPATIBLE.RDBMS의 새 설정 값 이상으로 설정되어 있는지 확인하십시오.
COMPATIBLE.ASM 특성과 마찬가지로 기본값은 10.1입니다.
COMPATIBLE.ASM은 항상 COMPATIBLE.RDBMS보다 크거나 같습니다.
이 항목은 이 섹션의 뒷부분에서 자세히 설명합니다.
• COMPATIBLE.ADVM :이 속성은 디스크 그룹에 ADVM 볼륨이 포함될 수 있는지 여부를 결정합니다.
이 값은 11.2 이상으로만 설정할 수 있습니다.
COMPATIBLE.ADVM 특성의 기본값은 설정할 때까지 비어 있습니다.
그러나 COMPATIBLE.ADVM을 고급 상태로 만들기 전에 COMPATIBLE.ASM 특성은 이미 11.2 이상으로 설정되어 있어야하며 ADVM 볼륨 드라이버를 로드해야합니다.
COMPATIBLE.ASM 특성은 항상 COMPATIBLE.ADVM보다 크거나 같습니다.
또한 COMPATIBLE.ADVM과 COMPATIBLE.RDBMS 간에는 아무런 관련이 없습니다.

ASM Disk Group Management
• DISK_REPAIR_TIME :이 속성은 디스크를 복구하고 온라인 상태로 되돌릴 시간 간격을 지정하여 디스크 삭제 작업의 지연을 정의합니다.
시간은 분(m 또는 M) 또는 시간(h 또는 H) 단위로 지정할 수 있습니다.
이 항목은 "디스크 오류 복구 : 빠른 디스크 다시 동기화"절에서 설명합니다.
• AU_SIZE :이 속성은 디스크 그룹의 단위 크기를 정의합니다.
• SECTOR_SIZE :이 속성은 디스크 그룹에 포함 된 디스크의 기본 섹터 크기를 지정합니다.
SECTOR_SIZE 디스크 그룹 속성은 디스크 그룹 생성 중에 만 설정할 수 있으며 가능한 값은 512, 4096 및 4K입니다.
섹터 크기를 기본값 이외의 값으로 설정하려면 COMPATIBLE.ASM 및 COMPATIBLE.RDBMS 디스크 그룹 특성을 11.2 이상으로 설정해야합니다.

Exadata Systems
• CONTENT.TYPE :이 새로운 속성은 11gR2에서 특별히 소개되었으며 Exadata 시스템에서만 유효합니다.
디스크 그룹에 CONTENT.TYPE 속성을 사용하려면 COMPATIBLE.ASM 속성을 11.2.0.3 이상으로 설정해야합니다.
CONTENT.TYPE 속성은 디스크 그룹 유형을 식별하고 해당 디스크 그룹에 대해 구체적으로 디스크 파트너 관계를 암시적으로 지정합니다.
옵션 유형은 DATA, Recovery 또는 System 일 수 있습니다. 이 매개 변수를 설정하면 ASM이 데이터 사본을 미러링하는 장애 그룹에서 
가장 가까운 이웃 디스크까지의 거리가 결정됩니다.
잊지 말고 다음 사항에 유의하십시오.
• 기본값은 가장 가까운 이웃 디스크와 1의 거리를 지정하는 DATA입니다.
• RECOVERY 값은 가장 가까운 인접 디스크와의 거리를 3으로 지정합니다.
• SYSTEM 값은 거리를 5로 지정합니다.
• STORAGE.TYPE :이 속성은 디스크 그룹의 디스크 유형을 식별하며 사용자가 해당 하드웨어에서 HCC(Hybrid Columnar Compression)를 활성화 할 수 있도록합니다.
가능한 값은 AXIOM, PILLAR, ZFSSA 및 OTHER입니다.
AXIOM 및 ZFSSA 값은 각각 Oracle Sun Pillar Axiom 스토리지 플랫폼 및 Oracle SUN ZFSSA 스토리지 장치를 반영합니다.
속성을 OTHER로 설정하면 모든 유형의 디스크가 디스크 그룹에있을 수 있습니다.
STORAGE.TYPE 속성은 디스크 그룹을 만들 때 또는 디스크 그룹을 변경할 때만 설정할 수 있습니다.
클라이언트가 디스크 그룹에 연결된 경우에는 속성을 설정할 수 없습니다.
• IDP.TYPE :이 속성은 지능형 데이터 배치 기능과 관련이 있으며 디스크의 데이터 배치에 영향을줍니다.
• CELL.SMART_SCAN_CAPABLE :이 속성을 설정하면 Exadata에서 스마트 스캔 기능을 활성화합니다.

File Access Control
• ACCESS_CONTROL.ENABLED :이 속성을 설정하면 파일 액세스 제어 기능을 사용할 수 있습니다.
이 속성은 가능한 값이 TRUE 및 FALSE 인 디스크 그룹을 변경할 때만 설정할 수 있습니다.
• ACCESS_CONTROL.UMASK :이 속성은 파일을 소유한 사용자, 동일한 사용자 그룹의 사용자 및 사용자 그룹에 없는 
사용자에 대해 ASM 파일을 생성 할 때 마스크 할 사용 권한을 지정합니다.

ASM umask 설정의 의미는 Unix/Linux umask와 유사합니다.
이 속성은 디스크 그룹의 모든 파일에 적용되며 가능한 값은 세 자리 조합으로 나타납니다. : {0|2|6} {0|2|6} {0|2|6}
기본값은 066입니다. 이 속성은 디스크 그룹을 변경할 때만 설정할 수 있습니다.
이것은 디스크 그룹 호환성 속성 설정에 의해 활성화된 기능에 대한 표뿐만 아니라 실제 출력을 위한 자리 표시자입니다.

Disk Group Compatibility Attributes
디스크 그룹 속성은 디스크 그룹 작성시 또는 ALTER DISKGROUP 명령을 사용하여 설정할 수 있습니다.
예를 들어 10.1 디스크 그룹 호환성을 가진 디스크 그룹을 만든 다음 COMPATIBLE.ASM 특성을 11.2로 설정하여 11.2로 업그레이드 할 수 있습니다.
호환성 속성에 대한 설명은 다음 섹션에서 다룹니다.
다음 예는 10.1 호환성을 가진 디스크 그룹을 만드는 CREATE DISKGROUP 명령을 보여줍니다 (기본값).

[SQL]
CREATE DISKGROUP DATA DISK 
'/dev/rdsk/c3t19d16s4',
'/dev/rdsk/c3t19d17s4';

이 디스크 그룹은 다음 명령을 사용하여 11.2로 업그레이드 할 수 있습니다.

[SQL]
ALTER DISKGROUP DATA SET ATTRIBUTE 'compatible.asm'='11.2.0.0.0';

디스크 그룹이 성공적으로 진행되면 다음 메시지가 나타납니다.

SUCCESS: Advancing ASM compatibility to 11.2.0.0.0 for grp 1

또 다른 예에서, 할당 단위 크기를 지정하는 AU_SIZE 속성과 COMPATIBLE.ASM 속성은 디스크 그룹 작성 시 지정됩니다.
AU_SIZE 속성은 디스크 그룹 생성시에만 지정할 수 있으며 ALTER DISKGROUP 명령을 사용하여 변경할 수 없습니다.

[SQL]
CREATE DISKGROUP FLASH DISK 
'/dev/raw/raw15', '/dev/raw/raw16','/dev/raw/raw17' 
ATTRIBUTE 'au_size'='4M', 'compatible.asm'='11.2';

V$ASM_ATIRIBUTE 뷰를 질의하여 DATA 디스크 그룹 속성을 얻을 수 있습니다 :

[SQL]
SELECT NAME, VALUE 
FROM V$ASM_ATTRIBUTE 
WHERE GROUP_NUMBER=1;

이전 예에서는 COMPATIBLE.ASM 특성이 향상되었습니다. 다음 예제에서는 COMPATIBLE.RDBMS 특성을 향상시킵니다.
버전은 11.2.0.0.0과 동일한 11.2로 설정됩니다.

[SQL]
ALTER DISKGROUP DATA SET ATTRIBUTE 'COMPATIBLE.RDBMS'='11.2';

Database Compatibility
데이터베이스 인스턴스가 처음 ASM 인스턴스에 연결되면 인스턴스간에 지원 될 수있는 가장 높은 Oracle 버전을 협상합니다.
ASM과 RDBMS 사이에는 인스턴스 수준 소프트웨어 호환성 설정과 디스크 그룹별 설정이라는 두 가지 유형의 호환성 설정이 있습니다.
인스턴스 - 소프트웨어 호환성은 init.ora 매개 변수 COMPATIBLE을 사용하여 정의됩니다.
ASM 또는 데이터베이스 인스턴스 레벨에서 11.2, 11.1, 10.2 또는 10.1로 설정 할 수 있는 이 COMPATIBLE 매개 변수는 
인스턴스에서 사용 가능한 소프트웨어 기능을 정의합니다. ASM 인스턴스에서 COMPATIBLE 매개 변수를 설정하는 것은 허용되지 않습니다.
ASM 인스턴스에 COMPATIBLE 매개 변수의 더 낮은 값을 사용하는 것은 유용하지 않습니다. ASM이 여러 데이터베이스 버전과 호환 가능하기 때문입니다.
COMPATIBLE.ASM 값은 COMPATIBLE.RDBMS보다 크거나 같아야합니다.
다른 호환성 설정은 디스크 그룹에만 적용되며 ASM 디스크 그룹에서 사용할 수 있는 속성과 데이터베이스에서 사용할 수 있는 속성을 제어합니다.
이것은 ASM 호환성(COMPATIBLE.ASM) 및 RDBMS 호환성 (COMPATIBLE.RDBMS) 속성으로 각각 정의됩니다.
이러한 호환성 속성은 디스크 그룹 메타 데이터에 지속적으로 저장됩니다.

RDBMS Compatibility
RDBMS 디스크 그룹 호환성은 COMPATIBLE.RDBMS 속성에 의해 정의됩니다.
Oracle Database 11g에서 기본적으로 10.1 인이 속성은 디스크 그룹을 마운트 할 수있는 데이터베이스의 최소 COMPATIBLE 버전 설정입니다.
COMPATIBLE.RDBMS의 디스크 그룹 속성을 11.2로 변경하면 되돌릴 수 없습니다.

ASM Compatibility
COMPATIBLE.ASM에 정의된 ASM 디스크 그룹 호환성은 디스크상의 ASM 메타 데이터 구조의 영구 형식을 제어합니다.
ASM 호환성은 기본적으로 10.1이며 RDBMS 호환성 레벨보다 크거나 같아야합니다.
호환성이 11.2로 올라간 후에는 더 낮은 버전으로 다시 설정할 수 없습니다. 현재 소프트웨어 버전까지의 모든 값을 설정하고 시행 할 수 있습니다.
호환성 속성에는 양자화 된 값이 있으므로 버전 번호의 다섯 부분 모두를 지정해야하는 것은 아닙니다.
COMPATIBLE.RDBMS 및 COMPATIBLE.ASM은 함께 디스크상의 ASM 메타 데이터 구조의 영구 형식을 제어합니다.
데이터베이스의 호환성 매개 변수 설정, 데이터베이스의 소프트웨어 버전 및 디스크 그룹의 RDBMS 호환성 설정의 조합은 데이터베이스 인스턴스가 
지정된 디스크 그룹을 마운트 할 수 있는지 여부를 결정합니다. 호환성 설정은 디스크 그룹에 사용할 수있는 ASM 기능을 결정합니다.

다음 쿼리는 최근에 Oracle Database 10g에서 Oracle Clusterware 11gR2로 업그레이드 된 ASM 인스턴스를 보여줍니다.

[SQL]
SELECT NAME, BLOCK_SIZE, ALLOCATION_UNIT_SIZE "AU_SIZE", 
STATE, COMPATIBILITY "ASM COMP", DATABASE_COMPATIBILITY "DB COMP" 
FROM V$ASM_DISKGROUP;

ASM 호환성 및 RDBMS 호환성은 여전히(업그레이드 된 인스턴스의 경우) 기본값인 10.1입니다. 10.1 설정은 ASM이 지원하는 가장 낮은 속성입니다.

NOTE
ASM 인스턴스는 각 데이터베이스 인스턴스의 데이터베이스 COMPATIBLE init.ora 매개 변수 설정이 모든 디스크 그룹의 RDBMS 호환성보다 
크거나 같으면 다른 호환성 설정을 사용하여 다른 RDBMS 클라이언트를 지원할 수 있습니다.
호환성 향상에 대한 예는이 장의 앞부분에있는 "디스크 그룹 및 속성"절을 참조하십시오.
디스크 그룹의 ASM 호환성은 11.0으로 설정할 수 있지만 RDBMS 호환성은 10.1이 될 수 있습니다 (다음 예 참조).

[SQL]
SELECT DB_NAME, STATUS, SOFTWARE_VERSION, COMPATIBLE_VERSION FROM V$ASM CLIENT;

[SQL]
SELECT NAME, COMPATIBILITY "COMPATIBLE", DATABASE_COMPATIBILITY "DATABASE COMP" FROM V$ASM_DISKGROUP;

이것은 디스크 그룹이 ASM 소프트웨어 버전 11.0 이상에서만 관리 될 수있는 반면 데이터베이스 소프트웨어 버전은 10.1 이상이어야 함을 의미합니다.

Summary
ASM 디스크는 디스크 그룹에 부여된 영구 저장 장치의 단위입니다. 디스크 그룹에 디스크를 추가하거나 삭제할 수 있습니다. 
디스크 그룹에 디스크를 추가하면 자동으로 또는 관리자가 디스크 이름을 지정합니다. 이것은 운영 체제를 통해 디스크에 액세스하는데 
사용되는 OS 이름과 다릅니다. RAC 환경에서 다른 노드의 다른 OS 이름으로 동일한 디스크에 액세스 할 수 있습니다.
ASM은 오라클이 모든 파일에 액세스하기 위해 사용하는 표준 OS 인터페이스를 통해 디스크에 액세스합니다 (ASMLIB가 사용되는 경우 제외).
일반적으로 ASM 디스크는 OS에서 볼 수있는 LUN의 파티션입니다. ASM 디스크는 로컬 파일 시스템 파일을 제외하고는 
OS 열기 시스템 호출을 통해 열 수있는 모든 장치가 될 수 있습니다. LUN은 단일 물리적 디스크 스핀들 일 수도 있고 고도로 중복된 
저장소에 의해 관리되는 가상 LUN 일 수도 있습니다. 디스크 그룹은 ASM에서 관리하는 기본 객체입니다. 
여러 개의 ASM 디스크로 구성됩니다. 각 디스크 그룹은 자체 설명합니다. 
즉, 디스크 그룹의 공간 사용에 대한 모든 메타 데이터가 디스크 그룹에 완전히 포함되어 있습니다.
ASM이 디스크 그룹의 모든 디스크를 찾을 수 있으면 추가 메타 데이터없이 디스크 그룹에 대한 액세스를 제공 할 수 있습니다.
주어진 ASM 파일은 단일 디스크 그룹 내에 완전히 포함되어 있습니다.
그러나 디스크 그룹에는 여러 데이터베이스에 속한 파일이 포함될 수 있으며 단일 데이터베이스는 여러 디스크 그룹의 파일을 사용할 수 있습니다.
대부분의 설치에는 소수의 디스크 그룹만 포함됩니다. 일반적으로 2개, 드물게는 3개 이상입니다.