그것은 공통 데이터 파일을 참조 : 비 파일 시스템 데이터 테이블 스페이스, UNDO_TABLESPACE 테이블 공간 및 읽기 전용 임시 테이블 스페이스 테이블 스페이스를. 그들은 예를 충돌 상황을 복원하지 않습니다 데이터베이스를 시작할 수없는 자체 DB를 비정상으로 이어질하지 않습니다, 피해 사용자 데이터에 액세스 할 수없는 원인이된다.
이러한 데이터 파일은 OPEN 상태 데이터베이스에, 고 가용성 전략을 사용하여 복원 할 수 있습니다
10.1 일반 데이터 파일 손상의 결과
일반 데이터 파일이 손상되면, 바로 비즈니스 사용자, 오류도에게 다양한 데이터를 액세스 (쿼리 및 수정) 할 수
머리가없는 충돌 예를 수행 할 때 ORA-01578, 세션 데이터 파일이 체크 포인트를 손상되는 경우에도, 명령의 실행을 중단되지 않습니다가 발생합니다
--1 인스턴스가 시작되면 일반 데이터 파일, 액세스 또는 머리 손상이없는 경우, 시작 명령은 상태가 탑재하기 시작 할 수 있습니다.
공통 데이터 파일이 손상된 경우 데이터가 더 이상 완료 검사 점 파일 헤더 때문에 --2 런타임 인스턴스가, 체크 포인트가 발생하면,이 데이터 파일의 상태가 자동으로 제어 파일에 설정되지는 오프 예입니다 충돌하지 않는, 경고 로그 검사 점은, 인스턴스가 더 이상 성공할 수 인스턴스를 다시 시작, 파일에 액세스하려고하는 데이터 파일을 ORA-00376 오류를 액세스하기 위해, 조립 라인 오프 오류 로그 파일에 이르는 없기 때문에 ORA-01171 오류가 발생했습니다.
실행될 수없는 데이터 선 명령에 액세스 할 필요가 손상 될 것이다 데이터 파일 블록의 헤더 데이터가 손상되지 않은 정상적인 경우 --3 런타임 인스턴스는, 상기 데이터 파일은 자동으로 로그 오프하지 않다.
시나리오 1 : 존재하지 않는 발견 test01.dbf 일반 데이터 파일을 시작할 때, 마운트 상태로 데이터 블록은 활성화 될 수 있습니다
장면 2 : 시작하는 동안 일반적인 데이터 파일 헤더 test01.dbf의 손상이 발견, DB 상태는 마운트 시작
SQL은> 시작 힘
데이터베이스 탑재.
ORA-01122 : 데이터베이스 파일은 5 꼬리 검증 체크
ORA-01110 : 데이터 파일 5 : /u01/app/oracle/oradata/orcl/test01.dbf
ORA-01210은 : 데이터 파일 헤더가 손상 미디어입니다
오프라인 데이터베이스 데이터 파일 그렇게 test01 데이터 파일을 5 오프라인으로 변경 사용하는 경우, 데이터 test01 데이터 파일은 개봉 후 여전히 열려 액세스 할 수 없습니다 DB
SQL> 변경 데이터베이스 데이터 파일 5 오프라인;
SQL> 데이터베이스 열기를 변경;
--1 테이블 공간에 저장 파티션 정보의 역사에 속하는 데이터 파일을 손상, 온라인 기업은 필요하지 않거나 일시적으로 방문 할 필요가 없습니다
--2 손상된 데이터 파일 또는 테이블 공간은 몇 가지 특정 응용 프로그램에 속하지만 응용 프로그램에서 사용되는 다른 테이블 스페이스의 다른 상대적으로 독립적 인은이 지역의 고 가용성 데이터베이스를 보장하기 위해 서비스를 제공하는 다른 응용 프로그램을 사용할 수 있습니다, 여전히 건강
시나리오 3 : 운전 중 공통 파일 헤더 데이터 손상, 전송 체크 포인트 데이터 파일에 로그를 변경할 때 오프라인 강요 당할 것이다
ORA-01171 : 데이터 파일 5 체크 포인트 발전 에러 오프라인으로 인한 것
ORA-01122 : 데이터베이스 파일 (5) 검증 체크에 실패
데이터 파일 5 : ORA-01110를 /u01/app/oracle/oradata/orcl/test01.dbf
ORA-01210 : 데이터 파일 헤더가 손상 미디어입니다
모든 서비스는 test.t1를 쿼리로 파일 내의 데이터를 액세스 할 수없는
SQL> SELECT * test.t1에서;
: 라인 1에 오류
ORA-00376 : 파일 (5)는이 시간에 읽을 수 없습니다
ORA-01110 : 데이터 파일 5 : /u01/app/oracle/oradata/orcl/test01.dbf를
이번에는 인스턴스를 다시 시작하면 DB가 열려 있지만, 5 호는 데이터 파일을 오프라인에서 여전히 할 수 있습니다, 당신은 수동으로 복원해야합니다.
SQL> 시작 힘;
SQL> 브이 $ 데이터 파일에서 선택 * 어디에 파일 # 개 = 5;
: 라인 1에 오류
ORA-01135 : DML / 쿼리에 대한 액세스 파일 5 오프라인
ORA-01110 : 데이터 파일 5 : /u01/app/oracle/oradata/orcl/test01.dbf
시나리오 4 : 영역 관리 테이블 공간이 LOCAL 인 경우, 런타임시, 데이터 파일 지역 (biimap) 관리 블록이 손상 비트 맵되지 않습니다
SQL> 테이블 T2 (ID 번호)를 테스트 테이블 생성;
ORA-01658 : 테이블 TEST에 세그먼트에 대한 INITIAL 범위를 만들 수 없습니다
시나리오 5 : 읽을 필요의 결과로 실행중인 인스턴스, 테이블, 인덱스, 손상 헤더 부분은, 머리 부분 실패의 수정 작업
SQL> test.t1 (ID, 이름) 알엇에 삽입 (2, 'XXX');
ORA-01578 : ORACLE 손상된 데이터 블록 (# 5 파일, 블록 # 202)
SYS @ ORCL> CONN yhqt / ***
연결됨.
YHQT @ ORCL> yhqtest_1 SELECT * FROM;
yhqtest_1에서 *을 선택
*
1 행에서 ERROR :
ORA-01578 오라클 데이터 블록이 손상 (파일 # 10, # 135 블록)
ORA-01110 : 데이터 파일 10 : '/u01/app/oracle/oradata/orcl/yhqt01.dbf '
시나리오 6 : 배드 블록 데이터를 저장하는 블록 (파일 # 10, # 143 블록)
YHQT @ ORCL> yhqtest_2 SELECT * FROM;
yhqtest_2에서 *을 선택
*
1 행에서 ERROR :
ORA-01578 오라클 데이터 블록이 손상 (파일 # 10, # 143 블록)
ORA-01110 : 데이터 파일 10 : '/u01/app/oracle/oradata/orcl/yhqt01.dbf '
- 자세한 내용은 DSI 데이터 손상 Kuaikuai 물리적 블록과 논리 블록 손상 손상 참조
10.2 백업
RMAN> 압축 백업 세트 테이블 테스트로서 백업;
RMAN-00571 : ============================================== =============
RMAN-00569 : =============== 오류 메시지 스택 ============== FOLLOWS =
RMAN-00571 : ============================================= ==============
RMAN-00558 : 입력을 구문 분석 명령하는 동안 오류가 발생
구문 오류 : RMAN-01009을 중 하나를 예상 : 발견 "테스트" "큰 따옴표 문자열, 식별자, 싱글 -quoted 문자열 "
RMAN-01007 : 행 1 열 (43)에서 파일 : 표준 입력
RMAN> 압축 백업 세트의 테이블 yhqt 같은 백업;
18 7 ~ 19에서 백업을 시작
채널 ORA_DISK_1의 사용
채널 ORA_DISK_1를 풀 백업 데이터 파일 세트를 압축 시작점
채널 ORA_DISK_1 : 백업 세트의 데이터 파일 (들)을 지정하는
입력 데이터 파일의 파일 번호 = 00,010 명 = / U01 / 애플리케이션 / 오라클 / ORADATA / ORCL / yhqt01.dbf의
채널 ORA_DISK_1 : 18 7 ~ 19 조각 (1)을 시동
RMAN-00571 = ================================================== ========
RMAN-00569 : =============== 오류 메시지 스택은 =============== FOLLOWS
RMAN-00571를 : ================================================== =========
RMAN-03009 : 2019년 7월 18일 17시 59분 4초에서 ORA_DISK_1 채널에 백업 명령의 실패
ORA-19566는 : / 파일 / U01 / 응용 프로그램 / 신탁 0 손상된 블록의 제한을 초과 ORADATA / ORCL / yhqt01.dbf
SQL> 브이 $ database_block_corruption SELECT * FROM;
FILE # 블록 # 블록 CORRUPTION_CHANGE # CORRUPTIO
---------- ---------- ---------- ------------ ------ --------
10 135 1 0 골절
5 2,199 9,533,291 CORRUPT 1
5 1 2,207 9,579,846 CORRUPT
5 2,231 9,620,379 1 CORRUPT
RMAN> {실행
데이터 파일 (10) (135)에 대한 설정 maxcorrupt;
백업 테이블 yhqt;
} 2> 3> 4>
SET MAX CORRUPT : 명령 실행
18 7 월 19 일부터 백업
채널 ORA_DISK_1의 사용
채널 ORA_DISK_1을 : 시작 전체 데이터 파일 백업이 설정
채널 ORA_DISK_1 : 백업 세트의 데이터 파일 (들)을 지정하는
입력 데이터 파일의 파일 번호 = 00,010 명 = / U01 / 애플리케이션 / 오라클 / ORADATA / ORCL / yhqt01.dbf의
채널 ORA_DISK_1 : 18 7 ~ 19 조각 (1)을 시동
채널 ORA_DISK_1 : 완료 조각 1 18 7 ~ 19
개 핸들 = / U01 / 애플리케이션 / 오라클 / FRA /ORCL/backupset/2019_07_18/o1_mf_nnndf_TAG20190718T180019_gm0jsmbb_.bkp 태그 = TAG20190718T180019 코멘트 = NONE의
채널 ORA_DISK_1 : 백업 세트 완료, 경과 시간 : 0시 0분 1초
18 7 월 19 일에 백업을 완료
(18) - 7 월 19 제어 파일과 SPFILE 자동 백업을 시작
조각 핸들 = / U01 / 응용 프로그램 / 오라클 / FRA / ORCL / 자동 백업 / 2019_07_18 / o1_mf_s_1013968820_gm0jsndn_.bkp 코멘트 = NONE
완료 제어 파일과 SPFILE 자동 백업 18 7 ~ 19에서
백업 이미지 복제 SYSAUX 테이블 공간
RMAN> 복사 SYSAUX 테이블 스페이스로 백업;
18 7 ~ 19에서 백업을 시작
채널 ORA_DISK_1의 사용
채널 ORA_DISK_1을 : 시작 데이터 파일 복사
입력 데이터 파일의 파일 번호 = 00,002 명 = / U01 / 애플리케이션 / 오라클 / ORADATA / ORCL / sysaux01.dbf
출력 파일명 = / U01 / 애플리케이션 / 오라클 / FRA / ORCL / 데이터 파일 / o1_mf_sysaux_gm0jwl05_.dbf 태그 = TAG20190718T180153 RECID = 2 STAMP = 1,013,968,917
채널 ORA_DISK_1 : 0시 0분 7초 : 데이터 파일이 완료, 경과 시간 복사
18 7 월 19 일에 완료 백업을
18에서 제어 파일과 SPFILE 자동 백업 시작 7 월 19
조각 핸들 = / U01 / 응용 프로그램 / 오라클 / FRA / ORCL / 자동 백업 / 2019_07_18 / o1_mf_s_1013968921_gm0jws37_.bkp 주석 = NONE
완료 제어 파일과 SPFILE 자동 백업 (18) - 7 월 19 일에
위의 명령 RMAN 명령을 실행하면 열린 상태에서 마운트 상태 또는 열린 상태의 데이터베이스는 또한 아카이브 로그 모드를 열 필요가 있음을 확인합니다.
10.3 복구
정상적인 심장 데이터 파일을 복원하려면 : 데이터 파일이 오프라인 백업과 복원 (복원 또는 스위치) 또는 증분 복구 리두 로그의 사용 (명령 복구) 및 라인 그래서 마지막으로 파일
정상 데이터의 주요 기능은 파일의 복구가 개방 상태 데이터베이스 복구 (DB 동안 사용할 수 없음) 상태로 장착 (로컬 사용할 dB)로 복구 DB를 유지할 수있다 수있다. 데이터의 사례 파일 헤더 손상은 특수 처리가 필요할 수 있습니다.
복구 전에 10.3.1 제조
그리고 마운트 상태로 진입 회복 전제 같은 중요한 데이터 파일의 복구가 정상적인 파라미터 제어 파일을 보장한다.
키 데이터 파일 손상 (시스템, 취소) 먼저 중요 데이터 파일을 복원해야합니다.
이 토론의 내용이 일반적으로 매개 변수 파일, 제어 파일, 중요한 데이터 파일을 기반으로하는 경우이다.
열린 상태에서 일반 데이터 파일의 복구, 우리는 먼저 파일이 이미 오프라인 복원되고 있는지 확인해야합니다.
손상된 파일 헤더의 10.3.2 비 복구
언제 까지나 (누락 된 파일을 포함하여) 파일 헤더에 손상이 없기 때문에, 파일은 ORA-01210 오류가 발생하지 않습니다,이 섹션의 단계가 낮은 복구 전략에 사용할 마운트 상태에서 데이터베이스를 복원 할 수 있습니다, 데이터베이스, 조립 라인에서 자동으로되지 않습니다 열린 상태에서 고 가용성을위한 정책을 복원 할 수 있습니다.
--1는 종료 중지를 사용하여 인스턴스를 폐쇄
--2 실행 시작 상태를 탑재하기 시작 탑재
--3 RMAN 복원 (또는 스위치) 정상 데이터 파일의 복구를 수행
아카이브 및 온라인 로그를 사용하여 데이터베이스를 복구하기 위해 RMAN을 통해 데이터를 복원 할 로그 파일을 다시 실행 --4
데이터베이스 열기를 열고 데이터베이스 변경 --5
예를 들어, 데이터 파일을 yhqt01.dbf하려면
--mount 상태 복구
RMAN> {실행
종료 중단을;
시작 마운트;
데이터 파일 '/u01/app/oracle/oradata/orcl/yhqt01.dbf을'복원;
데이터베이스를 복구;
데이터베이스 열기를 변경;}
--open 상태 복구, 예를 폐쇄하지
RMAN> 실행 {
sql'alter 데이터베이스 데이터 파일 (10) 오프라인 ';
복원 10 데이터 파일;
복구 10 데이터 파일;
'sql'alter 데이터베이스 데이터 파일 (10) 온라인;
}
--open 상태, 예를 들면 휴무
RMAN> 실행 {
시작 마운트;
sql'alter 데이터베이스 데이터 파일 (10) 오프라인 ';
데이터베이스 열기를 변경;
복원 10 데이터 파일;
복구 10 데이터 파일;
'sql'alter 데이터베이스 데이터 파일 (10) 온라인;
}
머리 손상 후 10.3.3 파일 복구
데이터 파일 헤더 손상 후뿐만 아니라 오프라인 상태에서 당신은 완료 할 수 없습니다 감소의 결과로,이 파일을 "인식 할 것"이라고 명령 채널을 복원 실행할 때 미래에, 경우. ORA-01210 경고 로그가 나타납니다
장면 : yhqt01.dbf 파일 헤더가 손상되었습니다 후 체크 포인트가 발생했습니다 ORA-01210와 ORA-01171 오류가 알람 로그를 발생, 제어 파일 yhqt01.dbf 파일에 오프라인 상태로 수정되었습니다
사용자 액세스 yhqt 테이블 공간 객체는 ORA-00376을 반환 : 파일 (10)이 시간에 읽을 수 없습니다
제어 파일은 파일이 오프라인 상태임을 나타 내기 때문에 파일을 복원하는 복원 명령이 시점에서 실수로 yhqt01.dbf의 RMAN-06010 에러를 유발, 복원 yhqt01.dbf이 존재 발견, 여전히 yhqt01.dbf 파일 헤더에 액세스 채널,
이 제어 파일의 정보와 일치 여부를 확인하려면, 파일 헤더가 손상되고, 명령이 실패합니다.
해결 방법 :
--1 헤드가 데이터 파일을 손상 삭제, 그래서 파일을 처리 누락로는, 채널 헤더 파일을 확인하려고하지 않습니다
복원 사용 후 온라인 수정 된 데이터 파일과 온라인 ... 데이터베이스 데이터 파일을 변경 DB에 상태를 탑재하고 --2
RMAN> 데이터 파일 (10)을 복원;
ORA-01135 : DM에 대한 액세스 파일 (10) / 쿼리가 오프라인
데이터 파일 : 10 : /u01/app/oracle/oradata/orcl/yhqt01.dbf의 ORA-01110
RMAN-06010 : 오류 찾는 동안 데이터 파일 (10)
删除该数据文件
$ RM /u01/app/oracle/oradata/orcl/yhqt01.dbf의
RMAN은> 10 데이터 파일을 복원;
RMAN> 데이터 파일 (10)을 복구;
SQL> 데이터베이스 열기를 변경;
SQL> 변경 데이터베이스 데이터 파일 (10) 온라인;
그래서 데이터 파일 헤더 손상 복구 단계가 가용성에 대한 낮은 가능한 정책과 전략에 기초해야하고 관련 데이터 파일에 따라 이미 오프라인 구분 세 종류의 총입니다 :
--1 오프라인에서 사용할 수 없습니다 낮은 복구 전략 (온라인, 마운트)
--2 가능한 정책이 조립 라인 낮은 복구 떨어져있다 (오프라인, 마운트)
--3 복구 전략이있다 고 가용성 오프라인 (오프라인 오픈)
주요 단계는 1 회복
--1 오프 중단 인스턴스가 종료를 사용하여
시작 부팅 상태 마운트 마운트 수행 할 --2 인스턴스를
--3 RMAN은 일반적인 데이터 파일을 실행 또는 스위치 복원 복원
--4 RMAN을 실행 로그 파일을 사용하여 데이터베이스를 복구하고 데이터 파일을 온라인 로그를 복원
- -5 데이터베이스를 열려면 열기 데이터베이스를 변경, 복원이 완료
RMAN이> RUN {
종료 ABORT,
시작 마운트,
데이터 파일 (10)을 복원,
데이터베이스를 복구,
데이터베이스 열기를 변경하는 행위}
복구의 주요 단계 2
--1 오프 예를 중단 종료를 사용하여
--2 시작 상태를 마운트 할 마운트
--3, 데이타베이스는 제어 파일 10 개 온라인 파일 상태 데이터를 온라인으로 수정되는 데이터 파일 변경
--4 RMAN> 10 데이터 파일 복구, 데이터 파일을 복원
- RMAN이 5> 데이터베이스를 복구합니다.
--6는 SQL> ALTER 개방형 데이터베이스;
RMAN이> RUN {
종료 ABORT,
시작 마운트,
온라인 데이터베이스 10 'sql'alter는,
데이터 파일 (10) 복원,
데이터베이스 복구,
ALTER 열기 데이터베이스;}
복구의 3 가지 주요 단계
--1 손상이 단계를 생략 머리를하지 않을 경우, 일반 손상된 데이터 파일 헤더를 제거하기 위해 운영 명령을 사용하여
--2 인스턴스가 중지 된 경우, 시작 마운트 상태를 탑재하기 시작 데이터베이스 개방 상태는,이 단계를 무시하면,
--3 오프라인 데이터베이스 (10) ALTER,
그들은 두 번째 단계의 조건을 충족하는 경우 --4, 그렇지 않으면이 단계를 무시 열린 ALTER 데이터베이스를 사용하여 데이터베이스를 열고
, 데이터 파일 (10) 복원> --5 사용 RMAN을
제출과 함께> --6 RMAN을 TABLESPACE를 복구 또는 데이터 파일을 복구 및 파일 복구 데이터를 리두 로그
- 7 10 개 수행 데이터 파일 데이터베이스 온라인 ALTER를,
$의 /u01/app/oracle/oradata/orcl/yhqt01.dbf의 RM을
- 예를 폐쇄하지
RMAN이> RUN {
'오프라인 데이터베이스 데이터 파일 (10) sql'alter을;
10 데이터 파일 복원,
복구 데이터 파일 (10),
sql'alter 데이터베이스 온라인 데이터 파일 10 ';
}
- 예를
RMAN이> RUN {
시작 마운트;
sql'alter 데이터베이스 데이터 파일 (10) 오프라인';
ALTER 개방형 데이터베이스;
복원 10 데이터 파일;
복구 10 데이터 파일;
'sql'alter 데이터베이스 데이터 파일 (10) 온라인;
}