시리즈 소개

MySQL은 현재 동적 웹 애플리케이션을 빌드하기 위해 PHP 프로그래밍 언어와 더불어 가장 일반적으로 사용되는 데이터베이스 서버이다. 하지만, DB2는 PHP의 훌륭한 지원을 받는 또 하나의 인기 데이터베이스로서 MySQL에 비해 매력적인 장점이 많아 수많은 애플리케이션에 이상적인 데이터베이스 서버로 자리매김하고 있다.

본 시리즈에서는 최근의 마이그레이션 프로젝트를 통해 기사 작성자들이 쌓은 경험을 바탕으로 파악한 PHP 애플리케이션에서 DB2로 이동하는 것이 합당한 이유, 마이그레이션의 준비, 실행, 지원 및 잠재적 위험 관리 방법을 설명한다. 이번 시리즈에서는 많은 코드 및 구성 샘플뿐 아니라, 프로젝트의 원활한 실행에 도움이 되는 자원에 대한 포인터도 제공한다.

성공적인 실시간 변환에서 체득한 교훈과 다양한 사례를 통해 이 프로젝트가 올바로 문서화되고 매력적인 이점을 제공하는 간단한 프로젝트가 될 수 있다는 점을 확인하게 될 것이다.

4개 파트로 구성된 본 시리즈에서는 ibm.com용 컨텐츠 프로덕션을 지원하기 위해 전 세계 4,000명의 IBM 내부 사용자가 사용하는 업무에 핵심적인 프로덕션 등급의 PHP 인트라넷 애플리케이션에 대한 성공적인 MySQL-DB2 마이그레이션에서 깨달은 교훈을 공유한다.

• 파트 1에서는 마이그레이션 준비에 필요한 단계를 설명한다.
• 파트 2에서는 데이터베이스 마이그레이션에 필요한 단계를 설명한다.
• 파트 3에서는 PHP 코드로 변환하는 데 필요한 단계를 설명한다.
• 파트 4에서는 애플리케이션을 배치 및 지원하는 데 필요한 단계를 설명한다.

학습 내용

본 기사 시리즈의 목표는 MySQL에서 DB2로 PHP 애플리케이션을 마이그레이션하는 데 일반적으로 필요한 사항, 이때 사용 가능한 자원, IBM 프로젝트 팀이 2010년 초에 해당 태스크를 수행한 방법을 소개하는 것이다.

MySQL에서 DB2로의 마이그레이션을 조사해본 적이 있다면, DB2 문서에서 읽은 각종 제품 정보, 성능 벤치마크 및 특징이나 MySQL to DB2 Conversion Guide(참고자료 참조)를 포함하여 이 태스크에 관한 IBM Redbooks®의 비교 자료를 바탕으로, DB2가 제공하는 가치를 이미 이해하고 있을지도 모르겠다.

DB2 Express-C는 Cloud 또는 Amazon EC2에서 IBM Smart Business Development and Test를 사용하여 손쉽게 설치하거나 평가할 수 있고 모든 기능을 갖추고 있는 무료 관계형 데이터 서버라는 사실도 이미 알고 있을지 모르겠다. 이런 오퍼링에 대한 링크는 참고자료 섹션에서 확인할 수 있다.

본 기사 시리즈에서는 ibm.com 웹 사이트의 다양한 섹션에 게시되는 컨텐츠의 일상적 관리 업무를 지원하기 위해 IBM 내부에서 많이 사용되는 PHP 인트라넷 애플리케이션에 대해 2010년에 성공리에 실행된 실제 마이그레이션 프로젝트를 구체적인 사례로 들어 설명한다.

본 시리즈를 모두 읽고 나면, 독자 여러분도 유사한 마이그레이션 사례를 남기고, 실행할 필요가 있는 작업 항목의 실행 시점과 종속 항목을 이해하고, 잠재적 위험을 예상하고, 그 과정에서 이루어지는 각 단계를 지원하기 위해 어느 곳을 살펴봐야 할지 알 수 있을 것이다. 이 모든 지식을 바탕으로, DB2를 선택할 때 더욱 큰 확신을 가지고 현재 MySQL을 바탕으로 빌드되어 있는 PHP 애플리케이션에 DB2를 최선의 방식으로 사용할 수 있을 것이다.

다루지 않는 내용

본 기사 시리즈의 목적은 IBM 내부에서 실시되었던 DB2에서 MySQL로의 마이그레이션 프로젝트에서 배운 점을 공유하고 유사한 프로젝트를 수행할 때 사용 가능한 자원에 관한 정보를 제공하는 것이다. 따라서 본 기사 시리즈가 모든 시나리오에 적용 가능한 포괄적인 마이그레이션 안내서는 아니다.

각자에게 적합한 접근 방식을 결정하려면 MySQL to DB2 Conversion Guide를 참조하거나 SMPO(Software Migration Project Office)에 문의하여 무료로 마이그레이션 평가를 받아보기 바란다. 관련 링크는 참고자료 섹션에서 제공된다.

위로

데이터베이스 마이그레이션 소개

이 기사에서는 MySQL에서 DB2로 데이터베이스를 마이그레이션하기 위한 4가지 기본 단계를 설명한다. 필요하다면 본 시리즈의 파트 1을 참조하여 마이그레이션을 진행하기 전에 전체 마이그레이션 프로세스에서 이런 단계를 스케줄링하는 방법을 확인하기 바란다.

1단계: MySQL 데이터베이스 구조를 DB2 형식으로 변환

• DB2에서 데이터베이스 새로 작성
• 원본 MySQL 데이터베이스 구조 추출
• 데이터베이스의 리버스 엔지니어링으로 엔티티 관계 다이어그램 확보
• 데이터 모델 구조 세분화 및 수정
• 다른 데이터베이스 오브젝트 변환

2단계: MySQL 데이터를 DB2 데이터베이스로 이동

• 불필요한 테이블과 데이터 제거
• 원본 데이터베이스에 있는 데이터 중 대상 DB2 데이터 유형과 맞지 않을 수 있는 데이터 변환
• MySQL에서 데이터 추출
• DB2로 데이터 로드
• 생성된 ID 열 증분 다시 설정

3단계: 사용자 권한 및 데이터베이스 관리 구성 다시 작성

• 필요한 사용자 계정 설정 및 사용자 계정에 알맞은 권한 지정
• 데이터베이스 백업 및 재해 복구 계획 구현
• Cognos 보고 메커니즘에서 사용할 수 있는 미러 시스템을 작성하도록 복제 구성

4단계: 데이터베이스 마이그레이션 기준선 검토

