[Oracle] Chapter 9. REDO와 UNDO의 동작

9.1 REDO와 UNDO를 왜 배워야 하는가?

 

트랜잭션이 가지고 있어야 하는 특성에 'ACID'라는 것이 있다. 이 특성을 구현하기 위해서 REDO와 UNDO는 빠질 수 없으므로 이들을 배울 필요가 있다. REDO와 UNDO에 대한 설명에 들어가기 앞서 ACID 특성이 대체 무엇인지 먼저 살펴보자.

 

9.1.1 A(Atomicity): 원자성

 

트랜잭션에 포함된 데이터의 변경은 '전부 OK'이거나 '모두 NG'라는 'all or nothing'을 말한다. DBMS는 수행 중인 트랜잭션에서 데이터를 일부만 변경하고 나머지는 수행하지 않은 채 커밋할 수 없다. 예를 들어, 어떤 트랜잭션에서 A 계좌에서 출금하고 B 계좌에 입금했을 떄 '출금은 기록됐지만 입금은 기록되지 않았다'는 상황이 발생하면 곤란하다. 원자성은 이런 일이 일어나서는 안된다는 의미이며, 트랜잭션은 더 이상 분리할 수 없는 데이터 변경을 위한 최소 단위이다.

 

9.1.2 C(Consistency): 일관성

 

트랜잭션에 의해 데이터 간의 일관성이 어긋나서는 안 된다는 의미이다. 일관성이 어긋나는 예로는 '고객 개인의 데이터는 변경되었는데, 고객 전체의 통계 데이터는 변경되지 않았다'와 같은 것들이 있다.

 

9.1.3 I(Isolation): 고립성

 

트랜잭션끼리는 고립(분리)되고 독립되어 있다는 의미이다. 어떤 트랜잭션을 단독으로 실행했거나 다른 트랜잭션과 동시에 실행했더라도 결과는 같아야(다른 트랜잭션을 의식할 필요가 없다) 한다는 것이다. 단, DBMS에 따라서는 어느 정도 고립시킬 것인가에 대한 레벨을 선택할 수 있다.

 

9.1.4 D(Durability): 지속성

 

커밋한 트랜잭션은 장애가 발생하더라도 데이터는 반드시 복구되어야 한다는 의미이다. ACID의 특징을 간략하게 정리해보면 다음과 같다.

 

- 장비가 꺼지더라도 커밋한 데이터는 복구할 수 있어야 한다.

- 어중간한 데이터 변경은 안된다.

- 트랜잭션 단위로 변경(또는 롤백)되어야 한다.

- 다른 트랜잭션과 동시에 실행하든 단독으로 실행하든 결과는 같아야 한다.

 

9.2 지속성을 구현하기 위해서는

 

우선은 데이터베이스의 중요한 특징인 '커밋한 데이터를 지키는 특성(지속성)'을 어떤식으로 구현하였는지 생각해보자. 지속성을 구현하기 위해서는 커밋한 데이터를 그 즉시 디스크에 기록하면 될 것 같아 보인다.

 

하지만 여기서 떠올렸으면 하는 부분이 바로 1장에서 설명했던 디스크의 특성이다. 첫머리를 찾는 시간이 디스크 I/O 시간의 대부분을 차지하고 있다. 이 방법으로는 대량의 데이터를 변경하면 커밋하는 데 너무 많은 시간이 걸린다.

 

그래서 상용 RDBMS 대부분은 로그(변경 로그)를 채용하여 성능과 지속성을 양립시킬 수 있게 하였다. 오라클도 마찬가지로 REDO 로그를 통해서 성능과 지속성을 확보했다. 어떻게 REDO 로그에 의해서 성능이 확보되느냐 하면, REDO 로그에 데이터를 한꺼번에 기록하는 것으로 I/O의 횟수가 줄어들고, 시퀀셜 액세스를 사용하여 I/O에 소모되는 시간을 줄였기 떄문이다. 또한, I/O 크기는 커지지만, 첫머리를 찾아가는 작업의 횟수는 변하지 않으므로 I/O 시간이 지연되지 않는다.

 

9.3 REDO와 UNDO의 개념

 

