프로젝트를 수행하다 보면 전문 마이그레이션 팀이 없는 경우 모델러나 튜너로 투입되어도 종종 마이그레이션을 지원할 때가 있다. 마이그레이션 검증이나 모니터링 지원이 대부분이지만 마이그레이션 절차에 대해 회의할 때는 경악할 때가 많다.

모 금융권에 튜너로 투입되었을 때의 일화다. 당시 여러 가지 문제로 인해 1:1 마이그레이션을 수행했어야 했다. 이미 몇 번의 테스트도 수행되었고 진행 절차만 확인해 달라고 해서 회의에 참석했는데 '테이블 생성 및 마이그레이션 수행시 Orange, Toad 툴 이용' 이라고 명시되어 있었다.

필자는 마이그레이션 전용 툴 중에 Orange나 Toad 제품을 이용하는 줄 알았는데 이 툴에서 직접 INSERT 작업을 수행한다고 한다. 너무 긴박하게 돌아가기 때문에 이렇게 밖에 수행할 수 없다는 DBA의 볼멘 소리였다.

물론 DBA 업무를 수행하는 이들중에는 꼼꼼하고 신중한 성격의 소유자들이 많이 있지만 사람은 대부분 실수를 종종 하게 된다.

특히나 긴박하게 주어진 시간 내에 수행해야 하는 마이그레이션 작업 시에는 한번의 실수로 인해 처음부터 마이그레이션을 재 수행해야 하거나 다시 기존 시스템으로 돌아가야 하는 일이 발생할 수 있다.

그러므로 반드시 마이그레이션은 사람의 손이 가는 작업을 줄여 최대한 실수를 방지하고 대부분의 작업을 자동화해서 계획된 프로세스에 의해 수행되어야 한다.

스크립트 생성 자동화

대부분의 스크립트 생성은 상용 툴을 많이 이용한다. 하지만 상용 툴을 사용할 수 없는 경우들도 있고, 마이그레이션을 진행하기 전까지 오브젝트들이 변경되거나 오브젝트가 많은 환경에서는 상용 툴을 이용하면 시간이 오래 걸리는 단점이 있다.

이럴 때 Oracle 9i부터 제공되는 DBMS_METADATA라는 PACKAGE를 이용하면 쉽게 해결할 수 있다.

/* 이 부분은 매번 스크립트 추출 시 공통으로 사용 */
SET TRIMSPOOL ON
SET HEADING   OFF;
SET FEEDBACK  OFF;
SET LINESIZE  300
SET ECHO      OFF;
SET PAGES     10000;
SET LONG      90000;
COL DDL FORMAT A10000

EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
    (DBMS_METADATA.SESSION_TRANSFORM,'SQLTERMINATOR',true);
    
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
    (DBMS_METADATA.SESSION_TRANSFORM,'STORAGE',false);
    
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
    (DBMS_METADATA.SESSION_TRANSFORM,'CONSTRAINTS',false);
    
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM
    (DBMS_METADATA.SESSION_TRANSFORM,'REF_CONSTRAINTS',false);
/* 여기까지 공통으로 사용 */



-- Tablespace 추출
SPOOL cre_tablespace.sql

SELECT DBMS_METADATA.GET_DDL('TABLESPACE',TABLESPACE_NAME) AS DDL
  FROM DBA_TABLESPACES
 WHERE TABLESPACE_NAME NOT IN ('SYS', 'SYSAUX','SYSTEM','TEMP', 'USERS', 'TOOLS');

SPOOL OFF

-- 처음 공백 제거
HOST perl -e's/^(공백) //g' cre_tablespace.sql
 
-- 문장 끝 공백 제거
HOST perl -e's/(공백)$//g' cre_tablespace.sql 



--  Table 추출
SPOOL cre_table.sql