• 데이터베이스 마이그레이션이 완료되었는지 확인한다. 완료되지 않았으면 파트 1의 그림 1에 나타낸 것처럼 마이그레이션이 완료될 때까지 1-3단계를 다시 수행한다.
• 시스템 백업
• 애플리케이션 변환 준비

위로

기존 MySQL PTT 데이터베이스 예제 사례 연구의 이해

이 기사에서 제시하는 예제 데이터베이스의 경우, PTT(Project Tracking Tool)용 원본 MySQL 데이터베이스에 150개의 테이블이 포함되고, 평균적으로 각 테이블에 6개의 열이 있고 총합 약 10GB의 텍스트 데이터가 저장된다. PTT는 원래 MySQL 버전 3.23을 기반으로 빌드되었고 7년간에 걸쳐 버전 5.0으로 마이그레이션했다. 모든 테이블에서 기본 MyISAM 엔진 유형을 사용했다.

PTT 데이터베이스는 ibm.com에 발표된 정보의 워크플로우를 지원하기 위한 다양한 기능에 사용된다. 애플리케이션은 제품 이미지 및 오퍼링 문서와 같은 2진 파일을 처리하지만, 파일은 데이터베이스 자체에 2진 데이터로 저장되지 않고 데이터베이스의 열에 입력된 논리 링크로 파일 시스템에 저장된다.

전 세계 4,000여 명의 사용자가 PHP 웹 프론트 엔드를 통해 이 데이터베이스에 액세스하여 데이터를 수정한다. 어떤 특정 시점에서든, 수백 명의 사용자가 시스템에서 동시에 활동한다.

데이터는 읽기와 쓰기에 모두 사용되는 단일 마스터 MySQL 서버에서 제공된다. 복제본 데이터베이스가 동기화된 상태로 유지되고 읽기 전용 보고 및 임시 쿼리에 사용된다. 데이터는 야간에 백업 및 아카이브된다.

이 기사에서는 새 DB2 시스템에서 유사한 구성을 작성하는 방법을 설명한다. 또한, 데이터베이스 설계를 최적화하고 그 무결성과 데이터 품질을 개선하고 사용하지 않거나 오래된 구조를 제거할 것이다. 이를 통해 이동하는 오브젝트의 수를 줄여 마이그레이션을 간소화하고, 마이그레이션하는 데이터의 크기를 줄여 스토리지 공간을 절약하고, 사용하지 않는 데이터로 인해 혼동이 발생할 가능성을 줄일 수 있다.

위로

마이그레이션 소프트웨어 설치

예제 데이터베이스 마이그레이션을 준비하려면 마이그레이션 단계 수행에 사용할 Windows 워크스테이션에 다음 컴포넌트를 설치한다.

원본 데이터베이스의 MySQL 사본 버전

데이터베이스 마이그레이션은 반복적 프로세스이므로, 손쉬운 액세스를 위해 원본 MySQL 데이터베이스의 사본을 워크스테이션에 설치한다. 이렇게 하면 원격 시스템에 설치했을 때보다 마이그레이션 중에 성능을 더 높일 수 있고, 따라서 마이그레이션 단계를 실행할 때 필요에 따라 원본 데이터베이스를 자유롭게 수정할 수 있다.

DB2의 버전

워크스테이션에서 대상 데이터베이스를 새로 작성하기 위해 DB2를 설치한다. 일반적으로 이 데이터베이스가 프로덕션 환경에서 사용되는 데이터베이스와 같은 에디션일 필요는 없지만, 완벽한 기능 호환성을 위해 같은 에디션으로 설치하는 것이 좋다. 이 기사의 예제를 따라 실습하려면 DB2 Enterprise Server Edition 버전 9.7.2를 설치한다.

IBM Data Movement Tool

MySQL에서 데이터베이스를 추출하여 DB2로 가져오는 데 사용할 수 있는 IBM Data Movement Tool의 최신 버전을 다운로드하여 압축을 푼다(참고자료 참조).

데이터 퍼스펙티브(선택적)를 포함한 IBM의 Eclipse 기반 IDE(Integrated Development Environment)

기존 Rational® Software Architect 배포 버전을 사용할 수 있는데, 이는 이 버전이 데이터베이스 모델을 시각화하고 편집하는 데 사용할 수 있는 올인원 개발 도구이기 때문이다. 참고자료에서 Rational Software Architect와 InfoSphere™ Data Architect, Optim™ Development Studio 등의 유사한 도구에 대한 링크를 찾을 수 있다.

배치할 때 알맞은 단계를 반복할 수 있도록 구성 결정 사항과 습득한 교훈을 신중하게 문서화해야 한다. 향후 데이터베이스 개선점 비교를 위한 구성 백업 및 기준선으로 삼을 수 있도록, 중요한 목표를 달성하는 중요 시점마다 Windows 운영 체제의 스냅샷을 가상 이미지에 저장하는 방안을 고려하자.

실제 머신 구성의 이미지를 캡처하려면 무료 VMware vCenter Converter를 사용하면 된다. 대안으로서, 이런 실습용 변경 작업을 위한 클라우드를 고려해보자. Amazon EC2 DB2 AMI를 사용하거나 IBM Development and Test on the IBM Cloud에 등록할 수 있다. 가상 컴퓨터를 사용하면 서버 하드웨어를 따로 마련하기 위해 초기 투자를 하거나 애쓸 필요가 없고 운영 체제와 DB2를 설치할 수 있으므로, 시간이 절약되고 마이그레이션 프로세스 속도가 빨라지고 더욱 확신을 가지고 자신의 필요에 가장 적합한 구성을 실험할 수 있다. 이러한 모든 제품에 대한 링크는 참고자료에서 찾을 수 있다.

위로

1단계. MySQL 데이터베이스 구조를 DB2 형식으로 변환

워크스테이션에 필수 소프트웨어를 설치한 후, 첫 번째 주요 단계는 MySQL 데이터베이스에서 테이블을 추출하고 이를 새 DB2 데이터베이스에서 다시 작성하는 것이다. 이 단계에서는 다음 하위 단계를 완료해야 한다.

• DB2에서 데이터베이스 새로 작성
• 원본 MySQL 데이터베이스 구조 추출
• 데이터베이스의 리버스 엔지니어링으로 엔티티 관계 다이어그램 확보
• 데이터 모델 구조 세분화 및 수정
• 다른 데이터베이스 오브젝트 변환

DB2에서 데이터베이스 새로 작성

PTT 애플리케이션은 전 세계 곳곳의 사용자를 지원하므로, 새 DB2 데이터베이스가 여러 가지 다른 언어와 문자 세트를 지원할 수 있는지 처음부터 확인하는 것이 중요하다. 이 요구사항을 지원하려면 UTF-8 codeset으로 데이터베이스를 작성한다.

