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 편집창이 따로 있습니다. 거기에서 실행시키면 잘 됩니다.


YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST


 예전에는 MS-SQL을 사용하던 중소 규모의 업체에서 회사 규모 확장에 따라서 Oracle을 구매하여 Migration을 하는 경우가 많았었다.  예전에 몸 담았었던 H 모사에서도 그랬고 대용량 DB를 운영하는 사이트에서는 Oracle을 많이 사용하는 추세였죠.
 최근들어 Windows 계열 서버의 사용이 많아지고, MS-SQL Server의 기능이 향상됨에 따라서 MS-SQL Server의 사용이 많아지고 있습니다. 그래서 역으로 Oracle에서 MS-SQL로 이전하는 경우도 생기고 있습니다. 물론 일반적인 경우는 아니라고 생각합니다. 아직은... 성능이든 엔지니어든 여러모로 부족한게 사실이니까요. 설치 및 관리의 편리함은 MS-SQL에 대한 접근성을 낮춰주었고 수많은 MS-SQL 사이트들이 존재하며 그 영역을 넓혀가고 있는데요. 기존 Oracle에서 MS-SQL로 이전하는 사용자를 위한 이전 툴이 MS에서 나왔습니다. 당연한 얘기겠죠. 후발 주자이니 이런 툴에 대한 지원을 잘해야겠죠.

이름하여 SQL Server Migration Assistant(SSMA for Oracle)!!

홈페이지에 있는 정보를 보니 세번째 버전인것 같은데, 그동안 까마득히 모르고 있었네요. 사실 이런식으로 Migration 작업을 한 적이 없었는데, 이번에 Migration 작업을 하시는 분이 있어서 대신 자료를 찾다가 발견하게 되었습니다. 이런 툴들이 존재하는걸 보니 이제는 DB 시장도 치열한 경쟁 구도로 바뀌어가는것 같습니다.
YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST


 자동화는 관리자든, 개발자든 공통적으로 중요한 일이죠. 이번에 IBM DeveloperWorks에 "손 쉬운 데이터베이스 마이그레이션"이라는 제목의 글이 올라왔습니다. 흠... LiquiBase라는 오픈소스 소프트웨어를 이용해서 데이터베이스 변경 관리하는 법을 소개하고 있네요. 흥미로운 글입니다.

원문 : 사람을 위한 자동화: 손 쉬운 데이터베이스 마이그레이션

데이터베이스는 종종 그것을 기반으로 하는 애플리케이션과 어긋난 상태로 존재하는데, 이로 인해 데이터베이스와 데이터를 안정된 상태로 끌어내는 것은 관리에 있어서 상당한 도전 과제가 됩니다. 사람을 위한 자동화 이번 기사에서는, 자동화 전문가 Paul Duvall이 오픈 소스 LiquiBase 데이터베이스-마이그레이션 도구를 사용하여 데이터베이스와 애플리케이션의 변경 사항을 관리할 때 발생하는 고통을 줄이는 방법을 보여줄 것입니다.

수년간 내가 일했던 애플리케이션들은 대부분 다량의 데이터를 관리해야 하는 엔터프라이즈 애플리케이션이었다. 그런 프로젝트에서 일하는 개발 팀은 보통 데이터베이스를 애플리케이션과는 완전히 별개의 것으로 취급한다. 이는 때때로 데이터베이스 팀과 애플리케이션 개발 팀으로 나뉘어 있기 때문이거나, 단순하게 팀이 그런 식으로 일을 하기 때문일 것이다. 두 방법 모두 다음과 같은 결과를 초래할 수 있다.

  • 데이터베이스에 변경 사항 직접 반영하기
  • 데이터베이스 변경 사항을 다른 팀원과 공유하지 않기
  • 일관되지 않은 방법으로 데이터베이스나 데이터 변경 적용하기
  • 데이터베이스 버전을 다음 버전으로 변경하는 관리를 비효율적으로 손수 다루기

개발자들이 데이터 변경 사항을 제대로 인지하지 못한 상태로 두는 비효율적인 상황이 발생한다. 게다가, 그들은 애플리케이션 사용자가 데이터 불일치나 충돌 문제를 경험하게 할 수도 있다.

그림 1은 소프트웨어 개발 프로젝트에서 흔히 사용하는 데이터베이스에 직접 변경을 가하는 방법을 보여준다. 직접 데이터를 변경하는 방법은 불안하고 에러가 발생할 여지가 많다, 그리고 방금 한 것을 되돌리는 걸 어렵게 하며 시간 흐름에 따라 데이터베이스에 어떤 변화가 있었는지 그 히스토리를 분석하는 것도 힘들다. 예를 들어, DBA가 한 건의 조회 데이터를 변경해야 한다는 것을 기억하고 있을지 모른다. 하지만 한 개발자가 나중에 이 데이터를 같은 테이블에 넣어야 한다는 것을 깜빡할 수도 있다.


YOUR COMMENT IS THE CRITICAL SUCCESS FACTOR FOR THE QUALITY OF BLOG POST