REDO와 UNDO의 개념을 이해하는 것은 쉬운 일이 아니다. 그래서 개념을 이해하기 위해 '가상 세계'와 '시간의 신'을 예로 들어 생각해보겠다. 이 가상 세계에서는 필요에 따라 시간을 되돌릴 수 있다. 또한, 가상 세계 안에 문제가 발생하여 정보가 손상되면, 시간의 신이 가상 세계를 다시 과거로 되돌려야 하는 경우도 있다. 이 가상 세계 안의 '시간의 신'에게 필요한 정보는 무엇일까? 우선은 가상 세계가 유실되었을 때 최신 상태까지 복구하기(시간을 흐르게 하기) 위한 정보가 필요하다. 몆 가지 방법이 있겠지만, '어떤 시점의 가상 세계 정보 + 가상 세계의 변경 정보(누가 무엇을 했다)'가 있다면 최신 상태까지 복구할 수 있을 것이다. 예를 들어, 어제부터 오늘까지 시간을 흐르게 하려면 누가 무엇을 했는지와 같은 정보를 사용해서 어제의 가상 세계 정보를 오늘의 정보로 바꾸어 가는 것으로 구현할 수 있다. '누가 무엇을 했는지'와 같은 정보만으로는 현재 상태에서 과거의 상태로 시간을 되돌릴 수 없다. 예를 들어, '오늘 A군이 학교에 갔다'와 같은 정보만으로는 A군이 학교에 가기 전에 어디에 있었는지 알 수 없으므로 학교에 가기 전의 시간으로 되돌릴 수 없다. 이를 위해서는 '어떻게 해야 과거의 상태로 되돌아갈 수 있는가?'라는 정보도 필요하다. 이 가상 세계가 데이터베이스에 해당하고, '누군가가 무엇을 했다는 정보'가 REDO로그, '어떻게 하면 과거의 상태로 돌아갈 수 있는지에 관한 정보'가 UNDO 정보이다. REDO 로그를 사용해서 과거의 데이터를 최신 데이터 쪽으로 흐르게 하는 것을 '롤 포워드(roll-forward)'라고 한다. 반대로, UNDO의 정보를 사용해서 변경을 취소(과거의 상태로 되돌린다)하는 것을 '롤백(rollback)'이라고 한다.

가상 세계의 시간에 해당하는 것이 오라클에도 존재한다. 그것은 'SCN(System Change Number)'이라는 것으로, 오라클 내부의 시간(정확히는 시간이 아닌 번호)을 나타낸다. 복구 등에 사용되므로 SCN이라는 단어와 그 의미를 기억해두도록 하자. 

 

9.4 REDO의 구조

 

데이터 변경은 캐시에서 이루어진다. 그떄 REDO 로그(변경 이력 데이터)라고 불리는 로그 데이터가 생성된다. 여기서 주목할 점은 블록의 데이터가 이 시점(커밋되지 않은 시점)에 변경된다는 점이다.

 

1 : 오라클 클라이언트 -> 1에서 2로 변경하는 UPDATE문 -> 서버 프로세스

2 : 서버 프로세스 -> REDO 로그와 UNDO를 서버 프로세스가 생성함. 아울러 캐시에 있는 블록의 데이터를 변경함 -> REDO로그 버퍼, 버퍼캐시

3: 서버 프로세스 -> UPDATE 종료의 통보 -> 오라클 클라이언트

 

오라클은 REDO 로그를 커밋이 발생하기 전에 디스크에 기록하는 방식으로 지속성을 구현했다. 단, 앞에서도 설명했듯이 성능에 단점이 있으므로 커밋하는 시점에 연동해서 데이터 블록을 기록하려고는 하지 않는다.

그러면 REDO 로그의 구조는 어떻게 되어 있을까? REDO 로그용 메모리로서 REDO 로그 버퍼가 공유 메모리에 존재한다. REDO 로그를 디스크에 REDO 로그 파일로 기록하는 것은 LGWR이라고 불리는 프로세스가 수행한다. 또한, REDO 로그 파일은 개수가 한정(일반적으론 한 세트에 3개)되어 있으며, 크기도 제한되어 있으므로 REDO 로그를 계속 보관하고 있을 수는 없다. 그래서 아카이브 REDO 로그 파일이라는 오랫동안 REDO 로그를 보관해두기 위한 파일이 존재한다. REDP 로그 파일은 REDO 로그의 일시적인 보관 창고이며, 아카이브 REDO 로그 파일이 오랜 시간 보관할 수 있는 본격적인 보관 창고이다. 다만, 데이터베이스의 백업을 받으면 백업을 시작한 시점 이전에 만들어진 아카이브 REDO 로그는 필요하지 않는다.

 

1: 서버 프로세스가 REDO 로그 버퍼에 REDO 로그를 넣음

2: LGWR은 서버 프로세스의 의뢰를 받거나, 또는 자발적으로 REDO 로그를 REDO 로그 버퍼에서 REDO 로그 파일에 기록함

3: ARCH 프로세스가 아카이브 REDO 로그 파일에 옮김

 

REDO 로그 파일은 매우 중요한 파일이므로 반드시 다중화해야 한다. 일반적으로 REDO 로그 그룹을 여러 개의 세트로 만들고, 그룹 안에 멤버(REDO 로그 파일)를 추가한다. 다중화하면 '그룹이 늘어난다'고 생각할 수 있지만, 실제로는 그룹이 아닌 '멤버'가 늘어나기 떄문에 예쌍했던 내용과 다른 형태의 다중화가 될 수 있으므로 신경을 써야 한다.(그룹은 REDO를 순차적으로 기록하기 위한 파일이다. 필수로 최소 2개 이상을 만들어야 하고, 순차적으로 순환하여 사용한다. 그리고 멤버는 REDO의 복사본을 저장하기 위한 파일이다. 안정성을 위해 멤버별로 다른 스토리지에 저장하는 것을 권한다.)

 

프로세스 수준에서의 동작을 설명하자면, 서버 프로세스는 커밋했을 때 LGWR 프로세스에 REDO 로그를 기록하도록 요청한다. 요청을 받은 LGWR 프로세스는 REDO 로그를 REDO 로그 파일에 기록한다. 기록이 끝나면 LGWR 프로세스가 서버 프로세스에 기록이 끝났다고 통보한다. 그 후에 서버 프로세스는 커밋이 끝난 것을 오라클 클라이언트에게 통보한다.

실은 스태츠팩(또는 AWR)이나 V$SESSION_WAIT 등에서 자주 볼 수 있는 'log file sync'라는 대기 이벤트는 주로 LGWR이 REDO 로그를 기록하는 것을 기다리고 있는 것이다. 일반적으로 항상 발생하는 필요한 대기 이벤트이므로 기다리는 시간이 허용 범위 내라면 튜닝을 하지는 않는다. 어떻게든 시간을 단축하고 싶다면(가능하다면), 커밋 횟수를 줄이거나 write 캐시(스토리지의 write 캐시란, 기록하는 I/O를 위한 캐시이다. 일반적으로 오라클의 write는 디스크에 기록되기 전까지는 I/O가 끝나지 않지만, write 캐시가 있다면 write 캐시에 기록하는 것으로 I/O가 끝난다. 따라서 기록하는 I/O의 응답 시간이 빨라지게 된다.)를 가진 스토리즈를 사용하는 방법 등이 있다. 또한, REDO 로그에 관련한 처리 과정들은 앞 장에서 설명했던 Latch가 보호하고 있다. 스태츠팩(또는 AWR)등에서 'redo copy'나 'redo allocation'등으로 표시되는 Latch가 REDO 로그를 위한 Latch이다.

 

9.4.1 REDO의 요약

 

여기서 1장에서 설명했던 오라클을 이해하기 위한 키워드 세 가지가 충족되었다는것을 눈치챈 분들도 계실 것이다.

◆ 병렬 처리를 가능케 하고 높은 처리량을 실현

기본적으로 여러 개의 서버 프로세스는 데이터를 동시에 변경할 수 있다(단, 같은 데이터는 제외). REDO 로그를 기록하는 데에서도 LGWR은 여러 서버 프로세스의 REDO 로그를 한꺼번에 기록하기 떄문에 높은 처리량을 구현할 수 있다.

◆ 응답 시간(response time)을 중시

커밋할 때 블록을 디스크에 기록하지 않고 REDO 로그에 기록하는 것으로 빠른 커밋을 구현할 수 있다.

◆ 커밋(COMMIT)한 데이터는 지킴

장비에 장애가 발생하여 DBWR이 데이터를 기록할 틈도 없었다고 가정하더라도 그후에 REDO 로그와 데이터 파일에 남아 있는 오래된 데이터를 사용해서 데이터를 복구(롤 포워드)할 수 있다.

 

9.5 UNDO의 구조

 

예전의 데이터로 되돌리기 위한 데이터인 UNDO(롤백 세그먼트라고도 말한다)에 관해 설명하겠다.

