여기저기 기웃거리기

Oracle 11g에서 눈에 띄는 변화 중 하나가 alert.log가 없어졌다가 아니라 위치와 포멧이 바뀌었다입니다.
하나의 디렉토리에 로그 파일들이 모여있는고 로그를 조회, 정리, 압축 해주는 유틸도 추가되었습니다.
그래서 로그보는 방법을 찾아봤습니다. 오라클 메뉴얼을 뒤져서 찾았습니다.

adrci라는 로그 관리 프로그램을 실행한뒤 필요한 명령을 실행하면 됩니다. 아래의 예제를 참고하시길...

[oracle]$ adrci
adrci> show alert -tail
(alert log중 최근 데이터 일부만 보기)

adrci> show alert -tail 50
(alert log중 최근 데이터 50건만 보기)

adrci> show alert -tail -f
(alert log를 "tail -f"처럼 실시간으로 모니터링하기)

adrci> show tracefile
(trace file 보기)

adrci> show tracefile -i 프로세스id
(특정 프로세스의 트레이스파일 찾기)

adrci> show tracefile %mmon%
(mmon의 트레이스 파일을 찾기. like 검색이라고 생각하면 된다. %ckpt%로 입력하면 체크포인트 트레이스파일을 검색한다.)

파라미터들은 소문자로 입력해도 잘 됩니다. 최소한 -tail 옵션은 잘 되더군요.
그럼 다음번에는 문제 분석을 위한 정보 수집 방법을 정리해보겠습니다.


iPhone 에서 작성된 글입니다.

지난번에 Postgres-XC 1.0.0에 대해서 글을 올렸는데 아직 문제가 좀 있다고 했었죠 이번에 1.0.1 버전을 테스트한 결과를 정리해서 올립니다. 짧게 얘기하면 "좋아졌다"입니다. ^^/


• 1.0.1 버전 개요
Postgres-XC 1.0.1은 PostgreSQL 9.1.5를 기반으로 만들어졌습니다.


• 지난버전 테스트 결과와 다른 점
1. 관리 툴
pgAdmin III 1.16.0 버전을 사용하면 오류메시지없이 접속됩니다. 한가지 아쉬운점이라면 dbms 버전 정보에는 PostgreSQL 9.1.5로 표시된다는 점입니다.

2. 트랜잭션 문제 해결
함수 내부에서 "select for update"로 데이터를 가져와서 다이나믹쿼리로 update문을 실행하면 일부 세션에서 데이터를 잘못가져오는 문제가 해결되었습니다.
1번 세션에서 begin 명령으로 트랜잭션을 시작한 후, 해당 함수를 실행한 뒤에 2번 세션에서 함수를 실행했을때 1번 세션의 트랜잭션이 종료된 후 update된 값을 "select fir update"로 가져와서 update해줍니다. 정상적으로 작동한다는 얘기입니다.
제 설명이 좀 복잡한가요? 회사에서 아이폰으로 작성하는거라 좀 시간도 부족하고 글 쓰기도 좀 힘드네요. 다음에 코드와 함께 집에서 다듬어서 적성하겠습니다.



iPhone 에서 작성된 글입니다.

Kairos mmdbms에서 공간 데이타를 추출하여 Kairos 혹은 이기종의 dbms에 적재하는데, ETL 툴을 사용하려하였으나 현재 검토 중이던 툴이 정상적으로 지원하지 않아서 kloader라는 Kairos 자체 툴을 이용하였다.

# kloader -h server_ip -p port_no -cp UTF-8
kloader> gisget -t table_name -shp output_dir/filename.shp ;
위는 추출할때 명령

위의 명령을 실행하면 세개(네개였었나)의 파일이 생성되는데 모두 scp 등을 이용하여 로딩할 서버로 전송한다.

마찬가지로 kloader를 실행한 뒤.
kloader> gisput -t table_name -shp intput_dir/filename.shp -mode append ;
대이타를 적재할때에는 "-mode"를 꼭 설정해야한다. 테이블에 존재하는 기존 데이타를 유지할지 지울지를 정해주는 것이므로 매우 중요한 파라미터이다.

iPhone 에서 작성된 글입니다.

이번에 ETL 작업을 하면서 겪은 당황스런 일을 적어두려합니다. 이번 작업은 아래에 설명할 두가지이며, 작업 환경은 다음과 같습니다.
세대의 장비는 모두 같은 건물 안에 있습니다. 멀리 넷트웍을 타고 전송되는 상황은 아닙니다.
ETL tool : GeoKettle
DBMS : PostgreSQL 9.x, Kairos 5.x


1. PC(1 cpu)에 설치된 PostgreSQL DB에서 데이타를 추출하여 서버(4 cpu)상의 PostgreSQL DB에 전송하는 작업.

2. 서버(4 cpu)상의 PostgreSQL DB에서 데이타를 추출하여 다른 서버(4 cpu)상의 Kairos DB에 데이타를 전송하는 작업.

1번 작업은 데이타 원본이 윈도우가 설치된 PC상에 있어서인지 오래 걸렸습니다. 더군다나 테이블끼리 1대 1로 전송하는게 아니라 원본에서 조인을 해서 추출을 하는 작업이었습니다. 오래걸리더군요. 이건 각오한 문제였구요.

그런데... 2번 작업에서 큰 문제가 생겼습나다. Kairos는 메모리 DB인데 데이타 로딩이 아주 느리더군요. 이건 뭐...
서버에서 서버로 보내는 것이고, 테이블도 거의 1대 1로 전송하는 상황이었고, 메모리도 각각 50GB 정도 설치되어 있었습니다. 더군다나 아직 서비스에 쓰이는 장비도 아닌데 초당 270건 정도밖에 안되더군요. ㅠㅠ

