경고 로그 파일

alert.log 파일은 Oracle 서버가 기록하는 파일로 인스턴스 및 데이터베이스의 상태 정보를 포함합니다. 분명하지 않은 시스템 문제가 발생할 경우 DBA는 먼저 이 파일에서 문제에 대한 정보를 찾아야 합니다. 데이터베이스 인스턴스에 광범위하게 또는 전역적으로 영향을 주는 다음과 같은 사항이 alert.log에 기록됩니다.

해당 파일에 내용이 계속 추가되므로 DBA는 디스크가 가득 차기 전에 기록 정보용 대체 기억 장치에 이 파일을 복사한 후 지워 주어야 합니다.

예제

다음 출력은 온라인 리두 로그 파일이 없기 때문에 alert.log 파일에 오류가 기록된 예를 보여줍니다.

...

Tue Nov 25 19:30:25 1997

Errors in file /users/dba00/trace/dba00_lgwr_14838.trc:

ORA-00321: log 2 of thread 1, cannot update log file header

ORA-00312: online log 2 thread 1: '/users/dba00/u02/log2b.rdo'

Tue Nov 25 19:30:25 1997

Errors in file /users/dba00/trace/dba00_lgwr_14838.trc:

ORA-00313: open failed for members of log group 2 of thread 1

Thread 1 advanced to log sequence 1312

  Current log# 2 seq# 1312 mem# 0: /users/dba00/u02/log2a.rdo

...

그룹에 두 멤버가 존재했기 때문에 LGWR가 프로세스를 계속할 수 있었다는 것은 alert.log 파일의 출력 내용을 정기적으로 모니터하여 문제가 있는지 여부를 확인하는 것이 얼마나 중요한지 보여줍니다.

DBA는 문제 진단에 도움이 될 수 있도록 alert.log 파일 이외에도 추적 파일을 사용할 수 있습니다. 위의 예제에서 LGWR 프로세스는 추적 파일도 생성했습니다.

Oracle 추적 파일

Oracle 백그라운드 프로세스 중 하나가 오류를 발견하면 일반적으로 오류에 대한 정보를 포함하는 추적 파일을 생성합니다. PMON, SMON, LGWR, DBWn 등의 추적 파일을 생성한 백그라운드 프로세스의 이름이 추적 파일 이름의 일부로 포함됩니다.

추적 파일은 BACKGROUND_DUMP_DEST 매개변수가 지정하는 대상에 기록됩니다. DBA는 데이터베이스의 문제를 확인하는 데 도움이 되도록 정기적으로 추적 파일을 모니터해야 하고 주기적으로 지우는 작업도 해야 합니다.

예제

다음은 온라인 리두 로그 파일이 없기 때문에 생성된 dba00_lgwr_14838.trc 파일의 출력입니다.

...

ORA-00313: open failed for members of log group 2 of thread 1

ORA-00312: online log 2 thread 1: '/users/dba00/u02/log2b.rdo'

ORA-27037: unable to obtain file status

SVR4 Error: 2: No such file or directory

Additional information: 3

ORA-00321: log 2 of thread 1, cannot update log file header

ORA-00312: online log 2 thread 1: '/users/dba00/u02/log2b.rdo'

ORA-00313: open failed for members of log group 2 of thread 1

...

참고: 추적 파일 번호 14838은 이전 alert.log 출력에도 나열되었습니다.

훼손 블록 감지 및 복구 기능

블록 훼손을 감지하고 복구하기 위한 몇 가지 기능은 다음과 같습니다.

블록 훼손을 복구할 때는 객체 사이의 종속성을 이해할 필요가 있으며 매우 신중하게 시도해야 합니다. 그렇지 않으면 데이터 무결성이 손상될 수 있습니다. 이러한 작업은 일반적으로 Oracle 지원 센터의 도움을 받아 수행해야 합니다.

DB_BLOCK_CHECKSUM 매개변수

DBWn 및 직접 로더는 체크섬을 디스크에 기록할 때 체크섬을 계산하여 모든 데이터 블록의 캐시 헤더에 저장합니다. 체크섬은 블록이 읽혀질 때 검증됩니다.