데이터가 변경되면 UNDO 정보가 생성되며, 생성된 UNDO 정보는 세그먼트에 보관된다. 세그먼트에 보관된다는 점으로 인해 UNDO 정보가 테이블스페이스들 중 어딘가에 보관된다는 사실을 알 수 있다. UNDO 정보가 보관되는 테이블스페이스를 UNDO 테이블스페이스라고 부른다. UNDO 테이블스페이스에는 여러 개의 UNDO 세그먼트가 생성된다. 기본적으로 트랜잭션과 UNDO 세그먼트가 일대일로 대응하기 떄문이다.

UNDO 세그먼트는 링 버퍼(ring buffer)이다. 링 버퍼는 조금 지나면 데이터가 덮어쓰이는 버퍼이지만, 커밋하지 않은 데이터는 덮어써지지 않는다. 덮어쓰지 못하고 UNDO 세그먼트가 가득 차면 UNDO 세그먼트가 커진다.

undo_retention이라는 파라미터 등으로 UNDO 정보의 유지 시간을 설정할 수 있다. UNDO 정보를 커밋한 이후에도 일정 시간 유지하고 싶을 떄 유용한 파라미터이다.

 

9.6 여러 상황에서 REDO와 UNDO의 동작

 

9.6.1 롤백할 떄의 동작

여기까지 설명한 것처럼 오라클에서는 커밋하지 않았더라도 데이터베이스의 데이터는 이미 변경된 상태이다. 롤백이 수행된다면 UNDO에 보관된 정보를 사용해서 데이터를 원래의 값으로 되돌린다.

서버 프로세스가 비정상적으로 종료(여기서 말하는 비정상 종료에는 ORA 에러를 발생시키며 종료된 경우 외에도 kill 명령어 등에 의해 프로세스가 비정상 종료된 경우도 포함된다.)했을 떄도 PMON이라고 불리는 백그라운드 프로세스가 정기적으로 체크를 수행하며, 종료된 서버 프로세스를 정리해준다. 또한, SMON이라고 불리는 백그라운드 프로세스가 데이터를 트랜잭션 시작 전의 상태로 되돌려준다.

 

9.6.2 읽기 일관성에 동반되는 동작

읽기 일관성이란, 데이터를 검색할 떄 어떤 시점의 데이터를 보여주는 기능을 말한다. 예를 들어, 검색을 시작한 후에는 다른 세션에서 변경한 데이터를(커밋을 했더라도) 읽지 못하게 하고, 검색 중에는 계속해서 검색을 시작한 시점의 데이터를 보여주는 것을 말한다.

이런 읽기 일관성을 위해서 UNDO를 사용하고 있다. 읽기 일관성은 데이터가 변경된 시점을 확인하고, 검색을 시작한 후에 변경된 데이터일 때는 UNDO를 사용해서 과거의 데이터를 메모리 위해 재현한다.

 

9.6.3 커밋되지 않은 데이터를 읽어올 떄의 동작

오라클에서는 기본적으로 고립성(isolation)을 지키기 위해 'read committed'라는 동작을 하도록 설정되어 있다. 이는 '다른 세션에서 커밋한 변경 데이터는 읽을 수 있다'는 특징을 가지고 있다.(트랜잭션 고립화 수준(transaction isolation level)의 기본 설정이 높지 않다는 점을 눈치챈 분들도 있을 것으로 생각한다. 하지만 많은 시스템이 성능과 편리함 떄문에 이 방식을 사용하고 있다.) 그러나 다른 세션에서 커밋되지 않은 변경 데이터는 읽어올 수 없다. 커밋되지 않은 다른 세션의 데이터를 읽어올 떄도 일기 일관성과 마찬가지로 변경되기 이전의 데이터를 보여주며, 필요할 떄는 UNDO를 사용해 과거의 데이터를 메모리 위에 재현하는 방식으로 구현한다.

 

9.6.4 ORA-1555 에러가 발생했을 때의 동작

이 에러는 '과거의 데이터를 보려 했으나 필요한 정보가 이미 없어졌다'라는 것을 의미한다. 대부분은 시간이 오래 걸리는 검색을 수행할 떄 UNDO의 정보가 덮어써진것이 원인이다.

