데이터베이스 업그레이드는 현재 사용하고 있는 제품에 대한 지원이 종료되어 정상적인 지원을 받지 못하는 경우처럼 안정적인 운영에 지장이 생길 수 있거나, 새로 발표한 버전의 새로운 기능이 기업의 미래 가치에 대한 요구와 일치해 기능적/비용적 이익이 예상될 때 검토된다.

또한 급속한 데이터의 증가 속도에 따라 상위 버전으로 데이터베이스를 업그레이드해야 하는 경우도있을 것이다.

리서치 기관인 IDC가 발표한 '디지털 유니버스(Digital Universe)'보고서에 따르면 개인과 기업에서 생성되는 디지털 정보의 양이 매 18개월마다 2배 증가함을 알 수 있다.

따라서 동일한 데이터를 보관하기 위해 데이터 보관주기를 변경해 데이터를 적게 유지하거나 필요한 만큼의 데이터를 유지할 수 있는 스토리지와 데이터베이스 시스템을 가져야만 될 것이다.

데이터베이스의 변경이나 업그레이드가 결정되었을 경우 대부분의 경우 업무용 애플리케이션은 특정 데이터베이스의 기능에 맞춰 구현되어 있기 때문에 데이터베이스의 변화에 따라 애플리 케이션의 수정이 불가피한 경우가 많다(몇몇 유명한 패키지는 '데이터베이스 UnDependency하다'고 말하기도 하지만 경우에 따라 수정이 필요한 경우가 존재할 수 있다).

더욱이 특정 DBMS는 버전 및 릴리즈의 변경에 따라 실행계획이 달라지는등 사이드 이펙트(side-effect)가 클 수 있으므로 세심한 주의와 검토가 필요하다.

필자가 경험한 보통의 경우에는 데이터베이스 업그레이드 시 애플리케이션의 수정이 동반되기 때문에 차세대 애플리케이션의 구축 등 대규모 작업과 동반해 데이터베이스를 업그레이드하는 경우가 많은 것이 현실이다.

하지만 관행에 따른 이러한 선택이 과연 적절한지 되돌아 볼 필요가 있을 것 같다.

애플리케이션 시스템의 재구축 작업과 함께 데이터베이스의 업그레이드를 하게 되면 데이터가 집중되는 상황 하에서 데이터베이스 업그레이드에 따른 성능 향상을 객관적으로 평가하기가 어려울 것이다.

성능 관점에서 병목지점이 될 수 있는 요소인 애플리케이션, 데이터베이스, 네트워크 등 부분별로 AS-IS와 TO-BE에 대한 객관적이고 관리 가능한 평가 지표와 목표치가 존재하고 있어야 정상적인 검토 및 사후 평가가 가능할 터인데,

한꺼번에 여러 항목을 복합적으로 다루게 되면 전체 성능에 영향을 미치는 갖가지 요소들이 이리 저리 얽혀 어떤 이유로 TO-BE가 좋아졌는지 혹은 나빠졌는지를 구분하고 개별적인 성과를 파악하기 어렵게 되기 때문이다.

일부 프로젝트의 경우 구간별 로드를 알 수 있는 APM 툴(성능관리 솔루션) 등을 이용한다. 하지만 의도적으로 대형 프로젝트의 시작에 맞춰서 모든 것을 통합해 진행하는 것보다는 가능하면 기업 IT 환경의 요구가 있을 때마다 순차적으로 해당 업그레이드를 진행하는 것이 좋다고 생각된다.

데이터베이스 업그레이드에 대한 대략적인 절차를 정리하면 다음과 같다.

• 1. 업그레이드 대상 AS-IS 시스템 선정
• 2. AS-IS 시스템과 관련한 업무 최적화
• 3. AS-IS 시스템의 업무별 BASELINE 수집
• 4. 업그레이드 TO-BE 시스템의 초기화 파라미터 결정
• 5. 시스템 업그레이드 및 데이터 마이그레이션
• 6. TO-BE 시스템의 이행 완료 후 모니터링
• 7. 업그레이드 평가 및 완료 보고

업그레이드 대상 AS-IS 시스템 선정

먼저 업그레이드를 할 대상 시스템의 선정은 시스템의 규모에 따라 달라지게 된다. 하나의 데이터베이스 시스템에서 여러 서비스를 하고 있다면 해당 서비스 전체가 업그레이드 대상 업무가된다.

근래 시스템 통합과 함께 데이터베이스 통합이 화두가 되어 데이터베이스 통합 프로젝트를 통해 데이터베이스 인스턴스수를 줄이고 특정 공급업체에 집중함으로써 기업은 비용을 절감 하고 데이터베이스 기술 품질을 향상시키고 데이터베이스 관리용이성을 높이려는 움직임이 활발하다.

이로 인해 하나의 슈퍼머신에 대규모의 데이터베이스를 운영하고 다종의 다양한 업무를 올려서 운영하는 상황이 일반화됨에 따라 데이터베이스를 업그레이드하게 될 경우 관련되는 대상 업무가 많아지게 되었다.

