소개

거의 모든 DBA는 자신의 제어를 벗어난 환경이 손상되거나 데이터베이스의 데이터가 유실될 경우 많은 스트레스를 받기 마련이다. 다른 작업은 모두 제쳐두고 예기치 않은 상태를 원상태로 복구하는 작업을 즉시 수행해야 한다. 이때 복구 작업을 쉽게 수행할 수 있는 도구가 있다면 중단 시간을 줄일 수 있다. 장기적으로 복구 관리는 자연스럽게 DBA의 일상 활동으로 자리를 잡게 될 것이며 결과적으로 피할 수 없는 문제가 발생하더라도 스트레스를 많이 받지 않고 빠르게 복구 작업을 수행할 수 있게 될 것이다.

이 기사에서는 DBA로 활동 중인 Erik의 일화를 소개한다. 가상의 회사인 JK Enterprises Great Outdoors에서 근무하는 Erik은 IBM Data Studio Administrator를 사용하여 회사의 중요 영업 데이터베이스를 백업한다. 올바르지 않은 애플리케이션 로직으로 인해 여러 테이블에서 데이터가 삭제되는 문제가 발생하자 Erik은 긴급히 데이터베이스를 복원한다. 그는 또한 애플리케이션 손상이 발생하기 전의 시점으로 데이터베이스를 롤포워드할 수도 있다.

이 기사에서 설명하는 기능은 Database Change Management 기능이 지원되지 않는 Data Studio Administrator 시험판인 Data Studio Administrator의 무료 버전을 다운로드하여 사용할 수 있다. Database Change Management 기능을 설치 및 구입하게 되면 제약 조건, 뷰, 트리거 및 참조 무결성과 같은 종속 오브젝트의 관리 및 데이터 보존을 포함한 확장된 변경 사항이 지원된다.

이 기사에서 설명하는 백업 및 복구 작업은 다음과 같은 단계로 진행된다.

1. 연결되어 있지 않은 경우, 영향을 받는 데이터베이스에 연결한다.
2. 테이블에 있는 행 데이터를 확인한다.
3. Backup 태스크 도구를 사용하여 시스템을 백업한다.
4. 애플리케이션 로직이 적용된 상황을 재현하기 위해 샘플 delete 명령문을 실행하여 두 테이블에 있는 모든 행을 삭제한다.
5. Restore 태스크 도구를 사용하여 데이터베이스를 복원한 후 delete 명령문을 실행하기 전의 시점으로 롤포워드한다.
6. 업데이트된 행 수를 통해 복원 작업 이후 데이터가 손상되지 않은 상태로 복원되었는지 확인한다.

위로

전제 조건

Erik의 시나리오를 따라오려면 다음과 같은 단계를 수행하여 제품을 설치하고 환경을 구성해야 한다.

1. Data Studio Administrator 버전 2 릴리스 1(픽스 팩 1 포함)이 설치되어 있어야 한다.

   Data Studio Administrator 버전 2 릴리스 1이 설치되어 있지 않은 경우에는 참고자료 섹션의 링크를 사용하여 시험판 제품을 다운로드한다.

   Data Studio Administrator 버전 2 릴리스 1 시스템의 픽스 팩 1을 설치하지 않은 경우에는 참고자료의 링크를 사용하여 픽스 팩 1 설치 파일 및 지침을 다운로드한다.

2. 지원되는 버전의 DB2®도 설치되어 있어야 한다. DB2가 없는 경우에는 참고자료 섹션의 링크를 사용하여 DB2 Express Edition의 무료 버전인 DB2 Express-C를 다운로드한다.
3. 다음 단계를 수행하여 GSDB라는 샘플 데이터베이스를 생성한다.
1. 이 기사의 다운로드 섹션에서 GSDB_Database.zip 파일을 다운로드한 후 GSDB_Database.sql 파일을 추출한다.
2. DB2 명령창을 연다.
3. GSDB_Database.sql 파일을 저장해 놓은 위치로 이동한다.
4. 다음 명령을 입력한다.
   db2 -td~ -f GSDB_Database.sql
