-
1. 회복의 의미
우리는 데이터베이스를 사용할 때 항상 데이터베이스의 내용이 신뢰할 수 있고 정확하기를 바랍니다. 그러나 컴퓨터 시스템 오류(하드웨어 오류, 네트워크 오류, 프로세스 오류, 시스템 오류)는 데이터베이스 시스템의 작동과 정확성에 영향을 미칩니다. 데이터베이스의 데이터를 성적으로 파괴하여 데이터베이스의 데이터 전체 또는 일부를 손실할 수도 있습니다. 따라서 위와 같은 장애가 발생했을 때 완전한 데이터베이스를 다시 구축할 수 있기를 기대하는 과정을 데이터베이스 복구라고 합니다. 복구 하위 시스템은 데이터베이스 관리 시스템의 중요한 부분입니다. 복구 처리는 발생한 장애 유형에 따라 영향을 받는 구조에 따라 다릅니다.
2. 복구 방법
가져오기 방법:
IMPORT를 사용하여 새 데이터베이스로 내보낸 마지막 데이터 파일을 가져옵니다. 이 방법을 사용하면 데이터베이스 개체를 내보냈을 때의 상태로 복원할 수 있으며 이후 변경 사항은 되돌릴 수 없습니다. IMPORT 명령은 대화식으로 실행될 수 있습니다. 각 매개변수의 구체적인 의미는 ORACLE EXP/IMP 매개변수에 대한 자세한 설명을 참조하세요. 이 방법은 아카이브 모드를 사용하지 않는 환경에 적합합니다.
안전한 복구 방법:
데이터베이스가 아카이브 모드로 실행 중인 경우 데이터베이스가 손상되면 콜드 백업(Hot Backup) 및 아카이브 백업을 통해 데이터베이스를 브레이크포인트 상태로 복원할 수 있다.
데이터베이스 제어 파일 복구(모든 제어 파일이 파괴되었다고 가정):
데이터베이스는 파일 시스템을 기반으로 합니다. tar, cp 및 기타 운영 체제 명령을 사용하면 됩니다.
데이터베이스는 원시 장치를 기반으로 합니다: dd if=$ORACLE_BASE/con.bak of=/dev/rdrd/drd1eek=12
데이터베이스 데이터 파일 복구
데이터 및 인덱스 테이블스페이스와 시스템 테이블스페이스 복구:
해당 데이터베이스 파일과 데이터 파일 백업 이후 생성된 모든 논리 로그 파일을 다시 복사하고 다음 명령을 실행합니다.
svrmgrl > 시작 마운트
svrmgrl > 데이터베이스 복구 자동 변경
제어 파일이 손상된 경우 다음을 수행합니다. svrmgrl > 백업 제어 파일을 사용하여 데이터베이스 복구를 변경합니다. 프롬프트에 따라 로그 파일 이름과 리두로그 파일 이름을 입력합니다.
svrmgrl > 데이터베이스 오픈 재설정 로그 변경;
데이터베이스 임시 파일 및 롤백 테이블 공간 복구: 간단히 오프라인으로 삭제하고 다시 구축하세요.
참고: 데이터베이스가 보관 모드에서 실행되지 않는 경우 복구는 마지막 백업 상태로만 복원할 수 있습니다. 아카이브 모드 설정 및 백업 관련 기술에 대한 자세한 내용은 ORACLE 데이터베이스 백업 기술을 참조하세요.
3. ORACLE 테이블스페이스 복구 솔루션
(1) 가구 테이블 공간 오류 현상:
데이터베이스를 시작할 때 ORA-01157, ORA-01110 또는 운영 체제 수준 오류가 발생합니다.
ORA-07360과 같은 오류로 인해 데이터베이스를 종료할 때(정상 종료 또는 즉시 종료 사용) 오류 ORA-01116, ORA-01110 및 운영 체제 수준 오류 ORA-07368이 발생합니다.
해결하다:
아래에는 두 가지 해결 방법이 있습니다.
솔루션 1: 사용자의 테이블스페이스를 쉽게 재구축할 수 있습니다. 즉, 최근에 내보낸 객체를 사용할 수 있거나 테이블스페이스의 객체를 쉽게 재구축할 수 있습니다. 이 경우 가장 쉬운 방법은 오프라인으로 전환하여 데이터 파일을 삭제하고 테이블스페이스를 삭제한 후 테이블스페이스와 모든 개체를 다시 빌드하는 것입니다.
svrmgrl> 시작 마운트
svrmgrl> 데이터베이스 데이터 파일 파일 이름 오프라인 삭제 변경;
svrmgrl> 데이터베이스 열기 변경;
svrmgrl> 내용을 포함하는 tablespace_name 테이블스페이스를 삭제합니다.
테이블스페이스와 모든 객체를 재구축합니다.
해결 방법 2: 사용자의 테이블 공간을 쉽게 재구성할 수 없습니다. 대부분의 경우 테이블 공간을 재구성하는 것은 불가능하고 너무 힘든 작업입니다. 이 방법은 시스템이 NOARCHIVELOG 모드에서 실행 중인 경우에만 수행됩니다. 손실된 데이터는 온라인 리두 로그에서 복구할 수 있습니다.
단계는 다음과 같습니다.
1) 백업에서 손실된 데이터 파일을 복원합니다.
2)svrmgrl> 시작 마운트
3)svrmgrl> v$log v1,v$logfile v2에서 v1.group#,member,sequence#,first_change#를 선택합니다. 여기서 v1.group#=v2.group#;
4) 데이터베이스가 NOARCHIVELOG 모드에서 실행 중인 경우: svrmgrl> v$recover_file에서 file#,change#를 선택합니다.
CHANGE#이 최소 FIRST_CHANGE#보다 크면 데이터 파일을 복원할 수 있습니다.
CHANGE#이 최소 FIRST_CHANGE#보다 작으면 데이터 파일을 복구할 수 없습니다. 가장 최근의 전체 백업을 복원하거나 옵션 1을 사용하세요.
5)svrmgrl> 데이터 파일 파일 이름을 복구합니다.
6) 복구가 성공했는지 확인
7)svrmgrl> 데이터베이스 오픈 재설정 로그를 변경합니다.
읽기 전용 테이블스페이스에 대해서는 미디어 복구를 수행할 필요가 없으며 백업만 복원하면 됩니다. 유일한 예외는 다음과 같습니다.
마지막 백업 후 테이블스페이스가 읽기-쓰기 모드로 변경되었습니다. 이 경우에는 미디어 복구가 필요합니다.
(2) 임시 테이블스페이스 임시 테이블스페이스에는 실제 데이터가 포함되어 있지 않습니다. 복구 방법은 임시 테이블스페이스를 삭제하고 다시 빌드하는 것입니다.
(3) 시스템 테이블스페이스의 백업이 불가능한 경우 데이터베이스를 재구축하는 방법밖에 없다.
(4) 테이블스페이스 롤백에는 두 가지 상황이 있습니다.
1. 데이터베이스가 완전히 종료되었습니다. (즉시 종료 또는 종료 명령 사용)
1) 데이터베이스가 완전히 닫혔는지 확인
2) init.ora 파일을 수정하고 "rollback-segment"를 주석 처리합니다.
3) svrmgrl> 시작 제한 마운트
4) svrmgrl> 데이터베이스 데이터 파일 파일 이름 오프라인 삭제 변경;
5) svrmgrl> 데이터베이스 열기 변경;
나타나는 결과에 따라 "명령문 처리됨"은 (7)로 이동하고 "ORA-00604,ORA-00376,ORA-01110"은 (6)으로 이동합니다.
6) svrmgrl> 즉시 종료
init.ora 파일을 수정하고 다음 줄을 추가합니다: _corrupted_rollback_segments = (<roll1>,...<rolln>)
svrmgrl> 시작 제한
7) svrmgrl> 내용을 포함하는 tablespace_name 테이블스페이스를 삭제합니다.
8) 테이블스페이스 및 롤백 세그먼트 재구축
9) svrmgrl> 시스템 비활성화 제한된 세션을 변경합니다.
10) init.ora 파일 수정
2. 데이터베이스가 완전히 닫히지 않았습니다(데이터베이스가 충돌하거나 shutdown abort 명령을 사용하여 데이터베이스를 닫음).
1) 백업 복원
2) svrmgrl> 시작 마운트
3) svrmgrl> v$datafile에서 파일#, 이름, 상태를 선택합니다.
svrmgrl> 데이터베이스 데이터 파일 파일 이름을 온라인으로 변경합니다.
4) svrmgrl> v$log v1,v$logfile v2에서 v1.group#,member,sequence#,first_change#를 선택합니다. 여기서 v1.group#=v2.group#;
5) svrmgrl> v$recover_file에서 파일#, 변경#을 선택합니다. #해결책 2-4를 참조하세요.
6) svrmgrl> 데이터 파일 파일 이름을 복구합니다.
7) svrmgrl> 데이터베이스 열기 변경;
3. 데이터베이스가 열려 있습니다.
1) 롤백 세그먼트 및 테이블스페이스 삭제
2) 테이블스페이스 및 롤백 세그먼트 재구축(5), 제어 파일 복구
1. 모든 제어 파일이 삭제됩니다. RAW DEVICE(네이키드 장치)의 경우 백업 제어 파일을 복사합니다. dd if='con.bak' of='/dev/rdrd/drd1'eek=128
2. 모든 제어 파일이 삭제되는 것은 아닙니다. 다른 제어 파일을 사용하여 데이터베이스(6)를 시작하고 데이터 블록과 그 안에 있는 데이터를 저장하십시오. 현상: ORACLE 작업을 실행할 때 ORA-1578 오류가 발생합니다. 데이터 블록이 손상되었을 수 있으며 다음과 같은 이유로 발생할 수 있다고 간주합니다.
I/O 하드웨어 또는 펌웨어 손상 운영 체제 I/O 또는 캐시 오류 메모리 또는 페이지 스왑 오류 데이터 파일의 일부가 덮어쓰여졌습니다. 포맷되지 않은 블록 디스크에 액세스하려고 합니다. 수리 기타 원인 해결 방법:
로그 및 추적 파일을 확인하여 다른 오류나 위치 지정 오류가 있는지 확인하세요.
sql>select * from v$datafile 여기서 file#=<F>;
sql> dba_extents에서 소유자, 세그먼트_이름, 세그먼트_유형을 선택합니다. 여기서 file_id=<F> 및 <B>는 block_id와 block_id+blocks-1 사이에 있습니다.
반환된 세그먼트_유형을 기반으로 합니다.
세그먼트 유형이 임시 또는 캐시이거나 반환 값이 없습니다. SQL 문이 올바른지 확인하세요.
세그먼트 유형이 롤백 세그먼트인 경우 데이터 블록을 복원해야 합니다.
세그먼트 유형은 인덱스입니다. 해당 세그먼트가 위치한 테이블을 확인하세요. 인덱스를 다시 작성하면 됩니다.
sql> dba_tables에서 소유자, table_name을 선택합니다. 여기서 Cluster_name = name_of_segment입니다.
오류 1578이 계속 발생하므로 데이터베이스를 복원해야 합니다.
세그먼트 유형은 테이블이며 테이블에 데이터를 저장합니다.
엔터티에 영구적인 데이터 손상이 있는지 분석
sql> 테이블 분석 table.name 구조 계단식 검증;
sql> 테이블 클러스터 이름 분석 구조 계단식 확인;
ARCHIVE 모드에서 실행되는 하드웨어 오류 복구 데이터베이스
오프라인 해당 데이터 파일 복사 백업 데이터 파일
데이터 파일의 이름을 새 위치로 바꿉니다.
아카이브 로그를 사용하여 데이터 파일 복구
온라인 데이터 파일 데이터베이스가 비ARCHIVE 모드에서 실행 중입니다.
OFFLINE해당 데이터 파일은 백업된 데이터 파일을 복사하고, 데이터 파일의 이름을 변경한 후 온라인에 저장합니다.
테이블에 데이터를 저장합니다. 예: sql>select * from bigemp;
오류: ORA-01578: ORACLE DATA 블록이 손상되었습니다(file#8,block#8147) ORA-00110: 데이터 파일 8: '/oracle/usr714.dbf' … … 손상된 파일 ID: 8=8(hex) 손상된 블록 ID : 8147=1fd3(hex) 손상된 블록의 첫 번째 rowid: 0000.1fd3.0000.0008 손상된 블록의 마지막 rowid: 0000.1fd2.7fff.0008 이 블록 이후의 첫 번째 rowid: 0000.1fd4.0000.0008
sql > 1=2인 bigemp에서 select *로 테이블 임시 생성;
sql > 임시 선택에 삽입 * from bigemp /*+rowid(bigemp) */ where rowid >='0000.1fd4.0000.0008';
sql > 임시 선택에 삽입 * from bigemp where rowid <='0000.1fd2.7fff.0008';
ORACLE 7.1 이전 버전에서는 rowid 범위 스캔이 존재하지 않는 경우 인덱싱을 통해 위와 동일한 목적을 달성할 수 있다.
4. 추신
ORACLE의 백업 및 복구 기술은 광범위하고 심오하다고 할 수 있습니다. 저는 그 중 일부만 알고 있으며 그다지 철저하지는 않습니다. 이 기사가 백업에 대한 경험을 공유하는 것도 환영합니다. 문제를 알려주시면 문제 해결에 관심이 있는 모든 DBA 친구와 데이터 관리자가 참고할 수 있도록 정리하여 여기에 게시하겠습니다.
동시에 저는 모든 친구들에게 백업이 매우, 매우, 매우, 매우, 매우, 매우, 매우, 매우, 매우 중요하다는 점을 상기시키고 싶습니다. . . 중요한 것은 가능하다면 ARCHIVE 모드를 사용해야 합니다. 그렇지 않으면 문제가 발생할 수 있으며 울 수도 없습니다.