코드 세트를 선택하는 것 외에도, 어떤 데이터 정렬 알고리즘이 목적에 부합할지 평가한다. 데이터 정렬 설정은 DB2가 데이터베이스에서 텍스트를 정렬하고 평가하는 방법을 결정하고, 문자열 비교 성능에 영향을 미칠 수 있다.

MySQL 기반 시스템이 데이터를 처리하는 작동 방식, 즉 대/소문자를 구분하지 않는 방식을 유지하려면 대/소문자 및 문자 정렬을 똑같이 취급하는 UCA500R1_S1 Unicode Collation Algorithm을 선택한다. 이 구성에서는 role, Role 및 rôle이라는 문자열이 똑같이 정렬 및 비교된다.

에는 인코딩 및 데이터 정렬 요구사항을 선택한 후 DB2 데이터베이스를 새로 작성하기 위한 명령이 표시되어 있다. DB2에 함께 제공되는 명령행 프로세서에서 이 명령을 실행할 수 있다. 가독성을 위해 행 바꿈이 추가된다.

			
CREATE DATABASE PTT 
USING CODESET UTF-8
TERRITORY US 
COLLATE USING UCA500R1_S1
PAGESIZE 4096;

데이터베이스를 작성할 때 여러 개의 기본값을 허용하여 DB2가 내장된 자동 기능을 사용하여 여러 가지 유지보수 태스크를 자동으로 처리하도록 할 수 있다. 예를 들어, 기본적으로 자동 저장이 설정되고 자동 튜닝 메모리 관리자가 작동한다.

데이터베이스를 작성할 때 다른 다양한 옵션을 지정할 수 있다. 무턱대고 데이터베이스를 사용하다가 나중에야 설정을 변경하여 적용하는 것보다는 처음부터 데이터베이스를 올바르게 구성하는 것이 현명한 방법일 것이므로, 설정을 잘 검토하고 조사하는 것이 당연하다. MySQL to DB2 Conversion Guide(참고자료 참조)의 6.2.1절에 이런 옵션 중 다수가 상세히 설명되어 있다.

원본 MySQL 데이터베이스 구조 추출

다음 태스크는 MySQL에서 데이터베이스 구조를 추출하여 DB2로 로드하는 것이다. 작은 데이터베이스가 있는 경우 mysqldump 유틸리티를 사용하여 MySQL에서 원본 DDL을 추출하고, 그와 동등한 DB2 구문에 일치하도록 수동으로 수정할 수 있다. MySQL to DB2 Conversion Guide(참고자료 참조)의 6.1절에 각 데이터 유형에 대한 설명과 이를 맵핑할 수 있는 방법을 보여주는 테이블이 나와 있다.

이 기사의 예제에서 150개의 테이블을 포함한 데이터베이스와 같이 큰 데이터베이스의 경우, IBM Data Movement Tool을 사용하여 데이터베이스 구조의 추출을 자동화하는 방안을 고려하자. IBM Data Movement Tool은 로컬 MySQL 데이터베이스와 새로 작성된 DB2 데이터베이스에 모두 연결하도록 구성된 간단한 사용자 인터페이스를 제공한다. 이 단계에서 IBM Data Movement Tool을 사용하여 데이터베이스 구조를 추출하는 방법을 설명한 상세 지시사항은 참고자료를 참조한다.

그림 1에 표시된 것처럼, 예제에서는 Data 선택란만 선택하고 Extract DDL/Data를 클릭한다.

IBM Data Movement Tool이 데이터베이스 구조를 추출하고 나면, migr 디렉토리에 DDL 파일 목록이 생긴다. 그 중 일부 파일은 빈 파일일 수도 있다. 예를 들어, 예제 원본 MySQL 데이터베이스에는 사용자 정의 기능이 없기 때문에 db2udf.sql 파일에는 아무런 컨텐츠도 없다.

DDL 파일과 같은 디렉토리에 있는 db2ddl.cmd 일괄처리 작업을 실행하여 로컬 DB2 데이터베이스로 DDL을 로드한다.

데이터베이스의 리버스 엔지니어링으로 엔티티 관계 다이어그램 확보

DDL이 DB2로 로드되었으면, RSA가 DB2에 존재하므로 RSA를 사용하여 데이터베이스 구조를 리버스 엔지니어링한다. 새로 작성된 DB2 데이터베이스에 연결하고 Rational Software Architect를 사용하여 비주얼 모델을 추출한다. 리버스 엔지니어링이라고 하는 이 프로세스는 테이블, 테이블의 열, 열 사이의 연계를 보여주는 엔티티 관계(ER) 다이어그램으로 데이터베이스를 변환한다.

이 단계에서는 사용하지 않는 테이블을 모두 제거하고, 특정 열의 데이터 유형을 변경하고, 기본 및 외부 키를 추가한다. 이것은 선택적 태스크이지만, 현재의 필요에 보다 적합하게 데이터 구조를 다시 구성할 수 있는 좋은 기회를 제공한다.

DB2 구문에 맞춰 DDL을 수동으로 편집하여 데이터 모델을 수정하기로 다시 결정할지도 모르지만, ER 다이어그램의 형태로 비주얼 모델을 생성하면 데이터 구조를 보고 문서화하고 유지보수하는 데 도움이 된다. 이 ER 다이어그램은 기술 팀과 비즈니스 이해 관계자에게 똑같이 유용한 문서화의 역할을 할 수 있다.

다이어그램을 생성하고 다음의 관련 태스크를 실행하여 앞서 나열한 이점을 실현할 수 있다.

테이블 또는 뷰 사이의 관계 빌드

이는 관계형 데이터베이스의 테이블이 함께 작동하는 방식을 이해하는 데 도움이 된다.

공통 기능에 도움이 되는 테이블을 색상 코드로 표시

예제에서는 USER, ACL 및 ROLE 테이블이 함께 작동하여 인증 및 권한 부여를 처리하므로, 모델에서 이런 테이블에 공통의 배경색을 지정하여 테이블을 논리적으로 연관시킬 수 있다.

데이터 구조 마이그레이션 프로세스 중에 수정된 열 강조표시 및 변경된 이유를 설명하는 주석 추가

도중에 어떤 열과 테이블이 수정되었는지 추적하는 데 도움이 된다.

InfoSphere Data Architect에서 이 작업의 완료 방법을 읽으면 기존 데이터베이스를 데이터 모델로 리버스 엔지니어링하는 방법을 자세히 학습할 수 있다(참고자료 참조). 이런 지시사항은 Eclipse Data Tools Platform을 기반으로 빌드된 IBM의 Eclipse 기반 IDE에서 실행할 때와 비슷하다. 튜토리얼에서 예제로 사용되는 Apache Derby 데이터베이스를 사용하지 말고, DB2 데이터베이스에 연결해야 할 것이다.

데이터 모델 구조 세분화 및 수정

ER 다이어그램을 생성했는지에 상관없이, 이 지점에서 데이터 구조 개선에 착수할 수 있다. 예제에서 사용되는 구조를 이렇게 수정하는 것을 생각해보자.

기본 키와 기본 키에 의지하는 모든 외부 키 사이에 데이터 유형의 일관성 확인

예를 들어, USER 테이블에서 기본 키 데이터 유형은 SMALLINT이지만, 다른 테이블에서 이 기본 키를 논리적으로 참조하는 USER_ID 외부 키는 더 큰 수의 INTEGER 데이터 유형이었다. 이 데이터 유형은 원래 두 데이터 유형이 일치할 필요가 없는 외부 키의 적용을 지원하지 않는 MySQL 버전에서 작성되었기 때문에, MySQL 데이터베이스 구조에서 종종 이를 발견할 수 있다.

필요한 경우 ID 열의 최대 크기 확대

애플리케이션을 사용한 지 오래된 경우, ID 열의 값이 지정된 최대 한계에 접근하기 시작할 수 있다. 마이그레이션은 이런 잠재적 문제점을 해결하는 좋은 기회가 된다. 예를 들어, USER 테이블의 ID가 SMALLINT로 지정되어 있고 사용자 수가 앞으로 32,767명을 초과할지도 모르는 경우, ID를 더 큰 INTEGER 유형으로 확대해야 하며, 그러면 앞으로 최대 20억 명의 사용자를 지원할 수 있다.

가능한 경우 MySQL TEXT 필드를 DB2 CLOB 텍스트 오브젝트 유형에서 VARCHAR 문자 유형으로 변경

DB2에서는 CLOB에 몇 가지 제한사항이 있다. CLOB를 사용하여 DISTINCT 값을 찾을 수 없고, CLOB를 버퍼 풀로 로드할 수 없다. 따라서 CLOB는 페이지 캐시를 이용할 수 없으므로 CLOB가 올바로 작동하지 않을 수도 있다. 가능하면 TEXT 필드를 VARCHAR로 변경하는 방안을 고려해야 한다. 기본 테이블스페이스가 VARCHAR 열의 최대 크기를 한정하므로, 최대 32KB의 텍스트만 저장될 수 있다.

오래되었거나 사용하지 않는 열 삭제

예를 들어, 어떤 애플리케이션은 다른 방법으로 보고서를 저장하므로, 이제는 중요하지 않고 오히려 팀에 새로 합류한 개발자에게 혼동만 주는 대량의 데이터를 가진 큰 레거시 테이블이 여러 개 있을지도 모른다. 이 기회에 이런 데이터를 아카이브하고 활성 데이터베이스에서는 제거하자.

필요한 경우 기본 키 또는 고유의 제한조건 추가

키 제한조건이 제공하는 데이터 무결성을 넘어, 이것은 DB2 복제에 매우 중요하다. 각 테이블에서는 백업 데이터베이스로 고유의 값을 전송하기 위해 기본 키나 고유 키가 필요하다.

새 외부 키 정의 및 적용

예제 MySQL 데이터베이스에서는 애플리케이션이 원래 외부 키를 지원하지 않는 기본 MyISAM 스토리지 엔진으로 작성되었기 때문에 외부 키가 없다. 데이터 변환 단계 중에 TASK_HISTORY 테이블에 연결된 USER 테이블을 유지하는 것과 같이 데이터 일관성을 개선하기 위해 필수적인 외부 키를 추가하여 사용자에 대한 변경사항을 연결하는 감사 레코드가 파손되지 않도록 한다.

인덱스, 뷰, 스토어드 프로시저 및 함수와 같은 다른 오브젝트 변환 또는 추가

데이터 구조를 시각화하면 테이블, 테이블의 상대적 중요성 및 성능에 영향을 미칠 수 있는 액세스 빈도 사이의 관계를 이해하는 데 도움이 될 수 있다. 이를 통해 데이터 품질과 읽기 속도를 개선하기 위해 제한조건을 적용해야 하는 곳과 관련 조치를 함께 그룹화해야 하는 곳을 더욱 정확히 파악할 수 있다.

RSA에서 정의된 새로운 데이터 구조 모델이 있는 경우 새 DB2 데이터베이스를 빌드할 원본이 되는 단일 DDL 파일로 이 모델을 내보낼 수 있다. 데이터베이스 구조의 복잡도에 따라, 다른 유형의 오브젝트가 모든 것을 논리적으로 구성한 상태로 유지할 수 있도록 별도의 DDL 파일을 생성하는 방법도 생각할 수 있을 것이다.

예를 들어, 반복적 마이그레이션에 권장되는 접근 방식은 한 파일에 테이블에 대한 DDL을 생성하고, 인덱스에 대한 DDL과 외부 키에 대한 DDL은 각기 별도로 생성하는 것이다. 이 접근 방식은 논리적으로 관계가 있는 조각으로 데이터 구조를 논리적으로 구분하는 데 도움이 된다. 이 접근 방식에서는 테이블 및 뷰와 같이 더욱 영구적인 다른 오브젝트의 정의 외에도, DDL 파일에서 (시간에 따라 변하는) 인덱스를 찾지 않고 현재 인덱스 목록을 보려는 경우 참조할 수 있는 문서를 제공한다.

앞서 설명한 리버스 엔지니어링 태스크와 마찬가지로, 참고자료의 InfoSphere 문서에 있는, 실제 데이터 모델을 DDL로 변환하는 방법을 설명한 튜토리얼을 읽어보면 IBM의 Eclipse 기반 도구를 사용하여 데이터 모델을 수정하고 내보내는 방법을 학습할 수 있다.

다른 데이터베이스 오브젝트 변환

IBM Data Movement Tool은 테이블, 키, 인덱스 및 테이블스페이스와 같은 대부분의 데이터베이스 오브젝트를 자동으로 변환할 수 있지만, 원본 MySQL 데이터베이스에 있는 경우 수동으로 변환할 필요가 있는 다른 오브젝트도 있다. 뷰, 스토어드 프로시저, 사용자 정의 함수(UDF), 트리거 등이 그런 오브젝트이다.

MySQL과 DB2 모두 SQL:2003 스토리지 프로시저 구문을 고수하므로, 이런 오브젝트를 수동으로 마이그레이션하기 어렵지 않다. 그리고 DB2 트리거 기능은 MySQL에서 사용 가능한 기능의 슈퍼세트를 제공하므로, 트리거를 손쉽게 다시 작성할 수 있다. IBM Redbook Developing PHP Applications for IBM Data Servers의 6장에 알아야 할 차이점이 상세히 설명되어 있다.