4. 기본 순환 로깅을 아카이브 로깅을 사용하도록 변경한다. 아카이브 로깅을 사용하려면 다음과 같이 UPDATE DATABASE CONFIGURATION 명령을 사용하여 LOGARCHMETH1을 OFF 이외의 값으로 설정해야 한다.

   UPDATE DB CFG FOR GSDB USING logarchmeth1 "DISK:C:\GSDB_ARCHIVE" failarchpath \ "C:\GSDB_failure" logprimary 2 logsecond 0 logfilsiz 1024;

   
   

   아카이브 로깅을 사용해야 하는 이유

   복구는 스토리지 오류, 전원 중단 또는 애플리케이션 오류와 같은 문제가 발생한 이후에 데이터베이스 또는 테이블 공간을 다시 빌드하는 작업이다. 데이터베이스 또는 개별 테이블 공간을 백업해 놓았다면 이들이 손상되었을 때 다시 빌드할 수 있다.

   순환 로깅은 로그가 지속적으로 겹쳐써지면서 현재 트랜잭션의 무결성을 보장할 필요가 있는 경우에만 유지된다는 것을 뜻한다. 이 유형의 복원 작업은 전체 백업이 수행된 특정 시점으로 데이터를 복구하기 때문에 버전 복구라고 한다. 이는 데이터베이스 생성 시 적용되는 기본 로깅 옵션이므로 이 기사에서 설명하는 시나리오를 수행하려면 먼저 이 옵션을 명시적으로 변경해야 한다.

   백업 이후에 적용된 변경 사항을 다시 적용하는 롤포워드 복구를 지원하려면 아카이브 로깅을 사용해야 한다. 이름에서 알 수 있듯이 아카이브 로깅은 적합한 아카이브 및 활성 로그를 통해 변경 사항을 적용하여 특정 시점으로 복구하는 데 필요한 로그를 보존한다.

   Linux®, Unix® 및 Windows®용 DB2 정보 센터의 복구 로그 이해" 주제에서 자세한 설명을 볼 수 있다.

   참고: 위 명령의 첫 번째 행 끝에 있는 백슬래시 문자는 단지 행 연결을 나타내기 위해 사용된 것이므로 실제로 명령을 입력할 때는 제외해야 한다. 즉, 한 행으로 이어진 문자열로 된 명령을 DB2 명령 창에 입력해야 한다.
   
   
   

   위 명령은 다음과 같은 사항을 지정한다.

   • 아카이브 로깅을 사용한다.
   • 아카이브 로그를 GSDB_ARCHIVE 디렉토리에 저장한다.
   • 아카이브 로깅에 실패할 경우, 임시 디렉토리 GSDB_failure에 기록한다.
   • 기본 로그는 두 개이며 보조 로그는 없다.
   • 기본 로그 크기는 1024개의 4KB 페이지이다.

   시나리오를 수행하는 동안 로깅 옵션을 변경한 후 데이터베이스에 대한 전체 오프라인 백업을 수행한다.

이후 섹션에서는 Erik이 겪은 주요 사건을 설명한 후 그가 취한 조치를 자세히 살펴본다. 세부 사항은 직접 따라할 수 있도록 단계별 지침으로 제공된다.

위로

데이터베이스에 연결하기

모든 Data Studio 제품은 공통 Data Source Explorer를 사용하여 데이터베이스에 연결한다. 이 시나리오에서 Erik은 다음과 같이 GSDB 데이터베이스에 연결하는 작업을 가장 먼저 수행한다.

1. 그림 1과 같이 Data Source Explorer에서 Database Connections을 마우스 오른쪽 단추로 클릭하고 New…를 선택한다.
   
   그림 1. Data Source Explorer에서 데이터베이스에 연결하기
   
   
   
2. 그림 2와 같이 필수 연결 매개변수를 입력한 다음 Test Connection 단추를 클릭하여 연결을 확인한다.
   
   그림 2. 연결 확인하기
   
   
   
3. 연결이 설정되었으면 Next 단추를 클릭한다.
4. 그림 3과 같이 Filter 화면에서 GOSALES 및 GOSALESCT 스키마가 포함되도록 선택한 다음 Finish 단추를 클릭한다.
   
   그림 3. 스키마를 기준으로 필터링하기
   
   
   