예를 들어, 데이터를 검색하는 데 24시간이 걸릴 때 검색을 시작하고서 1시간 뒤 다른 세션이 어떤 데이터를 변경하고 커밋했다고 가정하겠다. 그리고 몆 시간 후에 '해당 데이터에 관한 UNDO 정보가 덮어써져 사라졌다'고 가정하자. 그 후에 검색을 시작하고 20시간이 지난 후 데이터가 변경된 부분을 읽기 시작 했을 때, 오라클은 데이터가 변경도었으므로 검색을 시작했을 떄의 데이터를 재현하려고 한다. 하지만 UNDO 정보가 없어져 필요한 데이터를 재현해서 가져올 수 없으므로 ORA-1555(snapshot too old)라는 에러가 발생하며 검색에 실패한다.

 

에러가 발생하지 않도록 하기 위해서는 UNDO 정보를 좀 더 길게 유지할 수 있도록 설정해야 한다. 초기화 파라미터 undo_retention을 사용해서 UNDO 보존 기간의 하한값을 지정할 수가 있지만, 이 파라미터는 UNDO 테이블스페이스의 자동 확장 기능(autoextend)이 ON으로 되어 있을 때만 유효하다. undo_retention을 설정하고 싶을 때는 UNDO 테이블스페이스의 자동 확장 기능을 ON으로 변경하고, 필요하다면 MAXSIZE 값을 설정해주자. 또한, UNDO 테이블스페이스가 부족할 때는 undo_retention에서 지정한 시간보다 적더라도 UNDO 정보가 삭제된다. 따라서 v$undostat의 정보를 토대로 UNDO가 10분 동안 얼마나 생성되는지를 파악한 후, undo_retention을 크게 했을 경우에 UNDO 테이블스페이스가 감당할 수 있는지를 검토하고 값을 변경해야 한다.

 

9.6.5 체크포인트의 동작

체크포인트는 메모리의 데이터를 디스크와 동기화하는 작업을 말한다. 구체적으로 애기하면 DBWR이 데이터를 메모리에서 디스크로 기록한다.

REDO 로그와 예전 데이터가 있다면 롤 포워드는 할 수 있지만, 너무 오래된 데이터를 기점으로 롤 포워드하려면 많은 시간이 필요하다. 따라서 체크포인트를 통해 데이터를 디스크에 정기적으로 기록하고 롤 포워드에 걸리는 시간을 단축한다. 체크포인트는 파라미터를 통해 제어할 수는 있지만 1장에서 설명했던 것처럼 디스크에 비넙ㄴ하게 기록하면 병목 현상이 발생해서 성능이 안 좋아질  수 있으므로 너무 빈번하게 기록하지 않도록 설정하는 것이 바람직하다.

성능을 향상하기 위해 메모리를 잘 이용하고, 데이터를 보증하기 위해 디스크상의 데이터를 사용한다는 점을 잘 이해해야한다.

 

9.6.6 인스턴스 복구 시의 동작

컴퓨터는 장애가 돌발적으로 발생할 수 있다. 그때 오라클은 어떻게 데이터를 복구할까?

장애가 발생한 컴퓨터의 데이터 파일에는 조금 오래된 데이터밖에 없을 것이므로 REDO 로그가 활약한다. 오라클은 데이터 파일에 REDO 로그를 적용하고 데이터를 최신 상태로 갱신한다. 이때 커밋하지 않은 데이터를 어떻게 처리할지 막막해 보인다. 왜냐하면 REDO 로그 파일에는 커밋하지 않은 REDO 로그의 내용도 함께 기록 되어 있기 떄문이다. 하지만 커밋하지 않은 트랜잭션은 REDO 로그에도 커밋 정보가 존재하지 않는다. 따라서 UNDO 정보를 사용해서 커밋 정보가 존재하지 않은 트랜잭션들을 구분해내어 롤백 처리를 수행한다. 이런 부분에서 오라클이 원자성을 제대로 지키고 있음을 알 수 있다.

 

여기서 'UNDO는 테이블스페이스에 보관되어 있으니까 디스크에 실시간으로 기록하지 않는 거 아닌가?'라는 의문을 가지는 분들도 있을 것으로 생각한다, 실은 UNDO가 변경되는 정보 역시 REDO 로그에 들어가 있기 때문에 롤 포워드함으로써 UNDO를 최신 상태로 만들 수 있다. 오라클은 기동할 떄 이런 방식으로 자동 수행되는 복구를 '인스턴스 복구(instance recovery)'라고 부른다. 정식 명칭은 '충돌 복구(crash recovery)'이지만, '인스턴스 복구'가 더 많이 알려져 있다.

 

1: 우선은 REDO 로그를 사용해서 데이터의 시간을 흐르게 함(롤 포워드). 대상에는 SYSTEM 테이블스페이스나 UNDO 테이블스페이스도 포함됨

