불친절한 SQL 프로그래밍 1부 3장 정리

3.1 개념

3.1.1 사용자

데이터베이스에 로그인할 수 있는 계정으로 데이터베이스를 생성하면 관리자 계정이 함께 생성됨.

관리자 계정은 DBA가 사용함.

개발자는 DBA가 생성한 사용자 계정으로 로그인하는 것이 일반적임.

3.1.2 오브젝트

논리적인 데이터 구조.

사용자에 종속될 수 있음. 사용자에 종속된 오브젝트의 논리적 집합을 스키마라고 함.

스키마는 오브젝트를 소유한 사용자와 동일한 이름을 가짐.

사용자에 종속된 오브젝트를 스키마 오브젝트, 종속되지 않는 오브젝트를 비 스키마 오브젝트라고 함.

스키마 오브젝트	테이블, 클러스터, 인덱스, 뷰, 시퀀스, synonym, 오브젝트 타입
비 스키마 오브젝트	사용자, 롤, 디렉터리

오브젝트는 데이터 저장 여부에 따라 세그먼트 오브젝트와 비 세그먼트 오브젝트로 구분할 수 있음.

저장공간이 필요한 오브젝트를 세그먼트라고 함.

3.1.3 테이블

데이터를 구성하는 기본 단위로 행과 열로 구성됨.

3.1.5 데이터 무결성

데이터의 정확성과 일관성이 유지되고 있는 상태를 의미함.

개체 무결성	엔터티의 인스턴스가 속성이나 속성의 조합으로 식별되어야 함.	PK 제약 조건, UNIQUE 제약 조건, NOT NULL 제약 조건
참조 무결성	자식 엔터티의 외래 식별자가 부모 엔터티의 기본 식별자에 존재해야 함.	FK 제약 조건, 트리거
범위 무결성	속성값이 지정한 범위에 유효해야 함.	데이터 타입, 기본값, CHECK 제약 조건
사용자 정의 무결성	개체 무결성, 참조 무결성, 범위 무결성에 속하지 않는 무결성	트리거

3.1.6 트랜잭션

함께 수행해야 하는 작업의 논리적 단위로, 유명한 ACID 특징을 가지고 있음.

원자성	트랜잭션의 작업은 모두 수행되거나 수행되지 않아야 함.
일관성	트랜잭션이 완료되면 데이터 무결성이 일관되게 보장되어야 함.
독립성	트랜잭션은 다른 트랜잭션으로부터 고립된 상태로부터 수행되어야 함.
지속성	트랜잭션이 완료되면 장애가 발생했다고 하더라도 변경 내용이 지속되어야 함.

3.1.7 정적 데이터 딕셔너리 뷰

데이터베이스의 메타데이터를 조회할 수 있는 읽기 전용 뷰.

정적 데이터 딕셔너리 뷰와 뷰의 기본 테이블은 SYS 사용자가 소유하고 있음.

정적 데이터 딕셔너리 뷰는 3개의 세트로 구성되며 12.1버전부터 컨테이너 데이터베이스에서 사용하는 CDB_로 시작하는 뷰도 사용할 수 있음.

DBA_	데이터베이스 관리자	모든 오브젝트
ALL_	모든 사용자	사용자에게 권한이 있는 오브젝트
USER_	모든 사용자	사용자가 소유한 오브젝트

3.1.8 동적 성능 뷰

데이터베이스의 동적 정보를 조회할 수 있는 읽기 전용 뷰.

동적성능뷰는 V$로 시작하며, X$로 시작하는 동적 성능 테이블을 사용함.

동적 성능 테이블은 SYS 사용자가 소유하고 있으며 RAC(Real Applicaiton Clusters)의 경우 GV$로 시작하는 뷰에서 인스턴스 별로 정보를 조회할 수 있음.

---

3.2 구조

3.2.1 데이터베이스와 인스턴스

오라클 데이터베이스는 하나의 데이터베이스와 하나 이상의 인스턴스로 구성됨.

데이터베이스는 데이터를 저장하는 파일의 모음임.

인스턴스는 SGA와 백그라운드 프로세스로 구성됨.

오라클 데이터베이스는 아래의 상태를 거쳐 단계적으로 기동됨.

1. SHUTDOWN

   인스턴스가 없음

2. NOMOUNT

   인스턴스가 시작됨 (관련 파일 : Paremeter file)

3. MOUNT

   데이터베이스의 상태를 검사 (관련 파일 : Control file)

4. OPEN

   데이터베이스가 열림 (관련 파일 : data file, online redo log)

하나의 데이터베이스와 하나의 인스턴스로 구성된 오라클 데이터베이스를 single 서버라고 함.

고가용성과 성능 향상을 위해 오라클 데이터베이스를 RAC로 구성할 수 있음.

RAC는 하나의 데이터베이스와 2개 이상의 인스턴스로 구성됨.

3.2.2 프로세스 구조

백그라운드 프로세스와 서버 프로세스로 구분됨.

백그라운드 프로세스는 인스턴스가 시작될 때 서버 프로세스는 사용자가 데이터 베이스 서버에 접속될 때 생성됨.

