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

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

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

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

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

1. 피앤피시큐어의 DBSafer

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

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

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

iPhone 에서 작성된 글입니다.

Oracle database에 무작위로 숫자나 문자열을 생성하는 DBMS_RANDOM 패키지가 있죠. Tibero에도 있을까 궁금했었습니다. 그래서 PDF file로 받은 메뉴얼을 열어보았는데... 이럴수가 "tbPSM 참조 안내서(Tibero RDBMS 4 SP1 (TD-MAN-TDR-415005))"와 "tbPSM 안내서(Tibero RDBMS 4 SP1 (TD-MAN-TDR-415006))"에는 DBMS_RANDOM이라는 패키지 관련 내용이 없네요. 
 
정말 없을까? 궁금해서 tbAdmin에서 "DESC DBMS_RANDOM"을 실행해 보았습니다. 그랬더니, 메뉴얼에는 없지만DBMS_RANDOM이라는 패키지 정보가 뜨네요.
 
아래의 쿼리를 실행해보세요. 대충 어떻게 써야 할지 감이 올겁니다.

SELECT DBMS_RANDOM.RANDOM, DBMS_RANDOM.STRING('X', 5), DBMS_RANDOM.STRING('A', 8)  
FROM DUAL;

STRING 함수의 첫번째 인자값이 X이면 영문자 대문자와 숫자를 섞어서 무작위로 추출을 하고, A이면 영문자 대소문자를 섞어서 무작위로 추출을 합니다. 두번째 인자값은 문자열을 몇 자리로 할건지 지정해주는 인자입니다. 자세한 내용은 참고 문서의 내용을 확인해보시기 바랍니다. Oracle에 대한 문서이긴한데... Tibero에 적용해도 별 문제는 없네요.

참고 문서
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_random.htm
http://psoug.org/reference/dbms_random.html 
 Tibero RDBMS를 UNIX나 Linux상에서 운영할때 가끔씩은 session을 종료시켜야 할때가 있다. 이상한 쿼리가 실행되고 있다거나, Memory나 Disk I/O를 많이 일으킨다거나... 뭐 암튼 tm(Tibero Monitoring script)으로 확인한 session을 종료시키고 싶을때 명령행에서 처리하는 방법이다.

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

tbSQL 4 SP1

TmaxSoft, Co. Copyright(C) 2001-2009. All rights reserved.

Enter Password:

SQL> alter system kill session(111,1111);

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


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

select kill session (0: QUIT):

요기서 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에 생성된 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은 수작업으로 생성해야 합니다.

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 공유가 가능하다고 하는데, 별로 권장하지 않는다고합니다. 그래서 좀 고민이 되는 부분입니다. 


 TmaxData의 Tibero4로 migration을 진행하면서 알게된 몇가지 내용 중 Index rebuild에 대해서 얘기해보고자합니다. 기존에 사용하던 Oracle을 기준으로 하면... (제가 가장 잘 아는게 Oracle이라 이녀석이 기준입니다.) Index를 사용하다가 rebuild 해줄때 몇가지 옵션을 줄 수 있습니다.

SQL> ALTER INDEX IDX01 REBUILD ONLINE;
   * 기존의 인덱스를 계속 유지한채로 REBUILD하고, REBUILD가 끝나면 바꿔치기 하는 옵션이죠.

SQL> ALTER INDEX IDX01 REBUILD ONLINE TABLESPACE TS_IDX2;
   * REBUILD를 하면서 저장하는 TABLESPACE도 바꾸는 옵션이죠.


 사실 DB 관리를 하다보면 tablespace를 바꿔줄 일이 가끔씩 생깁니다. 그래서 Tablespace를 바꿀 수 있는 옵션은 아주 유용합니다. 그런데... Tibero4에서는 이를 지원하지 않고 있네요. ㅡ.ㅡ
[General syntax error]라는 오류가 발생합니다. Tmax에서도 지원하지 않는다고 하네요. 그런데, Tmax에서 제공하는 Tibero 관리/개발용 툴인 tbAdmin에는 인덱스 리빌드창(마법사??)에서 Tablespace를 선택할 수 있도록 되어있습니다. 혹시나 해서 실행시켜보니까 똑같은 오류가 발생하네요.


 현재 재직중인 직장에서 TmaxData의 Tibero4로 DBMS를 migration 및 신규 서비스 구축을 한다는 말씀을 드렸었나요? 음... 암튼 지금 그런 일이 진행되고 있습니다. 나름 대규모 작업이 진행중인데요.
국내 기업이다보니 버그나 기능 개선이 요구되면 그때그때 패치가 되고 있습니다. 이건 뭐 긍정적이라고 생각합니다. 아직 개선할 점이 많은게 문제이긴하지만 대응이 빠른 편이라고 생각합니다. 좋게좋게 생각해야죠.

 이번에 말씀드리려는건 현재 패치가 진행중이라고 알고있는데요. PSM(Oracle의 PL/SQL에 해당함)을 이용해서 함수(Function)를 만들어서 쓸때 생기는 문제입니다.

문제점 : select문장에서 만들어 놓은 함수를 실행시켰는데, 널(null) 값이 반환된다.

원인 : 함수안에서 실행되는 Query 문장이 인덱스를 타게되면 널(null) 값이 반환된다.

해결책 : 현재 패치 진행중이라고 한다. 일단 Full table scan하도록 힌트를 주면 됨.

 뭐... 패치 중이니까요... 곧 해결되겠죠.

+ Recent posts