Tibero4 migration 모험기 (4) 중간정리
Oracle DBA의 Tibero 사용기
 사용기나 감상문 정도로 적으면 될걸 굳이 모험기라는 조금은 부정적인 의미의 단어를 사용한건, Tibero라는 생소한 제품으로의 이전이 제게는 모험에 가깝다고 생각되어서입니다. 아주 주관적인 얘기니까 혹시 티맥스 관계자분들이 보시면... 걍 얘가 겁이 많구나... 이 정도로 생각하시면 됩니다. 현재 Tibero를 아주 잘 사용하고 있습니다. ^^

 그동안 Oracle을 사용하다가 Tibero RDBMS로 이전을 하기로 결정이 내려졌고, 현재 하나의 시스템을 제외하고는 Tibero로 이전을 하였습니다. 처음 Tibero를 접했을때는 너무 자료가 없고, 폐쇄적이라 테스트 해보기 힘들었다는게 문제였고, 실제 서비스에 일부 사용하고 있는 현재는 타업체의 DB, 솔루션과 함께 사용할때 생기는 다양한 문제점의 원인 파악 및 해결이 어렵다는게 가장 큰 문제입니다. 서두에 이미 결론을 내버려서 이 글을 끝까지 읽지 않으실지도 모르지만, 도입 결정 후 시스템 이전 과정과 서비스 과정에서 생긴 일을 하나씩 얘기해보려 합니다.

 * Tibero 도입을 결정하다.
 제가 이전에 블로그에 남겼던 글을 읽으셨다면 어느 정도 감을 잡으셨겠지만, Tibero 도입의 결정적인 이유는 다음과 같습니다.
첫째, Oracle RAC 도입 가격에 비해서 아주 저렴한 가격에 Shared Disk 방식의 Cluster DB를 도입할 수 있다.
둘째, Oracle에서 사용하던 Query, Procedure, Function 등이 수정없이 Tibero에서 사용할 수 있다.
셋째, 필요한 기능 추가 및 시스템 에러에 대한 빠른 대응 가능(국내에 연구 개발을 담당하는 조직이 있어서 가능한거죠.)

 위의 세가지 이유로 도입이 결정되었었습니다.

2010/02/18 - [Database] - DBA의 고민 (1) 고성능, 고가용성 시스템 구축. 안정성과 성능의 두 마리 토끼를 잡아야 하는데... ㅜㅜ
 위의 글을 보시면 왜 RAC같은 Cluster DB 제품을 도입하려하는지에 대한 내용이 들어 있습니다.


 * 테스트와 이전 작업을 진행하다.
도입이 결정되고는 내부 테스트와 이전 작업이 진행되었습니다. 작업 중 Oracle과는 다른점이 여러가지 발견되었습니다.

 [다르긴 하지만 크게 문제는 없어서 넘어간 점들]
첫째, 리스너는 하나 밖에 사용할 수 없다. 정책적으로 서비스나 솔루션별로 서로 다른 리스너를 사용할 수 없습니다.
둘째, log file들이 저장되는 위치를 마음대로 바꿀수 없다. Oracle에 비해서 자유도가 떨어지더군요.

 [문제가 있지만, 아직 패치가 되지 않은 점들]
첫째, Index rebuild를 할때 저장되는 Tablespace를 바꿀 수 없다. 여기에 관해서는 제가 예전에도 글을 올렸던 적이 있습니다. 2010/02/01 - [Database] - Tibero4 migration 모험기 (3) Index rebuild 기능

둘째, 서로 다른 Tibero instance간에 Materialized View를 생성해서 쓰면 성능 문제가 생길 수 있다.
  저희가 Materialized View(이하 M-View)를 사용하면서 격은 문제입니다. M-View에는 Fast라는 옵션을 줄 수 있습니다. 아시겠지만, 이 옵션을 쓰면 원본 Table에서 변경된 Data만 가져와서 M-View에 적용을 해줍니다. 이러면 M-View의 Data 동기화 작업 시간을 줄여주고, CPU 부하도 줄여주고... 뭐 이런저런 장점이 있습니다. 그런데 문제는요  동일한 인스턴스에서 M-View를 생성하면 Fast 옵션을 줄수 있는데, 서로 다른 티베로 인스턴스에서 DB Link를 이용해서 M-View를 생성하면 Fast 옵션을 줄 수 없다는겁니다. 어쩔 수 없이 Force 옵션을 주고 생성을 하게 되는데, 이러면 아카이브 파일이 엄청나게 쌓이더군요. M-View를 Refresh할때 마다 대량의 아카이브 파일이 생겨서 운영하기가 힘들 정도였습니다. 언제 패치가 나올지 확답을 받지 못한 상태입니다. 혹시 M-View를 많이, 그리고 여러 DB Instance에서 운영하시는 분들은 참고하시길 바랍니다.



