개요 

...

본 문서는 Altibase을 Altibase를 이용한 개발환경에서 개발자가 고려해야 할 사항들을 설명합니다.

...

본 문서에는 일반적인 사항을 기술하며 문서 후반에는 ALTIBASE 에러메시지들에 대하여 설명하고 있습니다. 문서에서 설명하는 ALtibase v6.3.1이상을 기준으로 합니다. 

다음의 문서들을 환경에 맞게 같이 참고하도록 합니다.

1. 『디스크 IO병목을 『Altibase 디스크I/O 병목을 고려한 볼륨구성 가이드』가이드』

2. 『ALTIBASE 『Altibase 백업정책 결정을 위한 고려사항』고려사항』

3. 『효율적인 『Altibase 이중화 구성 가이드』가이드』

4. 『ALTIBASE 『Altibase 이중화 제약사항 가이드』가이드』

5. 『ALTIBASE 용량 산정 가이드』『Altibase 운영을 위한 시스템 리소스 용량산정 가이드』

6. 『ALTIBASE Precompiler 개발 가이드』『Altibase Precompiler 가이드』

7. 『ALTIBASE SQL Tuning Guide』『Altibase SQL 튜닝 가이드』

8. 『ALTIBASE 자바 개발 가이드』『JAVA 개발 가이드』

9. 『ALTIBASE & VC++2008 Express Edition 개발 가이드』

10. 『ORACLE To ALTIBASE 변환 가이드』

11. 『ALTIBASE & WAS 연동 가이드』

『Altibase VC 2010 개발가이드』

10. 『Oracle to Altibase 변환가이드』

...

1. Altibase는 네트워크 기반의 이중화 방식
   

   Altibase는 네트워크을 네트워크를 기반으로 변경트랜잭션 변경 트랜잭션 로그를 송/수신하여 데이터를 동기화 하는 형태의 이중화 방식을 채택하고 네트워크 환경에서 발생할 수 밖에 없 채택하고 있습니다. 즉, 일반적으로 사용자가 흔히 이해하는 디스크를 공유하는 방식이 아닙니다.
   따라서, 이중화 설계 시 네트워크 환경에서 발생할 수 밖에 없는 있는 데이터 전송지연 등으로 인한 동기화 부분을 고려하여 설계를 해야 등을 고려해야 합니다.

   Altibase의 이중화 방식은 Lazy방식과 Eager방식이 Lazy 방식과 Eager 방식이 있습니다. Lazy방식은 Lazy 방식은 데이터의 전송지연을 허용하는 형태이며 Eager방식은 Eager 방식은 데이터의 지연을 전송지연을 허용하지 않는 형태입니다. 이와 같은 Lazy/Eager의 설정은 세션단위로도 설정이 설정은 이중화 단위로 설정이 가능합니다.
   따라서, 데이터의 전송지연이 허용되는 수준의 업무라면 Lazy방식을 채택하고 그렇지 않은 데이터의 동기화가 반드시 필요한 업무라면 Eager방식을 업무 별로 적절하게 설정하여 운용하도록 합니다운용하시기 바랍니다.

   비교	Lazy 방식	Eager 방식
   성능	단독 서버의 90% 성능 수준	Lazy 방식 대비 현저한 성능저하
   동기화	상대편 서버에 변경트랜잭션 로그의 전송 성공만을 확인하는 구조이기 때문에 성능은 우수한 반면 동기화는 지연될 수 있음	상대편 서버에 데이터 불일치를 원천 방지하기 위해 상대편 서버에 Commit 된 후 로컬에도 Commit 되기 때문에 성능은 급격히 지연되지만데이터의 동기화 부분은 지연되지 않음보장.

   
   
   

2. 데이터 불일치의 방지 방안 고려
   

   이중화 환경에서는 동일한 Primary key를 Key를 갖는 레코드를 양쪽 서버에서 동시에 서로 다른 값으로 변경하는 경우 이중화 방식에서는 서로 다른 레코드로 변경되는 상황이 발생하게 됩니다. 이 경우 사용자가 원치 않는 데이터의 불일치가 발생하기 때문에 업무요건을 충분히 파악하여 변경 업무를 이중화로 구성된 그룹 내에서 한쪽 서버에서만 발생하도록 프로그램을 배치하거나 동일한 PK를 갖는 레코드가 이중화로 구성된 그룹 내에서 변경이 동시에 발생하지 않도록 배치를 해야만 합니다.예를 들면, L4 switch를 사용한다면 업무별로 프로그램을 각기 다른 서버에 배치하여 192.168.1.X망에서 접속한 프로그램은 1번 DBMS서버로 접속을 하고 192.168.2.X망에서 접속한 프로그램은 2번 DBMS서버로 접속을 수행하는 형태의 구성이 가능할 것입니다. 또는, 사용자가 명시적으로 서비스 프로그램의 DBMS접속 부분에 IP를 지정하는 것도 방법이 됩니다.변경할 경우, 서버 간 충돌로 인해 원치 않는 데이터 불일치가 발생할 수 있습니다. 이를 방지하기 위해서는 다음과 같은 설계적 고려가 필요합니다.
   
   

   1. 업무 로직 분리
      

      변경(Insert/Update/Delete) 작업은 반드시 그룹 내 한쪽 서버에서만 수행되도록 배치하고, 다른 서버는 조회(Read) 전용으로 활용하는 방식입니다.
      예를 들어, 서버 A는 실시간 조회 전용, 서버 B는 변경 처리 전용으로 역할을 분리하면 충돌 가능성을 원천적으로 줄일 수 있습니다
      
      

   2. 서버별 데이터 담당 구분

      동일한 PK를 동시에 갱신하지 않도록, PK 범위를 서버별로 나누어 관리하는 방법입니다.
      예: 회원 ID를 기준으로 홀수는 서버 A, 짝수는 서버 B에서만 변경 가능하도록 설계합니다.

      
      

3. 로그 기반의 이중화 방식

   Altibase의 이중화는 로컬서버에서 발생한 트랜잭션의 변경로그를 변경로그를 원격서버로 전송하는 형태입니다. 한 개의 SQL문으로 백만 건을 변경하였다 하더라도 동일하게 변경한 경우, 원격서버로 한 개의 SQL문의 SQL문이 전송되는 형태가 아닌 백만 건의 변경트랜잭션 로그가 모두 전송되는 구조임을 의미합니다.

   이외도 이중화 환경의 주요 고려사항들은 ALTIBASE의 기술문서인『효율적인 기술문서인『Altibase 이중화 구성 가이드』, 『이중화 제약사항 가이드』문서를 반드시 참고하도록 합니다가이드』, 『Altibase 이중화 제약사항 가이드』문서를 반드시 참고하시기 바랍니다.

HA(High Availability) 및 백업에 대한 고려

...

일반적인 상황에서는 장애가 발생하고 복구가 되면 이중화는 자동으로 자신이 가지고 있는 장애시점에 미처 보내지 못한 트랜잭션 로그를 상대편에 보내어 데이터 동기화를 수행하게 됩니다.
하지만, 네트워크의 특성상 장애 시점에 변경트랜잭션 로그의 전송불가에 의한 데이터 변경트랜잭션된 로그가 전송되지 않아 데이터 불일치로 인해 서비스를 바로 Fail-Over할 수 없는 업무가 있는지를 고려해야 합니다.

반드시 데이터가 동기화 된 이후에만 서비스가 가능한 업무라면 Altibase는 데이터 미지연분에 미전송분에 대한 반영을 위해 Off-Line replicator를 제공하고 있습니다.
다만, 이것은 장애 서버의 디스크에 접속이 가능한 상태에서만 사용이 가능하다는 제약조건이 있습니다. (이 기능을 쓰고자 한다면 공유디스크 장비를 구축하는 것을 권장합니다.)

이러한 Off-Line replicator를 사용할 수 있는 환경이 아니라면 프로그램에서 장애시점의 Raw-Data를 누적하여 필요한 부분만큼 정상서버에 반영한 후 서비스를 이관하는 형태의 HA정책을 수립해야 합니다.
예를 들면, 증권사의 경우 대외계를 통해 나가는 모든 데이터는 고유번호로 관리됩니다. 이 번호는 대외계 시스템과 DB에 동일하게 존재하기 때문에 장애 발생시 대외계와 DB시스템 간에 차이가 발생한 부분만큼을 정상 서버에 반영하는 업무로직을 사용하는 경우도 있습니다.

...

백업방식은 다음과 같은 형태 중 하나를 택해야 합니다.

백업과 관련하여 『ALTIBASE 『Altibase 백업정책 결정을 위한 고려사항』문서를 참고하도록 합니다고려사항』문서를 참고하시기 바랍니다.

테이블 설계의 고려사항

...

