[Oracle] Chapter 10. 백업/복구의 구조와 동작

10.1 백업/복구를 왜 배워야하는가?

 

데이터는 매우 중요한 자산이며 시스템에 따라서는 '돈과도 바꿀 수 없을 정도로 중요하다'라고 이야기하기도 한다. 여러분도 '열심히 작업하던 파일(데이터)을 실수로 저장하기 전에 종료해버렸다'와 같은 난감한 상황을 겪어 보지 않았는가?

개인적인 파일(데이터)이라면 다시 생성하면 되겠지만, 여러 사람이 사용하는 시스템에서는 그런 식으로 데이터를 복원할 수 없다. 예를 들어, 은행의 계좌 정보가 사라졌다면 어떻게 될까? 계좌 데이터를 다시 생성하는 방식은 애초에 불가능하며, 이내 대혼란이 발생할 것이다.

견고한 시스템을 구축하기 위해 디스크를 다중화하는 등의 노력을 기울인다 하더라도, 시스템이나 관련된 장비가 만능일 수는 없다. 오랜 시간 동안 가동하여 장비들이 노후화되고 갑자기 디스크들이 동시에 손상되어 다중화한 보람도 없이 데이터가 유실될 수도 있다. 또한, 시스템을 다루는 것은 결국 사람이므로 휴먼 에러 떄문에 데이터가 유실되는 상황도 발생한다. 이런 만약의 사태에 대비해 데이터를 복원 할 수 있는 백업은 매우 중요하다.

그러나 실제 운영 환경에서는 백업을 받아 두지 않았거나, 노-아카이브 로그 모드(REDO 로그를 아카이브하지 않는 모드)이거나, 백업 중에 누락이 발생하는 것과 같은 일들이 많이 일어난다 그런 와중에도 장애가 발생하면 '어떻게든 데이터를 복구해야만 해!'와 같은 이야기를 심심치 않게 들을 수 있다.

백업을 받아 두었더라도 가장 최적의 복구 방법을 선택하여 데이터베이스 복구 시간을 단축해야 한다. 만약을 대비하여 백업/복구가 어떤 식으로 동작하는지를 지금부터 알아보자.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.2 백업/복구에 필요한 지식의 복습

 

이번 장을 배우는 데 필요한 지식을 다시 한번 복습하자. 데이터베이스를 구성하는 파일에는 데이터 파일, 컨트롤 파일, REDO 로그 파일, 이렇게 세 종류가 있다고 설명했다. 

REDO 로그는 데이터베이스의 데이터 변경 이력이며, REDO 로그를 사용해서 과거 시점의 데이터를 최신 시점의 데이터로 만들어 나가는 것을 롤포워드(roll-forward)라고 말한다. UNDO 정보는 데이터를 과거로 되돌리기 위한 정보이며, 롤백(rollback)은 UNDO 정보를 사용해서 변경한 것을 취소해 나가는(과거의 상태로 되돌리는) 것을 말한다.

또한, 오라클 내부의 시간(정확히는 시간을 대신할 수 있는 번호)을 나타내는 SCN이라는 숫자가 존재한다.

체크포인트는 버퍼 캐시의 데이터와 디스크의 데이터를 동기화하는 것을 말한다.

체크포인트가 끝나면 그때까지 메모리에서 변경되었던 데이터들이 디스크에 반영되었다는 것을 의미한다.

인스턴스 복구(충돌 복구)는 인스턴스가 비정상 종료될 떄나 오라클을 ABORT로 SHUTDOWN해서 다시 기동할 떄 자동으로 수행되는 것이다. 오라클은 데이터 파일의 데이터와 REDO 로그를 사용해서 데이터를 최신 상태로 만든다. 이 작업을 통해 커밋한 데이터를 복구하고, REDO 로그를 통해 커밋하지 않은 데이터도 알 수 있으므로 커밋하지 않은 데이터는 차례대로 롤백한다.

 

데이터베이스의 기동도 복습하겠다. 기동에는 SHUTDOWN(인스턴스가 정지한 상태), NOMOUNT(인스턴스가 기동한 상태), MOUNT(컨트롤 파일을 읽어온 상태), OPEN(사용자가 사용할 수 있는 상태)의 네 가지 상태가 있다. 오라클은 기동할 떄 초기화 파라미터를 파일에서 읽어온 후에 인스턴스를 기동한다. 인스턴스는 '공유 메모리 + 백그라운드 프로세스'의 집합을 뜻한다. 인스턴스를 기동한 후 초기화 파라미터를 토대로 컨트롤 파일을 읽어온다. 컨트롤 파일에는 데이터 파일이나 REDO 로그 파일의 위치가 적혀 있으므로 오라클은 그것을 토대로 데이터 파일을 확인하고 데이터베이스를 사용할 수 있는 상태로 만든다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.3 백업의 종류와 특징

 

백업에는 '온라인 백업(핫 백업)'과 '콜드 백업'이 있다. 콜드 백업은 가장 무난한 백업으로, 인스턴스를 완전히 정지한 상태에서 받는 백업을 말한다. 모든 데이터가 파일에 기록된(체크포인트 완료)상태이기 떄문에 할 수 있다면 콜드 백업을 받는 것이 간단하고 편하다.

