ORACLE의 구조 및 주 구성 요소에 대해 이해 (9버전 참고 내용)
* 오라클의 주요 구성요소
- Oracle 서버 : Oracle 서버에는 여러 파일 및 프로세스가 있지만 이 모두가 SQL문을 처리 하기 위해 있는 것이 아님. 그 중 일부는 데이터베이스 성능을 향상시키거나, 소프트웨어 또는 하드웨어 오류 발생시 데이터 베이스를 복구 및 데이터 베이스의 유지 관리 하는데 필요한 작업을 수행. Oracle 서버는 인스턴스와 데이터베이스로 구성
- Oracle 인스턴스 : 인스턴스는 백그라운드 프로세스와 메모리 구조의 조합으로 데이터베이스의 데이터를 액세스 하려면 인스턴스가 시작되어야 함. 인스턴스가 시작될 때마다 SGA(System Global Area)가 할당이 되고 Oracle 백그라운드 프로세스가 시작. 백그라운드 프로세스는 프로세스를 호출하기 위한 기능을 수행. 백그라운드 프로세스를 사용하여 각 사용자가 실행하는 여러 Oracle 프로그램으로 처리해야 할 기능을 통합가능. 백그라운드 프로세스는 I/O을 수행하고 다른 Oracle 프로세스를 모니터하여 병렬화를 높임으로써 성능 및 신뢰도를 향상 시킴
- Oracle 데이터베이스 : 데이터베이스 정보를 위한 실제적인 물리적 저장 영역을 제공하는 운영 체제 파일(데이터베이스 파일이라고도 함)로 구성. 데이터베이스 파일은 데이터를 일관성 있게 유지하고 인스턴스가 실패한 경우 데이터를 복구하는 데 사용.
- 기타 키 파일 : 비 데이터베이스 파일은 인스턴스를 구성하고 권한이 있는 사용자를 인증하며 디스크 고장 시 데이터베이스를 복구하는 데 사용
- 사용자 프로세스 및 서버 프로세스 : SQL 문이 실행 될 때 사용되는 기본 프로세스이지만 그 밖의 여러 프로세스가 Oracle 서버에서 SQL 문의 처리를 마칠 수 있도록 도와줌
- 기타 프로세스 : 그 밖에도 여러 프로세스가 고급 대기열 처리, Real Application Clusters, 공유서버, 고급 복제와 같은 옵션에 사용.
-----------------------------------------------------------------------------------------------------------
* Oracle 서버
- 데이터베이스 서버는 정보를 관리하는 데 핵심적인 역할을 수행. 일반적으로 서버는 다중 사용자 환경에서 많은 양의 데이터를 안정적으로 관리하여 여러 사용자가 동일한 데이터에 동시에 액세스 할 수 있게 해야 하지만 이러한 작업으로 인해 성능이 저하되는 일은 없어야 함. 또한 권한 없는 액세스를 방지하고 실패 복구를 위한 효율적인 해결책을 제공해야 함
* Oracle 인스턴스
- 인스턴스는 SGA(시스템 글로벌 영역) 메모리 구조와 데이터베이스 관리에 사용되는 백그라운드 프로세스로 구성. 인스턴스는 각 운영 체제에 지정된 방식에 따라 다름. 인스턴스는 한 번에 하나씩 데이터베이스를 열어 사용 가능.
* 접속 설정 및 세션 생성
- 사용자가 SQL문을 오라클 데이터베이스에 보내려면 인스턴스에 접속 해야 함.
> SQL*Plus와 같은 툴을 시작하거나, Oracle Forms 등의 툴을 사용하여 개발된 응용 프로그램을 실행. 이러한 응용 프로그램이나 툴은 사용자 프로세스로 실행
> 대부분의 기본 구성에서는 사용자가 Oracle 서버에 로그인 할 때 Oracle 서버를 실행 중인 시스템에서 프로세스가 생성되는 데 이 프로세스를 서버 프로세스라고 함. 서버 프로세스는 클라이언트에서 실행되는 사용자 프로세스 대신 Oracle 인스턴스와 통신하며 사용자 대신 SQL문을 실행
접속
- 접속은 사용자 프로세스와 Oracle 서버 간의 통신 경로로서 데이터베이스 사용자는 다음 세 방법 중 하나로 Oracle 서버에 접속 할 수 있음.
* Oracle 인스턴스를 실행하는 운영 체제에 로그인하고 해당 시스템에 있는 데이터베이스를 액세스하는 응용 프로그램이나 툴을 시작. 통신 경로는 호스트 운영 체제에서 사용 가능한 프로세스 간의 통신 방식을 사용하여 설정
* 사용자는 지역 컴퓨터에 있는 응용 프로그램이나 툴을 시작한 다음 네트워크를 통해 Oracle 인스턴스를 실행하는 컴퓨터에 접속, 이러한 클라이언트 서버 구성에서는 네트워크 소프트웨어가 사용자와 Oracle 서버 간의 통신에 사용
* 3 계층 접속에서 사용자 컴퓨터는 네트워크를 통해 Oracle 인스턴스를 실행 중인 시스템에 있는 응용 프로그램이나 네트워크 서버와 통신. 예를 들면, 사용자가 네트워크에 접속된 컴퓨터에서 브라우저를 실행하여 Windows NT 서버에 설치되어 있는 응용프로그램을 사용하면 이 응용 프로그램이 UNIX 호스트에서 실행 중인 오라클 데이터베이스에서 데이터를 검색.
세션
- 세션이란 Oracle 서버에 특정 사용자가 접속하는 것으로 Oracle 서버에서 사용자를 검증할 때 시작되어 사용자가 로그아웃하거나 비정상적으로 종료 될 때 끝남. 데이터베이스 사용자가 여러 툴, 응용 프로그램 또는 터미널에서 동시에 로그인하면 여러 세션을 동시에 사용 가능. 일부 전문적인 데이터베이스 관리 툴을 사용할 때를 제외하고는 데이터베이스 세션을 시작하려면 Oracle 서버를 사용 할 수 있어야 함.
주:여기서 설명한 것과 같이 사용자 프로세스와 서버 프로세스 간에 일대일로 대응하는 접속을 전용 서버 접속이라고 함. 공유 서버 구성을 사용하면 여러 사용자 프로세스가 서버 프로세스를 공유 가능함.
오라클 데이터베이스
- 데이터베이스의 일반적인 용도는 관련 정보를 저장, 검색 하는 것이며 오라클 데이터베이스에는 논리적 구조와 물리적 구조가 있음. 데이터베이스의 물리적 구조란 데이터베이스에 있는 운영 체제 파일 집합을 말함. 오라클 데이터베이스는 다음 세가지 유형의 파일로 구성
* 데이터베이스의 실제 데이터가 포함된 데이터 파일
* 장애가 발생했을 때 데이터를 복구 할 수 있도록 데이터베이스의 변경 사항이 기록된 RedoLogfiles(리두로그파일)
* 데이터베이스 무결성을 유지 관리하고 확인하는 데 필요한 정보가 포함된 제어 파일
기타 키 파일 구조
- Oracle 서버는 데이터베이스에 속하지 않는 기타 파일도 사용
* 매개변수 파일에는 Oracle 인스턴스의 특성이 정의. 예를 들어, 이 파일에는 SGA에 있는 일부 메모리 구조의 크기를 지정하는 매개변수가 포함
* 암호 파일은 사용자가 Oracle 인스턴스를 시작하고 종료할 수 있다는 것을 인증
* Archived Log files(아카이브된 리두 로그 파일)은 매체 고장 시 복구하는데 필요한 리두 로그 파일의 오프라인 복사본임.
물리적 구조
- 오라클 데이터베이스의 물리적 구조에는 제어 파일, 데이터 파일 및 리두 로그 파일 등 세가지 파일 유형이 포함
SGA(시스템 글로벌 영역)
- SGA는 공유 글로벌 영역이라고도 하며 데이터베이스 프로세스에서 공유하는 데이터베이스 정보를 저장하는 데 사용. 여기에는 Oracle 서버를 위한 데이터 및 제어 정보가 포함되며 Oracle이 상주하는 컴퓨터의 가상 메모리에 할당
동적 SGA :
- 동적 SGA는 인스턴스를 종료하지 않고 SGA 구성을 변경할 수 있는 기반 구조를 구현. 따라서 인스턴스를 종료하지 않고 데이터베이스 버퍼 캐시 및 공유 풀의 크기를 변경할 수 있음. 데이터베이스 버퍼 캐시 및 공유 풀은 처음 구성이 계속 유지 되는 것이 아니라 작업 로드에 따라 최대 SGA_MAX_SIZE까지 늘어나거나 줄어 들 수 있음.
SGA 크기 조정 :
- SGA 크기는 여러 초기화 매개변수에 의해 결정. SGA 크기에 가장 많은 영향을 주는 매개변수는 다음과 같음
DB_CACHE_SIZE
: 표준 블록의 캐시 크기. 기본적으로 UNIX에서는 48MB이고 NT에서는 52MB
LOG_BUFFER
: 리두 로그 버퍼에 할당되는 바이트 수
SHARED_POOL_SIZE
: 공유 SQL 및 PL/SQL에 제공되는 영역의 바이트 크기. 기본적으로 16MB지만 64비트인 경우 기본 크기는 64MB
LARGE_POOL_SIZE
: 대용량 풀의 크기. 기본값은 0입니다. (init.ora 매개변수PARALLEL_AUTOMATIC_TUNING이 TRUE로 설정될 때를 제외하고는 기본값이 자동으로
계산)
JAVA_POOL_SIZE
: Java 풀의 크기. 기본값은 24MB
따라서 SGA 크기는 SGA_MAX_SIZE - DB_CACHE_SIZE - LOG_BUFFER –
SHARED_POOL_SIZE - LARGE_POOL_SIZE - JAVA_POOL_SIZE를 초과 불가.
그래뉼은 오라클에서 메모리에 데이터 할당시 사용하는 일정한 용량 단위(물리적 메모리 단위)
10gR2 기준, MAXSGA의 크기가 < 1G 이면 4M SGA 가 <1g 16m="" p="">
(10gR2 기준, Oracle 9i 이하에서 MAX SGA < 128 이면 4M MAXSGA >= 128 이면 16M로 구성
할당 단위
그래뉼은 연속적인 가상 메모리 할당 단위로 그레뉼 크기는 예상되는 총 SGA 크기에 따라 다르며, 이 크기는 SGA_MAX_SIZE 매개변수 값에 준하여 계산됨
* 예상 SGA 크기가 128MB보다 작은 경우에는 4MB
* 그 외의 경우에는 16MB
구성 요소(데이터베이스 버퍼 캐시 및 공유 풀)는 그래뉼 단위에 따라 늘어나거나 줄어듬. 그래뉼을 소유하는 각 구성 요소의 경우 구성 요소에 할당된 그래뉼 수, 구성 요소에 대한 보류 작업(예: ALTER SYSTEM을 통한 그래뉼 할당, ALTER SYSTEM을 통한 그래뉼 해제, 해당 자체 튜닝) 및 그래뉼 단위의 대상 크기는 V$BUFFER_POOL 뷰에 의해 추적되고 표시됨. 인스턴스가 시작 될 때 Oracle 서버는 각 그래뉼 마다 그래뉼 항목을 하나씩 할당하여 주소 공간의 SGA_MAX_SIZE 바이트를 지원. 시작이 계속 됨에 따라 각 구성 요소는 필요한 그래뉼을 모두 얻게 됨. SGA 구성의 최소 단위는 세 개의 그래뉼 즉, 각각 고정 SGA[리두 버퍼 포함], 데이터베이스 버퍼 캐시, 공유 풀을 위한 그래뉼
- 공유 풀 환경에는 고정 구조와 가변 구조가 모두 있음. 고정 구조는 비교적 동일한 크기를 유지 하는 반면 가변 구조는 사용자 및 프로그램 요구 사항에 따라 크기가 늘어나거나 줄어듬. 고정 구조와 가변 구조의 실제 크기 조정은 초기화 매개변수와 Oracle 내부 알고리즘 작업에 따라 달라짐.
공유 풀 크기 조정
- 공유 풀은 재사용 가능한 SQL 실행 계획(PL/SQL 패키지, 프로시저 및 함수)과 커서 정보와 같이 전역적으로 공유 할 수 있는 객체를 위해 사용되므로 고정 영역과 가변 영역 모두의 요구를 수용하도록 크기가 조정되어야 함. 공유 풀에 대한 메모리 할당은 초기화 매개변수 SHARED_POOL_SIZE에 의해 결정되며 ALTER SYSTEM SET을 사용하여 크기를 동적으로 조정 가능. 성능 분석 후에 크기를 조정 할 수 있지만 전체 SGA 크기는 SGA_MAX_SIZE를 초과 불가
라이브러리 캐시
- 라이브러리 캐시 크기는 공유 풀에 정의된 크기 조정에 따라 달라짐. 메모리는 명령문이 구문 분석되거나 프로그램 단위가 호출 될 때 할당. 공유 풀의 크기가 너무 작으면 명령문이 라이브러리 캐시로 계속 재로드되어 성능에 영향을 주게 됨. 라이브러리 캐시는 LRU 알고리즘에 의해 관리됨. 캐시가 채워지면 라이브러리 캐시에서 최근에 덜 사용된 실행경로와 구문 분석 트리가 제거되어 새 항목을 위한 여유 공간이 생성. 재사용되지 않는 SQL 문이나 PL/SQL 문은 삭제 됨.
라이브러리 캐시 구조
* 공유 SQL
: 공유 SQL은 데이터베이스에 대해 SQL 문을 실행하기 위한 실행 계획과 구문 분석 트리를 저장하고 공유. 다음에 동일한 SQL문을 실행 할 때는 공유 풀에 있는 구문 분석 정보를 잉요하여 신속하게 처리 할 수 있음. SQL문에서 필요 할 때마다 공유 SQL 영역을 사용 할 수 있게 하려면 텍스트, 스키마 및 바인드 변수가 동일 해야 함
* 공유 PL/SQL
: 공유 PL/SQL 영역은 최근에 실행된 PL/SQL 문을 저장하고 공유. 구문 분석되고 컴파일된 프로그램 단위와 프로시저(함수, 패키지 및 트리)는 이 영역에 저장
데이터 딕셔너리 캐시
- 데이터 딕셔너리 캐시는 딕셔너리 캐시 또는 행 캐시라고도 함. 데이터 딕셔너리 정보를 데이터베이스 버퍼 캐시 및 공유 풀 메모리에 다중 캐시하여 성능을 향상시킬 수 있음. 데이터베이스에 대한 정보(사용자 계정 데이터, 데이터 파일 이름, 세그먼트 이름, 확장 영역 위치, 테이블 설명 및 사용자 권한)는 데이터 딕셔너리 테이블에 저장. 서버에서 이 정보가 필요하면 데이터 딕셔너리 테이블을 읽고 반환된 데이터는 데이터 딕셔너리 캐시에 저장
데이터 딕셔너리 크기 조정
: 전체 크기는 공유 풀 크기에 따라 달라지며 데이터베이스에 의해 내부적으로 관리됨. 데이터 딕셔너리 캐시가 너무 작은 경우에는 데이터베이스에서 서버에 필요한 정보를 얻기 위해 데이터 딕셔너리 테이블을 계속 질의해야 함. 이러한 질의를 순환 호출이라고 하는데 SQL을 사용하지 않는 데이터 딕셔너리 캐시에서의 직접 질의보다 속도가 느림
데이터베이스 버퍼 캐시
질의를 처리 할 때 Oracle 서버 프로세스는 필요한 블록을 데이터베이스 버퍼 캐시에서 찾음. 데이터베이스 버퍼 캐시에서 찾지 못한 경우에는 데이터 파일에서 블록을 찾아 데이터베이스 버퍼 캐시에 복사 이후 요청에서 동일한 블록이 필요하면 메모리에서 직접 블록을 찾기 때문에 물리적으로 읽을 필요가 없음. Oracle 서버는 LRU(Least Recently Used) 알고리즘을 사용해 최근에 액세스하지 않은 버퍼를 삭제하여 데이터베이스 버퍼 캐시에 새로운 블록을 위한 공간을 생성
데이터베이스 버퍼 캐시 크기 조정
: 데이터베이스 버퍼 캐시에 있는 각 버퍼의 크기는 Oracle 블록의 크기와 같고 DB_BLOCK_SIZE 매개변수를 통해 지정. 데이터베이스 버퍼 캐시는 버퍼 풀과 다중 블록 크기에 대한 독립된 서브 캐시로 구성. DB_BLOCK_SIZE 매개 변수는 SYSTEM 테이블 스페이스에서 사용되는 기본 블록 크기를 결정
다음 세 개의 매개변수가 데이터베이스 버퍼 캐시의 크기를 정의
* DB_CACHE_SIZE
- 기본 버퍼 캐시의 크기만 조정. 이 값은 항상 존재하며 0으로 설정 불가
* DB_KEEP_CACHE_SIZE
- 재사용될 메모리 블록을 보유하는 데 사용되는 Keep 버퍼 캐시의 크기를 조정
* DB_RECYCLE_CACHE_SIZE
- 거의 재사용되지 않을 메모리 블록을 제거하는 데 사용되는 Recycle 버퍼 캐시의 크기를 조정
버퍼 캐시 권고
- 버퍼 캐시 권고 기능은 다양한 캐시 크기의 작업을 예측하기 위한 통계 수집을 활성화ㅣ하거나 비활성화함. 이러한 통계에서 제공되는 정보를 사용하면 지정된 작업 로드에 맞게 데이터베이스 버퍼 캐시의 크기를 조정 가능. 수집된 버퍼 캐시 권고 정보는 V$DB_CACHE_ADVICE 뷰를 통해 표시
- 버퍼 캐시 권고는 초기화 매개 변수 DB_CACHE_ADVICE를 통해 활성화됨. 이 매개변수는 동적 매개변수로 ALTER SYSTEM을 사용하여 변경 가능. 세 값 (OFF, ON, READY)을 사용 가능.
DB_CAHCE_ADVICE 매개변수 값
OFF : 권고가 해제되고 권고에 대한 메모리가 할당되지 않음
ON : 권고가 설정되고 CPU 및 메모리 오버헤드가 모두 발생
OFF 상태 일 때 이 매개변수를 ON 상태로 설정하려고 하면 "ORA-4031 Inability to allocate from the Shared Pool when the parameter is switched to ON" 이라는 오류 메시지가 발생함. 매개변수가 READY 상태인 경우에는 메모리가 이미 할당되어 있으므로 오류메세지 없이 ON으로 설정 가능.
READY : 권고가 해제되지만 권고에 대한 메모리는 할당된 상태로 유지. 권고가 실제로 설정되기 전에 메모리를 할당하면 ORA-4031 오류가 발생하지 않음. 매개변수가 OFF에서 이 상태로 전환된 경우에는 ORA-4031 오류가 발생 가능
리두 로그 버퍼
- 리두 로그 버퍼는 데이터 파일 블록의 변경 사항을 포함하는 순환버퍼. 이 정보는 리두 항목에 저장되며 리두 항목에는 INSERT, UPDATE, DELETE, CREATE, ALTER 또는 DROP 작업에 의해 변경되기 전의 데이터를 재생성해야 하는 정보가 포함됨
리두 로그 버퍼 크기 조정
- 리두 로그 버퍼의 크기는 초기화 매개변수 LOG_BUFFER에 의해 정의
대용량 풀
- 공유서버, Oracle XA 또는 병렬 질의 버퍼용 대용량 풀에서 세션 메모리를 할당함으로써 주로 공유 SQL 문을 캐시하기 위한 용도로 공유 풀을 사용 할 수 있음. 따라서 공유 풀 내의 영역에 대한 부담을 줄일 수 있음. 공유 풀은 충분한 메모리를 사용하여 공유 서버 세션정보, I/O, 백업 및 복구 프로세스를 위해 SQL 구문 분석 트리를 캐시 할 수 있음. 공유 SQL 캐시 크기를 조정하여 오버헤드를 줄이면 성능이 향상됨
백업 및 복원
- RMAN(Recovery Manager)은 BACKUP_DISK_IO= n 및 BACKUP_TAPE_IO_SLAVE=TRUE 매개변수가 설정된 경우 대용량 풀을 사용함. 대용량 풀이 구성되었지만 크기가 충분하지 않으면 대용량 풀에서 메모리를 할당 불가. RMAN은 오류 메세지를 경고 로그 파일에 쓰며 백업 또는 복원을 위해 I/O 슬래이브를 사용하지 않음.
병렬실행
- PARALLEL_AUTOMATIC_TUNING이 TRUE로 설정되면 대용량 폴이 사용되고, 그렇지 않으면 이러한 버퍼가 공유 풀에 할당 됨
대용량 풀 크기 조정
- 대용량 풀은 LARGE_POOL_SIZE 매개변수에서 정의한 크기(바이트)로 조정됨. 이 매개변수는 동적 매개변수가 아님
대용량 풀 및 LRU 목록
- 대용량 풀에는 LRU 목록이 없음. LRU 목록을 사용하는 공유 풀의 예약 공간과는 다른 개념
Java 풀
Java 풀은 선택적인 설정이지만 Java를 설치하고 사용하는 경우 필요. Java 풀은 JAVA_POOL_SIZE 매개변수를 통해 바이트 단위로 크기가 조정. Oracle 9i 버전에서 Java 풀의 기본 크기는 24MB.
PGA(프로그램 글로벌 영역)
프로그램 글로벌 영역 또는 PGA(프로세스 글로벌 영역)는 데이터를 포함하고 단일 서버 프로세스 또는 단일 백그라운드 프로세스의 정보를 제어하는 메모리 영역임. PGA는 프로세스가 생성될 때 할당되고 프로세스가 종료될 때 할당이 해제 됨. 여러 프로세스가 공유하는 SGA와 달리 PGA는 단 하나의 프로세스가 사용하는 영역임
PGA 내용 :
PGA 메모리의 내용은 인스턴스가 전용 서버에서 실행되는지 또는 공유 서버 구성에서 실행되는 지 여부에 따라 다름. 일반적으로 PGA 메모리에는 다음 구성 요소가 포함됨.
* 전용 SQL 영역 : 바인드 정보 및 런타임 메모리 구조와 같은 데이터가 포함되며 SQL문을 실행하는 각 세션마다 전용 SQL 영역이 있음. 동일한 SQL 문을 제출하는 각 사용자는 단일 공유 SQL 영역을 사용하는 고유한 전용 SQL 영역을 가지고 있음. 따라서 많은 전용 SQL 영역을 동일한 공유 SQL 영역과 연관시킬 수 있음. 커서의 전용 SQL 영역은 다음 두 영역으로 나누어짐
- 지속 영역 : 바인드 정보를 포함하며 커서가 닫힐 때만 해제됨
- 런타임 영역 : 실행 요청의 첫 번째 단계로 생성. INSERT, UPDATE 및 DELETE 명령의 경우 이 영역은 명령문이 실행된 후에 해제되고 질의의 경우에는 모든 행이 인출되거나 질의가 취소된 후에만 해제
전용 SQL 영역의 위치는 세션에 설정된 접속 유형에 따라 다름. 전용 서버 환경에서는 전용 SQL 영역이 해당 서버 프로세스의 PGA에 있고 공유 서버 환경에서는 SGA에 있음. 전용 SQL 영역은 사용자 프로세스에서 관리해야 함. 사용자프로세스에서 할당 할 수 있는 전용 SQL 영역의 수는 항상 초기화 매개변수 OPEN_CURSORS에 의해 제한됨. 이 매개변수의 기본 값은 50임.
* 세션 메모리 : 세션의 변수 및 세션에 관련된 기타 정보를 유지하기 위해 할당되는 메모리로 구성. 공유서버환경에서 세션 메모리는 전용 메모리가 아닌 공유 메모리임
* SQL 작업 영역 : 정렬, 해시 조인, 비트맵 병합, 비트맵 생성과 같은 메모리가 많이 필요한 작업에 사용. 작업 영역의 크기는 제어하거나 튜닝 할 수 있음.
Oracle9i부터 작업 영역의 크기는 WORKAREA_SIZE_POLICY 매개변수를 기본 값인 AUTO로 설정하고 초기화 매개변수 PGA_AGGREGATE_TARGET을 설정하여 전역적으로 자동 관리됨.
전용 서버와 공유 서버의 메모리 할당 차이
- PGA 메모리의 내용은 인스턴스가 전용 서버 구성에서 실행되는지 또는 공유 서버 구성에서 실행되는지 여부에 따라 다름. 일반적으로 PGA 메모리에는 다음 구성요소가 포함
사용자 프로세스
- 데이터베이스 사용자가 데이터베이스의 정보를 요청하려면 먼저 Oracle 서버에 접속해야하며 SQL*Plus 와 같은 데이터베이스 인터페이스 툴을 사용하고 사용자 프로세스를 시작하여 접속을 요청. 사용자 프로세스는 Oracle 서버와 직접 상호 작용하지 않고, 대신 세션을 생성하고 서버 프로세스를 시작하는 UPI(사용자 프로그램 인터페이스)를 통해 호출을 생성
서버 프로세스
- 사용자가 접속하면 서버 프로세스가 시작되어 사용자 프로세스 요청을 처리. 서버 프로세스는 전용 서버 프로세스 또는 공유 서버 프로세스일 수 있음. 전용 서버 환경에서는 서버 프로세스가 단일 사용자 프로세스의 요청을 처리하며 사용자 프로세스의 접속이 해제되면 서버 프로세스가 종료됨. 공유 서버 환경에서는 서버 프로세스가 여러 사용자 프로세스의 요청을 처리함. 서버 프로세스는 OPI(Oracle 프로그램 인터페이스)를 사용하여 Oracle 서버와 통신
백그라운드 프로세스
- Oracle 구조에는 다섯 가지 필수 백그라운드 프로세스가 있음. 옵션이 사용되는 동안에는 이러한 필수 목록 외에도 여러가지 선택적인 백그라운드 프로세스가 시작됨. 이 과정에서는 ARCn 백그라운드 프로세스 외의 선택적 프로세스에 대한 정보는 없음.
* RECO : 복구자
* QMNn : 고급 대기열 처리
* ARCn : 아카이버
* LCKn : RAC 잠금 관리자 - 인스턴스 잠금
* LMON : RAC DLM 모티너 - 글로벌 잠금
* LMDn : RAC DLM 모니터 - 원격 잠금
* CJQ0 : 조정자 작업 대기열 백그라운드 프로세스
* Dnnn : 디스패처
* Snnn : 공유서버
* Pnnn : 병렬 질의 슬래이브
DBWn(데이터베이스 기록자)
- 서버 프로세스는 실행 취소 블록 및 데이터 블록의 변경 사항을 데이터베이스 버퍼 캐시에 기록함. DBWn은 데이터베이스 버퍼 캐시의 더피 버퍼를 데이터 파일에 기록하여 데이터베이스 버퍼 캐시에 있는 사용 가능한 버퍼(서버 프로세스가 있는 데이터 파일의 블록을 읽을 때 겹쳐 쓸 수 있는 버퍼) 수를 충분하게 유지. 서버 프로세스는 데이터베이스 버퍼 캐시에서만 변경하므로 데이터베이스 성능이 향상
DBWn는 다음 이벤트 중 하나가 발생할 때 까지 데이터 파일에 기록하는 것을 지연함
* 증분 또는 정상 체크포인트가 발생한 경우
* 더피 버퍼의 개수가 한계 값에 이른 경우
* 사용 가능한 버퍼를 스캔 할 때 프로세스가 지정된 개수의 블록을 스캔했는데도 찾을 수 없는 경우
* 시간 초과가 발생한 경우
* RAC(Real Application Clusters) 환경에서 핑 요청을 한 경우
* 정상 또는 임시 테이블스페이스를 오프라인으로 설정한 경우
* 테이블스페이스를 읽기 전용 모드로 설정한 경우
* 테이블을 삭제하거나 잘라낸 경우
* ALTER TABLESPACE 테이블 스페이스 이름 BEGIN BACKUP인 경우
- 블록의 크기는 2,4,8,16,32K 크기 중 선택하여 설정 가능하며 대게 8K
LGWR(로그 기록자)
- LGWR는 다음 상황일 때 리두 로그 버퍼의 내용을 리두 로그 파일에 순차적으로 기록
* 트랜잭션 커밋 시
* 리두 로그 버퍼가 1/3 찾을 경우
* 1MB 이상의 변경 사항이 리두 로그 버퍼에 기록 된 경우
* DBWn가 데이터베이스 버퍼 캐시에서 수정된 블록을 데이터 파일에 기록하기 전에
* 3초마다
리두가 복구를 위해 필요하기 때문에 디스크에 리두를 기록한 후에만 LGWR는 커밋 작업을 확인 또한 LGWR는 데이터 파일에 기록하도록 DBWn에 요청 가능
- 리두 엔트리로 저장되며, 시간 순서대로 데이터베이스 버퍼캐시에서 수정된 사항을 리두 정보로 저장
- 데이터베이스 버퍼캐시에 단순한 insert 문을 통해 데이터가 입력되어도 리두 로그 버퍼에는 상당량에 데이터가 저장됨 LGWR를 통해 리두 로그 파일에 기록을 함 하지만 LGWR가 더 많이 움직이는 데, 단순한 insert 문이라고 하여도 DBWn이 데이터 파일에 기록을 할 때 상대적으로 많은 양이므로 LGWR에 비해 덜 작동함 ( 이모든 이유는 데이터베이스가 블록단위로 입출력을 하기 때문)
예:) DB버퍼캐시에 insert 문을 2개를 두 블록에 기록, 리두 로그 버퍼에 해당 사항에 대한 정보를 한블록에 기록 이 때 DBWR는 두 블록을 데이터 파일에 기록해야 하고, LGWR는 리두 로그 파일에 한 블록만 기록함. 실제로 DB 버퍼 캐시에는 50MB만 기록하였고, 리두로그버퍼에 2KB를 기록하였더라도 실제로 처리하는 작업량은 DBWR가 2배가 되므로 DBWR의 실제 작업량이 더 많아 짐.
SMON(시스템 모니터)
- Oracle 인스턴스가 실패하면 디스크에 기록하지 않은 SGA의 정보는 손실 예를 들면, 운영체제가 실패하면 인스턴스도 실패. 인스턴스 손실 후 백그라운드 프로세스인 SMON은 데이터베이스를 다시 열 때 인스턴스 복구를 자동으로 수행. 인스턴스 복구는 다음 단계로 구성
1. 롤 포워드하여 데이터 파일에는 기록되지 않았지만 온라인 리두 로그에 기록된 데이터를 복구. 이 데이터는 인스턴스가 실패 했을 때 SGA가 손실되었기 때문에 디스크에 기록되지 않음. 이 프로세스 동안 SMON은 리두 로그 파일을 읽어 들여 리두 로그에 기록된 변경 사항을 데이터 블록에 적용. 모든 커밋된 트랜잭션이 리두 로그에 기록되었기 때문에 이 프로세스는 이러한 트랜잭션을 완전히 복구함
2. 데이터베이스를 열어 사용자가 로그인하도록 함. 복구되지 않은 트랜잭션에 의해 잠긴 데이터를 제외하고는 즉시 사용 가능
3. 커밋되지 않은 트랜잭션은 롤백됨. 이것은 SMON에 의해 또는 각 서버 프로세스가 잠긴 데이터를 액세스할 때 해당 서버 프로세스에 의해 롤백됨,
SMON은 또한 다음과 같은 일부 공간 유지 관리 기능을 수행
* 데이터 파일에서 사용 가능한 공간의 인접 영역을 병합
* 임시 세그먼트의 할당을 해제하여 데이터 파일에서 사용 가능한 공간으로 되돌림.
PMON(프로세스 모니터)
- 백그라운드 프로세스인 PMON은 프로세스 실패 후 다음과 같이 정리
* 사용자의 현재 트랜잭션이 롤백됨
* 현재 유지된 테이블 또는 행 잠금을 해제
* 현재 사용자가 예약한 기타 자원을 사용 가능하게 함
* 사용 불능 디스패처를 재시작함
- 서버프로세스는 사용자프로세스와 1:1로 연결, 사용자가 연결이 계속 되는(포크) 경우 서버 프로세스는 늘어 나게 되는 데, 핀 신호를 받지 않고 꺼진 서버 프로세스는 계속 고스트프로세스로 남아 하드에 부담을 주는 데 이것을 작동 중지 시키는 역할을 함
CKPT(체크포인트)
- CKPT 프로세스는 3초마다 데이터를 제어 파일에 저장하여 리두 로그 파일에서 복구가 시작되는 위치를 식별하는데 이를 체크포인트라고 함. 체크포인트의 용도는 특정 시점 이전에 수정된 데이터베이스 버퍼 캐시의 모든 버퍼가 데이터 파일에 기록되게 하는 것. 체크 포인트 위치라고 하는 이 시점은 인스턴스 오류 시 데이터베이스 복구가 시작되는 위치. DBWn는 이 시점 전에 수정된 데이터베이스 버퍼 캐시의 모든 버퍼를 이미 기록했을 것. Oracle9i 이전에는 이 작업이 리두 로그 마지막에 수행됨. 로그 스위치가 발생한 경우에도 CKPT는 이 체크포인트 정보를 데이터 파일의 헤더에 기록
체크포인트를 시작하는 이유
* 메모리에 있는 수정된 데이터 블록을 정기적으로 디스크에 기록하여 시스템 또는 데이터베이스 오류 시 데이터가 손실되지 않게 함.
* 인스턴스 복구에 필요한 시간을 줄임. 복구를 수행하기 위해서는 마지막 체크포인트 이후의 리두 로그 항목만 처리되면 됨.
* 종료하는 동안 모든 커밋된 데이터가 데이터 파일에 기록되게 함.
CKPT가 기록한 체크포인트 정보에는 체크포인트 위치, 시스템 변경 번호, 복구를 시작할 리두 로그에서의 위치, 로그 정보 등이 포함
ARCn(아카이버)
- 다른 모든 백그라운드 프로세스는 데이터베이스의 구성에 따라 선택적이나 그 중 ARCn 프로세스는 디스크 손실 후 데이터베이스를 복구하는 데 반드시 필요. 온라인 리두 로그 파일이 채워지면 Oracle 서버는 다음 온라인 리두 로그 파일에 기록을 시작하는 데 이와 같이 한 리두 로그에서 다른 리두 로그로 전환하는 프로세스를 로그 스위치라고 함. ARCn 프로세스는 로그 스위치가 발생할 때마다 채워진 로그 그룹을 백업하거나 아카이브하기 시작. 이것은 로그를 다시 사용하기 전에 온라인 리두 로그를 자동 아카이브하므로 데이터베이스의 모든 변경 사항이 보존. 따라서 DBA는 디스크 드라이브가 손상되더라도 데이터베이스를 장애 발생 시점까지 복구 가능.
리두 로그 파일 아카이브
- 데이터베이스를 ARCHIVELOG모드와 NOARCHIVELOG 모드 중에서 어느 모드에서 작동하도록 구성할지 여부는 DBA가 결정해야 하는 중요한 문제 중 하나.
NOARCHIVELOG 모드
- NOARCHIVELOG 모드에서는 로그 스위치가 발생할 때마다 온라인 리두 로그 파일을 겹쳐 씀. LGWR는 해당 그룹의 체크포인트가 완료될 때까지 리두 로그 그룹을 겹쳐 쓰지 않음. 따라서 인스턴스 실패 시 커밋된 데이터는 복구 할 수 있고 SGA만 손실 됨. 즉 디스크는 손실되지 않고 메모리만 손실되는 데 예를 들어 운영체제가 실패하면 인스턴스도 실패.
ARCHIVELOG 모드
- 데이터베이스가 ARCHIVELOG 모드로 실행하도록 구성된 경우 채워진 온라인 리두 로그 파일의 비활성 그룹은 다시 사용하기 전에 아카이브해야 함. 데이터베이스의 변경 사항은 온라인 리두 로그 파일에 기록되기 때문에 데이터베이스 관리자는 데이터 파일의 물리적 백업 및 아카이브된 온라인 리두 로그 파일을 사용하여 디스크 손실을 포함하여 어느 한 부분의 실패로 인해 커밋된 데이터를 손실하는 일 없이 데이터베이스를 복구할 수 있음. 대개 운용 중인 데이터베이스는 ARCHIVELOG 모드에서 실행하도록 구성
논리적 구조
논리적 구조 계층
* 오라클 데이터베이스에는 테이블스페이스가 하나 이상 포함되어 있음.
* 테이블스페이스에는 세그먼트가 하나 이상 포함되어 있음
* 세그먼트는 확장영역으로 구성됨
* 확장 영역은 논리적 블록으로 구성됨
* 블록은 읽기 및 쓰기 작업의 최소 단위
오라클 데이터베이스 구조는 데이터베이스를 구성하는 논리적 구조와 물리적 구조로 나뉠 수 있음.
* 물리적 구조에는 데이터베이스를 구성하는 제어 파일, 온라인 리두 로그 파일 및 데이터 파일이 포함.
* 논리적 구조에는 테이블 스페이스, 세그먼트, 확장 영역 및 데이터 블록이 포함됨
Oracle 서버는 세그먼트, 확장 영역 및 데이터 블록을 포함한 논리적 저장 영역 구조와 테이블 스페이스를 통해서 디스크 영역 사용을 세부적으로 제거 가능.
테이블 스페이스
- 오라클 데이터베이스의 데이터는 테이블스페이스에 저장됨
* 오라클 데이터베이스는 논리적으로 테이블스페이스라고 하는 작은 논리적 저장 영역으로 그룹화될 수 있음.
* 테이블 스페이스는 어느 한 시점에서 데이터베이스 하나에만 속할 수 있음.
* 각 테이블스페이스는 데이터 파일이라고 하는 하나 이상의 운영 체제 파일로 구성됨
* 테이블스페이스는 하나 이상의 세그먼트로 구성
* 데이터베이스를 실행하는 동안 테이블스페이스를 온라인으로 설정 가능.
* SYSTEM 테이블스페이스 또는 활성 실행 취소 세그먼트가 있는 테이블스페이스를 제외하면 데이터베이스를 실행하면서 테이블스페이스를 오프라인으로 설정 할 수 있음
* 테이블스페이스를 읽기/쓰기 및 읽기 전용 상태로 전환 가능
데이터 파일(논리적 구조 아님)
* 오라클 데이터베이스의 각 테이블스페이스는 데이터 파일이라고 하는 하나 이상의 파일로 구성되며 이러한 데이터 파일은 Oracle 서버를 실행 중인 운영 체제를 따르는 물리적 구조
* 데이터 파일은 한 테이블스페이스에만 속할 수 있음.
* Oracle 서버에서는 지정된 용량의 디스크 공간과 작은 용량의 오버헤드를 할당하여 테이블스페이스용 데이터 파일을 생성
* 데이터베이스 관리자는 데이터 파일 생성 후 크기를 변경할 수 있고 테이블스페이스의 객체가 커짐에 따라 데이터 파일도 동적으로 커지도록 지정 할 수 있음.
세그먼트
* 세그먼트는 테이블스페이스 안의 특정 논리적 저장 영역 구조에 할당된 영역
* 테이블스페이스는 하나 이상의 세그먼트로 구성됨
* 세그먼트를 여러 테이블스페이스로 확장할 수 없지만 동일한 테이블스페이스에 속한 여러 데이터 파일로 확장 가능
확장 영역
- 공간을 확장 영역 단위로 세그먼트에 할당
* 하나 이상의 확장 영역으로 세그먼트를 구성
- 생성된 세그먼트는 하나 이상의 확장 영역으로 구성
- 세그먼트가 커지면 확장 영역이 세그먼트에 추가
- DBA는 수동으로 세그먼트에 확장영역을 추가 가능
* 확장 영역은 연속된 Oracle 블록 집함
* 확장 영역은 데이터 파일로 확장 할 수 없으므로 한 데이터 파일에 존재해야 함
데이터 블록
- Oracle 서버에서는 Oracle 블록 또는 데이터 블록이라는 단위로 데이터 파일에 있는 저장 공간을 관리
* 가장 작은 단위인 오라클 데이터베이스의 데이터는 데이터 블록에 저장
* Oracle 데이터 블록은 Oracle 서버가 할당, 읽기 또는 기록 할 수 있는 가장 작은 단위의 저장 영역
* 하나의 데이터 블록은 기존 데이터 파일에서 할당된 하나 이상의 운영 체제 블록에 대응
* 오라클 데이터 베이스의 표준 데이터 블록 크기는 데이터베이스가 생성 될 때 초기화 매개변수 DB_BLOCK_SIZE를 통해 지정
* 데이터 블록 크기는 불필요한 I/O를 피하기 위해 운영 체제 블록 크기의 배수가 되어야 함
* 최대 데이터 블록 크기는 운영 체제에 따라 다름
SQL 문 처리
질의 처리
* 구문 분석
- 동일한 명령문 검색
- 구문, 객체 이름 및 권한을 검사
- 구문을 분석하는 동안 사용된 객체를 잠금
- 실행 계획을 생성하고 저장
* 바인드 : 변수 값을 얻음
* 실행 : 명령문을 처리
* 인출 : 사용자 프로세스로 행을 반환
DML 문 처리
* 구문 분석
- 질의 처리에 사용되는 구문 분석과 동일
* 바인드
- 질의 처리에 사용되는 바인드 단계와 동일
* 실행
- 데이터 및 실행 취소 블록이 데이터베이스 버퍼 캐시에 없는 경우 서버 프로세스는 이러한 블록을 데이터 파일에서 읽어 데이터베이스 버퍼 캐시에 복사
- 서버 프로세스는 수정될 행을 잠굼. 실행 취소 블록에 데이터의 이전 이미지를 저장하여 필요한 경우 DML 문을 롤백할 수 있음.
- 데이터 블록 변경은 새로운 데이터 값을 기록
- 서버 프로세스는 이전 이미지를 실행 취소 블록에 기록하고 데이터 블록을 갱신. 이러한 변경은 모두 데이터베이스 버퍼 캐시에서 수행. 데이터베이스 버퍼 캐시의 변경된 블록은 더티 버퍼, 즉 디스크에 있는 해당 블록과 동일 하지 않은 버퍼로 표시
- DELETE 또는 INSERT 명령을 처리할 때도 유사한 단계가 사용. DELETE의 이전 이미지에는 삭제된 행의 열 값이 포함되고 INSERT의 이전 이미지에는 행 위치 정보가 포함됨.
DDL 문 처리
- DDL(데이터 정의어) 문이 성공하려면 데이터 딕셔너리에 대한 쓰기 액세스가 필요하기 때문에 DDL 문의 실행은 DML(데이터 조작어)문 및 질의와 다름. 이러한 명령문의 경우 구문 분석에는 실제로 구문 분석, 데이터 딕셔너리 조회 및 실행이 포함. 트랜잭션 관리, 세션 관리 및 시스템 관리 SQL문은 구문 분석 및 실행 단계를 사용하여 처리. 다시 실행하려면 다른 실행 단계를 수행할 것.