1. 테이블 저장 위치를 목적에 맞게 선정
   Altibase는 메모리/디스크 테이블스페이스를 모두 지원합니다. 사용자는 빠른 처리성능이 요구되는 업무에 대해서는 어떤 테이블들을 메모리 테이블스페이스 위치 시킬 것인지를 선정해야 합니다.
   즉, 메모리/디스크 테이블스페이스에 각각 위치할 업무 목적 별 테이블의 목록을 작성할 필요가 있습니다.
   다만, 하나의 테이블 명으로 메모리/디스크에 동시에 위치할 수 없기 때문에 예를 들어, 당일 처리를 메모리 테이블에 저장하고 이전 처리를 디스크에 저장하고 한다면 테이블을 2개로 분리하여 EXEC_TABLE_MEM / EXEC_TABLE_DISK 와 같은 형태로 테이블을 생성해야 합니다.
   조회 시에는 가급적 각각의 테이블을 조회하도록 설계하고, 만약 2개의 테이블을 동시에 조회해야 한다면 UNION ALL 을 이용하여 조회하거나 별도의 View를 생성하여 조회하는 방법을 택하면 됩니다.
   단,메모리 테이블과 디스크 테이블로 분리된 2개의 테이블을 동시에 조회하게 될 때의 처리 속도는 디스크 테이블의 처리 성능을 따라갑니다.
   컬럼 타입에 대한 고려
   Altibase가 제공하는 숫자 타입의 경우 Numeric (9)와 같은 타입은 Integer타입으로도 충분히 표현이 가능한데 차지하는 공간은 8byte를 차지합니다.
   Integer타입에 비해 레코드당 4 byte를 더 점유하게 됩니다. 처리 성능 측면에서도 내부적으로 Numeric의 경우 다시 Native타입으로 변환을 해야 하는 비용이 발생하기 때문에 Integer타입에 비해서는 다소 느릴 수 밖에 없습니다
   
   
   1. 메모리 테이블스페이스
      초고속 처리 성능이 요구되는 업무에 적합합니다.
      트랜잭션 빈도가 높고, 데이터 유효기간이 짧은 테이블(예: 세션 정보, 당일 거래 데이터 등)에 권장됩니다.

   2. 디스크 테이블스페이스
      장기간 보관 및 대용량 데이터 적재가 필요한 업무에 적합합니다.
      이력 데이터, 대량 조회 위주의 테이블에 주로 사용됩니다.

   3. Hybrid Partitioned Table(HPT) 활용
      Altibase는 하나의 논리적 테이블을 메모리와 디스크 파티션으로 동시에 구성할 수 있는 HPT 기능을 제공합니다.
      예: 최신 N일 데이터를 메모리 파티션에 저장하고, 그 이전 데이터는 디스크 파티션에 저장하여 단일 테이블처럼 관리 가능.
      애플리케이션 입장에서는 별도 테이블을 구분할 필요 없이 하나의 테이블로 조회할 수 있어 관리 편의성이 높습니다.
      단, Hybrid Partitioned Table을 사용할 경우에도 디스크 파티션이 포함된 쿼리의 경우 성능은 디스크 I/O에 영향을 받게 됩니다.

       

2. 컬럼 타입에 대한 고려
   Altibase에서 컬럼 타입을 선택할 때는 저장공간 효율성, 처리 성능, 연산 특성을 종합적으로 고려해야 합니다. 특히 숫자형과 날짜형의 경우, Native/Non-Native 타입의 차이와 내부 변환 비용이 성능에 직접적인 영향을 줄 수 있습니다.
   다음의 사항들을 컬럼 타입의 선정에 있어 고려할 것을 권장합니다.

   고려사항	설명
   숫자형	1. Native ßà Non-Native의 변환비용 최소화 되도록 고려    (Native타입[Integer, Double, BigInt]이 성능 면에서는 더 유리함) 2. 실수 형의 정밀도를 요하지 않는 경우 Double 타입의 선택 3. Sum, Avg가 사용되는 컬럼이라면 Double, BigInt 타입의 선택Altibase의 숫자형 타입은 크게 Native 타입과 Non-Native 타입으로 구분됩니다. Native 타입 (성능 유리, 내부 변환 불필요) SMALLINT (2 Byte) INTEGER (4 Byte) BIGINT (8 Byte) DOUBLE (8 Byte, 부동소수점) Non-Native 타입 (저장 시 내부 변환 발생, 성능 불리) NUMERIC(p, s) (정밀도 p, 소수점 자리 s 지정, 최대 38자리 지원) 1. Native 타입 우선 사용 동일한 데이터를 표현할 수 있다면 Native 타입을 선택하는 것이 변환 비용을 줄이고 성능상 유리합니다. 예: 단순 정수형 데이터는 NUMERIC보다는 SMALLINT/INTEGER/BIGINT 중 크기에 맞는 타입 사용. 2. 정수형 데이터 값의 범위에 따라 SMALLINT, INTEGER, BIGINT 중 가장 작은 범위를 선택해 저장공간을 절약합니다. 3. 실수형 데이터 고정된 정밀도가 꼭 필요하지 않다면 DOUBLE 타입을 선택하는 것이 성능상 유리합니다. 정밀도를 반드시 보장해야 하는 경우에만 NUMERIC(p, s) 사용. 4. 집계 연산 고려 SUM, AVG가 자주 사용되는 컬럼은 DOUBLE 또는 BIGINT 타입을 권장합니다. (NUMERIC 사용 시 변환 비용 증가 가능)
   날짜형	날짜 관련 연산이 중요한 경우라면 Date 타입을 선택하고 검색 및 비교 연산에 국한된 경우라면 Char/Varchar타입을 선택 (Date 타입은 8byte로 고정되어 있음)
   Join	Join이 발생하는 컬럼이라면 형 변환이 발생하지 않도록 고려	JOIN 조건에 사용되는 컬럼은 반드시 동일한 타입으로 정의해야 합니다. 서로 다른 타입 간 비교 시 내부 형 변환이 발생하여 성능 저하를 유발할 수 있습니다.

    

    

3. 이중화 대상인 경우 반드시 Primary Key를 가져야 합니다.

4. Foreign Key는 트랜잭션의 성능을 저하시킴으로 무분별하게 사용하지 않습니다저하시키기 때문에 무분별한 사용은 자제해야 합니다.

파티션 테이블의 제한

...

Altibase 파티션 테이블의 경우 현재까지 (버전 67.3.1기준0기준) Partitioned Local Index, Non-Partitioned Global Index를 지원하고 있으며 Partitioned Global Index를 지원하고 있지 지원하지 않습니다.
따라서, 파티션 테이블 전체를 조회하는 조건 절에 파티션 키가 배제된 형태의 조회 시에는 현저한 성능저하가 발생하기 때문에 파티션 테이블은 성능 저하가 발생할 수 있으므로  업무 목적상 히스토리성 데이터를 월별, 목적별 보관 형태의 목적으로 사용할 목적별로 분리 보관하는 용도로 사용하는 것을 권장합니다.

하드웨어 준비의 고려사항

...

위에서 언급한 사항들과 관련된 물리적인 고려사항을 정리하여 설명합니다.

...

추가적으로 Altibase의 리두로그 파일에 대한 정책은 무한 생성이라고 볼 수 있습니다. 몇 개의 리두로그 파일을 생성하고 재사용하는 구조가 아니라 계속 새로운 리두로그 파일을 생성해 가는 정책을 쓰기 때문에 대량 변경작업등으로 인한 리두로그 파일의 대량 생성이 불가피할 경우들이 있기 때문에 리두로그 파일이 저장될 디스크의 공간은 충분히 책정하는 것이 바람직합니다.
하드웨어적인 용량산정과 하드웨어 용량 산정과 관련된 자세한 사항은 『ALTIBASE 용량산정 가이드』문서를 참고하도록 합니다가이드』 문서를 참고하시기 바랍니다.

Not Support Feature

...

Altibase는 SQL92 표준을 준수하지만 타 DBMS와 비교하여 약간 상이한 부분들이 존재합니다.
이와 관련된 자세한 사항은 각 타 DBMS벤더 별로 제공되고 있는 기술문서를 참고하도록 합니다.

(Ex)『ORACLE To ALTIBASE 변환 가이드』『MSSQL to Altibase 변환가이드』, 『Oracle to Altibase 변환가이드』, 『Altibase, Oracle 비교 자료』

개발 단계의 고려사항

...

개발 단계에서 필요한 고려사항들을 정리하여 설명합니다.

...

1. Altibase 접속 방식의 선택

   접속방식	설명
   CONNTYPE=1	TCP/IP 방식의 접속, 일반적인 접속 방식
   CONNTYPE=2	UNIX Domain Socket 방식의 접속, 로컬서버 내에서만 사용가능
   CONNTYPE=3	IPC 방식의 접속, 로컬서버 내에서만 사용가능

   CONNTYPE=n 의 의미는 접속방식을 의미하며 프로그램 n의 의미는 접속 방식을 지정하는 것으로, 프로그램 내에서 접속 문자열을 지정할 경우 사용자가 명시적으로 지정할 수 있습니다.
   DBMS와 응용 프로그램이 별도의 분리된 서버에 위치하면 프로그램이 서로 다른 서버에 위치하는 경우에는 CONNTYPE=1 의 방법만 방식만 사용이 가능합니다.
   하지만, DBMS와 응용 프로그램을 같은 서버에서 구동할 수 있는 경우라면 통신비용의 감소를 위해서 CONNTYPE=2, 3을 선택하는 것을 프로그램이 동일한 서버에서 동작한다면 네트워크 통신 비용 절감을 위해 CONNTYPE=2 또는 CONNTYPE=3 방식을 권장합니다.

    