이건 tbAdmin 사용자들을 위한 팁입니다.

* tbAdmin에서의 PSM 실행
 Oracle에서 DBMS_JOB 패키지를 사용하여 job을 설정하죠. Tibero에서도 동일하게 job을 설정합니다. 문제는 tbAdmin(TmaxData에서 Tibero client로 배포하는 이클립스 기반의 프로그램입니다.)의 sql 편집창에서 해당 PSM(Oracle의 PL/SQL에 해당합니다.)을 실행시켜도 job이 설정되지 않습니다. 그렇다고 에러 메세지도 보이지 않습니다.
 해결 방법은 간단하더군요. SQL 편집창 말고 PSM 편집창이 따로 있습니다. 거기에서 실행시키면 잘 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

 그동안 MS Windows 7에 Oracle client를 설치하려면 설정 파일을 수정해줘야만 했었습니다. 각종 블로그에 설치하는 방법이 올아왔었죠. 문제는 그렇게 해줘도 일부 설치가 안되는 PC가 생겼으며, 당연히 Oracle의 공식적인 지원이 없었기에 안 되는 사람은 어쩔수 없이 Windos XP로 돌아가거나, Windows 7 재설치라는 악수를 둘 수 밖에 없었습니다.

 이번에 Oracle 11g R2의 Windows 버전이 출시되었습니다.
OTN에 Oracle 11g R2 다운로드 페이지 (지난번에 제가 64비트 버전은 링크가 깨져있다고 했었는데, 이번에는 잘 들어가집니다. 다운로드 받아야 겠네요. ^^)

 위의 웹 페이지에서 Windows 버전을 다운로드 받으면 MS Windows 7에 정상적으로 설치됩니다. 물론 Oracle 9i 및 10g client를 설치하면 사용할 수 있었던 Enterprise Manager는 메뉴에서 사라졌네요.(11g R1에서부터 없어졌었나요? 11g R1을 설치해보질 않아서 확인을 못했습니다.) 그 외에는 잘 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

  작년말에 한창 문제가 되었던 내용입니다.
저희가 운영하는 Oracle DB 중에서 Tibero로 이전하는 DB가 있었습니다. Tibero에서 Oracle로 Gateway(Tibero에서 제공한 Gateway)를 이용해서 Database link를 만들어서 일반 DB Link 이용하듯이 쓸 수 있어서 좋았는데, 문제는 Oracle DB에 있는 기준 정보들이 변경되었을때 이를 Tibero에 적용시킬 방법이었습니다. Oracle에서는 현재 Tibero로 DB Link를 지원하지 않으므로 Oracle측에서 변동내용이 있을때 Data 동기화 작업을 위해서 Tmax Prosync라는 제품을 이용하였습니다.

* Tmax Prosync
[Oracle to Tibero Prosync], [Tibero to Oracle Prosync]가 있는데, [Tibero to Oracle Prosync]는 시스템에 부하를 많이 주는 문제가 있어서 제외하고 [Oracle to Tibero Prosync](이하 Prosync)만 사용하기로 했었습니다.
 Prosync는 Oracle의 로그마이너를 이용하여 테이블의 변동 내용을 알아내고, 이를 로그 파일로 저장한뒤에 Tibero측에 insert, update, delete 문장을 보내서 실행시키는 구조입니다. 그래서 Oralce DB에서도 필요한 설정을 했죠. (알고 계시겠지만 Supplemental Logging 설정이 필요합니다.)
그리고 실제 구축을 했었죠. 그런데 실제로 사용하는 중에 문제가 생겼습니다.

* 문제
 일부 테이블은 몇개의 컬럼이 빠진채로 변경 내용이 감지 되어서 Tibero측에 정상적인 쿼리문이 보내지지 않더군요.

* 원인 및 해결 과정
 TmaxData의 여러 엔지니어가 와서 이 문제에 달려들었었습니다. 결국 마지막에 밝혀낸건 Oracle logminer의 버그라고 하네요. 10g 버전에서는 해결이 되었다고 합니다. 10g를 사용하는 곳은 이상없이 사용 가능하실테고, 저희처럼 9i를 사용하는 곳은 문제가 되네요. Function Based Index가 생성되어있는 테이블은 Logminer에서 비정상적으로 인식을 해서 변경 내용을 정상적으로 감지 하지 못하더군요. Function Based Index를 제거하니까 바로 정상적으로 인식하더군요.
 해당 인덱스를 살펴보니 실제로 쓰이지는 않는 인덱스이더군요. (왜 만들었는지... 제가 입사하기전에 만든거라 왜 만든건지, 누가 요청한건지를 모릅니다.) 그래서 해당 인덱스를 일반 인덱스로 바꿔버렸습니다. 그 다음부터는 잘 되더군요.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.