오라클 SGA

출처: https://blog.naver.com/qowndyd/220995596404

오라클 데이터베이스 서버구조   → 오라클 데이터베이스 서버는 하나 이상의 오라클 데이터베이스 인스턴스로 구성된다. → 인스턴스는 메모리 구조와 백그라운드 프로세스로 구성된다. → 인스턴스가 시작될 때마다 SGA(System Global Area) 라는 공유 메모리 영역이 할당되고 백그라운드 프로세스가 시작된다. ​ ◆ 오라클 데이터베이스 SGA(System Global Area) 메모리 구조   → 데이터베이스 버퍼캐시 : 데이터베이스 파일에서 검색된 데이터 블록을 캐시에 저장한다. → 리두 로그 버퍼 : 물리적 파일에 기록하기 전에 Recovery 정보를 캐시에 저장한다. → Shared Pool : 세션 간에 공유할 수 있는 다양한 구성 요소를 캐시에 저장한다. → Java Pool : JVM(Java Virtual Machine) 내의 세션 별 Java 코드 및 데이터에 사용된다. → Stream Pool : Oracle Streams 에서 캡처 및 적용 프로세스에 대한 정보를 저장하는데 사용된다. → PGA(Program Global Area) : 서버 또는 백그라운드 프로세스에 대한 데이터 및 제어정보를 포함하는 메모리 영역이다. ​ ◆ 데이터베이스 버퍼 캐시   → 데이터 파일에서 읽은 데이터 블록의 복사본을 보관하는 SGA 부분이다. → 인스턴스에 동시에 연결하는 모드 유저는 데이터베이스 버퍼 캐시에 대한 액세스를 공유한다. → 특정 데이터 피스를 처음 사용해야 하는 경우 데이터베이스 버퍼 캐시에서 데이터를 검색한다. 이미 있는 데이터를 발견하는 경우(캐시적중) 메모리에서 데이터를 직접 읽을 수 있다.(빠름) → 데이터를 발견하지 못하면(캐시실패) 데이터에 액세스 하기 전에 데이터 블록을 디스크의 데이터 파일에서 캐시의 버퍼로 복사해야 한다. ​ ◆ 리두(REDO) 로그 버퍼   → 데이터베이스에 대한 변경 사항 관련 정보가 포함된 SGA의 순환버퍼 이다. → Insert, Update, Delete, Create, Alter, Drop 작업에 따른 데이터베이스의 변경 사항을 재생성하데 필요한 정보를 포함한다. 필요한 경우 데이터베이스 복구에 사용된다. → 서버 프로스세에 의해 유저의 메모리 영역에서 리두로그 버퍼로 복사된다. → 연속되는 순차적 공간을 차지한다. → LGWR(로그 기록자) 백그라운드 프로세스는 리두로그버퍼를 디스크의 활성 리두 로그(또는 파일 그룹)에 기록한다. → CPU 수에 따라 리두 로그 버퍼가 두 개 이상 있을 수 있으며 자동으로 할당된다. ​ ◆ Shared Pool   오라클 데이터베이스는 데이터 딕셔너리에 자주 액세스 하므로 두 곳의 특수 위치에 딕셔너리 정보를 보관하도록 지정한다.(라이브러리 캐시, 데이터 딕셔너리 캐시) → 라이브러리 캐시 : SQL문, PL/SQL, 프로시저 및 패키지의 공유 가능한 부분이 포함된다. → 데이터 딕셔너리 캐시(행 캐시) : 데이터베이스에 대한 참조 정보를 포함하는 데이터베이스 테이블의 모음이다. → 제어구조 : 반드시 필요한 Lock 구조를 포함한다. ​ ◆ DML 문 처리   1. 서버 프로세스는 해당 명령문을 받아 라이브러리 캐시에서 유사한 SQL 문이 포함된 공유 SQL영역이 있는지 확인한다. 발견되면 기존 공유 SQL영역이 명령문 처리에 사용된다. 발견되지 않을 경우 구문분석이 시작되고 새 공유 SQL 영역이 해당 명령문에 대해 할당된다. 2. 데이터 및 언두 세그먼트 블록이 버퍼 캐시에 없는 경우, 서버 프로세스는 데이터 파일에서 버퍼캐시로 읽어 들인다. 수정해야 할 행은 lock 한다. 3. 서버 프로세스는 데이터 버퍼에 수행될 변경 사항과 언두 변경 사항을 기록한다. 이러한 변경사항은 버퍼가 수정되기 전에 리두 로그 버퍼에 기록된다. 이것을 먼저 쓰기 로깅(write-ahead logging) 이라고 한다. 4. 언두 세그먼트 버퍼에서는 수정되기 전의 데이터 값이 들어 있다. 언두 버퍼는 필요한 경우 DML문이 롤백될 수 있도록 데이터의 이전 이미지를 저장하는데 사용된다. 데이터버퍼는 새로운 데이터 값을 가지고 있다. ​ ◆ COMMIT 처리   1. 서버 프로세스는 SCN(시스템 변경 번호)과 함께 커밋 레코드를 리두 로그 버퍼에 배치한다. SCN은 일정하게 증가하며 데이터베이스 내에서 고유한 번호이다. SCN은 데이터 파일에서 데이터를 검색할 때 데이터를 동기화하고 읽기 일관성을 제공하기 위한 내부 시간 기록으로 오라클 데이터베이스에 의해 사용된다. 2. LGWR 백그라운드 프로세스는 커밋 레코드를 포함하여 모든 리두 로그 버퍼 항목을 리두로그파일에 연속적으로 기록한다. 이 시점부터 인스턴스 실패가 발생할 경우에도 변경사항이 손실되지 않도록 보장된다. 3. 수정된 블록이 SGA에 계속 존재하거나 해당 블록을 수정 중인 세션이 없을 경우 데이터베이스는 블록에서 lock 관련 트랜잭션 정보를 제거한다. 이것을 커밋삭제라고 부른다. ​ ◆ Large Pool   대규모 메모리 할당을 제공하기 위해 구성된다. 아래 경우에 권장된다. → 병렬 실행 : Parallel Query 사용시 → 오라클 데이터베이스 백업 및 복구 작업 : Recovery Manager 사용시 Large Pool을 사용하면 크로 작은 할당에서 동일한 메모리 영역을 공유하는 것과 관련하여 발생 가능한 단편화 문제를 피할 수 있다. Shared Pool과 달리 Large Pool에는 LRU list가 없다. ​ ◆ Java Pool 및 Streams Pool   → Java Pool 메모리 : JVM의 모든 세션 별 Java 코드 및 데이터에 사용된다. → Streams Pool 메모리 : 데이터베이스 내에서 또는 데이터베이스 간에 데이터 스트림의 데이터, 트랜잭션 및 이벤트를 전달하고 관리한다. ​ ◆ PGA(Program Global Area)   → 서버프로세스가 클라이언트 프로세스를 대신하여 요청을 수행하기 위해 사용하는 임시적인 메모리 영역 → 작업이 끝나면 클라이언트 요청에 대한 세부정보를 PGA에 보관한 다음, PGA 영역을 클라이언트에게 넘겨준다 ​ ◆ 백그라운드 프로세스   ▶ DBWR(데이터베이스 기록자) : 데이터베이스 버퍼 캐시의 수정된 (더티)버퍼를 비동기적으로 디스크에 기록한다. ▶ LGWR(로그기록자) : 디스크에 있는 리두 로그 파일에 로그 버퍼의 Recovery 정보를 기록한다. ▶ CKPT(체크포인트 프로세스) : 콘트롤 파일의 체크포인트 정보와 각 데이터 파일 헤더를 기록한다. ▶ SMON(시스템모니터) : 인스턴스 시작 시 Recovery를 수행하고 사용되지 않은 임시 세그먼트를 정리한다. ▶ RCBG(결과 캐시 백그라운드) : Shared Pool에 저장된 결과 캐시를 유지 관리하는데 사용된다. ▶ CJQ0(작업 큐 프로세스) : 스케줄러를 통해 일괄 처리에 사용되는 유저 작업을 실행한다. ▶ ARCn(아카이버 프로세스) : 로그스위치가 발생한 후에 리두 로그 파일을 지정된 저장장치로 복사한다. ▶ QMNn(큐 모니터 프로세스) : Oracle Streams 메시지 큐를 모니터한다. ▶ MMON(관리 효율성 모니터링 프로세스) : 관리 효율성 관련 백그라운드 작업을 수행한다. ▶ MMAN(메모리 관리자 백그라운드 프로세스) : SGA 및 PGA 메모리 구성 요소를 자동으로 관리하는데 사용한다. ​ ◆ 자동 공유 메모리 관리(Automatic Shared Memory Management)   → 10g 이후 사용할 수 있게 되었다. → SGA_TARGET파라미터를 사용한다. → SGA 구성을 단순화하여 모든 SGA 구성요소에 사용되는 전체 메모리 양을 간편하게 지정할 수 있도록 할 수 있다. → 오라클 데이터베이스는 작업 로드 요구 사항에 따라 자동으로 튜닝된 구성 요소 간에 메모리를 주기적으로 다시 분산한다. → 이 기능을 사용하려면 STATISTICS_LEVEL 을 TYPICAL 또는 ALL로 설정해야 한다. ​ ◆ 자동 SQL 실행 메모리 관리   → PGA 작업 영역에 메모리를 자동으로 할당 하는 모드를 제공한다. → PGA_AGGREGATE_TARGET 파라미터를 사용한다. → 인스턴스 세션의 PGA 영역에 할당되어야 할 전체 메모리 양을 지정할 수 있다. → 자동 모드에서 메모리 사용량이 많은 연산자(정렬 및 Hash Join)에 의해 상용되는 작업 영역은 자동 및 동적으로 조정될 수 있다. → 전체적인 시스템 성능이 극대화되고 가용 메모리가 query 사이에 더욱 효율적으로 할당되어 처리량과 응답 시간을 모두 최적화 할 수 있다. 특히 메모리 활용도가 개선되어 로드가 많은 경우의 처리량이 향상된다. → 정렬 또는 Hash Join 연산자는 작업 로드가 계속해서 변경되기 때문에 자동 PGA 메모리 관리를 활성화된 상태로 유지하는 것 좋다. ​ ◆ 자동 메모리 관리   → 인스턴스의 다양한 메모리 영역 크기는 SQL 처리 속도에 직접적인 영향을 미친다. 자동 메모리 관리(Automatic Memory Management)를 사용하면 필요한 작업 로드 메모리 양에 맞게 자동으로 각 메모리 구성 요소의 크기가 적용된다. → MEMORY_TARGET 초기화 파라미터를 사용한다. → MMAN 백그라운드 프로세스에서 자동으로 SGA 내부 구성 요소 간에, 그리고 SGA와 집계PGA 간에 필요한 메모리를 다시 분산하여 대상 메모리 크기를 튜닝한다. → 두 개의 프로세스(MMON, MMAN)으로 구현된 SGA 메모리 Broker를 사용한다. → 통계 및 메모리 Advisory 데이터는 MMON을 통해 메모리에서 주기적으로 캡처된다. 그 후 이 두 개의 프로세의 결정에 따라 메모리 구성 요소 크기가 조정된다. ​ ◆ 데이터베이스 저장 영역 구조   → 콘트롤 파일 : 데이터베이스 자체에 대한 데이터(즉, 물리적 데이터베이스 구조정보) 를 포함한다. 이 파일은 매우 중요하다. 이 파일이 없으면 데이터베이스 내의 데이터에 액세스할 때 데이터 파일을 열 수 없다. → 데이터 파일 : 데이터베이스의 유저 또는 응용 프로그램 데이터, 메타데이터 및 데이터 딕셔너리를 포함한다. → 온라인 리두 로그 파일 : 데이터베이스의 인스턴스 Recovery를 가능하게 한다. 데이터베이스 서버가 손상되었지만 해당 데이터 파일은 손실되지 않은 경우 인스턴스는 이 파일을 사용하여 데이터베이스를 Recovery할 수 있다. → 파라미터 파일 : 인스턴스 시작 시 어떻게 인스턴스를 구성할 지 정의하는데 사용된다. → Password file : sysdba, sysoper 및 sysasm이 데이터베이스에 원격으로 연결하여 관리 작업을 수행할 수 있도록 한다. → 백업파일 : 데이터베이스 Recovery 에 사용된다. 백업 파일은 일반적으로 Media Failure 또는 User Error 로 원본 파일이 손상되었거나 삭제되었을 경우에 복원한다. → 아키이브된 리두 로그 파일 : 인스턴스에 의해 생성되는 데이터 변경(리두)에 대한 기록을 지속적으로 포함한다. 이 파일과 데이터베이스 파일, 두 개를 사용하면 손실된 데이터파일을 Recovery 할 수 있다. 즉 복원된 데이터 파일의 Recovery를 가장 최신의 데이터로 가능하게 하는 역할을 한다. → Trace file : 각 서버와 백그라운드 프로세스는 Tracle File에 정보를 기록한다. 시스템 오류가 프로세스에서 감지되면 프로세스는 오류에 대한 정보를 해당 Trace File에 덤프한다. Trace File에 기록된 정보 중 일부는 개발자가 사용하고 일부는 오라클 고객지원센터에서 사용하게 된다. → Alert Log File : 특수 Trace 항목으로, 데이터베이스의 Alert Log에는 메시지와 오류가 시간순으로 기록되어 있다. 각 인스턴스에는 한 개의 Alert log file이 있다. 이 파일을 정기적으로 검토하는 것이 좋다. ​ ◆ 논리적 및 물리적 데이터베이스 구조   → 스키마 : 데이터베이스 유저가 소유하는 데이터베이스 객체의 모음으로 논리적 개념이다. 스키마 객체에는 테이블, 뷰, 시퀀스, 내장 프로시저, 동의어, 인덱스, 클러스터, 데이터베이스 링크 등의 구조가 있다. → 데이터 블록 : 가장 작은 세분성 레벨에서 오라클 데이터베이스의 데이터는 데이터 블록에 저장된다. 하나의 데이터 블록은 디스크에서 특정 바이트 수의 물리적 데이터베이스 공간에 해당한다. 데이터 블록 크기는 생성시 각 테이블스페이스에 대해 지정된다. 데이터 베이스는 사용 가능한 데이터베이스 공간을 Oracle 데이터 블록으로 사용 및 할당한다. → Extent : 그 다음 레벨의 논리적 데이터베이스 공간이다. Extent는 단일 할당으로 얻은 일정수의 연속적인 데이터 블록으로, 특정 유형의 정보를 저장하는데 사용된다. → 세그먼트 : 그 다음 레벨의 논리적 데이터베이스 공간이다. 세그먼트에는 다음과 같은 유형이 있다. ​   오라클 데이터베이스는 동적으로 공간을 할당한다. 세그먼트의 기존 Extent가 가득 차면 다른 Extent가 추가된다. Extent는 필요에 따라 할당되므로 세그먼트의 Extent는 디스크 상에서 인접해 일을 수도 있고 그렇지 않을 수도 있다. ​ ◆ 세그먼트, Extent 및 블록   → 데이터 블록은 데이터베이스의 가장 작은 I/O 단위이다. → 데이터베이스에서 OS(운영체제)의 데이터 블록 집합을 요청하면 OS는 이를 저장 장치의 디스크 블록이나 실제 파일시스템으로 매핑한다. 따라서 데이터베이스에 있는 데이터의 물리적 주소를 알 필요는 없으며, 데이터 파일을 여러 디스크에 스트라이핑 또는 Mirroring할 수도 있다. → 데이터 블록의 크기는 데이터베이스 생성 시 설정할 수 있다. 대부분의 경우 기본 크기는 8KB 가 적합하다. 큰 데이블 및 인덱스를 사용하는 데이터웨어하우스(DW) 응용프로그램을 지원하는 경우 블록의 크기를 크게 지정하는 것이 효과적일 수 있다. → 읽기와 쓰기가 무작위로 발생하는 경우 데이터블록 크기를 작게 지정하는 것이 유용할 수 있다. 최소 데이터블록 크기는 OS에 따라 다르다. 최소 Oracle 블록 크기는 2KBm인데 이렇게 작은 크기는 거의 사용되지 않는다. ​ ◆ SYSTEM 및 SYSAUX 테이블 스페이스   → 각 오라클 데이터베이스에는 생성시 자동으로 생성되는 SYSTEM 테이블스페이스 및 SYSAUX 테이블스페이스가 포함되어 있어야 한다. → 테이블스페이스는 온라인(액세스 가능) 상태이거나 오프라인(액세스 불가) 상태일 수 있다. 테이블스페이스가 열려 있는 경우 SYSTEM 테이블스페이스는 항상 온라인 상태이다. → SYSTME 테이블스페이스는 데이터 딕셔너리 정보 등 데이터베이스의 핵심 기능을 지원하는 테이블을 저장한다. → SYSAUX 는 SYSTEM의 보조 테이블스페이스 이다. 테이블스페이스 Recovery 를 수행하기 위해 오프라인으로 전환할 수 있지만 SYSTEM 테이블스페이스의 경우 불가능하다. 그리고 두 테이블스페이스 중 어느 한 쪽도 읽기 전용으로 설정할 수 없다. ​ ​ ​ ​ ​ 태그#sga#sga메모리#데이터베이스버퍼캐시#리두로그버퍼#sharedpool#largepool#javapool#streamspool     공감 2   이 글에 공감한 블로거 열고 닫기  댓글 쓰기  이 글에 댓글 단 블로거 열고 닫기 블로그 카페 Keep 메모 보내기 인쇄

[출처] SGA 메모리 구조의 이해|작성자 Oracle DBA