그러므로 업그레이드 시 영향을 미치는 업무와 연관 시스템에 대한 선행 조사를 실시해 다운타임 및 인력에 대한 계획을 수립해야 한다.

AS-IS 시스템과 관련한 업무 최적화

AS-IS 시스템에서 TO-BE 시스템으로 이행하기 전 성능 기준에 못 미치는 악성 SQL을 포함해 가능한 한 전체 SQL에 대한 전수조사 및 수집을 실시한다 (SQL과 실행계획 그리고 SQL 통계 등).

그리고 필요한 경우 SQL 최적화 작업을 수행해 이행 이후 발생할 수 있는 장애에 대한 예방적 최적화 작업을 실시한다

AS-IS 시스템의 업무별 BASELINE 수집

AS-IS 시스템의 수집 및 최적화를 진행했다면 TO-BE 시스템과의 성능 평가를 위해 BASELINE 자료를 생성한다.

이때 업무별로 중요한 애플리케이션을 기준으로 적절한 시나리오를 가지고 테스트를 수행해 실제 업무를 최대한 반영할 수있도록 한다. 그리고 일관적이고 정확한 평가를 하기 위해 전문가 그룹이나 성능관리 솔루션의 도움이 필요할 수도 있다.

시나리오와 테스트를 위한 SQL 최적화 적용은 실제 유지보수를 위한 개발자의 도움이 매우 중요하기 때문에 데이터베이스 업그레이드에 대한 기업의 요구와 기대에 대해 이를 수행하는 전체 인원이 이를 중요한 업무로 인식하고 각자 맡은 역할에 맞게 동참하는 것이 매우 중요하다고 할 수 있다.

이를 위해 가능한 데이터베이스 전문가 집단인 DA 그룹이 각종 회의/의사결정을 주도하며, 관련 그룹이 이해를 모으기 위한 여러 가지 노력이 경주된다.

업그레이드 TO-BE 시스템의 초기화 파라미터 결정

데이터베이스 버전이 높아지면서 새로운 기능이 많이 추가되고, 이를 검토해 적용하거나 문제가 되는 것으로 알려진 기능들을 ON/OFF하기도 한다.

오라클을 예로 들면 대표적으로 10G의 BIND-PEEKING과 ASMM의 MUTEX 사용을 제한하는 것이다.

오라클 데이터베이스는 OS 및 버전 그리고 릴리즈에 따라 새롭게 도입되거나 더 이상 지원되지 않는 초기화/히든 파라미터가 존재한다. 그렇기 때문에 이에 대한 리스트를 정리해 적용 여부와 적용 시 파급효과에 대한 검토를 수행할 필요가 있다.

시스템 업그레이드 및 데이터 마이그레이션

데이터베이스의 업그레이드는 서버의 가용한 공간과 다운타임에 따라 선택이 달라진다. 각 방법들의 특징을 간단히 정리하면 아래 [표1]과 같다.

• [표1] 오라클 데이터베이스 업그레이드를 위한 선택

• 방법	공간	다운타임
  Oracle Database Upgrade Assistant	별도 공간 불필요	작음
  수동 업그레이드	별도 공간 불필요	작음
  exp/ imp	별도 공간 필요	큼
  create table as select	별도 공간/시스템 필요	큼

OUA(Oracle Database Upgrade Assistant)를 이용하는 방법이나 수동으로 업그레이드를 함에 있어 사전에 버그리스트 확인 및 백업과 설치 리허설 등 가능한 보호조치를 하고 진행해야하며 설치 계획 시 실제 작업시간의 2~3배 정도 계획시간을 두어 트러블 발생 시 문제를 해결할 수 있는 예비 시간을 스케줄링하는 것이 좋다.

TO-BE 시스템의 이행 완료 후 모니터링

시스템 이행 완료 후 일정 기간 집중적인 모니터링을 실시해 업그레이드 이전/이후 실행계획이 변경되어 부적절한 비용을 발생시키는 SQL을 찾아 AS-IS 실행계획으로 고정하거나 해당 버전에 최적화된 SQL로 변경해야 한다.

AS-IS와 TO-BE SQL 전체를 비교 검토할 수 있는 검증 SQL/Repository 및 Tool을 준비해 즉시 대응할 수 있도록 하는 것이 좋다.

업그레이드 평가 및 완료 보고

AS-IS에서 수행했던 시나리오대로 TO-BE 시스템에서 수행해 CPU/MEMORY 및 각종 DB 지표를 확인해 이상 여부와 성능 개선 여부를 수치로 표현해 리포트로 작성할 수 있다.

가능한 명확한 절차와 검증방법으로 최대한 위험을 배제해 안정적인 업그레이드를 수행한 후 정량적 분석에 의한 이익을 설명 할 수 있어야만 제대로 데이터베이스 업그레이드 프로젝트를 수행한 것으로 볼 수 있다.