또한 현재 로그에 체크섬이 기록되기 전에 모든 로그 블록에 체크섬이 주어집니다.

DB_BLOCK_CHECKING 매개변수

DB_BLOCK_CHECKING 매개변수를 TRUE로 설정하면 데이터 및 인덱스 블록이 변경될 때마다 이들을 검사할 수 있습니다.

DBVERIFY 유틸리티

이 명령행 유틸리티는 데이터 파일 블록에 대한 무결성 검사를 수행합니다. 이 유틸리티의 장점은 온라인 성능에 최소한의 영향을 주면서 온라인 및 백업 데이터 파일 모두를 검증하는 데 사용할 수 있다는 것입니다.

이 유틸리티에 대한 자세한 내용은 Oracle8i Utilities 설명서를 참조하십시오.

DBMS_REPAIR 패키지

DBMS_REPAIR 패키지는 블록 훼손을 감지하고 표시할 수 있는 새로운 PL/SQL 인터페이스를 제공합니다. 이 패키지를 생성하려면 SYS 사용자로 dbmsrpr.sql 및 prvtrpr.plb 스크립트를 실행하면 됩니다.

ANALYZE TABLE ... VALIDATE STRUCTURE

ANALYZE TABLE...VALIDATE STRUCTURE 문은 분석된 객체의 구조를 검증합니다.

체크섬 작업

참고: DB_BLOCK_CHECKSUM을 TRUE로 설정하면 성능이 저하됩니다. 데이터 훼손 문제를 진단하기 위해 이 값을 TRUE로 설정하려는 경우 반드시 Oracle 지원 센터 담당자의 조언에 따르십시오.

DB_BLOCK_CHECKING

이 매개변수는 동적으로 변경될 수 있으며 읽는 중에 블록을 검사하지 않으므로 성능에 최소한의 영향을 줍니다. 이 매개변수가 설정되면 훼손된 블록이 발견될 경우 Oracle 서버는 다음 오류를 생성하고 경고 파일에 기록합니다.

ORA-1578 ORACLE data block corrupted

이 새로운 매개변수의 주요 장점은 가능한 모든 블록 훼손을 즉시 감지하여 그 영향이 확산되지 않도록 한다는 것입니다. 이 매개변수는 기존의 10210 및 10211 이벤트를 대체합니다.

DBVERIFY 유틸리티

DBVERIFY 유틸리티를 사용하면 관리자가 지정된 데이터 파일 내에서 데이터 블록의 구조적인 무결성을 검사하여 데이터 파일을 검증할 수 있습니다. 이 유틸리티는 데이터베이스에 포함되지 않으므로 데이터베이스 작업에 최소한의 영향을 줍니다.

DBVERIFY의 주요 기능

단계

설명

1

이 유틸리티는 온라인 데이터 파일을 검증하는 데 사용할 수 있습니다.

2

데이터 파일의 한 부분에 대해 이 유틸리티를 호출할 수 있습니다.

3

이 유틸리티는 오프라인 데이터 파일을 검증하는 데 사용할 수 있습니다.

4

이 유틸리티의 출력을 오류 로그에 보낼 수 있습니다.

DBVERIFY 실행

DBVERIFY 유틸리티의 실행 파일 이름은 운영 체제에 따라 다르며 해당 Oracle Home의 bin 디렉토리에 위치합니다.

실행 파일의 이름은 운영 체제에 따라 다르며 UNIX의 경우 dbv 실행 파일을 실행해야 합니다.

명령행 인터페이스

명령행 인터페이스를 사용하여 호출되는 DBVERIFY 유틸리티를 호출합니다. 이 유틸리티는 백업 데이터베이스 또는 데이터 파일을 복원하기 전에 이들 파일이 유효한지 확인할 필요가 있을 경우 또는 데이터 훼손 문제가 발생했을 때 진단 도구로서 주로 사용해야 합니다.

예제

블록 1에서 시작하여 블록 500에서 끝나는 data01.dbf 데이터 파일의 무결성을 검증하려면 다음 명령을 실행합니다.

UNIX

$ dbv /users/DB00/u03/data01.dbf start=1 end=500

DBVERIFY 출력

이전 명령의 출력 예는 다음과 같습니다.

