Oracle AI Database 인스턴스

이 장에서는 Oracle 데이터베이스 인스턴스의 특성, 인스턴스와 연관된 매개변수 및 진단 파일, 인스턴스 생성 및 데이터베이스 열기/닫기 중에 발생하는 결과에 대해 설명합니다.

주: 이 장의 목적에 따라 "데이터베이스"라는 용어는 달리 명시되지 않는 한 다중 테넌트 CDB(컨테이너 데이터베이스)를 나타냅니다.

Oracle AI Database 인스턴스 소개

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

물리적 레벨에서 CDB는 CREATE DATABASE 문으로 생성된 디스크의 파일 집합입니다. CDB에는 하나 이상의 유저 생성 PDB가 포함됩니다. PDB는 CDB에 속하는 전체 데이터 파일 집합 내에 고유한 데이터 파일 집합을 포함합니다. 데이터베이스 인스턴스는 CDB 및 해당 PDB와 연관된 데이터를 관리하고 사용자에게 서비스를 제공합니다.

실행 중인 모든 CDB는 하나 이상의 Oracle 데이터베이스 Instance와 연관되어 있습니다. Instance는 메모리에 있고 데이터베이스는 가장 좁은 의미에서 디스크에 있는 파일 집합이기 때문에 데이터베이스 없이 Instance가 존재할 수 있고 Instance 없이 데이터베이스가 존재할 수 있습니다.

데이터베이스 Instance 구조

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

SGA는 다음과 같은 다양한 용도로 사용됩니다.

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

데이터베이스 Instance에는 백그라운드 프로세스 및 서버 프로세스도 포함됩니다. 각 프로세스에는 Instance의 일부로 간주되는 고유한 전용 메모리가 있습니다. 서버 프로세스가 종료되면 인스턴스가 계속 작동합니다.

다음 그림은 Oracle 데이터베이스 Instance의 기본 구성 요소를 보여줍니다.

그림 1: 데이터베이스 인스턴스

그림 cncpt325.png에 대한 설명

참조:

데이터베이스 Instance 구성

Oracle AI Database는 단일 인스턴스 구성 또는 Oracle RAC(Oracle Real Application Clusters) 구성에서 실행됩니다. 이러한 구성은 상호 배타적입니다.

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

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

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

그림 cncpt296.gif에 대한 설명

단일 Instance 구성이든 Oracle RAC 구성이든 관계 없이 데이터베이스 Instance는 한 번에 하나의 데이터베이스와만 연관됩니다. 데이터베이스 인스턴스와 마운트(인스턴스를 하나의 데이터베이스와 연관)를 시작할 수 있지만 두 데이터베이스를 동일한 인스턴스와 동시에 마운트할 수는 없습니다. 주: 이 장에서는 별도로 언급하지 않는 한 단일 인스턴스 데이터베이스 구성에 대해 설명합니다.

여러 Instance가 동일한 컴퓨터에서 동시에 실행될 수 있으며, 각 Instance는 자체 데이터베이스에 액세스합니다. 예를 들어, 컴퓨터는 prod1 및 prod2의 두 개의 개별 데이터베이스를 호스트할 수 있습니다. 하나의 데이터베이스 인스턴스가 prod1를 관리하고, 별도의 인스턴스가 prod2를 관리합니다.

참조: Oracle RAC에 대한 자세한 내용은 Oracle Real Application Clusters Administration and Deployment Guide를 참조하십시오.

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

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

기본값인 읽기/쓰기 데이터베이스 인스턴스는 DML을 처리하고 클라이언트 응용 프로그램의 직접 연결을 지원할 수 있습니다. 반면, 읽기 전용 데이터베이스 인스턴스는 쿼리를 처리할 수 있지만 수정 DML(UPDATE, DELETE, INSERT 및 MERGE) 또는 직접 클라이언트 연결을 지원하지 않습니다.

주: 이 설명서에서 달리 명시되지 않는 한 데이터베이스 인스턴스에 대한 모든 참조는 인스턴스를 읽기/쓰기하는 것입니다.

이전 릴리스에서는 대기 데이터베이스에 액세스하지 않은 모든 데이터베이스 인스턴스가 읽기/쓰기 상태였습니다. Oracle Database 12c 릴리스 2(12.2)부터는 읽기 전용 및 읽기/쓰기 인스턴스가 단일 데이터베이스 내에 공존할 수 있습니다. 읽기/쓰기 및 읽기 전용 인스턴스는 모두 질의할 수 있고 읽기/쓰기 인스턴스는 수정할 수 있으므로 이 구성은 데이터를 질의하고 수정하는 병렬 SQL 문에 유용합니다.

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

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

참조:

데이터베이스 Instance의 기간

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

이 기간 동안 데이터베이스 Instance는 자신을 하나의 데이터베이스와만 연관시킬 수 있습니다. 또한 Instance는 데이터베이스를 한 번만 마운트하고 한 번만 닫은 다음 한 번만 열 수 있습니다. 데이터베이스가 닫히거나 종료된 후에는 이 데이터베이스를 마운트하고 열 다른 인스턴스를 시작해야 합니다.