다른 방법으로서, 2단계의 데이터 마이그레이션 중에 오류가 발생하지 않도록 하기 위해, DB2로의 데이터 로드가 완료될 때까지 이 태스크를 미루었다가 데이터베이스를 세분화할 때 이 마이그레이션 단계 중의 다른 반복 프로세스에서 이 태스크를 수행할 수도 있다.

위로

2단계. MySQL 데이터를 DB2 데이터베이스로 이동

이 단계에서는 MySQL 데이터베이스에서 데이터를 추출하여 DB2로 로드한다. 이 프로세스에서는 데이터 품질을 개선할 기회도 주어진다. 이 단계에서는 다음 단계를 완료해야 한다.

• 불필요한 테이블과 데이터 제거
• DB2에 부적당한 MySQL 데이터 변환
• MySQL에서 데이터 추출
• DB2로 데이터 로드
• 생성된 ID 열 증분 다시 설정

불필요한 테이블과 데이터 제거

IBM Data Movement Tool에서는 데이터베이스 테이블마다 SELECT 쿼리를 지정하여 원본 데이터베이스에서 추출할 데이터를 명시하는 table name.tables 파일을 생성한다. 이 예제에서는 4년 미만의 태스크만 포함시킨다. 이동할 데이터의 양을 필터링하기 위해 일부 행의 전체를 제거하고 WHERE 문으로 다른 행을 한정할 필요가 있다.

MySQL에서 DB2로 어떤 테이블을 이동하지 않으려면 이 파일에서 해당 테이블 전체를 제거해야 한다. 데이터의 서브세트를 이동하려면 SELECT 절을 적절히 수정해야 한다. 이 예제에서는 리스트 2에 표시된 행을 삭제하여 WORK_TMP 테이블이 DB2로 마이그레이션되지 않도록 한다.

		
"timetrac"."work_tmp":SELECT * FROM "timetrac"."work_tmp"

다른 경우에는 2008년 이후로 작성된 WORK 테이블에 있는 데이터만 유지하고 싶을 수도 있다. 이 예제의 경우 리스트 3에 표시된 것처럼 WHERE 절을 추가하자.

		
"timetrac"."work":SELECT * FROM "timetrac"."work" WHERE ts >= '2008-01-01'

DB2에 부적당한 MySQL 데이터 변환

또 다른 중요한 태스크는 원본 데이터베이스와 새 데이터베이스에 있는 데이터 유형 사이의 호환성을 결정하는 것이다. 데이터 모델을 다시 구성한 1단계에서 DB2 데이터베이스를 수정했기 때문에, MySQL에서 가져온 데이터가 DB2에 정의된 데이터 유형과 호환 가능했는지 확인하자.

예를 들어, TIME 데이터 유형은 MySQL과 DB2에 모두 존재하지만 범위는 다르다. MySQL에서는 TIME이 -838:59:59에서 838:59:59 범위의 시계를 나타낸다. 그러나 DB2에서는 TIME이 00:00:00에서 24:00:00 범위의 24시간 단위 시계로 표시된다. 24시간 단위의 시계에 적합하지 않은 TIME 데이터 유형을 가진 데이터가 있는 경우, MySQL에서 DB2 데이터 유형과 호환되도록 데이터를 정규화한 후 마이그레이션한다. 리스트 4 는 변환 작업에 사용할 수 있는 SQL문을 나타낸 것이다.

		
mysql> UPDATE WORK W SET W.HOUR = SUBTIME(W.HOUR, '24:00:00') WHERE W.HOUR >= '24:00:00';

마이그레이션하기 전에 원본 데이터베이스를 변경해야 하는 다른 데이터 유형이 있을지도 모른다. MySQL to DB2 Conversion Guide(참고자료 참조)의 6.1절에 각 데이터 유형에 대한 설명과 데이터 호환성을 보여주는 테이블이 나와 있다.

MySQL에서 데이터 추출

마이그레이션을 위해 MySQL의 데이터를 알맞게 준비한 상태에서, 그림 2에 표시된 것처럼 IBM Data Movement Tool을 다시 열고 Data 선택란을 선택하고 Extract DDL/Data를 클릭한다.

위 작업을 완료하면 migr 폴더에 geninput, rowcount, timetrac.tables(여기서 timetrac은 데이터베이스 이름임), unload라는 4개의 파일이 표시된다.

timetrac.tables 파일 이름을 데이터베이스 추출 단계 후에 데이터를 서브세트로 제한하기 위해 편집한 파일 이름으로 바꾼다. MySQL에서 unload를 실행하여 데이터를 추출한다. 마이그레이션이 완료된 후, IBMDataMovementTool.log 파일에 오류 메시지가 있는지 확인한다. 로드 해제에 성공하면 db2load.cmd 파일과 데이터 폴더를 포함하여 많은 파일이 생성되어 있을 것이다.

DB2로 데이터 로드

migr 디렉토리로 이동하고 db2load.cmd 일괄처리 스크립트를 실행하여 실제로 DB2로의 데이터 마이그레이션을 수행한다.

db2load.log를 살펴보고 모든 데이터가 DB2로 올바르게 로드되었는지 확인한다. IBM Data Movement Tool에서는 원본 MySQL 데이터베이스의 행 번호가 DB2 테이블의 행 번호와 같은지 확인하기 위한 스크립트를 제공한다. rowcount 명령을 실행하여 번호가 일치하는지 확인할 수 있다.

이런 차원을 넘어, 중요한 쿼리의 출력을 비교하는 것과 같이 다른 방법을 사용하여 DB2의 데이터를 신중하게 확인하고 싶을 수도 있을 것이다. MySQL to DB2 Conversion Guide(참고자료 참조)의 7.2.7절에 마이그레이션된 데이터를 확인하기 위한 몇 가지 전략이 소개되어 있다.

생성된 ID 열 증분 다시 설정

데이터를 이동한 후, 자동으로 생성된 ID 열에 대해 마이그레이션된 데이터에 있는 기존의 모든 값보다 높은 번호로 매기기 시작하기 위해 데이터베이스를 업데이트할 필요가 있을 수도 있다. 예를 들어, 마이그레이션한 데이터에 3,000개의 행이 있는 경우 ID를 1부터 시작해서 지정하여 충돌을 일으키는 대신, 3,000보다 높은 안전한 숫자(예: 5,000)부터 삽입하는 방법으로 새 레코드에 대한 ID를 생성하기 시작하도록 데이터베이스를 수정할 수 있을 것이다. 리스트 5 에서는 생성된 ID 열 번호 매기기를 다시 설정하기 위해 열 정의를 수정한 것을 보여준다.

