Oracle Database의 설계 및 디스크와 메모리와의 관계

 

Database(DB) : 데이터의 저장소

• 데이터베이스는 무조건 하드디스크에 저장될 수 밖에 없음

DBMS(Database Management System) : 데이터베이스 관리 시스템

관계형DB : 데이터의 종속성을 관계로 표현하는 것이 특징

관계형 DB = 2차원 DB → 테이블로 이루어짐

• Column(열) = 필드 = 속성 : 데이터의 제목(분류) , 유일한 이름을 가진다
• Row(행) = 튜플 = 레코드 : 관계된 데이터들의 묶음
• DB의 모델링에 따라서 사용하는 DBMS도 바뀐다. 관계형DB는 RDBMS를 사용하여 관리함

datetime을 사용하면 YYYY-MM-DD HH:mm:ss 형태로 저장되고 데이터 값을 입력해 주어야 한다.

 

timestamp는 1970/1/1의 기준으로 몇 초가 지났는지 기록됨

년도 표시에서 RR은 0~49까지는 현 세기를 나타내고 50~99까지는 전 세기의 년도를 나타냄

사용하는 이유는 년도를 표시할 때 년도에서 YY 두 자리만 사용할 때 YY/MM/DD 라는 형태라고 치고 98년도를 치면 DB에서는 2098년인지 1998년인지 인지할수없기 때문에

→ 이럴때 RR/MM/DD 형식에 97년도를 입력하게되면 DB내부에서는 1997년으로 인식됨

 

Primary key : NOT NULL, UNIQUE(고유성)

• - UNIQUE : 학번이나 휴대폰 번호처럼 고유해야한다(중복이 안됨), 유니크 인덱스가 만들어짐 
• - PK는 테이블 당 하나만 가질 수 있다.
• - 관계형 DB는 이론 상 모든 테이블에 하나의 기본 키를 가져야 한다. 

 

파일 시스템 : 디스크 파티션을 관리하는 하나의 체계

• 단점 : 응용 프로그램 별로 파일을 유지하여 같은 데이터의 중복성이 발생하여 디스크의 공간을 낭비할 수 있음

DBMS는 DB에 데이터를 통합하여 관리하기에 중복 문제를 쉽게 해결할 수 있다.

• 만약 DB에서 중복이 발생하면 발생하는 치명적인 단점은 디스크에 있는 중복이 정보를 보여줄 때 메모리에 올려서 확인하기 때문에 결국에는 메모리의 공간 낭비로도 이어짐
  • 디스크의 공간 낭비에서 메모리의 공간 낭비로도 이어짐

하나의 종속성을 가지고 있는 컬럼이 또 종속성을 가지고 있으면 잘라야됨 - 제3정규화

 

학생 테이블

학번	이름	학과 번호	학과 이름
001	xxx	1	컴퓨터정보
002	xxa	2	컴퓨터공학
003	aan	1	컴퓨터정보

                                                                                               ↓

 

학과 테이블

학과 번호	학과 이름
1	컴퓨터정보
2	컴퓨터공학
3	드론학과

↓

 

학생 테이블에서 중속성이 있는 컬럼 제거

학번	이름	학과 번호
001	xxx	1
002	xxa	2
003	aan	1

 

단 , 지나친 정규화는 많은 조인을 만들어 성능 상 단점이 발생함 → 성능을 위해 반정규화 하는 경우도 있음

반정규화 : 하나 이상의 테이블에 데이터를 중복해 배치하는 최적화 기법

• 시스템의 성능 향상 또는 개발자의 편의성을 위해 의도적으로 정규화 원칙을 위배하는 행위
• 하지만 반정규화 동작 때문에 데이터 일관성 유지가 어려울 수 있다

데이터베이스의 처리 속도에 가장 큰 영향을 미치는 것은 디스크 I/O 동작이다 하지만 데이터를 저장하는 하드디스크는 CPU에 비해 현저히 느리기 때문에 데이터베이스는 캐시 기술을 이용해 메모리에 올려서 처리하는 구조를 가지고 있음.