다음 표는 이전에 닫은 데이터베이스를 다시 열려고 시도하는 데이터베이스 인스턴스를 보여줍니다.

테이블 1 인스턴스의 기간

명령문 설명 
SQL> STARTUP
 ORACLE instance started.

  Total System Global Area 468729856 bytes
 Fixed Size 1333556 bytes
 Variable Size 440403660 bytes
 Database Buffers 16777216 bytes
 Redo Buffers 10215424 bytes
 Database mounted.
 Database opened.
 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
 이 query는 현재 Instance가 시작된 시간을 보여줍니다. 
SQL> SHUTDOWN IMMEDIATE
 Instance는 데이터베이스를 닫고 종료되어 이 Instance의 수명이 끝납니다. 
SQL> STARTUP
 Oracle instance started.
 . . .
 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
 이 query는 현재 Instance가 시작된 시간을 보여줍니다. 시작 시간이 다르면 이 instance가 데이터베이스를 종료한 instance와 다릅니다.

데이터베이스 Instance 식별

여러 데이터베이스 Instance가 단일 호스트에 상주할 수 있습니다. 따라서 액세스하려는 Instance를 지정할 수 있어야 합니다. Oracle OFA(Optimal Flexible Architecture) 규칙은 잘 구성된 Oracle 설치를 보장하기 위해 생성되는 구성 지침 집합입니다. 이 절의 예에서는 OFA 구조를 가정합니다.

이 단원에서는 다음 항목을 다룹니다.

Oracle 기본 디렉토리

Oracle 기본 디렉토리는 Oracle 제품의 이진을 저장합니다.

Oracle Base 디렉토리는 Oracle AI Database 설치 소유자의 데이터베이스 홈 디렉토리입니다. 호스트에는 Oracle AI Database를 여러 개 설치할 수 있으며 많은 Oracle AI Database 소프트웨어 설치 소유자가 있을 수 있습니다.

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

/u01/app/oracle

앞의 경로에서 /u01/는 마운트 지점이고 /u01/app/는 응용 프로그램 소프트웨어의 하위 트리입니다.

참조: Oracle Base 개요는 Oracle AI Database Installation Guide for Linux를 참조하십시오.

Oracle 홈 디렉토리

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

Oracle AI Database 소프트웨어를 새로 설치할 때마다 새 Oracle 홈 디렉토리를 지정해야 합니다. Oracle Database 21c부터 Oracle 홈은 읽기 전용입니다. Oracle 홈은 이진 파일과 같은 정적 파일을 저장합니다.

기본적으로 Oracle 홈 디렉토리는 Oracle 기본 위치(ORACLE_BASE) 디렉토리 트리 내의 종속 디렉토리입니다. 단일 Oracle 기본 위치 내의 여러 Oracle 홈 디렉토리에 있는 동일한 호스트에 이 릴리스 또는 이전 데이터베이스 소프트웨어 릴리스를 두 번 이상 설치할 수 있습니다. 버전마다 다르며 유저 계정이 서로 다른 여러 데이터베이스가 동시에 공존할 수 있습니다.

다음 예에서는 /u01/app/oracle/의 동일한 Oracle 기본 디렉토리 내에 있는 세 개의 서로 다른 Oracle 홈의 전체 경로 이름을 보여줍니다.

/u01/app/oracle/product/19.3.0/dbhome_1
/u01/app/oracle/product/19.3.0/dbhome_2
/u01/app/oracle/product/20.1.0/dbhome_1

Oracle 기본 위치(/u01/app/oracle/) 뒤의 경로 이름 부분에는 제품 릴리스 번호(예: 19.3.0) 및 Oracle 홈 상대 디렉토리(예: dbhome_1)가 포함됩니다. /u01/app/oracle/product/19.3.0/ 디렉토리에는 두 개의 개별 Oracle 홈(dbhome_1 및 dbhome_2)이 포함됩니다.

ORACLE_BASE/homes/home_name에 있는 Oracle 기본 홈(ORACLE_BASE_HOME) 디렉토리는 Oracle 홈과 관련된 동적 파일을 저장합니다. Oracle 기본 위치의 모든 Oracle 홈에서 공유하는 Oracle 기본 구성 디렉토리(ORACLE_BASE_CONFIG)는 인스턴스별 동적 파일을 저장합니다.

다음 예제에서 첫번째 경로는 Oracle 홈이고 두번째 경로는 이 Oracle 홈에 대한 Oracle 기본 홈입니다.

/u01/app/oracle/product/20.1.0/dbhome_1
/u01/app/oracle/homes/dbhome_1

참조: Oracle 홈에 대한 개요는 Oracle AI Database Installation Guide for Linux

Oracle SID(시스템 식별자)

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

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

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

