[오라클] Oracle® Database Concepts 챕터 13 한글 번역

torch·2024년 7월 23일
0

Oracle

목록 보기
13/13
post-thumbnail

Reference : 13. Oracle Database Instance

*GPT 번역 기반으로 내용이 정확하지 않을 수 있습니다.


13 Oracle 데이터베이스 인스턴스

이 장에서는 Oracle 데이터베이스 인스턴스의 본질, 인스턴스와 관련된 매개 변수 및 진단 파일, 인스턴스 생성 및 데이터베이스 열기와 닫기 시 발생하는 일을 설명합니다.

이 장에는 다음 섹션이 포함되어 있습니다:

  • Oracle 데이터베이스 인스턴스 소개
  • 데이터베이스 인스턴스 시작 및 종료 개요
  • 체크포인트 개요
  • 인스턴스 복구 개요
  • 매개 변수 파일 개요
  • 진단 파일 개요

Oracle 데이터베이스 인스턴스 소개

데이터베이스 인스턴스는 데이터베이스 파일을 관리하는 메모리 구조 집합입니다.

물리적 수준에서 CDB는 CREATE DATABASE 문에 의해 디스크에 생성된 파일 집합입니다. CDB는 하나 이상의 사용자 생성 PDB를 포함합니다. PDB는 CDB에 속한 전체 데이터 파일 집합 내에서 자체 데이터 파일 세트를 포함합니다. 데이터베이스 인스턴스는 CDB 및 그 PDB와 관련된 데이터를 관리하고 사용자에게 서비스를 제공합니다.

실행 중인 모든 CDB는 적어도 하나의 Oracle 데이터베이스 인스턴스와 연결됩니다. 인스턴스는 메모리에 존재하고 데이터베이스(좁은 의미의 데이터베이스)는 디스크에 있는 파일 집합이기 때문에, 인스턴스는 데이터베이스 없이 존재할 수 있으며 데이터베이스도 인스턴스 없이 존재할 수 있습니다.

데이터베이스 인스턴스 구조

인스턴스가 시작되면 Oracle 데이터베이스는 시스템 글로벌 영역(SGA)이라는 메모리 영역을 할당하고 하나 이상의 백그라운드 프로세스를 시작합니다.

SGA는 다음과 같은 다양한 목적을 제공합니다:

  • 많은 프로세스 및 스레드가 동시에 접근하는 내부 데이터 구조 유지
  • 디스크에서 읽어온 데이터 블록 캐싱
  • 온라인 리두 로그 파일에 쓰기 전에 리두 데이터를 버퍼링
  • SQL 실행 계획 저장

단일 컴퓨터에서 실행되는 Oracle 프로세스는 SGA를 공유합니다. Oracle 프로세스가 SGA와 연결되는 방식은 운영 체제에 따라 다릅니다.

데이터베이스 인스턴스에는 백그라운드 프로세스가 포함됩니다. 서버 프로세스와 이들 프로세스에 할당된 프로세스 메모리도 인스턴스에 존재합니다. 서버 프로세스가 종료되어도 인스턴스는 계속 작동합니다.

다음 그래픽은 Oracle 데이터베이스 인스턴스의 주요 구성 요소를 보여줍니다.

그림 13-1 데이터베이스 인스턴스

그림 13-1 설명
"시스템 글로벌 영역(SGA) 개요"를 참조하십시오.

"백그라운드 프로세스 개요"를 참조하십시오.

데이터베이스 인스턴스 구성

Oracle 데이터베이스는 단일 인스턴스 구성 또는 Oracle Real Application Clusters(Oracle RAC) 구성으로 실행됩니다. 이 두 구성은 상호 배타적입니다.

단일 인스턴스 구성에서는 데이터베이스와 데이터베이스 인스턴스 간에 일대일 관계가 존재합니다. Oracle RAC에서는 데이터베이스와 데이터베이스 인스턴스 간에 일대다 관계가 존재합니다.

다음 그림은 가능한 데이터베이스 인스턴스 구성을 보여줍니다.

그림 13-2 데이터베이스 인스턴스 구성

그림 13-2 설명
단일 인스턴스 구성이나 Oracle RAC 구성 모두에서 데이터베이스 인스턴스는 한 번에 하나의 데이터베이스와만 연결됩니다. 하나의 데이터베이스 인스턴스를 시작하여 하나의 데이터베이스에 마운트할 수 있지만, 동일한 인스턴스로 두 개의 데이터베이스를 동시에 마운트할 수는 없습니다.

참고: 특별한 언급이 없는 한 이 장에서는 단일 인스턴스 데이터베이스 구성을 논의합니다.
하나의 컴퓨터에서 여러 인스턴스가 동시에 실행되어 각기 다른 데이터베이스에 접근할 수 있습니다. 예를 들어, 하나의 컴퓨터는 두 개의 서로 다른 데이터베이스(prod1과 prod2)를 호스트할 수 있습니다. 하나의 데이터베이스 인스턴스가 prod1을 관리하고, 별도의 인스턴스가 prod2를 관리합니다.

참고:
Oracle Real Application Clusters Administration and Deployment Guide에서 Oracle RAC에 대한 구체적인 정보를 참조하십시오.

읽기/쓰기 및 읽기 전용 인스턴스

모든 데이터베이스 인스턴스는 읽기/쓰기 또는 읽기 전용입니다.

기본 설정인 읽기/쓰기 데이터베이스 인스턴스는 DML을 처리할 수 있으며 클라이언트 애플리케이션의 직접 연결을 지원합니다. 반면, 읽기 전용 데이터베이스 인스턴스는 쿼리를 처리할 수 있지만 수정 DML(UPDATE, DELETE, INSERT, MERGE)을 지원하지 않으며 클라이언트의 직접 연결을 지원하지 않습니다.

참고: 특별히 언급되지 않은 한, 이 매뉴얼에서 데이터베이스 인스턴스에 대한 모든 참조는 읽기/쓰기 인스턴스를 의미합니다.
이전 릴리스에서는 스탠바이 데이터베이스에 접근하는 인스턴스를 제외하고 모든 데이터베이스 인스턴스가 읽기/쓰기였습니다. Oracle Database 12c Release 2(12.2)부터는 읽기 전용 및 읽기/쓰기 인스턴스가 단일 데이터베이스 내에 공존할 수 있습니다. 이 구성은 데이터 쿼리와 수정 SQL 문을 모두 수행하는 병렬 SQL 문에 유용합니다. 읽기/쓰기 및 읽기 전용 인스턴스는 쿼리를 수행할 수 있으며, 읽기/쓰기 인스턴스는 데이터를 수정합니다.

읽기/쓰기 인스턴스와 달리 읽기 전용 인스턴스는 다음과 같은 특성을 가집니다:

  • 이미 읽기/쓰기 인스턴스가 열어둔 데이터베이스만 열 수 있습니다.
  • 체크포인트 및 아카이버 프로세스 등 많은 백그라운드 프로세스를 비활성화합니다.
  • 비활성화된 리두 스레드 또는 온라인 리두 로그가 없는 스레드를 마운트할 수 있습니다.

인스턴스를 읽기 전용으로 지정하려면 INSTANCE_MODE 초기화 매개 변수를 READ_ONLY로 설정하십시오. 이 매개 변수의 기본값은 READ_WRITE입니다.

참고:
"백그라운드 프로세스 개요"에서 체크포인트 및 아카이버 백그라운드 프로세스에 대해 자세히 알아보십시오.

"온라인 리두 로그 개요"를 참조하십시오.

Oracle Database Reference에서 INSTANCE_MODE 초기화 매개 변수에 대해 자세히 알아보십시오.

데이터베이스 인스턴스의 기간

데이터베이스 인스턴스는 STARTUP 명령으로 생성되고 종료될 때 끝납니다.

이 기간 동안 데이터베이스 인스턴스는 하나의 데이터베이스와만 연결될 수 있습니다. 또한 인스턴스는 데이터베이스를 한 번만 마운트할 수 있으며, 한 번만 닫고, 한 번만 열 수 있습니다. 데이터베이스를 닫거나 종료한 후에는 이 데이터베이스를 마운트하고 열기 위해 다른 인스턴스를 시작해야 합니다.

다음 표는 데이터베이스 인스턴스가 이전에 닫은 데이터베이스를 다시 열려고 시도하는 상황을 설명합니다.

표 13-1 인스턴스의 기간

