Backup & Recovery

1998, 한 만호

Database Specialist

원본출처 : http://bora.dacom.co.kr/~mhan/article/rdbms/back_rec.html

DBA의 가장 중요한 임무중의 하나는 기업의 모든 데이타베이스를 항상 이용가능한 상태로 유지하는 것이다. 여기서 이용가능하다는 것은 데이타베이스에 저장된 데이타들을 사용자들이 언제나 액세스할수 있을뿐 아니라, 데이타베이스 내용이 항상 갱신되고 정확하게 유지되는것을 의미한다. 사용자들이 데이타가 소실되었다거나 데이타가 맞지 않는다고 판단되는 사태가 발생되어서는 결코 안될것이다.

데이타베이스를 손상시키는 많은 상황들이 발생한다. 홍수나 지진같은 자연적인 재해, 전원이 끊어지거나 디스크가 파손되는 시스템 장애, DBMS 버그 또는 애플리케이션 애러같은 소프트웨어 장애뿐 아니라 조작자의 조작실패, 자용자의 판단 실수 또는 카보드 장애같은 사람에 의한 장애도 발생할 수 있다.

대규모 시스템환경에서 DBA는 개발 데이타베이스, 단위 또는 인수테스트 데이타베이스, 데이타분산을 위한 리플리케이트같은 운영용 제품을 위한 데이타베이스, 데이타 웨어하우스및 데이타 마트등 여러가지 데이타베이스를 항상 이용가능한 상태로 유지하여야 할 책임을 가지고 있다. 이들은 모두 서로 다른 이용가능상태를 필요로 하고 있다. 특히 온라인 프로덕트 데이타베이스는 24시간 365일 이용가능하게 해달라고 요구하고 있다. 데이타 웨어하우스 데이타베이스는 보통 업무시간에만, 아니면 업무시간 이후 몇시간 정도까지만 이용가능하면 되는것이 보통이다.

한편 테스트 데이타베이스는 테스트 기간에만 일시적으로 필요하지만 테스트 기간동안에는 확실히 이용가능해야 함을 요구받는다. 예를 들어 각 테스트 후에 새로운 정확한 테스트 데이타베이스를 DBA가 구축해 주어야 한다. 개발자들은 보통 개발 마감 날짜가 다가올수록 개발 데이타베이스의 이용상태에 대하여 어려운 요구를 해온다. 국제적인 조직인 경우에 각국의 업무시간이 또한 데이타베이스 이용가능 상태에 영향을 미친다.

리커버리는 장애상황을 정상상태로 만들기 위하여 데이타베이스를 재탑재하는 정확한 절차를 말한다. 기본적인 리커버리 절차는 다음과 같다.

1. 데이타베이스의 장애, 파손 상태등을 정의한다. 
2. 정상처리를 중지시킨다. 
3. 파손된 부분을 파악한다. 
4. 복구절차를 시행한다. 즉 
    . 옳바른 시스템 자원을 재탑재 한다. 
    . 파손 데이타를 제거한다. 
    . 재가동한다. 중간에 멈춘 트랜잭션을 다시 수행시킨다. 
5. 정상으로 가동한다. 

장애 상황으로부터 리커버리하는 기술들은 다음과 같은 것들이 있다.

Dump & Restart 데이타베이스 전체를 정기적으로 백업하고 있어야 한다. 장애가 발생하면 이 백업 받았던 데이타를 모두 재 탑재한다. 그래서 시스템을 재가동하면 새로운 트랜잭션을 수행할 수 있게 된다. 장애당시 수행하던 트랜잭션을 알수 있으면 재 수행하면 된다. 시스템을 제가동하는것은 다음 유형이 있다.

. Warm Restart는 수행하던 모든 트랜잭션이 정상으로 종료한 후에 정지된 시스템을 재가동 하는것이다.

. Emergency Restart는 조작자가 restart 명령어로 재가동 하는것이다. 백업받았던 데이타를 재탑재하는 절차가 필요할수도 있다.

. Cold Restart는 보통 warm restart가 불가능할 경우에 수행된다. 백업받았던 데이타베이스를 재탑재가 필요하다. 보통 물리적인 파손을 복구할때 사용되며 리커버리 데이타가 손실되었을때 복구하는 방법이 된다.

Undo-Redo processing(Rollback and re-execute)는 트랜잭션의 감사증적(Audit Trail)을 이용하여 최근까지의 모든 부분적으로 수행된 트랜잭션들을 수행되기 전의 상태로 복귀(undo)시킨다. 복귀는 갱신절차를 역순으로 수행하는 것이다. Log를 이용하여 모든 갱신 상황을 기록함으로써 트랜잭션이 시작되어 끝날때까지 모든 갱신 레코드를 추적할수 있게 된다.