인스턴스별 파일은 Oracle 기본 위치에 별도로 저장됩니다. 이름에 SID가 포함된 파일은 Oracle 기본 구성 디렉토리(ORACLE_BASE_CONFIG)의 dbs 하위 디렉토리에 있습니다. 이러한 구분으로 인해 기존 Oracle 홈의 소프트웨어를 사용하여 데이터베이스를 생성한 다음 새 Oracle 홈에 있는 소프트웨어를 사용하여 이 데이터베이스에 대한 인스턴스를 시작할 수 있습니다.

참조:

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

데이터베이스 인스턴스는 데이터베이스에 대한 사용자 액세스를 제공합니다. 인스턴스와 데이터베이스는 다양한 상태일 수 있습니다.

Instance 및 데이터베이스 시작 개요

일반적으로 유저가 Instance를 사용할 수 있도록 Instance를 수동으로 시작한 다음 데이터베이스를 마운트하고 엽니다. SQL*Plus STARTUP 명령, Oracle Enterprise Manager(Enterprise Manager) 또는 SRVCTL 유틸리티를 사용하여 이러한 단계를 수행할 수 있습니다.

Oracle Net을 사용하여 데이터베이스 Instance를 시작하려면 다음 조건이 만족되어야 합니다.

리스너는 데이터베이스 Instance를 시작할 수 있는 전용 서버를 생성합니다.

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

그림 3: 인스턴스 및 데이터베이스 시작 시퀀스

그림 cncpt212.gif에 대한 설명

데이터베이스는 종료 상태에서 열린 데이터베이스 상태로 진행될 때 다음 단계를 거칩니다.

인스턴스 시작의 표 2 단계

단계 마운트 상태입니다. 설명 자세히 알아보기
1 데이터베이스를 마운트하지 않고 인스턴스가 시작되었습니다. Instance가 시작되지만 아직 데이터베이스와 연관되어 있지 않습니다. "인스턴스 시작 방법"
2 데이터베이스가 마운트되었습니다 인스턴스가 시작되고 해당 제어 파일을 읽어서 데이터베이스와 연관됩니다. 데이터베이스가 유저에게 닫히는 경우 "데이터베이스를 마운트하는 방법"
3 데이터베이스 열기 Instance가 시작되고 열린 데이터베이스와 연관됩니다. 데이터 파일에 포함된 데이터는 권한이 부여된 유저가 액세스할 수 있습니다. "데이터베이스를 여는 방법"

참조:

관리자 권한으로 연결

데이터베이스 시작 및 종료는 관리자 권한이 있는 Oracle AI Database에 접속하는 사용자에게 제한되는 강력한 관리 옵션입니다.

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

다음 특수 시스템 권한을 사용하면 데이터베이스가 열려 있지 않은 경우에도 데이터베이스 Instance에 액세스할 수 있습니다.

이전 권한의 제어는 데이터베이스 자체의 범위를 벗어납니다. SYSDBA 시스템 권한으로 데이터베이스에 접속하면 SYS이 소유한 스키마에 있게 됩니다. SYSOPER로 연결하면 공용 스키마에 있습니다. SYSOPER 권한은 SYSDBA 권한의 하위 집합입니다.

참조:

인스턴스가 시작되는 방법

Oracle AI Database가 인스턴스를 시작하면 단계별로 진행됩니다.

단계는 다음과 같습니다.

  1. 플랫폼별 기본 위치에서 서버 매개변수 파일을 검색하고, 찾을 수 없는 경우 텍스트 초기화 매개변수 파일을 검색합니다. STARTUP을 SPFILE 또는 PFILE 매개변수로 지정하면 기본 동작이 무효화됩니다.

  2. 파라미터 파일을 읽어서 초기화 파라미터의 값 확인

  3. 초기화 파라미터 설정에 따라 SGA를 할당합니다.

  4. Oracle 백그라운드 프로세스를 시작합니다.

  5. 경보 로그 및 추적 파일을 열고 모든 명시적 매개변수 설정을 경보 로그에 적합한 매개변수 구문으로 씁니다.

이 단계에서는 Instance와 연관된 데이터베이스가 없습니다. NOMOUNT 상태가 필요한 시나리오에는 데이터베이스 생성 및 특정 백업/복구 작업이 포함됩니다.

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

데이터베이스 마운트 방법

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

데이터베이스를 마운트하기 위해 Instance는 CONTROL_FILES 초기화 파라미터에 지정된 데이터베이스 Control File의 이름을 가져와서 파일을 엽니다. Oracle AI Database는 제어 파일을 읽어 데이터베이스 열 때 액세스하려고 시도할 데이터 파일 및 온라인 리두 로그 파일의 이름을 찾습니다.

마운트된 데이터베이스에서 데이터베이스는 닫히고 데이터베이스 관리자만 액세스할 수 있습니다. 관리자는 특정 유지 관리 작업을 완료하는 동안 데이터베이스를 닫은 상태로 유지할 수 있습니다. 그러나 정상적인 작업에는 데이터베이스를 사용할 수 없습니다.

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