ALTER TABLE WORK ALTER COLUMN ID RESTART WITH 5000;

위로

3단계. 사용자 권한 및 데이터베이스 관리 구성 다시 작성

데이터베이스 구조와 데이터를 DB2로 가져온 상태에서, 세 번째 중요 단계는 그 데이터에 대한 액세스 권한과 관리가 알맞은지 확인하는 것이다. 필요한 사용자 계정을 설정하고 사용자 계정에 알맞은 권한을 지정할 필요가 있다. 그런 다음 조사 결과 DB2에 설치할 방법을 결정한 기존 시스템과 DB2 전문가의 자문을 받은 정보를 바탕으로 데이터베이스 백업 및 재해 복구 구성을 구현한다. 마지막으로, Cognos® 비즈니스 인텔리전스 시스템에서 보고서 생성을 위해 사용할 미러 시스템을 작성하도록 복제를 구성한다.

이 단계에서는 다음 하위 단계를 완료해야 한다.

• 권한 모델 변환
• 백업 및 복원 프로시저 변환
• 보고 복제 모델 변환

권한 모델 변환

DB2를 설치할 때 기본 인스턴스 소유자 사용자 ID db2inst1을 작성했다. MySQL 데이터베이스에는 이와 유사한 관리 사용자 root가 있었다. 따라서 일반적으로 루트 사용자에 의해 실행되는 기능을 수행해야 할 때는 언제든 db2inst1을 대신 사용할 것이라는 점이 분명하다.

다른 두 개의 사용자 계정도 작성해야 한다. 사용자 pttuser는 애플리케이션에서 요구하는 읽기 및 쓰기 조작을 수행한다. 사용자 read는 프로덕션 및 복제본 데이터베이스에서 모두 필요하다. 이 계정은 프로덕션 데이터베이스에서 읽기 전용 쿼리를 수행하는 데 필요하다. 복제본 데이터베이스의 Cognos 보고 메커니즘에서도 read 계정을 사용한다. 표 1에 이런 계정이 표시되어 있다.

Linux 운영 체제에서는 이런 사용자 계정을 작성할 수 있고, GRANT 문을 사용하여 이런 계정에 알맞은 데이터베이스 권한을 지정한다. 이는 DB2 데이터베이스를 작성하고 MySQL에서 이 데이터베이스로 데이터를 마이그레이션한 후 별개의 작업으로 완료되는 것이 보통이다. 하지만, 프로덕션 환경에 배치할 때 데이터베이스 구조를 작성할 때 사용하는 것과 같은 DDL에 GRANT 문을 포함시킬 것이다.

MySQL에서는 (연결하는 호스트 이름으로 정규화된) 사용자에게 전체 데이터베이스에 대한 읽기, 쓰기 또는 다른 관리 권한을 부여할 수 있으므로, 액세스 권한 제공이 정교하지 않게 이루어지는 경우가 많다. 예제에서는 사용자 pttuser가 (웹 서버의 호스트 이름에서만) 데이터베이스에 대한 읽기 및 쓰기 액세스 권한을 가지고 있으므로, 그 안에 있는 각각의 테이블에 액세스하고 수정할 수 있다.

DB2에서는 사용자에 대한 액세스 권한을 부여하지만, 사용자가 연결하는 호스트 이름을 표시하지는 않는다. 또한, DB2에서는 MySQL에서처럼 데이터에 대한 쿼리, 추가 또는 업데이트 액세스 권한을 지정할 수 있다. 하지만, (권장되는 방법은 아니지만 그 사용자로서 데이터베이스와 테이블을 작성하지 않았다면) 전체 데이터베이스에 대한 액세스 권한을 부여할 수 있는 단일 명령이 없기 때문에, 데이터베이스에 있는 각각의 테이블에 대해 사용자에게 액세스 권한을 부여해야 한다. 따라서 테이블과 같은 오브젝트가 작성된 후 GRANT 명령이 DDL에 포함되는 경우가 종종 있다.

리스트 6 은 예제에서 WORK 테이블에 부여할 권한을 보여준다. 애플리케이션 사용자는 전체 읽기 및 쓰기 액세스 권한을 받는 반면, 보고 사용자는 데이터를 읽을 수만 있다.

-- GRANT statements to provide read/write access to the application user account
GRANT DELETE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT INSERT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER";  
GRANT UPDATE ON TABLE "TIMETRAC"."WORK" TO USER "PTTUSER"; 

-- GRANT statement to provide read only access to the reporting/ad hoc user account
GRANT SELECT ON TABLE "TIMETRAC"."WORK" TO USER "READ";

MySQL to DB2 Conversion Guide(참고자료 참조)의 7.1.3절에 DB2에서 제공하는 사용자 계정 관리 및 세분화된 옵션의 차이점에 대한 상세한 정보가 설명되어 있다.

백업 및 복원 프로시저 변환

가용성이 높은 애플리케이션에 대한 필요성과 데이터를 조심스럽게 아카이브해야 한다는 요구사항을 균형적으로 조절해 줄 재해 복구 계획을 구현할 준비가 되었다.

MySQL에서는 mysqldump와 같은 명령을 사용하여 데이터를 백업하고 SQL을 실행하여 데이터를 복원할 수도 있다. 예제로 든 시스템에서는 mysqldump를 사용하여 야간에 백업하는 방법을 선택하고 라이브 장애 복구 시스템으로서 이중의 임무를 수행하는 읽기 전용 보고용으로 동기화된 복제본 데이터베이스를 실행하려고 한다.

새 데이터베이스에 대해, DB2와 함께 제공되는 도구를 사용하여 백업 및 복원 명령을 스케줄링한다. 이런 명령을 사용하여 오프라인이나 온라인으로 전체 또는 증분 백업을 수행하기 위한 여러 가지 옵션이 있다. 예를 들어, 매일 한 번씩 온라인 증분 백업을 수행하고, 유지보수 기간 중에 매주 한 번씩 오프라인으로 전체 백업을 수행할 수 있을 것이다. 표 2 는 백업 및 복원 정책과 스케줄의 예를 나타낸 것이다.

MySQL to DB2 Conversion Guide(참고자료 참조)의 9장에 설명된 내용이 새로운 백업 및 복구 프로세스를 결정하고 구현하는 데 핵심적인 사항이 될 수 있다. 여기서는 DB2 Control Center 또는 Optim™ Development Studio를 사용하여 백업을 실행하도록 스케줄링하는 방법에 대한 샘플 백업 명령 및 포인터를 제공한다.