Roll-forward processing(Reload and re-execute)는 checkpoint 까지의 옳바른 상황으로 재탑재 하는 것이다. 트랜잭션 감사 증적을 이용하여 최근에 기록된 트랜잭션을 재수행함으로써 옳바른 상태로 복귀하도록 DBA가 명령을 내릴수 있다. 물리적인 매체가 파손되었을때 주로 이용하게 되는 방법이다.

Restore and repeat는 이전의 옳바른 상태를 탑재하는데 있어 앞의 방법과는 좀 다르다. 트랜잭션은 감사증적에 있는 전후 이미지를 단순히 재구성하게 되고 실제 트랜잭션은 재수행되지 않는다.

이렇듯 DBA는 DBMS가 제공하는 다양한 도구와 기능들에 대하여 적절한 대응을 하여야 한다. 전체 데이타베이스를 offline으로 백업하는 기능, 필요한 부분만을 선택하여 백업하는 기능, 특별한 순간에 데이타베이스를 잠시 복제하여 두는 기능, 트랜잭션을 roll back, roll forward 하기 위한 저널링 기능들이 있다. 이 기능들중 일부는 사용자가 바쁘게 일하고 있는 온라인중에 수행할수도 있다. 각 백업 방안에 대응되는 리커버리 방안이 존재하여야 한다. 이 방안들은 아주 중요한 순간에 또는 사용자가 기다리고 있는 상태에서 신속하고 정확히 수행되어야 하기 때문에 한치의 실수가 없는 효율적인 방안들이어야 한다. 병렬로 복수 매체에 백업하는 방법, 압축과 해제 기능, 오래된 백업 데이타를 자동으로 삭제하여 정리하는 방법 또는 테이프 색인을 하는데 표준적인 방법등을 DBA는 필요하게 된다.

데이타베이스의 가용성을 증가시키기위한 hot standby기술을 사용하기도 한다. Hot standby는 대개 운영 데이타베이스의 데이타를 대기하는 (stanbdby) 데이타베이스로 복제하고 있다. 운영 데이타베이스에 장애가 감지되면 사용자는 대기하던 데이타베이스로 연결하여 운영 데이타베이스가 복구될때까지 업무를 계속 수행할 수 있게 된다. 그러나 데이타베이스 복제(Database Replication)는 다시 논하여야할 뜨거운 감자라고 할 수 있다.

Oracle

Oracle 7.3은 데이타베이스 백업및 리커버리를 위하여 full and partial backup과 redo log를 사용한다. 데이타베이스 백업은 물리적인 파일들을 O.S 백업하고 있다. Redo log들은 2개 이상을 미리 생성하여 놓는데 데이타베이스에서 발생되는 모든 변경 사항을 기록하고 있다. 또는 데이타베이스 백업을 위하여 export & inport를 사용할수도 있다. Oracle은 대기 데이타베이스(Stabdby database) 기능을 제공하는데 이것은 또다른 하느웨어 플랫폼에 운영 데이타베이스의 아카이브 데이타를 대기 데이타베이스에 적용시켜 놓으므로써 항상 리커버리가능한 상태로 만들어 두는 것이다.

Full backup은 모든 data files, parameter files, control files등을 O.S 백업하는것이다. Full backup은 O.S 명령어 또는 Server manager의 호스트 명령어로 실행한다. Full backup은 online중에 실행할수도 있지만 offline 상태로 실행하여야 데이타 정합성을 보장할 수 있다. Online중에 실행한 backup data는 리커버리를 위하여 online 또는 아카이브된 redo log 데이타를 필요로 한다. 데이타베이스를 normal 또는 immedate로 shutdown한 후에 full database backup을 하는것이 가장 바람직하다.

Partial backup은 선택한 데이타 파일, 콘트롤 파일 또는 특정 테이블스페이스를 구성하는 데이타 파일만을 O.S 백업하는것이다. Partial backup을 하려면 반드시 ARCHIVELOG 모드로 데이타베이스가 지정되어 있어야 한다. 아카이브 모드는 데이타베이스 생성시에 정의하지만 후에도 언제든지 재지정할 수 있다.

디스크 장애가 발생한 경우 파손된 데이타 파일의 백업 데이타를 재탑재한 후 다음 3가지중의 한 방법으로 파손된 데이타베이스를 복구할 수 있다. 이것은 server manager를 이용하여 할 수 도 있고 ALTER DATABASE SQL 명령어로 수행할수도 있다.

. RECOVER DATABASE 명령어로 전체 데이타베이스 복구를 수행할 수 있다. 이 명령은 redo 처리를 필요로 하는 모든 데이타 파일에 대해서 메체 복구를 수행한다.

. RECOOVER TABLESPACE 명령으로 특정 테이블스페이스를 복구한다. 이 명령은 기술된 테이블스페이스를 구성하는 데이타 파일들을 복구한다. 테이블스페이스 안의 테이블들이 위치한 데이타 파일 이름을 알아야 하기 때문에, 리커버리 동안 데이타베이스는 오픈되어 마운트되어 있어야 한다.

