♣ 매체 장애 유형

매체 장애는 영구적인 것과 일시적인 것의 두 범주로 나누어 진다.

영구적인 매체 장애 - 디스크에 있는 데이터베이스의 영구적인 손실을 일으키는 심각한 하드웨어 문제이다.
일시적인 매체 장애

1. 디스크 제어 장치가 고장났을 경우이다.
디스크제어 장치를 교환하면 디스크상의 데이터를 다시 액세스 할 수 있다.

2. 저장 영역 장치의 전원이 끊어졌을 경우.
전원이 다시 공급되면 저장 영역 장치와 관련된 데이터를 모두 다시 액세스 할 수 있다

♣ 데이터 파일 손실

▶ NOARCHIVE 모드에서 데이터 파일 손실
영구적이거나 일시적인 매체 장애가 데이터 파일에 영향을 줄 경우 오라클은 자동으로 종료한다.

-. 일시적인 매체 장애의 경우
하드웨어 문제를 해결하고 데이터베이스를 재시작. 일반적으로 인스턴스 복구가 가능하며 온라인 리두 로그를 사용하여 커밋된 트랜잭션을 모두 복구할 수 있다.

- 영구적인 매체 장애의 경우
매체 복구 준비 단계 수행 

▶ ARCHIVELOG 모드에서 데이터 파일 손실
- 활성화된 롤백 세그먼트를 포함한 데이터파일이나 SYSTEM테이블스페이스의 데이터파일에 영향을 준 경우 데이터베이스는 작동할 수 없게 되며 오라클이 데이터베이스를 중지 하지 않았다면 즉시 종료.
일반적으로 인스턴스 복구가 가능하며 온라인 리두로그를 사용하여 커밋된 트랜잭션을 모두 복구할 수 있음.

- 영구적이거나 일시적인 매체장애가 위에 언급되지 않은 데이터파일에만 영향을 준 경우 손상된 데이터파일은 사용할 수 없게 되며 오라클은 자동으로 손상된 데이터 파일을 오프라인으로 설정하지만 데이터베이스는 계속 작동할 수 있다.
데이터베이스의 손상되지 않은 부분을 계속 사용하려면 데이터베이스를 종료하지 말라.
먼저 문제가 되는 데이터 파일을 가지고 있는 모든 테이블스페이스를 임시 옵션을 사용하여 오프라인으로 설정.
그후에 열린 데이터베이스,오프라인 테이블스페이스 복구 수행(완전 매체 복구 수행)을 한다. 

♣ 온라인 리두 로그파일 손실

▶ 이중화된 온라인 리두 로그의 온라인 리두 로그 멤버 손실
데이터베이스의 온라인 리두 로그가 이중화되어 있고 각 온라인 리두 로그 그룹 중 적어도 한 멤버가 매체 장애의 영향을 받지 않은 경우 오라클은 정상적으로 작동한다.
(오류 멧시지가 데이터베이스의 LGWR 추적파일과 ALTER파일에 기록)

- 하드웨어 문제가 일시적인 경우 문제를 해결한다.
문제를 해결한후에는 LGWR은 이전에는 사용할 수 없었던 온라인 리두 로그 파일을 액세스한다.

- 하드웨어 문제가 영구적인 경우.
DROP명령을 사용하여 손상된 멤버를 삭제하고 ADD명령어를 사용하여 새 맴버를 추가한다.

▶ 온라인 리두 로그 그룹의 모든 온라인 리두 로그 멤버 손실
매체 장애로 온라인 리루 로그 그룹의 모든 멤버가 손상된 경우 매체 장애의 영향을 받은 온라인 리두 로그 그룹 유형과 데이터베이스의 아카이브 모드에 따라 다른 생황이 발생할 수 있다.
V$LOGFILE에서 파일명을 찾은 후 손실된 파일 상태(비활성화된 상태인지 확인)를 확인하기 위해 손실된 파일에 해당하는 그룹 번호를 찿는다.

SELECT * FROM v$logfile;

GROUP#　　　　　STATUS　　　　　MEMBER
-----------------------------------------------------------------------------------------
0001　　　　　　　　　　　　　　　　　log1
0002　　　　　　　　　　　　　　　　　log2
0003　　　　　　　　　　　　　　　　　log3

SELECT * FROM v$log;

