Database Storage: Key Components and Operational Structure
데이터베이스 저장구조, 동작구조, 실습 소프트웨어 설치
Contents
1️⃣데이터베이스 저장구조 (Database storage structure)
2️⃣데이터베이스 동작구조 (Database operation structure)
1️⃣데이터베이스 저장구조
(Database storage structure)
데이터베이스 생성 시 고려사항 1#: Consideration 1# when creating a database:
기본적인 RDBMS 기능 (Basic RDBMS functionality)
데이터 정확성 및 무결성 보장(Ensuring data accuracy and integrity)
데이터가 정확하게 저장되고 있으며, 데이터 사이의 주어진 관계와 규칙들이 잘지켜지도록 관리한다.
RDBMS는 데이터가 정확하게 저장되고 관리되도록 다양한 무결성 제약(Primary Key, Foreign Key, Unique, Not Null 등)을 제공한다. 이를 통해 데이터 간의 관계가 유지되고, 잘못된 데이터가 입력되는 것을 방지한다.
데이터 일관성 유지(Maintaining data consistency)
- 트랜잭션을 통해 데이터 일관성을 유지한다. 트랜잭션이란, 데이터베이스에서 일련의 작업들이 모두 성공하거나 실패해야 하는 작업 단위를 의미한다. 이는 원자성(Atomicity), 일관성(Consistency), 고립성(Isolation), 지속성(Durability)이라는 ACID 특성으로 보장된다.
장애 복구 및 안정성(Disaster recovery and stability)
시스템에 장애가 발생할 경우, 장애 이전의 일관성 있는 상태로의 복구를 보장
RDBMS는 시스템 장애 발생 시 데이터가 손실되지 않도록 복구 기능을 제공한다. 로그 파일, 백업, 복구 메커니즘을 통해 장애 이전의 일관성 있는 상태로 복구할 수 있다.
관계형 데이터 관리(Relational data management)
- 데이터베이스 내에 있는 데이터 및 데이터 사이의 관계를 관리
- 테이블 간의 관계를 정의하는 외래 키(Foreign Key) 등을 통해 데이터 간의 연결을 유지하며, 이를 통해 복잡한 쿼리도 쉽게 처리할 수 있게한.
- 트랜잭션 처리 및 성능 보장(Transaction processing and performance assurance)
- 데이터의 삽입, 삭제, 수정, 검색 등 트랜잭션 처리에 대한 성능을 보장
- 인덱스, 최적화된 쿼리 처리, 캐싱 등의 기법을 통해 트랜잭션 처리 속도를 높이고, 동시에 여러 사용자의 요청을 효과적으로 처리할 수 있게한다.
이러한 기능들을 통해 RDBMS는 데이터의 정확한 저장, 관리, 복구, 성능을 보장하며, 복잡한 데이터 관계를 효율적으로 처리할 수 있게된다.
데이터베이스 생성 시 고려사항 2#:
데이터베이스 생성 시 고려사항을 자세히 설명하자면, 데이터베이스의 용도에 따라 설계와 최적화 전략이 달라진다. 특히 OLTP(Online Transaction Processing)와 OLAP(Online Analytical Processing) 데이터베이스의 차이점에 맞게 설계를 진행해야 한다.
데이터베이스의 용도
OLTP(Online Transaction Processing): 주로 온라인 트랜잭션 처리를 위한 데이터베이스로, 많은 양의 데이터를 실시간으로 처리하고 빠르게 조회해야 한다. 금융 시스템, 주문 관리 시스템 등이 이에 해당한다.
특징: 다수의 사용자가 동시에 데이터에 접근하며, 데이터 삽입, 수정, 삭제가 빈번하게 일어난다.
설계 요구사항: 빠른 트랜잭션 처리를 위해 테이블을 정규화하고, 인덱스 최적화와 데이터 분리(샤딩)를 고려해야 한다.
OLAP(Online Analytical Processing): 분석 목적의 데이터베이스로, 대용량 데이터를 집계하고 분석하는 데 중점을 둔다. 비즈니스 인텔리전스(BI) 보고서 작성, 데이터 마이닝에 사용된다.
특징: 주로 읽기 전용 작업이 많고, 복잡한 쿼리를 사용해 데이터를 집계하거나 분석함.
설계 요구사항: 데이터를 비정규화하거나 인덱스를 최적화하여 대규모 데이터를 효율적으로 분석할 수 있도록 설계해야 함.
트랜잭션 처리 성능 최적화 (Transaction processing performance optimization)
정규화 레벨(Normalization level): 데이터 무결성을 유지하면서도 중복을 최소화하기 위해 테이블을 정규화한다. 그러나 과도한 정규화는 복잡한 조인을 야기하여 성능 저하를 일으킬 수 있다. 따라서 OLTP 시스템에서는 적절한 수준의 정규화가 필요하며, OLAP 시스템에서는 비정규화를 통해 쿼리 성능을 향상시킬 수 있다.
인덱스 전략: 트랜잭션 처리 성능을 높이기 위해 적절한 인덱스를 생성해야 한다. 특히, OLTP 시스템에서는 인덱스가 데이터를 빠르게 검색할 수 있도록 돕는다. 하지만 인덱스가 너무 많으면 데이터 삽입 및 수정 시 성능이 저하될 수 있으므로, 인덱스를 신중히 설계해야 한다.
데이터 분리(샤딩): 대규모 데이터베이스의 경우, 데이터베이스 성능을 향상시키기 위해 데이터를 여러 서버에 분산(샤딩)하여 저장한다. 이는 트랜잭션 처리 성능을 크게 개선할 수 있게 한다.
캐싱: 자주 조회되는 데이터를 메모리에 캐싱하여, 디스크 접근을 줄이고 응답 시간을 단축시킬 수 있다.
대용량 데이터에 따른 하드웨어 자원 필요
(Hardware resources required for large-scale data)하드웨어 자원: 대규모 데이터를 저장하고 처리하려면 충분한 디스크 용량, 메모리(RAM), CPU 성능이 요구된다. 특히 대규모 트랜잭션 처리를 필요로 하는 시스템에서는 성능을 보장하기 위한 고성능 하드웨어 선택이 중요하다.
디스크(DISK): 데이터를 저장할 공간을 충분히 확보해야 하며, 빠른 읽기/쓰기 성능을 위해 SSD와 같은 고속 저장장치를 사용하는 것이 일반적이다.
메모리(MEMORY): 캐싱 및 인덱스 처리를 위해 충분한 양의 메모리가 필요하다. 메모리가 부족하면 디스크에 의존하게 되어 성능 저하를 초래할 수 있다.
CPU: 복잡한 쿼리 처리와 많은 트랜잭션을 처리하기 위해 다수의 코어를 지원하는 고성능 CPU가 요구된다.
데이터 증가량 관리 (Managing data growth)
데이터 증가량 예측: 데이터베이스 설계 시 월별 또는 연간 데이터 증가량을 예측하여 적절한 저장 공간과 확장 계획을 수립해야 한다. 데이터가 급증할 경우 시스템 성능이 저하될 수 있으므로, 데이터 증가에 따른 확장성을 고려하는 것이 중요하다.
- 예: 데이터 아카이빙 전략을 수립하거나, 데이터 파티셔닝을 적용해 구간별로 데이터를 분리 관리하는 방법을 사용할 수 있다.
모니터링 및 관리: 데이터 증가를 모니터링하고, 용량이 부족하지 않도록 주기적으로 점검하며 적절한 하드웨어 자원 할당을 통해 데이터베이스가 지속적으로 운영되도록 관리해야 한다.
데이터베이스 파일 분포 (Database file distribution)
데이터베이스 파일의 분포: 데이터베이스 파일이 시스템 전체 성능에 큰 영향을 미치므로, 데이터를 저장하는 파일의 분포를 고려해야 한다. 모든 데이터를 한 디스크에 저장하면 I/O 병목이 발생할 수 있으므로, 여러 개의 독립된 디스크로 데이터를 분산하는 것이 성능을 향상시키는 데 도움이 된다.
독립 디스크에 파일 분배: 데이터 파일, 로그 파일, 인덱스 파일 등을 별도의 디스크에 분산시켜 저장하면 각 디스크가 독립적으로 작동하여 I/O 성능을 최적화할 수 있다. 이는 특히 대용량 트랜잭션을 처리하거나 대규모 데이터를 다루는 시스템에서 효과적이다.
요약하면, 데이터베이스의 용도에 맞춘 설계가 중요하며, OLTP와 OLAP 시스템의 특성에 맞게 트랜잭션 처리 성능을 높이는 방법들이 필요합니다. 또한 대용량 데이터를 효과적으로 저장하고 관리하기 위해 하드웨어 자원을 적절히 활용하는 것뿐만 아니라, 데이터 증가량을 예측하고 지속적으로 관리하는 것이 중요하다. 데이터베이스 파일의 분포를 고려한 분산 저장 전략을 통해 I/O 성능을 최적화하는 것도 필수적인 요소이다.
오라클 데이터베이스 저장구조 1#:
데이터베이스의 물리적 저장구조 (Physical structure of the database)
오라클 데이터베이스의 저장 구조에 대해 설명하자면, 데이터베이스는 물리적으로 디스크에 파일로 저장되며, 기본적으로 다음과 같은 파일들로 구성된다:
데이터 파일(Data Files): 실제 데이터를 저장하는 파일. 테이블, 인덱스 등의 데이터베이스 객체가 이 파일에 저장된다.
로그 파일(Online Redo Log Files): 데이터베이스 변경 사항을 기록하는 파일. 트랜잭션이 커밋될 때마다 로그 파일에 기록되어 장애 발생 시 복구할 수 있도록 도와준다.
콘트롤 파일(Control Files): 데이터베이스의 물리적 구조를 관리하는 파일. 데이터 파일, 로그 파일의 위치, 데이터베이스의 상태 정보 등을 포함하고 있으며, 데이터베이스의 정상적인 운영에 필수적이다.
이 구조는 Memory와 Disk로 나뉘며, 데이터베이스 인스턴스가 메모리에서 동작하고, 실제 데이터 및 로그는 디스크에 저장된다.
오라클 데이터베이스 저장구조 2#:
논리적 저장구조 (Logical storage structure)
오라클 데이터베이스의 저장 구조는 논리적 구조와 물리적 구조로 나뉜다.
논리적 저장구조(Logical):
테이블스페이스(Tablespace): 데이터베이스의 논리적 저장 공간으로, 하나 이상의 데이터 파일로 구성된다. 각 테이블스페이스는 여러 개의 세그먼트를 포함할 수 있다.
세그먼트(Segment): 테이블, 인덱스와 같은 논리적 저장 단위를 나타낸다. 세그먼트는 여러 익스텐트로 이루어져 있으며, 데이터가 저장되는 실제 공간이다.
익스텐트(Extent): 연속된 데이터 블록들의 집합으로, 세그먼트가 데이터를 저장할 때 할당되는 단위이다.
데이터 블록(Oracle Data Block): 오라클 데이터베이스의 가장 작은 논리적 저장 단위이다. 각 블록은 오퍼레이팅 시스템 블록의 여러 개에 매핑될 수 있다.
물리적 저장구조(Physical):
- 데이터 파일(Data File): 테이블스페이스와 연관된 물리적 파일로, 데이터를 저장하는 실제 파일이다.
- OS 블록(OS Block): 운영 체제의 저장 단위로, 데이터 파일 안에서 논리적 데이터 블록이 실제로 저장되는 물리적 블록이다.
논리적 구조와 물리적 구조는 상호 연결되어 있으며, 논리적 구조는 사용자가 데이터를 관리하는 방식에 해당하고, 물리적 구조는 그 데이터가 실제로 디스크에 어떻게 저장되는지를 나타낸다.
💡데이터 블록(Oracle Data Block)이 중요한이유는?
데이터 블록(Oracle Data Block)이 중요한 이유는 오라클 데이터베이스의 기본적인 저장 및 관리 단위로서, 데이터베이스 성능과 저장 구조에 중요한 영향을 미치기 때문이다.
저장 단위: 오라클 데이터베이스에서 가장 작은 논리적 저장 단위가 데이터 블록이다. 모든 데이터(테이블, 인덱스 등)가 데이터 블록 안에 저장되며, 데이터베이스는 이 블록 단위로 데이터를 읽고 쓴다. 따라서, 효율적인 데이터 블록 관리가 전체 데이터베이스 성능에 직결된다.
I/O 효율성: 데이터 블록은 오라클에서 디스크 I/O 작업의 기본 단위로 사용된다. 오라클 데이터베이스는 데이터를 읽고 쓸 때 블록 단위로 처리하므로, 블록 크기(Block Size)를 잘 설정하면 디스크 I/O를 최적화할 수 있다. 적절한 데이터 블록 크기를 선택하면 대량의 데이터를 효율적으로 처리할 수 있다.
💡 I/O 입출력 횟수가 오라클 데이터 블록과 연관이 있는 이유는?
I/O 입출력 횟수가 오라클 데이터 블록과 연관이 있는 이유는 데이터베이스가 데이터를 블록 단위로 처리하기 때문이다. 데이터 블록의 크기, 배치, 캐싱 여부, 그리고 트랜잭션 처리 방식 등은 디스크 I/O의 효율성을 결정하며, 최적화된 데이터 블록 관리는 전체 I/O 성능을 크게 개선할 수 있다.
💡I/O 입출력 횟수가 적을 수록 성능이 늘어나는 건가요?
I/O 입출력 횟수가 적을수록 데이터베이스 성능이 좋아지는 것은 디스크 접근의 속도 차이와 병목 현상 때문이다. 성능을 최적화하려면 메모리 캐시를 최대한 활용하고, 효율적인 데이터 블록 관리와 최적의 I/O 전략을 사용하는 것이 중요하다.
💡I/O 입출력 횟수는 오라클 데이터 블록을 읽을때마다 늘어나나요?
오라클 데이터베이스는 데이터 블록(Oracle Data Block)을 기본 단위로 데이터를 저장하고, 읽고 쓴다. 데이터베이스가 데이터를 검색하거나 트랜잭션을 처리할 때, 필요한 데이터를 디스크에서 읽어올 때마다 해당 블록을 메모리로 가져오기 위해 I/O 작업이 발생한다.
각 I/O 작업은 데이터 블록을 읽거나 쓰는 단위로 발생하며, 데이터 블록이 여러 개 필요하다면 그만큼 I/O 횟수가 늘어난다.
I/O 횟수를 줄이기 위해서는 적절한 블록 크기 설정, 캐시 최적화, 데이터 블록의 연속성 등을 고려하는 것이 중요하다.
오라클 데이터베이스 저장구조 3#:
테이블스페이스(Tablespace)
위의 이미지는 오라클 테이블스페이스(Tablespace)의 구조를 설명하고 있다. 테이블스페이스는 논리적인 데이터 저장 구조로, 데이터를 저장하는 여러 데이터 파일(Data Files)로 구성되며, 세그먼트(Segments)가 그 안에 저장된다. 결론적으로 데이터가 물리적으로는 데이터 파일에 저장되지만 논리적으로는 테이블스페이스와 세그먼트를 통해 관리된다는 점을 강조하고 있다.
테이블스페이스(Tablespace) 개념 및 역할:
테이블스페이스는 오라클 데이터베이스의 논리적인 데이터 저장 구조로, 하나 또는 여러 개의 데이터 파일(Data Files)로 구성된다. 데이터베이스 내에서 데이터 저장 공간을 관리하는 가장 큰 논리적 단위이다. 참고로 테이블스페이스는 물리적인 실체가 아닌 논리적인 데이터 저장 구조이다. 즉, 테이블스페이스 자체는 물리적인 디스크 파일이나 특정 파일로 직접 눈에 보이는 것이 아니다.
주요 특징:
하나 이상의 테이블스페이스로 구성:
- 오라클 데이터베이스는 기본적으로 하나 이상의 테이블스페이스로 구성된다. 테이블스페이스는 데이터베이스의 논리적 구조로서 데이터를 저장할 수 있는 논리적 저장소 역할을 한다.
데이터 파일과의 관계:
테이블스페이스는 하나 이상의 데이터 파일로 구성된다. 각 데이터 파일은 물리적으로 디스크에 저장되며, 테이블스페이스는 이러한 데이터 파일들을 묶어서 논리적으로 관리하는 역할을 한다.
테이블스페이스에 추가되는 데이터 파일은 데이터 저장 공간을 확장하는 역할을 함
스키마 객체의 저장 공간:
- 테이블스페이스는 스키마 객체(테이블, 인덱스, 뷰, 클러스터, 시퀀스, 저장 프로시저 등)가 저장되는 공간이다. 즉, 데이터베이스에서 생성된 모든 객체는 테이블스페이스 안에 저장된다.
기본 테이블스페이스:
오라클은 기본적으로 네 가지 테이블스페이스를 제공한다:
SYSTEM: 데이터베이스의 핵심 메타데이터와 데이터 사전을 저장하는 테이블스페이스이다.
UNDO: 트랜잭션 중에 발생한 변경 사항을 기록하며, 트랜잭션 롤백을 위한 공간이다.
SYSAUX: 보조 시스템 테이블스페이스로, 데이터베이스에서 다양한 보조 데이터를 저장하는 데 사용된다.
TEMP: 임시 데이터를 저장하는 테이블스페이스로, 대규모 정렬이나 임시 데이터를 처리하는 데 사용된다.
사용자 정의 테이블스페이스:
- 사용자는 필요에 따라 추가적인 테이블스페이스를 생성하거나 삭제할 수 있다. 이는 데이터베이스 확장 또는 특정 데이터를 분리 저장하는 등의 목적으로 활용된다.
요약:
오라클 데이터베이스에서 테이블스페이스는 데이터를 저장하고 관리하는 논리적 구조로서, 데이터를 담고 있는 데이터 파일을 그룹화하여 구성된다. 테이블스페이스는 데이터를 저장할 수 있는 다양한 스키마 객체들을 담고 있으며, 사용자가 필요에 따라 추가로 생성하거나 관리할 수 있도록 되어있다.
오라클 데이터베이스 저장구조 4#:
세그먼트(Segment)
이 이미지는 오라클 데이터베이스 저장구조에서 세그먼트(Segment)가 어떻게 생성되고 관리되는지를 설명하고 있다. 특히 SQL 명령어가 실행된 후, 해당 명령어에 의해 생성된 스키마 객체(Schema Object)와 이 객체가 저장되는 세그먼트의 관계를 시각적으로 나타낸다.
설명:
SQL 명령어:
예시에서 보이는 SQL 명령어는
CREATE TABLE test_table로,my_column이라는 열을 가지는 테이블을 생성하는 명령어이다.이 명령어가 실행되면 테이블(test_table)이라는 스키마 객체가 데이터베이스에 생성된다.
스키마 객체(Schema Object):
- 이 명령어에 의해 생성된 test_table은 스키마 객체이다. 스키마 객체는 데이터베이스에서 테이블, 인덱스, 뷰, 시퀀스 등과 같은 구조를 말하며, 이들은 모두 테이블스페이스 내에서 관리된다.
세그먼트(Segment):
생성된 스키마 객체(test_table)는 실제 데이터를 저장하기 위해 세그먼트를 할당받는다. 세그먼트는 테이블, 인덱스, 클러스터 등의 객체들이 데이터를 저장할 수 있는 공간을 뜻한다.
각 세그먼트는 여러 개의 데이터 블록으로 구성되며, 이러한 데이터 블록들은 하나 이상의 데이터 파일에 분산되어 저장될 수 있다.
결론:
위 그림은 SQL 명령어를 통해 스키마 객체가 생성되고, 이 객체가 세그먼트에 의해 논리적인 데이터 저장 공간을 할당받는 과정을 보여주고 있다. 오라클 데이터베이스는 테이블이나 인덱스 같은 스키마 객체들을 세그먼트에 저장하고 관리하여, 물리적인 데이터 저장을 논리적으로 관리한다.
오라클 데이터베이스 저장구조 5#:
데이터블록(Data Block)
위의 이미지는 오라클 데이터블록(Data Block)의 내부 구조를 시각적으로 설명하고 있다. Row Header, Column Data, Free Space, Row Directory 등의 영역으로 구성된다. 데이터가 효율적으로 저장되고 관리되기 위해 이러한 구성 요소들이 상호작용하며, 데이터베이스 성능에 영향을 미친다.
데이터 블록의 주요 구성 요소:
Row Header:
- 각 행(Row)에 대한 메타데이터를 저장한다. 여기에는 행의 상태 정보, 열(Column)의 개수, 체인된 행 조각(Chained Row Pieces)의 정보 등이 포함된다. 즉, 행 자체에 대한 부가적인 정보를 담고 있는 영역이다.
Column Data (열 데이터):
- 실제 데이터가 저장되는 부분이다. 각 열(Column)의 데이터 값이 저장되며, 데이터블록 내부에서 Row Piece(행 조각)로 표현된다. 이때, 각 열의 길이와 값이 이 영역에 저장된다.
Row Piece in a Database Block (데이터 블록 내 행 조각):
- 데이터가 한 행(Row) 단위로 저장되며, 행의 크기가 클 경우 여러 데이터 블록에 걸쳐서 저장될 수 있다. 이 경우 체인된 행 조각(Chained Row Pieces)이 발생하며, 이는 여러 데이터 블록에 걸쳐 분산될 수 있다.
Row Overhead:
- 각 행에 대한 오버헤드(추가적인 메타데이터)로, 행의 관리와 관련된 정보가 포함된 부분이다. 여기에는 열의 개수, 체인된 행의 참조 정보 등이 들어 있다.
Table Directory:
- 데이터 블록 내에서 테이블의 시작 위치를 나타내는 디렉토리 역할을 한다. 여러 테이블이 하나의 데이터 블록에 저장될 수 있기 때문에, 테이블의 위치를 효율적으로 찾기 위한 정보를 제공한다.
Row Directory:
- 데이터 블록 내에서 행(Row)의 시작 위치를 나타내는 디렉토리이다. 여러 행이 데이터 블록 내에 저장될 때, 각 행의 위치를 관리하는 역할을 한다.
Free Space (여유 공간):
- 데이터가 저장된 후 남은 여유 공간이다. 데이터블록에 여유 공간이 남아 있으면 추가적인 데이터 삽입 시 이 공간이 사용된다. 여유 공간이 부족해지면 새로운 블록이 할당되어 데이터가 저장된다.
Common and Variable Header (공통 및 가변 헤더):
- 각 데이터블록에는 공통 헤더와 가변 헤더가 포함된다. 이 영역에는 데이터 블록에 대한 전체적인 정보가 저장되며, 데이터블록을 관리하는 데 필요한 추가적인 메타데이터가 포함된다.
데이터블록(Oracle Data Block)은 오라클 데이터베이스에서 가장 작은 저장 단위이다. 오라클 데이터베이스에서 모든 데이터는 이 데이터블록 단위로 저장되며, I/O 작업도 블록 단위로 처리된다. 데이터블록은 때때로 오라클 블록 또는 페이지(Page)라고도 불리기도 한다.
주요 특징:
가장 작은 저장 단위:
- 데이터블록은 오라클 내에서 데이터를 저장하는 가장 작은 단위이다. 테이블이나 인덱스와 같은 데이터베이스 객체는 데이터블록에 저장되며, 오라클은 데이터를 읽고 쓸 때 데이터블록 단위로 작업한다.
물리적 저장 공간:
- 데이터블록은 물리적 하드디스크 상에 존재하는 실제 저장 공간을 의미한다. 즉, 각 데이터블록은 디스크에서 특정 공간을 차지하고 있으며, 데이터베이스가 생성될 때 오라클 파라미터 파일에서 데이터블록의 크기를 지정할 수 있다.
데이터블록 크기 설정:
- 오라클에서는 데이터블록의 크기를 2K, 4K, 8K, 16K, 32K, 64K 중에서 선택할 수 있다. 데이터베이스의 크기와 용도에 따라 적절한 블록 크기를 설정할 수 있으며, 이는 데이터베이스의 성능에 큰 영향을 미친다.
데이터블록 크기와 I/O의 관계:
데이터블록 크기가 클 경우:
I/O 횟수 감소: 데이터블록의 크기가 크면 한 번의 I/O 작업으로 더 많은 데이터를 읽고 쓸 수 있으므로, I/O 작업 횟수가 줄어든다. 이는 I/O 성능 최적화에 유리하다.
- 공간 낭비: 반면, 데이터가 블록보다 작으면 남은 공간이 사용되지 않고 낭비될 수 있다. 즉, 저장되는 데이터의 크기보다 큰 데이터블록은 공간 낭비를 초래한다.
데이터블록 크기가 작을 경우:
I/O 횟수 증가: 데이터블록의 크기가 작으면, 데이터를 읽고 쓰기 위해 더 많은 I/O 작업이 필요하게 되어 I/O 횟수가 증가한다. 이는 성능 저하로 이어진다.
공간 낭비 감소: 그러나 블록 크기가 작으면 데이터가 더 효율적으로 저장되어, 공간 낭비는 줄어든다. 작은 데이터 단위가 저장될 때 불필요한 공간 낭비가 발생하지 않기 때문에 효율적으로 저장할 수 있다.
결론:
데이터블록은 오라클 데이터베이스에서 데이터를 저장하고 관리하는 가장 작은 단위이며, 데이터블록의 크기 선택은 I/O 성능과 저장 공간 효율성에 큰 영향을 미친다. 블록 크기가 클수록 I/O 작업이 줄어들어 성능이 향상될 수 있지만, 그만큼 공간 낭비가 발생할 수 있으며, 반대로 블록 크기가 작으면 I/O 작업이 늘어나지만 저장 공간의 낭비를 줄일 수 있다. 따라서 시스템의 특성에 맞는 적절한 블록 크기를 설정하는 것이 중요하다.
오라클 데이터베이스 저장구조 6#:
익스텐트(Extent)
익스텐트(Extent)는 오라클 데이터베이스에서 연속적인 데이터 블록들을 묶어놓은 논리적 저장 단위입니다. 익스텐트는 데이터 저장 공간을 보다 효율적으로 관리하고, 데이터를 연속적으로 저장하여 성능을 최적화하는 데 중요한 역할을 합니다.
주요 특징:
연속적인 블록들의 묶음:
- 익스텐트는 연속적으로 있는 데이터 블록을 묶어 관리한다. 이러한 연속적인 블록들은 테이블이나 인덱스와 같은 데이터베이스 객체가 데이터를 저장할 때 사용된다. 여러 개의 데이터 블록을 묶어서 익스텐트로 관리함으로써, 데이터가 분산되지 않고 연속적인 형태로 저장된다.
효율적인 데이터 관리:
- 데이터를 연속적인 블록에 저장하면 디스크 I/O 작업을 최소화할 수 있어 성능이 향상된다. 연속된 데이터 블록을 하나의 익스텐트로 묶어 관리하면 데이터 검색과 같은 작업이 효율적으로 처리될 수 있다. 이는 특히 대량의 데이터를 처리할 때 성능 최적화에 기여한다.
초기 크기와 확장:
테이블이나 인덱스 같은 데이터베이스 객체를 처음 생성할 때, 해당 객체가 사용할 초기 익스텐트 크기를 정의할 수 있다. 즉, 테이블을 생성할 때 첫 번째 익스텐트의 크기를 설정하고, 그 크기만큼의 블록이 할당된다.
이후, 저장공간이 부족해지면 오라클은 자동으로 추가 익스텐트를 할당한다. 이렇게 추가된 익스텐트는 테이블이 더 많은 데이터를 저장할 수 있도록 공간을 확장해주는 역할을 한다.
요약: 익스텐트(Extent)는 연속적인 데이터 블록을 묶어 효율적으로 관리하는 논리적 단위이다. 데이터베이스 객체가 데이터를 저장할 때 익스텐트가 할당되고, 저장 공간이 부족해지면 추가 익스텐트가 할당되어 공간이 확장된다. 이를 통해 데이터의 연속성 유지와 I/O 성능 최적화를 도모할 수 있다.
2️⃣데이터베이스 동작구조
(Database operation structure)
데이터베이스 아키텍쳐(Database Architecture) 1#: 트랜잭션(Transaction)
트랜잭션(Transaction)은 데이터베이스에서 하나의 논리적인 작업 단위로, 여러 데이터베이스 작업(쿼리)이 모두 성공하거나 모두 실패해야 하는 집합을 의미한다. 트랜잭션은 ALL or NOTHING의 원칙에 따라, 작업이 일부만 완료되는 일이 없도록 보장하게 된다. 트랜잭션의 성공 시 모든 작업이 커밋(commit)되며, 실패 시 롤백(rollback)되어 작업이 취소된다.
트랜잭션의 주요 특징:
ACID 특성:
원자성(Atomicity): 트랜잭션은 모두 실행되거나, 전혀 실행되지 않아야 한다. 하나의 작업이라도 실패하면 트랜잭션 전체가 취소되게 된다.
일관성(Consistency): 트랜잭션이 완료되면 데이터베이스는 일관성 있는 상태로 유지된다.
고립성(Isolation): 트랜잭션은 서로 독립적으로 실행되며, 다른 트랜잭션이 처리 중인 데이터를 볼 수 없다.
지속성(Durability): 트랜잭션이 성공적으로 완료되면, 그 결과는 영구적으로 저장된다.
ALL or NOTHING:
- 트랜잭션은 완전하게 처리되거나 전혀 처리되지 않아야 한다. 예를 들어, 여러 단계로 이루어진 트랜잭션에서 일부 단계만 완료되는 상황을 방지하기 위해, 모든 단계가 성공해야만 트랜잭션이 커밋된다. 하나의 단계라도 실패하면 트랜잭션은 모두 롤백되어 이전 상태로 복구된다.
트랜잭션 예시:
계좌 이체 트랜잭션:
- 다음은 계좌 이체 작업에서 발생하는 트랜잭션의 예시이다.
UPDATE savings_accounts
SET balance = balance - 1000000
WHERE account_id = 12345;
-- 1,000,000원을 저축 계좌에서 차감
UPDATE checking_accounts
SET balance = balance + 1000000
WHERE account_id = 67890;
-- 같은 금액을 당좌 계좌로 추가
- 이 예시는 한 계좌에서 1,000,000원을 출금하고, 다른 계좌로 1,000,000원을 입금하는 작업이다. 이 두 명령어는 하나의 트랜잭션으로 묶여 처리되어야 하며, 하나라도 실패하면 둘 다 롤백되어 출금도, 입금도 모두 취소되게 된다.
ALL or NOTHING 적용:
- 위 작업에서 만약 출금 작업은 성공하고 입금 작업이 실패한다면, 트랜잭션은 모두 취소(rollback)되어, 돈이 빠져나가거나 잘못 입금되는 상황을 방지할 수 있다.
트랜잭션의 중요성:
데이터 무결성: 트랜잭션은 여러 작업이 복합적으로 이루어지는 상황에서도 데이터의 일관성을 유지할 수 있도록 보장한다.
에러 처리: 작업 중에 에러가 발생해도 트랜잭션 덕분에 데이터의 손상이나 일관성 깨짐을 방지할 수 있다.
복구 기능: 트랜잭션은 장애나 시스템 에러가 발생하더라도 트랜잭션 이전 상태로 복구할 수 있는 메커니즘을 제공한다.
결론:
트랜잭션은 데이터베이스에서 여러 명령어를 하나의 묶음으로 처리하여 일관성과 무결성을 보장한다. 특히, 모든 명령어가 성공해야만 트랜잭션이 커밋되며, 실패 시 롤백하여 이전 상태로 복구된다. 이러한 트랜잭션 관리는 은행 시스템과 같이 중요한 데이터를 다루는 곳에서 필수적인 개념이다.
트랜잭션의 예시 #2
위의 예시는 트랜잭션(Transaction)을 시작하고 실행한 후, 그 결과를 커밋(COMMIT)하는 과정을 보여준다. 트랜잭션 이름을 설정하고 두 개의 계좌에 대해 업데이트 작업을 수행한 후, 변경 사항을 데이터베이스에 영구적으로 반영하게 된다..
트랜잭션 이름 설정:
SET TRANSACTION NAME 'bal_update';- 이 명령은 트랜잭션에 이름을 부여하는 것. 이 경우 트랜잭션의 이름은
'bal_update'로 설정되었다. 트랜잭션 이름은 디버깅이나 로그 기록 시 유용할 수 있으며, 특정 트랜잭션을 식별하는 데 도움이 된다.
- 이 명령은 트랜잭션에 이름을 부여하는 것. 이 경우 트랜잭션의 이름은
첫 번째 업데이트 (저축 계좌):
UPDATE savings_accounts SET balance = balance - 1000000 WHERE account = '3209';- 계좌 번호 3209에서 저축 계좌(savings_accounts)의 잔액을 1,000,000원 차감하는 작업이다 이 업데이트는 트랜잭션의 일부로 처리되며, 아직 커밋되지 않았다.
두 번째 업데이트 (당좌 계좌):
UPDATE checking_accounts SET balance = balance + 1000000 WHERE account = '3208';- 계좌 번호 3208의 당좌 계좌(checking_accounts)에 1,000,000원을 추가하는 작업이다. 이 역시 트랜잭션의 일부로, 첫 번째 업데이트와 함께 커밋 전까지는 실제로 반영되지 않는다.
커밋(COMMIT):
COMMIT;- 커밋 명령어는 트랜잭션에서 수행된 모든 변경 사항을 영구적으로 데이터베이스에 반영한다. 이때, 두 개의 업데이트가 모두 성공적으로 반영된다. 트랜잭션이 커밋되기 전까지는 데이터베이스에 변경 사항이 반영되지 않으며, 중간에 문제가 발생할 경우 롤백(rollback)될 수 있다.
트랜잭션 설명:
트랜잭션 이름 설정: 트랜잭션에 이름을 부여하면 나중에 어떤 트랜잭션이 어떤 작업을 수행했는지 쉽게 추적할 수 있게 된다. 예를 들어, 로그나 모니터링 시스템에서
'bal_update'라는 이름을 보고 이 트랜잭션이 계좌 잔액을 수정하는 작업임을 쉽게 알 수 있다.UPDATE 작업: 두 개의 UPDATE 문은 각각 저축 계좌에서 잔액을 차감하고, 당좌 계좌에 잔액을 추가하는 작업이다. 이 작업들은 모두 트랜잭션 안에서 처리되기 때문에 중간에 하나라도 실패하면 전체 트랜잭션이 롤백된다.
COMMIT: 커밋은 모든 작업을 성공적으로 마무리하고 데이터베이스에 영구적으로 적용하는 단계이다. 커밋 이후에는 더 이상 롤백할 수 없으며, 데이터가 확정적으로 변경된다.
요약:
이 트랜잭션 예시는 계좌 간 잔액 이체라는 전형적인 예시로, 출금과 입금 작업이 한 트랜잭션 내에서 처리된다. 이를 통해 데이터베이스의 일관성을 유지하면서, 실패 시 롤백되고 성공 시 영구적으로 반영되는 트랜잭션의 핵심 원리를 설명하고 있다.
데이터베이스 아키텍쳐(Database Architecture) 2#:
DBMS 동작 구조(DBMS Operation Structure)
위의 이미지는 DBMS(데이터베이스 관리 시스템)의 동작 구조를 설명하는 다이어그램이다. DBMS 간의 상호작용이 서버 프로세스를 통해 어떻게 상호작용하는지, 그리고 데이터베이스 파일에 접근하는 과정과 어떻게 관리되는지를 보여주고 있다.
주요 구성 요소:
Database Management System (DBMS):
- 데이터베이스 관리 시스템은 사용자 클라이언트와 데이터베이스 간의 상호작용을 관리하는 시스템이다. 사용자가 요청한 데이터를 처리하고, 데이터베이스에 저장되거나 수정된 데이터를 반환하는 역할을 한다.
데이터베이스 서버 프로세스:
서버 프로세스는 DBMS 내에서 사용자의 요청을 처리하는 중요한 프로세스이다. 사용자가 SQL 쿼리를 통해 데이터를 조회하거나 수정하는 요청을 보내면, 이 프로세스가 해당 요청을 처리하여 데이터베이스와 상호작용을 하게 된다.
서버 프로세스는 트랜잭션 관리, 질의 처리, 데이터 검색 및 수정 등 다양한 작업을 수행하며, 데이터베이스의 안정적이고 일관된 상태를 유지하는 역할을 한다.
데이터베이스(파일):
데이터베이스 파일은 실제로 데이터를 저장하는 물리적인 파일이다. 사용자가 생성한 테이블, 인덱스, 트랜잭션 정보 등 모든 데이터는 이 데이터베이스 파일에 저장된다.
DBMS는 이러한 데이터 파일을 효율적으로 관리하고, 서버 프로세스를 통해 데이터를 읽고 쓰는 작업을 처리한다.
사용자 클라이언트:
사용자 클라이언트는 데이터베이스에 접근하는 사용자 측의 프로그램이나 인터페이스이다. 이는 애플리케이션, SQL 인터페이스 또는 기타 툴을 통해 DBMS에 연결된다.
클라이언트는 데이터를 입력하거나, 조회, 수정, 삭제와 같은 작업을 서버 프로세스에 요청한다. 서버는 요청을 처리하고 결과를 클라이언트에게 반환하게 된다.
동작 과정:
사용자 요청:
- 사용자가 클라이언트를 통해 데이터베이스에 SQL 쿼리를 보내면, 요청이 DBMS의 서버 프로세스에 전달된다.
서버 프로세스 처리:
- 서버 프로세스는 클라이언트로부터 받은 요청을 처리한다. 트랜잭션 관리, 데이터 검색, 수정, 삭제와 같은 작업을 처리하고, 데이터베이스 파일에 저장된 데이터를 한다.
데이터베이스 파일 액세스:
- 서버 프로세스는 필요한 데이터를 데이터베이스 파일에서 검색하거나 수정하여 클라이언트의 요청에 응답한다.
응답 반환:
- 처리된 결과는 서버 프로세스에서 클라이언트로 반환되며, 사용자는 요청한 데이터나 수행된 작업의 결과를 확인할 수 있게 된다.
💡데이터베이스 아키텍쳐(Database Architecture) 3#:
SQL문(트랜잭션)이 동작하는 과정
(The process of how an SQL statement (transaction) operates)💡
이 이미지는 SQL문(트랜잭션)이 동작하는 과정을 설명하는 다이어그램으로, 사용자 클라이언트가 SQL 쿼리를 보내고 그 결과가 반환되는 과정을 시각적으로 나타내고 있다. 간단하게 설명하면 클라이언트가 SQL 요청을 보내면 데이터베이스 서버가 데이터를 읽고, 로그 파일에 기록하며, 데이터 변경을 처리한 후 그 결과를 클라이언트에게 반환하는 구조이다. Buffer Cache와 로그 파일을 통해 성능 향상과 데이터 무결성을 동시에 보장하는 역할을 한다. SQL문이 실행될 때 데이터베이스에서 어떤 작업이 이루어지는지 단계별로 살펴보자.
SQL문(트랜잭션)이 동작하는 과정:
사용자 요청 (조회/변경):
- 사용자 클라이언트가 SQL 쿼리(예: SELECT, UPDATE, INSERT)를 데이터베이스 서버로 보낸다. 이 단계에서 사용자는 데이터를 조회하거나 변경을 요청한다.
데이터 읽기 (Buffer Cache):
데이터베이스 서버는 클라이언트의 요청에 따라 Buffer Cache를 참조하여, 필요한 데이터가 메모리에 있는지 확인한다.
Buffer Cache에 데이터가 없으면 디스크의 데이터 파일에서 해당 데이터를 읽어와서 캐시에 저장하고, 이를 처리한다.
로그 기록:
데이터베이스 서버는 트랜잭션을 처리하면서 로그 파일(Redo Log)에 해당 작업을 기록한다. 로그 파일은 트랜잭션의 시작, 변경된 내용, 커밋 등의 정보가 기록된다.
이러한 로그는 장애 발생 시 트랜잭션을 복구할 때 사용된다.
커밋 이전에는 변경 사항이 데이터 파일에 영구적으로 저장되지 않으며, 트랜잭션이 완료되기 전까지는 변경 사항이 메모리나 로그 파일에만 기록된다. 커밋이 수행된 이후에만 데이터베이스에 영구적으로 반영된다.
데이터 쓰기:
트랜잭션이 완료되면, 변경된 데이터는 데이터 파일에 반영된다. 이 과정은 일반적으로 Checkpoint라는 메커니즘에 의해 트랜잭션의 변경 사항이 디스크에 영구적으로 저장된다.
데이터는 데이터 블록 단위로 관리되며, 일반적인 데이터 블록 크기는 8KB이다.
결과 반환:
- SQL문이 성공적으로 실행된 후, 결과가 사용자 클라이언트로 반환된다. 만약 데이터 변경 작업이 완료되면 그 결과가, 조회 작업일 경우 조회된 데이터가 반환된다.
추가 설명:
Buffer Cache: 자주 사용되는 데이터는 Buffer Cache라는 메모리에 저장되어 I/O 작업을 줄인다. 이 캐시는 성능 향상을 위해 중요한 역할을 하며, 데이터 조회 및 쓰기 작업이 우선 캐시에서 이루어진다.
로그 파일 (Redo Log): 트랜잭션이 진행되는 동안 변경된 데이터는 로그 파일에 기록된다. 로그 파일은 장애 복구와 트랜잭션의 일관성을 보장하는 데 중요한 역할을 한다.
데이터 파일: 실제 데이터는 디스크에 저장된 데이터 파일에 저장된다. 이 파일은 트랜잭션이 완료되고 커밋되면 변경된 데이터가 반영된다.
Checkpoint: 주기적으로 체크포인트(Checkpoint)가 발생하여, 데이터베이스의 현재 상태를 디스크에 저장한다. 이 작업은 로그 파일과 데이터 파일을 동기화하여 데이터 일관성 유지를 돕는다.
커밋(Commit): 트랜잭션이 커밋되면, 트랜잭션 내에서 변경된 모든 사항이 영구적으로 데이터베이스에 반영된다. 이때, 커밋 이전까지는 데이터 파일에 변경 사항이 쓰여지지 않으므로, 트랜잭션이 중간에 실패하거나 롤백(ROLLBACK)되면 변경 사항은 무효화된다.
데이터베이스 아키텍쳐(Database Architecture) 4#:
DBMS 성능 (DBMS Performance)
데이터베이스 성능을 최적화하기 위해서는 디스크 I/O를 줄이고 메모리 I/O를 극대화하는 방향으로 설계해야 하며, 장애 발생 시 신속한 복구 능력을 갖추어야 한다. 또한 다중 사용자 환경에서의 데이터 일관성을 유지하는 것이 매우 중요하다. 성능 최적화와 데이터 무결성을 모두 고려한 설계가 필요하다. DBMS 서비스는 디스크 I/O 줄이기와 메모리 I/O 최적화, 장애 복구 및 오류 처리, 다중 사용자 환경에서 데이터 일관성 보장을 담당하게 된다.
데이터베이스(DBMS) 성능에 영향을 미치는 주요 요소는 다음과 같다:
1. 디스크 I/O 줄이기와 메모리 I/O 최적화
(Reducing disk I/O and optimizing memory I/O)
디스크 I/O는 물리적 디스크에서 데이터를 읽고 쓰는 작업으로, 속도가 느리고 데이터베이스 성능의 주된 병목 현상을 일으킬 수 있다. 이를 최소화하기 위해 설계는 메모리 I/O를 최대한 활용하는 방향으로 이루어져야 한다.
Buffer Cache와 같은 메모리 캐시를 효과적으로 사용하여, 자주 참조되는 데이터를 메모리에 저장함으로써 디스크 접근 횟수를 줄일 수 있다. 이를 통해 성능을 향상시킬 수 있다
2. 장애 복구 및 오류 처리(Disaster recovery and error handling)
데이터베이스는 장애나 오류 발생 시 데이터를 원상태로 복구할 수 있는 메커니즘이 있어야 한다. 이를 위해 로그 파일(Redo Log), Checkpoint, 백업 및 복구 전략이 중요하다.
성능 최적화와 함께, 장애 발생 시 데이터 무결성과 일관성을 유지하는 것도 중요하다. 트랜잭션 처리 도중 오류가 발생하면, 데이터베이스는 트랜잭션을 롤백하여 이전 상태로 복구해야 한다.
3. 다중 사용자 환경에서 데이터 일관성 보장
(Ensuring data consistency in a multi-user environment)
데이터베이스는 여러 사용자가 동시에 접근하여 데이터를 조회하거나 수정하는 다중 사용자 환경에서 데이터 일관성을 보장해야 한다.
이를 위해 트랜잭션의 고립성(Isolation)이 필요하며, 이를 통해 하나의 트랜잭션이 완료될 때까지 다른 트랜잭션이 영향을 받지 않도록 한다. 또한, 락(Lock) 메커니즘을 사용해 동시에 동일한 데이터를 수정하는 문제를 방지한다.
동시성 제어와 락킹(Locking) 전략을 통해 데이터 충돌을 방지하고 성능을 높일 수 있다.
오라클 데이터베이스 아키텍쳐(Oracle Database Architecture) 1#:
오라클 인스턴스(서버), Oracle Instance
위의 다이어그램은 오라클 데이터베이스 아키텍처에서 메모리(SGA와 PGA), 백그라운드 프로세스(DBWn, LGWR 등), 클라이언트-서버 프로세스, 그리고 데이터베이스 영역(데이터 파일과 로그 파일) 간의 상호작용을 시각적으로 설명하고 있다. 각 요소는 데이터베이스 성능 최적화, 데이터 무결성 보장, 그리고 장애 복구를 위해 중요한 역할을 한다. 덧붙여서 오라클 인스턴스는 메모리와 백그라운드 프로세스로 구성되며, 데이터베이스와 상호작용하여 클라이언트의 요청을 처리한다.
1. 메모리 영역 (SGA - System Global Area)
SGA(시스템 글로벌 영역): 오라클 데이터베이스 인스턴스에서 사용되는 메모리 영역으로, 여러 사용자가 공유하는 데이터와 정보를 저장하는데 사용된다.
Shared Pool (공유 풀):
Library Cache: 자주 사용되는 SQL 명령어와 PL/SQL 코드가 저장되며, 캐시된 정보를 사용하여 재사용할 수 있도록 한다.
Data Dictionary Cache: 오라클 데이터베이스의 메타데이터(테이블, 인덱스, 사용자 정보 등)를 캐싱하여 빠른 조회를 가능하게 한다.
Large Pool: 백업 및 복구 작업, I/O 요청 등을 처리하는 데 사용되는 큰 메모리 영역이다.
Database Buffer Cache: 디스크에서 읽은 데이터를 메모리에 캐싱하여 I/O 작업을 줄이고 성능을 향상시키는 역할을 한다.
Redo Log Buffer: 트랜잭션이 발생할 때 로그 정보를 임시로 저장하는 영역이다. 나중에 Redo 로그 파일로 기록된다.
2. 프로세스 영역 (Background Processes)
DBWn (Database Writer): 메모리에서 디스크로 데이터를 쓰는 프로세스이다.
LGWR (Log Writer): Redo 로그 버퍼에 있는 트랜잭션 정보를 로그 파일로 기록한다.
CKPT (Checkpoint): 데이터베이스 체크포인트 작업을 수행하여 변경된 데이터를 디스크에 저장한다.
PMON (Process Monitor): 비정상 종료된 사용자 프로세스를 복구한다.
SMON (System Monitor): 시스템을 복구하고, 비정상 종료 후 데이터베이스를 재시작할 때 필요한 복구 작업을 처리한다.
3. PGA (Program Global Area)
- PGA: 각 사용자 프로세스별로 고유한 메모리 영역이다. 서버 프로세스에서 사용되는 메모리이며, 작업 공간 및 세션 메모리를 관리한다.
4. 클라이언트 프로세스와 서버 프로세스
클라이언트 프로세스: 사용자가 데이터베이스에 질의를 보내는 과정에서 발생하는 프로세스이다.
서버 프로세스: 클라이언트의 SQL 요청을 처리하고, 필요한 데이터를 데이터베이스에서 읽어 메모리로 가져온다.
5. 데이터베이스 영역
데이터베이스 파일: 실제 데이터가 저장된 파일로, 사용자가 생성한 테이블, 인덱스, 트랜잭션 정보가 저장된다.
Redo Log Files: 트랜잭션이 커밋되기 전에 로그 파일에 기록되는 정보로, 시스템 장애 시 데이터를 복구하는 데 사용된다.
연관 동작 과정:
클라이언트가 SQL 쿼리를 실행한다. (Client Process)
서버 프로세스는 클라이언트의 요청을 받아 처리하며, 필요한 데이터는 SGA에서 읽거나 PGA에서 작업을 수행한다.
Shared Pool에 자주 사용되는 SQL 명령어나 실행 계획이 캐시되어 있으면 이를 재사용한다. 만약 없다면 새롭게 SQL을 파싱하여 실행 계획을 만들고, Library Cache에 저장한다.
Database Buffer Cache에 필요한 데이터가 있으면 바로 메모리에서 처리하고, 없다면 디스크에서 데이터를 읽어와 캐시에 저장한다.
데이터가 변경되면 변경 사항은 Redo Log Buffer에 저장되고, 이후 Log Writer(LGWR)가 이를 로그 파일로 기록한다.
DB Writer (DBWn)는 변경된 데이터를 디스크에 기록하여 데이터의 무결성을 보장한다.
요약:
클라이언트가 요청을 보내면 서버 프로세스가 이를 받아 처리하고, SGA와 PGA를 사용하여 데이터를 처리한다.
SGA는 여러 사용자가 공유하는 메모리 공간으로, SQL 실행 계획과 데이터를 캐싱하여 성능을 향상시킬수 있다.
백그라운드 프로세스는 데이터 쓰기, 로그 기록, 복구 작업 등을 수행하여 데이터베이스의 안정성을 유지하는 역할을 한다.
오라클 데이터베이스 아키텍쳐(Oracle Database Architecture) 2#:
오라클 구조(Structure of Oracle) - 시스템 공유 영역(System Global Area, SGA)
SGA는 오라클 데이터베이스 인스턴스에서 중요한 메모리 영역으로, 데이터베이스 성능을 향상시키는 데 중요한 역할을 하는 메모리 버퍼들의 집합이다. SGA가 클수록 더 많은 데이터를 메모리에 저장할 수 있어 성능이 좋아질 수 있으며, 여러 사용자가 동시에 데이터베이스를 사용할 때도 효율적인 데이터 처리가 가능해진다. 사용자들이 동시에 데이터에 접근할 때 이 메모리 공간을 공유하게 된다.
SGA의 주요 특징:
오라클에 할당된 메모리 버퍼들의 집합
(A collection of memory buffers allocated to Oracle)SGA는 여러 가지 메모리 버퍼를 포함하고 있다. 이 메모리 버퍼들은 데이터베이스 버퍼 캐시(Database Buffer Cache), 공유 풀(Shared Pool), Redo 로그 버퍼(Redo Log Buffer) 등의 메모리 공간으로 구성된다.
이러한 버퍼들은 데이터베이스가 디스크와의 I/O를 줄이고, 자주 사용되는 데이터를 메모리에서 빠르게 처리할 수 있도록 돕는다.
하나의 SGA + 백그라운드 프로세스가 오라클 데이터베이스 인스턴스를 구성
(One SGA + background processes make up an Oracle database instance)- 오라클 인스턴스는 SGA와 백그라운드 프로세스의 결합으로 구성된다. SGA는 메모리 영역을, 백그라운드 프로세스는 데이터베이스 작업을 처리한다. 인스턴스는 데이터베이스를 액세스하고 관리하는 기본 단위이다.
인스턴스 시작 시 SGA 할당, 종료 시 반납
(SGA is allocated when the instance starts and returned when it shuts down)- 오라클 데이터베이스 인스턴스가 시작될 때, 운영 체제의 메모리에서 SGA를 할당받는다. 인스턴스가 종료되면 해당 메모리 자원은 운영 체제에 반납된다.
SGA는 데이터베이스에 연결된 사용자들이 공유
(SGA is shared by users connected to the database)- 여러 사용자가 동일한 데이터베이스에 연결되어도 SGA를 공유하여 데이터 접근 및 처리가 가능하다. 즉, 같은 데이터를 여러 사용자가 접근할 경우 SGA에 저장된 데이터를 재사용함으로써 성능을 향상시킬 수 있다.
SGA의 크기와 성능
(The size of the SGA and performance)- SGA의 크기가 클수록 더 많은 데이터를 메모리에 저장할 수 있으므로, 디스크 I/O가 줄어들고 성능이 향상된다. 자주 액세스되는 데이터를 SGA 내에 저장하면 디스크 접근 없이 메모리에서 빠르게 데이터를 읽고 쓸 수 있게 된다.
SGA의 주요 구성 요소:
데이터베이스 버퍼 캐시 (Database Buffer Cache)
Redo 로그 버퍼 (Redo Log Buffer)
공유 풀 (Shared Pool)
💡데이터베이스 버퍼 캐시 (Database Buffer Cache)
오라클 데이터베이스 아키텍처에서 데이터베이스 버퍼 캐시(Database Buffer Cache)는 메모리 영역으로, 디스크 I/O를 줄이고 데이터 접근 성능을 향상시키는 중요한 역할을 한다. LRU 알고리즘을 사용해 자주 사용되는 데이터를 메모리에 남기고, 자동 및 수동으로 캐시 크기를 조정하여 성능 최적화를 도모한다. 이를 통해 빠른 데이터 접근과 효율적인 메모리 사용을 지원한다.
데이터베이스 버퍼 캐시(Database Buffer Cache)의 주요 특징:
질의문에서 필요한 데이터 저장
- 데이터베이스 버퍼 캐시는 사용자가 요청한 데이터를 디스크에서 읽어와 메모리에 저장하는 역할을 한다. SQL 질의문이 데이터를 요청할 때, 이 캐시에 이미 해당 데이터가 저장되어 있으면 디스크로부터 데이터를 다시 읽을 필요 없이 바로 메모리에서 데이터를 처리할 수 있어 성능이 크게 향상될수 있다.
LRU(Least Recently Used) 알고리즘:
LRU 알고리즘을 사용하여 가장 최근에 사용된 데이터 블록을 메모리에 유지한다. 자주 사용되는 데이터는 메모리에 남아있고, 가장 오래된 데이터는 캐시에서 제거되어 새로운 데이터로 교체된다. 이를 통해, 자주 참조되는 데이터를 메모리에 저장하여 디스크 I/O를 줄일수 있다.
즉, 데이터베이스 버퍼 캐시는 사용 빈도에 따라 데이터 블록을 메모리에 보관하여, 가장 최근에 사용된 데이터를 우선적으로 남기고, 사용 빈도가 적은 데이터는 캐시에서 제거된다.
자동 조정 및 임의 조정 가능:
DBMS는 데이터베이스의 성능을 최적화하기 위해 데이터베이스 버퍼 캐시의 크기를 자동으로 조정할 수 있다. 예를 들어, 데이터 액세스 패턴이 변하거나 워크로드가 증가할 경우 DBMS는 메모리 자원을 효율적으로 관리하기 위해 캐시의 크기를 변경한다.
또한, 관리자(DBA)가 데이터베이스의 요구에 따라 캐시 크기를 임의로 조정할 수도 있다. 특정 데이터 집합에 대해 성능을 최적화해야 할 경우 캐시 크기를 수동으로 늘리거나 줄이는 것이 가능하다.
💡리두 로그 버퍼(Redo Log Buffer)
오라클 데이터베이스 아키텍처에서 리두 로그 버퍼(Redo Log Buffer)는 트랜잭션 중 발하는 모든 데이터 변경 사항을 저장하는 중요한 메모리 영역이다. 버퍼에 저장된 데이터는 주기적으로 온라인 리두 로그 파일로 기록되고, 해당 로그 파일은 장애 시 복구에 사용된다. 또한, 로그 파일이 재사용될 때 아카이브 로그 파일로 백업되어 데이터베이스의 장기 복구를 지원한다. 이 버퍼는 데이터베이스의 안정성과 복구 기능을 보장하기 위한 필수 구성 요소이다.
리두 로그 버퍼(Redo Log Buffer)의 주요 특징:
변경 사항 기록:
리두 로그 버퍼는 데이터베이스에 대한 모든 변경 사항을 기록한다. 여기에는 DML 명령어(예:
INSERT,UPDATE,DELETE)로 인해 발생한 변경 사항과 변경된 블록 번호, 변경 위치, 변경 전후 값 등이 포함된다.트랜잭션이 발생하면, 해당 트랜잭션의 모든 변경 사항이 이 버퍼에 저장된다. 이때 변경된 데이터 블록의 세부 정보까지 기록되어, 데이터베이스가 언제든지 복구 가능하도록 한다.
데이터베이스 복구용:
리두 로그 버퍼에 저장된 리두 항목은 데이터베이스에 장애가 발생했을 때 데이터를 복구하는 데 사용된다.
트랜잭션이 커밋되면, 리두 로그 버퍼의 데이터는 디스크의 온라인 리두 로그 파일(Online Redo Log Files)에 기록된다. 장애 발생 시 이 리두 로그 파일을 사용하여 데이터베이스를 이전의 일관성 있는 상태로 복구할 수 있게 된다.
온라인 리두 로그 파일로 기록:
리두 로그 버퍼에 있는 변경 사항은 주기적으로 또는 커밋 시점에 온라인 리두 로그 파일로 기록된다. 이를 통해 데이터베이스에 저장된 데이터가 손실되지 않도록 보장한다.
온라인 리두 로그 파일은 장애 복구 시 가장 먼저 사용되는 파일이다.
아카이브 로그 파일:
온라인 리두 로그 파일이 재사용될 때, 해당 로그 파일에 기록된 데이터는 아카이브 로그 파일(Archived Redo Log Files)로 백업된다. 아카이브 로그 파일은 데이터베이스가 백업이나 복구 작업을 수행할 때 사용되며, 일정 기간 동안 보관된다.
아카이브 로그 파일은 특히 장애 복구 시 중요한 역할을 하며, 데이터베이스를 특정 시점으로 복구하는 데 사용된다.
💡오라클 데이터베이스 아키텍처에서 공유 풀(Shared Pool)은 자주 사용되는 SQL 문장, 데이터 사전 정보, 그리고 최근에 조회된 결과 등을 저장하여 성능을 최적화하는 중요한 메모리 영역이다. 공유 풀은 여러 사용자가 동시에 데이터베이스에 접근할 때 성능을 향상시키는 데 기여한다. 좀 더 자세히 설명하면 라이브러리 캐시는 SQL 문과 실행 계획을 저장하여 SQL 재사용을 가능하게 하고, 데이터 사전 캐시는 데이터베이스 메타데이터를 저장하여 성능을 향상시킨다. 또한 결과 캐시는 최근 조회된 쿼리 결과를 저장하여 쿼리 처리 시간을 단축하는 역할을 한다. 이를 통해 데이터베이스의 전반적인 성능이 크게 향상될수 있다.
공유 풀(Shared Pool)의 주요 구성 요소:
라이브러리 캐시(Library Cache):
라이브러리 캐시는 공유 SQL 영역을 포함하고 있으며, 최근에 사용된 SQL 문장과 PL/SQL 문에 대한 정보, 해당 문장의 실행 계획이 저장된다.
오라클 데이터베이스는 SQL 명령어를 실행할 때 이 캐시에 해당 명령어가 이미 존재하는지 확인하게 된다. 만약 캐시에 SQL 문장과 실행 계획이 저장되어 있으면 재사용하게 되어, SQL을 다시 파싱하거나 실행 계획을 다시 생성할 필요가 없어 성능을 향상시킬 수 있다.
이를 통해 자주 실행되는 SQL 문장에 대해 성능 최적화가 이루어진다.
데이터 사전 캐시(Data Dictionary Cache):
데이터 사전 캐시는 데이터베이스에서 최근에 사용된 객체들에 대한 정보를 저장한다. 여기에는 데이터베이스 파일, 테이블, 인덱스, 사용자, 권한, 기타 객체들에 대한 메타데이터가 포함된다.
데이터 사전(Data Dictionary)은 데이터베이스의 구조와 관련된 정보를 제공하므로, 데이터 사전 캐시에 저장된 메타데이터는 SQL 문이 실행될 때 빠르게 참조되며, 이를 통해 데이터 사전에 대한 빈번한 접근을 최소화하고, 성능을 향상시킬 수 있다.
결과 캐시(Result Cache):
결과 캐시는 SQL 쿼리의 최근 조회된 결과값을 저장하는 공간이다. 동일한 쿼리가 다시 실행될 경우, 디스크에서 데이터를 다시 조회할 필요 없이 이 캐시에 저장된 결과를 반환할 수 있어 쿼리 처리 속도가 크게 향상될 수 있다.
이는 특히 읽기 작업이 많은 경우 성능 최적화에 중요한 역할을 한다.
시간없는 사람을 위해 💡SGA의 주요 구성요소 요약💡
데이터베이스 버퍼 캐시(Database Buffer Cache)
- 역할: 자주 사용되는 데이터를 메모리에 저장하여 디스크에서 데이터를 다시 읽지 않고 빠르게 처리할 수 있게 도와준다. 성능을 향상시키는 중요한 메모리 공간이다.
리두 로그 버퍼(Redo Log Buffer):
- 역할: 데이터가 변경될 때 그 변경 사항을 임시로 저장하는 공간이다. 트랜잭션이 완료되면 이 로그 데이터를 통해 시스템 장애 시 데이터를 복구할 수 있다.
공유 풀(Shared Pool):
- 역할: SQL 명령어, 실행 계획 등을 저장하여 동일한 쿼리를 재사용할 수 있게 도와준다. SQL을 다시 파싱하지 않고 바로 처리할 수 있어 쿼리 성능을 높여줄 수 있다.
오라클 데이터베이스 아키텍쳐(Oracle Database Architecture) 2#:
오라클 구조(Structure of Oracle) - 프로그램 공유 영역(Program Global Area, PGA)
오라클 데이터베이스 아키텍처에서 프로그램 글로벌 영역(Program Global Area, PGA)는 서버 프로세스나 백그라운드 프로세스가 작업을 수행할 때 필요한 데이터나 제어 정보를 저장하는 프로세스 전용 메모리 영역이다. PGA는 각 프로세스별로 개별적으로 할당되며 독립적인 PGA를 사용한다. 이를 통해 사용자 세션의 데이터를 저장하거나, 프로세스가 수행하는 작업에 필요한 메모리 공간을 제공한다. 데이터베이스 성능과 작업 효율성을 유지하기 위해 PGA는 자동으로 관리되며, 필요한 경우 수동 조정도 가능하다. 각 영역에 대해 자세히 알아보자
위의 이미지는 오라클 데이터베이스 아키텍처의 프로세스 영역에서 서버 프로세스(Server Process)가 어떻게 작동하는지 보여준다.
서버 프로세스는 사용자의 SQL 요청을 처리하고, 필요한 데이터를 SGA 또는 데이터 파일에서 가져와 처리한 후 결과를 사용자에게 다시 반환하는 역할을 한다. 만약 데이터가 SGA에 없을 경우 디스크에서 데이터를 읽어와 메모리에 저장하는 작업도 수행한다.
아래에서 서버 프로세스의 주요 역할을 간단히 살펴보자.
💡서버 프로세스(Server Process) 역할:
SQL 질의 실행(SQL query execution)
- 사용자가 SQL 질의문을 보내면, 서버 프로세스가 이를 실행한다. 예를 들어, SELECT, INSERT, UPDATE와 같은 명령어를 처리할 수 있다.
SGA(공유 메모리)와 데이터 파일 상호작용(Interaction with SGA and data files)
사용자가 요청한 데이터가 SGA의 데이터베이스 버퍼 캐시에 없다면, 서버 프로세스는 디스크의 데이터 파일에서 해당 데이터를 읽어와 SGA로 가져온다.
이렇게 가져온 데이터는 SGA에 저장된 후, 사용자에게 전송된다.
PGA(Program Global Area) 관리(PGA management)
- 서버 프로세스는 각자 PGA를 가지고 있으며, SQL을 처리하는 데 필요한 작업 공간과 세션 정보를 저장한다. 이 정보는 다른 프로세스와 공유되지 않는 독립적인 메모리 영역이다.
💡사용자 프로세스 (User Process)
역할: 사용자가 응용 프로그램을 실행할 때 생성되는 프로세스이다. 즉, 데이터베이스에 쿼리 요청(SQL 명령어 실행)을 보내고 그 결과를 받아오는 역할을 한다.
상호작용: 사용자 프로세스는 서버 프로세스와 상호작용하며, 데이터베이스에 직접 접근하지 않고, 서버 프로세스를 통해 데이터베이스와 간접적으로 통신한다.
💡백그라운드 프로세스 (Background Process)
역할: 데이터베이스의 물리적 구조(데이터 파일)와 메모리 구조(SGA) 간의 상호작용을 관리한다. 주요 백그라운드 프로세스들은 데이터 기록, 로그 관리, 복구 작업 등을 담당한다.
즉, 데이터의 읽기/쓰기를 처리하고, 데이터베이스의 안정성을 유지하는 작업을 수행한다.
💡백그라운드 프로세스 (Background Process) 상세설명
오라클 데이터베이스 아키텍처에서 백그라운드 프로세스는 데이터베이스의 성능과 안정성을 유지하고, 장애 발생 시 데이터를 복구하거나 자원을 회수하는 등의 중요한 역할을 한다.
PMON과 SMON은 프로세스 복구 및 자원 관리, DBWn과 LGWR는 데이터와 로그를 디스크에 기록하는 역할을 하며, CKPT는 체크포인트를 관리하여 데이터 복구를 돕는다. MMON/MMNL은 시스템 상태를 모니터링하고, RECO는 미완료된 트랜잭션을 처리한다.
결과적으로 각 프로세스는 데이터베이스의 특정 작업을 수행하며, 사용자 프로세스와 상호작용하거나 시스템 자원을 관리한다. 각 백그라운드 프로세스의 역할을 간단하게 살펴보자
Process Monitor (PMON):
역할: 사용자 프로세스가 비정상적으로 종료되면, 이 프로세스가 사용하던 자원(락, 메모리 등)을 회수하고, 관련 캐시를 정리한다.
기능: 사용자 프로세스의 복구와 자원 반납을 처리하여 데이터베이스의 정상적인 동작을 보
System Monitor (SMON):
역할: 인스턴스가 시작되거나, 여러 인스턴스가 있는 환경에서 장애가 발생한 인스턴스를 복구한다.
기능: 사용되지 않는 세그먼트를 정리하고, 여유공간을 확보하여 데이터베이스의 효율성을 유지한다.
Database Writer (DBWn):
역할: 버퍼 캐시에 있는 수정된 데이터 블록을 디스크의 데이터 파일로 기록하는 프로세스이다.
기능: 트랜잭션이 완료되어도 즉시 디스크에 쓰지 않으며, 버퍼에 공간이 부족할 때 데이터 파일에 기록한다.
트랜잭션이 완료되어도 즉시 데이터를 디스크에 쓰지 않는 이유는 디스크 I/O 횟수를 줄이기 위해서이다.
Log Writer (LGWR):
역할: 리두 로그 버퍼에 저장된 트랜잭션 로그를 온라인 리두 로그 파일에 기록한다.
기능: 트랜잭션이 완료되면, 로그 항목을 디스크에 저장하여 시스템 장애 발생 시 데이터를 복구할 수 있게 만든다.
Checkpoint Process (CKPT):
역할: DBWn에 의해 SGA에 있는 수정된 버퍼가 데이터 파일로 기록되는 체크포인트 작업을 관리한다.
기능: 체크포인트는 데이터베이스가 장애 발생 후 복구할 때 필요한 지점으로, CKPT가 이를 관리하여 복구 시간을 단축시킬 수 있다.
CKPT는 DB의 상태를 디스크에 주기적으로 기록함으로써 복구시간을 단축시킨다.
체크포인트 지점 이후의 데이터만 복구에 포함되므로, 복구할 트랜잭션의 양을 줄여 복구 시간을 줄이는 데 기여하는 것이다.
Manageability Monitor Processes (MMON, MMNL)
역할: 오라클 시스템 상태를 모니터링하고, 그 데이터를 Automatic Workload Repository (AWR)에 기록한다.
기능: 시스템 부하 상태를 기록하고, 성능 관리 및 모니터링을 위한 데이터를 제공하는 역할을 한다.
Recoverer Process (RECO):
역할: 네트워크 또는 시스템 장애로 미완료된 트랜잭션을 처리한다. 트랜잭션 테이블의 정보를 사용하여 보류 중인 트랜잭션을 완료(커밋 또는 롤백)한다.
기능: 장애가 발생한 트랜잭션을 자동으로 복구하거나 완료하고, 완료된 트랜잭션은 테이블에서 제거하여 데이터 일관성을 유지한다.
학습정리
