[Oracle] 오라클의 구조 정리1 - 인스턴스와 데이터베이스, 데이터베이스의 구성 요소

prana·2024년 10월 6일
0

ORACLE

목록 보기
24/96
post-thumbnail

출처: 오라클 구조 pdf 파일

  • 초반부 필요한 핵심 개념을 잘 설명해주는 것 같아 최종으로 정리하려 한다.
  • 데이터베이스 -> DB라고 줄여서 적을 수 있으니 양해 바랍니다.
  • 인스턴스와 데이터베이스
  • 데이터베이스의 구성 요소
  • 인스턴스의 구성 요소
  • 데이터 딕셔너리

인스턴스와 데이터베이스

오라클에서의 용어에 차이가 있다.

  • 데이터베이스: 물리적 저장
    • ✔️서버에 장착된 디스크에 저장된다.
  • 인스턴스: 데이터베이스 내 정보에 액세스 할 수 있는 소프트웨어를 일컬음
    • ✔️컴퓨터/서버에서 동작
    • 논리적이다. 서버의 내부-메모리 구조와 프로세스로 구성된다.
  • 사용자는 오라클 데이터베이스 내의 정보를 직접 액세스하지 않는다.
    대신, 사용자는 필요한 정보에 대한 요구를 오라클 인스턴스에 전달한다.

우리가 살고 있는 실제 세계에서 인스턴스와 데이터베이스를 유추해 볼 수 있다.
데이터베이스를 ‘섬’으로 간주하면, 인스턴스는 섬에 놓여진 ‘다리’로 생각할 수 있다.

이 다리를 통해 차가 왕래한다. 만일 다리가 폐쇄되면,
섬이 존재하기는 하지만 어떠한 차도 다리를 건널 수 없다.

✔️오라클 용어로 말해, 인스턴스가 기동되어 있으면 데이터가 데이터베이스에 입력되기도 하고 이로부터 출력되기도 한다.
이때 데이터베이스의 물리적 상태는 변하고 있다.

만일 인스턴스가 종료되어 있으면, 데이터베이스가 물리적으로 여전히 존재하기는 하지만
사용자는 데이터베이스를 액세스할 수 없다.
이때 데이터베이스는 정적이다. 인스턴스가 다시 서비스되면, 데이터는 데이터베이스에 입출력될 수 있다.



데이터베이스의 구성 요소

  • 데이터베이스를 생성할 때, 사용자는 이에 대해 특정한 이름을 부여하는데,
    데이터베이스를 액세스하는 인스턴스의 이름은 변경 가능하나⭕, 데이터베이스 이름은 변경할 수 없다.❌

테이블스페이스

  • DB에 저장된 모든 데이터는 반드시 테이블스페이스 내에 존재한다.
  • 논리적 구조이다.
  • 각 테이블스페이스는 데이터파일(Datafile)이라 불리는 물리적 구조로 구성된다.
  • 각 테이블스페이스는 하나 이상의 데이터파일로 구성되어야 하고, 각 데이터 파일은 단 하나의 테이블 스페이스에만 속할 수 있다.
  • 테이블을 생성할 때, 사용자는 어떤 테이블스페이스에 해당 테이블을 생성할 것인지를 지정할 수 있다.
    • 그다음, 오라클은 테이블스페이스를 구성하는 데이터파일 중 하나에서 테이블을 생성할 공간을 찾는다.

오라클 데이터베이스 내 물리적 파일

  • 테이블스페이스는 오라클 데이터베이스 내 정보의 물리적인 저장에 대한 논리적 뷰(logical view)이다.
  • 오라클 DB를 구성하는 물리적 파일의 기본적인 유형은 3가지이다.
  • 제어 파일(control files)
  • 데이터 파일(datafile)
  • 리두 로그 파일(redo log files)

제어 파일(Control files, 컨트롤 파일)

  • 컨트롤 파일은 다음과 같은 DB의 내용과 상태에 대한 주요 정보를 포함한다.