이것과 비교하면 온라인 백업은 24시간 데이터베이스를 운영하는 상황에서도 백업도 받아야 한다는 조건을 충족할 수 있다. 데이터베이스를 운영하는 상태에서 사용할 수 있는 백업 방법으로, 받기 전에 BEGIN BACKUP 명령어를 사용하고 백업이 끝나면 END BACKUP 명령어를 실행한다(단, 오라클의 백업 관리자인 RMAN으로 백업할 경우에는 이러한 명령어를 실행해줄 필요가 없다).

 

10.3.1 온라인 백업의 순서

 

온라인 백업의 순서는 다음과 같다.(ALTER DATABASE 구문은 10g 이후부터 사용할 수 있다.)

1: 'ALTER TABLESPACE <테이블스페이스명> BEGIN BACKUP;' 또는 'ALTER DATA-BASE BEGIN BACKUP;'을 실행

2: 백업을 실행

3: 'ALTER TABLESPACE <테이블스페이스명> END BACKUP;'또는 'ALTER DATABASE END BACKUP;'을 실행

 

온라인 백업은 데이터베이스를 운영하면서 백업을 받는 것이므로 콜드 백업처럼 체크포인트가 수행된 상태의 파일이 아니다. 또한, 백업을 읽어오는 시점과 데이터를 변경하는 시점이 어긋나면 같은 블록 안의 데이터라도 제대로 읽어온다는 보장이 없어지기 때문에 BEGIN BACKUP에서 END BACKUP까지는 REDO 로그에 각종 정보를 추가해서 데이터를 복구할 수 있도록 동작한다. 이런 이유로 데이터가 불완전해 질 수 있기 떄문에 데이터 파일을 복원(restore)한 후에는 반드시 REDO 로그를 적용해야 한다.

또한, EXPORT 등을 사용한 논리 백업을 받을 떄도 있다. 논리 백업은 데이터를 빼내오는 형태의 백업이므로 REDO 로그를 이용해 복구할 수는 없다. 배치 처리, DBA의 관리 작업 등을 하기 전에 데이터를 보존해두고 싶을 떄 사용한다.

그리고 백업은 다른 시점으로 두 세트를 받는 것을 권장한다. 보험이라고 생각해도 되며, 백업을 받는 도중에 장애가 발생해서 받는 도중이었던 백업과 원본 데이터가 손상될 수도 있기 떄문이다.

 

TIP

온라인 백업 도중에 인스턴스가 정지하면?

 

온라인 백업을 받는 중에 어떤 이유로 인스턴스가 강제로 정지하면, 기동할 때 'ORA-1113: file<XXX> needs media recovery'라는 에러가 발생하며, 데이터베이스를 OPEN할 수 없게 된다. 그럴 때는 MOUNT 상태에서 END BACKUP을 수행하고 그 후에 데이터베이스를 OPEN한다. 또한, 복원하지 않고 복구하는 방법도 있다. 이 에러가 발생할 확률은 낮지만, 실제로 발생하면 매우 당황스러우므로 온라인 백업을 담당하는 분이라면 기억해두자.

 

TIP

논리 백업

 

논리 백업이란 어떤 시점에 데이터의 내용만을 뺴내어 보존해두는 백업을 말한다. 대표적인 방법으로는 데이터 펌프(expdp/impdp)를 사용해서 덤프(dump)파일로 데이터를 보존하는 방법이 있다.

논리 백업은 운영상의 실수로 발생하는 사고에 대응할 때도 유효하다. 데이터베이스를 복원할 정도는 아니더라도, 실수로 데이터를 삭제해버려서 데이터를 복구해야 하는 경우라면 논리 백업에서 필요한 데이터만 가져오면 된다(플래시백 테이블이라는 기능도 있지만, 상황에 따라서는 사용할 수 없는 경우도 있으므로 생략한다). 하지만, 논리 백업은 어디까지나 데이터의 내용물만을 보존하고 있으며, 백업한 시점의 데이터까지만 복구할 수 있다. 그러므로 데이터를 최신 상태로 되돌리기 위해서는 애플리케이션의 로그를 이용하는 등의 별도 수단을 함께 사용할 필요가 있다.

 

이에 비해 이번 장에서 소개했던 백업은 물리 백업이다. 물리 백업은 데이터 파일이나 컨트롤 파일을 백업하기 때문에 파일이 손상되었을 때도 복구할 수 있다. 또한, REDO를 적용하는 것으로 최신 상태까지 복원할 수가 있다. '데이터가 유실되면 안 된다'는 관점에서는 물리 백업을 권하지만, 상황에 따라서는 논리 백업도 유효하므로 보조 수단으로 사용하기 위해 백업을 받는 경우도 많다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.4 데이터베이스 손상의 예

 

1: 디스크의 물리적인 고장으로 인한 데이터 파일의 손상

2: 작업 실수 등으로 인한 OS상에서의 삭제나 덮어쓰기

3: 어떤 문제로 인한 블록 손상

4: 데이터 파일에 일시적으로 접근 불가

5: 하드웨어의 물리적인 고장이나 케이블의 문제

 

10.4.1 디스크의 물리적인 고장으로 인한 데이터 파일의 손상

이런 문제는 RAID를 이용해 디스크를 다중화해두면 어느 정도 예방은 할 수 있다. 하지만 'RAID 컨트롤러가 고장 나서 RAID 안의 데이터가 유실'되는 경우도 많으며, RAID로 장애를 완전하게 예방할 수 있는 것은 아니다. 오라클은 기동된 상태에서 장애를 금방 알아챈다. 정지한 상태였다고 해도 다음 번 기동할 때 바로 알 수 있다.

 

10.4.2 작업 실수 등으로 인한 OS상에서의 삭제나 덮어쓰기

rm 등의 명령어를 사용해 파일을 삭제해 버린 경우나, cp 등의 명령어를 사용해 파일을 덮어써버린 문제 등이 있다. 오라클은 기동된 상태에서는 장애를 바로 알아챈다. 정지한 상태였다고 해도 다음 번 기동할 때 바로 알 수 있다.

 

10.4.3 어떤 문제로 인한 블록 손상

데이터 파일 전체가 손상된 것이 아니라 일부 블록만이 손상된 상태이다. 오라클은 여러 방법으로 블록이 손상되지 않았는지를 점검하고 있으며, 알아챈 시점에 '여기가 손상되었다'고 알려준다. 블록 손상은 현장에서 주로 오라클을 많이 의심하는 장애이지만, 실제로는 장애의 원인이 오라클이 아닌 다른 것인 경우가 많다. 블록 손상이 더욱 큰일인 이유는 손상되더라도 오라클이 눈치채지 못하는 떄가 많다는 것(해당 장소를 읽어오기 전까지 눈치채지 못함)과 다른 곳에도 손상된 블록이 존재할 수 있다는 점이다.

 

10.4.4 일시적인 데이터 파일의 접근 불가

오라클이 데이터 파일에 접근하려고 했을 때, OS나 스토리지 측의 문제나 불안정한 상태로 인해 파일에 접근할 수 없는 경우가 있다. 읽어올 수 없다면 에러가 발생하는 정도로 끝나지만, 기록할 수 없을 때는 오라클이 데이터 파일을 오프라인(사용할 수 없는 상태)으로 변경하고 복구가 필요하다고 인식한다. 기록할 수 없는 테이블스페이스가 SYSTEM 테이블스페이스일 떄는 인스턴스가 중지된다.

 

10.4.5 하드웨어의 물리적인 고장이나 케이블의 문제

디스크 이외의 하드웨어도 고장이 날 수 있으며, 케이블이 느슨해지거나 하는 등의 문제로 인해 I/O 에러가 발생할 수 있다. 앞에서 설명했던 블록 손상도 이 문제로 인해 발생할 수 있다.

 

10.4.6 드라이버나 어댑터 카드 등의 제품 불안정에 의한 손상

불안정한 제품으로 인해 오라클 자신이나 오라클에서 디스크까지의 구간에서 발생하는 손상을 말한다. 저의 경험상 논리적인 손상을 제외하면 원인은 대부분 오라클 이외의 것이었다. 앞에서 설명했던 블록 손상도 이 문제로 인해 발생할 수 있다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.5 기본적인 복구의 종류와 동작

 

백업에도 몆 가지 종류가 있듯이 복구에도 다음과 같이 몆 가지 종류가 있다.

- 충돌(인스턴스)복구, 미디어 복구

- 완전 복구, 불완전 복구

- 데이터베이스/테이블스페이스/데이터 파일/블록의 복구

 

10.5.1 인스턴스 복구와 미디어 복구

9장에서도 설명했지만 일반적으로 인스턴스 복구라고 불리는 충돌 복구(crash recovery)는 인스턴스가 비정상 종료된 후 다시 기동할 때 자동으로 수행되는 복구를 말한다. 미디어 복구는 디스크의 데이터가 손상되었을 때 사용자가 명시적으로 수행하는 복구이다. 또한 백업본을 복원한 후 복구하는 것이 아닌, 현재 데이터 파일만을 사용하는 방식도 있다(상세한 내용은 뒤에서 설명한다). 일반적으로 이야기하는 복구란 미디어 복구를 의미한다.

 

10.5.2 완전 복구와 불완전 복구의 차이

완전 복구란, 데이터베이스를 최신 데이터까지 복구한다는 의미이다. 이와 대조적으로 불완전 복구는 어떤 시점(도중)까지만 복구한다는 의미이다. 일반적으로 특별한 이유가 없는 한 완전 복구를 선택하며, 오라클도 특별히 지정하지 않으면 완전 복구를 수행한다. 불완전 복구를 선택하는 것은 아카이브 REDO 로그가 유실되어을 때나 어떤 사정으로 인해 특정 시점의 데이터로 바꾸고 싶을 때 등이다.

 

10.5.3 데이터베이스/테이블스페이스/데이터 파일/블록의 복구

데이터베이스 복구는 데이터베이스 전체를 복구하는 것을 말하며 'RECOVER DATABASE'라고 입력하여 수행한다.

데이터베이스를 중단하지 않고 정상적인 테이블스페이스는 운영을 계속해가며 손상된 테이블스페이스만을 복구하고 싶을 떄가 있다. 그럴 때는 복구할 테이블스페이스만을 사용할 수 없는 상태(오프라인)로 변경하고 테이블스페이스를 복구한다. 당연한 이야기지만, SYSTEM 테이블스페이스와 같이 오프라인 상태로 만들면 데이터베이스를 운영할 수 없게 되는 주요 테이블스페이스는 이런 복구 방법을 사용할 수 없다. 또한, 좀 더 좁은 범위만 복구하는 방법으로 데이터 파일 범위로 복구하는 방법도 있다. 'RECOVER DATAFILE <데이터 파일명>'이라고 입력하면 수행한다. 이들에 관해서는 '10.7.2 데이터베이스가 가동 중인 상태에서 테이블스페이스를 복구한다'에서 상세히 설명하겠다.