명령어설명
SQL> STARTUPORACLE 인스턴스가 시작되었습니다. 총 시스템 글로벌 영역 468,729,856 바이트 고정 크기 1,333,556 바이트 가변 크기 440,403,660 바이트 데이터베이스 버퍼 16,777,216 바이트 리두 버퍼 10,215,424 바이트 데이터베이스가 마운트되었습니다. 데이터베이스가 열렸습니다. STARTUP 명령어가 인스턴스를 생성하고, 데이터베이스를 마운트하고 엽니다.
SQL> SELECT TO_CHAR(STARTUP_TIME, 'MON-DD-RR HH24:MI:SS') AS "Inst Start Time" FROM V$INSTANCE;Inst Start Time ------------------ JUN-18-14 13:14:48 이 쿼리는 현재 인스턴스가 시작된 시간을 보여줍니다.
SQL> SHUTDOWN IMMEDIATE인스턴스가 데이터베이스를 닫고 종료하여 이 인스턴스의 수명이 끝납니다.
SQL> STARTUPOracle 인스턴스가 시작되었습니다. . . . STARTUP 명령어가 새로운 인스턴스를 생성하고 데이터베이스를 마운트하고 엽니다.
SQL> SELECT TO_CHAR(STARTUP_TIME, 'MON-DD-RR HH24:MI:SS') AS "Inst Start Time" FROM V$INSTANCE;Inst Start Time ------------------ JUN-18-14 13:16:40 이 쿼리는 현재 인스턴스가 시작된 시간을 보여줍

니다. 다른 시작 시간은 이 인스턴스가 데이터베이스를 종료한 인스턴스와 다름을 보여줍니다. |

데이터베이스 인스턴스 식별

하나의 호스트에 여러 데이터베이스 인스턴스가 존재할 수 있습니다. 따라서 액세스하려는 인스턴스를 지정할 수 있는 방법이 필요합니다.

Oracle Optimal Flexible Architecture(OFA) 규칙은 잘 조직된 Oracle 설치를 보장하기 위해 만들어진 구성 지침입니다. 이 섹션의 예는 OFA 아키텍처를 가정합니다.

이 섹션에는 다음 주제가 포함되어 있습니다:

  • Oracle 기본 디렉토리
  • Oracle 홈 디렉토리
  • Oracle 시스템 식별자(SID)

참고:
Oracle Database Installation Guide for Linux에서 OFA 개요를 참조하십시오.

Oracle 기본 디렉토리

Oracle 기본 디렉토리는 Oracle 제품의 바이너리를 저장합니다.

Oracle 기본 디렉토리는 Oracle 데이터베이스 설치 소유자의 데이터베이스 홈 디렉토리입니다. 하나의 호스트에는 여러 Oracle 데이터베이스 설치가 있을 수 있으며, 여러 Oracle 데이터베이스 소프트웨어 설치 소유자가 있을 수 있습니다.

다음 예는 운영 체제 사용자 계정 oracle의 Oracle 기본 디렉토리를 보여줍니다:

/u01/app/oracle

위 경로에서 /u01/은 마운트 포인트이고, /u01/app/은 애플리케이션 소프트웨어의 서브트리입니다.

참고:
Oracle Database Installation Guide for Linux에서 Oracle 기본 디렉토리 개요를 참조하십시오.

Oracle 홈 디렉토리

Oracle 홈은 Oracle 데이터베이스의 소프트웨어 위치입니다.

각 Oracle 데이터베이스 소프트웨어 설치 시마다 새로운 Oracle 홈 디렉토리를 지정해야 합니다. 기본적으로 Oracle 홈 디렉토리는 Oracle 기본(ORACLE_BASE) 디렉토리 트리 내의 하위 디렉토리입니다.

이 릴리스 또는 이전 릴리스의 데이터베이스 소프트웨어를 동일한 호스트에 여러 번 설치할 수 있으며, 하나의 Oracle 기본 내의 서로 다른 Oracle 홈 디렉토리에 설치할 수 있습니다. 다른 버전의 여러 데이터베이스가 서로 다른 사용자 계정에 의해 동시에 공존할 수 있습니다.

다음 예는 /u01/app/oracle/ 기본 디렉토리 내의 세 가지 다른 Oracle 홈의 전체 경로 이름을 보여줍니다:

/u01/app/oracle/product/12.1.0/dbhome_1
/u01/app/oracle/product/12.1.0/dbhome_2
/u01/app/oracle/product/18.0.0/dbhome_1

Oracle 기본(/u01/app/oracle/) 이후의 경로 이름 부분에는 제품 릴리스 번호(예: 12.1.0)와 Oracle 홈 상대 디렉토리(예: dbhome_1)가 포함됩니다. /u01/app/oracle/product/12.1.0/ 디렉토리는 두 개의 별도 Oracle 홈: dbhome_1과 dbhome_2를 포함합니다.

Oracle Database 18c부터 읽기 전용 Oracle 홈을 소프트웨어 이미지로 생성할 수 있습니다. 읽기 전용 Oracle 홈은 바이너리와 같은 정적 파일을 저장합니다. Oracle 기본 홈(ORACLE_BASE_HOME) 디렉토리는 ORACLE_BASE/homes/home_name에 위치하며 Oracle 홈에 특정한 동적 파일을 저장합니다. Oracle 기본 구성 디렉토리(ORACLE_BASE_CONFIG)는 Oracle 기본의 모든 Oracle 홈이 공유하며 인스턴스에 특정한 동적 파일을 저장합니다.

다음 예는 첫 번째 경로가 읽기 전용 Oracle 홈이고, 두 번째 경로가 이 Oracle 홈의 Oracle 기본 홈을 보여줍니다:

/u01/app/oracle/product/18.0.0/ro_dbhome_1
/u01/app/oracle/homes/ro_dbhome_1

참고:
Oracle Database Installation Guide for Linux에서 Oracle 홈 개요를 참조하십시오.

Oracle 시스템 식별자(SID)

시스템 식별자(SID)는 특정 호스트의 Oracle 데이터베이스 인스턴스에 대한 고유 이름입니다.

UNIX 및 Linux에서는 Oracle 데이터베이스가 SID 및 Oracle 홈 값을 사용하여 공유 메모리 키를 생성합니다. 또한 Oracle 데이터베이스는 기본적으로 초기화 매개 변수 파일을 찾기 위해 SID를 사용하여 관련 파일(예: 데이터베이스 제어 파일)을 찾습니다.

대부분의 플랫폼에서 ORACLE_SID 환경 변수가 SID를 설정하고 ORACLE_HOME 변수는 Oracle 홈을 설정합니다. 데이터베이스 인스턴스에 연결할 때 클라이언트는 Oracle Net 연결에서 SID를 지정하거나 네트 서비스 이름을 사용할 수 있습니다. Oracle 데이터베이스는 서비스 이름을 ORACLE_HOME 및 ORACLE_SID로 변환합니다.

전통적인 읽기/쓰기 Oracle 홈에는 인스턴스 특정 파일이 포함됩니다. 그러나 Oracle 홈이 읽기 전용인 경우 인스턴스 특정 파일은 Oracle 기본에 별도로 저장됩니다. 두 경우 모두 이름에 SID가 포함된 파일은 Oracle 기본 구성 디렉토리(ORACLE_BASE_CONFIG)의 dbs 하위 디렉토리에 위치합니다. 이러한 분리를 통해 사용자는 기존 읽기 전용 Oracle 홈에 있는 소프트웨어를 사용하여 데이터베이스를 생성한 후, 새로운 읽기 전용 Oracle 홈에 있는 소프트웨어를 사용하여 이 데이터베이스의 인스턴스를 시작할 수 있습니다.

참고:
"서비스 이름"을 참조하십시오.

Oracle Database Administrator’s Guide에서 Oracle SID를 지정하는 방법을 배우십시오.

데이터베이스 인스턴스 시작 및 종료 개요

데이터베이스 인스턴스는 사용자가 데이터베이스에 접근할 수 있도록 합니다. 인스턴스와 데이터베이스는 여러 상태에 있을 수 있습니다.

인스턴스 및 데이터베이스 시작 개요

보통, 수동으로 인스턴스를 시작하고, 데이터베이스를 마운트하고 열어서 사용자에게 사용할 수 있게 합니다. 이러한 단계를 수행하려면 SQL*Plus STARTUP 명령어, Oracle Enterprise Manager(Enterprise Manager) 또는 SRVCTL 유틸리티를 사용할 수 있습니다.

Oracle Net을 사용하여 데이터베이스 인스턴스를 시작하려면 다음 조건이 충족되어야 합니다:

  • 데이터베이스가 Oracle Net 리스너에 정적으로 등록되어 있어야 합니다.
  • 클라이언트가 SYSDBA 권한으로 데이터베이스에 연결되어 있어야 합니다.
  • 리스너가 전용 서버를 생성하여 데이터베이스 인스턴스를 시작할 수 있어야 합니다.

다음 그래픽은 데이터베이스가 종료 상태에서 열림 상태로 진행되는 과정을 보여줍니다.

그림 13-3 인스턴스 및 데이터베이스 시작 순서

그림 13-3 설명
데이터베이스는 종료 상태에서 열림 상태로 진행될 때 다음 단계를 거칩니다.

표 13-2 인스턴스 시작 단계