서버 프로세스는 클라이언트 프로세스와 통신이 가능함.

백그라운드 프로세스는 데이터베이스 운영에 필요한 백그라운드 작업을 수행함.

PMON(Process Monitor)	다른 프로세스를 감시(프로세스 정리)
SMON	시스템 레벨의 정리 작업을 담당(인스턴스 복구)
CKPT	control file과 data file 헤더를 갱신하고 DBWn에 신호를 보냄
DBWn	database buffer cache의 dirty buffer를 data file에 저장
LGWR	redo log buffer를 online redo log 파일에 저장
ARCH	online redo lig 파일을 archive redo log 파일로 보관

3.2.3 메모리 구조

오라클 데이터베이스의 메모리는 SGA와 PGA로 구분됨.

• SGA는 백그라운드 프로세스와 서버 프로세스의 공유 메모리 영역으로 인스턴스가 시작될 때 할당되고 종료될 때 해제됨. shared pool은 library cache와 data dictionary cache를 포함함. SGA의 주요 요소는 아래와 같으며, 다음과 같이 동작함.

  database buffer cache	data file에서 읽은 data block의 복사본을 캐싱하고 변경을 기록함
  redo log buffer	DB의 변경사항을 online redo log 파일에 기록하기 전에 버퍼링
  shared fool	다양한 유형의 프로그램 데이터를 캐싱
  library cache	실행 가능한 SQL, PL/SQL 코드를 저장
  data dictionary cache	데이터 딕셔너리 정보를 캐시
  large pool	shared pool보다 큰 메모리를 할당하기 위한 영역

• PGA는 서버 프로세스의 독점 메모리 영역으로 서버 프로세스가 형성될 때 할당되고 종료될 때 해제됨. 이 곳에서는 세션 정보와 SQL 관련 데이터가 저장됨.
  

3.2.4 저장 구조

오라클 데이터베이스는 물리 저장 구조와 논리 저장 구조가 분리되어 있음.

물리 구조를 변경해도 논리 구조에는 영향을 미치지 않음.

3.2.4.1 물리 저장 구조

물리 저장구조는 파일로 저장되며 OS에서 확인 가능함.

archive redo log 파일처럼 데이터베이스에 속하지 않는 파일도 존재함.

물리 저장 구조의 파일은 아래와 같음.

data file	세그먼트(테이블, 인덱스)가 저장되는 파일
control file	데이터베이스의 물리적인 구성 요소에 대한 제어 파일
online redo file	데이터베이스의 변경 사항을 저장하는 파일 세트
archived redo log	online redo log의 오프라인 사본

3.2.4.2 논리 저장 구조

논리 저장 구조는 오라클 데이터베이스 내부에서 관리됨.

세그먼트는 하나의 테이블스페이스에 속하고 다수의 데이터 파일에 저장됨.

논리 저장 구조의 단위는 아래와 같음.

우리가 알고 있는 그 행은 블록에 저장되는데 하나의 행을 조회하더라도 행이 저장된 블록 전체를 읽어야 함.

블록(block)	데이터를 저장하는 가장 작은 논리적 단위
익스텐트(extent)	논리적으로 연속된 data block의 집합 (공간을 확장하는 단위)
세그먼트(segment)	오브젝트에 할당된 extent의 집합
테이블스페이스(table space)	세그먼트를 포함하는 데이터베이스 저장 단위

3.2.5 네트워크 구조

• 리스너(listener) : 데이터베이스 서버에서 동작하는 프로그램으로, 오라클 데이터베이스의 접속을 처리함. listener.ora 파일은 리스너의 설정 파일임. tnsnames.ora 파일은 클라이언트의 설정 파일로, 데이터베이스 서버 접속 정보가 저장됨.
  
• 리스너 방식의 접속은 아래의 순서대로 진행됨.
  1. 클라이언트 프로세스가 데이터베이스 서버에 접속을 요청
  2. 리스너가 클라이언트 프로세스의 접속 요청을 수락하고 서버 프로세스를 생성
  3. 리스너가 서버 프로세스와 클라이언트 프로세스를 연결한 후 다른 접속 요청을 대기

3.2.6 애플리케이션 구조

오라클 데이터베이스는 네트워크 구조의 단계에 따라 3가지 유형의 애플리케이션 구조를 가질 수 있음.

• local
  데이터베이스 서버 내에서 직접 접속
  

• client-server
  클라이언트에서 데이터베이스 서버로 접속(2-tier)

• multi-tier
  애플리케이션 서버를 통해서 데이터베이스 서버로 접속(3-tier)
  해당 구조는 일정 수 이상의 커넥션을 유지할 수 있도록 커넥션 풀을 사용함.
  커넥션 풀을 사용하면 서버 프로세스 생성과 PGA 할당에 대한 부하를 경감시킬 수 있음.

[추가] 커넥션과 세션

• 커넥션(connection)은 클라이언트 프로세스와 데이터베이스 인스턴스 사이의 물리적 통신 경로
• 세션(session)은 데이터베이스에 로그인된 사용자의 상태를 나타내는 논리적인 객체임.
• 커넥션을 통해 세션이 생성된다고 보면 됨.