보고 복제 모델 변환

파트 1에서 언급한 바와 같이, Cognos와 같은 도구를 채택하여 비즈니스 인텔리전스를 개선하는 것이 DB2로의 마이그레이션을 이끄는 핵심 요인이어야 한다. 따라서 쿼리를 실행하고 보고서를 추출하는 복제본 데이터베이스의 구성이 데이터베이스 마이그레이션 작업의 중대한 부분이 되어야 한다.

데이터에 대한 보고서를 실행해야 하는 경우 마스터 프로덕션 데이터베이스에 대한 로드를 줄이기 위해 읽기 전용 복제본 데이터베이스를 가지고 있을 가능성이 매우 높다. 복제본 데이터베이스는 운영 중인 데이터베이스의 정확한 사본이다. 데이터베이스의 마스터 인스턴스에 대한 정보에 액세스하여 이를 수정하는 애플리케이션을 실행하고, 복제본 데이터베이스로 모든 데이터를 복제하고, 데이터베이스의 읽기 전용 인스턴스에 대한 모든 보고서를 실행한다.

이때도 MySQL과 DB2는 복제를 서로 다른 방식으로 처리한다. MySQL을 사용할 때는 몇몇 구성 매개변수를 변경하고 한 서버에서 다른 서버로 실시간으로 전체 데이터베이스를 복제할 수 있다. 또는 백업해두었다가 나중에 다른 데이터베이스로 비동기식으로 복원할 수도 있다.

DB2를 사용할 때는 SQL 복제와 Q 복제를 포함한 유사한 옵션을 사용할 수 있다. 이 예제에서는 Q 복제를 처리하는 데 필요한 채널 기반 메시지 큐 관리자에 의해 복잡도가 더 높아지지 않도록 하기 위해 SQL 복제를 사용한다. SQL 복제를 사용할 때는 복제하려는 데이터베이스에 있는 각각의 테이블을 지정하는 구성을 작성한다. 데이터베이스 구조를 변경할 때마다 그 구성을 반드시 업데이트해야 할 것이다.

또한, DB2에서 복제를 설정하기 전에 데이터베이스 테이블마다 기본 키 또는 고유 인덱스가 있는지 확인하고 싶을 것이다. 이는 좋은 방법이긴 하지만, 어떤 데이터베이스에서는 이를 빠뜨릴지도 모른다. 예제로 든 MySQL 테이블은 기본 MyISAM 스토리지 엔진으로 작성되었기 때문에 이런 값을 빠뜨렸다는 점을 기억하자. MySQL 복제는 키나 인덱스 없이 작동한다. 하지만, DB2 복제에서는 테이블의 행을 고유하게 식별하기 위해 키나 인덱스가 필요하다. 테이블에 기본 키나 고유 인덱스가 없는 경우, 업데이트 중인 레코드를 찾을 때 사용할 키가 없기 때문에 운영 중인 데이터베이스에서 업데이트되는 레코드가 업데이트되는 기존 레코드 대신 새로 작성되는 레코드로 보일 수 있다.

MySQL to DB2 Conversion Guide(참고자료 참조)의 9장이 복제 구성 전략의 중심이 될 것이다. DB2에서는 복제 설정을 관리하는 데 사용할 수 있는 도구를 제공하거나, 사용자가 직접 로그 전송을 바탕으로 사용자 정의 솔루션을 구현할 수 있다.

위로

4단계. 데이터베이스 마이그레이션 기준선 검토

1-3단계가 차례대로 여러 번 반복되어 한 차례 완전히 반복한 이 시점에서는, Windows 워크스테이션에서 작동하는 데이터베이스 시스템과 변경한 내용과 문제점이 있었던 사항에 대한 특별한 참고 사항이 있을 것이다.

가상 머신을 사용한 경우 올바로 작용하는 저장 지점으로서 아카이브하고 향후 성능 변화의 비교를 위한 기준선으로 사용할 두 가지 목적으로, Windows 시스템의 이미지를 스냅샷으로 캡처했다. 물론, IBM 또는 Amazon Cloud에서 가상 이미지를 사용하고 그것을 같은 방식으로 사용하는 것이 또 하나의 옵션이다.

자신의 환경에 가장 적합한 방법을 확인하기 위해 여러 가지 다른 마이그레이션 방법을 실행하며 실험해보고 싶을지 모르겠다. 1-3단계에서 사용한 Windows 워크스테이션의 시스템에 만족한다면, 본 기사 시리즈의 파트 3에 있는 PHP 애플리케이션에 대한 업데이트를 테스트해 볼 전용 서버로 데이터베이스를 이동할 수 있다.

위로

결론

본 기사 시리즈의 목표는 MySQL에서 DB2로 PHP 애플리케이션을 마이그레이션하는 데 일반적으로 필요한 사항, 이때 사용 가능한 자원, 성공적인 마이그레이션 사례를 소개하는 것이다.

이번 두 번째 시리즈 기사에서 살펴본 내용은 다음과 같다.

• 변환한 원본 MySQL 데이터베이스에 대한 학습
• 데이터베이스 구조를 DB2로 변환하는 방법 학습
• 데이터를 DB2로 마이그레이션하는 방법 학습
• 데이터베이스 관리를 설정하는 방법 학습

본 시리즈의 다음 파트에서는 PHP 코드를 변환하는 방법을 학습할 것이다.

감사의 인사

본 기사의 작성자 일동은 Leons Petrazickis와 Ambrish Bhargava가 기사를 검토하고 의견을 주신 데 대해 감사의 말씀을 드린다.

참고자료

교육