참조:

데이터베이스가 열린 방식

마운트된 데이터베이스를 열면 정상적인 데이터베이스 운영에 사용할 수 있습니다.

유효한 유저는 열려 있는 데이터베이스에 연결하여 해당 정보에 액세스할 수 있습니다. 일반적으로 데이터베이스 관리자는 데이터베이스를 열어 일반적인 용도로 사용할 수 있도록 합니다.

데이터베이스를 열면 Oracle AI Database는 다음 작업을 수행합니다.

참조:

읽기 전용 모드

기본적으로 데이터베이스는 읽기/쓰기 모드에서 열립니다. 이 모드에서는 유저가 데이터를 변경하여 온라인 리두 로그에 리두를 생성할 수 있습니다. 또는 읽기 전용 모드로 열어 사용자 트랜잭션에 의한 데이터 수정을 방지할 수 있습니다. 주: 기본적으로 물리적 대기 데이터베이스는 읽기 전용 모드로 열립니다.

읽기 전용 모드는 데이터베이스 액세스를 데이터 파일이나 온라인 리두 로그 파일에 쓸 수 없는 읽기 전용 트랜잭션으로 제한합니다. 그러나 데이터베이스는 리두를 생성하지 않고 데이터베이스 상태를 변경하는 recovery 또는 작업을 수행할 수 있습니다. 예를 들어, 읽기 전용 모드에서는 다음과 같습니다.

참조:

데이터베이스 파일 검사

Instance가 데이터베이스를 열려고 할 때 데이터 파일이나 리두 로그 파일이 없거나 파일이 있지만 일관성 테스트에 실패하는 경우 데이터베이스는 오류를 반환합니다. Media Recovery가 필요할 수 있습니다.

참조: 백업 및 복구 개요는 Oracle AI Database Backup and Recovery User's Guide를 참조하십시오.

데이터베이스 및 Instance 종료 개요

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

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

그림 4: 인스턴스 및 데이터베이스 종료 시퀀스

그림 cncpt281.gif에 대한 설명

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

테이블 3 정합성 보장 종료 단계

단계 마운트 상태입니다. 설명 자세히 알아보기
1 Database closed 데이터베이스가 마운트되었지만 온라인 데이터 파일과 리두 로그 파일이 닫힙니다. "데이터베이스를 닫는 방법"
2 데이터베이스 마운트 해제됨 Instance가 시작되지만 더 이상 데이터베이스의 콘트롤 파일과 연관되지 않습니다. "데이터베이스 마운트 해제 방법"
3 데이터베이스 Instance 종료 데이터베이스 Instance가 더 이상 시작되지 않습니다. "인스턴스 종료 방법"

Oracle AI Database는 인스턴스 실패 시 앞의 모든 단계 또는 인스턴스를 즉시 종료하는 SHUTDOWN ABORT를 거치지 않습니다.

종료 모델

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

다음 표에는 여러 종료 모드의 동작이 요약되어 있습니다.

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

데이터베이스 동작 중단 IMMEDIATE 트랜잭션 일반
새 사용자 연결을 허용합니다. 아니요 아니요 아니요 아니요
현재 세션 종료 시까지 대기 아니요 아니요 아니요 예.
현재 트랜잭션 종료 시까지 대기 아니요 아니요 예. 예.
체크포인트를 수행하고 열린 파일을 닫습니다. 아니요 예. 예. 예.

가능한 SHUTDOWN 문은 다음과 같습니다.

참조:

데이터베이스 종료 방법

데이터베이스 종료 작업은 데이터베이스 종료에서 암시적입니다. 작업의 특성은 데이터베이스 종료가 정상인지 비정상인지에 따라 다릅니다.

정상적인 종료 중 데이터베이스가 닫히는 방법

데이터베이스가 ABORT 이외의 옵션을 사용하여 SHUTDOWN의 일부로 닫히면 Oracle AI Database는 SGA의 데이터를 데이터 파일 및 온라인 리두 로그 파일에 기록합니다.

그런 다음 데이터베이스는 온라인 데이터 파일과 온라인 리두 로그 파일을 닫습니다. 오프라인 테이블스페이스의 모든 오프라인 데이터 파일은 이미 닫혔습니다. 데이터베이스가 다시 열리면 오프라인 상태였던 테이블스페이스는 오프라인 상태로 유지됩니다.

이 단계에서 데이터베이스는 닫히고 정상적인 작업을 위해 액세스할 수 없습니다. 데이터베이스를 닫은 후에도 제어 파일이 열린 상태로 유지됩니다.

비정상적인 종료 중 데이터베이스 종료 방법

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

비정상 종료 시 Oracle AI Database는 SGA 버퍼의 데이터를 데이터 파일과 리두 로그 파일에 쓰지 않습니다. 이어서 데이터베이스를 다시 열려면 인스턴스 복구가 필요하며 Oracle AI Database가 자동으로 수행합니다.

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