DBVERIFY - Verification starting : FILE = /users/DBA00/u03/data01.dbf

DBVERIFY - Verification complete

Total Pages Examined :  500

Total Pages Processed (Data):   22

Total Pages Failing   (Data):   0

Total Pages Processed(Index):   16

Total Pages Failing(Index):     0

Total Pages Empty :      0

Total Pages Marked Corrupt:      0

Total Pages Influx:     0

설명: Pages는 처리된 Oracle 블록 수입니다.

DBVERIFY 매개변수

매개변수

설명

FILE

검증할 데이터베이스 파일 이름

START

검증할 시작 블록 주소. 블록 주소는 Oracle 블록에 지정되어 있습니다. START를 지정하지 않으면 파일의 첫 블록부터 검증합니다.

END

검증할 끝 블록 주소. END를 지정하지 않으면 파일의 마지막 블록까지 검증합니다.

BLOCKSIZE

파일의 블록 크기가 2KB 이상인 경우에만 필요

LOGFILE

로그 정보가 기록될 파일 지정. 기본값은 단말기 화면에 출력을 보내는 것입니다.

FEEDBACK

DB_VERIFY가 검증된 n개 페이지에 대해 `마침표(.)' 한 개를 표시하도록 합니다.

HELP

온-스크린 도움말 제공

PARFILE

사용할 매개변수 파일 이름 지정

DBMS_REPAIR를 사용한 훼손 검사

DBMS_REPAIR 패키지는 SYS 사용자가 사용하며 테이블, 분할 영역 또는 인덱스의 블록 훼손을 식별할 수 있습니다. 이 기능을 사용하면 DBMS_REPAIR 패키지는 객체를 검사하고 훼손된 블록의 목록을 생성합니다.

블록 훼손 감지를 위한 설정

블록 훼손이 있는지 여부를 확인하기 위해 객체를 검사하기 전에 검사 결과를 저장할 테이블을 생성해야 합니다. DBMS_REPAIR.ADMIN_TABLES 프로시저를 사용하여 이 테이블을 생성할 수 있습니다. 이 프로시저에는 다음 인수를 사용할 수 있습니다.

블록 훼손 감지

DBMS_REPAIR.CHECK_OBJECT 프로시저는 테이블, 분할 영역 또는 인덱스가 훼손되었는지 여부를 검사하는 데 사용할 수 있습니다. 이 프로시저는 지정된 객체의 모든 블록을 검사하여 훼손된 블록의 블록 주소로 지정된 복구 테이블을 채웁니다.

이 프로시저는 다음 매개변수를 갖습니다.

테이블을 분석한 후 블록 훼손을 검사하기 위해 다음과 같은 질의를 실행할 수 있습니다.

SQL> SELECT object_name, relative_file_no, block_id,
  2  marked_corrupt, corrupt_description, repair_description        
  3  FROM repair_table;
OBJECT_NAME  RELATIVE_F  BLOCK_ID  MARKED_COR
-----------  ----------  --------  ----------
CORRUPT_DESCRIPTION
------------------------------------------------------------
REPAIR_DESCRIPTION
------------------------------------------------------------
    CLASSES           6         3  FALSE
kdbchk: row locked by non-existent transaction table=0 slot=0
lockid=32   ktbbhitc=1
mark block software corrupt

복구 테이블에서 파일 6의 블록 3이 훼손되었다는 것을 알 수 있지만 이 블록은 아직 훼손된 것으로 표시되지 않았으므로 이 시점에서는 중요한 데이터를 포함하는 블록에서 행을 추출할 수 있습니다. 블록이 훼손된 것으로 표시된 후에는 전체 블록을 건너뛰어야 합니다.

훼손된 블록 표시

훼손된 블록이 있는 테이블에 대해 전체 테이블 스캔을 수행하면 오류가 발생하고 스캔이 중지됩니다. 테이블의 다른 모든 데이터를 읽을 수 있도록 하려면 데이터베이스 관리자가 되도록 많은 블록을 복구한 다음 복구할 수 없는 블록을 건너뛰어야 합니다.

Oracle8i의 초기 릴리스는 훼손 블록을 복구하지 않습니다. 이 때 데이터베이스 관리자는 DBMS_REPAIR.FIX_CORRUPT_BLOCKS 프로시저를 실행하여 다음 질의의 실행 결과에서 볼 수 있듯이 해당 블록을 소프트웨어 훼손으로 표시만 할 수 있습니다.

SELECT object_name, relative_file_no, block_id, marked_corrupt,
fix_timestamp
FROM repair_table;
OBJECT_NAME  RELATIVE_F  BLOCK_ID  MARKED_COR  FIX_TIMES

-----------  ----------  --------  ----------  ---------

CLASSES               6         3  TRUE        07-JAN-98

이 예제에서는 MARKED_CORRUPT 및 FIX_TIMESTAMP 열이 갱신되었습니다.

훼손된 블록 건너뛰기

DBMS_REPAIR.SKIP_CORRUPT_BLOCKS 프로시저를 사용하면 훼손된 것으로 표시된 블록을 제외한 모든 블록을 읽을 수 있습니다.

이 프로시저는 다음 매개변수를 갖습니다.

프로시저가 실행된 후 다음과 같은 질의를 실행하여 블록 훼손을 검사할 수 있습니다.

SELECT table_name, skip_corrupt
FROM dba_tables
WHERE table_name = 'CLASSES';
TABLE_NAME  SKIP_COR
----------  --------
T1          ENABLED

고아(Orphan) 키 및 일관성이 없는 결과

테이블에서 훼손 블록을 건너뛰면 인덱스만 검사하는 질의 또는 테이블을 읽는 질의의 결과에 일관성이 없을 수 있습니다. DBMS_REPAIR 패키지는 테이블에서 훼손된 것으로 표시되어 있는 블록을 가리키는 인덱스를 식별하는 기능을 제공합니다. 다음 단계를 수행하여 일관성이 없는 인덱스와 관련된 잠재적 문제를 식별하고 인덱스를 다시 생성합니다.

이 프로시저는 명명된 고아 테이블을 훼손된 블록을 가리키는 인덱스 키에 대한 데이터로 채웁니다.

분석된 객체

이 명령은 분석된 객체의 구조를 검증합니다.

INTO 및 CASCADE 절

활성화된(이전에는 비활성화된) 함수 기반 인덱스를 검증하기 위해 이 절을 사용하는 경우 검증 오류가 발생할 수 있습니다. 이러한 경우 인덱스를 재생성해야 합니다.

사용법

리두 로그 파일 정보를 분석하는 방법

1. 로그 파일을 분석하는 첫번째 단계는 딕셔너리 파일을 생성하는 것입니다.

- Oracle 서버가 딕셔너리 파일을 생성할 디렉토리로 UTL_FILE_DIR init.ora 매개변수를 초기화합니다.

- DBMS_LOGMNR_D 패키지에 있는 BUILD 프로시저를 사용하여 이 파일을 생성합니다.

참고: Oracle8 데이터베이스를 분석하는 경우 SYS 사용자로 제공된 dbmslogmnrd.sql 스크립트를 실행하여 DBMS_LOGMNR_D 패키지를 생성합니다.

예제에 표시된 코드는 /oracle/database/orc1dict.ora 파일을 생성하고 데이터 딕셔너리의 정보를 저장합니다. 이 파일은 객체 이름을 해석하는 데 사용되므로 덤프된 데이터 딕셔너리는 로그 파일에서 발견되는 모든 객체를 포함해야 합니다.

리두 로그 파일 정보를 분석하는 방법(계속)

2. LogMiner는 온라인 및 아카이브된 로그 파일을 모두 분석할 수 있습니다. 분석을 시작하기 전에 DBMS_LOGMNR.ADD_LOGFILE 프로시저를 사용하여 분석할 파일 목록을 제공해야 합니다.

- 이전에 제공된 파일 이름을 무시하고 분석할 새 파일 목록을 생성하려면 목록에 있는 첫 파일의 이름을 지정하는 동안 NEW 인수를 제공합니다.

- 이미 생성된 목록에 다른 파일을 추가할 때는 두번째 예제에 표시된 것처럼 ADDFILE 인수를 사용합니다.

이 목록을 정의할 때에는 동적 성능 테이블을 사용할 수 있어야 합니다.

리두 로그 파일 정보를 분석하는 방법(계속)

3. 분석할 로그 파일 목록이 생성되면 START_LOGMNR 프로시저를 호출하여 분석을 시작할 수 있습니다. 이 프로시저에서 사용할 수 있는 매개변수는 다음과 같습니다.

- STARTSCN: 분석할 SCN 범위의 하한

- ENDSCN: 분석할 SCN 범위의 상한

- STARTTIME: 분석할 시간 범위의 하한을 나타내는 날짜 값

- ENDTIME: 분석할 시간 범위의 상한을 나타내는 날짜 값

- DICTFILENAME: LogMiner 딕셔너리 파일 이름

4. END_LOGMNR 프로시저를 사용하여 분석 작업에 사용된 자원을 해제합니다.

리두 로그 파일 정보를 분석하는 방법(계속)

5. 로그 정보를 보기 위해 분석을 수행한 세션에서 V$LOGMNR_CONTENTS 뷰를 질의할 수 있습니다. 다른 세션에서는 이 뷰를 질의하여 데이터를 볼 수 없습니다. 다른 세션에서 결과를 보거나 뷰의 내용에 대해 여러 가지 작업이 필요한 경우 뷰의 정보를 테이블에 저장해야 합니다.

다음은 V$LOGMNR_CONTENTS 뷰의 일부에 대한 설명입니다.

열

설명

SCN

SCN(시스템 변경 번호)

TIMESTAMP

시간 기록

THREAD#

스레드 번호

LOG_ID

로그 ID

XIDUSN

트랜잭션 ID 실행 취소 세그먼트 번호

XIDSLOT

트랜잭션 ID 슬롯 번호

XIDSQN

트랜잭션 ID 시퀀스 번호

ABS_FILE#

데이터 블록 절대 파일 번호

REL_FILE#

데이터 블록 상대 파일 번호

DATA_BLK#

데이터 블록 번호

DATA_OBJ#

데이터 블록 객체 번호

DATA_OBJD#

데이터 블록 데이터 객체 번호

SEG_OWNER

세그먼트의 소유자 이름

SEG_NAME

세그먼트 이름

SEG_TYPE_NAME

세그먼트 유형

TABLE_SPACE

세그먼트의 테이블스페이스 이름

ROW_ID

행 ID

SESSION #

세션 번호

SERIAL #

일련 번호

USERNAME

사용자 이름

ROLLBACK

롤백 요청

OPERATION

작업

SQL_REDO

SQL 리두

SQL_UNDO

SQL 실행 취소

INFO

정보 메시지

STATUS

상태

참고

변경 내용 취소

실행 취소가 적용될 테이블에 중요한 종속성이 없는 경우 변경 내용을 취소하면 논리적 응용 프로그램 오류를 복구하기 위해 포인트 인 타임 복구를 수행할 필요성이 최소화됩니다.

동적 뷰

표시된 동적 성능 뷰는 분석 세션에서 분석에 제공되는 딕셔너리 파일, 로그 파일 및 인수를 검증하기 위해 질의할 수 있습니다.

요약 정보

컨텍스트

참조

매개변수

BACKGROUND_DUMP_DEST
DB_BLOCK_CHECKSUM
DB_BLOCK_CHECKING
UTL_FILE_DIR

동적 성능 뷰

V$LOGMNR_CONTENTS
V$LOGMNR_DICTIONARY
V$LOGMNR_LOGS
V$LOGMNR_PARAMETERS

데이터 딕셔너리 뷰

없음

패키지 및 프로시저

DBMS_REPAIR.admin_tables
DBMS_REPAIR.check_object
DBMS_REPAIR.fix_corrupt_blocks
DBMS_REPAIR.skip_corrupt_blocks
DBMS_REPAIR.rebuild_freelists
DBMS_REPAIR.dump_orphan_keys
DBMS_LOGMNR_D.build
DBMS_LOGMNR.add_logfile
DBMS_LOGMNR.start_logmnr
DBMS_LOGMNR.end_logmnr

명령

ANALYZE INDEX ... VALIDATE STRUCTURE
ANALYZE TABLE... VALIDATE STRUCTURE [CASCADE]

유틸리티

dbv