• RSS 피드를 사용하여 곧 공개될 이 시리즈 기사에 대한 소식을 요청하자. (developerWorks 컨텐츠의 RSS 피드에 관해 자세히 확인해보자.)
  
  
• IBM Redbooks에서 무료로 제공하는 MySQL to DB2 Conversion Guide를 사용하여 마이그레이션을 계획하고 실행해보자.
  
  
• 무료로 제공되는 Developing PHP Applications for IBM Data Servers IBM Redbook을 참조하여 샘플 애플리케이션을 사용해 DB2에서 PHP 애플리케이션을 구성, 실행 및 테스트하는 방법을 파악하자.
  
  
• MySQL에서 DB2로의 데이터베이스 오브젝트 및 데이터 마이그레이션에 도움이 될 수 있는 무료 IBM Data Movement Tool을 다운로드하고 학습해보자.
  
  
• 기존 데이터베이스를 데이터 모델로 리버스 엔지니어링하는 방법을 자세히 알아보려면 이 Information Center 주제를 읽어보자.
  
  
• IBM의 Eclipse 기반 도구를 사용하여 실제 데이터 모델을 DDL로 변환하는 방법을 알아보려면 InfoSphere 문서를 읽어보자.
  
  
• DB2로의 ISV 애플리케이션 마이그레이션에 대해 Daniel Krook이 블로그에 올린 Writing SQL for both MySQL and DB2라는 글을 읽어보자.
  
  
• 특정 개발 주제에 대한 자세한 정보는 Recommended reading list: DB2 for Linux, UNIX, and Windows application development를 참조한다.
  
  
• 특정 관리 주제에 대한 자세한 정보는 Recommended reading list: DB2 for Linux, UNIX, and Windows database administration을 참조한다.
  
  
• Raul F. Chong, Xiaomei Wang, Michael Dang 및 Dwaine R. Snow가 공동 집필하여 IBM Press에서 발표한 Understanding DB2: Learning Visually with Examples, 2nd Edition을 참조하여 DB2를 익히고 그 기능을 심층 학습해보자.
  
  
• George Baklarz와 Paul C. Zikopoulos가 공동 집필하여 IBM Press에서 발표한 DB2 9 for Linux, UNIX, and Windows: DBA Guide, Reference, and Exam Prep, 6th Edition을 참조하여 DB2 애플리케이션 개발 및 관리에 대해 자세히 알아보자.
  
  
• Leverage MySQL skills to learn DB2 Express: DB2 versus MySQL backup and recovery로 데이터를 안전하게 보존할 수 있는 전략을 알아보자.
  
  
• Leverage MySQL skills to learn DB2 Express: DB2 versus MySQL administration and basic tasks를 참조하여 도구, SQL 구문, 동시성 옵션 및 권한을 얻자.
  
  
• Leverage MySQL skills to learn DB2 Express: DB2 versus MySQL data movement를 탐색하여 MySQL 및 DB2 내에서 사용 가능한 가져오기 및 내보내기 도구에 대해 알아보자.
  
  
• Leverage MySQL skills to learn DB2 Express: DB2 versus MySQL graphical user interface에서 데이터베이스 시스템 관리를 위한 시각적 도구에서 사용 가능한 기능을 비교해보자.
  
  
• IBM DB2 functions in the official PHP documentation 및 PDO driver에서 PHP에 권장되는 2개의 DB2 인터페이스에 대해 알아보자.
  
  
• 정보 관리 우수 사례에서는 본 기사의 사례 연구에서 사용된 Information Modeling with Rational Data Architect Version 7과 같이 사용 가능한 도구를 최선으로 활용하는 방법과 공통 해결 과제에 대한 최적의 해결책을 제시하는 논문 시리즈를 확인할 수 있다.
  
  
• IBM Smart Business Development and Test on the IBM Cloud를 빠르게 살펴보자.
  
  
• Best practices for DB2 for Linux, UNIX, and Windows: Cost reduction strategies with DB2에서 DB2 성능 최적화에 대한 개론을 읽어보자.
  
  
• Best practices: Writing and tuning queries for optimal performance에서 DB2 쿼리 튜닝 최적화에 대한 소개 자료를 읽어보자.
  
  
• Migration station에서는 다른 데이터베이스, 애플리케이션 서버 및 운영 체제에서 IBM 소프트웨어로의 마이그레이션에 대한 자세한 정보를 확인할 수 있다.
  
  
• developerWorks Information Management 영역에서는 Information Management에 대한 정보를 제공한다. 기술 자료, 사용법 기사, 교육, 다운로드, 제품 정보 등을 찾아볼 수 있다.
  
  
• developerWorks 기술 행사 및 웹 캐스트를 통해 최신 정보를 얻을 수 있다.
  
  
• Twitter의 developerWorks 페이지를 살펴보자.
  
  

제품 및 기술

• IBM DB2 e-kit for Database Professionals를 다운로드하여 DB2 기능을 학습하고 기존 데이터베이스 관리 및 애플리케이션 개발 스킬을 활용하고 DB2 커뮤니티에 참여하고 인증 시험을 준비하자.
  
  
• Software Migration Project Office DB2 migration team을 통해 무료 마이그레이션 평가를 받을 수 있다.
  
  
• IBM Smart Business Development and Test on the IBM Cloud를 사용하여 IBM Cloud에서 PHP/DB2 애플리케이션을 작성하고 확인하자.
  
  
• DB2 on Amazon EC2를 평가해보자.
  
  
• Linux, Windows 또는 IBM i에서 높은 수준의 신뢰성, 성능 및 보안이 요구되는 PHP 애플리케이션을 실행하고 관리하기 위한 완벽한 엔터프라이즈급 웹 애플리케이션 서버에 대한 자세한 내용은 Zend Server를 확인해보자.
  
  
• Zend Server에는 DB2 드라이버가 포함되지만, 고유의 PHP 구성을 가진 경우 PECL 또는 Windows binaries on SourceForge에서 드라이버 확장 소스를 찾을 수 있다.
  
  
• DB2 training and certification에 대해 자세히 알아보거나 Information Management bootcamp에 참석하자.
  
  
• 무료로 제공되는 DB2 Express-C 데이터 서버를 다운로드하여 설치하자.
  
  
• Rational Software Architect 또는 InfoSphere Data Architect를 사용하여 논리 및 실제 데이터 모델링을 수행할 수 있다.
  
  
• Optim Development Studio를 사용하여 DB2 기반 애플리케이션을 개발하고 최적화할 수 있다.
  
  
• 무료 VMware vCenter Converter를 활용하여 실제 머신을 가상 이미지로 변환할 수 있다.
  
  
• developerWorks에서 직접 다운로드할 수 있는 IBM 시험판 소프트웨어를 사용하여 후속 개발 프로젝트를 구현해 보자.
  
  

토론

• 포럼에 참여하기.
  
  
• PHP forum: Developing PHP applications with IBM Information Management products (DB2 and Informix)에서 질문을 검색, 모니터링 및 제출할 수 있다.
  
  
• DB2 Application Enablement 포럼에서 IBM Data Management Tool에 대한 질문을 제출할 수 있다.
  
  
• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

아티클 순위

의견

위로

목차

• 시리즈 소개
• 데이터베이스 마이그레이션 소개
• 기존 MySQL PTT 데이터베이스 예제 사례 연구의 이해
• 마이그레이션 소프트웨어 설치
• 1단계. MySQL 데이터베이스 구조를 DB2 형식으로 변환
• 2단계. MySQL 데이터를 DB2 데이터베이스로 이동
• 3단계. 사용자 권한 및 데이터베이스 관리 구성 다시 작성
• 4단계. 데이터베이스 마이그레이션 기준선 검토
• 결론
• 참고자료
• 필자소개
• 의견