DBMS의 백업 절차를 수립하고 테스트하는 것은 미디어 장애, OS, Software 그리고 Database에 심각한 손상을 주는 각종 오류로부터 기업의 중요 정보를 보호할 수 있는 필수적인 절차이다.

 

데이터 손상의 유형

 

유  형

내        용

비숙련 DBA에 의한 손상

DBA 교육 및 풍부한 경험을 가진 외부 인력의 적절한 도움

사용자 실수

실수로 인한 데이터 삭제 및 갱신

부적절한 보안 구성

해커에 의한 자료 손상 및 내부 인력에 의한 고의적 정보 손상

부적절한 Database 구성

적절한 업그레이드 및 패치 계획, 테스트 시스템 구축

부적절한 Backup 절차

경험 많은 엔지니어에 의한 백업 계획 및 절차 테스트

부적절한 하드웨어 구성

예상되는 장애에 대비한 하드웨어 다중화

 

(1) Control, Redo log, Archive log 파일의 다중화
(2) 백업 전략 수립
: 신속한 복구를 보장할 수 있도록 백업 방법, 간격, 보관주기 등 결정
(3) 복구 시나리오 준비 : 장애 유형별 복구 시나리오 준비 및 복구 시간 측정
(4) 백업 시스템 구축 : 고객의 데이터량과 최소한의 다운타임을 고려한 백업 솔루션 구성 및 백업 장비 구성
(5) Data-Guard 구성(Stand-by) : H/W 장애시 부품 교체 후 OS 재설치, Oracle DBMS 재설치, Data 복구 등에 많은 시간이 소요된다.  또한 24x7의 가용성이 중요시되는 환경에서 Downtime을 최소화하기 위해서는 Data-Guard 구성이 바람직하다.
Data-guard는 별도의 여분의 H/W가 필요하며 Archive log 전송으로 실시간으로 복구가 이루어지며 어떠한 유형의 장애라도 수 분 안에 정상 서비스가 가능해진다.


(6) Oracle Real Application Cluster(RAC)
: 확장성과 고가용성을 위한 클러스터 구성. 최소한 각각의 인스턴스를 가진 두 개의 서버로 이루어지며, 1개의 Database 를 공유한다.
높은 가용성을 요구하는 사이트와 추후 부하 증가에 따른 손쉬운 확장성을 요구하는 사이트에 적합하다.
(참고: 하드웨어 장애에 대해서만 대비가 되며, 디스크나 미디어 손상 그리고 유저 실수에 의한 데이터 손상에 대한 보호는 이루어지지 않는다. 따라서 여전히 백업은 필요하다.)


 

(7) Replication (복제) : 데이터베이스 스키마 오브젝트가 네트워크를 가로질러 여러 데이터베이스에 분산 복제되어 미션 크리티컬한 애플리케이션의 가용성을 높여줄 수 있다.


 

(8) User Error 에 대한 대비 : 유저의 실수에 의한 table drop 및 DML 후 commit 작업에 대한 복구
(9) Flash-back Query와 LogMiner를 통한 복구 : Flash-back Query는 9i부터 도입된 일종의 타임머신 기능으로 DB를 특정 상태 이전으로 돌려서 조회할 수 있다. 특히 유저 실수로 갱신하고 commit한 데이터도 손쉽게 복구해낼 수 있는 강력한 기능이다.