단계마운트 상태설명자세히 알아보기
1데이터베이스를 마운트하지 않고 인스턴스 시작인스턴스가 시작되었지만 데이터베이스와는 아직 연결되지 않았습니다."인스턴스가 시작되는 방법"
2데이터베이스 마운트인스턴스가 시작되어 데이터베이스의 제어 파일을 읽어 데이터베이스와 연결됩니다. 데이터베이스는 사용자에게 닫혀 있습니다."데이터베이스가 마운트되는 방법"
3데이터베이스 열림인스턴스가 시작되어 열린 데이터베이스와 연결됩니다. 데이터 파일에 포함된 데이터는 권한 있는 사용자에게 접근 가능합니다."데이터베이스가 열리는 방법"

참고:

  • "The Oracle Net Listener"
  • "Overview of Control Files"
  • Oracle Database Administrator’s Guide에서 인스턴스를 시작하는 방법을 참조하십시오.
  • Oracle Database Administrator’s Guide에서 SRVCTL 사용하는 방법을 참조하십시오.

관리자 권한으로 연결

데이터베이스 시작 및 종료는 관리자 권한으로 Oracle Database에 연결된 사용자에게만 허용되는 강력한 관리 옵션입니다.

일반 사용자는 Oracle 데이터베이스의 현재 상태를 제어할 수 없습니다. 운영 체제에 따라 사용자가 관리자 권한을 가지는 조건은 다음 중 하나입니다:

  • 사용자의 운영 체제 권한이 관리자 권한을 사용하여 연결할 수 있도록 합니다.
  • 사용자가 특별한 시스템 권한을 부여받고, 데이터베이스가 네트워크를 통해 데이터베이스 관리자를 인증하는 데 암호 파일을 사용합니다.

다음과 같은 특별 시스템 권한이 데이터베이스가 열리지 않았을 때에도 데이터베이스 인스턴스에 접근할 수 있도록 합니다:

  • SYSDBA
  • SYSOPER
  • SYSBACKUP
  • SYSDG
  • SYSKM

위의 권한에 대한 제어는 데이터베이스 자체 외부에서 이루어집니다. SYSDBA 시스템 권한으로 데이터베이스에 연결하면 SYS가 소유한 스키마에 있게 됩니다. SYSOPER로 연결하면 공용 스키마에 있게 됩니다. SYSOPER 권한은 SYSDBA 권한의 하위 집합입니다.

참고:

  • "SYS and SYSTEM Schemas"
  • "Overview of Database Security"에서 암호 파일 및 데이터베이스 관리자 인증에 대해 알아보십시오.
  • Oracle Database Security Guide에서 관리 권한 관리에 대해 알아보십시오.
  • Oracle Database Administrator’s Guide에서 시스템 권한에 대해 자세히 알아보십시오.
  • Oracle Database Installation Guide에서 운영 체제 권한 그룹에 대해 자세히 알아보십시오.

인스턴스가 시작되는 방법

Oracle Database가 인스턴스를 시작할 때 다음 단계를 거칩니다:

  • 플랫폼별 기본 위치에서 서버 매개 변수 파일을 검색하고, 찾지 못하면 텍스트 초기화 매개 변수 파일을 검색합니다(STARTUP 명령어에 SPFILE 또는 PFILE 매개 변수를 지정하여 기본 동작을 재정의할 수 있음).
  • 초기화 매개 변수 값을 결정하기 위해 매개 변수 파일을 읽습니다.
  • 초기화 매개 변수 설정을 기반으로 SGA를 할당합니다.
  • Oracle 백그라운드 프로세스를 시작합니다.
  • 알림 로그 및 추적 파일을 열고, 모든 명시적 매개 변수 설정을 유효한 매개 변수 구문으로 알림 로그에 기록합니다.

이 단계에서는 데이터베이스가 인스턴스와 연결되지 않습니다. NOMOUNT 상태가 필요한 시나리오에는 데이터베이스 생성 및 특정 백업 및 복구 작업이 포함됩니다.

참고:
Oracle Database Administrator’s Guide에서 서버 매개 변수 파일을 사용하여 초기화 매개 변수를 관리하는 방법을 참조하십시오.

데이터베이스가 마운트되는 방법

인스턴스는 데이터베이스와 연결하기 위해 데이터베이스를 마운트합니다.

데이터베이스를 마운트하려면, 인스턴스는 CONTROL_FILES 초기화 매개 변수에 지정된 데이터베이스 제어 파일의 이름을 가져와 파일을 엽니다. Oracle Database는 제어 파일을 읽어 데이터 파일과 온라인 리두 로그 파일의 이름을 찾아 데이터베이스를 열 때 접근을 시도합니다.

마운트된 데이터베이스에서는 데이터베이스가 닫혀 있으며 데이터베이스 관리자만 접근할 수 있습니다. 관리자는 특정 유지 관리 작업을 완료하는 동안 데이터베이스를 닫아둘 수 있습니다. 그러나 데이터베이스는 정상적인 작업을 위해 사용할 수 없습니다.

Oracle Database가 동일한 데이터베이스를 여러 인스턴스가 동시에 마운트할 수 있게 허용하는 경우, CLUSTER_DATABASE 초기화 매개 변수 설정이 데이터베이스를 여러 인스턴스에 사용할 수 있게 합니다. 데이터베이스 동작은 설정에 따라 다릅니다:

  • 첫 번째 인스턴스가 데이터베이스를 마운트할 때 CLUSTER_DATABASE가 false(기본값)인 경우, 해당 인스턴스만 데이터베이스를 마운트할 수 있습니다.
  • 첫 번째 인스턴스가 CLUSTER_DATABASE가 true인 경우, 다른 인스턴스는 CLUSTER_DATABASE 매개 변수 설정이 true로 설정된 경우 데이터베이스를 마운트할 수 있습니다. 데이터베이스 생성 시 지정된 사전 결정된 최대 수의 인스턴스가 데이터베이스를 마운트할 수 있습니다.

참고:

  • Oracle Database Administrator’s Guide에서 데이터베이스를 마운트하는 방법을 참조하십시오.
  • Oracle Real Application Clusters Administration and Deployment Guide에서 하나의 데이터베이스에 여러 인스턴스를 사용하는 것에 대해 자세히 알아보십시오.

데이터베이스가 열리는 방법

마운트된 데이터베이스를 열면 일반 데이터베이스 작업을 위해 사용할 수 있게 됩니다.

유효한 모든 사용자는 열린 데이터베이스에 연결하고 데이터를 접근할 수 있습니다. 일반적으로 데이터베이스 관리자가 데이터베이스를 열어 일반적으로 사용할 수 있게 합니다.

데이터베이스를 열 때 Oracle Database는 다음 작업을 수행합니다:

  • 언두 테이블스페이스를 제외한 테이블스페이스의 온라인 데이터 파일을 엽니다.
  • 데이터베이스가 이전에 종료되었을 때 테이블스페이스가 오프라인 상태였던 경우, 해당 테이블스페이스와 해당 데이터 파일은 데이터베이스가 다시 열릴 때 오프라인 상태로 남습니다.
  • 언두 테이블스페이스를 획득합니다.
  • 여러 개의 언두 테이블스페이스가 있는 경우, UNDO_TABLESPACE 초기화 매개 변수가 사용할 언두 테이블스페이스를 지정합니다. 이 매개 변수가 설정되지 않은 경우, 사용 가능한 첫 번째 언두 테이블스페이스가 선택됩니다.
  • 온라인 리두 로그 파일을 엽니다.

참고:

  • "Online and Offline Tablespaces"
  • "Data Repair"

읽기 전용 모드

기본적으로 데이터베이스는 읽기/쓰기 모드로 열립니다. 이 모드에서는 사용자가 데이터에 변경을 가할 수 있으며 온라인 리두 로그에 리두를 생성합니다. 대안으로, 읽기 전용 모드로 열어 사용자 트랜잭션에 의한 데이터 수정이 없도록 할 수 있습니다.

참고: 기본적으로 물리적 스탠바이 데이터베이스는 읽기 전용 모드로 열립니다.
읽기 전용 모드는 데이터베이스 접근을 읽기 전용 트랜잭션으로 제한하여 데이터 파일이나 온라인 리두 로그 파일에 쓸 수 없게 합니다. 그러나 데이터베이스는 리두를 생성하지 않고도 복구 또는 데이터베이스 상태를 변경하는 작업을 수행할 수 있습니다. 예를 들어, 읽기 전용 모드에서는:

  • 데이터 파일을 오프라인 및 온라인 상태로 전환할 수 있습니다. 그러나 영구 테이블스페이스를 오프라인으로 전

환할 수는 없습니다.

  • 오프라인 데이터 파일과 테이블스페이스를 복구할 수 있습니다.
  • 데이터베이스 상태에 대한 업데이트를 위해 제어 파일을 사용할 수 있습니다.
  • CREATE TEMPORARY TABLESPACE 문으로 생성된 임시 테이블스페이스는 읽기/쓰기가 가능합니다.
  • 운영 체제 감사 로그, 추적 파일 및 알림 로그에 쓰기가 계속될 수 있습니다.

참고:

  • Oracle Database Administrator’s Guide에서 읽기 전용 모드로 데이터베이스를 여는 방법을 참조하십시오.
  • Oracle Data Guard Concepts and Administration