데이터베이스가 닫히면 Oracle AI Database는 데이터베이스를 마운트 해제하여 인스턴스에서 연관 해제합니다.

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

인스턴스가 종료되는 방법

데이터베이스 종료의 마지막 단계는 인스턴스를 종료하는 것입니다. 데이터베이스 Instance가 종료되면 SGA가 메모리 점유를 중단하고 백그라운드 프로세스가 종료됩니다.

비정상적인 상황에서는 데이터베이스 Instance의 종료가 정상적으로 발생하지 않을 수 있습니다. 메모리 구조를 메모리에서 제거할 수 없거나 백그라운드 프로세스 중 하나가 종료되지 않을 수 있습니다. 이전 Instance의 나머지 부분이 있는 경우 후속 Instance 시작이 실패할 수 있습니다. 이러한 경우 이전 인스턴스의 나머지 부분을 제거한 다음 새 인스턴스를 시작하거나 SHUTDOWN ABORT 문을 실행하여 새 인스턴스를 강제로 시작할 수 있습니다.

경우에 따라 프로세스 정리 자체에 오류가 발생할 수 있으므로 프로세스 모니터(PMON) 또는 Instance가 종료될 수 있습니다. 동적 초기화 매개변수 INSTANCE_ABORT_DELAY_TIME는 내부적으로 생성된 인스턴스 실패를 지연시킬 시간(초)을 지정합니다. 이 지연은 당신에게 응답 할 수있는 기회를 제공합니다. 데이터베이스는 지연된 종료가 시작될 때 경보 로그에 메시지를 기록합니다. 경우에 따라 특정 데이터베이스 리소스가 격리되도록 허용하면 Instance가 종료되지 않을 수 있습니다.

참조:

체크포인트 개요

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

이 용어는 다음과 같은 관련 의미를 갖습니다.

체크포인트의 목적

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

목표는 다음과 같습니다.

Oracle AI Database가 체크포인트를 시작할 때

체크포인트 프로세스(CKPT)는 데이터 파일 헤더 및 제어 파일에 체크포인트를 기록합니다.

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

다른 유형의 체크포인트에는 스키마 객체가 삭제되거나 잘릴 때의 Instance 및 Media Recovery 체크포인트와 체크포인트가 포함됩니다.

참조:

Instance Recovery 개요

인스턴스 복구는 온라인 리두 로그의 레코드를 데이터 파일에 적용하여 가장 최근의 체크포인트 이후에 변경된 사항을 재구성하는 프로세스입니다.

Instance Recovery는 관리자가 이전에 종료된 데이터베이스를 비일관적으로 열려고 할 때 자동으로 수행됩니다.

Instance Recovery의 목적

Instance Recovery는 Instance Failure 이후의 데이터베이스가 일관성 있는 상태인지 확인합니다. Oracle AI Database가 데이터베이스 변경 사항을 관리하는 방식 때문에 데이터베이스의 파일을 일관성 없는 상태로 유지할 수 있습니다.

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

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

SHUTDOWN ABORT 문 또는 비정상적인 종료로 인해 열린 데이터베이스 인스턴스가 실패하면 다음 상황이 발생할 수 있습니다.

Instance Recovery는 온라인 리두 로그 파일과 현재 온라인 데이터 파일만 사용하여 데이터 파일을 동기화하고 이러한 파일의 일관성을 유지합니다.

참조:

Oracle AI Database가 인스턴스 복구를 수행할 때

Instance Recovery가 필요한지 여부는 리두 스레드의 상태에 따라 다릅니다.

리두 스레드는 데이터베이스 Instance가 읽기/쓰기 모드로 열릴 때 Control File에서 열린 것으로 표시되며 Instance가 일관되게 종료될 때 닫힌 것으로 표시됩니다. 리두 스레드가 콘트롤 파일에서 open으로 표시되지만 이러한 스레드에 해당하는 스레드 enqueue를 보유하는 라이브 인스턴스가 없는 경우 데이터베이스는 Instance Recovery를 필요로 합니다.

Oracle AI Database는 다음과 같은 상황에서 자동으로 인스턴스 복구를 수행합니다.

SMON 백그라운드 프로세스는 온라인 리두를 자동으로 적용하여 Instance Recovery를 수행합니다. 사용자 개입이 필요하지 않습니다.

참조:

Instance Recovery의 중요성

Instance Recovery는 체크포인트를 사용하여 데이터 파일에 적용해야 하는 변경 사항을 결정합니다. 체크포인트 위치는 체크포인트 SCN이 낮은 SCN으로 커밋된 모든 변경 사항이 데이터 파일에 저장되도록 보장합니다.

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

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

그림 cncpt282.gif에 대한 설명