그래서 눈물을 머금고 text로 추출해서 로딩하는 방식을 썼습니다.

한가지 더 문제가 있었는데, GeoKettle로 Kairos에 데이타를 이전할때 not null 제약이 걸린 컬럼에 null 값이 들어가면 오류가 발생하지 않고 행이 걸린것처럼 멈춰 있더군요. jdbc 드라이버 문제인지 GeoKettle의 문제인지 모르겠습니다. 암튼 이 문제땜에 에러가 안 뜨니 좀 기다려보자는 생각에 시간을 많이 소비했었죠.




사용한 툴과 디비를 보시면 아시겠지만 gis 관련 데이타를 다루는 작업이었습니다. 문제는 Kairos는 GeoKettle이 지원하지 않는 제품이라 이 툴로는 일반적인 문자, 숫자 등의 데이타가 아닌 공간 데이타는 Kairos로 이전을 할 수가 없었습니다. 오픈소스인 Pentaho Kettle 기반의 제품이니까 공부를 좀 해서 Kairos의 공간 데이타를 인식할 수 있게 만들어 보고 싶다는 생각을 해봅니다. 실제로 진행을 할 수 있을지는 모르겠습니다만...

그럼 평온한 밤 보내시길~~~

iPhone 에서 작성된 글입니다.

그동안 오픈소스 ETL툴인 Pentaho kettle을 업무에 도입하기 위해 그리고 개인적으로 공부를 해왔었는데, 큰 문제를 만나게 되었습니다. 바로 지리공간정보를 다루게 되니... 데이터형 문제가 발생하더군요. 그래서 구글님께 물어봤더니 답을 주시더군요.

GeoKettle입니다.

www.spatialytics.org

이 툴은 오픈소스 ETL 툴인 Pentaho Kettle에 지리정보를 다룰 수 있도록 - spatial data type을 인식하도록 플러그인( 이게 맞는지는 아직 확인 중입니다. )이 미리 설정되어 있습니다.

PostGIS가 설치된 PostgreSQL에서 테스트 해본 결과 100만건의 geometry형의 data를 전송하는데 별다른 문제는 없었습니다. 160초 가량 걸리더군요. 원본 디비가 개인 PC라서 좀 느린게 아니었을까 생각합니다.

한가지 단점이라면 Big data 관련 기능이 추가된 Kettle 4.3버전이 아니라 4.2 버전을 기반으로 했는지 Big data관련 기능이 일부 빠진것 같더군요. 이 부분은 곧 해소되지 않을까 생각합니다.

더 자세한 기능 분석은 좀 더 사용해본 뒤에 작성하겠습니다.

iPhone 에서 작성된 글입니다.

Postgres-XC로 시스템을 구축하려고 공부 중입니다. 아직 보기 좋게 정리는 못 했고 우선 간단히 장단점을 적어보려합니다.
회사에서 외부 사이트를 거의 막아놔서 아이폰에서 작성하는거라 글로만 설명하는 점 이해해주시길 바라며...

1. 장점
1.1. Open source라 구축 가능한 인력과 시간, 그리고 장비만 있으면 소프트웨어 라이선스 비용은 들지 않는다.

1.2. 읽기 및 쓰기 부하 분산이 가능하다.

1.3. Oracle RAC처럼 어플리케이션에서는 읽고 쓰는것을 구분하여 디비 접속을 하지 않아도 된다. 전체 노드가 읽기 및 쓰기가 가능하다.

2. 단점
2.1. 1.0 버전이 출시된지 몇달되지 않아서 구축 사례와 한글로 된 자료 등이 거의 없다.

2.2. PostgreSQL 9.1.x 버전에서만 사용 가능하다. 고로 이전 버전을 쓰고 있다면 업그레이드를 해야한다.

2.3. Trigger를 지원하지 않는다.
현재로는 지원하기 어렵다고한다.

2.4. 관리 툴의 부재
기존의 pgAdmin으로는 접속시 오류가 발생하여 관리가 불가능하다.

2.5. 트랜잭션의 문제
펑션 내부에서 dynamic query를 이용하여 update를 하도록 만들어서 여러세션에서 사용했을때, 트랜잭션을 걸어서 사용하면 일부 update문이 실행되지 않는 문제 발생.
설정의 문제인지 버그인지 확인 중입니다.

그런데 위의 문제로인해서 일단 업무에 Postgres-XC을 도입하는것은 보류한 상태입니다.


iPhone 에서 작성된 글입니다.

CentOS 6.2를 설치하면 예전과 다르게 scim이 아니라 ibus를 통해서 한글 입력이 가능하게 되어있다.
뭐 이건 별 문제가 되지 않는다. 쓰면되지 뭐... 근데 그놈과 일부 패키지들을 선택했더니 ibus는 설치가 됐는데 정작 한글은 입력할 수 없었다. 왜일까? 이리저리 검색해서 찾은 해답은 아래와 같다.

yum으로 한글 관련 패키지를 추가로 설치해야한다.
ibus-hangul
ibus-anthy
위의 두개 패키지를 설치하면 입력방식 설정창에서 한글과 일본어를 추가할 수 있게된다. 근데 일본어는 왜 같이 추가되는걸까? 이것도 한번 찾아봐야겠다.


iPhone 에서 작성된 글입니다.