Month: December 2016

Ruby2.3.3 on Windows10(64bit)

보통 다른언어들은 위도우에 설치하는게 더 쉬운데..

루비는.. 아니다.

버전충돌이 심해서 rvm같은걸 설치 해 주는게 좋은데… 윈도우에서는 잘 안되는것 같다.

윈도우 인스톨러 이용해서 특정버전해서 개발하는게 좋지 않을까
https://rubyinstaller.org/downloads/

설치해야 할 것이 두가지다.

Devkit은 native 루비 gem을 다운받았을 때 이것들을 컴파일하는 역할을 한다.  이거 없으면 기본적인rails app 테스트도 힘드니 필수적이다.

Ruby 설치

이건 그냥 인스톨러 돌리면 바로 설치된다.

설치과정에서 add path는 꼭 선택 해 준다. 안해줬다면 그냥 중복 설치하면 된다.

Devkit 설치

Devkit은 설치파일이 아니고 압축파일이다.

C:\RubyDevkit 또는 C:\Ruby23-x64\Devkit

이쯤에 적당히 풀어준다.

환경변수 추가는 수동으로 해줘야한다.
C:\Ruby23-x64\Devkit\bin

커맨드창을 열어서

 

루비 데브킷 디렉토리로 이동
cd C:\Ruby23-x64\Devkit
자동으로 루비 설치경로를 확인
ruby db.rb init
데브킷 설치
ruby db.rb install

이제 rails budle rake 등 기본적인 gem들을 설치하고 사용하면된다.

 

[ERROR] DB 커넥션이 알 수 없는 이유로 닫히는 경우

org.springframework.dao.RecoverableDataAccessException: 
### Error querying database.  Cause: java.sql.SQLRecoverableException: 접속 종료
### The error may exist in file [D:\a_workspace\idea]
### The error may involve kr.co.aaaaa.api.server.module.common.dao.CommonMainDAO.aaa01
### The error occurred while executing a query
### SQL: { ~~~~~~~  }
### Cause: java.sql.SQLRecoverableException: 접속 종료
; SQL []; 접속 종료; nested exception is java.sql.SQLRecoverableException: 접속 종료


~~~~

Caused by: java.sql.SQLRecoverableException: 접속 종료

 

단순한 실수로 발생할 확률이 높고 의외로 해결에 시간이 오래 걸린다.

내 코드가 잘못됐다고 생각하지 않고 보통 다른데서 문제를 찾다보니 한참 걸린다.

 

이건 보통 transaction이나 connection close를 적절한 곳에서 해 주지 않아서 발생한다.

아마도…. 다른 이유였다면 검색하면서 시간 버리지 않고 금방 해결했을거다.

 

여태까지 여러 삽질을 해왔는데…
라이브러리의 문제로 오류가 발생했던 경험이 두어번정도 있었고 나머지는 다 내 코드 문제였다.

avro 자바-파이썬 에서 숫자자료형길이 호환안되는 문제 : 파이썬은 숫자자료형길이가 무제한

닷넷에서 뭐였는데… 스텍오버플로우에서 그거 닷넷버그라고 회피해서 사용하는법을 알려줬던 것 같다.

아 그리고… 오라클은 좀 많았던것같다.  아예 먹통은 아니고 의존성 문제였지만(문제있는 라이브러리는 패치를 하던가 삭제를 하던가.. 다운받게 공개를 해놔가지고)

 

몇년이나 일하면서 서너번이면 많지는 않으니

MSSQL2008 -> Oracle12c Sqldeveloper이용 데이터 대강이전

어쩌다 보니 어느패션업체의 디비 마이그레이션업무를 처리하게 됐다.
직접 말한것은 아니고 기획자를 통해서 한다리 건너서 협의가 이뤄져서 정확히는 모르겠지만
전달받기로는 마이그레이션이 쉬운게 아니라고 설명을 하면 “그냥 해주면 안되요?” 라는 반응을 보였다는 것 같다.

고객사에서는 마이그레이션을 그냥 파일 카피 정도로 생각하는 것 아닐까?
내가 갔으면 말도안되다는것을 좀 더 강하게 어필했을 것 같은데…

디비 전환 이유는 …. 정확히 전달받지는 못했지만 데이터를 보니까 이해가 갔다.
데이터 상태를 보니 속도가 매우 느렸을 것 같다.
검색도 하지 않을 것 같은 로그테이블이 동일한 데이터베이스에 수백기가 쌓여 있었다
MSSQL이 느리니까 짷좋은 오라클로 옮기면 빨라지겠지? 정도의 판단이 아니었을까

그리고 기왕 마이그레이션을 하기로 마음을 먹었으면 안쓰는 테이블이라던가 프로시저들을 파악해서 정리를 하면 좋을텐데…

대~애충 빨리 해다라고 하니 그럴 수 밖에…

마이그레이션은 툴을 이용해서 처리하기로 했다.
유료는 안 써봐서 모르겠고 이전에도 몇 번 돌려봤는데 특정 쿼리문은 번역도 안되고 테이블도 몇 개씩 빼먹고 하는 경우가 많았다.
각 데이터베이스에 의존적인 키워드를 사용하는 경우 오류도 발생하고

툴은 SqlDeveloper 4.1.5를 사용하기로 결정
(고객사에서 추가비용 지출을 저언혀 생각하지 않고 있어서)

SqlDevelop – Tools – Database – Third Party JDBC Driver에 추가

jtds-1.3.1-dist

이래저래 필요한 셋팅하고서 마이그레이션 실행
오류가 이것저것 많이 발생했는데 주로 발생하는 문제는 인코딩 오류, 쿼리오류
인코딩은 초반에 잡아줘서 해결했지만.. 쿼리는… 일부는 포기하고 넘어갔다.

MSSQL 2008 -> Oracle12c
결과 : 쓸데없는 테이블을 생성 해 놓는다. 마이그레이션 결과기록 테이블인가?
데이터는 제대로 옮겨지지 않는다. (뭘 잘못한 것 같진 않고 12는 아직 지원되지 않는것 같다)

MSSQL2008 -> Oracle11gr2
결과 : 테이블과 데이터는 잘 옮겨졌다

Oracle11gr2 -> Oracle12c
여기서는 자동화 툴이 안돌아가고 쿼리로 백업받은 후에 다시 올렸다.
덤프는 뭔가 호환이 안되는 것 같다.
이 방법으로 하는경우 Clob은 이전이 안된다. Oracle Clob은 쿼리 insert가 안되서 Varchar4000으로 변경할 수 있는 부분은 변경하고 안되는 부분은 python script를 이용해서 처리했다.

 

야매이전 완료 후

Function, Procedure – 거의 다 깨진다.
View – 거의못쓸지경.. 다 지우는게 나을 것 같다
Table-Clob제외하고는 정상

처참하네.. 마이그레이션이라고 할 수 있을까?
오류가 날 대 마다 거의 다 손으로 처리해야하지 않을까 싶다.

일 해 놓고도 미안한 상황이다
정식 프로젝트가 아니라 더 시간을 할애할 수는 없으니 대강 마무리할 수 밖에…