항목설명
데이터베이스 이름
데이터베이스 생성 시기
데이터파일의 현재 상태복구가 필요한지 여부, 읽기 전용 상태 여부 등
이전 데이터베이스 종료 상태데이터베이스가 제대로 닫혔는지 여부
아카이브 리두 로그 적용 기간각 아카이브 리두 로그에 의해 적용되는 기간
데이터베이스 백업 종류데이터베이스에 수행된 백업의 종류

컨트롤 파일 매개변수

  • 컨트롤 파일의 크기는 초기화 매개변수에 영향을 받는데, 이 초기화 매개변수들은 초기화 파일의 일부이며, 데이터베이스 생성 시에 설정된다. (초기화 파일에 대한 내용은 뒷부분에)
  • MAXLOGFILES : 데이터베이스에 대한 리두 로그 파일 그룹의 최대 수

  • MAXLOGMEMBERS: 각 리두로그 파일 그룹에 대한 멤버의 최대 수

  • MAXLOGHISTORY: 컨트롤 파일이 포함할 수 있는 리두 로그 히스토리 파일의 최대 수.
    • 이 히스토리 파일은 아카이브 리두로그에 유지 되어 있는 트랜잭션의 범위를 식별함으로써 리두로그를 사용하는 자동 복구 작업을 간단히 하기 위해 사용

  • MAXDATAFILES: 컨트롤 파일이 관리할 수 있는 데이터파일의 최대 수.
    • MAXDATAFILES 매개변수에 지정된 수보다 많은 데이터 파일을 추가하면, 컨트롤 파일이 자동으로 확장 된다.
      - 설명: 컨트롤 파일이 관리할 수 있는 데이터 파일의 최대 수를 설정한다. 데이터베이스가 생성될 때, 컨트롤 파일 내에서 관리할 수 있는 데이터 파일의 수를 정의하는 중요한 매개변수
      - 오라클 7 버전에서는 이 매개변수 값이 초과될 경우 제어 파일을 재생성해야 했으나, 오라클 8 버전 이후에서는 자동으로 컨트롤 파일이 확장된다.
      - 주요 기능: 데이터 파일을 추가할 때 컨트롤 파일의 용량 제한을 설정하며, 데이터베이스 크기가 확장될 수 있는 범위를 결정한다.

  • MAXINSTANCES: 컨트롤 파일이 관리할 수 있는 인스턴스의 크기와 수
  • 이러한 MAX값을 큰 값으로 설정하는 것이 바람직하다.

다중 컨트롤 파일

  • 데이터베이스는 최소 두 개의 컨트롤 파일을 가져야 한다.
  • 컨트롤 파일에 대한 최소 하나의 복사본이라도 없다면, 데이터베이스의 일부 혹은 전체에 대한 기록을 잃게 될 수 있다.
  • 제어파일의 재생성은 어렵고 위험의 소지가 있으므로 여러 개의 제어 파일에 대한 복사본을 유지하는 것이 좋은 방법이다.
CONTROL_FILES = (/u00/oradata/prod/prodctl1.ctl,
				/u01/oradata/prod/prodctl2.ctl,
                /u02/oradata/prod/prodctl3.ctl)
  • 오라클은 모든 컨트롤 파일 복사본이 본 파일과 일치하도록 유지하므로, 변경도 동시에 일어난다.

데이터 파일

  • 데이터베이스 내 저장된 실제 데이터를 포함한다.
  • 즉, 데이터를 저장하는 테이블과 인덱스, 데이터 구조에 대한 정보를 유지하는 데이터 딕셔너리, 일관성을 구현하는 데 롤백 세그먼트를 포함한다. (롤백 세그먼트는 나중에)
  • 오라클 데이터베이스 블록으로 구성, 데이터베이스 블록은 디스크 상의 운영체제 블록으로 구성된다.
  • 오라클 블록의 크기: 2KB~32KB (이제는 8KB가 표준처럼 사용됨)
  • 데이터파일은 단 하나의 데이터베이스에만 속하고, 해당 데이터베이스 내의 단 하나의 테이블스페이스에만 속한다.
  • 데이터는 사용자가 수행하고 있는 작업에 기초하여, 필요에 따라 오라클 블록 단위로 데이터파일에서 메모리로 읽혀진다.
  • 데이터블록은 데이터베이스가 사용자가 변경한 사항을 확실하게 기록하도록 하기 위해 필요에 따라 메모리에서 디스크 상에 저장된 데이터 파일로 쓰여진다.
  • 데이터 파일은 오라클 데이터베이스와 운영체제 사이에서 가장 하위 레벨에 위치한다.