2. Altibase는 Auto-Commit 모드가 기본 설정
   JDBC는 표준 스펙상 Auto-Commit모드로 접속하게 됩니다. 그 외 응용프로그램은 사용자가 별도로 변경하지 않는 이상 기본적으로 $ALTIBASE_HOME/conf/altibase.properties 파일 내에 정의된 “AUTO_COMMIT” 속성에 속성값에 의해 결정됩니다.
   이 속성값이 “1” 이면 Auto-Commit 모드로 동작합니다. (Auto-Commit이라 함은 변경 트랜잭션 정상적으로 완료된 후 자동으로 Commit이 수행됨을 의미)
   따라서, 사용자가 이 속성값을 Non Auto-Commit으로 변경하고자 한다면 설정파일에서 해당 속성값을 “0”으로 변경한 후 ALTIBASE를 재 구동 해야 합니다.
   만일, 세션 별로 제어를 할 경우에는 DBMS에 접속한 이후 다음과 같은 SQL을 수행하면 됩니다.

   Code Block
   theme DJango language sql
   ALTER SESSION SET AUTOCOMMIT = FALSE; (Java의 경우는 setAutoCommit함수를 이용하여 제어하도록 합니다.)

   (ALTER SYSTEM 명령을 위해 명령으로 시스템 전체에 반영하도록 실시간으로 변경할 수 있으나 재 구동 후에 다시 원복 될 것임으로 전체에 영향을 미치는 속성의 변경은 프로퍼티 파일을 통해 수정하고 재 구동하는 방법을 있으나 재구동 시 원복되므로, 전체에 영향을 주는 설정 변경은 반드시 프로퍼티 파일에서 수정 후 재구동하는 것을 권장합니다.)

Thread 프로그램, Connection Pool의 관리

...

Thread 환경의 프로그램에서는 하나의 연결을 다수의 Thread가 공유할 경우 반드시 해당 연결에 대한 동시성 제어를 개발자가 수행해야 합니다. Altibase는 세션과 서버간의 통신과정에서 약속된 프로토콜을 주고 받습니다.
일반적으로 PREPARE -> BIND -> EXECUTE -> FETCH등의 과정을 거치게 되는데 되는데 이 과정이 순차적으로 진행되어야 할 상황에서 상황에서 다른 프로토콜이 인터럽트가 발생하여 세션처리 과정이 잘못 처리되는 과정에서 오류가 발생하게 되는 것입니다중간에 개입하면 세션 처리 과정이 잘못되어 오류가 발생할 수 있습니다.

Communication link failure (EXEC->INVL)

Communication link failure (PREP->EXEC)

Invalid request to process the SQL statement

위의 오류들은 Thread 프로그램 또는 Connection Pool을 사용하는 과정에서 하나의 연결이 어떠한 SQL을 수행 중에 동시성 제어가 안 된 상태에서 또 다른 SQL을 진행시킬 경우 발생합니다.
따라서, 위와 같은 오류가 발생하면 먼저 개발자가 작성한 프로그램에서 연결 부분에 대한 동시성 제어나 처리과정 중에 잘못된 인터럽트가 발생하지 않는지 확인이 필요합니다.

...

프로그램에서 수행한 SQL문들은 개별 프로그램과 서버에 prepared된 prepared 상태로 존재합니다. 이러한 SQL문들은 사용이 완료되면 완료되면 관련 자원을 해제하도록 코드를 개발하는 코드에 반영하는 것이 바람직합니다.  특히  특히, 자바의 경우 메모리 증가 현상이 발생할 수 있으므로 다음과 같은 코드가 반드시 중요합니다.

Connection con = pool.getConnection();
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery();

try
{
   ….
} exception ()
{
   …..
}
finally
{
    // 개발자가 프로그램 내에서 사용한 모든 자원을 명시적으로 해제하도록 합니다.
    rs.close();
    stmt.close();
    conn.close();
}

CLI/ODBC등의 개발의 경우도 마찬가지로 ODBC 등의 개발에서도 동일하게, SQLAllocStmt로 메모리가 할당된 이후 사용이 끝난 시점에는 반드시 SQLFreeStmt 함수를 통해 SQL_DROP을 수행해야 합니다. 재사용이 된다면 재사용할 경우에는 SQL_CLOSE 옵션을 이용하도록 하며 그렇지 않고 , 완전히 해제할 경우라면 경우에는 SQL_DROP 옵션을 통해 사용하여 명시적으로 자원을 해제하도록 합니다.

Session Timeout

...

세션은 DB에 접속한 프로그램의 연결을 의미합니다. 각 세션은 Altibase 고유의 Timeout정책에 의해 관리됩니다. Altibase는 크게 5가지 Timeout정책을 Timeout 정책을 제공하고 있으며 다음과 같습니다. (아래 색상이 표기된 것은 연결 문자열에서만 제어가 가능합니다.)

...

만일, 사용자가 연결시도에 대한 5초 시간제한과 네트웍상의 네트워크상의 블로킹현상이 발생할 경우 이를 30초안에 응답이 없으면 연결을 해제하겠다고 설정한다면 다음과 같이 연결 문자열에 옵션을 추가하면 됩니다.

...

그 외의 TIMEOUT설정은 기본적으로 $ALTIBASE_HOME/conf/altibase.properties에서 properties 에서 설정한 단위로 동작하게 되며 세션 별로는 다음과 같은 질의를 수행하여 제어가 가능합니다. (“0” 으로 설정할 경우 무한대로 동작하게 됨무한대 동작)

ALTER SESSION SET QUERY_TIMEOUT = 30 (-- 초 단위)
ALTER SESSION SET FETCH_TIMEOUT = 30