GROUP　　MEMBER　　　STATUS　　　　　　ARCHIVED
-------------------------------------------------------------------------------------------------------------
0001　　　　　1　　　　　　INACTIVE　　　　　　YES
0002　　　　　1　　　　　　ACTIVE　　　　　　　YES
0003　　　　　1　　　　　　CURRENT　　　　　　NO

● 비활성화된 온라인 리두 로그 그룹 손실
-비활성화된 온라인 리두로그 그룹만이 일시적인 매체 장애의 영향을 받았을 경우 문제점을 수정.
LGWR은 필요시 해당 그룹을 재사용할 수 있다.

- 매체 장애로 인해 비활성화된 온라인 리두 로그 그룹에 영구적이로 액세스할 수 없게 되면 손상된 비활성화된 온라인 리두 로그 그룹은 정상 데이터베이스 작업을 중단할 것이다.

데이터베이스가 종료되기 전에 문제를 발견했다면 ALTER DATABASE CLEAR LOGFILE 명령어를 사용한다.

데이터베이스를 이미 종료했다면 다음 작업 수행
.1. 열린 데이터베이스를 SHUTDOWN ABORT하여 데이터베이스 종료.

2. 새인스턴스를 시작하고 데이터베이스를 마운트한다. MOUNT 옵션을 사용

3. 손실된 로그가 아카이브된 경우 ALTER DATABASE CLEAR LOGFILE 명령어 실행

4.손실된 로그가 아카이브되지 않은 경우 ALTER DATABASE CLEAR UNARCHIVE LOGFIEL 명령어를 실행하고 즉시 데이터베이스를 백업한다.
ALTER DATABASE 명령어에 BACKUP COMROLFILE 옵션을 사용하여 데이터베이스의 제어 파일을 백업한다.
아카이브되지 않은 로그를 지우면 아카이브하지 않고도 재사용할 수 있다.
그러나 파일이 로그의 첯 번째 변경 이전에 오프라인으로 설정되지 않았다면 로그의 마지막 변경 전에 사작된 백업은 사용할 수 없다.
따라서 지워진 백업 복구 시 로그 파일이 필요하다면 해당 백업이 복구할 수 없게 된다.
지워진 아카이브되지 않은 로그를 온라인으로 설정하려는 오프라인 데이터 파일이 있다면 UNRECOVERABLE DATAFILE 키워드가 필요하다.
데이터 파일을 온라인으로 설정하는데 필요한 리두로그가 지워지고 복사본도 없으므로 데이터 파일과 해당 테이블 스페이스는 데이터베이스에서 삭제 되어야 한다.

주: ALTER DATABASE CLEAR LOGFILE명령어는 다음과 같은 두가지 경우에 매체 장애로 인한 입출력 오류로 실패할 수 있다.
-현재 구성된 로그 파일 이름으로 로그 파일을 재생성하여 대체 저장 영역장치에 로그 파일의 위치를 재지정 할 수 없을 경우
-이름이 정확하지 않거나 사용할 수 없어 로그 파일을 재생성하기 위해 현재 구성된 로그 파일 이름을 재사용 할 수 없을 경우

위의 두가지 경우 입출력 오류가 발생하기 전에 CLEAR LOGFILE 명령어를 사용하여 로그 파일 상태를 "being cleard"와 "not requiring archiving" 으로 변경하기 위해 제어 파일을 갱신한다.
입출력 오류는 CLEAR LOGFILE 이 새로그 파일 생성을 시도하고 새 로그 파일에 0을 쓰는 단계에서 발생한다.

이 시점에서 다음 명령어를 순서대로 실행하여 복구를 완료할 수 있다.
-새 이름으로 로그 파일을 추가한다.
- 기존 이름의 로그 파일을 삭제한다.

이제 데이터베이스를 열 수 있다.

● 활성화된 온라인 리두 로그 그룹 손실
데이터베이스가 아직 실행 중이고 손실된 활성화 로그가 현재 로그가 아닌 경우 ALTER SYSTEM CHECKPOINT 명령어를 사용할 수 있다.
명령어 성공적으로 실행되면 실제 활성화된 로그는 비활성화 된다.

1. 일시적인 매체 장애인 경우 필요시 오라클이 해당 그룹을 재사용 할 수 있도록 문제 해결