데이터베이스 파일 검사

인스턴스가 데이터베이스를 열려고 할 때 데이터 파일이나 리두 로그 파일 중 하나가 없거나, 파일이 존재하지만 일관성 검사를 통과하지 못한 경우, 데이터베이스는 오류를 반환합니다. 미디어 복구가 필요할 수 있습니다.

참고:

  • "Backup and Recovery"

데이터베이스 및 인스턴스 종료 개요

일반적인 사용 사례에서는 수동으로 데이터베이스를 종료하여 유지 관리 또는 기타 관리 작업을 수행하는 동안 사용자가 접근할 수 없도록 합니다. 이러한 단계를 수행하려면 SQL*Plus SHUTDOWN 명령어 또는 Enterprise Manager를 사용할 수 있습니다.

다음 그림은 열린 상태에서 일관된 종료 상태로 진행되는 과정을 보여줍니다.

그림 13-4 인스턴스 및 데이터베이스 종료 순서

그림 13-4 설명
Oracle Database는 열린 데이터베이스가 일관되게 종료될 때마다 다음 단계를 자동으로 수행합니다.

표 13-3 일관된 종료 단계

단계마운트 상태설명자세히 알아보기
1데이터베이스 닫힘데이터베이스가 마운트되었지만, 온라인 데이터 파일과 리두 로그 파일은 닫혀 있습니다."데이터베이스가 닫히는 방법"
2데이터베이스 마운트 해제인스턴스는 시작되었지만, 더 이상 데이터베이스의 제어 파일과 연결되지 않습니다."데이터베이스가 마운트 해제되는 방법"
3데이터베이스 인스턴스 종료데이터베이스 인스턴스가 더 이상 시작되지 않습니다."인스턴스가 종료되는 방법"

Oracle Database는 인스턴스 장애나 SHUTDOWN ABORT와 같은 상황에서 모든 단계를 거치지 않고 인스턴스를 즉시 종료합니다.

참고:

  • Oracle Database Administrator’s Guide에서 데이터베이스를 종료하는 방법을 참조하십시오.

종료 모드

SYSDBA 또는 SYSOPER 권한이 있는 데이터베이스 관리자는 SQL*Plus SHUTDOWN 명령어 또는 Enterprise Manager를 사용하여 데이터베이스를 종료할 수 있습니다. SHUTDOWN 명령어는 종료 동작을 결정하는 옵션을 가집니다.

다음 표는 다양한 종료 모드의 동작을 요약한 것입니다.

표 13-4 데이터베이스 종료 모드

데이터베이스 동작ABORTIMMEDIATETRANSACTIONALNORMAL
새로운 사용자 연결 허용아니요아니요아니요아니요
현재 세션이 종료될 때까지 대기아니요아니요아니요
현재 트랜잭션이 종료될 때까지 대기아니요아니요
체크포인트를 수행하고 열린 파일을 닫음아니요

가능한 SHUTDOWN 명령어는 다음과 같습니다:

  • SHUTDOWN ABORT

이 모드는 다른 형태의 종료가 성공하지 않을 때와 같은 비상 상황을 위한 것입니다. 이 종료 모드는 가장 빠릅니다. 그러나 데이터 파일을 일관되게 만들기 위해 인스턴스 복구가 필요하므로 이후 데이터베이스를 다시 여는 데 상당한 시간이 소요될 수 있습니다.

SHUTDOWN ABORT는 열린 데이터 파일을 체크포인트하지 않으므로, 데이터베이스를 다시 열기 전에 인스턴스 복구가 필요합니다. 다른 종료 모드는 데이터베이스를 다시 열기 전에 인스턴스 복구가 필요하지 않습니다.

참고: CDB에서는 PDB에 대해 SHUTDOWN ABORT를 실행하는 것이 non-CDB에서 SHUTDOWN IMMEDIATE를 실행하는 것과 같습니다.

  • SHUTDOWN IMMEDIATE

이 모드는 일반적으로 SHUTDOWN ABORT 다음으로 가장 빠릅니다. Oracle Database는 실행 중인 SQL 문을 종료하고 사용자를 연결 해제합니다. 활성 트랜잭션은 종료되며 커밋되지 않은 변경 사항은 롤백됩니다.

  • SHUTDOWN TRANSACTIONAL

이 모드는 사용자가 새로운 트랜잭션을 시작하지 못하도록 하지만, 현재 트랜잭션이 완료될 때까지 기다렸다가 종료됩니다. 현재 트랜잭션의 성격에 따라 이 모드는 상당한 시간이 소요될 수 있습니다.

  • SHUTDOWN NORMAL

이것이 기본 종료 모드입니다. 데이터베이스는 연결된 모든 사용자가 연결을 끊을 때까지 기다렸다가 종료됩니다.

참고:

  • Oracle Database Administrator’s Guide에서 다양한 종료 모드에 대해 자세히 알아보십시오.
  • SQL*Plus User's Guide and Reference에서 SHUTDOWN 명령어에 대해 자세히 알아보십시오.

데이터베이스가 닫히는 방법

데이터베이스 종료의 일환으로 데이터베이스 닫기 작업이 수행됩니다. 작업의 성격은 데이터베이스 종료가 정상적이냐 비정상적이냐에 따라 다릅니다.

정상 종료 동안 데이터베이스가 닫히는 방법

SHUTDOWN ABORT를 제외한 옵션으로 SHUTDOWN의 일환으로 데이터베이스가 닫히면, Oracle Database는 SGA의 데이터를 데이터 파일 및 온라인 리두 로그 파일에 기록합니다.

그 후, 데이터베이스는 온라인 데이터 파일 및 온라인 리두 로그 파일을 닫습니다. 오프라인 테이블스페이스의 오프라인 데이터 파일은 이미 닫혀 있습니다. 데이터베이스가 다시 열리면 오프라인 상태였던 테이블스페이스는 오프라인 상태로 남습니다.

이 단계에서는 데이터베이스가 닫혀 있으며 정상적인 작업을 위해 접근할 수 없습니다. 데이터베이스가 닫힌 후에도 제어 파일은 열려 있습니다.

비정상 종료 동안 데이터베이스가 닫히는 방법

SHUTDOWN ABORT 또는 비정상 종료가 발생하면 열린 데이터베이스의 인스턴스가 닫히고 데이터베이스가 즉시 종료됩니다.

비정상 종료에서는 Oracle Database가 SGA의 버퍼에 있는 데이터를 데이터 파일 및 리두 로그 파일에 기록하지 않습니다. 데이터베이스를 다시 여는 작업은 인스턴스 복구가 필요하며, 이는 Oracle Database가 자동으로 수행합니다.

데이터베이스가 마운트 해제되는 방법

데이터베이스가 닫힌 후, Oracle Database는 데이터베이스를 인스턴스와 연결 해제하기 위해 마운트를 해제합니다.

데이터베이스가 마운트 해제되면 Oracle Database는 데이터베이스의 제어 파일을 닫습니다. 이 시점에서 데이터베이스 인스턴스는 메모리에 남아 있습니다.

인스턴스가 종료되는 방법

데이터베이스 종료의 마지막 단계는 인스턴스를 종료하는 것입니다. 데이터베이스 인스턴스가 종료되면, SGA는 메모리를 차지하지 않으며, 백그라운드 프로세스가 종료됩니다.

특이한 상황에서는 데이터베이스 인스턴스 종료가 깨끗하게 이루어지지 않을 수 있습니다. 메모리 구조가 메모리에서 제거되지 않거나 백그라운드 프로세스 중 하나가 종료되지 않을 수 있습니다. 이전 인스턴스의 잔해가 남아 있는 경우, 이후 인스턴스 시작이 실패할 수 있습니다. 이러한 상황에서는 이전 인스턴스의 잔해를 제거한 후 새로운 인스턴스를 시작하거나 SHUTDOWN ABORT 명령어를 실행하여 새로운 인스턴스 시작을 강제할 수 있습니다.

일부 경우, 프로세스 정리 자체가 오류를 만날 수 있으며, 이는 프로세스 모니터(PMON) 또는 인스턴스의 종료를 초래할 수 있습니다. 동적 초기화 매개 변수 INSTANCE_ABORT_DELAY_TIME은 내부적으로 생성된 인스턴스 장애를 지연하는 시간을 초 단위로 지정합니다. 이 지연은 사용자가 대응할 시간을 제공합니다. 데이터베이스는 지연된 종료가 시작될 때 알림 로그에 메시지를 기록합니다. 특정 데이터베이스 자원을 격리함으로써 인스턴스가 종료를 피할 수 있는 상황도 있습니다.

참고:

  • Oracle Database Administrator’s Guide에서 데이터베이스 종료에 대한 자세한 정보를 참조하십시오.
  • Oracle Database Reference에서 INSTANCE_ABORT_DELAY_TIME 초기화 매개 변수에 대해 자세히 알아보십시오.

체크포인트 개요

체크포인트는 일관된 데이터베이스 종료, 인스턴스 복구 및 일반적인 Oracle Database 운영에서 중요한 메커니즘입니다.

이 용어는 다음과 같은 관련된 의미를 가집니다:

  • 인스턴스 복구가 시작되어야 하는 리두 스트림의 SCN(시스템 변경 번호)을 나타내는 데이터 구조
  • 체크포인트 위치는 데이터베이스 버퍼 캐시에서 가장 오래된 더티 버퍼에 의해 결정됩니다. 체크포인트 위치는 리두 스트림에 대한 포인터 역할을 하며, 제어 파일과 각 데이터 파일 헤더에 저장됩니다.
  • 데이터베이스 버퍼 캐시에서 디스크로 수정된 데이터베이스 버퍼를 쓰는 작업

참고:

  • "시스템 변경 번호 (SCNs)"

체크포인트의 목적

Oracle Database는 여러 목표를 달성하기 위해 체크포인트를 사용합니다.

목표에는 다음이 포함됩니다:

  • 인스턴스나 미디어 장애 발생 시 복구에 필요한 시간 단축
  • 데이터베이스가 버퍼 캐시의 더티 버퍼를 정기적으로 디스크에 기록하도록 보장
  • 일관된 종료 동안 데이터베이스가 모든 커밋된 데이터를 디스크에 기록하도록 보장

Oracle Database가 체크포인트를 시작하는 시점

체크포인트 프로세스(CKPT)는 체크포인트를 데이터 파일 헤더와 제어 파일에 쓰는 역할을 담당합니다.

체크포인트는 다양한 상황에서 발생합니다. 예를 들어, Oracle Database는 다음과 같은 유형의 체크포인트를 사용합니다:

  • 스레드 체크포인트

데이터베이스는 특정 목표 이전에 특정 스레드에서 리두로 수정된 모든 버퍼를 디스크에 기록합니다. 데이터베이스의 모든 인스턴스에서 스레드 체크포인트의 집합은 데이터베이스 체크포인트입니다. 스레드 체크포인트는 다음 상황에서 발생합니다:

  • 일관된 데이터베이스 종료

  • ALTER SYSTEM CHECKPOINT 문

  • 온라인 리두 로그 스위치

  • ALTER DATABASE BEGIN BACKUP 문

  • 테이블스페이스 및 데이터 파일 체크포인트

데이터베이스는 특정 목표 이전에 리두로 수정된 모든 버퍼를 디스크에 기록합니다. 테이블스페이스 체크포인트는 각 테이블스페이스의 데이터 파일마다 하나씩 데이터 파일 체크포인트의 집합입니다. 이러한 체크포인트는 테이블스페이스를 읽기 전용으로 설정하거나 오프라인으로 설정하는 정상적인 작업, 데이터 파일 축소, 또는 ALTER TABLESPACE BEGIN BACKUP을 실행하는 등의 다양한 상황에서 발생합니다.

  • 증분 체크포인트

증분 체크포인트는 온라인 리두 로그 스위치에서 많은 수의 블록을 쓰지 않도록 부분적으로 의도된 스레드 체크포인트의 일종입니다. DBW는 최소 3초마다 작업이 있는지 확인합니다. DBW가 더티 버퍼를 쓰면 체크포인트 위치가 진전되어 CKPT가 체크포인트 위치를 제어 파일에 기록하게 하지만 데이터 파일 헤더에는 기록하지 않습니다.

기타 체크포인트 유형에는 인스턴스 및 미디어 복구 체크포인트와 스키마 객체가 삭제되거나 잘렸을 때 발생하는 체크포인트가 포함됩니다.

참고:

  • "체크포인트 프로세스 (CKPT)"
  • Oracle Real Application Clusters Administration and Deployment Guide에서 Oracle RAC의 글로벌 체크포인트에 대한 정보를 참조하십시오.

인스턴스 복구 개요

인스턴스 복구는 최신 체크포인트 이후에 발생한 변경 사항을 재구성하기 위해 온라인 리두 로그의 기록을 데이터 파일에 적용하는 과정입니다.

인스턴스 복구는 관리자가 이전에 불일치하게 종료된 데이터베이스를 열려고 할 때 자동으로 발생합니다.

인스턴스 복구의 목적

인스턴스 복구는 인스턴스 장애 후 데이터베이스가 일관된 상태에 있는지 확인합니다. Oracle Database가 데이터베이스 변경을 관리하는 방식 때문에 데이터베이스 파일이 일관되지 않은 상태로 남을 수 있습니다.

리두 스레드는 인스턴스에 의해 생성된 모든 변경 사항의 기록입니다. 단일 인스턴스 데이터베이스는 하나의 리두 스레드를 가지고 있지만, Oracle RAC 데이터베이스는 각 데이터베이스 인스턴스마다 하나씩 여러 리두 스레드를 가지고 있습니다.

트랜잭션이 커밋되면 로그 작성자 프로세스(LGWR)는 메모리에 있는 남은 리두 항목과 트랜잭션 SCN을 온라인 리두 로그에 기록합니다. 그러나 데이터베이스 작성자(DBW) 프로세스는 수정된 데이터 블록을 가장 효율적일 때 데이터 파일에 기록합니다. 이 때문에, 커밋되지 않은 변경 사항이 일시적으로 데이터 파일에 존재할 수 있으며, 반면 커밋된 변경 사항은 아직 데이터 파일에 존재하지 않을 수 있습니다.

열려 있는 데이터베이스의 인스턴스가 SHUTDOWN ABORT 명령어나 비정상적인 종료로 인해 실패하면 다음과 같은 상황이 발생할 수 있습니다:

  • 트랜잭션에 의해 커밋된 데이터 블록이 데이터 파일에 기록되지 않고 온라인 리두 로그에만 존재합니다. 이러한 변경 사항은 데이터 파일에 다시 적용해야 합니다.
  • 데이터 파일에는 인스턴스 실패 시 커밋되지 않은 변경 사항이 포함되어 있습니다. 이러한 변경 사항은 트랜잭션 일관성을 보장하기 위해 롤백되어야 합니다.

인스턴스 복구는 온라인 리두 로그 파일과 현재 온라인 데이터 파일만 사용하여 데이터 파일을 동기화하고 일관성을 보장합니다.

참고:

  • "데이터베이스 작성자 프로세스 (DBW)" 및 "데이터베이스 버퍼 캐시"
  • "데이터 동시성 및 일관성 소개"

Oracle Database가 인스턴스 복구를 수행하는 시점

인스턴스 복구가 필요한지 여부는 리두 스레드의 상태에 따라 달라집니다.

데이터베이스 인스턴스가 읽기/쓰기 모드로 열리면 리두 스레드는 제어 파일에 열림으로 표시되고, 인스턴스가 일관되게 종료되면 닫힘으로 표시됩니다. 제어 파일에 리두 스레드가 열림으로 표시되지만, 해당 스레드에 해당하는 스레드 인큐를 보유한 라이브 인스턴스가 없으면 데이터베이스는 인스턴스 복구가 필요합니다.

Oracle Database는 다음 상황에서 자동으로 인스턴스 복구를 수행합니다:

  • 단일 인스턴스 데이터베이스의 실패나 Oracle RAC 데이터베이스의 모든 인스턴스 실패 후 처음으로 데이터베이스를 열 때. 이 형태의 인스턴스 복구는 크래시 복구라고도 합니다. Oracle Database는 종료된 인스턴스의 온라인 리두 스레드를 함께 복구합니다.
  • Oracle RAC 데이터베이스의 일부 인스턴스만 실패할 때. 인스턴스 복구는 구성에 있는 살아남은 인스턴스에 의해 자동으로 수행됩니다.

SMON 백그라운드 프로세스는 인스턴스 복구를 수행하며, 온라인 리두를 자동으로 적용합니다. 사용자 개입은 필요하지 않습니다.

참고:

  • "시스템 모니터 프로세스 (SMON)"
  • Oracle Real

인스턴스 복구를 위한 체크포인트의 중요성

인스턴스 복구는 데이터 파일에 적용해야 할 변경 사항을 결정하기 위해 체크포인트를 사용합니다. 체크포인트 위치는 체크포인트 SCN보다 낮은 SCN을 가진 모든 커밋된 변경 사항이 데이터 파일에 저장되었음을 보장합니다.

다음 그림은 온라인 리두 로그의 리두 스레드를 보여줍니다.

그림 13-5 온라인 리두 로그의 체크포인트 위치

그림 13-5 설명
인스턴스 복구 중에는 데이터베이스가 체크포인트 위치와 리두 스레드의 끝 사이에 발생한 변경 사항을 적용해야 합니다. 그림 13-5에서 보여지듯이, 일부 변경 사항은 이미 데이터 파일에 기록되었을 수 있습니다. 그러나 체크포인트 위치보다 낮은 SCN을 가진 변경 사항만 디스크에 기록된 것이 보장됩니다.

참고:

  • Oracle Database Performance Tuning Guide에서 인스턴스 복구 시간을 제한하는 방법을 알아보십시오.

