어쩌다 보니 어느패션업체의 디비 마이그레이션업무를 처리하게 됐다.
직접 말한것은 아니고 기획자를 통해서 한다리 건너서 협의가 이뤄져서 정확히는 모르겠지만
전달받기로는 마이그레이션이 쉬운게 아니라고 설명을 하면 “그냥 해주면 안되요?” 라는 반응을 보였다는 것 같다.
고객사에서는 마이그레이션을 그냥 파일 카피 정도로 생각하는 것 아닐까?
내가 갔으면 말도안되다는것을 좀 더 강하게 어필했을 것 같은데…
디비 전환 이유는 …. 정확히 전달받지는 못했지만 데이터를 보니까 이해가 갔다.
데이터 상태를 보니 속도가 매우 느렸을 것 같다.
검색도 하지 않을 것 같은 로그테이블이 동일한 데이터베이스에 수백기가 쌓여 있었다
MSSQL이 느리니까 짷좋은 오라클로 옮기면 빨라지겠지? 정도의 판단이 아니었을까
그리고 기왕 마이그레이션을 하기로 마음을 먹었으면 안쓰는 테이블이라던가 프로시저들을 파악해서 정리를 하면 좋을텐데…
대~애충 빨리 해다라고 하니 그럴 수 밖에…
마이그레이션은 툴을 이용해서 처리하기로 했다.
유료는 안 써봐서 모르겠고 이전에도 몇 번 돌려봤는데 특정 쿼리문은 번역도 안되고 테이블도 몇 개씩 빼먹고 하는 경우가 많았다.
각 데이터베이스에 의존적인 키워드를 사용하는 경우 오류도 발생하고
툴은 SqlDeveloper 4.1.5를 사용하기로 결정
(고객사에서 추가비용 지출을 저언혀 생각하지 않고 있어서)
SqlDevelop – Tools – Database – Third Party JDBC Driver에 추가
이래저래 필요한 셋팅하고서 마이그레이션 실행
오류가 이것저것 많이 발생했는데 주로 발생하는 문제는 인코딩 오류, 쿼리오류
인코딩은 초반에 잡아줘서 해결했지만.. 쿼리는… 일부는 포기하고 넘어갔다.
MSSQL 2008 -> Oracle12c
결과 : 쓸데없는 테이블을 생성 해 놓는다. 마이그레이션 결과기록 테이블인가?
데이터는 제대로 옮겨지지 않는다. (뭘 잘못한 것 같진 않고 12는 아직 지원되지 않는것 같다)
MSSQL2008 -> Oracle11gr2
결과 : 테이블과 데이터는 잘 옮겨졌다
Oracle11gr2 -> Oracle12c
여기서는 자동화 툴이 안돌아가고 쿼리로 백업받은 후에 다시 올렸다.
덤프는 뭔가 호환이 안되는 것 같다.
이 방법으로 하는경우 Clob은 이전이 안된다. Oracle Clob은 쿼리 insert가 안되서 Varchar4000으로 변경할 수 있는 부분은 변경하고 안되는 부분은 python script를 이용해서 처리했다.
야매이전 완료 후
Function, Procedure – 거의 다 깨진다.
View – 거의못쓸지경.. 다 지우는게 나을 것 같다
Table-Clob제외하고는 정상
처참하네.. 마이그레이션이라고 할 수 있을까?
오류가 날 대 마다 거의 다 손으로 처리해야하지 않을까 싶다.
일 해 놓고도 미안한 상황이다
정식 프로젝트가 아니라 더 시간을 할애할 수는 없으니 대강 마무리할 수 밖에…