2. 데이터베이스가 NOARCHIVELOG 모드고 영구적인 매체 장애로 활성화된 온라인 리두 로그 그룹에 액세스할 수 없는 경우 데이터베이스를 전체 백업으로 복원
데이터베이스를 복원한 후 RESETLOGS 옵션을 사용하여 작업을 제수행하고 데이터베이스를 연다.
백업 이후에 이루어진 갱신 사항을 손실되었으므로 재실행되어야 한다.
데이터베이스를 종료하고 전에 오프라인 백업을 수행한다.

3. 데이터베이스가 ARCHIVELOG 모드인 경우 불완전 매체 복구 수행해야 한다.
손상된 로그 이전의 로그를 사용하여 복구하는데 대한 내용을 취소에 준한 복구,시간에 준한 복구수행, 변경 사항에 준한 복구 수행에 있는 절차 사용한다.
손실된 리두 로그에 현재 이름이 새로 생성된 온라인 리두 로그 그룹을 새 위치로 이름을 변경하려면 RENAME 명령어를 실행한다.

4. RESETLOGS 옵션을 사용하여 데이터베이스를 연다.

주: 불완전 복구가 끝난 시점부터 현재까지 실행된 모든 갱신 사항은 재실행되어야 한다

▶ 여러 리두 로그 그룹 손실
가장 어려운 것에서 가장 쉬운 것까지 어려움의 정도는 다음과 같다.
1. 현재 온라인 리두 로그
2. 활성화된 온라인 리두 로그
3. 아카이브되지 않은 리두 로그
4. 비활성화된 온라인 리두 로그 

♣ 아카이브된 리두 로그 파일 손실

데이터베이스가 작동하고 있어 채워진 온라인 리두로그 그룹이 아카이브되고 있는데 아카이브된 리두 로그 파일이 유일한 복사본이 손상되었다고 하더라도 데이터베이스의 현재 작업에는 영향을 주지 않는다.
그러나 추후에 매체 복구가 필요한 경우 다음과 같은 상황이 발생할 수 있다.

- 현재 아카이브된 채워진 온라인 리두 로그 그룹이 기록된 후 모든 데이터 파일이 백업되면 채워진 온라인 리두 로그 그룹이 아카이브된 버전은 완전 매체 복구 작업이 필요하지 않다.

- 채워진 온라인 리두 로그 그룹이 기록되기 전에 데이터파일의 최근의 백업 파일이 만들어 졌다고 한다.
이제 그룹은 손상된 아카이브된 리두 로그 파일에 해당한다.
미래의 한 시점에서 해당 데이터 파일은 영구적인 매체 장애로 손상되었다.
손상된 데이터 파일의 최근 백업이 사용되어야 하며 불완전 매체 복구는 데이터베이스를 손상된 아카이브된 리두 로그 파일까지만 복구한다.

- 시간에 준한 복구가 필요한 경우나 원래의 온라인 리두로그 그룹이 기록되기 전에 만들어진 기존 데이터 파일 백업을 사용할 경우에 손상된 아카이브된 리두로그 파일이 필요하다.
이 경우 불완전 매체 복구를 사용하면 손상된 아카이브된 리두 로그 그룹까지만 데이터베이스를 복구 할 수 있다. 

♣ 제어 파일 손실

제어 파일의 이중화 여부에 관계없이 매체 장애로 인해 데이터베이스의 제어 파일이 손상된 경우 오라클 백그라운드 프로세스가 처음으로 제어 파일에 액세스할 때까지 데이터베이스는 실행을 계속한다.
이 시점에서 데이터베이스와 인스턴스는 자동으로 종료된다.

매체 장애가 일시적인 것이며 데이터베이스가 아직 종료되지 않은 경우 즉시 매체 장애를 해결하여 데이터베이스가 자동으로 종료되는 것을 막을 수 있다.
그러나 일시적인 매체 장애가 해결되기 전에 데이터베이스가 종료된 경우 문제를 해결한 후 데이터베이스를 재시작 할 수 있다.

영구적으로 데이터베이스 제어파일을 액세스 하지 못하게 하는 매체 장애에 대한 적합한 복구 절차는 제어 파일이 이중화되어 있는 지의 여부에 달려 있다.

▶ 이중화된 제어 파일 맴버 손실
영구적인 매체 장애로 데이터베이스의 하나 이상의 제어 파일이 손상되고 적어도 한 제어 파일이 매체 장애에 의해 손상되지 않은 경우.