Instance Recovery 동안 데이터베이스는 체크포인트 위치와 리두 스레드 끝 사이에 발생하는 변경 사항을 적용해야 합니다. 그림 16-5에 표시된 것처럼 일부 변경 사항이 이미 데이터 파일에 기록되었을 수 있습니다. 하지만 체크포인트 위치보다 낮은 SCN의 변경 사항만 디스크에 보장됩니다.

참조: 인스턴스 복구 시간을 제한하는 방법은 Oracle AI Database Performance Tuning Guide를 참조하십시오.

인스턴스 복구 단계

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

온라인 리두 로그에 언두 데이터가 포함되어 있으므로 롤포워드해도 해당하는 언두 세그먼트가 재생성됩니다. 롤포워드는 데이터베이스를 롤포워드하는 데 필요한 만큼의 온라인 리두 로그 파일을 진행합니다. 롤포워드 후 데이터 블록은 온라인 리두 로그 파일에 기록된 모든 커밋된 변경 사항을 포함합니다. 또한 이러한 파일에는 Failure 전에 데이터 파일에 저장되었거나 온라인 리두 로그에 기록되어 캐시 Recovery 중에 도입된 커밋되지 않은 변경 사항이 포함될 수 있습니다.

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

다음 그림은 데이터베이스 Instance Failure로부터 Recovery하는 데 필요한 두 단계인 롤포워드 및 롤백을 보여줍니다.

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

그림 cncpt196.gif에 대한 설명

Oracle AI Database는 필요에 따라 여러 트랜잭션을 동시에 롤백할 수 있습니다. 실패 시점에 활성 상태였던 모든 트랜잭션은 종료됨으로 표시됩니다. SMON 프로세스가 종료된 트랜잭션을 롤백할 때까지 기다리지 않고 새 트랜잭션이 개별 블록을 롤백하여 필요한 데이터를 얻을 수 있습니다.

참조:

파라미터 파일 개요

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

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

초기화 매개변수

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

Oracle AI Database는 다양한 환경에서의 운영 최적화를 위한 다양한 초기화 매개변수를 제공합니다. 일반적으로 기본값이 적합하기 때문에 이러한 파라미터 중 일부만 명시적으로 설정해야 합니다.

초기화 파라미터의 기능 그룹

초기화 파라미터는 서로 다른 기능 그룹에 속합니다.

대부분의 초기화 파라미터는 다음 그룹 중 하나에 속합니다.

변수 파라미터는 데이터베이스 관리자에게 특히 중요합니다. 이러한 파라미터를 사용하여 데이터베이스 성능을 향상시킬 수 있기 때문입니다.

기본 및 고급 초기화 파라미터

초기화 파라미터는 기본 및 고급의 두 그룹으로 나뉩니다.

일반적으로 적절한 성능을 얻으려면 대략 30개의 기본 파라미터만 설정하고 튜닝해야 합니다. 기본 파라미터는 데이터베이스 이름, 콘트롤 파일 위치, 데이터베이스 블록 크기 및 언두 테이블스페이스와 같은 특성을 설정합니다.

하지만 고급 파라미터를 수정하여 성능을 최적화해야 하는 경우도 있습니다. 고급 매개변수를 통해 전문가 DBA는 고유한 요구 사항을 충족하기 위해 Oracle AI Database의 동작을 조정할 수 있습니다.

Oracle AI Database는 데이터베이스 소프트웨어와 함께 제공되거나 DBCA(Database Configuration Assistant)에서 자동으로 생성되는 시작 초기화 매개변수 파일에 값을 제공합니다. 구성 및 데이터베이스 튜닝 방법에 따라 이러한 Oracle 제공 초기화 파라미터를 편집하고 다른 파라미터를 추가할 수 있습니다. 매개변수 파일에 포함되지 않은 관련 초기화 매개변수의 경우 Oracle AI Database가 기본값을 제공합니다.

참조:

서버 파라미터 파일

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

서버 파라미터 파일의 주요 특성은 다음과 같습니다.

서버 파라미터 파일을 사용하면 클라이언트 응용 프로그램에 대해 여러 텍스트 초기화 파라미터 파일을 유지 관리할 필요가 없습니다. 서버 파라미터 파일은 처음에 CREATE SPFILE 문을 사용하여 텍스트 초기화 파라미터 파일에서 작성됩니다. Database Configuration Assistant를 통해 직접 생성할 수도 있습니다.

참조:

텍스트 초기화 Parameter file

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

매개변수 파일의 레거시 구현인 이 유형의 매개변수 파일은 다음과 같은 주요 특성을 가집니다.

텍스트 초기화 매개변수 파일은 한 행에 하나씩 일련의 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로 데이터베이스를 시작할 수 있어야 한다고 가정합니다. 이 경우 그림 16-7과 같이 각 컴퓨터에 하나씩 두 개의 별도 텍스트 초기화 매개변수 파일이 있어야 합니다. 서버 파라미터 파일은 파라미터 파일의 급증 문제를 해결합니다.

그림 7: 다중 초기화 매개변수 파일

그림 cncpt247.gif에 대한 설명

참조:

초기화 파라미터 값 수정

초기화 파라미터를 조정하여 데이터베이스의 동작을 수정할 수 있습니다. 매개변수를 static 또는 dynamic으로 분류하면 매개변수 수정 방법이 결정됩니다.

다음 표에는 차이점이 요약되어 있으며,

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

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

정적 매개변수에는 DB_BLOCK_SIZE, DB_NAME 및 COMPATIBLE가 포함됩니다. 동적 매개변수는 현재 사용자 세션에만 영향을 주는 세션 레벨 매개변수와 데이터베이스 및 모든 세션에 영향을 주는 시스템 레벨 매개변수로 그룹화됩니다. 예를 들어, MEMORY_TARGET는 시스템 레벨 매개변수이고 NLS_DATE_FORMAT는 세션 레벨 매개변수입니다.

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

데이터베이스는 새 값과 초기화 파라미터의 이전 값을 Alert Log에 출력합니다. 데이터베이스는 기본 파라미터의 변경 사항을 검증하여 부적합한 값이 서버 파라미터 파일에 기록되지 않도록 합니다.

참조:

진단 파일 개요

Oracle AI Database에는 데이터베이스 문제를 방지, 감지, 진단 및 해결하기 위한 결함 진단 가능성 인프라가 포함되어 있습니다. 문제에는 코드 버그, 메타 데이터 손상, 고객 데이터 손상과 같은 critical 오류가 포함됩니다.

고급 결함 진단 기능 Infrastructure의 목표는 다음과 같습니다.

자동 진단 저장소

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

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

앞의 특성을 통해 고객과 Oracle Support는 여러 Oracle Instance, 구성 요소 및 제품 전반의 진단 데이터를 상호 연관시키고 분석할 수 있습니다.

ADR은 데이터베이스 외부에 위치하며, 이를 통해 Oracle AI Database는 물리적 데이터베이스를 사용할 수 없을 때 ADR에 액세스하고 관리할 수 있습니다. 데이터베이스 Instance는 데이터베이스를 생성하기 전에 ADR을 생성할 수 있습니다.

문제 및 장애

ADR은 데이터베이스에서 심각한 오류인 문제를 사전에 추적합니다.

위기 오류는 내부 오류(예: ORA-600) 또는 기타 심각한 오류로 나타납니다. 각 문제에는 문제를 설명하는 텍스트 문자열인 문제 키가 있습니다.

문제가 여러 번 발생하면 ADR은 각 발생마다 시간 기록된 장애를 만듭니다. 장애는 숫자 장애 ID로 고유하게 식별됩니다. 장애가 발생하면 ADR은 장애 경보를 Enterprise Manager로 전송합니다. 위기 오류의 진단 및 해결은 일반적으로 장애 경보에서 시작됩니다.

문제가 단기간에 많은 Incident를 생성할 수 있으므로 ADR은 특정 임계값에 도달한 후 Incident 생성에 Flood Control을 적용합니다. 홍수 제어 장애는 경보 로그 항목을 생성하지만 장애 덤프는 생성하지 않습니다. 이러한 방식으로 ADR은 진단 데이터가 있는 시스템을 오버로드하지 않고 심각한 오류가 발생하고 있음을 알려줍니다.

참조: 결함 진단 기능 기반구조에 대한 자세한 내용은 Oracle AI Database Administrator's Guide를 참조하십시오.

ADR 구조

ADR 기준은 ADR 루트 디렉토리입니다.

ADR 기반은 여러 ADR 홈을 포함할 수 있습니다. 여기서 각 ADR 홈은 Oracle 제품 또는 구성 요소의 인스턴스에 대한 모든 진단 데이터 추적, 덤프, 경고 로그 등의 루트 디렉토리입니다. 예를 들어, 공유 저장 영역 및 Oracle ASM이 있는 Oracle RAC 환경에서는 각 데이터베이스 Instance 및 각 Oracle ASM Instance에 고유한 ADR 홈이 있습니다. 그림 16-8에서는 데이터베이스 인스턴스에 대한 ADR 디렉토리 계층을 보여줍니다. 다른 Oracle 제품 또는 구성 요소(예: Oracle ASM 또는 Oracle Net Services)에 대한 기타 ADR 홈은 이 계층 내에서 동일한 ADR 기반 아래에 존재할 수 있습니다.

그림 8: Oracle AI Database 인스턴스의 ADR 디렉토리 구조

그림 admin077.gif에 대한 설명

다음 Linux 예에서는 데이터베이스를 만들기 전에 고유한 SID 및 데이터베이스 이름으로 인스턴스를 시작할 때 Oracle AI Database는 기본적으로 ADR을 호스트 파일 시스템에 디렉토리 구조로 만듭니다. SID 및 데이터베이스 이름은 ADR 홈에 있는 파일에 대한 경로 이름의 일부를 구성합니다.