2: UNDO 세그먼트도 최신 상태가 되었기 떄문에 UNDO 정보를 사용해서 롤백할 수 있음. 커밋하지 않은 것은 롤백함

 

인스턴스 복구를 조금이라도 더 빠르게 하고 싶으신 분도 있을 것이다. 그떄는 체크포인트가 적절한 빈도로 수행되도록 설정해라. 또한, 데이터베이스가 ABORT에 의해 정지한 후 다시 기동할 떄도 인스턴스 복구가 수행되므로 가급적이면 ABORT를 사용한 정지는 피해야 한다.

 

9.7 요약

 

- REDO는 오래된 데이터를 최신 데이터로 만들기 위해 존재한다.

- UNDO는 최신 데이터를 오래된 데이터로 만들기 위해 존재한다.

- 읽기 일관성을 위해 UNDO를 사용한다.

- ORA-1555가 발생할 때는 우선 undo_retention이나 UNDO 테이블스페이스의 크기를 튜닝할 것을 검토하며, 장시간 수행되는 SQL문으로 인해 발생한다면 애플리케이션의 개선도 필요할 수 있다.

- 장비에 장애가 발생하거나 인스턴스가 비정상 종료했을 떄는 REDO와 UNDO를 사용해서 데이터를 복구하고, 커밋하지 않은 데이터의 롤백을 수행한다.

 

칼럼

멀티테넌트 아키텍처

 

오라클 12c R1부터 제공되는 멀티테넌트 아키텍처(Multi-Tenant Architecture, MTA)를 들어 본적이 있으신가요?

 

12c에서 주요 기능 중 하나로 발표되었기 때문에 이미 들어본 분들도 계실 것이다. 간단히 설명하면 클라우드 시대에 발맞추어 발표된 여러 개의 데이터베이스를 관리하면서도 시스템의 독립성을 확보하고, 운영 비용을 절감하기 위한 새로운 시스템 아키텍처이다.

 

여기에는 여러 개의 업무용 데이터베이스와 그것을 관리하는 관리 데이터베이스가 존재한다. 관리 데이터베이스는 어디까지나 관리를 목적으로 하며, 소속되어 있는 여러 업무 데이터베이스가 지금까지 해왔던 대로 각 시스템의 애플리케이션 등에서 커넥션을 받아 데이터 처리를 수행한다.

 

또한 백업/복구, 업그레이드나 패치의 적용과 같은 기본적 관리를 관리 데이터베이스를 경유해서 내부적으로 수행할 수 있으므로 데이터베이스를 관리하기 위한 운영 비용이 절감된다는 장점도 존재한다.

 

앞서 설명한 관리 데이터베이스에 해당되는 것이 CDB(Container DataBase, 컨테이너 데이터베이스), 업무용 데이터베이스에 해당하는 것이 PDB(Pluggable DataBase, 플러거블 데이터베이스)이다.

 

CDB는 데이터베이스 전체에 공유하는 오브젝트와 메타데이터를 관리한다. 반면 PDB는 지금까지 해왔던 대로 애플리케이션에서 접속하는 데이터베이스이며, 각각의 데이터를 가지고 있다. 접속하는 애플리케이션 측에서는 데이터베이스를 PDB라고 따로 신경 쓸 필요 없이 지금까지 해왔던 것처럼 사용하면 된다.

 

프로세스나 메모리와 같은 자원은 공유하지만, 사용자 데이터는 개별로 저장하는 아키텍처이므로 자원을 효율적으로 활용하고, 데이터의 독립성을 유지할 수 있다.

 

용어

디스크가 꺠지다, 복원하다, 복구하다.

 

● 디스크(또는 파일)가 꺠지다

디스크나 파일이 손상되어 사용할 수 없는 상태를 뜻한다. 물리적인 손상이 발생된 경우에는 백업받은 파일로부터 복원과 복구가 필요하다.

● 복원하다

백업 파일이 저장된 미디어로부터 데이터베이스(컨트롤 파일, 데이터 파일, REDO 로그 파일)나 복구에 필요한 파일(아카이브 REDO 로그)을 원하는 위치에 복제 또는 추출해내는 작업이다.

● 복구하다

복원된 데이터베이스(또는 테이블스페이스, 데이터 파일)에 아카이브 REDO 로그나 REDO 로그를 적용하여 최신의 상태 또는 원하는 시점의 상태로 만드는 작업이다.