제어 파일이 손상된 후에 데이터베이스복구
1. 인스턴스가 아직 실행중일 때는 SHUTDOWN ABORT명령을 하여 즉시 현재 인스턴스 사용 중지한다.

2. 매체 장애를 일으킨 하드웨어 문제 해결
하드웨어 문제가 빨리 해결될 수 없는 경우 손상된 제어 파일을 대체 저장 영역 장치에 복원하여 데이터베이스를 계속 복구한다.

3. 손상되지 않은 데이터베이스의 제어 파일의 복사본을 손상된 제어 파일에 복사한다.
가능하다면 손상되지 않은 제어 파일을 모든 손상된 제어 파일의 원래 위치로 복사한다.
하드웨어 문제가 해결되지 않으면 손상되지 않은 제어 파일을 대체 위치에 복사한다.
모든 손상된 제어 파일을 원래 위치에 복원했다면 5단계를 수행한다.
손상된 제어 파일이 모두 복원되지 않았거나 원래 위치로 복원되지 못한 경우에는 4단계 수행한다.

4. 손상된 제어 파일이 모두 복원되지 않았거나 3단계에서 원래위치로 복원되지 못한 경우 CONTROL_FILES 매개변수가  모든 제어 파일의 현재 위치를 반영하고 복원되지 않은 모든 제어 파일을 배제하도록 데이터베이스의 매개변수 파일을 편집해야 한다.

5. 새 인스턴스를 시작하고 데이터베이스를 마운트하여 연다.

▶ 현재 제어 파일의 모든 복사본 손실
영구적인 매체 장애로 데이터베이스의 모든 제어 파일이 손실되거나 손상되었지만 모든 온라인 리두 로그 파일이 손상되지 않은 상태로 있을 경우 CREATE CONTROLFILE 명령어에 NORESETLOGS 옵션을 사용하여 새 제어 파일을 생성함으로써 복구할 수 있다.
그런 다음 ALTER DATABASE OPEN을 실행시킨후 RECOVER DATABASE를 실행한다.

다음 옵션을 사용하여 제어 파일 백업의 존재나 현재성에 따라 CREATE CONTROLFILE명령어의 텍스트를 생성할 수 있다.

-데이터베이스의 구조를 마지막으로 변경한후 ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS를 실행하고 SQL명령어를 출력을 저장한 경우 출력이 있는데로 CREATE CONTROLFILE 명령어를 사용할 수 있다.
그러나 ALTER DATABASE BACKUP CONTROLFILE TO TRACE를 최근에 실행한 때가 데이터베이스의 마지막 구조 변경 이전인 경우 구조 변경 사항을 반영하도록 ALTER DATABASE BACKUP CONTROLFILE TO TRACE의 출력을 편집해야 한다.

- TO TRACE 옵션을 사용하여 제어 파일을 백업하지 않았지만 대신 ALTER DATABASE BACKUP CONTROLFILE 명령어에 TO filename 옵션을 사용한 경우 SQL 명령어의 출력을 얻기 위해 제어 파일의 복사본을 사용할 수 있다.
이것은 ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS를 실행하기 전에 제어 파일을 복사하고 STARTUP MOUNT를 실행하여 수행할 수 있다.
제어 파일의 복사본이 최근의 구조 변경 일자보다 앞선 경우 구조 변경 사항을 반영하도록 TO TRACE 출력을 편집.

- TO TRACE 형식이나 TO filename 형식 중 어떤 형태로도 제어 파일 백업이 없는 경우 CREATE CONTROLFILE명령어를 수동으로 설정해야 한다. 

♣ 사용자 오류 복구

1. 기존의 손상되지 않은 데이터베이스를 백업한다.

2. 기존 데이터베이스는 그대로 두고 시간에 준한 복구를 사용하여 사용자 오류전의 상태로 데이터베이스의 임시 복사본을 재구축한다.

3. 재구축된 데이터베이스의 임시 복사본에 손실되거나 훼손된 복사본을 엑스포트한다.

4. 손실되거나 훼손된 데이터를 영구 데이터베이스로 임포트한다.

5. 디스크 영역을 절약하기 위해 재구축한 임시 데이터베이스의 복사본과 연관된 파일을 삭제한다.