Cache : 가까운 미래나 다음 작업에 필요한 데이터를 미리 가져다 놓음

• Cache는 CPU안의 레지스터의 속도에 범접함 → 데이터 처리 속도가 현저히 빨라짐 

 

입출력 채널(I/O Channel) : 컴퓨터 시스템에서 데이터의 입력과 출력을 담당하는 하드웨어 혹은 소프트웨어 구성 요소를 의미, 이 채널은 CPU와 주변 장치(디스크,네트워크 인터페이스 등)사이에서 데이터를 전송하는 역할을 한다.

• 데이터베이스의 관점에서 입출력 채널은 데이터베이스의 성능에 매우 중요한 요소
  • 필요한 정보를 디스크에서 메모리로 옮기는 과정(I/O 작업)은 종종 성능의 병목 지점이 될 수 있습니다.
  • 이러한 문제점으로 DBMS에서는 (캐싱, 인덱싱 등) 여러 최적화 기법을 사용하여 속도를 향상시킨다.
• 입출력(I/O) 병목현상 : 대부분의 DBMS는 디스크 기반 시스템이기 때문에, 디스크와 메모리 사이의 데이터 전송 속도가 DBMS의 전체적인 성능을 결정하기 때문이다.

DBMS에서 효율적인 I/O 처리를 위해 여러 가지 기법들이 사용됨

• Buffering : 자주 접근하는 데이터나 최근에 접근한 데이터를 메모리에 임시로 저장함으로써 디스크 접근 횟수를 줄입니다.
• Caching : Buffering과 유사하지만 일반적으로 Cache는 자주 사용되거나 사용될 가능성이 높은 데이터를 저장합니다.
• Prefetching : 필요한 데이터가 필요하기 전에 미리 로드되도록 하는 기법입니다.
• Indexing : 인덱싱은 특정 값을 가진 레코드를 찾기 위해 모든 레코드를 검색하는 대신 직접 해당 위치로 접근할 수 있게 해줍니다.

---

디스크에 데이터베이스를 구축하는 이유는 큰 용량이기때문에 비교적 용량이 큰 디스크에 저장하고 필요한 데이터가 있을때 마다 빠르게 처리 할 수 있는 메모리에 올려서 처리하는게 효율적이기때문에

디스크에 DB 구축 → DBMS 인터페이스를 이용해 → 메모리로 데이터를 옮겨서 보다 빠르게 사용

작업 흐름

• 디스크 → (DBMS를 통해) → 메모리 → (작업 수행) → (Rollback / Commit) → 다시 디스크

하드디스크의 DB의 A 라는 공간에 10 이라는 데이터가 있는데 이것을 메모리에 옮겨서 사용을 하는데 A 라는 데이터가 100으로 데이터가 변화되면 하드디스크의 저장된 데이터와 메모리에 저장된 데이터가 다른데 이것을 Dirty block 이라고 한다

 

 

메모리에 올라간 데이터가 변경된 부분인 dirty block을 하드디스크에 반영하려면

트랜잭션 1 : A ⇒ 10 ⇒ 100

트랜잭션 2 : A ⇒ 100 ⇒ 200

트랜잭션1이 A 데이터를 커밋하기 전까지는 A 데이터가 Locking 되어 트랜잭션2에서는 수정할 수 없고 대기를 해야함

Write-back : 메모리 상에서 발생한 변경사항들을 일정 시점에 한 번에 디스크로 반영하는 것

• DML시 Commit / Rollback
• 모든 DBMS 시스템은 Write-back 함

Write-through : 각각의 변경사항들을 즉시 디스크로 반영 하는 것

• 오버 헤드가 발생함

Dirty Block: 메모리에 올라온 데이터 블록이 변경되어 디스크의 원본 데이터와 일치하지 않게 되면, 이를 "Dirty Block"이라 합니다. 이는 변경사항이 아직 디스크에 반영되지 않았음을 의미합니다.

