고객사 요청으로 기술지원을 갔다가 데이터 복구 작업을 해야 되는 경우가 있었다.
특정 테이블의 데이터 복구 작업 시 업무 영향도를 최소화하기 위해서 개발 시스템에 운영DB의 백업 이미지를 경로재지정 복구를 수행하여 필요한 데이터를 추출하는 방법으로 작업을 진행하였다.
문제는 개발서버의 자원이 운영시스템만큼 풍족하지 못하고, 이미 개발DB가 존재하기 때문에 복구 중 rollforward 작업이 진행되지 못하게 되었다.
rollforward를 수행하면서 내부적으로 DB가 활성화되는 것 같은데, 개발서버의 물리적 메모리의 가용량이 DB가 필요로 하는 메모리 크기가 되지 못해서 생긴 것 같다. 마치 대저택에서 살던 사람이 사업이 망해 단칸방으로 세간살이를 옮겨야 되는 경우와 비슷한..
인스턴스 메모리 및 DB 메모리를 변경해도 이 문제는 해결되지 않았다. STMM이 수행되어도 DB내 설정된 버퍼풀의 크기를 충족하지 못해 DB가 활성화되지 못하는..
해결 방안을 얻고자 자료들을 찾아보니, Registry 변수에서 버퍼풀 크기를 강제로 제어하는 변수를 알게 되었다.
DB2_OVERRIDE_BPF=버퍼풀ID,페이지수;버퍼풀ID,페이지수
운영DB를 통해서 가장 큰 (페이지수가 많은) 버퍼풀ID와 페이지 수를 확인을 하고 크기를 줄여나갔다.
이 변수를 적용하고 나서 rollforward 작업 진행되어 데이터 복구 작업을 완료할 수 있었다.
이후 언젠가 블로그 글을 살펴보면서 같이 일했던 동료분이 “실수로 bufferpool 크기를 과도하게 설정한 경우 해결하는 방법”으로 글이 적혀둔걸 보게 되었다. (남의 경험이 공유되어도 직접 비슷한 경험을 하지 않는 이상 급박한 상황에서 해결안을 쉽게 찾아내긴 어려운 법 같다.)
고객사 시스템에 직접 터미널로 붙어서 작업하는 환경이 없어져서 장애관련 정보를 수집하고 메모하는 것이 어려워진다. 그저 기억속으로만 간직해야 되는
'Note' 카테고리의 다른 글
| [SQL] model dimension by (0) | 2015.01.08 |
|---|---|
| [보안] authentication 과 srvcon_auth (0) | 2014.07.14 |
| [보안] SSL 설정 (0) | 2014.06.18 |
| [관리] db2gcf (0) | 2014.05.19 |
| [복구] 경로재지정 복구 (0) | 2014.04.15 |