조금 특수한 것이 블록의 복구이다. RMAN(칼럼 'RMAN이란?을 참고)을 사용하면 특정 블록을 지정해서 복구할 수도 있다. 특정 블록만을 백업된 데이터로 돌려놓고 해당 블록에 관한 REDO 로그만을 사용하는 고도의 복구 방법이다. 해당 블록 외에는 사용할 수 있는 상태이기 때문에 장애가 국소적으로 발생했을 떄 매우 높은 가용성을 유지할 수 있는 방식이다.

또한, 복구할 때는 가용성뿐만이 아니라 복구에 걸리는 시간이나 재작업할 가능성이 낮아야 한다는 부분도 중요하다. 예를 들어, SYSTEM 테이블스페이스의 데이터파일만 손상되었는데 데이터베이스 전체를 복원해서 복구하는 것과, SYSTEM 테이블 스페이스의 데이터 파일만을 복원한 후 복구하는 것은 들어가는 시간이 다르다. 전체를 복원하면 사용자 테이블스페이스 등의 데이터 파일을 읽어오는 작업이나 REDO 로그를 적용하는 등의 작업이 필요해지기 떄문이다.

 

또한, 일부의 영역만을 복구했으나 다시 작업해야 하는 일이 발생해서 전체적인 복구 시간이 오히려 길어지는 경우도 있다. 재작업이 발생하는 이유로는 손상된 블록이 숨어 있는 경우가 있기 때문이다. 오라클은 해당 블록을 읽어올떄까지는 데이터의 손상을 알지 못하기 때문에 겨우 복구를 완료했음에도 나중에서야 데이터가 손상된 것을 눈치채는 경우가 있다. 앞서 이야기한 SYSTEM 테이블스페이스의 데이터 파일이 손상된 예로 설명하면, SYSTEM 테이블스페이스에서 블록 손상이 발견되어 사용자 테이블스페이스의 복구가 필요해졌을 가능성도 있다. 따라서 어떤 이유로 인해 데이터가 손상되었는지를 이해하고 가장 최적의 복구 방법을 선택할 수 있어야 한다.

 

10.5.4 복구할 필요가 없는 테이블스페이스도 존재한다?

 

사실은 복구할 필요가 없는 테이블스페이스도 존재한다. 장애가 발생했을 떄 다음에 나열한 테이블스페이스에 해당되는지 한번 생각 해봐야한다.

 

- 임시(temporary) 테이블스페이스

- 읽기 전용 테이블스페이스(읽기 전용으로 변경한 후에 백업을 받았다는 전제)

- 인덱스용 테이블스페이스(인덱스를 재생성한다는 것이 전제)

 

임시 테이블스페이스(테이블이나 인덱스 등을 보관하지 않는 임시 테이블스페이스)라면 삭제한 후 다시 생성하면 된다. 이것은 정렬 등을 위해서 일시적으로 데이터를 저장하기 위한 공간이므로 유실되어도 문제가 발생하지 않는다.

또한 테이블스페이스를 읽기 전용 모드로 변경하면, 오라클은 해당 테이블스페이스의 데이터를 변경하지 않는다. 따라서 읽기 전용 모드로 변경한 테이블스페이스는 REDO 로그가 필요하지 않는다. 한 번만 백업을 받아 두면 나중에 복원하는 것만으로도 복구를 완료할 수 있다.

인덱스용 테이블스페이스는 인덱스를 생성하기 위한 데이터가 테이블에 존재하고 있으므로 테이블스페이스를 버린다 하더라도 인덱스만 다시 만들면 원상 복구된다.

 

칼럼

RMAN이란?

 

RMAN은 오라클 8 이후에 기본적으로 포함된 도구인 'Recovery MANager'의 약어로, 백업/복구를 간단하게 수행할 수 있는 관리 도구이다. RMAN은 써드 파티 제품과 연동해서 테이프에서 자동으로 복원할 수 있으며, 관리 정보를 가지고 있는 카탈로그 데이터베이스를 사용할 수도 있다.

최근에는 RMA에서만 수행할 수 있는 기능도 존재한다. 10g 이후의 RMAN에서 주목해야 할 것은 변경한 부분만을 백업하는 기능(체인지 트래킹, change tracking)과 백업한 파일의 갱신 기능(증분 백업, incremental backup)이다.

최근엔 디스크나 데이터베이스의 크기가 커져서 한 개의 디스크를 백업하는 데 소요되는 시간이 길어졌기 떄문에 전체 백업에 소요되는 시간도 무시할 수는 없다. 오라클 이외의 제품에서는 백업할 때 기본적으로 모든 디스크의 데이터를 읽어 와야 한다. 하지만 체인지 트래킹 기능을 사용하면 변경된 부분만을 핀 포인트로 읽어 RMAN으로 백업할 수 있다.(지금까지의 백업에서는 모두 읽어오지 않으면 변경되었는지 아닌지를 판단할 수 없었다).

그렇다 해도 일반적인 증분 백업만 받는 것만으로는 부족하므로 언젠가 전체 백업을 받을 필요가 있다. 그래서 증분 백업 기능을 이용해 이전에 받은 풀 백업에 변경된 데이터를 적용한다. 체인지 트래킹과 증분 백업을 합쳐 사용함으로써 필요한 부분만을 읽어 와, 풀 백업을 항상 최신 데이터로 유지할 수 있다. 단, 백업 자체를 갱신해야 하므로 백업을 디스크에 보관해야만 한다는 제한이 있다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.6 기본적인 복구의 흐름(데이터베이스 전체의 복구)

 

데이터베이스 전체를 복구하는 예를 토대로 기본적인 복구의 흐름을 설명하겠다. 데이터베이스 전체를 복구할 떄는 모든 데이터 파일을 복원하고 업무를 정지한 후 복구한다. 순서는 다음과 같다.

 

1. 데이터베이스가 손상되었는지를 확인한다.

2. 재작업할 수 있도록 현재 상태를 백업한다.

3. 필요한 데이터 파일과 아카이브 REDO 로그 파일을 복원한다.

4 복구를 실행한다.

 

10.6.1 ⑴데이터베이스가 손상되었는지 확인

 

앞에 설명한 것처럼 오라클은 기동 중인 상태에서 손상되었는지를 알 수 있으며, 기동하기 전에 아는 경우도 있다. 또한, 사용자나 스토리지가 먼저 알아채는 때도 있을 것이다. 만약 ORA 에러가 발생했다면 그 내용을 확인해서 OS나 스토리지에서 에러가 발생하지 않았는지를 확인한다. 매뉴얼이나 MOS(My Oracle Support)의 문서 등을 참조하면서 필요하다면 SR(서비스 요청)을 통해 데이터베이스가 손상되었는지와 복구가 필요한지를 확인하자.

오라클이 멈췄을 때는 무엇이 망가졌는지를 조사해야 한다. 예를 들어, 컨트롤 파일이 손상되었다면 MOUNT 상태가 되기 전에 오라클이 정지할 것이다. 초기화 파라미터 파일이 손상되었다면 인스턴스의 기동 자체가 수행되지 않는다. 반대로 데이터 파일에만 발생한 장애라면 MOUNT까지는 성공하고 OPEN에 실패했을 것이다.

지금부터는 데이터 파일에 장애가 발생한 것을 전제로 이야기를 진행하겠다. 데이터 파일을 복구할 때는 MOUNT 상태여야 하는데, 그 이유는 컨트롤 파일을 읽어오지 않은 상태에서 데이터 파일이 어디에 있는지 알 수 없기 떄문이다. 따라서 MOUNT 상태에서 뷰(view)를 확인해보자. 오라클이 제공해주는 v$recover_file이나 v$datafile_header와 같은 뷰를 확인하면, 오라클이 복구가 필요하다고 인식한 데이터 파일을 확인할 수 있다.

 

10.6.2 ⑵재작업할 수 있도록 현재 상태 백업

 

데이터베이스가 손상된 것을 확인했으므로 마음 같아서는 바로 복원하고 복구 작업을 하고 싶겠지만, 그전에 먼저 데이터베이스를 정지하고 현재의 상태를 백업하도록 한다. 백업을 하는 이유는 다시 재작업할 수 있도록 준비하기 위함이며, 또한, 나중에 데이터베이스를 조사할 기회를 놓치지 않기 위함이다. '다시  작업해야 하는 것까지 걱정해야 해?'라고 생각할 수 있지만, 실제로 데이터베이스에 손상이 발생하면 현장은 매우 혼란스러우며, 급하게 복구하기 위해 절차나 명령어를 실수하는 경우가 많이 발생한다. 따라서 장애가 이중으로 발생하는 것을 막고, 다시 복구할 수 있는 기회를 얻을 수 있으므로 현재 상태의 백업은 반드시 필요하다.

또한, 현재 상태의 백업을 받을 떄는 데이터 파일뿐만 아니라 컨트롤 파일이나 REDO 로그 파일, 아카이브 REDO 로그 파일도 포함해라.

 

10.6.3 ⑶필요한 데이터 파일과 아카이브 REDO로그 파일 복원

 

일반적으로 데이터 파일을 복원하지만, 복원할 필요가 없을 때도 있다. 일시적인 I/O장애 등으로 데이터를 기록하지 못하고 데이터베이스가 가동 중인 상태에서 데이터 파일만 오프라인이 된 상황이 존재할 수 있다. 이때 v$ 뷰를 조회해보면 복구가 필요하다고 표시는 되지만 복원하지 않고 복구를 시도해볼 수 있으며, 이런 상황에서는 복원을 하지 않고도 복구할 수 있는 경우도 많다.

그에 비해 실제로 데이터 파일이 손상되었거나 없어졋을 때는 반드시 복원을 해야 한다. 기본적으로 alert 파일이나 v$뷰에서 표시한 것들을 복원할 대상으로 삼지만, 표시되어 있지 않은 다른 데이터 파일일지라도 장애가 의심된다면 복원할 수 있다. 또한, 필요한 파일들을 복원하자마자 바로 복구를 시작하지는 말자. 복원한 후에는 MOUNT하고 v$datafile_header를 확인하는 습관을 가져야 한다. 여기서는 복원한 파일의 시점이 장애 발생 이전(백업을 받은 시점)인지를 확인해라. 현장에서는 데이터 파일을 복원할 때 필요한 파일이 누락되는 일이 자주 발생하며, 안타깝게도 이런 파일의 누락은 복구하는 마지막 단계에서 발견되는 일이 많다. 여기서 미리 확인해두지 않으면 데이터 파일을 다시 한번 복원해야 하므로 또 다시 많은 시간이 소모된다. 따라서 복원할 때는 복구 대상 데이터 파일을 확인해서 누락이 되지않도록 주의해야 한다.

SELECT TABLESPACE_NAME, NAME, STATUS, RECOVER, TO_CHAR(CHECKPOINT_TIME,'MM-DD HH24:MI:SS')
FROM V$DATAFILE_HEADER;

계속해서 복구에 필요한 아카이브 REDO 로그 파일을 복원한다. 필요한 아카이브 파일들이 디스크에 모두 존재하고 있다면 복원하지 않아도 상관없다. 또한, 온라인 백업을 복구하는 데는 백업하던 중에 생성된 REDO 로그 역시 필요하므로 '아카이브 REDO 로그가 누락'되지 않도록 평소 운영할 때 주의를 기울여라.

 

10.6.4 복구 실행

 

완전 복구를 수행하기 위해 MOUNT 상태에서 'RECOVER DATABASE;'라고 입력한다. 그러면 복구를 시작하게 되는데, 내부적으로는 어떻게 동작할까?

우선은 복구 프로세스가 아카이브 REDO 로그를 읽은 다음, 어느 곳의 데이터(블록)를 변경해야 하는지 파악하고, 블록이 캐시에 올라와 있지 않다면 디스크에서 블록을 읽어 와서 캐시에 올려놓는 동작을 한다. 그 후에 캐시의 데이털르 변경한다. 다른 부분에서 살펴보았던 동작과 비슷하다고 느끼지 않았는가? 실은 복구 할 때의 동작은 DML문에 의한 데이터 변경 동작과 거의 같다.

 

1. REDO 정보

2. 작업장인 버퍼 캐시에 놓여 있지 않은지를 확인

3. 필요한 경우에는 디스크에서 블록을 일거와서 캐시에 둠

4. 캐시의 데이터를 REDO 정보를 사용해서 변경

# 복구가 끝날 떄까지 이 작업을 반복 #

 

복구가 끝나면 'Media recovery complete'라는 표시가 나타나지만, 여기서 안심하면 안된다. ALTER DATABASE OPEN 명령어까지 잘 실행된 후여야 비로소 복구를 위한 큰 벽을 넘었다고 말할 수 있다. 이 명령어를 실행했을 떄 에러가 발생하지 않고 끝났다면 데이터베이스를 사용할 수 있는 상태라는 의미이므로 업무를 재개해도 상관없다.

 

칼럼

백업/복구에서 자주하는 실패

 

자주 들리는 백업/복구의 실패 사례에는 다음과 같은 것들이 있다. 같은 실수를 하지 않기 위해 참고하자.

- 일부 데이터 파일의 백업 누락

- 일부 데이터 파일의 복원 누락

- 아카이브 REDO 로그를 테이프에서 복원할 때 누락

- 필요한 아카이브 REDO 로그 파일의 삭제

 

'백업 누락'은 대부분 데이터 파일을 운영 중에 신규로 추가했을 떄 많이 발생한다. 데이터 파일을 추가하는 명령어를 실행한 이후에 백업용 셸을 수정하지 않았기 때문에 백업을 수행할 때 빠지는 상황이 발생한 것이다. 스토리지의 고급 백업 기능을 사용할 때도 잘 잊어버릴 수 있으므로 백업/복구는 반드시 테스트를 수행해라.

'복원 누락'은 단순히 파일을 지정하는 것을 빠트렸거나 오라클의 v$뷰를 대충 확인했을 때 발생할 수 있다. 본문에서도 설명했듯이 복원 누락은 복구의 최종 단계에서 알게 되는 일이 많으므로 실제 현장에서는 철저히 확인하자.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.7 그 외의 복구

 

10.7.1 불완전 복구란 무엇인가?

 

데이터베이스의 불완전 복구란 어떤 것인지 조금 더 자세하게 설명하겠다. 불완전 복구는 최신 데이터가 아니라 중간의 특정 시점까지 하는 것을 의미하므로 일부 데이터가 유실된다. 따라서 복원할 데이터 파일은 반드시 복구 목표 시간보다 오래된 것을 사용할 필요가 있다. 왜냐하면 아카이브 REDO 로그를 사용하여 오래된 데이터 파일을 복구 목표 시간까지 롤 포워드하기(시간을 흐르게 한다) 떄문이다. 그러므로 v$datafile_header를 사용해서 복원한 후의 파일을 확인하도록 하자.

완전 복구 명령어와 다른 부분은 'recover DATABASE UNTIL XXX'라는 구문이 사용된다는 점이다. XXX에는 'TIME XXX', 'CANCEL', 'CHANGE XXX'등의 옵션이 들어간다. 오라클의 로그를 통해서 복구 목표 시간과 SCN을 확인했다면 CHANGE를 사용할 수도 있지만, 대부분은 TIME을 사용해서 시간을 지정하거나 CANCEL을 지정해서 '이 정도로 복구했으면 충분하다'라는 것을 알고 있는 아카이브 REDO 로그까지 적용한다.

RECOVER 명령어가 종료된 후에는 'ALTER DATAASE OPEN RESETLOGS;'라고 입력한다. RESETLOGS에는 각종 초기화 처리가 포함되어 있으므로 처리하는 데 몆 분 정도 걸린다. 따라서 바로 프롬프트가 돌아오지 않는다고 해서 당황하지 말도록 하자.

중간까지 내부 동작이 데이터베이스 완전 복구와 같다. 다른 부분은 RESETLOGS부분이다. 데이터 파일 간의 시간(타임스탬프)이 맞지 않으면 데이터베이스는 오픈할 수 없다. 하지만 RESETLOGS를 수행하면 여러 정보가 초기화되어 데이터 파일간의 시간이 맞지 않더라도 데이터베이스를 오픈할 수 있게 된다. 다만 이 과정 중에 현재의 REDO 로그를 청소하는 작업이 들어가 있으며, RESETLOGS를 수행한 시점 이전의 아카이브 REDO 로그는 OPEN 이후에 더 이상 사용할 수 없게 된다. 따라서 RESETLOGS를 실행한 후에는 전체 데이터베이스를 가능한 빨리 다시 백업해야 한다.

 

10.7.2 데이터베이스가 가동 중인 상태에서 테이블스페이스를 복구

 

데이터베이스가 가동 중인 상태에서 테이블스페이스를 복구할 수도 있다. 일반적으로 복구가 필요한 파일이 존재하면 데이터베이스를 OPEN할 수 없다. 이런 때는 중요한 테이블스페이스가 아니라면 MOUNT 상태에서 해당 테이블스페이스의 데이터 파일을 'ALTER DATABASE DATAFILE <데이터 파일> OFFLINE;' 또는 'ALTER TABLESPACE <테이블스페이스명> OFFLINE;' 명령어를 통해 오프라인으로 변경한 후 OPEN 명령어를 실행할 수 있다.

데이터베이스가 OPEN 상태로 전환되어 사용할 수 있는 상태라도, OFFLINE으로 전환한 파일 안의 데이터는 사용할 수 없다. 그래서 해당 부분만을 대상으로 복구를 수행한다. 필요한 파일을 복원한 후 'RECOVER TABLESPACE <테이블스페이스명>;'DLSK 'RECOVER DATAFILE <데이터 파일>;' 명령어를 사용해서 복구를 수행한다. 복구가 끝난 후에는 'ALTER DATABASE DATAFILE <데이터 파일> ONLINE;' 또는 'ALTER TABLESPACE <테이블스페이스명> ONLINE;'을 실행하면 사용할 수 있는 상태로 변경된다.

 

# 주의! SYSTEM 테이블 스페이스는 테이블스페이스 복구를 할 수 없음 #

1. 장애가 탐지된 테이블 스페이스는 여기라고 가정

2. 손상된 사용자 테이블스페이스(또는 손상된 데이터파일)을 오프라인으로 변경하는것으로, 손상된 부분을 제외한 데이터베이스를 계속 가동할 수 있게 됨

3. 복원과 복구를 수행. 복구가 끝나면 ALTER TABLESPACE ... ONLINE 명령어를 실행하여 사용할 수 있는 상태로 변경

 

10.7.3 컨트롤 파일 복구

 

지금까지는 데이터가 손상됐을 떄를 설명했습니다만, 컨트롤 파일이 손상되는 장애도 존재한다.

컨트롤 파일이 손상되었을 떄는 우선 다중화해둔 컨트롤 파일의 일부만이 손상되었는지, 전체가 손상되었는지를 확인한다. 컨트롤 파일은 일반적으로 다중화되어 있으므로 그중 한 개만 손상된 것이라면 복원할 필요 없이 대응할 수 있다. 장애를 해결하기 위해 alert.log를 확인하고 어떤 컨트롤 파일이 손상되었는지를 확인한다. 우선은 해당 컨트롤 파일을 초기화 파라미터의 컨트롤 파일 목록에서 제외시킨다.

 

이것으로 오라클은 해당 파일을 참조하지 않는다. 하지만 남아 있는 파일에서도 에러가 발새할지도 모른다. 다시 기동을 수행할 떄 에러가 발생하면 계속해서 손상된 컨트롤 파일을 제외하는 작업을 반복한다. 만약 데이터베이스가 정상적으로 기동한다면, 기동할 때 정상적으로 사용할 수 있었던 컨트롤 파일을 사용하여 문제가 발생했던 컨트롤 파일을 덮어씀으로써 문제를 해결할 수 있다. 하지만 전체 컨트롤 파일이 손상되었을 때는 컨트롤 파일을 다시 생성하거나, 컨트롤 파일의 백업을 복원한후 'RECOVER ... USING BACKUP CONTROLFILE' 명령어를 실행해야 한다. 순서가 복잡하므로 상세한 내용은 매뉴얼이나 MOS(My oracle Support)의 문서를 참고해라.

앞장과 마찬가지로 복구는 오래된 데이터를 토대로 변경 로그인 REDO 로그를 적용하여 데이터를 최신화하는 것을 기본으로 한다.

 

칼럼

아카이브 로그는 필수!

 

지금도 노-아카이브 로그 모드로 데이터베이스를 운영하는 시스템이 있다는 이야기를 자주 듣는다. 조금 귀찮긴 하지만 반드시 아카입즈 로그 모드로 설정해서 사용해라. 운영 환경뿐만 아니라 '테스트 환경이지만 데이터가 없어지면 안 돼'라는 업무팀의 요청도 꽤 있다. 아카이브 로그를 사용하는 이유는 다음과 같다.

# 노-아카이브 로그 모드에서는 온라인 백업을 받을 수 없다.

# 노-아카이브 로그 모드에서는 미디어 복구를 사용할 수 없을 때가 있다. 실제 대응할 방법이 인스턴스 복구 정도밖에 없다.

# 노-아카이브 로그는 백업 및 복구시 사용할 수 있는 방법에 제한이 있으므로 바람직하지 않다.

또한, 아카이브 로그라고 해도 노-로깅(nologging)에서의 작업은 복구할 수 없으므로 평소 운영할 때도 주의가 필요하다. 노-로깅은 테이블이나 인덱스에 nologging을 지정하거나 SQL문에 명시했을 떄 수행된다.(테이블을 노-로깅으로 설정하고 DIRECT 모드(append 힌트 사용)로 대량의 데이터를 INSERT할 경우에만 REDO 로그가 생성되지 않는다. 일반적인 INSERT ... VALUES문의 경우 여전히 REDO 로그가 생성된다는 사실을 명심하기 바란다. 인덱스의 노-로깅은 인덱스를 생성(create)하거나 재생성(rebuild)할 경우에만 적용된다.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

10.8 요약

 

이번 장에서는 다음의 내용을 설명했다.

# 콜드 백업과 온라인 백업의 차이와 주의점

# 완전 복구/불완전 복구의 차이와 주의점

# 테이블스페이스 및 데이터 파일의 복구

# 컨트롤 파일이 손상되었을 떄의 대처 방법

 

백업/복구를 잘할 수 있게 되었다면 초급을 탈출했다고 볼 수 있다. 꼭 테스트 환경을 사용해 머리속에 절차를 떠올리며 실제 백업/복구를 연습해라.

앞으로 두 개의 장이 남아있다. 이제 슬슬 마물디를 해야 할 단계이다. 다음 장에서는 ㅁ나무리의 일환으로 백그라운드 프로세스에 관해 설명한다. 지금까지는 주로 서버 프로세스의 동작을 설명했지만, 전면에 나서지는 않으나 뒤에서 일을 지원하는 백그라운드 프로세스의 동작도 알아 두어야 하기 때문이다.

 

칼럼

오라클의 패치 정책

 

패치(patch)란 소프트웨어의 기능을 추가하거나, 버그 등을 수정하는 프로그램을 말한다. 오라클 12c R2 이후부터는 3개월마다 RU 및 RUR이라는 두 가지 패치가 정기적으로 제공되고 있다(단, 윈도우 제외).

 

#RU(Release Update)

보안, 옵티마이저의 동작, 기능 추가에 관련된 수정 내용이 포함된다. 누적형 패치로서 최신 릴리즈를 적용하면 모든 수정 내용을 적용할 수 있다.

#RUR(Release Update Revisions)

RU를 적용한 환경에만 적용할 수 있는 수정 패치이다. 같은 시기에 릴리즈된 RU와 비교해서 옵티마이저의 동작, 기능 추가의 수정은 포함되지 않으며, 보안이나 가벼운 버그 수정만이 포함된다.

 

18.1.0 

__._._

18: 데이터베이스의 릴리즈 버전을 의미(첫 번쨰 필드)

1: 이미 적용된 RU를 의미(두 번쨰 필드)

0: 이미 적용된 RUR을 의미(세 번째 필드)

 

해당 기간에 릴리즈된 RU를 적용하든가, 이미 적용된 RU에 RUR을 적용하든가를 선택할 수 있다. 한개의 RU에 최대 두 번째 분기까지의 RUR만 릴리즈되기 때문에 세 번째 분기 이후의 수정 패치를 적용하고 싶을 떄는 해당 분기에 릴리즈된 RU를 적용해야 한다.

제품 버전	1월(1분기)	4월(2분기)	7월(3분기)	10월(4분기)
18.1.0	RU1(18.2.0)	RUR(18.2.1) (RU1에만 적용 가능)	RUR(18.2.2) (RU1에만 적용 가능)
		RU2(18.3.0)	RUR(18.3.1) (RU2에만 적용 가능)	RUR(18.3.2) (RU2에만 적용 가능)
			RU3(18.4.0)	RUR(18.4.1) (RU3에만 적용 가능)
				RU4(18.5)

RU 쪽이 수정 범위가 넓지만 큰 기능 수정보다는 보안 이슈를 우선해서 수정하고 싶을 때가 있다. 그럴 떄는 RUR을 적용하는 것이 선택할 수 있다.

일반적으로 최신 패치를 적용하는 것을 추천하지만 '시스템이 안정 가동 중인 상태이므로 변경하고 싶지 않다'라는 이유로 패치 적용을 하지 않을 떄도 있다. 처음부터 완벽한 소프트웨어를 만드는 것은 어려운 일이기 떄문에 정기적으로 패치를 적용함으로써 좀 더 좋은 방향으로 소프트웨어를 수정해나가야 한다. 이런 점에서 오라클은 매일매일 진화하고 있다고 말할 수 있다.