SELECT DBMS_METADATA.GET_DDL('TABLE', OBJECT_NAME, OWNER) DDL
  FROM DBA_OBJECTS
 WHERE OWNER IN ('WISEU')
   AND OBJECT_TYPE = 'TABLE'
   AND OBJECT_NAME NOT LIKE 'BIN$%';
   
SPOOL OFF

HOST perl -e's/^ //g' cre_table.sql
HOST perl -e's/ $//g' cre_table.sql


--  인덱스 추출
SPOOL cre_index.sql

SELECT DBMS_METADATA.GET_DDL('INDEX', INDEX_NAME, OWNER) DDL
  FROM DBA_INDEXES
 WHERE OWNER IN('SSO_DEV');

SPOOL OFF

HOST perl -e's/^ //g' cre_index.sql
HOST perl -e's/ $//g' cre_index.sql

마이그레이션 수행 스크립트 자동화

스크립트는 이미 생성해 놓았지만, 의외로 스크립트 수행은 DBA가 수동으로 실행하는 경우가 많다. 따라서 스크립트가 수행되는 도중 네트워크 연결이 끊겨 실행이 완료되었는지 여부를 알 수 없는 경우도 발생한다.

실제 마이그레이션을 수행할 때도 스크립트를 자동화하고 매단계가 수행될 때마다 반드시 로그가 기록되게 스크립트를 작성 하도록 하자.

실제 스크립트 로그가 기록되면 오류 여부 및 수행 여부를 확인할 수 있다. 실행해야 할 스크립트 순서대로 번호를 부여해, 마이그레이션을 수행할 때 좀더 효율적으로 하는 것도 하나의 방법이다.

예) 
01.Cre_tablespace.sh
02.cre_user.sh
03_1. insert_data01.sh
03_2. insert_data02.sh
...
13. data_verify.sh

또한 INSERT와 같은 작업은 여러 개의 Session에서 동시에 수행할 수도 있으며 PARALLEL DEGREE 및 몇 개의 Session 으로 수행하는 것이 가장 효율적인지의 여부는 마이그레이션 리허설 때 미리 테스트해 두는 것이 좋다.

작업 확인 프로세스 자동화

마이그레이션을 할 때 실제로 작업이 정상 수행되고 있는지 확인할 필요가 있다.

이를 위해 마이그레이션 리허설 때 수행 시간을 꼼꼼히 기록하고 마이그레이션 당일 해당 수행 스크립트가 기존보다 늦어진다면 어떤 이유에서 늦어지는지를 확인할 필요가 있다.

예를 들면 마이그레이션 시에 수행되지 말아야 할 배치 프로세스가 수행되고 있는지 또는 백업이 수행되고 있는지 확인해야 한다.

마이그레이션이 완료된 이후 인덱스나 통계 정보를 생성하기 전에 마이그레이션이 완벽히 수행되었는지 확인하기 위해 테이블 건수를 체크한다.

이 작업도 마이그레이션 시 기존 테이블의 건수를 미리 임시 테이블에 넣어 놓고 마이그레이션이 완료된 테이블의 건수도 INSERT가 완료되면 임시 테이블에 넣을 수 있도 록 자동화하면 실수를 줄일 수 있다.

마이그레이션은 많은 시간이 소요되는 작업이고 한번의 실수로 소요했던 시간만큼의 시간이 더 걸리거나 아예 지금까지 해왔던 작업을 롤백해야 하는 경우도 생긴다.

그러므로 매 작업마다 로그를 기록하고 로그를 확인하는 것을 결코 잊어서는 안 될 것이다.

어디서부터 잘못되었는지 모르면 잘못된 부분을 재처리 할지 조차 알 수 없으므로 처음부터 다시 해야 하기 때문이다.

옛말에 '무식하면 손발이 고생한다'는 속담이 떠오른다. 마이그레이션시 대부분의 프로세스를 자동화해서 사용자 실수를 최소한으로 줄이고, DBA 업무 부하도 줄여서 효율적인 업무수행이 될 수 있도록 노력해야 한다.