...

TIMEOUT 관련 에러는 $ALTIBASE_HOME/trc/altibase_boot.log에도 log 에도 기록이 남게 됩니다.

위의 로그가 altibase_boot.log에 기록이 되면 개발자는 반드시 왜 Timeout으로 인한 오류가 발생했는지 확인하여 조치해야 합니다.
각각의 원인은 앞에서 설명한 바와 같기 때문에 질의처리의 병목으로 발생했다면 해당 질의를 튜닝 해야 할 것이며 위의 예제처럼 UTrans_Timeout이 발생한다면 변경 트랜잭션이 발생한 후 commit/rollback을 수행하지 않은 것임으로 접속정보를 통해 해당 프로그램의 트랜잭션 제어부분을 반드시 수정/조치해야 합니다.

...

CURSOR를 이용한 SELECT문을 구현할 때에는 반드시 FETCH 구문에 대해 에러체크를 에러 체크를 수행하고 에러가 발생하거나 혹은 데이터를 모두 읽은 후에는 반드시 CURSOR를 CLOSE하도록 CLOSE 해야 합니다.
만일, 이미 다 읽은 CURSOR를 FETCH하려고 하거나 아직 닫히지 않는 CURSOR에 어떤 작업을 시도할 경우 의도하지 않은 오류가 발생할 수 있으므로 CURSOR를 사용한 뒤에는 반드시 정상적으로 CLOSE하도록 CLOSE 해야 합니다.

또 하나의 주의사항은 ALTIBASE의 경우 FETCH도중에 COMMIT/ROLLBACK이 발생하게 되면 자동적으로 열린 CURSOR를 닫게 됩니다CURSOR가 닫힙니다. 따라서, FETCH를 수행하면서 다른 트랜잭션을 발생하고자 할 경우에는 별도의 DB세션을 생성 한 후 해당 세션을 통해 별도의 트랜잭션을 처리하도록 하거나 FETCH가 모두 완료된 이후 COMMIT/ROLLBACK을 수행하도록 해야 합니다. 하지만, 처리해야 하는 레코드 건수가 많다면 대량 변경으로 수행하기 보다는 별도의 세션을 맺어 매건 처리하는 구조로 구현하는 것을 권장합니다.  변경될  
변경될 레코드의 개수가 하나의 트랜잭션으로 반드시 묶여야 한다면 조건을 주어 나누어서 처리가 되도록 프로그램을 개발하는 것이 바람직합니다.

...

Altibase에서 LOB타입을 조회할 때에는 반드시 Non-Auto-Commit모드로 동작해야 한다합니다. Auto-Commit모드에서는 다음과 같은 오류가 발생할 수 있습니다.

[ERR-91101 : Connection is in autocommit mode. One can not operate on LOB datasdata with autocommit mode on.]

...

DB업무와 관련해 개발 작업을 진행하다 보면 질의 처리가 느린 경우들이 발생합니다. 혹은, 테스트 환경에서는 빠르게 처리되었는데 통합테스트 또는 운영 단계에서 질의가 매우 느린 경우들이 발생합니다. 이것은 개발자 혹은 DBA가 수행되는 모든 질의에 대해 실행계획의 검증이나 테스트 과정을 소홀히 한 경우라고 볼 대한 테스트 과정이나 실행계획 검증이 제대로 안 된 경우일 수 있습니다.

Altibase는 질의의 처리과정 즉, 실행계획을 다음과 같이 확인할 수 있습니다.

...

1. 메모리 테이블의 대량 변경작업 시 메모리 증가의 가능성
   Altibase는 MVCC(Multi Version Concurrency Control)기법을 지원합니다. MVCC기법은 변경이 발생할 경우 동일 레코드를 해당 테이블의 빈 공간에 복제하여 복제하여 변경을 가하게 수행하게 됩니다.
   만일, 천 만 건을 변경하면 천 만 건의 복제 본으로 인한 메모리 증가가 발생할 수 밖에 없습니다.
   (물론 이렇게 늘어난 영역은 다시 데이터 또는 복제영역으로 재활용이 되지만 실시간으로 메모리를 해제 시키지는 않습니다.)
   
   
2. 대량 변경작업을 수행함으로써 트랜잭션 로그파일의 지속적인 증가
   대량의 변경작업은 각 변경 대상 레코드에 대한 리두로그를 트랜잭션 로그파일에 기록해야 합니다.
   따라서, 하나의 트랜잭션 내에 변경되는 모든 레코드의 리두로그를 기록해야 하는데 만일, 이 대상의 범위가 많다면 그만큼의 트랜잭션 로그파일도 많이 생성될 수 밖에 없습니다.
   (Altibase는 체크포인트 시점에 트랜잭션 로그파일을 삭제하게 되는데 로그파일에 트랜잭션이 지속중인 정보가 존재하면 삭제할 수 없고 이로 인해 로그파일 증가에 의한 디스크 부족의 장애가 발생할 가능성이 있습니다.)
   
   
