I. 오라클 데이터베이스
II. 데이터베이스 구성
III. 데이터베이스 구조
1) Instance구조
• 메모리 구조
৹ SGA
① Shared Pool
② Database Buffer Cache
③ KEEP 버퍼 풀 및 RECYCLE 버퍼 풀
④ Redo Log Buffer
⑤ Large Pool
⑥ Java Pool 및 Streams Pool
৹ PGA
① Stack Space
② UGA
▫ User Session Data
▫ Cursor State
▫ Sort Area
▫ Dedicated Server
▫ Shared Server
• 프로세스 구조
৹ 서버 프로세스
৹ 백그라운드 프로세스
① DBWn(데이터베이스 기록자 프로세스)
② LGWR(로그 기록자 프로세스)
③ CKPT(체크포인트 프로세스)
④ SMON(시스템 모니터 프로세스)
⑤ PMON(프로세스 모니터 프로세스)
⑥ RECO(복구자 프로세스)
⑦ ARCn(아카이버 프로세스)
2) Database 저장 영역 구조
• Data File
• Comtrol File
• Prameter File
• Password File
• 백업 파일
• 온라인 리두 로그 파일
• 아카이브 된 리두 로그 파일
• Trace file
• Alert Log File
3) 논리적 및 물리적 데이터베이스 구조
• 데이터베이스, 테이블스페이스 및 데이터 파일
• 테이블스페이스
• 데이터 블록
• Extent
• 세그먼트
৹ 데이터 세그먼트
৹ 인덱스 세그먼트
৹ 언두 세그먼트
৹ 임시 세그먼트
IV. ASM ( 자동 저장 영역 관리)
1) ASM
2) ASM 저장 영역 구성 요소
I. 오라클 데이터베이스
• Database란 데이터를 저장하는 보관소를 의미합니다
• Oracle은 DataBase Management System(DBMS)이라는 분야의 한 종류입니다
• Oracle RDBMS(관계형 데이터베이스 관리 시스템)는 다중 유저 환경에서 많은 양의 데이터를 안정적으로 관리하여
다수의 유저가 동일한 데이터에 동시에 액세스 할 수 있도록 합니다.
II. 데이터베이스 구성
• 각 데이터베이스 Instance는 단 한 개의 데이터베이스와만 연관됩니다
• 동일 서버에 데이베이스가 여러 개 있는 경우 각 데이터베이스마다 별개의 고유한 데이터베이스 Instance가 존재합니다
• 데이터베이스 Instance는 공유될 수 없습니다.
• RAC(Real Applications Cluster) 데이터 베이스에는 일반적으로 여러 개별 서버에 동일 공유 데이터베이스에 대한
여러 Instance가 포함됩니다
• RAC 모델에서는 동일한 데이터베이스가 각 RAC Insatance와 연관되어 하나의 Instance에 대해 최대 하나의 데이터베이스만
연관시켜야 하는 필요조건을 충족시킵니다.
III. 데이터베이스 구조
1) Instance의 구조
• 인스턴스는 메모리 영역과 백그라운드 프로세스 영역으로 나뉘어 있습니다
• 메모리 영역은 공유메모리 영역인 SGA와 프로세스 전용 메모리 영역인 PGA로 나뉘어 있습니다
• 백그라운드 프로세스는 공유 메모리 관리등 내부적인 작업을 수행하여 서버 프로세스를 지원하고, DBWn,
CKPT, SMON, PMON, LGWR 등이 있습니다.
• 메모리 구조
• 오라클 데이터베이스는 다양한용도로 메모리 구조를 생성 및 사용하는데 메모리에는 실행 중인 프로그램 코드,
유저 간에 공유되는 데이터 및 각 연결된 유저의 전용 데이터 영역이 저장됩니다.
৹ SGA
• 하나의 오라클 데이터베이스 Instance의 데이터 및 제어 정보를 포함하는 공유 메모리 구조(SGA 구성요소)의 그룹입니다
• SGA는 모든 서버 및 백그라운드 프로세스에서 공유됩니다.
① Shared Poo
• SGA의 Shared Pool 부분에는 라이브러리 캐시, 데이터 딕셔너리 캐시, SQL Query 결과 캐시, PL/SQL 함수 결과
캐시, 병렬 실행 메시지의 버퍼 및 제어 구조가 포함됩니다
• 데이터 딕셔너리는 데이터베이스, 해당 구조 및 유저에 대한 참조 정보를 포함하는 데이터베이스 테이블 및
뷰 모음입니다.
• SQL문 구문 분석 중에 데이터 딕셔너리를 자주 액세스하고 지속적으로 작업을 수행하려면 이와 같은 액세스가
반드시 필요합니다.
• 데이터베이스가 데이터 딕셔너리에 자주 액세스하므로 메모리에 있는 두 곳의 특수한 위치에 딕셔너리 데이터를
보관하도록 지정하는데 그중 한 영역이 데이터 딕셔너리 캐시이며, 전체 데이터 블록을 보관하는 버퍼 대신
데이터를 행으로 보관하므로 행 캐시라고 도 합니다
• 딕셔너리 데이터를 보관하는 메모리의 다른 한 영역은 라이브러리 캐시입니다
• User Process는 데이터 딕셔너리 정보 액세스를 위해 이 두 캐시를 공유합니다
• 데이터베이스에서 실행하는 각 SQL문을 공유 SQL 영역으로 나타내고, 두 유저가 같은 SQL문을 실행하는 경우
해당 유저에 대해 공유 SQL 영역을 재사용합니다.
• 공유 SQL 영역에는 지정된 SQL 문에 대해 구문 분석 트리 및 실행 계획이 포함됩니다.
• 오라클 데이터베이스는 로컬 변수, Global 변수, 패키지 변수 (패키지 인스턴스)를 포함한 프로그램 단위를
실행하는 세션 및 SQL 실행을 위한 버퍼와 관련된 값을 보관하기 위한 전용 영역을 할당합니다.
• 여러 유저가 동일한 프로그램 단위를 실행하는 경우 모든 유저에게 단일 공유 영역이 사용되며, 모든 유저는
자신의 고유 세션에 특정된 값이 보관된 고유한 전용 SQL 영역의 개별 복사본을 유지 관리합니다
• Query 결과 및 Query 부분의 SQL Query 결과 캐시의 메모리에서 캐시에 저장될 수 있고, 데이터베이스가
캐시 된 결과를 사용하여 이러한 Query 및 Query 부분의 향후 실행을 수행할 수 있습니다.
• Shared Pool의 고정된 영역은 SGA에 대한 시작 오버헤드를 나타내고, 크기는 일반적으로 크기가 지정된
Shared Pool 또는 SGA에 비해 매우 작습니다.
② Database Buffer Cache
• 데이터 파일에서 읽거나 읽기 일관성 모델을 만족시키기 위해 동적으로 생성된 블록 이미지를 보관하는 SGA의
일부로 Instance에 동시에 연결하는 모든 유저는 데이터베이스 버퍼 캐시에 대한 액세스를 공유합니다
• 특정 데이터를 처음 사용해야 하는 경우 데이터베이스 버퍼 캐시의 데이터를 검색하고 프로세스에서 캐시에 이미
있는 데이터를 발견하는 경우 메모리에서 데이터를 직접 읽어올 수 있습니다
• 프로세스가 캐시의 데이터를 발견하지 못하면 데이터 액세스를 하기 전에 데이터 블록을 디스크의 데이터 파일에서
캐시의 버퍼로 복사해야 합니다.
• 데이터베이스 버퍼 메모리에 데이터가 있는 경우 디스크에서 데이터를 읽어 오는 것보다 훨씬 빠릅니다.
• 캐시의 버퍼는 LRU(Lest Recently Used) List와 접근 횟수의 조합을 사용하는 조합을 사용하는 복합 알고리즘에
의해 관리되고, LRU는 디스크 액세스를 최소화하기 위해 최근에 사용된 블록이 메모리에 유지되도록 보장합니다.
③ KEEP 버퍼 풀 및 RECYCLE 버퍼 풀
• KEEP 버퍼 풀은 LRU가 일반적으로 버퍼를 보유하는 것보다 오랫동안 메모리에 버퍼를 보유하도록 설계되었습니다
• RECYCLE 버퍼 풀은 일반적으로 LRU가 버퍼를 비우는 것보다 빠르게 버퍼를 메모리에서 비울 수 있도록 설계되었습
니다.
④ Redo Log Buffer
• 데이터베이스에 대한 변경 사항 관련 정보가 포함된 SGA의 순환 버퍼입니다
• 리두 항목은 DML, DDL 또는 내부 작업에 의해 데이터베이스에 수행된 변상 사항을 재생성하는 데 필요한
정보를 포함합니다
• 필요한 경우 리두 항목은 데이터베이스 Recovery에 사용됩니다
• 서버 프로세스가 버퍼 캐시에 변경 사항을 적용할 때 리두 항목이 생성되고 SGA의 리두 로그 버퍼에 기록됩니다
• 로그 기록자 백그라운드 프로세스는 리두 로그 버퍼를 디스크의 활성 리두 로그 파일에 기록합니다.
⑤ Large Pool
• DBA는 다음을 위한 대규모 메모리 할당을 제공하기 위해 Large Pool이라는 선택적 메모리 영역을 구성할 수 있습니다
▫ Shared Server 및 Oracle XA 인터페이스용 세션 메모리
▫ I/O 서버 프로세스
▫ 오라클 데이터베이스 백업 및 복원 작업
▫ Parallel Query 작업
▫ Advanced Queuing 메모리 테이블 저장 영역
• Shared Server, Oracle XA 또는 Parallel Query 버퍼에 대해 Large Pool에서 세션 메모리를 할당함으로써
오라클 데이터베이스는 기본적으로 공유 SQL을 캐시에 저장하는데 Shared Pool을 사용할 수 있으며,
공유 SQL 캐시를 축소하면 발생하는 성능 오버해드를 방지할 수 있습니다
• 백업 및 복원 작업, I/O 서버 프로세스 및 병렬 버퍼에 사용되는 메모리는 크기가 수백 KB인 버퍼에서 할당됩니다
• Large Pool 은 LRU List로 관리되지 않습니다.
⑥ Java Pool 및 Streams Pool
• Java Pool 메모리는 JVM의 모든 세션별 Java 코드 및 데이터를 저장하는 데 사용되며, 오라클 데이터베이스를
실행 중인 모드에 따라 다른 방식으로 사용됩니다
• Java Pool은 Java로 만들어진 프로그램을 사용할 경우 반드시 설정해야 하고 JAVA_POOL_SIZE 파라미터를 통해
설정할 수 있습니다.
• Streams Pool은 Oracle Streams 전용으로 사용되며, 버퍼링 된 큐 메시지를 저장하고 Oracle Streams 캡처
프로세스 및 적용 프로세스에 대해 메모리를 제공합니다
• Streams Pool을 별도로 구성하지 않으면 크기는 0에서 시작하며 Oracle Streams가 상용될 때 필요에 따라
동적으로 커집니다.
৹ PGA
• PGA는 서버 또는 백그라운드 프로세스를 시작할 때 오라클 데이터베이스에서 생성되는 비공유 메모리입니다
• PGA는 서버 프로세스에 대한 데이터 및 제어 정보를 포함하는 전용 메모리 영역으로 각 서버 프로세스에는 고유한
PGA 영역을 갖고 있습니다
• PGA에 대한 액세스는 해당 서버 프로세스에 배타적이며 대신 작업을 수행하는 Oracle 코드에 의해 서만 읽힙니다
① Stack Space
• SQL문장에 Bind 변수를 사용할 때 이를 저장하는 공간입니다.
② UGA
▫ User Session Data
• 추출된 결과 값을 전달하기 위해 유저 프로세스의 세션 정보를 저장합니다. 그리고 SQL문 결과를 유저
프로세스에게 전달하고자 유저 세션 주소를 저장하고 있습니다.
▫ Cursor State
• 해당 SQL의 파싱 정보가 기록되어 있는 주소를 저장합니다. 실행한 SQL문의 위치입니다.
▫ Sort Area
• 정렬할 때 사용하는 공간입니다. SQL의 작업 공간이며 가장 많은 공간을 할당해야 합니다.
▫ Dedicated Server
• User Session Data, Cursor State, Sort Area 영역을 직접 PGA 공간에 저장합니다.
▫ Shared Server
• User Session Data 영역을 SGA에 저장합니다.
• 프로세스 구조
৹ 서버 프로세스
• 서버 프로세스는 Instance에 연결된 클라이언트의 요청을 처리합니다
• 유저 프로세스로부터 SQL 수신 및 실행합니다.
- SQL 파싱 ( 옵티마이저를 통한 실행 계획 생성 포함)
- SQL 결과 회신
• 데이터 파일의 데이터 블록을 버퍼 캐시로 적재합니다
• 데이터 변경 시 리두 로그 버퍼에 기록합니다.
৹ 백그라운드 프로세스
① DBWn(데이터베이스 기록자 프로세스)
- 데이터베이스 버퍼 캐시의 더티 버퍼를 디스크에 기록합니다
- 시스템에서 데이터를 많이 수정하는 경우에는 기록 성능을 개선하기 위해 추가 프로세스를 구성할 수 있습니다
- 데이터베이스 버퍼 캐시의 버퍼는 수정되면 더티로 표시되며 SCN 순서로 보관되는 상위 체크포인트 큐에 추가됩니다
- SCN 순서는 변경된 버퍼에 대한 리두 로그에 기록되는 리두 순서와 일치합니다
- 테이블 스페이스가 읽기 전용으로 설정되거나 오프라인으로 전환되는 등의 경우에도 기록을 수행할 수 있습니다
- DB_WRITER_PROCESSES 초기화 파라미터는 DBWn 프로세스 수를 지정하고 프로세스의 최대 수는 36개입니다
- DBWn 프로세스는 다음과 같은 경우에 더티 버퍼를 디스크에 기록합니다
▫ 서버 프로세스가 버퍼를 임계값 수만큼 스캔한 후에 재사용 가능한 클린 버퍼를 찾지 못하면 DBWn에 기록을
수행하라는 신호를 보내면 DBWn은 다른 처리를 수행하면서 더티 버퍼를 디스크에 비동기 방식으로 기록합니다
▫ DBWn은 버퍼를 기록하여 Insatance Recovery가 시작되는 리두 스레드의 위치인 체크포인트를 전진시키고
이 로그 위치는 버퍼 캐시의 가장 오래된 더티 버퍼에 의해 결정됩니다
▫ 어떤 경우에든 DBWn은 효율성을 개선하기 위해 일괄 처리된(다중 블록) 쓰기를 수행하고, 다중 블록 쓰기에서
기록되는 블룩 수는 운영 체제에 따라 다릅니다
② LGWR(로그 기록자 프로세스)
- 리두 로그 버퍼 항목을 디스크의 리두 로그 파일에 기록하여 리두 로그 버퍼를 관리하며, 마지막으로 기록된 이후
버퍼로 복사된 모든 리두 항목을 기록합니다
- 리두 로그 버퍼는 일종의 순환 버퍼이므로 LGWR가 리두 로그 버퍼의 리두 리두 항목을 리두 로그 파일에 기록하면
서버 프로세스가 새 항목을 복사하여 디스크에 기록된 리두 로그 버퍼의 항목을 겹쳐 쓸 수 있습니다
- LGWR는 아래의 경우 기록합니다
▫ User Process가 트랜잭션을 커밋할 때
▫ 리두 로그 버퍼가 1/3 찼을 때
▫ DBWn 프로세스가 수정된 버퍼를 디스크에 기록하기 전에 (필요한 경우에 기록합니다)
▫ 3초마다
③ CKPT(체크포인트 프로세스)
- 데이터베이스의 리두 스레드에 SCN(시스템 변경 번호)을 정의하는 데이터 구조로, 컨트롤 파일 및 각 데이터 파일
헤더에 기록되는 Recovery의 필수 요소입니다.
- 체크포인트가 발생할 경우 오라클 데이터베이스는 모든 데이터 파일의 헤더를 갱신하여 체크포인트의 세부 사항을
기록해야 하는데 이 작업은 CKPT 프로세스에 의해 수행됩니다
④ SMON(시스템 모니터 프로세스)
- 시스템 레벨 관점으로 일을 바라보며 데이터베이스를 위한 가비지 컬렉터 역할을 수행합니다
- SMON은 필요한 경우 Insatance가 시작될 때 Recovery를 수행하며 더 이상 사용하지 않는 임시 세그먼트도
정리합니다
- 파일 읽기 또는 오프라인 오류로 인해 Instance Recovery 도중에 종료된 트랜젝션을 건너뛰는 경우
테이블스페이스나 파일이 다시 온라인으로 전환되면 SMON이 이를 Recovery 합니다
⑤ PMON(프로세스 모니터 프로세스)
- User Process가 실패할 경우 프로세스 Recovery를 수행하고, 데이터베이스 버퍼 캐시를 정리하며,
User Process에서 사용하던 리소스를 해제합니다
- PMON은 활성 트랜젝션 테이블의 상태를 재설정하고 Lock을 해제하며 활성 프로세스 리스트에서 프로세스 ID를
제거합니다
- PMON은 정기적으로 디스패치와 서버 프로세스의 상태를 확인하여 실행이 정지된 경우 이를 재시작하고, Instance
및 디스패처 프로세스에 대한 정보도 네트워크 리스너에 등록합니다
⑥ RECO(복구자 프로세스)
- RECO는 분산 트랜잭션과 관련된 Failure를 자동으로 해결하는 분산 데이터베이스 구성에 사용되는 백그라운드
프로세스입니다
- Instance의 RECO 프로세스는 In-Doubt 분산 트랜잭션과 관련된 다른 데이터베이스에 자동으로 연결됩니다
- RECO 프로세스는 관련 데이터베이스 서버 간의 연결을 재설정할 때 모든 In-Doubt 트랜잭션을 자동으로 해결하여
각 데이터베이스의 보류 트랜잭션 테이블에서 해결된 In-Doubt 트랜잭션에 해당하는 모든 행을 제거합니다
⑦ ARCn(아카이버 프로세스)
- 로그 수위치가 발생한 후에 리두 로그 파일을 지정된 저장 장치로 복사합니다.
- ARCn 프로세스는 데이터베이스가 ARCHIVELOG 모드이며 자도 아카이브가 활성화되어 있을 때만 표시됩니다
- 데이터 대량 로드 시와 같이 아카이브 할 작업 로드가 많을 것으로 예사오디면 아카이브 프로세스의 최대수를
늘릴 수 있습니다
- LOG_ARCHIVE_MAX_PROCESSES 파라미터를 통해 동적으로 프로세스 개수를 변경할 수 있습니다.
- 아카이브 프로세스의 기본값은 4개입니다.
2) Database의 구조
৹ Data File
- 데이터파일은 데이터가 저장되는 파일입니다
- 데이터베이스의 유저 또는 응용 프로그램 데이터, 메타 데이터 및 데이터 딕셔너리를 포함합니다
- 서버 프로세스가 파일을 읽어 메모리로 올리면 메모리에서 변경된 데이터는 DBWn에 의해 데이터 파일에 반영하여 시스템
장애 시에도 데이터를 보존할 수 있습니다.
৹ Control File
- 데이터베이스 자체에 대한 데이터를 포함하고, 리두 로그 및 데이터 파일의 위치 정보, 백업과 관련된 메타 데이터를
포함하고 있습니다
- 컨트롤 파일에 저장되는 정보는 아래와 같습니다
▫ 리두 로그 및 데이터 파일에 대한 위치정보
▫ 체크포인트 발생 정보
▫ 데이터베이스의 이름
▫ 리두 로그 이력
▫ RMAN의 백업 정보
৹ Prameter File
- Instance가 시작될 때 Instance의 구성에 필요한 설정들에 대한 파라미터 값이 저장되어 있는 파일입니다
- 파라미터 파일의 종류는 아래와 같습니다
▫ 서버 파라미터 파일 : SPFILE
- 파일이 데이터베이스 서버에 위치해야 합니다
- 바이너리 파일로 수정을 위해서는 ALTER SYSTEM 명령어를 사용해야 합니다
- 자동메모리 관리 시 메모리 정보가 저장되어 재시작 시 반영됩니다
▫ 텍스트 초기화 파라미터 파일: PFILE
- 텍스트 파일로 vi 에디터를 통해 수정합니다
- 동적으로 변경 가능한 파라미터는 종류와 상관없이 운영 중에 변경이 가능합니다
- PFILE은 재시작 시 반영을 위해 데이터를 통해 수정하는 작업이 필요합니다.
৹ Password File
- sysdba, sysoper 및 system럴이 Instance에 원격으로 연결하여 관리 작업을 수행할 수 있도록 합니다.
৹ 백업 파일
- 데이터베이스 Recovery에 사용되는 파일로 일반적으로 Media Failure 또는 User Error로 원본 파일이 손상되거나
삭제되었을 경우 복원합니다.
৹ 온라인 리두 로그 파일
- 데이터베이스 서버가 손상되었지만 해당 데이터 파일은 손실되지 않은 경우 Instance는 이러한 파일 안에 있는 정보를
사용하여 데이터베이스를 Recovery 할 수 있습니다
- 파일을 재 사용하는 순환구조를 사용하며 영구 보존을 위해서는 별도의 파일로 백업하는 과정이 필요합니다
৹ 아카이브 된 리두 로그 파일
- Instance에 의해 생성되는 데이터 변경에 대한 기록을 지속적으로 포함합니다
- 이카이브 로그는 복원된 데이터 파일의 Recovery를 가능하게 합니다.
৹ Trace file
- 각 서버와 백그라운드 프로세스는 연관된 Trace File에 정보를 기록할 수 있습니다
- 내부 오류가 프로세스에서 감지되면 프로세스는 오류에 대한 정보를 해당 Trace File에 덤프 합니다
৹ Alert Log File
- 특수 Trace 항목으로 데이터베이스의 Alter Log에는 메시지와 오류가 시간순으로 기록되어 있습니다.
3) 논리적 및 물리적 데이터베이스 구조
৹ 데이터베이스, 테이블스페이스 및 데이터 파일
- 각각의 데이터베이스는 논리적으로 두 개 이상의 테이블 스페이스로 나뉩니다
- 테이블 스페이스가 테이블 스페이스에 있는 모든 세그먼트의 데이터를 물리적으로 저장할 수 있도록 하나 이상의
데이터 파일이 명시적으로 생성됩니다
- TEMPORARY 테이블 스페이스인 경우 데이터 파일 대신 임시 파일이 포함됩니다
- 테이블 스페이스의 데이터 파일은 지원되는 모든 저장 기술을 사용해서 물리적으로 저장할 수 있습니다
৹ 테이블스페이스
- 데이터베이스는 테이블스페이스라는 논리적 저장 영역을 단위로 나뉘어 관련된 논리적 구조 또는 데이터 파일을
함께 그룹화합니다.
৹ 세그먼트
- Extent 다음 벨의 논리적 데이터베이스 저장 영역은 세그먼트입니다
- 세그먼트는 특정 논리적 구조에 할당된 일련의 Extent입니다
① 데이터 세그먼트
- 클러스터화 되지 않은 각각의 비인덱스 구성 테이블에는 데이터 세그먼트가 있지만, Extermal Table,
Global Temporary Table, Partition Table은 예외입니다
- 테이블 데이터는 모두 해당 데이터 세그먼트의 Extent에 저장됩니다
- Partition Table의 경우 각 Partition은 데이터 세그먼트를 가집니다
- 각 클러스터는 데이터 세그먼트를 가지고 클러스터에 있는 모든 테이블의 데이터는 클러스터의 데이터
세그먼트에 저장됩니다.
② 인덱스 세그먼트
- 각 인덱스는 해당 데이터를 모주 저장하는 인덱스 세그먼트를 가집니다
- Partition 인덱스의 경우 각 Partition은 인덱스 세그먼트를 가집니다
③ 언두 세그먼트
- 각 데이터베이스 Instance당 하나의 UNDO 테이블 스페이스가 생성됩니다
- 테이블 스페이스에는 언두 정보를 임시로 저장하기 위한 다수의 언두 세그먼트가 포함되어 있습니다
- 언두 세그먼트의 정보는 데이터베이스 Recovery 중 유저에게 커밋되지 않은 트랜잭션을 롤백하기 위해 읽기
일관성 데이터베이스 정보를 생성하는 데 사용됩니다
④ 임시 세그먼트
- SQL 문에서 실행을 완료할 임시 작업 영역이 필요할 때 오라클 데이터베이스에 의해 생성됩니다
- 명령문의실행이 완료되면 나중에 사용할 수 있도록 임시 세그먼트의 Extent가 Instance로 반환됩니다
৹ Extent
- 데이터 블록 다음 레벨의 논리적 데이터 베이스 공간은 Extent입니다
- Extent는 단일 할당을 얻은 일정 수의 연속적인 오라클 데이터 블록으로, 특정 유형의 정보를 저장하는 데 사용됩니다
- Extent에 있는 데이터블록은 논리적으로 연속된 데이터이지만 RAID 스트라이핑 및 파일 시스템 구현으로 인해
물리적으로는 디스크에 분산되어 있을 수 있습니다
৹ 데이터 블록
- 가장 작은 레벨에서 오라클 데이터베이스의 데이터는 데이터 블록에 저장됩니다
- 하나의 데이터 블록은 디스크에서 특정 바이트 수의 물리적 공간에 해당합니다
- 데이터 블록 크기는 생성 시 각 테이블 스페이스에 대해 지정됩니다
- 데이터베이스는 사용 가능한 데이터베이스 공간을 Oracle 데이터 블록으로 사용 및 할당합니다.
IV. ASM ( 자동 저장 영역 관리)
1) ASM
- 오라클 데이터베이스 파일을 위한 볼륨 관리자와 파일 시스템의 수직 통합을 제공합니다
- ASM은 단일 SMP 시스템의 관리 기능이나 Oracle RAC 지원을 위해 클러스터의 여러 노드 간에 관리 기능을 제공합니다
- 사용 가능한 모든 리소스에 I/O 로드를 분산하여 성능을 최적화하면서 수도 I/O 튜닝의 필요성도 제거 합니다
- ASM을 통해 DBA는 저장 영역 할당을 조정할 때 데이터베이스를 종료하지 않고 데이터베이스 크기를 늘리도록 허용함으로써
동적 데이터베이스 환경을 관리할 수 있습니다
- ASM은 결함 발생 시 대처할 수 있는 데이터의 중보 사본을 관리할 수 있으며 업체에서 공급한 신뢰할 수 있는 자장 영역
메커니즘의 최상위에 ASM을 구축할 수 있습니다
- 데이터 관리는 파일별로 하나하나 유저가 상호 작용하는 것이 아니라 데이터 클래스에 대해 원하는 신뢰성 및 성능 특성을
선택하여 수행합니다
- ASM 기능은 수동 저장 영역을 자동화함에 따라 더욱 많은 대규모 데이터베이스르 보다 향상된 효율성으로 관리할 수 있도록
합니다
2) ASM 저장 영역 구성 요소
- ASM은 기존 데이터베이스 기능을 제거하지 않고 기존의 데이터베이스는 평상시대로 작동할 수 있습니다
- 새 파일은 ASM 파일로 생성하고 기존 파일은 이전 방식으로 관리하거나 ASM으로 이전할 수 있습니다
- 데이터 파일은 파이 시스템 또는 ASM 파일의 운영 체제에 저장된 파일과 일 대 일 관계를 갖습니다
- ASM 디스크 그룹은 논리적 단위로 관리되는 하나 이상의 ASM 디스크의 모음입니다
- 각 ASM 디스크는 ASM이 할당하는 가장 작은 연속된 디스크 공간인 여러 ASM 할당 단위로 나뉩니다
- ASM 디스크 그룹을 생성하면 디스크 그룹의 호환성 레벨에 따라 ASM 할당 단위 크기를 1, 2, 4, 8, 16, 32 또는 64MB로
설정할 수 있습니다
'ORACLE > 아키텍처' 카테고리의 다른 글
| 네트워크 환경 (0) | 2023.09.18 |
|---|---|
| Dynamic Performance 뷰 와 데이터 딕셔너리 (0) | 2023.09.18 |
| 데이터베이스 시작 및 종료 (0) | 2023.09.18 |
