여기저기 기웃거리기

Tmax Day 2013 행사에 참석 중입니다.

예전에 비해서 데이터베이스 쪽 제품들이 짜임새있게 개발이 되는것 같습니다.
티베로6와 인피니데이터3.0은 꽤 쓸만한듯하네요.
자세한 참관기는 나중에 올리도록 하겠습니다. 일단 facebook.com/TiberoUsers 에서 현장 사진을 볼수 있습니다.

iPhone 에서 작성된 글입니다.

요즘 IT쪽에 보안 문제가 큰 화두가 되고있습니다. 물론 보안은 아주 기본적인 요구사항입니다. 하지만 제 경험상 보안 솔루션 도입은 비용과 운용상의 불편함을 이유로 검토 후 보류해버리는 경우가 많았습니다.

요즘 수 많은 사건사고로 인해서 보안 솔루션 도입에 꽤 적극적이 된 회사의 모습을 보면, 역시 어디서 한 건 터지고, 법으로 규제해야 기업체가 돈을 쓴다는걸 다시한번 머리속에 새깁니다. (기업이 돈을 많이 남기면 재투자하고, 고용을 확대해서 서민 경제가 좋아진다는 얘기는 어느나라 얘기일지...)

티베로 엔지니어를 통해서 확인한 티베로를 지원하는 DBMS 접근제어 솔루션들입니다.

1. 피앤피시큐어의 DBSafer

2. 웨어벨리의 Shakra(샤크라)
샤크라 맥스는 아직 티베로를 지원하지 않고 샤크라만 티베로를 지원한다고 합니다.

그리고 제작사측에서 티베로를 지원한다고 연락이 온 DBMS 접근제어 솔루션이 있습니다.
1. 신시웨이의 Petra(페트라)

아직 확인이 안된게 많습니다. 내용 확인이 되는대로 추가하겠습니다.

iPhone 에서 작성된 글입니다.

 Tibero RDBMS를 UNIX나 Linux상에서 운영할때 가끔씩은 session을 종료시켜야 할때가 있다. 이상한 쿼리가 실행되고 있다거나, Memory나 Disk I/O를 많이 일으킨다거나... 뭐 암튼 tm(Tibero Monitoring script)으로 확인한 session을 종료시키고 싶을때 명령행에서 처리하는 방법이다.

1. tbsql을 이용한다.
 이 방법은 뭐 따로 설명할 필요가 있을까마는....

이런식으로 처리해준다. Oracle과 다를거 없다.
session이 종료되지 않을때도 있다.


2. tbsvr kill을 이용한다.
명령행에서 "tbsvr kill"을 입력하면 session을 종료시킬 수 있다.

요기서 33을 입력해주면 해당 session이 종료된다. 물론...... 안될때도 있다.
0(영)대신에 Q를 입력해도 이 프로그램에서 빠져나갈 수 있다.

 Tibero는 Oracle과 유사한 구조로 구현되어있기에, Oracle처럼 Redo log file과 Archive log file이 존재한다. 당연히 Archive log mode로 설정을 해줘야 된다.


1. Tibero RDBMS의 설정 파일에 Archive log file이 저장될 디렉토리를 지정해준다.
$TB_HOME/config/DB명.tip파일에 디렉토리 설정을 추가해준다.
LOG_ARCHIVE_DEST="/data/tb_archive_log"


2. 운영중인 Tibero를 종료시킨 뒤 mount mode로 기동한다.
# tbboot mount

3. Achive log mode로 변경한다.
# tbsql sys

SQL>  alter database archivelog;


4. DBMS를 재기동한 뒤 정상적으로 Archive log file이 생성되는지 확인한다.
# tbdown immediate

# tbboot

# tbsql sys

SQL> alter system switch logfile;

 Tibero 4 SP1을 사용한지도 벌써 일년이 넘어가고 있다. 그동안 안정화에 꽤 많은 노력을 기울였고, 생각보다 오래 걸렸지만, Tibero를 그럭저럭 사용하고 있다. 문제는 아직까지는 초기에 Tibero 영업에서 얘기한 "Oracle 10g 기준으로 거의 모든(?) 기능이 동일하다"는 얘기에는 많이 모자란 모습이라는 것이다.

 그동안 Tibero에 대해서 몇번 얘기했었는데, 이번에 얘기할 것은 Oracle의 exp, imp에 해당하는 tbexport와 tbimport에 대한 얘기이다. tbexport는 Oracle의 exp와 같이 Online 상태의 DB에서 data를 backup할때 사용하는

 무엇이 문제인가!!
 Oracle에서 export한 덤프 파일을 import할 때에 원본 DB에는 A라는 Tablespace가 존재하지만, import하는 DB에는 A라는 Tablespace가 없다고 가정해보자. 어떻게 되는가. 아래의 이미지를 보면 쉽게 이해가 가지 않을까?
  DB-1의 ERP라는 유저를 export한 뒤 DB-2의 ERP라는 유저에 import한다고 할 때, 두 DB에 생성된 Tablespace가 서로 다르다면, Oracle에서는 DB-1에서 export한 Table들이 원래 생성되었던 A라는 Tablespace가 DB-2에 없다면 import하는 계정의 default tablespace인 B에 Table을 생성하죠. Tibero에서도 이렇게 될 줄 알았습니다.


 그런데... Tibero에서는 import하는 DB에 원래 DB-1에서 Table이 생성될때 사용했던 Tablespace와 동일한 이름의 Tablespace가 없으면 에러를 발생시키네요. ignore=y 옵션을 주고 시작하면 해당 오류를 그냥 통과하고 나머지를 import합니다만 오류가 발생한 Table은 수작업으로 생성해야 합니다.

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