데이터 파일 구조

  • 데이터파일 헤더(Datafile Header): 각 데이터파일의 첫 번째 블록
    • 데이터베이스 무결성을 유지하는 데 사용되는 중요한 정보
    • ✔️체크포인트 구조(checkpoint structure)
      • 논리적 타임 스탬프로, 데이터파일에 변경사항이 쓰여진 마지막 시점을 표시한다.
      • 이 타임스탬프는 복구 작업을 할 때 중요하다.
      • 오라클 복구 프로세스는 데이터파일을 현재 시점으로 복구하기 위해 어떠한 리두로그를 적용할지를 결정해야 하는데, 이때 데이터파일 헤더 내 타임 스탬프를 사용한다.

익스텐트와 세그먼트

  • 물리적 관점: 데이터 파일은 운영체제 블록으로 저장된다.

  • 논리적 관점: 데이터블록, 익스텐트, 세그먼트 (3개의 중간 레벨)

    • ✔️익스텐트(extent) : 오라클 데이터 파일 내 연속적인 데이터 블록의 집합

    • ✔️세그먼트(segment): 하나 이상의 익스텐트로 구성되는 테이블이나 인덱스와 같이, 오라클 데이터베이스 내에서 공간을 차지하는 객체


  • 데이터 변경 시, 오라클은 동일한 데이터 블록 내에서 데이터 변경을 시도한다.
  • 만일 데이터 블록 내에 새로운 정보를 저장할 공간이 충분하지 않으면, 오라클은 해당 데이터를 새로운 데이터 블록에 쓸 것이다.
  • 이 데이터 블록은 다른 익스텐트에 위치할 수도 있다.

리두 로그 파일

  • 트랜잭션과 오라클 내부 작업의 결과로써, 데이터베이스에 변경된 사항에 대한 기록을 저장한다.

  • 일반적인 작업 시, 오라클은 변경된 블록을 메모리에 캐시(혹은 저장)한다.

  • 인스턴스 장애가 발생했을 경우, 변경된 블록 중 일부는 데이터 파일에 쓰여지지 않았을 수도 있다.

  • ✔️ 리두 로그에 변경사항을 기록함으로써, 장애 발생 시 유실된 변경 사항을 복구해낼 수 있다.

  • 오라클 7버전에서는 인덱스 생성, SELECT 문을 이용한 테이블 생성, 데이터 적재 등과 같은 일부 작업에 대해 리두 정보 생성의 비활성화를 지원했다.

리두 로그 파일 다중화

  • 오라클은 리두 로그를 관리하기 위해 특정한 용어를 사용한다.
  • 아래 사진은 미러링되어 있는, 두 개의 멤버로 구성되어 있는 각 그룹을 나타낸다.
  • 각 오라클 인스턴스는 데이터베이스의 변경 사항을 기록하기 위해 리두 스레드를 사용한다.

  • 리두 스레드는 하나 이상의 리두 로그 멤버로 구성된 리두 로그 그룹들로 구성된다.

  • 논리적으로는 리두로그 그룹을 단일 리두 로그 파일로 생각할 수 있다.

    • 하지만, 오라클은 리두로그에 대한 모든 주요한 무결성을 보장하고자, 리두 로그 복사본을 여러 개 지정할 수 있도록 한다.
      각 리두 로그 파일 복사본을 여러 개 생성함으로써, 디스크 장애나 기타장애시 리두로그파일을 보호할 수 있다.
  • 여러 개의 멤버가 하나의 리두로그 그룹에 존재할 때, 오라클은 여러 개의 리두 로그 파일 복사본을 유지한다.

    • 🚨 오라클 데이터베이스 상태와 안전에 매우 중요하다.
      유실된 리두 로그 파일은 재생성할 수 있는 방법이 없다. 따라서 반드시 여러 개의 리두 로그 파일 복사본을 유지해야 한다.
  • 오라클은 항상 모든 리두로그 파일 복사본이 갱신될 때까지 기다린다.

    • 오라클은 디스크 상의 모든 리두로그 파일 복사본이 성공적으로 갱신되었는지 확인한 후, 리두 기록이 완료되었다고 판단한다.