인스턴스 복구 단계

인스턴스 복구의 첫 번째 단계는 캐시 복구 또는 롤 포워드라고 하며, 온라인 리두 로그에 기록된 모든 변경 사항을 데이터 파일에 다시 적용합니다.

온라인 리두 로그에는 언두 데이터가 포함되어 있기 때문에, 롤 포워드는 해당 언두 세그먼트도 다시 생성합니다. 롤 포워드는 데이터베이스를 최신 상태로 만들기 위해 필요한 만큼 많은 온라인 리두 로그 파일을 거쳐 진행됩니다. 롤 포워드가 완료되면 데이터 블록에는 온라인 리두 로그 파일에 기록된 모든 커밋된 변경 사항이 포함됩니다. 이러한 파일에는 인스턴스 실패 전에 데이터 파일에 저장되었거나 캐시 복구 중에 온라인 리두 로그에 기록된 커밋되지 않은 변경 사항도 포함될 수 있습니다.

롤 포워드 후에는 커밋되지 않은 모든 변경 사항이 롤백되어야 합니다. Oracle Database는 체크포인트 위치를 사용하여, 체크포인트 SCN보다 낮은 SCN을 가진 모든 커밋된 변경 사항이 디스크에 저장되었음을 보장합니다. Oracle Database는 언두 블록을 적용하여 인스턴스 실패 전에 쓰여졌거나 캐시 복구 중에 도입된 데이터 블록의 커밋되지 않은 변경 사항을 롤백합니다. 이 단계를 롤백 또는 트랜잭션 복구라고 합니다.

다음 그림은 데이터베이스 인스턴스 실패에서 복구하기 위해 필요한 두 단계인 롤 포워드와 롤백을 보여줍니다.

그림 13-6 기본 인스턴스 복구 단계: 롤 포워드 및 롤백

그림 13-6 설명
Oracle Database는 필요에 따라 여러 트랜잭션을 동시에 롤백할 수 있습니다. 장애 발생 시 활성 상태였던 모든 트랜잭션은 종료된 것으로 표시됩니다. SMON 프로세스가 종료된 트랜잭션을 롤백할 때까지 기다리는 대신, 새로운 트랜잭션은 필요한 데이터를 얻기 위해 개별 블록을 자체적으로 롤백할 수 있습니다.

참고:

  • "언두 세그먼트"에서 언두 데이터에 대해 자세히 알아보십시오.
  • Oracle Database Performance Tuning Guide에서 인스턴스 복구 메커니즘 및 튜닝에 대한 논의를 참조하십시오.

매개 변수 파일 개요

데이터베이스 인스턴스를 시작하려면 Oracle Database는 권장되는 서버 매개 변수 파일 또는 텍스트 초기화 매개 변수 파일을 읽어야 합니다. 이러한 파일에는 구성 매개 변수 목록이 포함되어 있습니다.

데이터베이스를 수동으로 생성하려면, 매개 변수 파일로 인스턴스를 시작한 후 CREATE DATABASE 문을 실행해야 합니다. 따라서 데이터베이스 자체가 존재하지 않아도 인스턴스와 매개 변수 파일은 존재할 수 있습니다.

초기화 매개 변수

초기화 매개 변수는 인스턴스의 기본 작동에 영향을 미치는 구성 매개 변수입니다. 인스턴스는 시작 시 초기화 매개 변수를 파일에서 읽습니다.

Oracle Database는 다양한 환경에서 최적의 운영을 위해 많은 초기화 매개 변수를 제공합니다. 이 매개 변수 중 일부만 명시적으로 설정해야 하며, 기본값이 보통 적절합니다.

초기화 매개 변수의 기능적 그룹

초기화 매개 변수는 다른 기능적 그룹으로 나눌 수 있습니다.

대부분의 초기화 매개 변수는 다음 그룹 중 하나에 속합니다:

  • 파일 또는 디렉토리와 같은 엔티티의 이름을 지정하는 매개 변수
  • 프로세스, 데이터베이스 리소스 또는 데이터베이스 자체의 한계를 설정하는 매개 변수
  • SGA 크기와 같은 용량에 영향을 미치는 매개 변수(이 매개 변수는 가변 매개 변수라고 합니다)

가변 매개 변수는 데이터베이스 성능을 향상시키기 위해 데이터베이스 관리자에게 특히 관심을 끌 수 있습니다.

기본 및 고급 초기화 매개 변수

초기화 매개 변수는 기본과 고급 두 그룹으로 나뉩니다.

일반적으로 약 30개의 기본 매개 변수만 설정 및 조정하면 적절한 성능을 얻을 수 있습니다. 기본 매개 변수는 데이터베이스 이름, 제어 파일의 위치, 데이터베이스 블록 크기 및 언두 테이블스페이스와 같은 특성을 설정합니다.

드물게 최적의 성능을 위해 고급 매개 변수를 수정해야 할 수도 있습니다. 고급 매개 변수는 전문 DBA가 고유한 요구 사항을 충족하도록 Oracle Database의 동작을 조정할 수 있게 합니다.

Oracle Database는 데이터베이스 소프트웨어와 함께 제공되는 시작 초기화 매개 변수 파일에 값을 제공하거나 Database Configuration Assistant에 의해 생성된 초기화 매개 변수 파일을 제공합니다. 이러한 Oracle 제공 초기화 매개 변수를 편집하고 다른 매개 변수를 추가할 수 있습니다. 초기화 매개 변수 파일에 포함되지 않은 관련 초기화 매개 변수에 대해서는 Oracle Database가 기본값을 제공합니다.

참고:

  • "Tools for Database Installation and Configuration"
  • 초기화 매개 변수를 지정하는 방법을 배우려면 Oracle Database Administrator’s Guide를 참조하십시오.
  • 초기화 매개 변수 유형에 대한 설명은 Oracle Database Reference를 참조하십시오.
  • V$PARAMETER 설명 및 SHOW PARAMETER 구문에 대해서는 Oracle Database Reference 및 SQL*Plus User's Guide and Reference를 참조하십시오.

서버 매개 변수 파일

서버 매개 변수 파일은 초기화 매개 변수의 저장소입니다.

서버 매개 변수 파일의 주요 특징은 다음과 같습니다:

  • Oracle Database만이 서버 매개 변수 파일을 읽고 씁니다.
  • 하나의 서버 매개 변수 파일만 데이터베이스에 존재합니다. 이 파일은 데이터베이스 호스트에 있어야 합니다.
  • 서버 매개 변수 파일은 바이너리 파일이며 텍스트 편집기로 수정할 수 없습니다.
  • 서버 매개 변수 파일에 저장된 초기화 매개 변수는 지속적입니다. 데이터베이스 인스턴스가 실행되는 동안 매개 변수에 대한 모든 변경 사항은 인스턴스 종료 및 시작 시에도 지속됩니다.

서버 매개 변수 파일은 클라이언트 애플리케이션을 위한 여러 텍스트 초기화 매개 변수 파일을 유지할 필요성을 제거합니다. 서버 매개 변수 파일은 CREATE SPFILE 문을 사용하여 텍스트 초기화 매개 변수 파일에서 처음 생성됩니다. Database Configuration Assistant에 의해 직접 생성될 수도 있습니다.

참고:

  • 서버 매개 변수 파일에 대해 더 자세히 알아보려면 Oracle Database Administrator’s Guide를 참조하십시오.
  • CREATE SPFILE에 대해 알아보려면 Oracle Database SQL Language Reference를 참조하십시오.

텍스트 초기화 매개 변수 파일

텍스트 초기화 매개 변수 파일은 초기화 매개 변수 목록이 포함된 텍스트 파일입니다.

이 유형의 매개 변수 파일은 매개 변수 파일의 레거시 구현으로 다음과 같은 주요 특징이 있습니다:

  • 데이터베이스를 시작하거나 종료할 때 텍스트 초기화 매개 변수 파일은 데이터베이스에 연결하는 클라이언트 애플리케이션과 동일한 호스트에 있어야 합니다.
  • 텍스트 초기화 매개 변수 파일은 텍스트 기반이며 바이너리 파일이 아닙니다.
  • Oracle Database는 텍스트 초기화 매개 변수 파일을 읽을 수 있지만 쓸 수 없습니다. 매개 변수 값을 변경하려면 텍스트 편집기로 파일을 수동으로 수정해야 합니다.
  • ALTER SYSTEM으로 초기화 매개 변수 값을 변경하면 현재 인스턴스에만 영향을 미칩니다. 변경 사항을 알리기 위해 텍스트 초기화 매개 변수 파일을 수동으로 업데이트하고 인스턴스를 다시 시작해야 합니다.
  • 텍스트 초기화 매개 변수 파일은 한 줄에 하나씩 key=value 쌍으로 구성되어 있습니다. 예를 들어, 초기화 매개 변수 파일의 일부는 다음과 같습니다:
db_name=sample
control_files=/disk1/oradata/sample_cf.dbf
db_block_size=8192
open_cursors=52
undo_management=auto
shared_pool_size=280M
pga_aggregate_target=29M
.
.
.

텍스트 매개 변수 파일이 생성할 수 있는 관리 문제를 설명하기 위해, clienta와 clientb 컴퓨터를 사용하고 SQL*Plus에서 어느 컴퓨터에서나 데이터베이스를 시작할 수 있어야 한다고 가정해 봅시다. 이 경우, 각각의 컴퓨터에 별도의 텍스트 초기화 매개 변수 파일이 하나씩 존재해야 합니다. 이는 그림 13-7에 나와 있습니다. 서버 매개 변수 파일은 매개 변수 파일의 확산 문제를 해결합니다.

그림 13-7 여러 초기화 매개 변수 파일

그림 13-7 설명

참고:

  • 텍스트 초기화 매개 변수 파일에 대해 더 자세히 알아보려면 Oracle Database Administrator’s Guide를 참조하십시오.
  • CREATE PFILE에 대해 알아보려면 Oracle Database SQL Language Reference를 참조하십시오.

초기화 매개 변수 값 수정

초기화 매개 변수를 조정하여 데이터베이스의 동작을 수정할 수 있습니다. 매개 변수가 정적 또는 동적인지에 따라 수정 방법이 결정됩니다.

다음 표는 차이점을 요약한 것입니다.

표 13-5 정적 및 동적 초기화 매개 변수

특성정적동적
매개 변수 파일(텍스트 또는 서버) 수정 필요아니요
설정이 적용되기 전에 데이터베이스 인스턴스 재시작 필요아니요
Oracle Database Reference 초기화 매개 변수 항목에서 "수정 가능"으로 설명됨아니요
데이터베이스 또는 인스턴스에만 수정 가능아니요

정적 매개 변수에는 DB_BLOCK_SIZE, DB_NAME, COMPATIBLE이 포함됩니다. 동적 매개 변수는 세션 수준 매개 변수와 시스템 수준 매개 변수로 나뉘며, 각각 현재 사용자 세션에만 영향을 미치거나 데이터베이스 및 모든 세션에 영향을 미칩니다. 예를 들어, MEMORY_TARGET은 시스템 수준 매개 변수이고, NLS_DATE_FORMAT은 세션 수준 매개 변수입니다.

매개 변수 변경의 범위는 변경 사항이 적용되는 시점에 따라 다릅니다. 인스턴스가 서버 매개 변수 파일로 시작된 경우, ALTER SYSTEM SET 문을 사용하여 시스템 수준 매개 변수 값을 다음과 같이 변경할 수 있습니다:

  • SCOPE=MEMORY

변경 사항은 데이터베이스 인스턴스에만 적용됩니다. 데이터베이스가 종료되고 다시 시작되면 변경 사항은 지속되지 않습니다.

  • SCOPE=SPFILE

변경 사항은 서버 매개 변수 파일에 적용되지만 현재 인스턴스에는 영향을 미치지 않습니다. 따라서 변경 사항은 인스턴스가 다시 시작될 때까지 적용되지 않습니다.

참고: Oracle Database Reference에서 수정 불가능으로 설명된 매개 변수 값을 변경할 때 SPFILE을 지정해야 합니다.

  • SCOPE=BOTH

Oracle Database는 변경 사항을 메모리와 서버 매개 변수 파일 모두에 기록합니다. 이는 데이터베이스가 서버 매개 변수 파일을 사용할 때의 기본 범위입니다.

데이터베이스는 초기화 매개 변수의 새 값과 이전 값을 알림 로그에 기록합니다. 예방 조치로 데이터베이스는 기본 매개 변수의 변경 사항을 유효한 값이 서버 매개 변수 파일에 기록되지 않도록 검증합니다.

참고:

"지역별 설정"

  • 초기화 매개 변수 설정을 변경하는 방법을 배우려면 Oracle Database Administrator’s Guide를 참조하십시오.
  • 모든 초기화 매개 변수에 대한 설명은 Oracle Database Reference를 참조하십시오.
  • ALTER SYSTEM 구문 및 의미에 대해서는 Oracle Database SQL Language Reference를 참조하십시오.

진단 파일 개요

Oracle Database는 데이터베이스 문제를 방지, 탐지, 진단 및 해결하기 위한 고급 진단 가능 인프라를 포함합니다. 문제에는 코드 버그, 메타데이터 손상 및 고객 데이터 손상과 같은 중요한 오류가 포함됩니다.

고급 결함 진단 인프라의 목표는 다음과 같습니다:

  • 문제를 사전에 탐지
  • 문제가 탐지된 후 손상 및 중단을 제한
  • 문제 진단 및 해결 시간을 단축
  • 추적 파일을 분할하고, 조각당 크기와 유지할 최대 조각 수를 사용자가 정의할 수 있게 하며, 사용자 지정 디스크 공간 한도에 도달하면 추적을 비활성화하여 관리성을 개선
  • Oracle Support와의 고객 상호 작용을 단순화

다중 테넌트 컨테이너 데이터베이스(CDB)와 비CDB는 아키텍처 차이가 있습니다. 특별한 언급이 없는 한 이 섹션은 비CDB의 아키텍처를 가정합니다.

참고:

  • CDB에서 진단 파일을 관리하는 방법을 배우려면 Oracle Database Administrator’s Guide를 참조하십시오.

자동 진단 리포지토리

자동 진단 리포지토리(ADR)는 추적 파일, 경고 로그, DDL 로그 및 건강 모니터 보고서와 같은 데이터베이스 진단 데이터를 저장하는 파일 기반 리포지토리입니다.

ADR의 주요 특징은 다음과 같습니다:

  • 통일된 디렉토리 구조
  • 일관된 진단 데이터 형식
  • 통일된 도구 세트

이러한 특징은 고객과 Oracle Support가 여러 Oracle 인스턴스, 구성 요소 및 제품 간에 진단 데이터를 연관시키고 분석할 수 있게 합니다.

ADR은 데이터베이스 외부에 위치하므로, 물리적 데이터베이스가 사용할 수 없을 때도 Oracle Database가 ADR에 접근하고 관리할 수 있습니다. 데이터베이스가 생성되기 전에 데이터베이스 인스턴스가 ADR을 생성할 수 있습니다.

문제와 사건

ADR은 데이터베이스의 중요한 오류를 사전에 추적합니다.

중요한 오류는 ORA-600과 같은 내부 오류 또는 기타 심각한 오류로 나타납니다. 각 문제에는 문제를 설명하는 텍스트 문자열인 문제 키가 있습니다.

문제가 여러 번 발생하면 ADR은 각 발생에 대해 타임스탬프가 있는 사건을 생성합니다. 사건은 고유한 숫자 사건 ID로 식별됩니다. 사건이 발생하면 ADR은 사건 경고를 Enterprise Manager에 보냅니다. 중요한 오류의 진단 및 해결은 일반적으로 사건 경고에서 시작됩니다.

짧은 시간에 많은 사건이 생성될 수 있으므로 ADR은 특정 임계값에 도달한 후 사건 생성을 제한합니다. 제한된 사건은 경고 로그 항목을 생성하지만 사건 덤프를 생성하지 않습니다. 이렇게 해서 ADR은 시스템이 진단 데이터로 과부하되는 것을 방지하면서 중요한 오류가 계속 진행 중임을 알려줍니다.

참고:

  • 결함 진단 인프라에 대한 자세한 내용은 Oracle Database Administrator’s Guide를 참조하십시오.

ADR 구조

ADR 기본 디렉토리는 ADR의 루트 디렉토리입니다.

ADR 기본 디렉토리에는 여러 ADR 홈이 있을 수 있으며, 각 ADR 홈은 Oracle 제품 또는 구성 요소 인스턴스의 모든 진단 데이터(추적, 덤프, 경고 로그 등)의 루트 디렉토리입니다. 예를 들어, 공유 스토리지 및 Oracle ASM이 있는 Oracle RAC 환경에서는 각 데이터베이스 인스턴스와 각 Oracle ASM 인스턴스가 자체 ADR 홈을 가집니다.

그림 13-8은 데이터베이스 인스턴스의 ADR 디렉토리 계층 구조를 보여줍니다. 다른 Oracle 제품 또는 구성 요소(예: Oracle ASM 또는 Oracle Net Services)의 다른 ADR 홈이 이 계층 구조 내에서 동일한 ADR 기본 디렉토리 아래에 존재할 수 있습니다.

그림 13-8 Oracle 데이터베이스 인스턴스의 ADR 디렉토리 구조

그림 13-8 설명
다음 Linux 예제와 같이 데이터베이스를 생성하기 전에 고유한 SID와 데이터베이스 이름으로 인스턴스를 시작하면, Oracle Database는 기본적으로 호스트 파일 시스템에 디렉토리 구조로 ADR을 생성합니다. SID와 데이터베이스 이름은 ADR 홈의 파일 경로의 일부를 형성합니다.

예제 13-1 ADR 생성

