BLOG ARTICLE 로그마이너 | 1 ARTICLE FOUND

  1. 2010.04.14 Oracle 9.2.0.7에서의 로그마이너 버그

  작년말에 한창 문제가 되었던 내용입니다.
저희가 운영하는 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를 제거하니까 바로 정상적으로 인식하더군요.
 해당 인덱스를 살펴보니 실제로 쓰이지는 않는 인덱스이더군요. (왜 만들었는지... 제가 입사하기전에 만든거라 왜 만든건지, 누가 요청한건지를 모릅니다.) 그래서 해당 인덱스를 일반 인덱스로 바꿔버렸습니다. 그 다음부터는 잘 되더군요.
YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST