개요 

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

특정 개발환경 별 참고 문서는 각 개발환경 별로 작성된 기술문서를 참고하도록 합니다.

본 문서에는 일반적인 사항을 기술하며 문서 후반에는 ALTIBASE 에러메시지들에 대하여 설명하고 있습니다. 

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

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

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

3. 『Altibase 이중화 구성 가이드』

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

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

6. 『Altibase Precompiler 가이드』

7. 『Altibase SQL 튜닝 가이드』

8. 『JAVA 개발 가이드』

9. 『Altibase VC 2010 개발가이드』

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

설계 단계의 고려사항

Altibase를 이용하여 DB 또는 시스템 설계를 수행하는 경우 고려할 사항들을 설명합니다. 설계 단계에서 고려하지 못한 사항들은 이후 개발뿐 아니라 운영 단계에까지 미치는 영향이 크기 때문에 반드시 아래 사항들을 고려하여 설계에 참고할 것을 권장합니다.

이중화 환경의 고려사항

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

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

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

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

   
   
   

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

   이중화 환경에서는 동일한 Primary Key를 갖는 레코드를 양쪽 서버에서 동시에 서로 다른 값으로 변경할 경우, 서버 간 충돌로 인해 원치 않는 데이터 불일치가 발생할 수 있습니다. 이를 방지하기 위해서는 다음과 같은 설계적 고려가 필요합니다.
   
   

   1. 업무 로직 분리
      

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

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

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

      
      

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

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

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

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

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

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

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

HA외에도 물리적인 디스크 장애로 인한 데이터파일의 손상 및 트랜잭션 로그파일의 손상으로 인한 장애에 대비하여 백업정책을 수립해야 합니다. ALTIBASE의 백업 방식은 아카이브 모드를 이용한 전체 백업 방식과 증분 백업 방식을 모두 제공하고 있습니다.

따라서, 사용자는 백업 시점에 (1) 오프라인 상태에서 모든 필요 파일을 콜드 백업하는 방식, (2) 온라인 상태에서 데이터베이스 또는 테이블스페이스 단위의 전체 백업 방식, (3) 온라인 상태에서 데이터베이스 또는 테이블스페이스 단위의 증분 백업 방식 중 하나를 선택해야 합니다.

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

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

테이블 설계의 고려사항

1. 테이블 저장 위치를 목적에 맞게 선정
   Altibase는 메모리/디스크 테이블스페이스를 모두 지원합니다.
   
   
   1. 메모리 테이블스페이스
      초고속 처리 성능이 요구되는 업무에 적합합니다.
      트랜잭션 빈도가 높고, 데이터 유효기간이 짧은 테이블(예: 세션 정보, 당일 거래 데이터 등)에 권장됩니다.

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

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

       

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

   고려사항	설명
   숫자형	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 조건에 사용되는 컬럼은 반드시 동일한 타입으로 정의해야 합니다. 서로 다른 타입 간 비교 시 내부 형 변환이 발생하여 성능 저하를 유발할 수 있습니다.

    

    

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

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

파티션 테이블의 제한

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

하드웨어 준비의 고려사항

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

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

Not Support Feature

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

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

개발 단계의 고려사항

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

DBMS 접속 방식의 선택

1. Altibase 접속 방식의 선택

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

   CONNTYPE=n의 의미는 접속 방식을 지정하는 것으로, 프로그램 내에서 접속 문자열을 지정할 경우 사용자가 명시적으로 지정할 수 있습니다.
   DBMS와 응용 프로그램이 서로 다른 서버에 위치하는 경우에는 CONNTYPE=1 방식만 사용이 가능합니다.
   하지만, DBMS와 응용 프로그램이 동일한 서버에서 동작한다면 네트워크 통신 비용 절감을 위해 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을 수행하면 됩니다.

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

Thread 프로그램, Connection Pool의 관리

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

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

(간혹, 사용자 프로그램에서 Timer를 설정한 경우 위와 같은 동시성 제어 문제가 아니어도 발생할 수 있습니다. 예를 들면, SELECT~FETCH 과정 중에 Timer가 동작되어 아직 FETCH프로토콜이 완료되지 않은 상태에서 다른 SQL문이 수행될 경우 위와 같은 오류가 발생할 수 있습니다.)

Application의 연결해제 시 확인사항

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

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

Session Timeout

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

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

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

위의 TIMEOUT에 의한 오류가 발생하면 다음과 같은 에러를 응용 프로그램에서 확인할 수 있습니다.

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

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

사용자가 위의 조치로 해결하기 어렵고 업무적으로 처리를 강제로 해야 한다면 DB전체의 속성 값을 변경하기 보다는 해당 프로그램의 DB세션에 대해 해당 TIMEOUT 설정 값을 변경하여 처리하도록 합니다.

SELECT Cursor 사용 시 주의

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

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

SQL Error의 체크

Altibase환경의 개발자는 모든 질의 처리 이후 반드시 SQL Error를 체크할 것을 권장합니다. 특히, 다음의 경우를 반드시 체크하도록 해야 명확한 오류를 알아낼 수 있습니다.

위 코드에서는 PREPARE 또는 DECLARE CURSOR수행 후 에러 체크하는 부분이 없습니다. 이 경우 PREPARE (DECLARE CURSOR)단계가 오류였을 경우라면 EXECUTE (OPEN)단계에서 SQL오류는 “Not defined (XX)” 와 같은 오류가 발생하여 실제로 PREPARE (DECLARE CURSOR) 오류로 인함임에도 불구하고 해당 오류를 정확하게 확인할 수 없습니다.

ALTIBASE는 PREPARE (DECLARE CURSOR) 수행과정도 서버로 질의를 전송하여 Execute전 단계까지 질의처리 과정을 해놓기 때문에 PREPARE (DECLARE CURSOR)를 수행한 이후에도 반드시 에러를 체크하는 로직을 넣어야 합니다.

중요한 점은 모든 SQL처리 문이 들어간 경우는 반드시 SQL에러체크를 수행하도록 해야 한다는 점을 알아두어야 합니다.

LOB 타입의 주의

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

테이블의 컬럼에 LOB를 빼고 조회를 할 경우는 상관이 없으나 SELECT 타겟절에 LOB 타입이 포함될 경우 위와 같은 오류가 발생합니다. 따라서, LOB 타입을 조회할 때에는 반드시 세션의 속성을 Non-Auto-Commit모드로 변경을 한 후 수행하도록 해야 합니다.
단, Altibase v6.3.1 이상의 JDBC 드라이버를 사용할 경우에는 Client Side에서 트랜잭션 Commit 모드를 제어하도록 설정하여 Auto-Commit 모드에서도 LOB 타입의 데이터를 조회할 수 있습니다.
JDBC 드라이버의 Client Side에서 트랜잭션 Commit 모드를 설정하는 방법은 아래와 같습니다.

• altibase_cli.ini 예시

Prepared Statement의 사용

Altibase는 질의처리의 성능을 빠르게 하기 위해 내부에 수행된 질의의 실행계획을 저장하고 있습니다. 하지만, 매번 PREPARE/EXECUTE를 하는 형태의 질의를 수행하게 되면 내부적으로 이미 PREPARE된 실행계획을 사용하게 되지만 PREPARE를 수행하는 네트웍 비용이 매번 발생하기 때문에 이러한 성능 감소 요인을 막기 위해서는 다음과 같이 코드를 작성할 것을 권장합니다.

오픈 소스 중에는 OTL (Oracle, Odbc Template Library)라는 DB개발 라이브러리가 있습니다. 이 라이브러리는 모든 질의를 매번 Prepare/execute를 수행하는 형태로 처리하고 있습니다. 단, streaming옵션을 활성화 시키면 한번 prepare된 질의는 execute만 수행하는 형태로 처리하게 되는데 이런 튜닝요소를 통해 (네트웍 전송비용의 감소) 응용 프로그램의 처리속도를 2배 이상 향상 시키는 경우도 있으므로 개발자는 질의 처리를 수행하는 과정에서는 가능한 dynamic SQL을 최소화 시키고 동일한 질의를 매번 prepare하고 있지는 않은지 확인하도록 해야 합니다.

위의 코드는 매번 실행할 SQL문장을 만들고 prepare한 후 execute하도록 실행합니다. 이런 경우는 다음과 같이 한다면 간결하고 합리적이라 할 것입니다.

SQL Tuning

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

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

위와 같은 명령을 수행한 후 iSQL이나 또는 AdminCenter2와 같은 유틸리티에서 질의를 수행하면 수행된 실행계획을 확인할 수 있습니다.

위의 실행계획은 T1 테이블을 FULL SCAN하고 레코드에 대해 262,145번 접근했음을 확인할 수 있습니다. 만일, 인덱스가 존재하고 인덱스를 타도록 조건을 명시한다면 다음과 같이 출력될 수도 있을 것입니다.

------------------------------------------------------------
PROJECT ( COLUMN_COUNT: 1, TUPLE_SIZE: 4 )
SCAN ( TABLE: T1, INDEX: IDX_T1, ACCESS: 2, SELF_ID: 2 )
------------------------------------------------------------

SQL튜닝과 관련된 사항은 『ALTIBASE SQL 튜닝 가이드』문서를 참고하면 더 많은 정보를 얻을 수 있으므로 개발 전에 개발자들은 반드시 읽어볼 것을 권장합니다.

대량 변경 작업의 주의

일반적인 대량 변경작업은 Altibase뿐 아니라 타 DBMS에서도 부하가 크기 때문에 각 벤더 별로 요구하는 주의사항들이 존재합니다. ALTIBASE는 다음과 같은 사항의 주의가 필요합니다.

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

Altibase Trace 로그

Altibase는 설치된 경로인 $ALTIBASE_HOME/trc 경로에 모듈 별로 중요한 상태정보 및 에러 등에 대해 Trace 로그를 기록하고 있습니다. 이 에러들에 설명합니다.

Trace 로그의 분류

Altibase가 기록하는 Trace로그는 다음과 같습니다.

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

이하에서는 사용자에게 의미 있는 중요한 메시지들에 대한 각 Trace로그 별로 분리하여 설명합니다.

altibase_boot.log

사용자는 DBMS에서 오류가 발생하면 altibase_boot.log를 먼저 확인해야 합니다. 표 중에 orange color표시는 사용자가 반드시 조치할 에러입니다.

altibase_sm.log

altibase_sm.log는 체크포인트의 수행여부 및 장시간 수행되는 질의의 존재 여부 등을 판단해볼 수 있는 중요한 근거가 됩니다.

altibase_qp.log

altibase_qp.log에는 사용자가 수행한 DDL의 수행기록 및 DB 속성값을 “ALTER SYSTEM” 구문으로 변경을 가하는 경우 등에 대한 로그가 기록됩니다.
아래와 같이 분류됩니다.

altibase_rp.log

altibase_rp.log에는 이중화의 동작상태에 대한 로그가 기록됩니다

altibase_rp_conflict.log

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

이중화 Conflict가 발생하면 앞서 설명한 이중화 환경의 고려사항을 제대로 준수하지 않았거나 이중화 지연으로 데이터 불일치가 발생했을 가능성이 있기 때문에 Conflict 발생 시 남는 SQL문을 통해 원인을 찾는 것이 중요합니다.

altibase_dk.log

altibase_dk.log에는 Database Link를 사용하는 환경에서 발생할 수 있는 여러 가지 정보 및 에러를 기록합니다.

altibase_error.log

altibase_error.log에는 Altibase 비정상 종료 발생 시, 원인 분석을 위한 중요한 단서를 제공합니다.

Client Application 에러 메시지

Altibase를 사용하는 응용 프로그램을 운영하는 환경에서 자주 발생하는 에러 유형들을 소개하고 각 유형들에 대해 어떤 사항들을 개발자가 확인해야 하는지를 설명한다.

Connection does not exist

DBMS에 연결이 되지 않은 상태 또는, 단절된 상태에서 질의를 처리하려고 할 경우 발생하는 오류이다. 다음의 경우들에서 발생할 수 있다.

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

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

Communication link failure

일반적으로 위의 “Connection does not exist” 는 이 오류 다음으로 발생하게 된다. 이 에러는 질의를 수행과정에서 세션이 단절된 상태를 의미한다. 원인은 앞서 설명한 것처럼 TIMEOUT정책에 의해 해제되는 경우가 일반적이다. 간혹, 네트웍의 문제로 연결이 단절되는 경우가 발생할 수 있다.
이 문제는 통신소켓상의 문제로 다양한 원인으로 발생할 수 있기 때문에 다음의 사항들을 체크하고 확인할 것을 권장한다.

Calculate stack overflow

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

이 값은 메모리의 증가를 유발하기 때문에 전체 시스템에 반영하여 사용하기 보다는 해당 세션만 변경하여 사용하도록 할 것을 권장한다.

Conversion not applicable

다음과 같은 경우에 발생한다.

위의 예제처럼 BYTE컬럼에 CLOB의 데이터를 넣을 경우 형 변환을 CLOB을 BYTE로 변환할 수 없음으로 에러를 발생시킨다. Altibase 변환 함수는 어떤 데이터 타입의 입력 값을 다른 데이터 타입으로 변환한다. 변환함수에 대한 내용은 Altibase SQL Reference 매뉴얼을 참고하면 된다.

Invalid cursor state

CURSOR를 사용할 때 다 사용된 CURSOR를 정상적으로 CLOSE CURSOR처리를 하지 않은 채 다시 OPEN CURSOR를 하려고 시도할 경우 발생한다. 또는 이미 Fetch가 완료된 CURSOR를 다시 Fetch하려고 시도하는 경우에도 발생한다.

간혹, 사용자 프로그램이 쓰레드인 경우 연결객체에 대한 동시성 제어를 제대로 하지 않아 자신의 쓰레드에 유효하지 않은 커서를 핸들링 할 경우도 발생하게 되는데 앞에서 설명한 것처럼 반드시 CURSOR를 사용 후에는 명시적으로 CLOSE CURSOR 구문을 사용함으로써 문제를 해결하도록 해야 한다.

Not defined cursor

CURSOR를 사용할 때 CURSOR NAME을 명시하는데 이 CURSOR NAME이 존재하지 않거나 혹은 DECLARE(PREPARE) CURSOR를 수행하는 과정에서 오류가 발생했는데 이를 체크하지 않아 EXECUTE 혹은 OPEN CURSOR단계에서 오류가 발생할 때 이 에러가 나타난다. 사용자는 반드시 다음과 같이 개발을 해야 한다.

Invalid request to process the SQL statement

일반적으로 쓰레드 구조의 프로그램에서 자주 발생하며 앞에서 설명한 바와 같이 쓰레드 구조의 연결 객체에 대한 동시성 제어가 올바르지 않을 경우 ALTIBASE 서버와 클라이언트 간에 주고 받아야 하는 프로토콜의 순서가 틀려지는 경우 발생한다.

먼저, 프로그램의 구조가 쓰레드라면 이러한 동시성 제어가 올바른지 확인하도록 해야 한다. 혹은, PREAPRE->BINDING->EXECUTE와 같이 질의를 수행해야 하는 순서가 제대로 지켜지지 않은 경우가 있는지 확인해야 한다.

Invalid literal

이 에러는 숫자형 타입에 문자를 입력하는 등의 오류가 발생할 경우 나타난다.

위의 예처럼 컬럼 타입이 숫자형임에도 데이터를 문자열로 삽입하려고 시도할 경우 발생한다.

반대로, 문자열을 숫자형 변수에 담으려고 할 경우에는 다음과 같이 오류가 발생한다.

Invalid length of data type

컬럼 타입보다 더 큰 값으로 데이터가 입력되는 경우 발생한다.

위의 예처럼 컬럼 타입은 2byte까지 저장이 가능한데 입력을 4byte로 하려고 하면 지정된 컬럼 크기보다 데이터 값이 크기 때문에 에러가 발생한다.

Indicator variable required but not supplied error

이 에러는 Precompiler를 사용하는 개발환경에서 발생을 하는데 SELECT 결과에서 컬럼의 리턴 값이 NULL로 리턴 될 경우 INDICATOR변수가 지정되지 않으면 SQL_SUCCESS_WITH_INFO와 함께 이 오류메시지를 발생하게 된다.

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

Invalid size of data to bind to host variable 

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

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

Too many pages are allocated

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

따라서, 불필요한 테이블을 삭제하거나 MEM_MAX_DB_SIZE를 더 큰 값으로 늘리고 Altibase를 재 구동해야 한다. 이러한 임시 조치 이후에는 어떤 이유로 메모리 테이블스페이스의 사용량이 증가 하였는지 각 테이블 별 사용량의 조회나 대량 변경작업등이 발생하지 않았는지 확인하여 조치할 필요가 있다.

The Tablespace does not have enough free space

테이블스페이스의 여유공간이 부족할 경우 발생한다. 디스크 테이블스페이스의 경우 데이터파일의 추가 작업이 필요하다.

The transaction exceeds lock timeout specified by user

DML간에는 Lock을 대기하고 서버에 설정된 TIMEOUT정책에 의해 동작을 하게 되지만 DML에 의해 잡힌 Lock으로 인해 DDL이 대기하게 될 경우 즉시, 이 에러가 발생하게 된다.

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

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

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

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

String data right truncated

SELECT문 등에서 리턴 되는 문자타입의 값이 선언된 호스트변수의 크기보다 클 경우 발생한다. DB에 접속하여 조회하는 테이블의 컬럼 크기를 확인하고 사용된 호스트 변수의 크기를 (컬럼 크기 + 1 byte)로 선언하도록 해야 한다.

Value overflow

숫자형 컬럼의 표현 범위보다 더 큰 값이 입력될 경우 발생한다.

Several statement still opened

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