redo : 모든 변경 사항(INSERT, UPDATE, DELETE 등)을 추적하여 시스템 장애가 발생했을 때 복구를 가능하게 합니다.

undo : 각 트랜잭션에서 수행된 작업을 롤백(undo)하기 위한 정보를 저장

redo archive log : 만약 오라클 데이터베이스에서 Redo log file이 꽉차면 아카이브화 된다.

• 별도의 디렉토리나 스토리지 위치에 보관된다. 주로 백업 및 복구 작업에 이용되면 시간 경과 후에도 보존이 된다. 정기적으로 삭제를 해줘야함

redo log file : Redo log 파일은 데이터베이스의 모든 변경사항을 기록하는 로그이다.

redo log buffer : redo log file 또는 redo archive log와 동일한 정보를 가지지만 메모리에 임시적으로 저장되는것이다 이것이 꽉차면 redo log file(disk) 파일로 이동된다.

Redo archive log와 Redo log file은 동일한 정보를 담고 있지만 그 활용 방식과 보관 위치 등에 차이가 있다.

데이터 단위 : bit < byte < word < record(row) < block 메모리에서 워드 단위 읽어와서 그것을 캐쉬해서 CPU가 처리한다.

block : word들의 집합체

메모리 ↔ 디스크 는 block 단위로 데이터가 이동됨

DB의 스토리지

Tablespace > segment(s) > extend(s) > block(s)

• Extend 는 여러개의 Block의 모음이고,
• Segment 는 여러개의 Extend가 모여 구성되어 있고,
• Tablespace 는 여러개의 Segment로 구성되어져 있다.

Block

Block은 오라클 DB에서 데이터를 구성하는 가장 작은 단위이고, DBMS는 어떠한 데이터를 읽고 쓰는(I/O) 작업을 하려면 가장 작은 데이터의 모음인 Block을 Read하고 Write 한다.

→ 논리적인 가장 최소의 I/O 단위

Block의 크기는 고정적이다, 처음에 데이터베이스를 생성할 때 8KB가 디폴트 값으로 정해진다.

가장 최소 단위는 2KB 까지 설정 가능하다.

Extend

Data block(Block)이 모여 만든 저장 공간(단위)

크기가 가변적이다.

Segment

Extend가 모여 만든 저장 (공간)단위

크기가 가변적이다

한 개의 Segment는 하나의 Tablespace에만 대응된다, 어떠한 Segment는 여러개의 Tablespace에 동시에 존재 할 수 없다

Tablespace

Oracle DB는 Data를 저장할 때 논리적으로는 Tablespace에 저장하고 물리적으로는 datafiles에 저장한다.

 

Tablespace의 데이터는 물리적으로 O/S의 파일의 datafiles에 저장되지만 DBMS가 물리적인 저장소를 추상화하여 관리하기 때문에 실제 테이블스페이스가 여러 개의 물리적인 파일들을 하나의 논리적인 단위로 사용한다 → logical storage(논리적)인 저장공간이다.

 

요약 : Tablespace는 하나 또는 여러개의 데이터 파일로 구성되어 있는 논리적인 데이터 저장구조 입니다.

 

예를 들어, Tablespace 파일이 100mb이 이고 하나 일 때 O/S File도 100mb인데 Tablespace가 하나 더 추가되면 O/S File 내에 Tablespace가 하나 더 늘어서 디스크의 용량이 추가된다

Tablespace의 종류는 크게 두가지가 있다.

 

SYS Tablespace

Oracle 데이터베이스의 핵심 시스템 정보 - 오라클 객체 (테이블,인덱스 등)이 저장되어져 있다.

데이터 사전 : 객체정보만 모아놓은 것 SQL 구문에 대한 정보 → 깨지면 SQL 구문 불가

데이터 카탈로그 : 데이터베이스에 대한 정보를 가짐 → 깨지면 DB를 쓸 수가 없음

• 기본 테이블, 뷰 테이블, 동의어, 인덱스, 사용자 그룹 등
• 컨트롤 파일이 깨지면 DB를 마운트하지 못함