위로

테이블의 행 수 확인하기

GSDB 데이터베이스에 연결된 후 Erik은 선택된 테이블의 행 수를 확인하려고 한다.

이 시나리오에서는 행 수를 테이블의 현재 상태를 나타내는 지표로 사용한다. 복원 작업을 수행한 후 이 수를 사용하여 테이블이 동일한 상태로 복원되었는지 확인할 수 있다.

선택된 테이블의 행 수를 확인하기 위해 다음을 수행한다.

1. 그림 4와 같이 Data Source Explorer에서 GSDB 데이터베이스의 Tables 폴더를 두 번 클릭한다.
   
   그림 4. Tables 폴더를 두 번 클릭하기
   
   
   
2. 이제 그림 5와 같이 Object List 창에 테이블 스키마, 테이블 이름 및 각 테이블의 행 수가 표시된다. GOSALES.PRODUCT 및 GOSALES.PRODUCT_FORECAST 테이블에 각각 274개의 행과 2728개의 행이 있다는 것을 알 수 있다.
   
   
   그림 5. 행 수를 보여 주는 Object List 창
   
   
   
3. 앞에서 설명한 방법 대신 그림 6과 같이 개별 테이블을 마우스 오른쪽 단추로 클릭한 다음 Data > Return All Rows를 선택해서 실제 데이터를 볼 수도 있다.
   
   그림 6. 개별 테이블의 모든 행 리턴하기
   
   
   

위로

데이터베이스 백업하기

Erik은 이제 다음과 같은 단계를 수행하여 GSDB 데이터베이스를 백업한다.

1. 그림 7과 같이 Data Source Explorer에서 GSDB 데이터베이스를 마우스 오른쪽 단추로 클릭하고 Backup…을 선택하여 Backup 태스크 도구를 실행한다.
   
   그림 7. Data Source Explorer에서 Backup 선택하기
   
   
   
2. 그림 8과 같이 1. Type 탭에서 Back up the entire database를 선택한다.
   
   그림 8. Backup 태스크 도구에서 백업 유형 선택하기
   
   
   
3. 2. Image 탭을 선택한다.
4. 드롭다운 메뉴에서 File System을 매체 유형으로 선택한다(그림 9).
5. Browse 단추를 클릭한 후 C:\GSDB_BACKUP을 백업 이미지의 위치로 선택한다(그림 9).
   
   
   그림 9. 백업 매체 유형 및 위치 선택하기
   
   
   
6. 3. Options 탭을 선택한다.
7. Backup type에서 Full backup – Back up all data를 선택한다(그림 10).
8. Availability에서 Offline - Users cannot access the database during the backup을 선택한다. 이 항목을 선택한 후 정지 선택란 옵션이 활성화되면 선택란을 선택한다(그림 10). 로깅 유형을 변경한 후에는 해당 유형의 백업이 있어야만 나중에 지정 시점으로의 복원을 수행할 수 있으므로 전체 오프라인 백업을 수행해야 한다.
   
   그림 10. 백업 옵션 선택하기
   
   
   
9. 그림 11과 같이 Preview Command 를 클릭하여 Command 창에서 명령을 생성하고 확인한다.
   
   그림 11. 백업 명령 미리보기
   
   
   
10. Run 단추 를 클릭한다.
11. 그림 12와 같이 Data Studio Administrator는 백업 성공 메시지를 리턴해야 한다.
    
    그림 12. 성공을 보여 주는 메시지 창
    
    
    

위로

문제 발생

이날 Erik은 나중에 애플리케이션 로그를 보다가 올바르지 않은 애플리케이션 로직으로 인해 GOSALES.PRODUCT 및 GOSALES.PRODUCT_FORECAST 테이블의 모든 행이 삭제된다는 것을 발견한다. 이를 확인하기 위해 Object List 창으로 이동한 그는 그림 13과 같이 두 테이블의 행 수가 0인 것을 보게 된다. 그리고 이들 테이블에 각각 274개의 행과 2728개의 행이 있었기 때문에(그림 5 참조) 문제가 발생했다는 것을 알게 된다.