예제 16-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/diag/rdbms/dbn/osi/trace/osi_ora_29229.trc
Active Problem Count  0
Active Incident Count 0
ORACLE_HOME           /d1/3910926111/oracle
Attention Log         /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/trace/attention_osi.log
13 rows selected.

경보 로그

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

Alert Log 내용에는 다음이 포함됩니다.

관리 작업을 성공적으로 수행하면 Oracle AI Database는 시간 기록 및 함께 Alert Log에 "completed"라는 메시지를 기록합니다.

Oracle AI Database는 데이터베이스가 아직 생성되지 않은 경우에도 데이터베이스 인스턴스를 처음 시작할 때 그림 16-8에 표시된 alert 하위 디렉토리에 경보 로그를 생성합니다. 이 파일은 XML 형식입니다. trace 하위 디렉토리는 텍스트 전용 경보 로그를 포함합니다.

V$DIAG_INFO을 질의하여 경보 로그를 찾습니다.

주의 로그

모든 데이터베이스에는 중요하고 가시성이 높은 데이터베이스 이벤트가 포함된 주의 로그가 있습니다.

주의 로그에는 중요하고 눈에 띄는 데이터베이스 이벤트만 포함되어 있으므로 alert를 식별하고 적절한 조치를 취할 수 있습니다. 각 주의 로그 메시지에는 대상 오디언스, 원인 및 수행할 작업을 비롯한 다양한 속성이 있습니다. 주의 로그는 다음 형식으로 정보를 제공합니다.

Oracle AI Database는 그림 16-8에 표시된 trace 하위 디렉토리에 attention_ORACLE_SID.log이라는 주의 로그를 만듭니다. V$DIAG_INFO를 질의하여 주의 로그를 찾을 수도 있습니다.

DDL 로그

DDL 로그는 경보 로그와 형식 및 기본 동작이 동일하지만 DDL 문 및 세부정보만 포함합니다. 데이터베이스는 Alert Log의 복잡성을 줄이기 위해 DDL 정보를 자체 파일에 기록합니다.

DDL 로그 레코드는 DDL 텍스트로, 선택적으로 보완 정보로 증강됩니다. 각 DDL 문에 대해 하나의 로그 레코드가 존재합니다. DDL 로그는 ADR 홈의 log/ddl 하위 디렉토리에 저장됩니다.

추적 파일

추적 파일은 문제를 조사하는 데 사용되는 진단 데이터가 포함된 파일입니다. 또한 Trace File을 통해 응용 프로그램 또는 Instance 튜닝을 위한 지침을 확인할 수 있습니다.

Trace File 유형

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

또한 SQL Trace 기능은 개별 SQL 문에 대한 성능 정보를 제공하는 Trace File을 생성합니다. 다양한 방법으로 클라이언트 식별자, 서비스, 모듈, 작업, 세션, instance 또는 데이터베이스에 대해 Trace를 활성화할 수 있습니다. 예를 들어, DBMS_MONITOR 패키지의 해당 프로시저를 실행하거나 이벤트를 설정할 수 있습니다.

참조:

Trace File 위치

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

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

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

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

참조:

Trace File 세분화

Trace file 크기가 제한되면 데이터베이스가 이를 최대 5개의 세그먼트로 자동으로 분할할 수 있습니다. 세그먼트는 활성 추적 파일과 이름이 같지만 세그먼트 번호가 추가된 별도의 파일입니다(ora_1234_2.trc 참조).

각 세그먼트는 일반적으로 MAX_DUMP_FILE_SIZE에 의해 설정된 제한의 20%입니다. 모든 세그먼트의 결합된 크기가 제한을 초과하는 경우 데이터베이스는 프로세스 초기 상태에 대한 관련 정보를 포함할 수 있는 첫번째 세그먼트는 아니지만 가장 오래된 세그먼트를 삭제한 다음 새 빈 세그먼트를 생성합니다.

참조: Oracle AI Database Administrator's Guide에서 추적 파일 크기를 제어하는 방법 알아보기

진단 덤프

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

추적은 진단 데이터의 연속 출력인 경향이 있습니다. 반대로 덤프는 일반적으로 이벤트에 대한 응답으로 진단 데이터의 일회성 출력입니다.

덤프 및 장애 추적

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

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

장애를 생성하는 동안 응용 프로그램은 작업의 일부로 힙 또는 시스템 상태 덤프를 취할 수 있습니다. 이 경우 데이터베이스는 기본 Trace File 이름 대신 Incident 파일 이름에 덤프 이름을 추가합니다. 예를 들어, 프로세스의 장애로 인해 데이터베이스가 prod_ora_90348.trc 파일을 생성합니다. 장애의 덤프는 prod_ora_90348_incident_id.trc 파일을 생성합니다. 여기서 incident_id은 장애의 숫자 ID입니다. 장애의 일부로 생성된 힙 덤프 작업은 힙 덤프 파일 prod_ora_90348_incident_id_dump_id.trc를 생성합니다. 여기서 dump_id은 추적 덤프의 숫자 ID입니다.