3. 이중화 환경에서의 Dead-Lock 발생 가능성 및 반영 지연
   이중화 환경에서는 앞서 설명한 바와 같이 하나의 트랜잭션이 변경한 모든 레코드의 변경정보를 상대편 서버로 전송하게 됩니다.
   이 과정에서 상대편 서버의 해당하는 레코드에 대하여 락을 유지하게 되는데 만일, 상대편 서버에서 동일한 범위에 속하는 레코드를 변경할 경우 이중화 로그에 의해 발생한 트랜잭션과 상대편 서버 자체에서 발생하는 트랜잭션 간에 데드락이 유발될 간에 Deadlock이 발생할 수 있습니다.

Altibase Trace 로그

...

해당 로그파일은 기본적으로 10개까지 altibase_xx.log를 포함하여 altibase_xx.log-[1-10]까지 순환되면서 로그를 기록하게 됩니다.

...

...

...

altibase_rp.log

...

altibase_rp.log에는 이중화의 동작상태 및 각종 Conflict발생 시의 질의가 기록되기 때문에 이중화 문제의 추적에 있어 중요한 단서제공을 하고 있습니다.동작상태에 대한 로그가 기록됩니다

altibase_rp_conflict.log

...

altibase_rp_conflict.log에는 각종 Conflict발생 시의 질의가 기록되기 때문에 이중화 문제의 추적에 있어 중요한 단서제공을 하고 있습니다.

위 예시에서 사용된 이중화 객체 명은 “REP1” 입니다. 사용자가 지정한 이중화 객체는 이름이 다를 것이므로 에러에 대한 조회 시에 이를 고려하도록 해야 하며 주로 이중화 Sender/Receiver의 동작 상태 및 Conflict 오류를 감지할 것을 권장합니다.또한, 이중화 Conflict가 발생하면 앞서 설명한 이중화 환경의 고려사항을 제대로 준수하지 않았거나 이중화 지연으로 데이터 불일치가 발생했을 가능성이 있기 때문에 어떠한 이유로 그러한지 Conflict 발생 시 남는 SQL문을 통해 원인을 찾는 것이 중요합니다.

...

Client Application 에러 메시지

...

1. 앞에서 설명한 TIMEOUT정책에 의해 연결이 해제된 이후 질의를 수행할 때
2. 쓰레드 프로그램의 경우 존재하지 않는 연결 고유 명을 이름을 사용한 경우

위의 사항들을 점검하고 관련 사항에 적합한 조치를 취하도록 한다. 예를 들어, TIMEOUT정책에 의해 발생하였다면 해당 세션의 TIMEOUT 설정 값을 늘리거나 또는 질의의 튜닝을 진행 하는 식의 조치가 필요하다.

...

Altibase 내부적으로 질의를 처리하는 과정에서 사용되는 객체로, 수행되는 질의가 필요로 하는 Stack이 부족한 경우 발생한다. 사용자는 해당 질의의 수행 전에 다음과 같이 질의를 수행한 후 에러가 발생한 질의를 수행하면 정상적으로 처리할 수 있다.

...

위의 예제처럼 BYTE컬럼에 CLOB의 데이터를 넣을 경우 형 변환을 CLOB을 BYTE로 변환할 수 없음으로 에러를 발생시킨다. 즉, 각 컬럼 타입끼리는 호환이 가능한 매트릭스가 있는데 그러한 호환 가능하지 않는 질의를 처리하게 될 경우 이 에러가 발생한다.컬럼 타입 간의 호환은 ALTIBASE ODBC User 매뉴얼을 Altibase 변환 함수는 어떤 데이터 타입의 입력 값을 다른 데이터 타입으로 변환한다. 변환함수에 대한 내용은 Altibase SQL Reference 매뉴얼을 참고하면 된다.

Invalid cursor state

...

위의 경우처럼 INDICATOR변수를 명시적으로 사용하거나 또는, Precompiler의 옵션에서 –unsafe_null 옵션을 이용하여 에러가 발생하지 않도록 할 수 있다.

Incompatible NLS between the client and the server

Altibase 서버로 접속을 시도할 때 서버에 설정된 문자셋과 다른 문자셋 값으로 접속을 시도할 경우 발생한다. 예를 들어, 서버는 MS949로 설정된 상태인데 클라이언트에서 US7ASCII와 값으로 접속을 시도할 경우 이러한 에러가 발생한다.

서버에 설정된 문자셋을 조회하는 방법은 다음과 같다.

이 에러는 5.3 이전 버전들에서만 발생하게 된다. 5.3버전부터는 문자셋이 달라도 US7ASCII로 접속은 가능하다. 다만, 서버와 클라이언트간의 문자셋의 차이로 한글과 같은 문자를 저장하려 할 경우 올바르지 않은 데이터로 저장될 수 있음으로 주의가 필요하다.