. RECOVER DATAFILE 명령어로 특정 데이타 파일들만을 복구할 수 있다.

백업 데이타가 없더라도 파손된 데이타 파일을 복구할 수 도 있다. 이를 위해서는 필요한 모든 로그 파일이 존재해야 하고, 파손된 파일 이름을 알고 있는 control file이 있어야 한다. 이 이외에도 오라클은 incompleted recovery, change-based, cancel-based, time-based 및 사용자 실수에 대한 리커버리등 다양한 경우에 대비한 경우의 수를 제공하고 있다.

Sybase SQL Server

Sybase SQL Server 11은 Database dump, Transaction dump, Checkpoint, 데이타베이스별로 존재하는 transaction log를 이용하여 데이타베이스 리커버리를 수행한다. 모든 백업과 복구처리는 SQL Server와 같은 플랫폼에서 수행되는 Backup Server라 불리는 별도의 open server 프로그램이 수행한다.

Database dump는 data file과 transaction log를 모두 포함하여 데이타베이스를 완전 복제하는것이다. 이 기능은 DUMP DATABASE 명령어로 수행하여 테잎이나 디스크에 복제한다. Dump가 수행되는 동안 사용자들이 계속 데이타베이스를 액세스하도록 하는 dynamic dump도 제공된다.

Transaction dump는 transaction log를 정기적으로 백업하는것을 말한다. DUMP TRANSACTION 명령어는 transaction log의 inactive 부분을 삭제하는 역할도 한다. 복수의 디바이스를 사용하여 dump database나 dump transaction 시 복수의 디바이스로 분산백업을 하는 기능도 제공된다.

Transaction log는 syslog라는 시스템 테이블로 유지하는 write-ahead log 이다. 데이타베이스와 그 transaction log를 동기화시키기 위하여 자동적인 체크포인트 기능을 사용하거나 CHECKPOINT 명령어를 사용할 수 있다. 체크포인트를 만나면 메모리에 남아있는 갱신된 데이타 페이지들을 디스크의 데이타 파일에 기록하게 된다. 정규적인 체크포인트는 시스템 장애시 리커버리 시간을 단축시켜 준다.

SQL Server가 restart될때마다 자동으로 각 데이타베이스의 transaction log를 검사하여 리커버리할 트랜잭션이 있는가를 확인한다. 만일 로그 레코드가 데이타 페이지보다 최근것이면 트랜잭션 로그로부터 변경사항을 재적용하게 된다.

LOAD DATABASE 명령어로 전체 데이타베이스를 재탑재하게 된다. 이후에 LOAD TRANSACTION으로 모든 transaction log dump를 그것이 생성된 순서대로 재탑재하게 된다. 이렇게 하게되면 transaction log 내의 정보에 의하여 transaction 이 재수행되게 되고 데이타베이스를 재구축하게 되는 것이다.

IBM DB2

DB2 2.1.1은 BACKUP 명령어와 Database Director 라는 두가지의 기능을 제공하고 있는데, 이것을 가지고 crash recovery, restore, roll-forward 3가지의 방법을 구사할 수 있다.

BACKUP은 online 또는 offline으로 할 수 있다. Online backup은 특정 데이타베이스가 roll-forward recovery로 정의되어있을때만 가능하다. BACKUP 명령어를 사용하려면 SYSADM, SYSCTRL 또는 SYSMAINT 권한을 가지고 있어야 한다. 데이타베이스나 테이블스페이스는 고정 디스크나 테잎으로 백업할 수 있다. 서로 다른 테이블스페이스에 대해서라도 동시에 테이블스페이스 백업과 재탑재를 할수는 없게 되어있다.

Restore는 full backup 받은 데이타베이스를 offline상태에서 재탑재하는 유일한 방법이다. 그래서 restore가 수행되면 데이타베이스는 마지막 full backup을 받았던 상태가 되는것이다. Roll-forward는 log에 남아았는 변경분을 반영하는 것이다. 따라서 restore를 한다음 변경분을 roll-forward로 반영하여 장애 발생싯점의 상태로 리커버리를 수행하게 되는것이다.

Crash recovery는 불완전한 상태로 남겨지는 데이타베이스를 방어하기 위한 것이다. 트랜잭션이 갑자기 중단되어 버리면 불완전한 또는 in-doubt 트랜잭션을 rollback 수행하여야 하는데 이는 RESTART DATABASE 명령어로 가능하다. 만일 AUTORESTART가 설정되어 있으면 장애시마다 자동으로 RESTART DATABASE가 수행된다. 리커버리 도중에 매체 장애가 발생해도 리커버리는 계속 수행되고 장애가 발생한 테이블스페이스는 offline되어 roll-forward 대기 상태가 된다. 이 offline된 테이블스페이스는 데이타베이스 모드에 따라 추가적인 리커버리 절차가 필요하다.