Non-SYS Tablespace

데이터베이스 관리자(DBA)나 사용자가 직접 생성하고, 관리하는 Tablespace이다.

이 Tablespace에는 실제 데이터들이 저장된다.

아래의 SQL구문은 새로운 사용자를 생성하는 SQL 구문이다.

CREATE USER mapia
identified by tiger
/* default tablespace를 지정해주지 않으면 system tablespace로 들어가기 때문에 지정을 해줘야함 */
default tablespace users;

SQL 문장을 실행할 때, Oracle DBMS는 일반적으로 다음과 같은 체크 과정을 거칩니다

Syntax Check: SQL 문장의 구문이 올바른지 확인합니다. 예를 들어, 모든 키워드가 올바르게 사용되었는지, 괄호나 세미콜론 등의 기호가 제대로 닫혀 있는지 등을 검사합니다.

Semantic Check: SQL 문장이 의미상 올바른지 확인합니다. 예를 들어, 참조하는 테이블이나 컬럼 이름들이 실제로 존재하는지, 데이터 타입들이 일치하는지 등을 검사합니다.

Privilege Check: 실행하려는 SQL 문장에 필요한 권한들이 현재 사용자에게 부여되어 있는지 확인합니다.

Block 크기 지정의 중요성

만약 데이터 수정이 빈번한 DB에 블록 크기를 크게 설정하면, 수정이 발생할 때 변경된 내용(block) 전체가 log에 기록되므로 redo log도 블록 크기만큼 증가합니다. 예를 들어, 2KB만 수정하더라도 블록 크기가 32KB로 설정되어 있다면 32KB가 전체 redo 로그에 저장되어 메모리와 디스크 용량을 낭비하게 됩니다.

Block 크기를 32k로 지정하였는데 데이터의 수정 작업이 일어날때 그 데이터가 속한 block을 통째로 가져와서 수정을 하는데 그 중에 수정할게 2k 밖에 없을때 남는 30k 도 같이 따라 오는데 30k는 쓰지 않는 같이 따라온 데이터니까 낭비가 일어남

Redo 로그와 Redo 아카이브 로그

Redo log - 메모리에 저장됨

 

Redo Archive Log : 디스크에 저장됨

 

Redo 로그 : Oracle 데이터베이스에서 변경 사항을 기록하기 위해 메모리의 Redo Buffer에 저장됩니다. 트랜잭션이 커밋되면, 해당 변경 사항은 Redo Buffer에서 디스크 상의 Redo 로그 파일로 기록(flush)됩니다.

 

Redo 아카이브 로그 : 꽉 찬 Redo 로그 파일을 디스크 상의 별도 위치에 보관하는 것입니다. 이 작업은 Oracle 데이터베이스가 ARCHIVELOG 모드로 설정되어 있을 때 수행됩니다. 아카이브된 redo log 파일들은 데이터베이스 백업 및 복구 작업 등을 위해 필요한 경우 사용됩니다.

 

• 변경 사항은 메모리(Redo Buffer)에 먼저 저장되고,그 후 디스크(Redo Log Files)로 flush 되며,필요한 경우 꽉 찬 Redo Log Files가 Archived Redo Logs 형태로 추가적으로 보관(디스크) 됩니다.

버퍼링 : 디스크보다 메모리가 속도가 그나마 빠르니까 디스크의 있는 Database를 메모리에 올려서 사용하는 것

 

디스크 I/O : 디스크의 플래터(Platter)의 섹터에 데이터가 저장되므로 물리적으로 헤드가 그 섹터에 접근을 해 데이터에 액세스 해야한다.

 

메모리 I/O : 전기적인 신호로 처리를 하기 때문에 물리적으로 데이터에 접근하는 디스크보다는 훨씬 빠르다. 약 10,000배 정도 빠름

 

결론 : 디스크의 차지하는 용량을 중요하게 생각해야되는 이유는 결국 메모리에 올려서 작업을 하기 때문에 메모리의 용량에서도 영향이 가기 때문에