Invalid size of data to bind to host variable 

...

...

이 에러는 호스트 변수의 크기보다 더 큰 데이터를 넣어 질의가 처리될 경우 발생한다. 예를 들어, CHAR (20)으로 선언한 호스트변수에 20보다 큰 문자열이 들어올 경우 발생한다. 일반적으로 개발자가 변수의 초기화의 실패 또는, 쓰레기 값이 들어올 경우 발생할 수 있다. 또는, 쓰레드 환경의 프로그램에서 동시성 제어 실패로 A 문장을 PREPARE한 후 바인딩을 해야 하는데 B 문장의 바인딩을 수행할 경우 발생할 수 도 있다. (A문장은 20byte를 binding하면 되는데 잘못 핸들링 하여 B문장의 100byte를 바인딩 하는 형태)

일단, 사용자는 해당 호스트 변수 값을 출력하여 명확히 길이를 넘지 않는지 체크하고 쓰레드 부분의 핸들링에 있어서도 동시성 부분에 문제가 없는지 확인하도록 해야 한다.

 

Invalid character in use

일반적으로 한글에 대해 LIKE 검색 시 발생을 하게 되는데 예를 들어 Altibase 서버의 문자셋 값을 KO16KSC5601로 설정하였는데 KO16KSC5601의 표현 범위를 넘어선 문자가 뒤섞여서 저장된 경우 발생한다.
위의 오류가 발생한 경우에는 다음과 같이 작업을 하는 것을 권장한다.

즉, 한글을 사용하는 경우라면 KSC5601보다 MS949 / UTF8과 같은 문자셋을 사용하고 서버와 일치하는 문자셋으로 접속하여 처리할 것을 권장한다.

Too many pages are allocated

...

Altibase 메모리 테이블스페이스의 경우는 모든 메모리 테이블스페이스의 합산이 $ALTIBASE_HOME/conf/altibase.properties 에서 설정한 MEM_MAX_DB_SIZE를 초과할 수 없다. 이 에러메시지는 모든 공간이 소진되어 발생한다.

...

위의 표와 같이 A세션이 먼저 DML을 통해 Lock을 획득한 상태에서 B세션이 DDL을 수행하려고 할 경우 이 에러가 발생하기 때문에 DDL_LOCK_TIMEOUT에 의해 위 에러가 발생한다. 따라서 해당 테이블에 Lock이 존재하는지 체크하고 조치한 후 작업을 진행하면 된다.

...

The update log size ‘…’ is bigger than TRX_UPDATE_MAX_LOGSIZE ‘…’

...

Altibase에서는 대량 변경작업이 유발하는 후속적인 장애상황을 Altibase는 대량 변경작업으로 인한 부작용을 방지하기 위해 변경 , 변경 트랜잭션에 의해 발생하는 리두로그의 양이 $ALTIBASE_HOME/trc/altibase.properties에 properties에서 설정한 TRX_UPDATE_MAX_LOGSIZE에 명시된 값보다 커질 경우 LOGSIZE 값을 초과할 경우, 이 에러를 발생시키고 롤백처리를 하게 된다롤백 처리한다.
사용자는 해당 트랜잭션이 반드시 하나의 질의문으로 처리되어야 한다면 세션 레벨에서 다음과 같이 이 속성 값을 변경하여 처리하도록 한다. 기본값 10485760 (단위 바이트)

ALTER SESSION SET TRX_UPDATE_MAX_LOGSIZE = 0;  (해당 제약을 없애는 설정)

ALTER SESSION SET TRX_UPDATE_MAX_LOGSIZE = 52428800;  (해당 제약을 50MB로 설정)

단, 이렇게 변경하여 처리할 경우 리두로그 파일의 생성이 많아져서 디스크 풀 장애와 같은 상황이 발생할 수 있으므로 주의가 필요하다. 또한, ALTIBASE는 대량 변경 작업 시 MVCC로 인한 리소스의 증가를 방지하기 위해 테이블에 X-Lock을 획득하려고 시도하기 때문에 X-Lock획득 이후 해당 테이블에 조회 및 변경이 X-Lock으로 인해 대기하게 됨으로 사용자의 주의가 필요하다. 보다 자세한 내용은 『09-18. ERR-11118』를 참고하도록 한다.

String data right truncated

...

Several statement still opened

...

Fetch 프로토콜이 진행 중에서 CREATE TABLE과 같은 질의가 수행될 때 DDL을 수행하면 발생한다. 따라서, 모든 동일 세션에서 CURSOR-FETCH가 완료된 후 DDL을 수행하거나 열려 있는 CURSOR를 CLOSE한 이후 DDL질의를 수행하도록 해야 한다. 또는, 별도의 세션에서 DDL질의를 수행하도록 코드의 변경이 필요하다.

...