오라클은 데이터 블록 손상 감지 및 수정을 위한 다양한 방법을 제공합니다. 한 가지 방법은 손상이 감지된 후 개체를 삭제하고 다시 만드는 것입니다. 데이터 블록 손상이 행의 하위 집합으로 제한되는 경우 손상된 행을 제외한 모든 데이터를 선택하여 테이블을 다시 빌드하는 또 다른 옵션이 있습니다.
데이터 블록 손상을 관리하는 또 다른 방법은 다음과 같습니다. 테이블 및 인덱스의 손상된 블록을 검색하고 복구할 수 있습니다. 이 방법을 사용하면 가능한 경우 손상을 해결하고 개체를 다시 작성하거나 복구하려고 시도하는 동안 개체를 계속 사용할 수 있습니다. 다음 방법을 사용하여 손상을 해결합니다:
- 3 단계:개체를 사용할 수 있게 만들기
- 4 단계:손상 복구 및 손실된 데이터 재 구축
참고:데이터 손실과 관련된 모든 손상은 해당 데이터가 전체 데이터베이스 시스템에 어떻게 들어 맞는지 분석하고 이해해야 합니다. 이 패키지에서 제공하는 복구 방법이 각 특정 손상 문제에 적합한 도구인지 확인해야 합니다. 수리의 성격에 따라 데이터가 손실될 수 있으며 논리적 불일치가 발생할 수 있습니다.
표 19-1 에서는 패키지를 구성하는 절차에 대해 설명합니다.
표 19-1
프로시저 이름 | 설명 |
---|---|
|
테이블 또는 인덱스의 손상을 감지하고 보고합니다. |
|
블록(이전에 |
|
손상된 데이터 블록의 행을 가리키는 인덱스 항목을 보고합니다. |
|
개체의 프리리스트를 다시 작성합니다. |
|
사용하는 경우 테이블 및 인덱스 스캔 중에 손상된 것으로 표시된 블록을 무시합니다. 사용하지 않는 경우,당신은 오류 오라-1578 블록이 손상 표시 발생할 때 얻을. |
|
복구 및 고아 키 테이블에 대한 관리 기능(만들기,삭제,제거)을 제공합니다. 참고:이러한 테이블은 항상 시스템 스키마에 만들어집니다. |
1 단계:손상 감지 및 보고
첫 번째 작업은 손상을 감지하고 보고해야 합니다. 보고는 블록에 무엇이 잘못되었는지를 나타낼 뿐만 아니라 관련 복구 지시문을 식별합니다. 손상을 감지하기 위한 몇 가지 옵션이 있습니다. 표 19-2 는 다양한 검출 방법론을 설명합니다.
표 19-2 부패 검출 방법의 비교
검출 방법 | 설명 |
---|---|
수리 |
지정된 테이블,파티션 또는 인덱스에 대한 블록 검사를 수행합니다. 복구 테이블을 결과로 채웁니다. |
프로젝트 |
오프라인 데이터베이스에서 블록 검사를 수행하는 외부 명령줄 유틸리티입니다. |
분석 |
구조 유효성 검사 옵션과 함께 사용하면 인덱스,테이블 또는 클러스터 구조의 무결성을 확인하고 테이블과 인덱스가 동기화되었는지 확인하거나 확인합니다. |
블록 검사 |
그들은 실제로 손상 표시되기 전에 손상된 블록을 식별합니다. 블록을 변경할 때 검사가 수행됩니다. |
check_object프로시저는 지정된 개체에 대한 손상을 확인하고 보고합니다. 분석과 비슷합니다…인덱스 및 테이블에 대한 구조 문 유효성 검사,블록 검사는 각각 인덱스 및 데이터 블록에 대해 수행됩니다.
check_object
는 손상을 보고할 뿐만 아니라fix_corrupt_blocks
이 이후에 개체에서 실행될 경우 발생할 수 있는 모든 수정 사항을 식별합니다. 이 정보는 먼저admin_tables
절차에서 만들어야 하는 복구 테이블을 채워서 사용할 수 있습니다.
check_object
절차를 실행한 후 복구 테이블에 대한 간단한 쿼리에 개체의 손상 및 복구 지시문이 표시됩니다. 이 정보를 통해 보고된 문제를 가장 잘 해결하는 방법을 평가할 수 있습니다.
오프라인 데이터베이스 검사 수행
일반적으로 데이터 손상 문제가 발생하면 오프라인 진단 유틸리티로 사용합니다.
참조: 자세한 내용은 다음을 참조하십시오.
분석:손상 보고
분석 테이블…구조 유효성 검사 문은 분석된 개체의 구조를 확인합니다. 오라클이 구조의 유효성을 성공적으로 검사하면 유효성 검사를 확인하는 메시지가 사용자에게 반환됩니다. 오라클 개체 구조에서 손상이 발생하면 오류 메시지가 반환됩니다. 이 경우 개체를 삭제하고 다시 만듭니다.
참조:분석 문에 대한 자세한 내용은 다음을 참조하십시오.
DB_BLOCK_CHECKING(블록 검사는 초기화 매개 변수)
설정할 수 있습니다 차단 검사에 대한 인스턴스를 통해 DB_BLOCK_CHECKING 매개 변수(기본값이 TRUE);이 검사 데이터 및 인덱스 블록을 때마다 그들이 수정할 수 있습니다. 시스템 설정 변경 명령문에 의해 수정 가능한 동적 매개 변수입니다.
2 단계:수리 비용 및 사용 혜택 평가
수리 비용을 사용하기 전에 부채와 관련하여 사용 혜택의 무게를 측정해야 합니다; 또한 손상된 개체를 해결하는 데 사용할 수 있는 다른 옵션도 검토해야 합니다.
첫 번째 단계는 다음 질문에 대답하는 것입니다:
- 부패의 정도는 무엇인가?
손상 및 복구 작업이 있는지 확인하려면
check_object
절차를 실행하고 복구 테이블을 쿼리합니다. - 블록 손상을 해결하기 위해 사용할 수 있는 다른 옵션은 무엇입니까?
다른 소스에서 데이터를 사용할 수 있다고 가정하면 개체를 삭제하고 다시 만들고 다시 채 웁니다. 또 다른 옵션은 생성 테이블을 발행하는 것입니다…손상된 테이블에서 선택 문으로 새 하나를 만들 수 있습니다.
선택한 문에서 손상된 행을 제외하면 손상을 무시할 수 있습니다.
미디어 복구를 수행합니다.
- 개체를 사용할 수 있게 하려면 어떤 논리적 손상 또는 부작용이 발생합니까? 이것들은 해결 될 수 있습니까? 그렇게 하기 위해 필요한 노력은 무엇인가?
손상된 것으로 표시된 블록의 행에 액세스 할 수 없습니다. 그러나 유효하게 액세스 할 수있는 행이 여전히 있더라도 블록이 손상되었다고 표시 될 수 있습니다.
블록이 손상되었다고 표시되면 참조 무결성 제약 조건이 깨질 수 있습니다. 이 경우 제약 조건을 사용하지 않도록 설정하고 다시 사용하도록 설정하면 불일치가 보고됩니다. 모든 문제를 해결 한 후에는 제약 조건을 성공적으로 다시 활성화 할 수 있어야합니다.
테이블에 정의된 트리거가 있는 경우 논리적 손상이 발생할 수 있습니다. 예를 들어,행이 다시 삽입되는 경우 삽입 트리거가 발생해야합니까? 이러한 문제는 설치 시 트리거 및 트리거 사용을 이해하는 경우에만 해결할 수 있습니다.
프리리스트 블록에 액세스 할 수 없습니다. 손상된 블록이 프리리스트의 머리 또는 꼬리에 있는 경우 공간 관리는 프리리스트를 다시 초기화합니다. 그런 다음 프리리스트에 있어야 하는 블록이 있을 수 있습니다.
rebuild_freelists
절차를 실행하여 이 문제를 해결할 수 있습니다.인덱스와 테이블이 동기화되지 않을 수 있습니다. 먼저
dump_orphan_keys
절차를 실행하여 이 문제를 해결할 수 있습니다(손상된 데이터를 다시 작성할 때 유용할 수 있는 키에서 정보를 얻기 위해). 그런 다음 인덱스 변경 온라인 다시 작성 문을 실행하여 테이블과 해당 인덱스를 다시 동기화하십시오. - 수리가 데이터 손실을 수반하는 경우 이 데이터를 검색할 수 있습니까?
데이터 블록이 손상되었다고 표시되면 인덱스에서 데이터를 검색할 수 있습니다.
dump_orphan_keys
절차는 이 정보를 검색하는 데 도움이 될 수 있습니다. 물론 이러한 방식으로 데이터를 검색하는 것은 인덱스와 테이블 간의 중복성에 따라 달라집니다.
3 단계:개체를 사용할 수 있도록
이 단계에서는 테이블 및 인덱스 스캔 중에 손상을 무시하여 개체를 사용할 수 있도록 합니다.
부패 수리: 손상된 개체를 사용할 수 있게 하려면 복구 기능 범위 밖에 남아 있는 손상을 건너뛰는 환경을 설정합니다.
손상으로 인해 데이터 블록의 잘못된 행과 같은 데이터 손실이 발생하는 경우 이러한 모든 블록은fix_corrupt_blocks
절차에 의해 손상된 것으로 표시됩니다. 그런 다음skip_corrupt_blocks
프로시저를 실행할 수 있습니다. 건너뛰기를 설정하면 테이블 및 인덱스 스캔이 손상된 것으로 표시된 모든 블록을 건너뜁니다. 이는 미디어 및 소프트웨어 손상된 블록 모두에 적용됩니다.
손상된 블록을 건너뛸 때의 영향
인덱스와 테이블이 동기화되지 않으면 한 쿼리가 인덱스만 프로브한 다음 후속 쿼리가 인덱스와 테이블을 모두 프로브하는 상황에서 설정된 트랜잭션 읽기 전용 트랜잭션이 일치하지 않을 수 있습니다. 테이블 블록이 손상되었다고 표시되면 두 쿼리는 다른 결과를 반환하여 읽기 전용 트랜잭션의 규칙을 위반합니다. 이 방법에 접근하는 한 가지 방법은 설정된 트랜잭션에서 읽기 전용 트랜잭션을 수행 할 때 손상을 건너 뛰지 않는 것입니다.
연결된 행을 선택할 때도 비슷한 문제가 발생합니다. 본질적으로 동일한 행의 쿼리는 손상에 액세스 할 수도 있고 액세스하지 않을 수도 있으므로 다른 결과를 얻을 수 있습니다.
4 단계:손상 복구 및 손실된 데이터 재 구축
개체를 사용할 수 있게 한 후 다음 복구 작업을 수행할 수 있습니다.
덤프 _오르판 _키를 사용하여 데이터 복구
dump_orphan_keys
프로시저는 손상된 데이터 블록의 행을 가리키는 인덱스 항목을 보고합니다. 이러한 모든 인덱스 항목은 키 및 손상 행을 저장하는 고아 키 테이블에 삽입됩니다.
인덱스 항목 정보가 검색된 후 인덱스 변경 온라인 다시 작성 문을 사용하여 인덱스를 다시 작성할 수 있습니다.
프리리스트의 머리 또는 꼬리에”손상됨”으로 표시된 블록이 발견되면 프리리스트가 다시 초기화되고 오류가 반환됩니다. 이 프리리스트 오프 잘못된 블록을 취하지만,그것은 당신이 손상된 블록을 따라 모든 블록에 프리리스트 액세스를 잃게 발생합니다.
rebuild_freelists
절차를 사용하여 프리리스트를 다시 초기화할 수 있습니다. 개체가 스캔되고 블록이 프리리스트에 있는 것이 적절하면 마스터 프리리스트에 추가됩니다. 프리리스트 그룹은 공평한 방식으로 블록을 측정하여 처리됩니다-한 번에 블록. 개체에서”손상됨”으로 표시된 모든 블록은 다시 빌드하는 동안 무시됩니다.
제한 사항 및 제한 사항
:
- 로브가있는 테이블,중첩 테이블 및 바레이는 지원되지만 줄 밖 열은 무시됩니다.
- 클러스터는
skip_corrupt_blocks
및rebuild_freelist
절차에서 지원되지만check_object
절차에서는 지원되지 않습니다. - 인덱스 구성 테이블 및 로브 인덱스는 지원되지 않습니다.
-
dump_orphan_keys
프로시저는 비트맵 인덱스 또는 함수 기반 인덱스에서 작동하지 않습니다. -
dump_orphan_keys
프로시저는 최대 3,950 바이트 길이의 키를 처리합니다.
검사 _개체
check_object
프로시저는 지정된 개체를 검사하고 복구 테이블에 손상 및 복구 지시문에 대한 정보를 채웁니다. 유효성 검사는 개체의 모든 블록을 검사하는 블록으로 구성됩니다. 개체의 일부를 확인하려는 경우 선택적으로 범위,파티션 이름 또는 하위 파티션 이름을 지정할 수 있습니다.
procedure check_object(schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN binary_integer DEFAULT NULL, relative_fno IN binary_integer DEFAULT NULL, block_start IN binary_integer DEFAULT NULL, block_end IN binary_integer DEFAULT NULL, corrupt_count OUT binary_integer)
표 19-3 개체 확인 절차
인수 | 설명 |
---|---|
|
검사할 개체의 스키마 이름입니다. |
|
검사할 테이블 또는 인덱스의 이름입니다. |
|
검사할 파티션 또는 하위 파티션 이름입니다. 이 개체가 분할된 개체이고 |
|
처리할 개체의 유형입니다. 테이블 개체 또는 인덱스 개체 중 하나여야 합니다. 이 매개 변수는 다음과 같습니다. |
|
채울 복구 테이블의 이름입니다. 테이블이 시스템 스키마에 있어야 합니다. |
|
향후 사용을 위해 예약. |
|
상대 파일 번호. 블록 범위를 지정할 때 사용됩니다. |
|
블록 범위를 지정하는 경우 처리 할 첫 번째 블록입니다. 개체가 단일 테이블,파티션 또는 하위 파티션인 경우에만 지정할 수 있습니다. |
|
블록 범위를 지정하는 경우 처리 할 마지막 블록입니다. 개체가 단일 테이블,파티션 또는 하위 파티션인 경우에만 지정할 수 있습니다. 블록 _시작 또는 블록 _엔드 중 하나만 지정되면 다른 블록은 각각 파일의 첫 번째 또는 마지막 블록으로 기본값으로 설정됩니다. |
|
보고된 손상 수입니다. |
수정
이 절차를 사용하여check_object
절차에서 이전에 생성된 복구 테이블의 정보를 기반으로 지정된 개체의 손상된 블록을 수정합니다. 블록을 변경하기 전에 블록이 여전히 손상되었는지 확인합니다. 손상된 블록은 손상된 블록 소프트웨어를 표시하여 복구됩니다. 복구가 수행되면 복구 테이블의 관련 행이 수정 타임스탬프로 업데이트됩니다.
procedure fix_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', flags IN boolean DEFAULT NULL, fix_count OUT binary_integer)
표 19-4 수정 프로그램 중단 차단 절차
인수 | 설명 |
---|---|
|
스키마 이름. |
|
고정 할 손상된 블록이있는 개체의 이름입니다. |
|
처리할 파티션 또는 하위 파티션 이름입니다. 이 개체가 분할된 개체이고 |
|
처리할 개체의 유형입니다. 테이블 개체 또는 인덱스 개체 중 하나여야 합니다. 이 매개 변수는 다음과 같습니다. |
|
복구 지시문이 있는 복구 테이블의 이름입니다. 시스템 스키마에 있어야 합니다. |
|
향후 사용을 위해 예약. |
|
블록의 수는 고정. |
손상된 데이터 블록의 행을 가리키는 인덱스 항목을 보고합니다. 발생한 각 인덱스 항목에 대해 지정된 고아 테이블에 행이 삽입됩니다.
복구 테이블을 지정하면 소프트웨어 손상으로 표시된 모든 데이터 블록 외에 기본 테이블과 연결된 모든 손상된 블록이 처리됩니다. 그렇지 않으면 손상된 것으로 표시된 블록만 처리됩니다.
이 정보는 테이블에서 손실된 행을 다시 빌드하고 진단할 때 유용할 수 있습니다.
procedure dump_orphan_keys( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT INDEX_OBJECT, repair_table_name IN varchar2 DEFAULT 'REPAIR_TABLE', orphan_table_name IN varchar2 DEFAULT 'ORPHAN_KEY_TABLE', key_count OUT binary_integer)
표 19-5 덤프 _오르판 _키 프로시저
인수 | 설명 |
---|---|
|
스키마 이름. |
|
개체 이름. |
|
처리할 파티션 또는 하위 파티션 이름입니다. 이 개체가 분할된 개체이고 |
|
처리할 개체의 유형입니다. 기본값은 인덱스 객체입니다. |
|
기본 테이블의 손상된 블록에 대한 정보가 있는 복구 테이블의 이름입니다. 지정된 테이블이 시스템 스키마에 있어야 합니다. |
|
손상된 데이터 블록의 행을 참조하는 각 인덱스 항목에 대한 정보로 채울 고아 키 테이블의 이름입니다. 지정된 테이블이 시스템 스키마에 있어야 합니다. |
|
처리된 인덱스 항목 수입니다. |
지정된 개체에 대한 프리리스트를 다시 작성합니다. 모든 무료 블록은 마스터 프리리스트에 배치됩니다. 다른 모든 프리리스트는 제로화됩니다. 객체에 여러 프리리스트 그룹이 있는 경우,자유 블록은 모든 프리리스트 간에 분산되어 라운드 로빈 방식으로 다른 그룹에 할당됩니다.
procedure rebuild_freelists( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT);
표 19-6
인수 | 설명 |
---|---|
|
스키마 이름. |
|
프리리스트를 다시 작성할 개체의 이름입니다. |
|
프리리스트를 다시 작성할 파티션 또는 하위 파티션 이름입니다. 이 개체가 분할된 개체이고 |
|
처리할 개체의 유형입니다. 테이블 개체 또는 인덱스 개체 중 하나여야 합니다. 이 매개 변수는 다음과 같습니다. |
지정된 개체의 인덱스 및 테이블 스캔 중에 손상된 블록을 건너뛰거나 건너뜁니다. 개체가 테이블인 경우 건너뛰기가 테이블 및 해당 인덱스에 적용됩니다. 개체가 클러스터인 경우 클러스터의 모든 테이블과 해당 인덱스에 적용됩니다.
procedure skip_corrupt_blocks( schema_name IN varchar2, object_name IN varchar2, partition_name IN varchar2 DEFAULT NULL, object_type IN binary_integer DEFAULT TABLE_OBJECT, flags IN boolean DEFAULT SKIP_FLAG);
표 19-7 스킵_중단_차단 절차
인수 | 설명 |
---|---|
|
처리할 개체의 스키마 이름입니다. |
|
개체의 이름입니다. |
|
처리할 파티션 또는 하위 파티션 이름입니다. 이 개체가 분할된 개체이고 |
|
처리할 개체의 유형입니다. 테이블 개체 또는 클러스터 개체 중 하나여야 합니다. 이 매개 변수는 다음과 같습니다. |
|
스킵 플래그가 지정된 경우 인덱스 및 테이블 스캔 중에 개체에 대한 소프트웨어 손상 블록 건너뛰기를 켭니다. 소프트웨어 손상 블록을 발생 하는 검사 반환 합니다. |
관리 테이블
복구 및 고아 키 테이블에 대한 관리 기능을 제공합니다.
procedure admin_tables( table_name IN varchar2, table_type IN binary_integer, action IN binary_integer, tablespace IN varchar2 DEFAULT NULL);
표 19-8 관리자 _테이블 프로시저
인수 | 설명 |
---|---|
|
처리할 테이블의 이름입니다. 이 문제를 해결하려면 다음 단계를 수행하십시오. 지정된 경우 테이블 이름에 적절한 접두사인’고아_’또는’수리_’이 있어야 합니다. |
|
테이블 유형,고아 테이블 또는 수리 테이블 중 하나 여야합니다. |
|
수행할 관리 작업을 나타냅니다. 이 작업을 수행하는 방법은 다음과 같습니다. 테이블이 이미 있고 만들기 작업이 지정된 경우 오류가 반환됩니다. 삭제_작업은 존재하지 않는 개체와 연결된 테이블의 모든 행을 삭제하는 것을 나타냅니다. 테이블이 존재하지 않고 삭제 작업이 지정되면 오류가 반환됩니다. 경우 CREATE_ACTION 및 DROP_ACTION 지정,관련의 이름을 따서 명명된 뷰 DBA_<table_name>가 만들어지고 떨어졌다 각각입니다. 뷰는 존재하지 않는 개체와 연결된 행이 제거되도록 정의됩니다. |
|
테이블을 만들 때 사용할 테이블스페이스를 나타냅니다. 기본적으로 시스템의 기본 테이블스페이스가 사용됩니다. 테이블스페이스가 지정되어 있고 동작이 생성되지 않으면 오류가 반환됩니다. |
예외를 복구 할 수 있습니다.
942 | 복구 테이블이 없습니다 |
1418 | 지정된 인덱스가 존재하지 않습니다. |
24120 | 잘못된 매개 변수 |
24121 | 계단식 플래그와 블록 범위를 지정할 수 없음 |
24122 | 잘못된 블록 범위 |
24124 | 잘못된 작업 매개 변수가 지정되었습니다 |
24126 | 뉴스레터 구독 지정 및 개체가 테이블이 아닙니다. |
24127 | 테이블 스페이스가 지정되고 동작이 생성되지 않습니다. |
24128 | 파티션되지 않은 개체에 대해 지정된 파티션 |
24129 | 잘못된 고아 키 테이블 이름-‘고아_’접두사가 있어야 함 |
24129 | 지정된 복구 테이블이’수리_’접두사로 시작되지 않음 |
24131 | 복구 테이블에 잘못된 열이 있음 |
24132 | 복구 테이블 이름이 너무 깁니다. |