% setenv ORACLE_SID osi
% echo "DB_NAME=dbn" > init.ora
% sqlplus / as sysdba
.
.
. 
Connected to an idle instance.
 
SQL> STARTUP NOMOUNT PFILE="./init.ora"
ORACLE instance started.
 
Total System Global Area  146472960 bytes
Fixed Size                  1317424 bytes
Variable Size              92276176 bytes
Database Buffers           50331648 bytes
Redo Buffers                2547712 bytes
 
SQL> COL NAME FORMAT a21
SQL> COL VALUE FORMAT a60
SQL> SELECT NAME, VALUE FROM V$DIAG_INFO;
 
NAME                  VALUE
--------------------- --------------------------------------------------------
Diag Enabled          TRUE
ADR Base              /d1/3910926111/oracle/log
ADR Home              /d1/3910926111/oracle/log/diag/rdbms/dbn/osi
Diag Trace            /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/trace
Diag Alert            /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/alert
Diag Incident         /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/incident
Diag Cdump            /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/cdump
Health Monitor        /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/hm
Default Trace File    /d1/3910926111/oracle/log ... osi/trace/osi_ora_6825.trc
Active Problem Count  0
Active Incident Count 0

경고 로그

모든 데이터베이스에는 데이터베이스 메시지와 오류의 시간 순서 로그를 포함하는 XML 파일인 경고 로그가 있습니다.

경고 로그 내용에는 다음이 포함됩니다:

  • 모든 내부 오류(ORA-600), 블록 손상 오류(ORA-1578) 및 교착 상태 오류(ORA-60)
  • STARTUP, SHUTDOWN, ARCHIVE LOG, RECOVER와 같은 SQL*Plus 명령과 같은 관리 작업
  • 공유 서버 및 디스패처 프로세스의 기능과 관련된 여러 메시지와 오류
  • 물질화된 뷰의 자동 새로 고침 중 발생하는 오류

Oracle Database는 Enterprise Manager GUI에 정보를 표시하는 대신 경고 로그를 사용합니다. 관리 작업이 성공하면 Oracle Database는 "completed"와 함께 시간 기록을 포함한 메시지를 경고 로그에 기록합니다.

Oracle Database는 데이터베이스 인스턴스를 처음 시작할 때 그림 13-8에 표시된 경고 하위 디렉토리에 경고 로그를 생성합니다. 이 파일은 XML 형식입니다. 추적 하위 디렉토리에는 텍스트 전용 경고 로그가 포함되어 있으며, 그 일부는 다음 예제에 나타나 있습니다:

Fri Nov 02 12:41:58 2014
SMP system found. enable_NUMA_support disabled (FALSE)
Starting ORACLE instance (normal)
CLI notifier numLatches:3 maxDescs:189
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 2
Number of processor cores in the system is 2
Number of processor sockets in the system is 2
Shared memory segment for instance monitoring created
Picked latch-free SCN scheme 3
Using LOG_ARCHIVE_DEST_1 parameter default value as /disk1/oracle/dbs/arch
Autotune of undo retention is turned on.
IMODE=BR
ILAT =10
LICENSE_MAX_USERS = 0
SYS auditing is disabled
NOTE: remote asm mode is local (mode 0x1; from cluster type)
Starting up:
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
With the Partitioning, Advanced Analytics and Real Application Testing options.
.
.
.
Using parameter settings in client-side pfile 
System parameters with nondefault values:
  processes                = 100
  sessions                 = 172

예제 13-1에서와 같이, 경고 로그 위치를 찾으려면 V$DIAG_INFO를 쿼리하십시오.

DDL 로그

DDL 로그는 경고 로그와 동일한 형식 및 기본 동작을 가지지만 DDL 문과 세부 사항만 포함합니다. 데이터베이스는 경고 로그의 혼잡을 줄이기 위해 DDL 정보를 별도의 파일에 기록합니다.

DDL 로그 기록은 선택적으로 보충 정보가 추가된 DDL 텍스트입니다. 각 DDL 문에 대해 하나의 로그 기록이 존재합니다. DDL 로그는 ADR 홈의 log/ddl 하위 디렉토리에 저장됩니다.

추적 파일

추적 파일은 문제를 조사하는 데

사용되는 진단 데이터를 포함한 파일입니다. 또한, 추적 파일은 애플리케이션 또는 인스턴스를 조정하는 데 도움을 줄 수 있습니다.

참고:

  • "Performance and Tuning"

추적 파일 유형

각 서버 및 백그라운드 프로세스는 주기적으로 관련된 추적 파일에 기록할 수 있습니다. 이 파일에는 프로세스 환경, 상태, 활동 및 오류에 대한 정보가 포함됩니다.

SQL 추적 기능은 개별 SQL 문에 대한 성능 정보를 제공하는 추적 파일도 생성합니다. 클라이언트 식별자, 서비스, 모듈, 작업, 세션, 인스턴스 또는 데이터베이스에 대해 다양한 방식으로 추적을 활성화할 수 있습니다. 예를 들어, 적절한 절차를 실행하거나 DBMS_MONITOR 패키지에서 이벤트를 설정할 수 있습니다.

참고:

  • "Session Control Statements"
  • 추적 파일, 덤프 및 코어 파일에 대해 알아보려면 Oracle Database Administrator’s Guide를 참조하십시오.
  • 애플리케이션 추적에 대해 알아보려면 Oracle Database SQL Tuning Guide를 참조하십시오.

추적 파일 위치

ADR은 추적 파일을 trace 하위 디렉토리에 저장합니다. 추적 파일 이름은 플랫폼에 따라 다르며 .trc 확장자를 사용합니다.

일반적으로 데이터베이스 백그라운드 프로세스 추적 파일 이름에는 Oracle SID, 백그라운드 프로세스 이름 및 운영 체제 프로세스 번호가 포함됩니다. RECO 프로세스의 추적 파일 예는 mytest_reco_10355.trc입니다.

서버 프로세스 추적 파일 이름에는 Oracle SID, 문자열 ora 및 운영 체제 프로세스 번호가 포함됩니다. 서버 프로세스 추적 파일 이름의 예는 mytest_ora_10304.trc입니다.

때때로 추적 파일에는 .trm 확장자로 끝나는 해당 추적 메타데이터 파일이 있습니다. 이러한 파일에는 데이터베이스가 검색 및 탐색에 사용하는 구조적 정보인 추적 맵이 포함됩니다.

참고:

  • "그림 13-8"
  • 추적 파일을 찾는 방법에 대해 알아보려면 Oracle Database Administrator’s Guide를 참조하십시오.

추적 파일의 분할

추적 파일 크기가 제한될 때 데이터베이스는 자동으로 최대 다섯 개의 세그먼트로 나눌 수 있습니다. 세그먼트는 활성 추적 파일과 동일한 이름을 가지지만 세그먼트 번호가 추가됩니다. 예를 들어 ora_1234_2.trc와 같이 됩니다.

각 세그먼트는 일반적으로 MAX_DUMP_FILE_SIZE로 설정된 한도의 20%입니다. 모든 세그먼트의 총 크기가 한도를 초과하면 데이터베이스는 가장 오래된 세그먼트(처리 초기 상태에 대한 관련 정보를 포함할 수 있는 첫 번째 세그먼트는 제외)를 삭제한 후 새로운 빈 세그먼트를 생성합니다.

참고:

  • 추적 파일 크기를 제어하는 방법에 대해 알아보려면 Oracle Database Administrator’s Guide를 참조하십시오.

진단 덤프

진단 덤프 파일은 상태 또는 구조에 대한 시점 정보를 자세히 포함하는 특수 유형의 추적 파일입니다.

추적은 연속적인 진단 데이터 출력을 의미하는 반면, 덤프는 일반적으로 이벤트에 대한 응답으로 생성되는 일회성 진단 데이터 출력입니다.

추적 덤프 및 사건

대부분의 덤프는 사건 때문에 발생합니다.

사건이 발생하면 데이터베이스는 사건을 위해 생성된 사건 디렉토리에 하나 이상의 덤프를 기록합니다. 사건 덤프는 파일 이름에 사건 번호도 포함합니다.

사건 생성 중에 애플리케이션이 작업의 일환으로 힙 또는 시스템 상태 덤프를 생성할 수 있습니다. 이러한 경우 데이터베이스는 기본 추적 파일 이름 대신 덤프 이름을 사건 파일 이름에 추가합니다. 예를 들어, 프로세스의 사건으로 인해 데이터베이스는 파일 prod_ora_90348.trc를 생성합니다. 사건의 덤프로 인해 사건 파일 prod_ora_90348_incident_id.trc가 생성됩니다. 여기서 incident_id는 사건의 숫자 ID입니다. 사건의 일환으로 생성된 힙 덤프 작업은 힙 덤프 파일 prod_ora_90348_incident_id_dump_id.trc를 생성합니다. 여기서 dump_id는 추적 덤프의 숫자 ID입니다.

profile
비전공 개발 공부 이야기

0개의 댓글