여기저기 기웃거리기

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

 예전에는 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 시장도 치열한 경쟁 구도로 바뀌어가는것 같습니다.

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

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

 보통 새 장비가 들어오면 - 그 장비가 몇백만원 단위의 저가가 아니라 대형 장비라면 - 그 장비를 설치하는 일은 납품 업체에서하고, OS 설치까지도 알아서 해주죠. 저희는 서버, 스토리지, SAN Switch까지 들어오기때문에 여러 업체가 작업을 하게 되었습니다. 그래서 중간에 조정자가 필요합니다. 저희도 "을"의 입장이지만, 납품 업체들의 일정을 모아서 "갑"에게 알려주고 "갑"의 의사결정에 따라서 일정을 확정하는거죠.

0. 상면, 전력 등을 미리 신청하여 확보하였는가?
1. 기존의 서버스와 상관없이 미리 할 수 있는 작업은 무엇인가?
2. 여러 업체가 동시간대에 할 수 있는 작업은 무엇인가?
3. 다른 작업보다 먼저 해야할 작업은 무엇인가?
4. 기존의 서비스를 중지해야한다면 최소, 최대 몇시간이 걸리는가?
5. Migration하게 될 장비의 사양에 맞게 소프트웨어 라이센스도 확보되었는가?


음... 이 정도가 중요하게 고려되어야할 문제인것 같습니다. 마지막에 라이센스 문제가 적혀있는데, 이번에 저희 프로젝트에서 문제가 되었던 점입니다. 이건 초기에 계약이 어떻게 되었는지와도 상관이 있는 문제라서 좀... 난감한 문제이죠.

 DB 서버 이전을 하는 첫 단계로 기본 정보 수집 단계입니다.

 이 단계에서 우선 기본적으로 DB에 Datafile이 몇개나 되는지 용량은 얼마나 되는지 어떤 디렉토리 구조로 나뉘어서 저장되어 있는지 목록을 만듭니다. 그리고 각 계정별로 어떤 테이블이 있는지, 그리고 데이터의 양은 얼마나 되는지를 마찬가지로 목록으로 만듭니다.

 목록으로 만드는 이유는 이전 과정에서 앞으로는 없어도 되는, 현재 사용중이지 않은 테이블 혹은 계정을 가려내어 빼기 위함입니다. 한번쯤은 정리해주는게 필요하죠. ^^ 그래야 새 서버로 옮겼을때에 성능 향상이 눈에 뛰겠죠. ㅋㅋ 음... 그리고 좀더 자세한 내용은 나중에 적어보겠습니다. 사무실에 올라가야 겠네요.

------------------------

내용 추가

1. 데이터 파일 목록

2. 유저별 Object 목록
 : system, sys 및 기타 DBMS 설치시 생성되거나 툴을 설치할때 생성되는 계정의 Object를 제외한 목록 정리

3. 각 유저별 디스크 사용량 정리

 이번에 새 장비가 들어와서 서버 이전을 해야합니다. 이기종 DBMS간의 이전은 아니라서 참 다행스럽긴한데, 그래도 고민해야할것들이 참 많네요. 그래서 Oracle이라는 DBMS의 관점을 포함해서 일반적인 DBMS Server의 이전이라고 가정하고 서버 이전을 할때 고려해야할 점들을 정리해보고자합니다.

 (1) 서버 이전을 시작하며

 서버 이전을 하기전에 우선 새 장비 도입과 관련된 업체 사람들이 모여서 회의를 하죠.
서버 납품 일정, 스토리지 장비 납품일정, 넷트웍 관련 장비 납품 일정, 전원 및 상면 예약 등등의  협의 사항을 얘기했습니다. 장비가 들어오는 시간 순서부터, 연결하는 순서. 동시에 작업 가능한 일들... 열거하려니 참 힘드네요.

그리고 결정적으로 Migration시에 발생하는 라이센스 변동 내용. 이건... 계약 내용에 없는건데, 갑이 억지를 부리네요. CPU갯수가 두배이상 늘어나는데, 어플리케이션 라이센스도 알아서 처리하라는...(음... CPU갯수가 틀리니까 경고메세지가 뜨는데 그게 보기 싫으시다는) 우리 "갑"님.

 그 외에는 걱정거리는 없네요.
더 많은 CPU 갯수, 더 빠른 CPU, 더 빠르고 용량이 늘어난 스토리지 도입. 뭐 걱정보단 DB 파일 저장 구조를 어떻게 꾸밀지만 고민하면 됩니다. 이것도 중요한거지요.

자세한 고민은 다음회부터 하겠습니다. 그럼 빨리 사무실에 들어가봐야 겠어요. 벌써 15분 가량이 지났네요.