About DATABASE

적용 대상:

Oracle Database - Enterprise Edition - 버전 7.0.16.0 to 11.2.0.4 [릴리즈 7.0 to 11.2]
이 문서의 내용은 모든 플랫폼에 적용됩니다.

목적

이 문서는 오라클 데이터파일에 하나 이상의 블록 손상들을 어떻게 처리하는지 설명하고 손상된 블록들을 다루기 위한 주요 작업에 대해 설명한다. 작업을 수행하기 전에 문서 전체를 읽는다.

상세 내역

소개

이 문서는 오라클 데이터파일에 하나 이상의 블록 손상들을 어떻게 처리하는지 설명하고 손상된 블록들을 다루기 위한 주요 작업에 대해 설명한다. 작업을 수행하기 전에 문서 전체를 읽는다.

이 노트는 메모리 손상 문제 (일반적으로 ORA-600 [17xxx] 유형 오류)를 포함하지 않는다.

주의 : STARTUP중에 ORA-1578 문제가 발생하는 경우에는 문서:106638.1를 참조하여 상담 받기 위해 해당지역의 지원 센터에 문의하십시오.

         - 이 노트는 고객에게 공개되어 있지 않지만 관련 단계들은 경험이 많은 지원 분석가에 의해 제공되어질 수 있습니다.

많은 오류 유형에 대해 여러 곳에서 이 문서를 참조 할 수 있다 - 손상된 블록에 대해 다음 정보를 확보하는 것이 중요하다 :

• 손상된 블록을 포함하고 있는 파일의 절대 파일 번호(FILE NUMBER).
  이 문서에서 "&AFN"과 같이 사용되었다.

• 손상된 블록을 포함하는 파일의 파일 이름(FILE NAME).
  이 문서에서 "&FILENAME"과 같이 사용되었다.
  파일 번호는 알고 있지만 파일 이름을 모르는 경우 파일 이름을 알기 위해 V$DATAFILE을 사용할 수 있다: 

  Oracle8i에서 파일 번호가 V$DATAFILE 표시되지 않고 &AFN이 DB_FILES 매개변수(parameter) 값보다 크다면 아마도 임시 파일(TEMPFILE) 일 것이다. 
  이 경우 파일 이름은 이 SQL문을 사용하여 찾을 수 있다:

• 해당 파일에서 손상 블록의 블록 번호(BLOCK NUMBER).
  이 문서에서 "&BL"과 같이 사용되었다.

• 영향을 받는 블록을 포함하는 테이블스페이스 번호와 이름
  이 문서에서 "&TSN"(테이블스페이스 번호)와 "&TABLESPACE_NAME"과 같이 사용되었다.
  이들을 모를 경우 다음 SQL문을 사용하여 찾을 수 있다 :

• 손상된 부분이 있는 테이블스페이스의 블록 크기(BLOCK SIZE).
  이 문서에서 "&TS_BLOCK_SIZE"와 같이 사용되었다.

오라클 7, 8.0 그리고 8.1인 경우 :
데이터베이스의 모든 테이블스페이스는 동일한 블록 크기를 가지고 있다.
이 버전에서는 "SHOW PARAMETER DB_BLOCK_SIZE"로 &TS_BLOCK_SIZE 값을 사용할 수 있다.

예 : ORA-1578 오류인 경우 :
            ORA-01578: ORACLE data block corrupted (file # 7, block # 12698)
            ORA-01110: data file 22: '/oracle1/oradata/V816/oradata/V816/users01.dbf'
      이라면:

 
다른 오류(ORA-600, ORA-1498 등)에서 위의 값은 오라클 지원에 의해 제공되거나 관련 오류를 포함한 문서에서 제공된다.


ORA-1410 "invalid ROWID" , ORA-12899 "value too large for column" 등과 같은 일부 오류는 손상된 파일 / 블록의 세부 사항을 제공하지 않는다. 이러한 경우 Document 869305.1가 손상된 행의 위치를 찾는 데 도움이 될 수 있다.

손상을 처리하는 단계들의 개요

블록 손상에는 여러 가지 원인이 있다.

• • 하드웨어 / 펌웨어의 잘못된 I/O
  • OS 문제
  • 오라클 문제
  • 노로깅(NOLOGGING) 또는 복구 불가능(UNRECOVERABLE)인 데이터베이스에서 복구
    (ORA-1578의 경우는 예상되는 동작이다.- 아래를 확인한다.)

오라클 오류가 발생한 시점이 손상이 처음에 발생했을 때보다 훨씬 나중일 수 있다.

근본 원인은 일반적으로 손상이 발생 된 시점에 알 수 없고, 대부분 가장 중요한 요구 사항은 정상적으로 다시 운영하는 것이다. 이 문서에서 손상 문제를 해결하기 위해 사용되는 단계는 아래와 같다:

1. 1. 손상 문제의 범위를 결정하고 문제가 영구적인지 또는 일시적인지 결정
      
      문제가 넓은 범위이거나 오류가 자주 발생하는 경우에는 먼저 원인을 파악에 주력한다(하드웨어를 확인하는 등..). 하드웨어에 결함이 있는 경우 시스템을 복구하는 것은 소용이 없기 때문에 매우 중요하다.
       
   2. 결함이 있거나 의심되는 하드웨어를 교체 또는 제거
   3. 어떤 데이터베이스 객체들이 영향을 받았는지 결정
   4. 가장 적합한 데이터베이스 복구 / 데이터 살리기 방법을 선택

위의 모든 단계에서 증거를 수집하고 어떤 작업을 했는지에 대해 정확하게 기록하는 것이 중요하다. 이 문서의 '증거 >>' 태그들은 문제의 근본 원인 식별을 지원하기 위해 수집되어져야 하는 정보를 나열한 것이다.

노로깅(NOLOGGING) 또는 복구 불가능(UNRECOVERABLE)으로 인한 손상 

노로깅(또는 복구 불가능) 동작이 객체에서 수행되어 졌고 해당 객체가 포함 된 데이터파일이 나중에 복구되었다면 노로깅 동작에 의해 영향을 받은 데이터 블록들은 손상된 것으로 표시되어지고 액세스 할 때 ORA-1578가 발생할 것이다. Oracle8i에서 ORA-26040은 ("ORA-26040: Data block was loaded using the NOLOGGING option" ) 원인이 매우 분명하게 표시되지만 과거 버전은 추가적인 오류 메시지가 없다. 블록이 노로깅 동작을 통한 복구에 의해 손상된 경우에는 이 문서의 섹션 3 "어떤 객체가 영향을 받는가?"를 활용할 수 있지만 아래 사항을 주의해야 한다 :

1. 1. 복구 방법으로는 노로깅 데이터를 살릴 수 없다
   2. 블록 내부에서 살릴 수 있는 데이터는 없다

(1) 손상 문제의 범위를 결정

손상 오류가 발생할 때 마다 오류 메시지 전체를 기록하고 관련 오류에 대한 인스턴스의 경고 로그(alert log)와 추적 파일(trace file)을 확인한다. 하나의 블록 손상 또는 UNRECOVERABLE 작업으로 인한 오류인지 더 심각한 문제로 인한 오류지 확인하기 위해 가장 먼저 이 작업을 하는 것이 중요하다.

문제의 범위를 결정하고 다른 손상이 있는지 확인하기 위해 영향 받는 파일(및 중요한 파일)에 DBVERIFY를 사용하여 분석하는 것이 좋다. 
DBVERIFY 사용에 대한 상세내용은 Document 35512.1를 참고한다.

손상된 파일/블록 목록들을 결정한 다음 조치할 수 있는 작업을 결정하는 데 아래 단계들은 도움이 될 수 있다.

(2) 의심스러운 하드웨어를 교체 또는 이동

손상 문제의 대부분은 하드웨어 결함에 의해 발생한다.

하드웨어 오류 또는 의심스러운 구성 요소가 있다면 하드웨어 문제를 해결하거나 복구 방법을 진행하기 전에 서브 시스템에서 사용 가능한 별도의 디스크 공간을 만드는 것이 좋다.

다음 단계를 사용해서 데이터 파일을 이동할 수 있다 :

• • 이관되어야 할 파일이 OFFLINE이거나 인스턴스가 마운트(MOUNT) 상태(OPEN이 아님)인지 확인
  • 물리적으로 새로운 위치에 데이터 파일을 복원(또는 복사)
    예: /newlocation/myfile.dbf
  • 파일의 새로운 위치를 오라클에게 알려줌.
    예: ALTER DATABASE RENAME FILE '/oldlocation/myfile.dbf' TO '/newlocation/myfile.dbf';
        (임시 파일의 이름은 변경할 수 없음을 주의 – 임시 파일은 삭제 후 새로운 위치에 재생성 되어야 한다.)
    

 direct IO , async IO 또는 유사한 특별한 IO 기능을 사용한다면 잠재적인 문제의 원인을 제거하기 위해 그러한 기능을 비활성화하는 것은 좋을 수 있다.

(3) 어떤 객체가 영향을 받는가?

복구하는 방법에 대해 결정을 하기 전에 어떤 객체가 영향을 받았는지 확인하는 것이 가장 좋다. - 다시 만들기 쉬운 객체에 손상이 있을 수 있기 때문이다.
예: 테이블의 5개 행에서 손상인 경우 테이블을 삭제하고 다시 생성하는 것이 복구를 수행하는 것보다 더 빠를 수 있다.

각 손상에 대해 다음 표에 있는 정보를 수집한다.
이 작업을 수행하기 위한 단계는 아래에 설명되어 있다. 

 각 손상에 대해서 이 표를 기록하는데 아래 정보가 도움이 될 것이다.

1. "최초 오류" 최초에 보고된 오류다. 예 : ORA-1578 / ORA-1110 , 모든 인수(argument)를 포함한 ORA-600 등..

2. "절대 파일 번호", "상대 파일 번호" 그리고 "블록 번호" 파일 번호 및 블록 번호는 오류, 오라클 지원, 또는 이 문서에서 제공된 오류 문서 안의 단계에 의해 확인할 수 있다.

    Oracle8/8i/9i/10g: 절대 파일번호와 상대 파일 번호는 거의 동일하지만 다를 수도 (특히 데이터베이스가 Oracle7에서 이관 된 경우) 있다. &AFN과 &FN에 대한 정확한 번호를 확인하는 것이 중요하며 틀릴 경우에는 잘못된 객체를 살릴 수도 있다.

    ORA-1578은 동반된 ORA-1110 오류 안에 절대 파일 번호와 함께 상대 파일번호를 알려준다. ORA-600 오류에서는 절대 파일 번호를 알려준다.

    다음 질의는 데이터베이스 안의 데이터파일에 대한 절대 및 상대 파일 번호를 표시할 것이다 :

    Oracle8i/9i/10g:

    위의 정보 외에도 Oracle8, Oracle8i 이후부터는 임시 파일(TEMPFILE)을 가질 수 있다. 아래 질의는 데이터베이스 안의 임시 파일에 대한 절대 및 상대 파일 번호를 표시할 것이다 :

    Oracle7:  절대 파일 번호와 상대 파일 번호 모두 동일한 파일 번호를 사용한다.

3. "세그먼트 유형", "소유자", "이름" 그리고 "테이블스페이스"
다음 질의는 주어진 절대 파일 번호 &AFN"과 손상된 블록의 블록 번호 "&BL"에 대해 객체 타입, 소유자, 세그먼트의 이름을 확인해 줄 것이다. – 질의를 하기 위해서 데이터베이스는 열려(OPEN) 있어야 한다 :

만약 블록이 임시 파일 안에 있다면 위의 질의의 결과는 없을 것이다.
임시 파일에 대한 "세그먼트 유형"은 "TEMPORARY" 이다.

위의 질의가 어떠한 행도 반환되지 않는 경우 손상된 블록이 로컬 관리 테이블스페이스(Locally Managed Tablespace, LMT)의 세그먼트 헤더일 수 있다.손상된 블록이 LMT안의 세그먼트 헤더 블록일 때, 위의 질의는 경고 로그(alert log)에 손상 메시지를 생성하지만 질의가 실패하지는 않는다. 이 경우 아래 질의를 사용한다:

(4) 관련 객체와 복구 방법

관련 객체와 복구 방법은 세그먼트 유형에 따라 달라질 수 있다. 추가적인 질의와 가능한 복구 방법은 가장 일반적인 세그먼트 유형 각각에 대해서 아래에 설명되어 있다.

캐쉬(CACHE)
클러스터(CLUSTER) 
파티션 인덱스(INDEX PARTITION)   인덱스(INDEX) 
LOB 인덱스(LOBINDEX)                LOB 세그먼트(LOBSEGMENT) 
롤백(ROLLBACK) 
파티션 테이블(TABLE PARTITION)   테이블(TABLE)
임시(TEMPORARY)
TYPE2 UNDO
다른 세그먼트 유형(Other Segment Types)
질의로부터 "no rows"

캐쉬(CACHE)

-세그먼트 유형이 CACHE인 경우에는 정확하게 SQL과 매개 변수(parameter)를 입력하였는지 재확인한다. 동일한 결과가 나온다면 모든 정보와 함께 오라클 지원을 받는다.

방법:

   데이터베이스 복구를 필요로 할 가능성이 있다.

클러스터(CLUSTER) 

- 세그먼트가 클러스터인 경우에는 클러스터에 포함되어 있는 테이블들을 확인한다.

방법:
   소유자가 "SYS"인 경우 모든 상세 내용과 함께 오라클 지원을 받는다.
   데이터베이스 복구를 필요로 할 가능성이 있다.

   딕셔너리 클러스터가 아닌 경우 가능한 방법:
      복구
      또는 클러스터 안의 모든 테이블에서 데이터를 살린 후 클러스터와 모든 테이블을 재생성 한다.

   클러스터는 몇 개의 테이블로 구성되기 때문에 복구 방법을 결정을 하기 전에 클러스터 안의 각 테이블에 대한 정보를 수집하는 것이 가장 좋다.

파티션 인덱스(INDEX PARTITION)

- 세그먼트가 파티션 인덱스인 경우 이름과 소유자를 기록한 다음 영향 받는 파티션을 확인한다 :

 

그런 다음 세그먼트가 인덱스 세그먼트였다면 아래와 같이 계속 진행한다.

방법:
  파티션 인덱스는 아래와 같이 사용하여 재생성(rebuild) 할 수 있다:
    ALTER INDEX xxx REBUILD PARTITION ppp;    
  (아래 "(5B)인덱스 재생성"에서 설명된 것처럼 재생성(REBUILD) 방법을 다룬다.)

인덱스

- 세그먼트 유형이 인덱스이면서 소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.

  딕셔너리 인덱스나 파티션 인덱스가 아닌 경우는 인덱스의 테이블을 확인한다:

  제약 조건의 유형(CONSTRAINT_TYPE)에 대한 값은 다음과 같다.

P    인덱스는 기본 키 제약 조건(primary key constraint)을 지원한다.
U    인덱스는 고유 키 제약 조건(unique constraint)을 지원한다.

  인덱스가 기본 키 제약 조건("P" 유형)을 지원할 경우는 기본 키가 외래 키 제약 조건(foreign key constraint)에 의해 참조되었지 확인한다.

방법:
  소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

  딕셔너리 인덱스가 아닌 경우에 대한 가능한 방법은 다음과 같다:
  복구
  또는 인덱스 재생성(관련된 모든 제약 조건에 대해 활성화(enable)/비활성화(disable)와 함께)
  (아래 "(5B)인덱스 재생성"에서 설명된 것처럼 재생성(REBUILD) 방법을 다룬다.)

롤백(ROLLBACK)

- 세그먼트가 롤백 세그먼트인 경우에는 롤백 세그먼트 손상에 대한 특별한 조치가 필요하므로 오라클 지원을 받는다.

방법:
데이터베이스 복구를 필요로 할 가능성이 있다.

TYPE2 UNDO

- TYPE2 UNDO는 롤백 세그먼트의 특별한 유형으로 시스템에서 관리하는 실행 취소 세그먼트(system managed undo segment)이다. 이 세그먼트의의 손상은 특별한 조치가 필요하다.

방법:
  데이터베이스 복구를 필요로 할 가능성이 있다.

파티션 테이블(TABLE PARTITION)

- 세그먼트 유형이 파티션 테이블인 경우는 이름과 소유자를 기록한 다음 영향 받는 파티션을 결정한다 :

  그런 다음 세그먼트가 테이블 세그먼트였다면 아래와 같이 계속 진행한다.

방법:
  모든 손상이 동일한 파티션 안에 있는 상황에선 비어있는 테이블을 손상된 파티션과 교체(EXCHANGE)하는 방법이 있다. - 테이블로부터 정상적인 데이터를 추출하는 동안 (손상된 파티션 안의 데이터를 조회하지 않고) 지속적으로 응용 프로그램을 허용할 수 있다.

  다른 방법은 아래 "테이블(TABLE)" 방법을 참조한다.

테이블(TABLE)

- 소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

  딕셔너리 테이블이나 파티션 테이블이 아닌 경우는 테이블에 존재하는 인덱스를 확인한다.

  그리고 테이블에 기본 키(primary key)가 있는지 확인한다.

 
  기본 키(primary key)가 있는 경우는 외래 키 제약 조건(foreign key constraint)에 의해 참조되는지 확인한다.

방법:
  소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

  딕셔너리 테이블이 아닌 경우에 대한 가능한 방법은 다음과 같다:
  복구
  또는 테이블(또는 파티션)으로부터 데이터를 살린 다음 테이블(또는 파티션)을 재생성 한다.
  또는 손상된 위치를 그대로 남겨둔다.
        (예: 생략해야 될 문제의 블록을 표시하기 위하여 DBMS_REPAIR를 사용한다.)

IOT (인덱스 구성 테이블, Index Organized Table)

- IOT 테이블의 손상은 힙(heap)이나 파티션 테이블과 같은 방식으로 처리 해야 한다.
  PK가 손상된 경우는 예외이다.
  IOT 테이블의 PK는 테이블 자체이며, 삭제나 재생성은 할 수 없다.

방법:
  소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

  딕셔너리 테이블이 아닌 경우에 대한 가능한 방법은 다음과 같다: 
  복구
  또는 테이블(또는 파티션)으로부터 데이터를 살린 다음 테이블(또는 파티션)을 재생성 한다.
  또는 손상된 위치를 그대로 남겨둔다.
        (DBMS_REPAIR는 IOT에서 사용할 수 없다.)

LOB 인덱스(LOBINDEX)

- LOB가 속해 있는 테이블을 확인한다:

- 테이블의 소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

- LOB 인덱스는 재생성(rebuild)될 수 없으므로 영향 받는 테이블의 LOB 컬럼의 손상과 같은 문제로 다뤄야 한다.
  "테이블(TABLE)" 부분의 SQL을 사용하여 손상된 LOB 인덱스를 가지는 테이블에 대한 인덱스와 제약 조건 정보를 확인한 다음 다시 여기로 돌아 온다.

방법:
  소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

  딕셔너리 테이블이 아닌 경우에 대한 가능한 방법은 다음과 같다:
  복구
  또는 테이블(또는 파티션)으로부터 데이터를 살린 다음 테이블(또는 파티션)을 재생성 한다.

  문제의 컬럼에 추가적인 DML이 없는 경우를 제외하고 손상을 그대로 남겨 두는 것은 일반적으로 좋지 않다.

LOBSEGMENT

- LOB가 속해 있는 테이블을 확인한다:

소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다. 데이터베이스 복구를 필요로 할 가능성이 있다.

딕셔너리 테이블이 아닌 경우 ...

  "테이블(TABLE)" 부분의 SQL을 사용하여 손상된 LOB 인덱스를 가지는 테이블에 대한 인덱스와 제약 조건 정보를 확인한 다음 영향 받는 행의 상세한 내용을 확인하기 위해 다시 여기로 돌아온다.

  손상된 LOB를 가지는 테이블 행에 대해 어떠한 상세 내용 없이 오류가 보고되기 때문에 손상된 LOB 블록을 참조하는 정확한 행을 찾는 것은 힘들 수 있다.

  일반적으로 응용프로그램의 로그나 SQL_TRACE 또는 오류가 발생한 세션의 10046 TRACE(해당되는 경우)에서 확인

  현재의 SQL/바인드/행을 식별하는데 도움이 된다.

  그런 다음 응용 프로그램에서 오류가 발생하기를 기다리고 추적파일(trace file)을 찾는다.

  추가적인 단서가 없는 경우 문제 테이블의 행을 검색하기 위해 오류가 발생할 때까지 반복하여 LOB 데이터를 추출하는 PLSQL 블록을 만들 수 있다. 이러한 방법은 시간이 걸릴 수 있지만 손상된 LOB 블록을 참조하는 기본 키 또는 행의 ROWID를 얻을 수 있다.

  보다 일반적인 다른 스크립트

 

방법:
  소유자가 "SYS"인 경우는 모든 상세 내용과 함께 오라클 지원을 받는다.
  데이터베이스 복구를 필요로 할 가능성이 있다.

  딕셔너리 테이블이 아닌 경우에 대한 가능한 방법은 다음과 같다:
  복구
  또는 테이블(그리고 LOB 컬럼)으로부터 데이터를 살린 다음 테이블(또는 파티션)을 재생성 한다.
  또는 손상된 위치를 그대로 남겨둔다.
        (DBMS_REPAIR는 LOB 세그먼트에서 사용되어 질 수 없다.)

임시(TEMPORARY)

- 세그먼트 유형이 TEMPORARY인 경우 손상은 영구적인 객체(permanent object)에 영향을 주지 않는다. 문제가 발생한 테이블 스페이스가 TEMPORARY 테이블스페이스인지 확인한다.

방법:
  임시 테이블스페이스인 경우 새로운 임시 테이블스페이스를 생성할 수 있고 모든 사용자에 대해해당 테이블스페이스로 변경한 다음  문제의 테이블스페이스를 삭제할 수 있다.

  임시 테이블스페이스가 아닌 경우 그 블록은 다시 읽지 말아야 하고 다음에 그 블록을 사용할 때 다시 포맷되어야 한다 - 치유된 근본 원인을 반복해서는 안 된다.

  디스크가 의심되고 테이블스페이스가 자주 사용되는 데이터를 포함한다면 영향 받는 파일의 데이터베이스는 복구 될 수 있지만 일반적으로 복원은 필요하지 않다.

다른 세그먼트 유형(Other Segment Types)

- 세그먼트 유형이 위의 결과가 아닌 경우 현재까지 수집된 모든 정보와 함께 오라클 지원을 받는다.

 "반환된 행이 없음"

손상된 블록을 포함하는 영역(extent)이 없는 경우에는 먼저 질의에 사용된 숫자를 다시 확인한다. 파일과 블록이 정확하다고 확신하고 DBA_EXTENTS에서 객체에 속한 것이 표시되지 않는다면:

• • 임시 파일에 속한 파일인지 다시 확인한다.
  • 임시 파일 번호가 init.ora의 DB_FILES 매개변수에 의존하기 때문에 이 매개 변수의 변경사항이 오류에 포함된 절대 파일 번호를 변경한다.
  • DBA_EXTENT는 로컬로 관리하는 테이블스페이스(locally managed tablespace)의 로컬 공간 관리에 사용되어진 블록을 포함하지는 않는다.
  • 지금 질의하는 데이터베이스가 오류가 발생한 데이터파일과 다른 지점이라면 문제가 되는 객체는 삭제되었을 수 있고 DBA_EXTENTS에 대한 조회 결과는 없을 수 있다.
  • 조사중인 오류가 DBVERIFY에 의해 보고된 경우에는 객체에 속하는지에 대한 여부와 상관없이 DBV는 모든 블록을 검사한다. 다른 객체에 사용되지 않는 블록이지만 데이터파일에 존재하는 손상된 블록일 수 있다.

방법:
  사용하지 않는(UNUSED) 오라클 블록에서의 오류는 기존의 문제가 있는 블록은 읽지 않으며 오라클이 새로운 블록 이미지를 만들 것이기 때문에 무시할 수 있다.

  공간을 관리하는 블록(space management block)이 의심되는 경우 문제를 확인하기 위하여 아래와 같이 DBMS_SPACE_ADMIN를 사용할 수 있다:

  이렇게 하는 것은 추적 파일(trace file)에 일관성 없이 쓰여지겠지만 심각하게 손상된 블록을 발견하면 아래와 같은 오류가 발생할 것이다:

증거>>

각각의 손상된 블록에 대하여 손상의 실제 원인을 식별 하고 확인할 필요가 있다면 다음과 같은 물리적 증거를 수집하는 것도 좋은 생각이다.

1. 손상 블록과 그 블록의 전/후 블록에 대한 운영체제 HEX 덤프

   유닉스 :

  예 : BL=1224 라면:

  VMS:

  XXXX= OS 블록 번호(512바이트 조각)일 때 '&TS_BLOCK_SIZE/512'로 보고된 블록 번호를 곱하여 계산.

2. ARCHIVELOG 모드인 경우 오류가 발생한 시간 주위, 바람직하게는 오류가 발생하기 전 몇 시간 동안의 ARCHIVELOG 파일의 안전한 복사본을 만든다. 또한 이전 이미지와 REDO로 원인을 파악하는데 도움이 될 수 있기 때문에 오류가 발생하기 전의 문제 데이터파일의 백업을 확보한다.

    (DBV는 파일의 백업 복사본에 문제가 존재하는지 확인하기 위하여 종종 사용되어진다.) 이상적인 시나리오는 어떠한 손상도 없는 데이터파일 백업 이미지와 손상이 처음 보고된 시점과 그 이전의 시간까지의 모든 REDO를 확보하는 것이다.

3. 문제 블록의 오라클 덤프를 확보:

    (결과는 USER_DUMP_DEST의 추척 파일(trace file)이다.)

(5) 복구 방법을 선택

영향 받는 객체에 따라 가장 좋은 복구 방법은 달라진다. 각 영향 받는 객체에 사용할 수 있는 주요 방법은 위 섹션 (3)의 정보에서 강조했다. 선택되어진 실제 복구 방법은 하나 이상의 방법을 조합할 수 있다 :

복구가 필요한가?

오류가 임시 테이블스페이스에 있거나 더 이상 데이터베이스 객체의 일부분이 아닌 블록인 경우 다른 스토리지 장비에 문제의 테이블스페이스를 재배치하는 것이 바람직할 수 있을지라도 아무런 조치가 필요하지도 않을 수 있다. 경고를 확인한다.

완전 복구 방법인가?

완전 복구를 위해서 다음의 조건이 참이어야 한다.

• 데이터 베이스는 ARCHIVELOG 모드이다.
  

  ( "ARCHIVE LOG LIST" 명령어는 ARCHIVELOG 모드인지 보여준다.)

• 영향 받는 파일들의 좋은 백업이 있어야 한다. 몇 가지 경우에서 현재 손상은 되었지만 오랜 시간 동안 발견되지 않을 수도 있음을 주의한다. 가장 최근의 데이터파일 백업이 여전히 손상을 포함하고 있다면 필요한 ARCHIVELOG 전체가 있는 한 더 이전의 백업이 필요할 수 있다. 
  ( 백업파일의 복구된 복사본에서 특정 블록이 손상되었다면 검증하기 위하여 종종 DBV START= / END= 방법을 사용할 수 있다.)

• 모든 ARCHIVELOG는 백업 받은 시간으로부터 현재 시점까지 이용 가능해야 한다.

• 현재 온라인 로그는 이용 가능해야 하고 아무 이상이 없어야 한다.

• NOLOGGING 동작을 통해서는 오류를 복구할 수 없다. 

위의 조건이 만족 될 때 완전 복구는 일반적으로 선호되는 방법이다. 

*하지만 주의한다*

(a) 트랜잭션의 롤백이 자체의 롤백 세그먼트 외에 다른 객체에서 손상된 블록을 나타낸다면 UNDO는 삭제되었을 수 있다.이 경우 인덱스를 재생성(rebuild) / 완전 복구 후 데이터 무결성을 확인 할 필요가 있다.

(b) 데이터파일 또는 데이터베이스 복구를 사용한 경우 복구되어진 파일이 마지막 백업 이후 NOLOGGING 동작인 데이터를 포함한다면 그 블록들은 손상으로 표시될 것이다. 어떤 경우에는 현재보다 더 나쁜 시나리오가 될 수 있다.

데이터베이스 복구가 벌써 실행되어졌고 손상은 아직 존재한다면 모든 백업이 손상을 포함하거나 근본 결함이 아직 존재하거나 REDO를 통해 문제가 재현된 것이다.

완전 복구 단계를 위한 "(5A) 완전 복구"를 참조한다.

객체는 객체 자신으로부터 데이터를 추출할 필요 없이 삭제 또는 재생성 되어 질 수 있는가?

객체를 잃거나 스크립트/최근 익스포트로 재생성 할 수 있다. 객체가 삭제되어진 다음 해당 객체의 블록은 "free"로 표시되고 그 블록이 새로운 객체에 할당되어졌을 때 다시 포맷되어질 것이다. 어떤 데이터도 필요하지 않다고 절대적으로 확신되지 않는다면 DROP보다는 RENAME하는 것이 좋다.

파티션 테이블인 경우 영향을 받는 파티션만 삭제되어 질 수 있다.

파티션 세그먼트 헤더나 파티션 헤더가 포함된 파일이 오프라인된 손상이라면 DROP PARTITION은 실패할 것이다. 이 경우에도 여전히 동일하게 정의된 테이블과 교환하여 파티션을 삭제할 수 있다.

재 생성을 할 수 있는 대부분의 일반적인 객체는 인덱스다.
항상 테이블의 인덱스 문제 이전에 테이블 손상을 먼저 해결한다.
자세한 내용은 "(5B) 인덱스 재생성"를 참조한다.

모든 세그먼트에서 절대 파일 번호와 손상 블록의 블록 번호를 알고 있을 때 객체의 DDL을 추출하는 가장 빠른 방법은 아래와 같다:

객체를 재생성 하기 전에 데이터를 살리는 것이 필요한가?

정기적으로 변경되는 중요한 응용프로그램 테이블에서 문제가 발생한 경우에는 가능한 테이블로부터 많은 데이터를 살리는 것이 필요할 것이고 그런 다음 테이블을 재생성 한다.

자세한 내용은 "(5C) 테이블에서 데이터 살리기"를 참조한다.

이 순간을 위해 손상된 장소를 남겨 두는 것을 허용하는가?

어떤 경우에는 가장 즉각적인 방법은 손상된 장소를 그대로 남겨 두는 것이고 응용프로그램의 접근을 허용하지 않도록 하는 것이다.

자세한 내용은 "(5D) 손상된 위치를 남겨두기"를 참조한다.

마지막 방법

아래의 방법이 가능한가?

데이터베이스나 테이블스페이스 시간 복구를 통하여 오래된 시점(시간 복구의 시점으로부터)으로 복구
또는 손상 이전의 COLD 백업의 복원
또는 존재하는 익스포트 파일을 사용하는 것

자세한 내용은 "(5E) 마지막 방법"을 참조한다.

(5A) 전체 복구

데이터베이스가 ARCHIVELOG 모드이고 영향 받은 파일의 좋은 백업을 가지고 있다면 일반적으로 선호하는 방법이다.

문제를 해결하는 것에 대해 보장하지 않지만 손상 이슈의 대부분에 효과적이다. 복구한 뒤 문제가 재현된다면 위의 방법 목록으로 돌아가서 다른 방법을 선택한다.

오라클 9i(또는 이상)을 사용하는 경우 RMAN BLOCKRECOVER 명령을 사용하여 블록 수준의 복구를 수행할 수 있다.

이전의 오라클 버전을 사용하는 경우 데이터파일 복구(데이터베이스의 나머지 부분은 여전히 실행되는 동안 완료될 수 있다.), 또는 데이터베이스 복구(데이터베이스가 중단되어야 한다.) 중 하나를 수행할 수 있다.

오라클 11g (또는 이상)을 사용하는 경우 데이터 복구 관리자를 사용할 수 있다.

블록 수준 복구

오라클9i의 RMAN은 데이터베이스(데이터파일의 다른 블록 포함)의 나머지 부분에 평소처럼 조회를 하면서 개별적인 블록을 복구할 수 있다. 블록 레벨 복구는 단지 현재 시점으로 블록을 완전히 복구하는데 사용할 수 있다.

개별 블록의 복구 방법을 사용하기 위하여 RMAN 백업을 사용할 필요는 없다.
예:

미디어 손상 문제로 인하여 파일 #6 블록 #30에 ORA-1578이 있고 '.../RESTORE/filename.dbf'에 복원되어지는 파일에 대한 좋은 COLD 백업 이미지가 있는지 고려한다. (기본 위치에) 존재하는 모든 아카이브로그를 제공한 다음 블록 수준의 복구를 수행하기 위해 다음과 같은 명령어를 사용하여 RMAN을 사용할 수 있다.

현재 시점에 단 하나의 문제 블록의 블록 복구를 수행하기 위해 등록된 데이터파일 백업 이미지와 필요한 ARCHIVELOG를 사용할 것이다.

RMAN BLOCKRECOVER 명령어와 한계의 자세한 내용에 대해서 문서를 참조한다. Document 144911.1 문서의 예제를 참조한다.

데이터파일 복구

데이터파일 복구는 다음 단계를 포함한다. 여러 개의 파일인 경우 각 파일의 단계를 반복하거나 아래의 "데이터베이스 복구"를 참조한다. 데이터베이스가 OPEN이거나 MOUNT인 상태라면 이 단계들을 사용할 수 있다.

영향 받은 데이터파일을 오프라인

(정상적이지 못한 백업인 경우를 대비하여) 안전한 위치로 복사

정상적인 디스크에 파일의 최신 백업을 복원

확실한 손상을 위하여 DBVERIFY로 복원 된 파일을 확인한다.

DBVERIFY 사용에 대한 자세한 내용은 Document 35512.1를 참조한다.

복원 된 파일이 정상이라면 새로운 위치의 데이터파일의 이름을 변경한다. (이전 위치와 다른 경우)

데이터파일 복구

파일을 온라인

데이터베이스 복구

데이터베이스 복구는 일반적으로 아래의 단계를 포함한다:

안전한 위치로 복구되어질 현재의 모든 파일을 복사

정상적인 디스크 위치에 백업파일을 복원
컨트롤 파일과 온라인 REDO 로그 파일은 복원하지 않는다.

DBVERIFY를 사용하여 복원된 파일을 검사한다. DBVERIFY를 사용하는 자세한 방법은 Document 35512.1를 참조한다.

변경된 파일의 이름을 변경한다.

요구한 모든 파일이 온라인인지 확인한다.

데이터베이스 복구

데이터베이스 오픈

전체 복구 후

전체 복구가 수행되었다면 데이터베이스를 사용할 수 있도록 하기 전에 아래와 같이 확인하는 것이 좋다:

실행 :

테이블/인덱스의 불일치를 확인하기 위하여 각 문제 객체에 대해 수행한다.
삭제된 UNDO가 있다면 재생성 되어야 할 인덱스에 대해 불일치가 발생할 수 있다.
응용 프로그램에서 테이블 안의 데이터에 대한 논리적 무결성을 확인한다.

(5B) 인덱스 재생성

손상된 객체가 사용자의 인덱스인 경우에는 테이블이 손상되지 않았다는 전제하에 간단하게 삭제 및 재생성을 할 수 있다.

기반 테이블이 손상된 경우에는 인덱스를 재생성 하기 전에 테이블을 정리하는 것이 좋다.

수집된 정보에 외래키 제약조건이 있는 인덱스가 발견되는 경우에는 아래와 같이 수행해야 된다:

• 각 외래키를 위하여

• 기본키를 재작성(rebuild)하기 한다.

• 외래키 제약조건을 활성화 한다.

파티션 인덱스인 경우 아래와 같이 수행한다.

주의 :

• 손상된 블록을 포함하고 있는 기존의 인덱스 세그먼트로부터 새로운 인덱스를 생성하도록 하기 때문에 "ALTER INDEX ..  REBUILD" 명령어를 를 사용하여 파티션이 아닌 손상된 인덱스를 재생성 하지 않는 것이 중요하다.

  이전 인덱스 세그먼트로부터 새로운 인덱스를 생성하지 않으며 이렇게는 사용되어 질 수 있다.

• 새로운 인덱스가 기존의 인덱스 열의 하위 세트인 경우  인덱스 생성 작업은 기존의 인덱스의 데이터를 사용할 수 있다. 따라서 두 개의 손상된 인덱스가 있는 경우 재생성 하기 전에 둘 다 삭제한다.
• 인덱스를 재생성 할 때 올바른 스토리지 정보를 사용하는지 확인한다.

(5C) 테이블로부터 데이터를 살리기

손상된 객체가 테이블이나 클러스터 또는 LOB 세그먼트인 경우에는 손상된 블록 안의 데이터는 유실 될 수 있다는 것을 이해해야 한다.

데이터의 일부는 블록의 헥사 덤프(HEX dump)나 인덱스의 열로부터 살릴 수 있다.

손상된 블록을 포함하는 테이블 외의 데이터를 얻는 방법에는 여러 가지가 있다. 아래에 설명된 것 중 가장 적절한 방법을 선택한다. 이러한 방법의 목적은 액세스 할 수 있는 테이블 블록에서 가능한 많은 데이터를 추출하는 것이다. 새로운 객체가 올바른 이름으로 생성될 수 있도록 손상된 테이블의 이름을 변경하는 것이 일반적으로 좋은 방법이다.

손상된 블록 주변의 손상된 테이블에서 데이터를 추출하는 방법

1. 오라클 8.0, 8.1, 및 9i를 포함한 오라클 7.2 이후부터 테이블에 손상된 블록을 건너 뛸 수(SKIP) 있다.

    이것은 데이터를 추출하는 가장 간단한 방법이고 아래에 설명되었다.

    DBMS_REPAIR.SKIP_CORRUPT_BLOCKS 또는 Event 10231  Document 33405.1를 사용하여 데이터를 추출

    IOT 오버플로우 세그먼트에 손상이 있는 경우 아래와 동일한 방법이지만, 인덱스 전체 스캔과 함께 10233 이벤트가 사용되어야 한다.

    "래퍼(wrapper)" 블록이 손상된 것으로 표시된 경우 이 방법만 사용할 수 있다. 예: 블록이 ORA-1578로 보고된 경우.

    문제가 ORA-600 또는 보고되지 않은 기타 오류와 ORA-1578인 경우 엑세스 할 때 ORA-1578이 발생하는 것과 같은 "소프트 손상(soft corrupt)"처럼 문제 블록을 표시하기 위하여 DBMS_REPAIR를 사용할 수 있고 DBMS_REPAIR.SKIP_CORRUPT_BLOCKS을 사용하는 것이 허락된다.

    주의 : "FIX_CORRUPT_BLOCKS" 프로시져에 의해 손상으로 표시된 모든 블록들은 FIX_CORRUPT_BLOCKS의 시간을 통하여 복원 / 복구 작업으로 손상으로 표시될 수 있을 것이다.

    DBMS_REPAIR 사용에 대한 전체 내용은 문서에서 찾을 수 있지만 요약하면 다음의 단계와 같다.

2. 오라클 7.1 이후부터 ROWID 범위 검색을 사용할 수 있다.

    이에 대한 구문은 조금 까다롭지만 ROWID 힌트를 사용하여 손상된 블록 주변을 조회 할 수 있다.

    Oracle7과 Oracle8 사이에 변경된 ROWID의 형식 때문에 이에 대한 두 개의 문서가 있다 :

     Using ROWID Range Scans to extract data in Oracle8 and higher Document 61685.1
     Using ROWID Range Scans to extract data in Oracle7 Document 34371.1

3. 기본 키가 있는 경우 이 인덱스에서 테이블 데이터를 조회할 수 있다.

    또한 다른 인덱스에서 데이터의 일부를 조회할 수 있다.

    속도가 느리고 시간이 많이 걸리지만 일반적으로 오라클 7.0 버전에 필요한 것이다. 이 방법은 Document 34371.1에서 설명되어 있다.(또한 ROWID 범위 스캔을 설명한다.)

4. 테이블에서 데이터를 살리기 위하여 사용할 수 있는 다양한 프로그램/PLSQL 스크립트가 있다. 설정하고 사용하는 시간이 위의 방법보다 오래 걸릴 수 있지만 ORA-1578 외의 손상 종류에 대해 다양한 방법으로 대처할 수 있다.

    이러한 방법을 지원받을 때 일반적으로 많은 조작이 필요하기 때문에 이 문서들 중 일부는 고객에게 보여지지 않을 수 있다.

    Pro*C 사용이 가능해야 하며 Pro*C 실행파일을 생성하는 방법을 이해해야 한다 :

    Oracle8.1의 SALVAGE.PC      Document 97357.1
    Oracle7의 SALVAGE.PC        Document 2077307.6

    수동적인 상호작업이 필요하다 :
    Oracle7/8의 SALVAGE.SQL    Document 2064553.4
    Oracle7/8의 SALVAGE.SQL    Note:  28308.1

    아래는 Oracle8i 및 9i에서만 가능하다. 목적은 손상된 블록을 표시하고 테이블 데이터를 추출하기 위해 SKIP_CORRUPT 테이블 속성을 를 사용하는 것이다.

    블록 손상을 표시하기 위한 DBMS_REPAIR 사용 Document 68013.1
    LONG 컬럼의 손상을 위해 : LONG 컬럼의 손상이 있는 테이블 재생성하기 Note: 876493.1

손상된 LOB 세그먼트 블록이 있는 테이블에서 데이터를 추출하는 방법

LOB 세그먼트에 DBMS_REPAIR를 사용할 수 없다.

손상된 LOB 블록이 테이블에서 어떠한 행에 의해 참조되지 않는 경우 테이블을 CREATE TABLE as SELECT (CTAS) 또는 익스포트/삭제/임포트 할 수 있다.

손상된 LOB 블록이 행에 의해 참조되는 경우 문제의 행을 제외하는 WHERE 술어와 함께 조회 또는 익스포트를 할 수 있다.

손상된 블록 자체에서 데이터를 추출

손상된 블록 자체는 "손상"이기 때문에 그 블록으로부터 추출된 모든 데이터는 의심하면서 취급해야 한다. 손상된 블록 자체로부터 행을 얻기 위한 주요 방법은 다음과 같다 :

• 테이블 블록에 대한 오라클 지원으로부터 블록의 내용을 해석하려고 시도하는 도구를 사용할 수 있다.

           HEX 또는 BLOCKDUMP를 읽을 수 있는 형식으로 변경 Note: 47419.1

• 손상된 블록에 들어있는 ROWID의 위치로 인덱스에 포함된 열의 데이터를 추출하기 위해 테이블에 있는 기존의 인덱스를 사용한다. 이는 위에서 언급한 ROWID 범위 스캔 문서의 끝 부분에 설명되어 있다.

   Oracle8/8i은 Document 61685.1를 참조한다.
   Oracle7은 Document 34371.1를 참조한다.

• 문제 블록에 데이터를 넣은 원래의 삽입/갱신 구문을 찾기 위해 REDO에 로그마이너를 사용할 수도 있다. 데이터가 블록 안에 실제로 들어갔을 때 주 요인이 여기에  있다.

   예; 행 2를 어제 삽입되었지만 행 1은 5년 전에 삽입되었을 수 있다.

(5D) 손상된 위치를 남겨두기

손상된 위치를 그대로 남겨 둘 수 있고 보고된 오류를 허용하거나 응용프로그램에서 문제의 행에 접근하는 것을 차단할 수 있다.
예: 문제 블록 / 행이 자식 테이블인 경우 자식 행에 절대 접근하지 않도록 부모 행을 접근하는 방법을 통해 응용 프로그램에서 접근을 차단할 수 있다. (하지만 계단식 제약조건을 조심해야 한다)

대량의 데이터에 접근하는 보고서와 기타 작업에 도움이 되지 않을 수 있으므로 조회할 때 블록 오류를 방지하기 위하여 위의 5C 안에 있는 DBMS_REPAIR 방법을 사용하는 것이 바람직할 수 있다. 이와 같이 손상을 표시하고 남겨두는 것은 전체 데이터를 살리거나 예정된 시스템 중단 기간에 시도되어질 복구, 또는 두 번째 (복제) 데이터베이스에 있는 다른 복구 방법을 확인하기 위한 시간을 확보하는 단기적인 해결책을 줄 수 있다. DBMS_REPAIR.FIX_CORRUPT_BLOCKS으로 손상된 블록을 표시하더라도 FIX_CORRUPT_BLOCKS이 실행된 시간을 통해 복구 후에 손상된 블록으로 표시될 수 있는 것을 유의한다. 

손상된 위치를 그대로 남겨는 것은 빠르게 없어지거나 나중에 삭제될 데이터를 위해 합리적일 수 있다.(예: 오래된 파티션들은 어느 시점에 제거될 수 있는 날짜로 파티션 된 테이블에서)

LOB 세그먼트에 손상을 남겨두기

응용프로그램에서 테이블을 재생성 할 수 있는 시간까지 손상된 LOB 열에 위치를 그대로 남겨두는 것은 가능하다.

위의 "경고" 시나리오를 발생하지 않게 하기 위한 방법 중 하나는 문제의 행을 보호하기 위해 WHERE 술어를 포함한 뷰를 통해 테이블에 접근할 수 있도록 보장하는 것이다.
예: 테이블 MYTAB ( a number primary key, b clob )은 손상된 LOB 데이터를 가리키는 하나 이상의 행을 가지고 있음을 고려한다.

다른 문제의 행에는 BAD='Y'로 설정한다.

MYVIEW로 MYTAB에 액세스하는 경우에는 문제 행은 표시되지 않을 것이고 이를 처리할 수 있을 때까지 격리된 손상된 항목은 갱신될 수 없다.

분명히 이 예제는 해결책을 마련할 시간을 더 줄 수 있으나 일부 응용 프로그램은 이미 유사한 방법을 가지고 있을 수 있고 문제의 행을 숨기는 뷰를 통해서만(또는 RLS 정책을 통해) 데이터에 접근 할 수 있다.

손상된 위치를 남겨 둘 때 경고

손상된 위치는 남겨둘 수 있으며 RMAN 백업 경고 / 오류 등으로 DBVERIFY를 실행하는 동안 손상된 블록은 여전히 표시될 것임을 알아야 한다.

이 도구들로부터 확인 될 것을 기대하는 손상, 특히 RMAN(예 : MAX_CORRUPT 설정됨)과 함께 건너 뛰는 것을 기대하는 블록에 대해 주의하여 기록하는 것이 중요하고, 손상이 해결되었을 때 에러의 "허용"을 반드시 삭제한다.

예: 손상된 위치를 남겨 두고 응용 프로그램 수준에서 문제의 행을 회피한 것에 의해 처리되어 진 손상된 블록을 고려한다.
RMAN은 백업 중에 손상을 허용하도록 구성 할 수 있다.
일부 테이블은 재구성 하는 동안 나중에 재생성 된 테이블이다.
RMAN은 현재 오류가 없어야 하는 것을 반영하기 위해 변경되지 않았다면 RMAN은 나중에 발생하는 다른 손상을 무시할 수 있다.

테이블 세그먼트 주변의 손상된 블록을 남겨두는 것이 질의로부터 일치하지 않는 결과를 초래할 수 있다는 사실에 주의하는 것이 중요하다.
예: 다른 결과는 인덱스 스캔인지 아니면 테이블 액세스인지에 따라 SKIP_CORRUPT 설정이 있는 테이블에서 발생할 수 있다.
다른 보고는 단지 오류일 수 있다.

손상된 위치를 남겨두지만 DBMS_REPAIR.FIX_CORRUPT_BLOCKS를 사용하면 블록이 손상된 것으로 REDO에 기록하고 이후의 복구 방법을 제한할 수 있는 것을 주의한다.

 (5E) 마지막 방법

(물리적 또는 논리적으로) 대기 설정이 있을 경우 첫 번째를 선택합니다.
문제 블록의 어떤 종류이든지 하나의 가능한 방법은 데이터베이스 또는 문제의 테이블스페이스를 손상이 발생하기 전의 시점으로 복구하는 것이다. 이 방법의 어려운 점은 처음 문제가 발생했을 때를 알 수 없는 것이다.

DBVERIFY는 종종 손상으로 인해 복원된 파일을 확인하는 데 사용할 수 있다.
DBVERIFY에 대한 자세한 내용은 Document 35512.1에서 설명되어 있다. 특히 START= / END= DBV 방법은 복원된 백업 이미지에서 문제의 블록 자체가 정상인지에 아닌지 빠르게 테스트를 하기 위하여 사용할 수 있다.

이 섹션에서 복구 가능한 몇 가지 최종 방법을 설명한다.
여기까지 온 경우는 다음 중 하나 이상의 일이 발생했을 것이다:

• "중요한" 데이터파일을 분실(또는 그 곳에서 손상이 발생)하고 문제의 파일에 대한 좋은 백업이 없다(손상 없이).
• 아카이브 로그 모드가 아니거나 모든 아카이브 파일이 없다.
• 전체 복구로도 문제가 재현된다.

마지막 기회:

데이터파일의 모든 사본을 잃어버렸지만 여전히 파일이 처음 생성되었을 때부터 아카이브 로그가 존재하는 경우에는 파일을 복구해볼 수 있음을 유의한다.
예:

이 시나리오에 있는 경우 아래 내용을 계속하기 전에 이 단계들을 사용하여 데이터파일 복구를 시도한다.

여기까지 온 경우 현재 시점으로 복구 할 남은 방법은 없다. 인스턴스를 종료를 권장하고 선택된 수행 과정이 실패할 경우를 대비하여 현재 위치로 되돌아 오기 위해 지금 현재의 데이터베이스를 백업한다.(예 : 백업이 비정상인 것을 확인한 경우).

사용 가능한 일부 개요 방법은 다음과 같다.

오래된 오프라인 백업으로 되돌리기
- 예: 노아카이브 로그 모드 인 경우

오프라인 백업으로 복제 데이터베이스를 구성하기
- 문제 테이블을 추출(익스포트) 또는 문제의 테이블스페이스를 전송

일관성이 있는 이전 시점으로 복구

• 정상 백업과 필요한 모든 아카이브 로그가 필요하다.
• 모든 파일들은 복원되어야 하고 전체 데이터베이스는  적당한 시점으로 돌아 간다.
• 복제 데이터베이스에서 시점 복구를 하는 것이 가능할 수 있고 그런 다음 문제의 테이블스페이스를 문제의 데이터베이스로 전송하거나 복제된 데이터베이스로부터 문제의 테이블을 익스포트나 임포트를 한다.

테이블스페이스에 대한 시간 복구
- 영향 받는 테이블스페이스만 시간 복구를 수행하는 것이 가능할 수 있다. Document 223543.1와 같이 테이블스페이스 시간 복구에 대해 설명하는 많은 문서가 있다.

논리적인 익스포트나 복사로 데이터베이스를 재구축하기
- 데이터베이스의 좋은 논리적 백업이 필요하다.
- 주의: 이 방법을 위해 데이터베이스는 재생성 해야 한다.
- 다른 방법과 마찬가지로 재 구축은 복제 데이터베이스에서 문제 테이블의 좋은 이미지를 얻을 수 있다.

좋은 백업이 있는 경우 DB_BLOCK_CHECKING=TRUE로 돌아가는 것은 잘못된 시작부분인 첫 번째 문제 시점을 찾는데 도움이 될 수 있다. 
복구 방법을 조사하는 동안 문제의 데이터베이스를 정지하는 것은 일반적으로 필요가 없다.