Erik이 데이터를 복구하기 위해 수행한 과정을 따라하기 위해 여기에서는 먼저 다음과 같은 DB2 명령을 입력하여 행 삭제를 재현해야 한다.

delete from GOSALES.PRODUCT
delete from GOSALES.PRODUCT_FORECAST

delete 명령을 실행하기 전의 시점으로 복구하기 위해 시간을 기록해 둔다.

위로

지정 시점으로 복원하기

Erik은 이제 Data Studio Administrator의 기능을 사용하여 데이터베이스를 적합한 상태로 복원하려고 한다. 올바르지 않은 애플리케이션 로직이 발생하기 전의 원래 상태로 데이터베이스를 되돌리기 위해 Erik은 다음과 같은 단계를 수행하여 데이터베이스 복원을 수행하고 지정 시점으로 롤포워드한다.

1. 그림 14와 같이 Data Source Explorer에서 GSDB 데이터베이스를 마우스 오른쪽 단추로 클릭하고 Restore…를 선택하여 Restore 태스크 도구를 실행한다.

1. 그림 15 및 16과 같이 1. Type 탭에서 Restore to an existing database와 Restore the entire database를 선택한다.
   
   그림 15. 기존 데이터베이스로 복원하는 항목 선택하기
   
   
   
   
   그림 16. 전체 데이터베이스를 복원하는 항목 선택하기
   
   
   
2. 2. Available Images 탭을 선택한다.
3. Select the backup images from a list를 선택한다(그림 17).
4. 백업 이미지 목록에서 올바르지 않은 애플리케이션을 실행하기(테이블 행을 삭제하기) 전의 최근 이미지를 선택하고 오른쪽 화살표 단추 를 클릭하여 백업 이미지를 오른쪽 상자로 이동한다(그림 17).
   
   그림 17. 올바르지 않은 애플리케이션을 실행하기 전의 최근 이미지 선택하기
   
   
   
5. 4. Roll forward 탭을 선택한다.
6. Restore the database and roll forward as follows를 선택한다(그림 18).
7. Roll forward to a point in time – Local을 선택한다(그림 18).
8. Roll forward to transaction 날짜 및 시간에 적합한 값을 입력한다. 날짜 및 시간은 올바르지 않은 애플리케이션을 실행한 시점(테이블 행을 삭제한 시점)보다 이전이어야 한다.
   
   그림 18. 올바르지 않은 애플리케이션을 실행한 시점보다 이전의 롤포워드 시간 선택하기
   
   
   
9. 5. Final State 탭을 선택한다.
10. 그림 19와 같이 Complete the restore and return the database to the active state를 선택한다.
    
    그림 19. 롤포워드 완료 후 데이터베이스를 활성 상태로 되돌리도록 선택하기
    
    
    
11. 그림 20과 같이 Preview Command 를 클릭하여 Command 창에서 명령을 생성하고 확인한다.
    
    그림 20. Restore 명령 미리보기
    
    
    
12. Run 단추 를 클릭한 후 그림 21과 같이 Messages 및 SQL Results 창에 결과가 표시되는지 확인한다.
    
    그림 21. 복원 진행률 및 상태
    
    
    

위로

복원 확인하기

Erik은 이제 안도의 한숨을 내쉴 수 있게 되었다. 드디어 올바르지 않은 애플리케이션 로직이 발생하기 전의 상태로 데이터베이스가 복원되었다. 그는 이를 확인하기 위해 Data Studio Administrator를 사용하여 다음과 같이 테이블 행 수를 확인한다.

1. Data Source Explorer에서 Tables 폴더를 두 번 클릭한다.
2. 이제 Object List 창에 GSDB 데이터베이스 테이블이 표시된다. 그림 22와 같이 GOSALES.PRODUCT 테이블을 마우스 오른쪽 단추로 클릭하고 Update statistics를 선택한다.
   
   그림 22. Update Statistics를 선택하여 행 수 새로 고치기
   
   
   
