ORACLE ASM이 스토리지를 관리하는 데이터 구조 list
Disk Group
ASM Disk group은 논리적인 단위로써 관리되는 디스크 집합체이며, ASM에서 고려되는 최상의 데이터 구조이다. 개별 Disk group은 자신의 파일 Directory와 Disk Directory 그리고 다른 Meta data를 포함하고 있다(Directory 개념은 해당 목차에서 다루도록 하겠다).
디스크의 크기에 비례하는 숫자의 Extent가 개별 Disk에 할당 됨으로써, Application에 의해 발생되는 I/O load는 하나의 Disk group에 속해있는 모든 Disk에 골고루 분산된다. 이러한 기능으로 Disk group의 디스크 공간이 없는 상태는, 바로 모든 Disk가 데이터로 꽉 차있다는 것을 의미한다.
이렇게 균등하게 I/O load가 분산되어 처리되기 때문에, 특정 Disk group구성 시 사용되는 Disk들은 크기가 비슷하고, 동등한 수준의 성능을 나타내는 것으로 지정해야 원하는 수준의 결과를 달성할 수 있다. 즉, 가장 좋은 성능을 나타내는 Disk 들을 모아 특정 Disk group을 생성하고, 이 Disk group에 Application에서 가장 중요한 데이터들을 저장하는 방법을 모색할 수 있는 것이다.
현재, ASM Disk group은 동시에 63개의 Disk group을 mount 할 수 있다.
Failure Group
Failure group은 스토리지 리소스를 공유하는 Disk group의 일부분이다. 여기서 말하는 ‘리소스’는 장애 발생 시 함께 영향을 받게 되는 Disk들이 서로 공유하고 있는 리소스를 일컫는다. 예를 들어, 어느 Disk들은 SCSI 컨트롤러 1번에 연결되어 있고, 나머지 Disk들은 SCSI 컨트롤러 2에 연결되어 있다면, 전자의 Disk들은 Failure group 1이 되는 것이고, 나머지 Disk 들은 Failure group 2에 속하게 되는 것이다. 즉, 운명을 같이하는 Disk 들의 집합체가 Failure group을 형성하는 것이다. 결과적으로, 하나의 Disk group은 여러 개의 Failure group으로 구성될 수 있다.
Failure group을 어떻게 지정하는 가는 고객이 원하는 안정성의 수준이 무엇인가에 따라 상당히 다를 수 있기 때문에, 사용자가 수동으로 지정/활용하는 것이 일반적이라 하겠다. 만약 Disk group 생성 시 Failure group을 지정하지 않는 다면, ASM은 개별 Disk에 대한 Failure group을 자신의 Disk로 지정한다.
Disk group을 생성할 때마다, DBA들은 그 Disk group의 redundancy를 고려해야 한다. 즉, 데이터의 복사본을 어떻게 유지할 것인가를 판단해야 한다(Data mirroring과 관계 있다). 이는 아래와 같이 세 개로 분류하여 지정된다.
■ EXTERNAL REDUNDANCY
ASM은 생성되는 Disk group에 대해 어떠한 redundancy를 고려하지 않겠다는 것을 의미한다. 이런 경우, 해당 Disk group에 대한 redundancy를 위해 Hardware solution을 사용하던지, 아니면 Disk 장애를 그대로 받아 들여야 한다.
■ NORMAL REDUNDANCY : 2-way mirroring
하나의 failure group에 장애가 발생하더라도 데이터 손실을 예방할 수 있는 방법이다. 이렇게 지정하기 위해서는 적어도 2개의 failure group을 지정할 수 있어야 한다.
■ HIGH REDUNDANCY : 3-way mirroring
가장 높은 수준의 데이터 보호 방법이다. 두 개의 failure group에 장애가 발생하더라도 데이터 손실이 발생하지 않는다. 적어도 3개의 failure group을 지정해야 한다.
ASM Disk
하나의 Disk group은 ASM Disk의 집합체로 구성되는 것이다. 즉, Disk group에 스토리지가 추가 되거나 삭제될 때 ASM Disk 단위로 처리된다. 또한, 데이터베이스 인스턴스에서 Direct I/O가 가능한 물리적인 disk이어야만 한다.
ASM Disk는 서로 다른 노드에서도 동일하게 인식되는 추상적인 이름을 갖고있다. 즉, OS에서 disk를 접근하기 위해 사용하는 이름과는 다르다. 이렇게 다른 이름을 유지하는 이유는 다른 노드들이 동일한 Disk에 대해서 상이한 OS 이름을 갖게 될 경우가 있기 때문이다. ASM Disk 이름은 Disk가 추가될 때 관리자가 지정할 수도 있고, 지정하지 않으면 자동적으로 지정된다. ASM 인스턴스가 Disk group을 mount 할 때, 정확한 ASM Disk를 찾기 위해 관련 OS 이름들이 검색된다. 그리하여 개별 OS 이름과 ASM Disk header 정보의 매핑작업이 이뤄지고 어떤 ASM Disk가 사용될 것인지를 결정하는 것이다. 위 매핑정보는 데이터베이스 인스턴스의 메모리에 저장/관리된다. OS 이름은 사전 경고 없이 변경될 가능성이 있기 때문에, ASM Disk에 저장되지 않는 특성을 갖는다.
ASM은 동시에 10,000개의 disk를 지원할 수 있다.
select a.name “Group_Name”,a.total_mb,a.free_mb,b.name “Disk_Name”,b.failgroup
from v$asm_diskgroup a, v$asm_disk b where a.group_number = b.group_number / Group_Name TOTAL_MB FREE_MB Disk_Name FAILGROUP ————————————————————————————————————– FIRST 4016 2044 FIRST_0002 THIRD FIRST 4016 2044 FIRST_0003 THIRD FIRST 4016 2044 FIRST_0000 SECOND FIRST 4016 2044 FIRST_0001 SECOND SECOND 2008 1956 SECOND_0000 SECOND_0000 SECOND 2008 1956 SECOND_0001 SECOND_0001 THIRD 2008 1956 THIRD_0000 THIRD_0000 THIRD 2008 1956 THIRD_0001 THIRD_0001 |
ASM Files
개념
ASM File은 ASM Disk group에 저장되는 Oracle 데이터파일이다. 파일이 생성될 때, Mirroring을 어떻게 할 것인지, Striping은 어떻게 할 것인가에 대한 정보가 함께 적용된다.
ASM File은 OS에 의해 확인될 수 없으며, RMAN이나 다른 Oracle 지원 툴에 의해 확인 가능하다. OMF(Oracle Managed File)와 유사하다. OMF 처럼 더 이상 필요치 않는 파일들은 자동적으로 제거된다. 생성/삭제/읽기/쓰기/크기 변경이 가능하고, 하나의 ASM File은 하나의 Disk group에 분산 저장된다. Disk group을 이루는 개별 파일들이 모든 disk에 분산 저장되기 때문에 하나의 disk에 대한 백업은 유용하지 않다. 때문에, ASM File에 대한 백업은 RMAN을 통해서 만이 가능하다. 그러나 PL/SQL 인터페이스를 통해서 ASM File의 내용을 읽어 내는 것은 가능하다.
특성
■ Load balancing
Disk group에 있는 모든 Disk에 걸쳐서 데이터가 분산 저장되는 이유로 파일접근 형태가 균형을 이루게 된다. 이러한 특성의 장점을 극대화 하기 위해서는 동일한 성능을 나타내는 disk들로 Disk group을 구성해야 한다.
ASM은 Disk group을 구성하는 모든 disk에 걸쳐서 하나의 AU(Allocation Unit) 단위로 파일들을 분산시킨다. 이것을 COARSE striping 이라고 한다. 이에 반해, 개별 AU 단위를 더 작은 크기로 잘라 분산 시키는 것을 FINE striping 이라고 일컫는다. FINE striping은 일반적인 크기의 I/O operation을 더욱더 작은 여러 개의 I/O operation으로 나누어 병렬로 처리하는 것이다.
■ Mirroring
RAID-1과 같은 형태처럼, ASM도 다중의 데이터 복사본을 유지함으로써, 중요 데이터를 보호할 수 있다. 그러나, RAID-1과 다르게 파일단위로 처리된다. RAID-1은 멤버들이 획일적인 알고리즘을 따르게 된다.
생성 예
ASM File의 개별 정보와 DBA_DATA_FILES에서 출력된 정보를 비교해 보기 바란다.
SELECT FILE_NUMBER,BLOCK_SIZE,BLOCKS,BYTES,SPACE,TYPE,REDUNDANCY,STRIPED FROM V$ASM_FILE; F_NUMBER BLOCK_SIZE BLOCKS BYTES SPACE TYPE REDUNDANCY STRIPED ————————————————————————————————————————————– 256 8192 56321 461381632 927989760 DATAFILE MIRROR COARSE 257 8192 25601 209723392 424673280 DATAFILE MIRROR COARSE 258 8192 6401 52436992 106954752 DATAFILE MIRROR COARSE 259 8192 641 5251072 12582912 DATAFILE MIRROR COARSE 260 8192 283 2318336 16777216 CONTROLFILE MIRROR FINE 261 512 20481 10486272 33554432 ONLINELOG MIRROR FINE 262 512 20481 10486272 33554432 ONLINELOG MIRROR FINE 263 512 20481 10486272 33554432 ONLINELOG MIRROR FINE 264 8192 2945 24125440 50331648 TEMPFILE MIRROR COARSE 265 8192 19201 157294592 319815680 DATAFILE MIRROR COARSE 266 512 5 2560 2097152 PARAMETERF MIRROR COARSE |
FILE_NAME M ————————————————————————— +FIRST/cook/datafile/system.256.1 440 +FIRST/cook/datafile/sysaux.257.1 200 +FIRST/cook/datafile/undotbs1.258.1 50 +FIRST/cook/datafile/users.259.1 5 +FIRST/cook/example01.dbf 150 +FIRST/cook/controlfile/current.260.1 +FIRST/cook/onlinelog/group_1.261.1 10 +FIRST/cook/onlinelog/group_2.262.1 10 +FIRST/cook/onlinelog/group_3.263.1 10 +FIRST/cook/tempfile/temp.264.1 23 |
ASM File type
ASM Disk group 내에 저장될 수 있는 파일형태는 아래와 같다.
■ Control File
■ Datafile
■ Online Redo Log
■ Archive Log
■ Temporary data file
■ RMAN backup piece
■ Datafile Copy
■ SPFILE
■ Disaster Recovery Configuration
■ Flashback Log
■ Change Tracking Bitmap
■ DataPump Dumpset
그러나, Oracle 실행모듈과 ASCII 파일, alert log / trace 파일들은 ASM Disk에 저장될 수 없다.
ASM File template
ASM File template은 데이터파일 생성 시 파일에 적용될 성질(redundancy,striping)을 다양하게 분류하여 목록화한 형태를 말한다. Template이 없다면, 파일 생성 시 마다 개별 성질들을 지정해야 할 것이다. 성질부여 작업을 간편하게 수행하기 위한 도구라고 생각하면 무리가 없겠다.
특정 Template은 하나의 Disk group과 연결관계를 갖는다. 서로 다른 Disk group은, 다른 성질을 갖고 있으면서 이름이 동일한 Template을 가질 수 있다.
새로운 Disk group이 생성될 때, ASM은 그 Disk group과 관계된 Default template을 생성한다. 이 Default template은 다양한 Oracle 데이터파일 type에 대한 기본적인 성질들을 포함하게 되는 것이다. Default template의 성질내용은 DBA에 의해 변경 가능할 뿐만 아니라, DBA는 새로운 template을 만들 수 있다. Default template은 삭제될 수 없다.
ASM File 생성 후에, 그 파일에 대한 성질을 변경하기 위해서는 RMAN을 통해 새로운 성질을 갖고 있는 파일로 복사해야 한다. 이것이 파일의 성질을 변경할 수 있는 유일한 방법이다.
아래 내용은 System Default template의 예를 보여준다.
group_num entry_num REDUND STRIPE S NAME ———- ———- —— —— – ——————- 1 0 MIRROR COARSE Y PARAMETERFILE 1 1 MIRROR COARSE Y DUMPSET 1 2 MIRROR FINE Y CONTROLFILE 1 3 MIRROR COARSE Y ARCHIVELOG 1 4 MIRROR FINE Y ONLINELOG 1 5 MIRROR COARSE Y DATAFILE 1 6 MIRROR COARSE Y TEMPFILE 1 7 MIRROR COARSE Y BACKUPSET 1 8 MIRROR COARSE Y AUTOBACKUP 1 9 MIRROR COARSE Y XTRANSPORT 1 10 MIRROR COARSE Y CHANGETRACKING 1 11 MIRROR FINE Y FLASHBACK 1 12 MIRROR COARSE Y DATAGUARDCONFIG 2 0 UNPROT COARSE Y PARAMETERFILE 2 3 UNPROT COARSE Y ARCHIVELOG 2 5 UNPROT COARSE Y DATAFILE 2 7 UNPROT COARSE Y BACKUPSET 2 12 UNPROT COARSE Y DATAGUARDCONFIG 2 11 UNPROT FINE Y FLASHBACK 2 10 UNPROT COARSE Y CHANGETRACKING 2 9 UNPROT COARSE Y XTRANSPORT 2 8 UNPROT COARSE Y AUTOBACKUP 2 6 UNPROT COARSE Y TEMPFILE 2 4 UNPROT FINE Y ONLINELOG 2 2 UNPROT FINE Y CONTROLFILE 2 1 UNPROT COARSE Y DUMPSET 3 0 UNPROT COARSE Y PARAMETERFILE 3 1 UNPROT COARSE Y DUMPSET 3 2 UNPROT FINE Y CONTROLFILE 3 3 UNPROT COARSE Y ARCHIVELOG 3 4 UNPROT FINE Y ONLINELOG 3 5 UNPROT COARSE Y DATAFILE 3 6 UNPROT COARSE Y TEMPFILE 3 7 UNPROT COARSE Y BACKUPSET 3 8 UNPROT COARSE Y AUTOBACKUP 3 9 UNPROT COARSE Y XTRANSPORT 3 10 UNPROT COARSE Y CHANGETRACKING 3 11 UNPROT FINE Y FLASHBACK 3 12 UNPROT COARSE Y DATAGUARDCONFIG 39 rows selected. |
Template을 정의하거나 변경할 때, COARSE/Fine-Grained striping 성질도 함께 지정한다.
ASM Meta data에 대한 redundancy/striping 성질은 ASM에 의해 사전 정의되기 때문에, 이 값들은 template 을 통해서 변경이 불가능 하다.
ASM File name
ASM filename은 아래와 같은 다양한 형태로 존재할 수 있다.
■ Fully Qualified ASM Filenames
존재하고 있는 ASM File을 참조하기 위한 형태이다. 이는 Disk group 이름, 데이터베이스 이름, 파일 type, type에 따른 tag 정보, 파일 number, 그리고 incarnation number를 가지고 ASM File을 표현한다. 이 형태는 ASM File이 생성될 때 자동적으로 지정된다. ‘Alias’를 사용하여 ASM File이 생성된다고 하더라도 이러한 형태의 filename도 함께 지정된다.
ASM은 파일생성 시 이 파일형태를 사용하기 때문에, DBA는 파일생성 문장에서 이 형태를 사용할 수 없다.
형태 : +<group>/<dbname>/<file type>/<tag>.<file>.<incarnation>
-
<group> : Disk group 이름
-
<dbname> : 파일이 속해 있는 데이터베이스 이름
-
<file type> : 오라클 파일 type
-
<tag> : 데이터파일에 대한 테이블스페이스와 같은 특수 정보
-
<file>.<incarnation> : 유일성 보장을 위한 File과 Incarnation 정보
-
예제 : +dgroupA/db1/controlfile/CF.257.8675309
■ Numeric ASM Filenames
존재하고 있는 ASM File을 참조하기 위한 형태이다. 이는 Disk group 이름, 파일 number, 그리고 incarnation number로 구성된다. ASM은 파일 생성 시 파일/Incarnation number를 내부적으로 사용하기 때문에, 이 형태는 파일 생성 시 사용될 수 없다.
이 형태는 Fully qualified name 형태에서 유추되며, 사용자에게 공개되지 않는다. 다만, 존재하는 파일을 참조하기 위한 API를 통해 사용 가능하다.
-
예제 : +dgroupA.257.8675309
■ Alias ASM Filenames
이 형태는 기존의 ASM File을 참조할 뿐만 아니라 새로운 ASM File을 생성할 때에도 사용될 수 있다. 파일과 Incarnation 숫자를 지정하지 않고, 단지 Disk group 이름과 사용자가 임의로 지정하는 문자열로 이뤄진다. 즉, DBA가 자신이 구별하기 쉽도록 파일 참조정보를 지정할 수 있는 것이다.
Alias Filename은 ‘/’ 문자를 가지는 Directory 구조를 사용한다. 이름을 이루는 각 항목들은 UTF-8 format을 따르며 48 byte 이상이 될 수 없다. 또한, 모든 항목이 포함하는 문자열은 256 byte를 넘을 수 없다. 문자열 사이에 space 문자를 넣을 수 있으나, 대소문자를 구별한다는 것을 유념해야 한다.
예제1 : +dgroupA/myfiles/control_file1
예제2 : +dgroupA/A rather LoNg and WeiRd name/for a file
ASM File은 파일 생성 시 Fully qualified name 형태를 따른다. DBA는 이때 alias를 사용하여 파일을 생성할 수도 있고, 추후 ‘ALTER DISKGROUP ADD ALIAS’ 명령어로 파일을 만들 수 있다.
■ Alias ASM Filenames with template
오직 ASM File을 생성할 때에만 사용되는 형태이다. 이는 Disk group 이름, alias 이름, 그리고 파일에 대한 Template 이름으로 구성된다. 파일 생성시 이러한 형태가 지정되고, alias가 존재하는 파일을 가리킨다면 Template은 무시된다.
-
예제 : +dgroupA/config1(spfile)
■ Incomplete ASM Filenames
파일 생성시에만 사용되는 형태이다. Disk group 이름만으로 구성한다. 이를 위해, ASM은 해당 파일의 type이 정의되어 있는 Default template을 사용한다.
예제 : +dgroupA
■ Incomplete ASM Filenames with template
파일 생성시에만 사용되는 형태이다. Disk group 이름과 Template 이름으로 조합된다. Template은 파일에 적용되어질 여러 가지 성질을 결정하게 된다.
예제 : +dgroupA(datafile)
이상의 ASM Filename 6개의 형태는 아래와 같은 범주로 나눠볼 수 있다.
그림. ASM Filenames
Allocation Unit(AU)
AU는 Disk group 내에서 저장영역을 할당하고자 할 때 사용하는 기본적인 단위/개념이다. ASM Disk내에서 가용한 공간은 AU 크기의 배수가 되는 것이다. ASM Disk의 header에는 이러한 AU에 대한 정보를 포함하고 있는 테이블이 존재한다.
_ASM_AUSIZE에 의해 변경하지 않는 이상, 기본적으로 AU는 1MB 이다. 이 크기는 하나의 ASM File이 여러 Disk에 골고루 분산되어 저장될 수 있을 정도로 작은 크기일 뿐만 아니라, 하나의 I/O operation에 의해 처리되는 하나의 AU가 좋은 처리량을 보장할 수 있을 정도로 충분히 큰 크기로 생각되는 것이 일반적이다(Oracle SAME 방법론 참조). 또한, AU을 접근하는 시간은 AU가 시작되는 곳을 찾아가는 seek time 보다, Disk의 전송속도에 지대한 영향을 받는다. Disk group에 대한 Rebalancing 작업은 이 AU 단위로 처리된다.
ASM Rebalancing
Disk가 추가/삭제 또는 크기조정이 일어날 때, Disk group은 모든 Storage에 대한 load를 균등히 하기 위해 rebalancing 작업을 수행한다. Rebalancing은 I/O load에 대한 통계정보에 근거하여 수행되지 않는다. 다만, Disk group에 포함되는 Disk의 크기를 기준으로 해당 작업을 수행하는 것이다. 이 작업은 Storage의 구성정보가 변경될 때 자동적으로 수행되며, DBA에 의해 수동으로 발생될 수 있다(사실 수동 작업은 필요 없다).
Thank you for the wonderful post
좋은 정보 감사합니다.