ROqynQX3gVz0_QcF16svVOdb_B0bY6IcdGWU77GNOT8,

 저희 회사에 Tibero TAC(Tibero Active Cluster)가 도입되었다는건, 이전의 제 글들을 보신 분이라면 아실겁니다. 국산 DBMS 시장에 여러가지 제품이 출시되어 있지만, Oracle RAC처럼 Shared disk 방식으로 구현한 Active-Active 형태의 Cluster 제품은 Tibero TAC가 처음이죠.

 현재 TAC를 사용중인데 편한 점부터 얘기를 해볼까합니다.

 우선 서비스 중단 없이 OS, DBMS 등의 패치 및 점검 작업 등을 할 수 있다는 점이 아주 편하다고 생각합니다. 각 노드를 번갈아가면서 재부팅하는 작업을 해보니 꽤 편하더군요. ^^  그리고 한쪽 노드에 부하가 몰려있을때라도 좀 한가한 나머지 노드에 접속하여 Data 조회, 조작 작업을 할 수 있는 가용성. 확실히 Cluster의 장점이 아닐까요?

 이제, TAC 제품의 단점을 얘기해볼까 합니다.

첫째, 원인을 정확하게 알 수 없는 성능 저하 현상 발생.
Storage와 OS 등의 제품들과 엮여서 딱히 어느 곳이 문제인지 알 수 없는 성능 저하 현상이 발생합니다. 그것도 자주!
벌써 몇달째 고생중인 문제인데요. 현재 원인 규명 작업을 진행중인데 쉽게 해결될것 같지가 않습니다.

둘째, 이기종 DBMS와의 data 공유가 어렵다. DBMS 자체가 이기종 DBMS와의 data 공유가 어렵다는건 티베로 만의 문제는 아니긴 한데, Data 공유를 위한 솔루션(ETL, DB복제툴 등)에서 티베로를 거의 지원하지 않는다는게 문제입니다. TmaxData에서 나온 제품만 지원하고 있죠. DB복제툴은 Oracle이외의 DBMS는 제대로 지원하지 않고, ETL tool의 경우에는 다양한 DB를 지원하지만 실시간 동기화(2, 3분 이내)에는 적절하지 않더군요.
Oracle과는 JAVA Gateway를 이용해서 처리할 수 있는데, 현재는 어느정도 해결이 되었지만 이 부분이 그동안 문제가 많았었죠. 프로세스가 정상 종료되지 않고 남아서 성능을 떨어뜨리는 현상을 일으켰는데, 현재는 Tibero 패치를 통해서 해결이 되었습니다. 뭐, Oracle과는 어느정도 해결이 된다고하지만 그 외의 DB와는 아직 문제가 많습니다. MS-SQL과는 Openquery를 통해서 select만 가능합니다. MS-SQL Gateway를 이용해서 data 공유가 가능하다고 하는데, 별로 권장하지 않는다고합니다. 그래서 좀 고민이 되는 부분입니다. 

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

 Oracle과 MS-SQL 사이의 Data 공유를 위해서 Openquery를 이용하고 있습니다. 지금까지 잘 이용하고 있었는데, 문제가 발생했습니다. Oracle DB를 Tibero로 바꾼다는거죠. 그래서 Tibero에서도 해당 기능을 사용할 수 있는지 점검해 봤습니다.
 Tibero to MSSQL Gateway라는게 존재하는데, 이는 설정을 따로 요청해야 하고, 기존의 MS-SQL측에서 생성된 프로시져를 쓸 수가 없다는 단점이 있어서 일단 Openquery를 이용하는 방법을 시도해봤습니다.

 MS-SQL에서 Linked server를 생성하는 방법에는 Tibero ODBC driver를 이용해서 Data 원본(DSN)을 만든 뒤에 이를 이용해서 Linked server를 생성하는 법과, Tibero oledb driver(2가지를 지원하더군요.)를 이용해서 바로 Linked server를 생성하는 방법이 있습니다.

 1. select query 실행
  ODBC, OLEDB 두가지 방법으로 모두 이상없이 잘 됩니다.

2. update query 실행
 ODBC, OLEDB 두가지 방법으로 모두 오류가 발생합니다.

결론.
 Openquery를 이용할 때 Tibero로는 select query만 실행 가능하다는 문제가 있습니다.