3. SQL Results 창을 클릭한다. 그러면 Object List 창이 새로 고쳐지면서 현재 행 수가 표시된다.
4. GOSALES.PRODUCT_FORECAST 테이블에 대해서도 동일한 프로세스를 수행하여(테이블을 마우스 오른쪽 단추로 클릭한 후 Update statistics를 선택하고 SQL Results 창 클릭하여) 현재 행 수를 새로 고친다.
5. 그림 23에서 볼 수 있듯이 이제 GOSALES.PRODUCT 및 GOSALES.PRODUCT_FORECAST 테이블의 행 수가 올바르지 않은 애플리케이션 로직이 발생하기 전과 같은 개수(각각 274개의 행과 2728개의 행)로 복원되었다.
   
   그림 23. 복구된 행
   
   
   

위로

결론

데이터베이스 관리자에게 Data Studio Administrator는 백업 및 복구 전략의 일환으로 정기 백업을 수행하는 데 도움이 되는 유용한 도구이다. 이러한 백업은 소프트웨어 오류, 하드웨어 장애, 올바르지 않은 애플리케이션 로직 및 사용자 오류와 같은 원인으로 인해 데이터가 손상된 이후 데이터베이스를 적절한 상태로 복원하는 데 사용할 수 있다.

데이터베이스가 성공적으로 복원된 것을 확인한 Erik은 위기를 극복했다는 기쁜 마음으로 모퉁이 카페로 가서 시원한 카라멜 모카라떼를 여유롭게 즐겼다.

위로

다운로드 하십시오

다운로드 방식에 대한 정보

참고자료

교육

• Data Studio Administrator가 Data Studio 포트폴리오의 다른 제품과 작동하는 방법을 "IBM Data Studio software: The big picture"에서 볼 수 있다.
  
  
• Data Studio Administrator 다운로드에서 사용할 수 있는 무료 관리 기능을 포함한 Data Studio 패키징에 대한 자세한 설명을 "Understanding Data Studio software packaging"에서 볼 수 있다.
  
  
• Data Studio Administrator의 모든 새 기능에 대한 설명을 "What’s new in Data Studio Administrator 2.1"에서 볼 수 있다.
  
  

제품 및 기술 얻기

• Data Studio Administrator의 시험판을 다운로드하자.
  
  
• Data Studio Administrator 2.1용 픽스 팩 1을 다운로드하고 설치하자. 이 기사에서 설명한 기능을 사용하려면 픽스 팩을 설치해야 한다.
  
  
• 커뮤니티를 DB2 Express Edition의 무료 버전인 DB2 Express-C를 다운로드하자. 이 제품은 DB2 Express Edition과 동일한 핵심 데이터 기능과 애플리케이션 빌드 및 전개를 위한 안정적인 환경을 제공한다.
  
  

토론

• Data Studio 팀 블로그
  
  
• Data Studio 커뮤니티 스페이스
  
  

필자소개

Sailaja Bandlamoori는 캐나다의 산호세에 소재하고 있는 IBM Silicon Valley Laboratory의 Information Management Data Studio 그룹에서 Data Studio Administrator에 관한 QA Team Lead를 맡고 있다. 2006년부터 Data Studio Administrator 제품 관련 업무를 맡고 있으며 그 이전에는 DB2 for z/OS 클라이언트/서버 시스템 테스트 업무를 수행했다.

TaWanna Harris는 캔사스 주의 레넥사에 있는 Information Management Data Studio 그룹 소속의 QA Staff Software Engineer이다. 2008년부터 Data Studio Administrator 제품 관련 업무를 맡고 있으며 그 이전에는 IBM Migration Toolkit, 파트너 및 고객 애플리케이션 테스트 및 상호 운용성 테스트 업무를 수행했다.

아티클 순위

의견

위로

목차

• 소개
• 전제 조건
• 데이터베이스에 연결하기
• 테이블의 행 수 확인하기
• 데이터베이스 백업하기
• 문제 발생
• 지정 시점으로 복원하기
• 복원 확인하기
• 결론
• 다운로드 하십시오
• 참고자료
• 필자소개
• 의견