오라클이 리두로그를 사용하는 방법

  • 오라클이 하나의 리두 로그 파일을 채웠으면, 자동으로 다음 그 로그 파일을 사용하기 시작한다.

  • 모든 이용 가능한 리두로그 파일을 순환했으면, 첫번째 리두로그 파일로 돌아가 이를 재사용한다.

  • 리두 로그 시퀀스 번호를 사용하여 상이한 리두 로그를 추적하는데, 이 시퀀스 번호는 리두 로그 파일 내에 기록된다.

redolog1.log, redolog2.log, redolog3.log 가 있다고 가정하자.

  • 오라클이 이 파일들을 처음으로 사용하는 경우, 각 리두로그 파일에 대한 리두 로그 시퀀스 번호는 각각 1,2,3이다.
  • 오라클이 첫번째 리두로그 파일인 redolog1.log로 돌아가면 오라클은 이를 재사용하되, 리두 로그 시퀀스 번호 4를 로그 파일에 부여한다.
  • 오라클이 redolog2.log로 이동하면, 오라클은 이 파일에 리두로그 시퀀스 번호 5를 부여한다.
  • ✔️ 리두 로그 시퀀스 번호: 오라클은 로그가 채워지고, 순환되는 순서를 결정하기 위해 사용한다.
  • ✔️ 리두 로그 파일 이름: 운영체제는 물리적 파일을 확인하기 위해, 리두 로그 파일을 사용한다.
    • 오라클은 자동으로 리두 로그 파일을 재사용하기 때문에, 리두 로그 파일이름이 반드시 리두 로그 파일 시퀀스 내의 리두로그 파일의 위치를 나타내는 것은 아니다.

아카이브 리두 로그

  1. 온라인 리두로그(Online Redo Logs)
  2. 아카이브 리두 로그(Archived Redo logs)
  • 온라인 리두로그: 오라클이 데이터베이스에 변경사항을 기록하기 위해 순환하여 사용하는 운영체제 파일들
  • 아카이브 리두로그: 온라인 리두로그의 재사용에 따른 리두 데이터의 유실을 막기 위해 생성되어 채워진 온라인 리두 로그의 복사본들
  • 오라클 데이터베이스는 아카이빙 리두 로그와 관련하여 다음 두 가지 모드를 운영할 수 있다.

  • NOARCHIVELOG

    • 어떠한 리두로그도 아카이빙 되지 않는다.
    • 오라클이 리두 로그를 순환함에 따라, 채워진 리두 로그는 초기화되어 재사용되므로 데이터베이스에서 변경 사항이 제거된다.
    • 이 모드는 근본적으로 장애 발생 시 복구가 불가능하다.
  • ARCHIVELOG

    • 오라클이 새로운 리두로그로 이동할 때, 이전 리두로그를 아카이빙한다.
    • 리두 로그 정보의 공백을 막기 위해 리두 로그가 성공적으로 아카이빙 될 때까지 해당 리두로그는 재사용될 수 없다.
      • 아카이브 리두로그와, 온라인 리두로그는 함께 모든 변경사항에 대한 완벽한 정보를 데이터베이스에 제공한다.
        이 두 파일을 함께 사용하면, 장애 발생 시점까지 커밋된 모든 트랜잭션 복구가 가능하다.
  • 로그 시퀀스 번호는 오라클이 데이터베이스 복구를 위해 온라인 리두로그와 아카이브 리두 로그를 사용하는 동안, 가이드 역할을 한다.

ARCHIVELOG 모드와 자동 아카이빙

  • 오라클 데이터베이스에 대한 자동 아카이빙을 활성화하려면, 다음 두 단계를 거쳐야 한다.
							ALTER DATABASE ARCHIVELOG
  • 만일, 데이터베이스가 ARCHIVELOG 모드 상태이면, 오라클은 리두 로그 파일이 채워지면 이 파일들을 아카이빙하라는 표시를 한다.
  • 채워진 로그 파일은 재사용되기 전에, 아카이빙 되어야 한다.
    • 하지만, 로그 파일이 아카이빙될 준비가 되었다는 표기가 되어있다고 해서, 자동으로 아카이빙 되는 것은 아니다.
    • 초기화 파일 내의 매개변수 또한 설정해주어야 한다.
    LOG_ARCHIVE_START = TRUE
  • 위와 같이 설정하면, 오라클은 채워진 리두로그를 아카이브 로그 대상 위치에 복사하기 위한 프로세스를 호출한다.
LOG_ARCHIVE_DEST = C:\ORANT\DATABASE\ARCHIVE -- 아카이브 리두 로그 파일 작성할 디렉토리
LOG_ARCHIVE_FORMAT="ORCL%S.ARC" --- 오라클이 아카이브 리두 로그 파일 이름에 대해 사용할 형식을 지정
PlaceholderDescription
%s왼쪽이 0으로 채워지지 않은 시퀀스 번호로 대체된다.
%T0으로 채워진 리두스레드 번호로 대체된다.
%t0으로 채워지지 않은 리두스레드 번호로 대체된다.
%S왼쪽이 0으로 채워진 시퀀스 번호로 대체된다.

ex) 아카이브 리두 로그 파일 이름이 스레드 번호와 시퀀스 번호를 포함하고,
0으로 채워지기를 원하는 경우

LOG_ARCHIVE_FORMAT="ORA%T%S.ARC"

  • 초기화 파일은 오라클 인스턴스가 기동될 때마다 읽혀지므로, 매개변수들을 변경하더라도 인스턴스가 종료되어 재기동될 때까지는 효력이 없다.

  • 자동 아카이빙을 활성화한다고 데이터베이스가 ARCHIVELOG 모드 상태로 되는 것은 아니다.

    • ARCHIVELOG 모드 상태로 설정한다고 해서, 자동 아카이빙 프로세스가 활성화하는 것도 아니다.
  • LOG_ARCHIVE_START 매개변수는 기본적으로 FALSE로 설정되어 있다.

    • ARCHIVELOG 모드의 설정과, LOG_ARCHIVE_START 설정의 불일치로, 오라클 인스턴스가 끝없이 기다리는 경우를 볼 수 있다.

      ✔️ 우선 초기화 매개변수를 변경한 다음, ALTER DATABASE ARCHIVELOG 명령어를 사용하자.

  • 아카이브 로그 대상 위치에, 리두 로그를 저장할 충분한 공간이 있는지 확인해야 한다.

    • 아카이브 로그 파일 대상 위치가 꽉 찬 경우, 오라클은 추가적인 리두로그 파일을 아카이빙할 수 없으므로 동작을 멈추게 된다.

아카이브 로그 관련 매개변수

  • 오라클 8 이후 버전에서 온라인 리두 로그를 다중화할 수 있듯, 여러 개의 아카이브 로그 대상 위치를 지정할 수 있다. 오라클은 채워진 리두로그를 지정된 위치에 복사한다.
  • 또한, 리두 로그가 반드시 모든 아카이브 로그 대상 위치에 성공적으로 복사되어야 하는지 여부도 지정할 수 있다.
  • LOG_ARCHIVE_DUPLEX_DEST: 리두 로그가 중복적으로 저장될 추가 위치를 지정한다.
  • LOG_ARCHIVE_MIN_SUCCEED_DEST: 리두 로그가 반드시 하나 또는 모든 위치에 성공적으로 작성되어야 하는지 여부를 표시한다.
  • 오라클 8i버전부터 재난 복구에 대비하여, 원격지 시스템을 포함한 최대 다섯군데의 필수 또는 선택 아카이브 로그 대상 위치를 지정할 수 있다.
  • 추가적인 업무 부담을 지원하도록 다중 아카이빙 프로세스에 대한 자동 지원기능을 지원한다.

0개의 댓글