pajama

Oracle 에서 Informix 로 Porting 하는 가이드

A Discussion of the Application Porting Issues
Informix Dynamic Server Version 7.3x

CHAP 1. 소개

CHAP 2. DDL

2.1 식별자(Identifiers)

식별자는 데이터베이스, 테이블, 컬럼, 인덱스, 뷰, 프로시저 등의 데이터베이스 오브젝트를 나타내는 이름이다.

2.2 데이터베이스 (Databases)

※ ANSI 데이터베이스의 특징
트랜잭션이 암시적(implicitly)으로 정의되므로 begin work 문장이 필요없이 모든 문장이 트랜잭션안에 들어간다.
데이터베이스의 모든 오브젝트는 소유자(owner)의 이름을 필요로 한다.
Grant to public 개념이 없으므로 각각의 사용자에게 권한을 부여해야 한다.

2.3 테이블 (Tables)

※ constraint 정의 구문 예제

※ Informix의 alter table 구문은 좀 더 풍부한 기능을 제공한다
- 컬럼 추가 및 삭제, 컬럼명 변경, next size변경, lock mode변경 등

2.4 자료형 (Data types)

※ NULL , 공백 문자열
오라클의 빈(empty) varchar 컬럼은 null로 간주한다.
공백이 들어간 문자열의 비교에서 오라클을 공백을 문자열 간주하고 인포믹스는 공백을 무시한다, 즉 오라클은 "abc" != "abc " 이고, 인포믹스는 "abc" = "abc " 이다.

2.5시퀀스 (Sequences)

2.6 인덱스 (Indexes)

2.7 뷰 (Views)

2.8 스토어드 프로시저 (Stored Procedures)

2.9 오라클 확장형 (oracle extensions)

CHAP 3. DML

3.1 SQL

3.1.1 selects
데이터를 읽어오는데 가장 적합한 방법을 옵티마이저가 어떻게 결정하느냐에 의해 질의가 실행 된다. 오라클과 인포믹스 7.3버전 이후 서버는 select문에서 옵티마이저 힌트를 사용할 수 있다.

3.1.2 Optimizer Directives
인포믹스 7.3이후 부터 오라클과 흡사한 옵티마이저 지시자(directives)를 제공한다.
질의가 수행될 때의 첫번째단계는 질의에 대한 최적화 경로를 찾아 컴파일하고 두번째 단계로 결과값을 출력한다.

인포믹스의 옵티마이저 지시자는 오라클의 옵티마이저 힌트와 구문과 동작에서 호환성이 있다.
지시자는 '+'기호가 따라오는 주석(comment)안에서 사용된다.
예)
select {+ ORDERED AVOID FULL(e)} * from employee e, department d 
where e.dept_no = d.dept_no;

오라클의 직접적인 힌트외에 인포믹스는 유일하게 negative directives 의 개념을 제공한다. 즉, 옵티마이저가 피하는 (avoid) 최적화 방법을 지시할 수 있다. 또한 set explain 의 출력결과에서 옵티마이저 지시자에 대한 모든 정보를 알 수 있어 지시어의 의미 또는 구문 에러를 표시할 수 있다.

옵티마이저 지시자는 다음과 같은 최적화 프로세스를 제어할 수 있다
· Access methods: 인덱스 또는 전체 스캔.
· Join Methods: hash join 또는 nested loop joins.
· Join Order: 지정한 테이블 순서에 의해 join
· Goal: first rows 또는 all rows (최초 응답시간 대 전체 산출 결과).

3.1.3 Inserts
INSERT INTO…SELECT 구문을 사용할 때 인포믹스는 select절에 union 을 사용할 수 없고, INSERT INTO…VALUES 에서 수식이나 select절을 사용할 수 없다. 이러한 경우 select에 대한 결과를 INTO TEMP 절을 사용하여 임시테이블을 생성하고, INSERT INTO…SELECT 절 구문을 임시테이블로 부터 읽어와서 입력하도록 재작성해야한다.

3.1.4 Deletes

오라클의 DELETE table_name 구문은 DELETE FROM table_name 구문으로 고쳐야한다

3.1.5 Temporary Tables
인포믹스와 오라클의 temporary table은 개념에 있어서 많이 다르다. 
오라클의 temporary table은 하나의 필드를 포함하는 배열과 같이 구현되어 있다.
인포믹스의 temporary table은 일반 테이블과 동일하게 구현되어 생성, 변경, 삭제 등의 작업을 할 수 있지만, 세션안에서만 유효하다.

3.1.6 Joins
오라클의 outer join 구문 + (조인 테이블의 컬럼에 부합하지 않는 값을 가진 컬럼의 뒤에 붙는다) 는 인포믹스의 OUTER 구문과 동일하다. OUTER 키워드는 테이블명 앞에 붙는다. 오라클과는 달리 괄호로 그룹화되어 복합(multiple) outer join을 허용한다.

오라클의 INTERSECT와 MINUS 오퍼레이터는 UNION과 비슷하다. INTERSECT는 인포믹스에서 WHERE EXISTS 나 WHERE … IN으로 교체할 수 있고, MINUS는 WHERE NOT EXISTS 또는 WHERE … NOT IN으로 교체할 수 있다.

인포믹스의 UNION은 대응되는 select 리스트의 자료형이 일치해야한다. 
만약 그렇지 않을 경우 컬럼 리스트를 변경하거나 자료형을 바꿔야한다.

3.1.7 Order by, Group by
인포믹스에서는 ORDER BY절 또는 GROUP BY절에 사용하는 컬럼 리스트가 반드시 select리스트에 나타나야 한다.

3.1.8 Sorts
오라클에서의 NULL값을 가장 높은 값이고 인포믹스에서는 가장 낮은 값이다. 
그러므로 오름차순으로 정렬을 할 경우 인포믹스에서는 NULL값이 먼저 출력된다.
이를 오라클과 동일한 순서로 변형시키기 위해서는 NULL값을 가장 높은 값으로 만들어 정렬할 수 있도록 stored procedure를 작성하고, 정렬이 끝나고 출력될 때 다시 NULL으로 교체하도록 하여야 한다.

3.1.9 Exceptions
하드 코딩된 오라클의 에러코드 값은 인포믹스의 에러 코드 값으로 교체해야한다.

3.1.10 Correlation Names
UPDATE나 DELETE의 메인 테이블에 대해 correlation name을 사용할 수 없다.

3.1.11 Aliases
테이블에 alias 를 주면 원본 테이블명을 select 리스트나 where절에서 사용할 수 없다.

3.1.12 Hierarchical Queries
인포믹스는 B-트리 형태의 계층적으로 구성된 질의 결과를 만들지 않는다.
오라클은 START WITH 와 CONNECT BY PRIOR 절을 사용하여 구현한다.
START WITH 는 루트 노드의 행을 지정하고, CONNECT BY에서 부모 노드와 자식 노드의 관계를 서술 한다. 이때 PRIOR 수식을 가장 먼저 확인한다.

다음 예는 JOB이 PRESIDENT인 직원을 루트 노드로 하여 그 아래 모든 하위 노드를 출력하는 질의어이다.

SELECT ename, empno,
              mgr, job 
FROM emp 
START WITH 
job = 'PRESIDENT' 
CONNECT BY PRIOR 
empno = mgr

오른쪽 테이블은 위의 질의 결과를 도식화하여 나타낸 것이다. 위와 같은 기능을 인포믹스에서 사용하려면 stored procedure나 function을 작성하여 cursor 또는 array를이용해야 한다. 인포믹스의 global array가 도움이 될 것이다.

3.2 호스트 변수 (Host Variables)

데이터 형에 따라 호스트 변수의 포맷을 변경할 필요가 있을 수 있다. 
예를 들어 number나 date같은 자료형은 인포믹스에서 동일한 포맷으로 지원되지 않으므로 SQL문장안에서 포맷을 정의하는 절차를 거쳐야 한다.

예를들어 오라클 함수 TO_CHAR는 날짜와 숫자 값의 포맷을 사용한다. 
비슷한 방식으로 인포믹스는 7.3 버전 이후 TO_DATE와 TO_CHAR 함수를 추가하였다. 
또한 ESQL/C에서는 오라클의 날짜 포맷에 대응하여 인포믹스 날짜 포맷을 출력하는 ifx_to_gl_datetime() 함수를 가지고 있다.

위의 경우 포맷은 인포믹스에서 제공하는 값을 사용해야하며 오라클의 모든 포맷을 반 드시 포함하고 있는것은 아니다.

3.3 날짜 및 시간 함수 (Date and Time Functions )

현재 날짜를 처리하기 위하여 오라클은 SYSDATE를 사용하는데, 인포믹스에서는 다음과 같이 자료형에 따라 다르게 표현한다.

SQL문으로 현재 시스템 날짜를 얻기 위하여 SELECT DISTINCT TODAY FROM SYSTABLES 
와 같이 사용한다. 또한 ESQL/COBOL의 ECO_TDY()함수나 ESQL/C의 rfmtdate()함수에서도 제공된다.

인포믹스의 날짜 처리 형태로 변환해야할 오라클 함수

· ADD_MONTHS(date,months), 
· LAST_DAY(date)
· MONTHS_BETWEEN(date1, date2)
· NEW_TIME(date,current_timezone,new_timezone)
· NEXT_DAY(date,char)
· ROUND(date,format)
· SYSDATE
· TRUNC(date,format)

오라클의 TO_CHAR, TO_NUMBER, TO_DATE 함수에 대한 포맷은 다음 표를 참조한다.

3.3.1 number format

3.3.2 date format

3.3.3 RR format
RR 포맷을 YY 포맷과 유사하지만 서로 다른 세기(century)의 날짜값을 구분하기 위하여 사용한다

3.4 집계 함수 (Aggregagte Functions )

3.5 수학 함수 (Mathematical Functions )

인포믹스는 오라클의 수학함수 CEIL, FLOOR, SIGN, COSH, SINH, TANH를 지원하지 않는다. ROUND함수에서 round factor -32 에서 32까지의 값을 사용할 수 있다.

3.6 스트링 함수 (String Functions)

3.7 기타 오라클 함수

인포믹스는 다음과 같은 오라클 함수를 지원하지 않는다.

· CHARTOROWID 
· CONVERT
· DUMP 
· GREATEST 
· GREATEST_LB 
· HEXTORAW 
· LEAST 
· LEAST_UB 
· RAWTOHEX 
· ROWIDTOCHAR 
· TO_LABEL 
· TO_MULTI_BYTE 
· TO_SINGLE_BYTE 
· UID 
· USER 
· USERENV(OSDBA/ LABEL/ LANGUAGE/ TERMINAL/ SESSIONID/ ENTRYID) 
· VSIZE

3.8 매크로(Macros)

인포믹스는 오라클의 macro를 지원하지 않으므로 코드에서 제거해야하고 관련된 로직은 인포믹스에서 동일하게 구현될 수 있다.

3.9 Pseudo-Columns

Pseudo-columns 은 테이블에는 존재하지만 SELECT * FROM table_name 과 같은 질의에서는 나타나지 않는 컬럼이다. 인포믹스에서 pseudo-column은 일반적으로 DBMS엔진에 의해 사용되므로 이러한 컬럼을 어플리케이션에서 직접적으로 사용하지 않는것이 향후 어플리케이션 이식성이나 어플리케이션 변경에 도움이 된다.

3.9.1 LEVEL 
오라클에서 hierarchical query를 할때 pseudo-column LEVEL 은 루트노드에 대하여 1을 리턴하고 그 루트노드의 자식 노드는 2를 노드 2가 부모인 자식 노드는 3을 등등.. 이러한 형태로 출력된다. 
질의에서 hierarchical 관계를 정의하려면 START WITH CONNECT BY 문을 사용한다. 
인포믹스는 hierarchical 질의를 지원하지 않으므로 LEVEL 컬럼을 사용하지 않는다.

3.9.2 ROWID 
오라클의 ROWID 컬럼은 각 데이터 행의 주소를 나타낸다. 
출력되는 ROWID는 다음과 같은 정보를 가지고 있다.

· 데이터파일에서 데이터 블럭의 정보 
· 데이터블럭에서의 행의 정보 (첫번째 행이 0) 
· 데이터파일 정보 (첫번째 파일이 1)

대부분 데이터베이스에서 한 행을 나타내는 ROWID는 유일한 값을 가지지만 서로 다른 테이블에서 동일한 클러스터안에 저장된 행은 동일한 ROWID를 가진다. 
ROWID 컬럼의 값은 오라클의 ROWID 자료형으로 저장된다.

ROWID는 새로 지워지고 새로 입력되면 새로운 값이 할당되므로 이 컬럼을 테이블의 primary key로 사용하지 말아야 한다. 또, ROWID 컬럼값은 입력,수정,삭제 될 수 없다.

SELECT ROWID, ename 
FROM emp 
WHERE deptno = 20

오라클의 ROWID는 인포믹스의 ROWID와 거의 동일하게 동작한다. 하지만 저장되는 
자료형은 서로 다르다.

3.9.3 ROWNUM 
오라클에서 ROWNUM 컬럼값은 선택된 결과 레코드의 순서를 나타낸다. 
다음과 같은 질의는 첫번째 9개 행을 출력한다.

SELECT * FROM emp WHERE ROWNUM < 10

이런 ROWNUM을 이용하여 테이블의 각 행에 유일한 값을 할당할 수 있다.

UPDATE tabx SET col1 = ROWNUM

오라클은 각 행을 읽어온후 ROWNUM을 할당하고 ORDER BY절에 의해 정렬되므로 ORDER BY에 의한 순서와 ROWNUM 순서가 다를 수 있다. 그러나 ORDER BY절에 사용되는 컬럼이 인덱스를 사용한다면 순서가 같아진다. 다음과 같은 질의는 아무런 행도 리턴하지 않는다.

SELECT * FROM employee WHERE ROWNUM > 1

첫번째 행을 가져와서 ROWNUM을 1로 할당하므로 조건에 맞지 않아 출력되지 않는다. 
두번째 행이 출력되기 위해서는 ROWNUM이 1로 다시 할당되는 이때도 조건에 맞지 않기 때문에 출력되지 않고 이후의 모든 행이 마찬가지 상태가 된다.

인포믹스는 ROWNU과 동일한 컬럼을 가지고 있지는 않지만 FIRST N 구문을 이용하여 구현할 수 있다.

인포믹스는 다음과 같은 복합적인 경우에는 사용할 수 없다.

· subqueries 
· into temp 문 
· view 정의 
· stored procedure 
· union 질의

ORDER BY 없이 FIRST N구문을 사용하면 의미없는 순서로 데이터가 출력될 것이다.

/* 월급이 가장 많은 10명을 출력 */ 
SELECT FIRST 10 name, salary FROM emp ORDER BY salary; 
/* 10개의 최고 월급 출력 */ 
SELECT FIRST 10 DISTINCT salary FROM emp ORDER BY salary;

인포믹스 7.3은 "FIRST"란 이름으로 컬럼명을 사용할 수 있다. 따라서 "FIRST" 뒤에 양의 정수가 따라 오지 않는 경우는 테이블의 컬럼명으로 생각한다. 
N값은 1에서 231 - 1 까지 사용할 수 있다.

UPDATE tabx SET col1 = ROWNUM

위와 같은 오라클의 ROWNUM을 할당하는 구문의 경우 ESQL/C 로 아래와 같이 구현한다.

int counter = 0;
EXEC SQL declare c1 cursor for
	SELECT col1, col2 
	  INTO :col1, :col2 
	  FROM table 1 
	 WHERE col1 = "XX";
EXEC SQL open c1;
while (SQLCODE == 0) {
	EXEC SQL fetch c1;
	counter++;  /* Increment counter for each row fetched */
	if (counter >= 5)	{
		break;
		/* logic... */
	}  /* End if */
}  /* End while */

3.10 커서를 이용한 수정 (Update Using Cursors )

인포믹스와 오라클의 커서는 약간의 차이가 있다. 
오라클과는 달리 인포믹스에서는 FOR UPDATE 커서가 여러 테이블을 조인하는 경우에는 사용할 수 없으므로 WHER CURRENT OF 문장을 테이블 조인상태에서 사용할 수 없다. 
따라서 테이블을 조인해야할 경우는 동일한 커서 루프에서 WHERE CURRENT OF 문장을 제거하고 UPDATE문장을 분리하여야 한다.

인포믹스에서 commit 또는 rollback 문은 트랜잭션안에서오픈된 모든 커서를 닫는다. 
커서를 닫지 않고 commit 또는 rollback을 실행하여야 할 경우 HOLD 커서를 선언할 수 있다. 그러나 HOLD커서는 FOR UPDATE 문에서 사용될 수 없다. 
따라서 오라클에서 fetch 루프안에서 업데이트하거나 commit하는 어플리케이션은 인포믹스의 형태로 변환해야한다. 커서는 HOLD를 사용하여 선언하고 업데이트 문장은 WHERE CURRENT OF 문장 없이 사용한다. WHERE CURRENT OF 문장의 의미를 나타내기 위하여

WHERE ROWID = fetch된 rowid값 또는 
WHERE primary key 컬럼 = fetch된 primary key 컬럼값

형태로 작성한다.

오라클의 트랜잭션 내의 fetch 루프를 구현하기 위하여 BEGIN WORK 문장이 COMMIT WORK 나 ROLLBACK WORK 문장에 바로 따라 올 수 있도록 한다.

3.11 시스템 테이블(System Tables )

오라클의 시스템 테이블 참조는 이에 대응되는 인포믹스의 시스템 카타로그 테이블 차조로 교체할 수 있다.

3.12 스토어드 프로시저 (Stored Procedures)

3.12.1 Size 
인포믹스의 stored procedure는 대략 64K의 한계가 있다. 
오라클의 64K가 넘는 procedure는 좀더 작은 단위로 쪼개고 필요한 매개변수와 리턴값을 서로 주고 받을 수 있도록 한다.

3.12.2 Packages 
오라클의 stored function과 stored procedure는 인포믹스의 stored procedure로 교체할 수 있다. 그러나Package body는 stored procedure와 stored function의 그룹을 포함하고 있고 package는 stored procedure와 stored function의 리스트를 가지고 있다. 
모든 package body는 인포믹스의 개별적인 stored procedure로 재작성해야 하고 package 레벨의 변수는 인포믹스의 global 변수로 대응시켜야 한다.

3.12.3 Exceptions
오라클은 CURSOR_ALREADY_OPEN, NO_DATA_FOUND, ZERO_DIVIDE 등과 같이 미리 정의되거나 사용자 정의된 exception label을 가지고 있다. 
EXCEPTION 구조를 사용한 BEGIN/END 블럭에서 하나의 exception 만 허용되고 보통 END 문 바로 앞에 EXCEPTION 처리문이 위치 한다.

인포믹스 또한 미리 정의되거나 사용자가 정의한 exception을 지원하지만 표현 방식이 label형태가 아니고 숫자로 나타난다. 모든 exception은 stored procedure의 control block에서 체크되고, 각 control block의 상단부에 EXCEPTION문으로 명시적으로 선언해야한다.

오라클에서는 exception 처리가 global하게 처리된다. 
인포믹스에서는 블럭단위로 exception처리가 제한된다.

3.12.4 Error Handling 
SQLCA 구조체는 stored procedure에서 완벽하게 지원하지 않는다. SQLCODE 변수 체크는 불가능하다. 대신 DBINFO 함수를 사용해 sqlca.sqlerrd1과 sqlca.sqlerrd2 값을 추출해 낼 수 있다. 이 함수는 커서가 열린FOREACH 문안에서 사용될 수 있다.

3.12.5 Cursors
오라클의 global 커서는 인포믹스에서 temporary 테이블을 통하여 구현한다.
오라클 procedure에서는 커서를 명시적으로 선언하고 오픈하지만 인포믹스에서는 procedure안에서 명시적으로 커서를 선언할 필요 없다. 따라서 오라클의 procedure 커서는 인포믹스의 FOREACH 구조로 변환할 수 있다.

3.12.6 Flow Control
오라클에서는 GOTO 와 EXIT 같은 점프 문장을 허용하지만 인포믹스에서는 루프를 빠져나가는 EXIT만 허용한다.

3.12.7 Variable Declaration and Assignment
오라클은 FOR 루프안에서 암시적(implicit) 변수 선언이 가능하다.

Out_customer_name := customer.name;

위의 out_customer_name은 customer테이블의 name 컬럼과 동일한 자료형을 가진다

인포믹스는 각각의 control block 상단에 모든 변수를 선언해야한다.

DEFINE out_customer_name LIKE customer.name;
DEFINE counter INTEGER;

따라서 오라클의 암시적 변수 선언은 인포믹스에서 control block 앞에 명시적(explicit) 변수 선언으로, 오라클의 할당 연산자 := 은 LET 키워드와 등호(=) 표시로 교체해야 한다.

3.12.8 Boolean
오라클의 BOOLEAN 자료형 변수는 char(1) 또는 정수형의 변수로 교체하고 프로그램적으로 제어하도록 한다.

3.12.9 Binary Data Types
오라클에서 binary형은 RAW로 사용하고 선언부에서 명시적으로 최대 길이를 정의한다. 
인포믹스에서는 REFERENCES BYTE 로 선언하고 단지 BLOB에 대한 포인터만을 관리한다.

3.12.10 Dynamic SQL
인포믹스에서는 procedure안에서 dynamic SQL을 지원하지 않는다. 이러한 종류의 처리는 ESQL/C 프로그램을 통하여 구현할 수 있다.

3.12.11 Compiler
오라클과는 달리 인포믹스의 procedure 컴파일러는 데이터베이스와 독립적으로 procedure를 생성할 수 있도록 하므로 컴파일단계에서는 에러가 상대적으로 적고 메시지가 상세하지 않지만 실행단계에서 데이터베이스 오브젝트의 유효 여부를 판단한다.

3.13 트리거 (Triggers)
오라클은 하나의 트리거에서 동시에 여러 이벤트 (insert, update, delete 등)를 처리할 수 있다. 
인포믹스는 하나의 트리거에서는 오직 하나의 이벤트만을 처리한다.

인포믹스는 오라클에 없는 몇가지 constraint를 제공하는데, EXECUTE PROCEDURE … INTO 구문을 사용하여 트리거가 insert나 update 이벤트 발생시 단지 한 행이나 한 컬럼에 대해서만 영향을 미치도록 할 수 있다.

인포믹스 7.3 이전에는 INSERT나 UPDATE 이벤트나 발생했을 때 트리거를 발생시키는 컬럼에 변경을 줄 수 없었다. 인포믹스 7.3버전 이후 reentrant UPDATE / INSERT 트리거의 기능이 EXECUTE PROCEDURE … INTO 구문을 통해 가능해졌고 이러한 기능으로 동일한 트리거 또는 다른 트리거를 cascade 하게 부르지 못하게 할 수 있다.

다음 예는 reentrant UPDATE / INSERT 트리거의 예이다.

create table foo (
      x int default NULL,
      y int default NULL,
      z int default NULL
);
create procedure reentrant()
	returning int;
	return 56;
end procedure;
create trigger reentrant_trigger insert on foo for each row (
execute procedure reentrant() into z
);
insert into foo values (1, 2, 3);
select * from foo;
x           y           z
1           2          56

오라클에서는 트리거의 본문에 SQL문과 stored procedure, 그리고 logical statement를 사용할 수 있다. 인포믹스는 stored procedure와 SQL문만이 가능하므로 logical statement는 procedure 안으로 옮겨 넣어야 한다.

3.14 Constraints
오라클과 인포믹스는 트랜잭션 안에서 constraint를 enable 또는 disable 시킬 수 있다. 차이점이 있다면 오라클 어플리케이션은 항상 트랜잭션을 사용하고 있고 인포믹스는 명시적으로 지정한 위치에서 트랜잭션을 사용하도록 되어 있다.
다음 constraint 구문은 인포믹스에서 사용가능하다

SET {CONSTRAINTS/INDEXES/TRIGGERS} FOR table_name {ENABLED/DISABLED}
SET CONSTRAINTS comma_separated_constraint_names {ENABLED/DISABLED}
SET INDEXES comma_separated_index_names {ENABLED/DISABLED}
SET TRIGGERS comma_triggers_constraint_names {ENABLED/DISABLED}
SET CONSTRAINTS {ALL/constraint_name} {IMMEDIATE/DEFERRED}

마지막 문장은 DBA권한이 없는 일반 사용자가 사용할 수 있는데, DEFERRED절을 사용하면 모든 constraint 위반 사항을 트랜잭션이 commit되거나 rollback되는 시점에 검사한다.

3.15 DUAL TABLE
오라클의 DUAL 테이블은 dummy 컬럼을 한 행 가지고 있는 시스템 테이블이다.
주로 다음과 같은 경우에 사용된다.

어떠한 상수값을 가져와서 호스트 변수에 저장할 때

SELECT TO_CHAR(SYSDATE) INTO :date_var FROM DUAL;

어떠한 변수값을 다른 변수에 할당할 때

SELECT TO_CHAR(SYSDATE) INTO :date_var FROM DUAL;

호스트 변수값과 일반 질의의 결과를 union할 때

SELECT col1, col2, col3 FROM table_name
UNION
SELECT :host_var1, :host_var2, :host_var3 FROM DUAL;

DUAL 테이블을 변환하는 방법은 DUAL 테이블의 용도에 따라 여러 방법이 있다.
단지 상수값을 할당하는 문장은 인포믹스의 변수값 할당 문장으로 교체할 수 있고 좀 더 복잡하게 사용하는 경우 DUAL 이란 이름으로 temporary 테이블을 만들어 사용할 수 있다.

CHAP 4. Embedded SQL

오라클의 embedded SQL 제품은 Pro*C, Pro*COBOL 이고 이와 관련된 인포믹스 제품은 ESQL/C, ESQL/COBOL이다.

4.1 호스트 변수 (Host Variables)

4.1.1 Declaration Override

4.1.2 Arrays
오라클에서는 배열 변수에 값을 할당하기 위하여 SQL문의 루프에서 배열처리를 할 필요가 없지만 인포믹스에서는 fetch 루프가 필요하다.

4.1.3 Formatting 
인포믹스에서 DECIMAL, MONEY, DATE, 또는 DATETIME 값을 읽어 호스트 변수에 넣을 때 출력할 포맷을 지정하는 과정을 거친다.

…
dec_t	dec_host_var;
char	formatted_dec[40];
EXEC SQL SELECT DEC_COLUMN INTO :dec_host_var FROM TABLE_NAME;
rfmtdec(&dec_host_var, "&&&&&&&.&&&", formatted_dec);
printf("The Decimal Value is %s\n", formatted_dec);
…

4.2 SQL구조체 (SQL Structures)

4.2.1 SQLCA

오라클 에러 메시지를 얻기 위하여 대개 SQLCA요소 중 SQLERRMC를 이용한다. 인포믹스에는 SQLERRM은 같은 기능을 하고HP와 Solaris에서는 SQLERRM대신rgetmsg 함수를 사용할 수도 있다.

4.2.2 SQLDA
오라클의 SQLDA구조는 인포믹스와 상당히 많이 다르다. 오라클의 SSQLALD 함수는 인포믹스의 ALLOCATE DESCRIPTOR문으로 변경되야 하는 등 많은 부분 변경이 필요하다.

만약 오라클 어플리케이션이 SQLDA 구조체를 직접 사용하지 않고 simple dynamic SQL 메소드를 사용했다면 indicators/placehoder는 인포믹스에서 '?로 교체할 수 있다.

4.2.3 ORACA
오라클의 ORACA구조체는 인포믹스에서 지원하지 않는다. 이 구조체는 오라클에서만 특정부분 사용되므로 어플리케이션에서 제거하여야 한다.

4.3 Pre-Compiler Options

어플리케이션에서 EXEC ORACLE OPTION문으로 시작되는 오라클 옵션은 제거한다. 이 문장은 성능과 관련될 수 있는 내용이므로 어플리케이션 로직에 영향을 미치지 않는다.

4.4 Embedded PL/SQL

오라클에서는Pro*C나 Pro*COBOL 코드 안에 프로시저 PL/SQL을 EXEC SQL EXECUTE와 END-EXEC 문 사이에서 포함할 수 있다. 인포믹스에서는 이러한 블럭을 동일한 기능을 하는 ESQL/C나 ESQL/COBOL코드로 변환해야 한다.

4.5 ODBC

Oracle Call Interface(OCI)를 사용하여 작성된 어플리케이션은 인포믹스의 Call Level Interface (CLI)로 재 작성해야 한다.

4.5.1 Database Library Calls
오라클의 OCI와 인포믹스 CLI의 가장 큰 차이점은 전체적인 데이터구조와 데이터베이스 라이브러리 호출을 처리하는데 사용되는 메카니즘이다.
오라클은 데이터베이스 서버로 direct connection을 사용하고 인포믹스는 ODBC connection을 사용한다.

4.5.2 Global Area Processing
또다른 차이점으로 세개의 global 영역을 가리키는 pointer 사용에 있다.
오라클이 사용하고 있는HAD (Handle Data Area), LDA (Logon Data Area), CDA (Cursor Data Area 포인터는 인포믹스에서HENV (Environment Area), HDBC (Database Connection Area), HSTMT (Statement Area) 포인터로 변환해야 한다.

4.5.3 Fetch cycle
오라클의 fetch cycle은 커서 데이터 영역안에서parsing, binding, defining, fetching executing 단계를 거치는데, 인포믹스는 "for each" 안에서 preparing, binding, executing, binding, fetching 단계를 가진다.

4.5.4 Raw Binary Data Type Processing
오라클의 RAW 바이너리 자료형은 pointer-to-BLOB REFERENCES BYTE 형으로 고쳐야 한다.

4.5.5 Parameter Binding
오라클에서 파라매터의 muliple output binding은 ODEFIN() 호출에서 OUTPUT 형으로 선언된다. 인포믹스에서는 SQLBindCol() 호출로 변환한다.
오라클과 인포믹스에서 input/output binding에 차이가 있는데, 오라클에서는 ODEFIN() 호출안에서 INPUT/OUTPUT 형으로 선언한다. 인포믹스에서는A=B, B=C, C=A 처럼 세개의 변수를 사용하여 라운드로빈 형태로 접근한다.

4.6 Embedded SQL for C

4.6.1 VARCHAR
오라클 Pro*C의 VARCHAR 자료형은 프리컴파일 이후 두 개의 요소, 즉 unsigned short len 과 unsigned char arr[size]로 나뉘어진다. 
인포믹스에서는 VARCHAR 형은 C의 CHAR와 동일하다.

4.6.2 Host Variables
오라클의 EXEC SQL TYPE은 C언어의 typedef 와 같다.

4.7 Embedded SQL for COBOL

4.7.1 VARCHAR
Pro*COBOL의 VARYING 절은 프리컴파일 이후 variable-name-LEN PIC S9(4) COMP 와 variable-name-ARR PIC X(size)로 확장된다. 
인포믹스에서는 이러한 개념을 지원하지 않으므로 variable-name-LEN 은 모두 제거하고variable-name-ARR 은 variable-name 으로 수정하며VARYING 절도 제거해야 한다.

4.7.2 Level 88
인포믹스 ESQL/COBOL 7.2 이후 부터 호스트 변수 선언부안에서 COBOL level 88의 기능을 지원한다

4.7.3 SQLDA
ESQL/COBOL 에서는 SQLDA 구조체가 허용 되지 않는다. SQLDA 데이터를 다루기 위해서는 ALLOCATE DESCRIPTOR, DESCRIBE, GET DESCRIPTOR, SET DESCRIPTOR 같은 인포믹스 매크로를 사용해야 한다.

4.7.4 REDEFINDES
인포믹스 ESQL/COBOL 7.2 이후 부터 REDEFINES 구문을 지원한다.

4.7.5 Tips
프리컴파일 할 때IF [ELSE IF … ] END-IF 또는 EVALUATE END-EVALUATE 또는 PERFORM END-PERFORM 블럭안에서 SQL문장을 만나면 SQL 문장뒤에 마침표가 있는지 상관하지 않고 생성된 COBOL 문장뒤에 마침표(period)를 찍는다. 이러한 동작은 COBOL 규칙에 어긋나 구문에러를 발생시킨다. 이런 문제를 피하기 위해 각각의 SQL 문장은 새로운 문단으로 이동시켜서 그룹화 한 뒤 수행되도록 한다.

CHAP 5. Application Architecture

5.1 트랜잭션 처리 (Transaction Processing)

다음 예에서ws-dbenviron 은 데이터베이스 이름, ws-connect-nm 은 사용자 이름ws-identity-nm 은 패스워드enp 와 connection-name 은 연결(connection) 이름이다.

5.1.1 Simple Connect

5.1.2 Named Connect with Literal

5.1.3 Named Connect 

5.1.4 Savepoints 
오라클은 PL/SQL안에서 savepoint는 허용한다. PL/SQL 블럭안에서 COMMIT 또는 ROLLBACK을 SAVEPOINT A, SAVEPOINT B.. 등으로 표시한 곳까지의 범위에 한정시킬 수 있다. 이러한 savepoint는 stored procedure와 같이 생각될 수 있는데, 전체 트랜잭션에 영향없이 호출한 procedure만 실행되던지(commit) 아니면 실패(rollback)될 수 있다. 
인포믹스는 stored procedure 안에서 savepoint 기능을 지원하지 않는다.

5.2 일관성 (Concurrency)

5.3 사용자 인증 (User Authentication)

CHAP 6. Environment

6.1 스크립트 (Scripts)

오라클에서는 '&'가 붙는 치환(substitution) 변수를 사용자 정의할 수 있다. 명령어 중에서 치환변수를 만나면 변수 자체가 아닌 변수에 값을 대입하여 실행하게 된다.
이러한 치환변수는 SQL이나 SQL*Plus 명령 어느 곳에서도 사용될 수 있다.
SQL*Plus에서 값이 정의 되지 않은 치환 변수를 만나면 값이 입력되기를 기다린다.
인포믹스의 dbaccess는 이러한 기능을 제공하지는 않지만, 쉘 스크립트를 이용하여 변수 치환을 할 수 있다.

위의 예제 스크립트에서는 decode 파일에 두가지 컬럼을 가진 행이 있는데,

oldval newval

다음과 같은 명령을 실행하여

subvals.ksh decodefile chgfile

chgfile 에 나타나는 oldval 을 newval 로 교체한다.
이 쉘 스크립트는 standard output으로 기록하는데, 출력 결과는 redirect될 수 있다. 이렇게 redirect된 파일은 dbaccess의 입력 파일로 실행될 수 있다.

6.2 유틸리티(Utilities)

질의의 성능 향상을 위하여 EXPLAIN 유틸리티를 통해 SQL문의 어떻게 데이터베이스에 접근하는지 그 경로를 알 수 있다. 이 유틸리티는 SET EXPLAIN on 문장으로 시작하여 SET EXPLAIN OFF문장으로 종료하고 실행결과는 SQEXPLAIN.OUT파일에 저장된다.
전체 시스템 성능은 onSTAT 유틸리티를 이용하여 모니터링 할 수 있다.

6.3 시스템 카타로그 (System Catalog)

인포믹스시스템 카타로그 테이블내의 모든 오브젝트는 소문자로 저장되고 소유자는 'informix' 이다. Systables 안에서 모든 테이블은 시스템에 의해 tabid가 부여 되고 이것은 다른 시스템 카타로그 테이블과 primary / foreign key로 사용된다.

APPENDIX A. Planning Guide

아래 체크리스트는 오라클 특성을 인포믹스로 얼마나 변환해야 할지 결정하기 위해 유용하게 사용 될 수 있다. 각 항목의 난이도 및 변환에 필요한 노력이 얼마나 필요한지는 1 에서 5단계로 표시된다.

APPENDIX B. Syntax

APPENDIX C. Database Concept

APPENDIX D. ANSI Reserved Words

APPENDIX E. Informix Logic

E.1 CONCAT

CREATE PROCEDURE concat (str1 VARCHAR(255), str2 VARCHAR(255)) 
	RETURNING VARCHAR(255);
	return str1 || str2;
END PROCEDURE;

E.2 INSTR

E.3 LTRIM

CREATE PROCEDURE ltrim (str VARCHAR(255), mask CHAR(1) DEFAULT ' ') 
RETURNING VARCHAR(255);
  	IF str IS NULL THEN
    		RETURN NULL;
  	ELSE
    		RETURN TRIM(LEADING mask from str);
  	END IF;
END PROCEDURE;

E.4 RTRIM

CREATE PROCEDURE rtrim (str VARCHAR(255), mask CHAR(1) DEFAULT ' ') 
RETURNING VARCHAR(255);
  	IF str IS NULL THEN
   		RETURN NULL;
  	ELSE
    		RETURN TRIM(TRAILING mask from str);
  	END IF;
END PROCEDURE;

E.5 TO_CHAR (For Non-Date/Datetime

CREATE PROCEDURE TO_CHAR(i INT)
RETURNING VARCHAR(12);
	RETURN I;
END PROCEDURE;

E.6 YYYYMMDD

CREATE PROCEDURE yyyymmdd (str VARCHAR(10)) RETURNING varchar(8);
  	DEFINE retstr VARCHAR(8);
  	IF str IS NULL THEN
    		RETURN NULL;
  	ELSE
    		LET retstr = str[7,10] || str[1,2] || str[4,5];
    		RETURN retstr;
  	END IF;
END PROCEDURE;

제공 : DB포탈사이트 DBguide.net

우선 게시판 성격에 맞지 않는 글을 올려서 죄송합니다. devel이나 튜토리얼쪽에는 쓰기권한이 없어서 정보를 공유하고자 여기에 올립니다.

DB내의 쿼리를 쓰면서 Shell 에서도 유용하게 쓸 수 있는 Script 작성 방법을 알려드리고자 합니다. 다 아시다시피 Scipt는 컴파일 할 필요도 없고 어떤 시스템에서도 구동할 수 있다는 장점이 있어서 많은 시스템 관리자들이 유용하게 사용들을 하고 있죠. 이런 Script 내에서 SQL문을 삽입하여 사용을 할 수 있는 방법이 있습니다.

다음의 4가지 예제를 통하여 확인해보시고 각자에 맞게 확장된 script를 만들어서 유용하게 사용하시기 바랍니다.

아래의 예제는 informix의 가장 기본적인 sample인 stores_demo를 이용해서 만들어졌습니다.

1. 직접입력(Redirecting input)

#!/bin/sh


안녕하세요. 정상규입니다.

database size를 출력하는 스크립트입니다.

(사용법 : sh dbsize.sh DBNAME)

그리고 IDS instance의 개별 database size를 출력하는 쿼리를 첨부하였으니 확인해보시길 바랍니다.

(dbsize.txt)

참조사이트)

http://www.informix.kr/xe/1177

http://database.sarang.net/?inc=read&aid=2500&criteria=informix&subcrit=qna&id=&limit=20&keyword=&page=4

이 강좌는 윈도우 2000 을 기준으로 작성하고 있기에... 그리고, 초급을 대상으로 하기는 하지만... 조금은 중급적인 부분도 사이사이 다루고 있기에... 조금은 내용이 깊어질 것도 같습니다... ^^

예를 들면 이번 강좌가 그러한 부분중에 하나이지요.. 조금은 중급적인 요소가 없지않은....

해서 이번 강좌는 OLE DB와 UDA(Universal Data Access) 에 대한 이야기부터 한번 해볼까 합니다.. 또한,이 부분을 좀 더 구체적으로 설명하기 위해서2001년 3월말에 나올 taeyo's Advanced ASP 책의 일부를 편집하여 사용할 것이기도 합니다. 히힛... (은근한 책 광고임다... ^-^) 국내 ADO, MTS, COM+의 대가인 최현진 사장(인브레인)님의 감수를 거친 부분이라.... 내용면에서도 조금은 흡족하지 않을까 하는 기대를 가져봅니다... ^^ 기대기대...

우리는 저번 강좌에서 Ms Access와 MS SQL 서버의 경우에 데이터베이스를 ODBC 세팅하는 부분까지 이야기해 보았습니다... 그렇다면 복습의 차원에서 여쭤보겠습니다... 왜??? 무엇땜시.. 우리는 ODBC를 세팅했던 것이었나요? 왜? 그렇게 하지 않으면 안되는 것이었던 것일까아아아아요....~~~~~

그 이유는... 데이터베이스로의 접근 때문이었습니다. 예전의 데이터베이스들은 폐쇄적이었기에.. 데이터베이스 자체에서 제공하는 클라이언트가 없다면 데이터베이스 서버로 접근할 수가 없었습니다.. 하지만, 그러다보니 서로 다른 데이터베이스간에 데이터를 공유하기에 어려움이 있었지요.. 해서, 이러한 폐쇄적인 것들을 개방적으로 오픈할 방법을 생각해 냈는데 그게 바로 ODBC 랍니다. Open Database Connectivity 라는 ODBC를 말이죠....

해서 우리는 웹쪽의 ASP나 Win32 어플리케이션들에서 특정 데이터베이스를 접근하기 위해서.. 그 연결통로라 볼 수 있는 ODBC 를 잡아야 했던 것입니다요... 그리고나면, 우리는 소스중에서 그 연결문자인 DSN 을 이용해서 해당 데이터베이스로 접근이 가능하게 되거든요.... ^^ 그래서 이전 강좌에서 열심히 ODBC를 잡았던 것입니다. ASP 에서 데이터베이스와 연동하기 위해서도 역시나 ODBC 의 연결이 필요하니까요

하지만, 그사이 세상은 놀랄만큼 바뀌고, 발전했지요. 그러니, 그 사이에 ODBC 를 능가할만한 것이 또한 등장할만도 하다는 느낌이 사정없이 들죠? 그렇습니다. 마이크로소프트는 그 사이에 이 방법을 구체하시켜서 ODBC 보다 뛰어난 성능을 가진 OLE DB 라는 것을 등장시켰습니다. 오옷... 대단한 MS (아부성은 아닙니다.)

그리고, MS는 ASP나 Win32 에서 ODBC나 OLEDB와 같은 연결통로를 통해서 데이터를 넣고, 조회하는 등의 작업을 하기 위해서 데이터를 핸들링 할 수 있는 기술을 또한 발전시켜 왔는데.. 그것은 바로 ADO 라는 것입니다. 이미 게시판을 어느정도 만들어 보신 분은 이미 만나보셨겠지만  ADODB.Connection, ADODB.RecordSet, ADODB.Command 등이 그것이랍니다.

다시 설명드리자면.. OLE DB는 RDBMS 에 접근할 수 있는 통로를 제공하는 역할을 담당하는 기술이구요..
(게다가, OLE DB 는 RDBMS 외에 비 관계형 데이터들에게도 접근이 가능합니다.)
ADO는 사실상의 데이터를 처리하는 역할을 하는 담당하는 기술입니다. OLE DB. 이름은 어디선가 자주 들어본 것... 좀 더 알아봅시다.진정코 OLEDB 그것은과연 무엇일까요? 이것은 마이크로소프트의 UDA라는 전략을 구현하는 기술중의 하나입니다...

어라? 그럼 또 UDA는 뭐야? 뭐가 이리 복잡해... -.- 라고 하실만도 합니다.  저도 그랬으니까요.. 하지만, 알고보면 무지 간단한 전략입니다. (단순하게 생각하면요) 하지만, 실제 이 전략에 의해 구현되는 기능들은 가히 몸서리쳐질만 하지요.. (물론, 못 느끼시는 분도 있을 수 있고, "그게 뭐...대단해?" 하시는 분도 있을 수 있습니다)
그렇다면, 알아봅시다. UDA 라는 것.. 그리고 그를 이루는 근간이 되는 OLE DB를 말이죠

UDA 란? UDA는 Universal Data Access를 나타내는 말입니다.

이것은 광범위한 데이터들을 접근할 수 있도록 하는 마이크로소프트의 기술로 UDA 전략이라고도 표현하죠. UDA라는 말은 일종의 개념적이며, 기술 전략적인 이름일 뿐이고, 실제로 이를 구현하는 것은 ADO와 OLE DB 입니다.뒤집어 이야기하면, ADO와 OLE DB를 사용하여 광범위하게 위치한 데이터들을 처리하게 하는 기술을 UDA라고 표현할 수 있을 것입니다.

그렇다?? 그렇다면 OLEDB는 무엇일까요?

여러분들도 어디선가 들어는 본 듯한 말일 것이기는 합니다. 하지만, 여러분들은 OLEDB 라는 단어보다는 아마도 ODBC에 더욱 친숙함을 느끼고 있을 겁니다. 지금까지 대부분의 프로젝트를 ODBC를 통해서 구현해 왔을터이니 말이져. 

그렇다면, 여러분이 프로젝트에서 사용한 ODBC의 역할은 무엇이었을까요?

다시금 이야기하자면 이기종의 데이터베이스를 접근할 수 있게 해주는 표준적인 방법으로 였을 겁니다. 거의 모든 관계형 데이터베이스를 접근할 수 있게 해 주는 것이 ODBC였으니 말이죠. 저의 경우도 인포믹스와 오라클에 대해서 ODBC를 이용하여 프로젝트를 수행해 본 경험이 있습니다. 인포믹스 때는 ODBC 가 안 잡혀서 죽는줄 알았습니다. .. 우찌우찌 성공하기는 했지만요... -.-  어쨋든 ODBC는 실로 멋진 기술임에 틀림없슴다.

그러나, OLEDB의 화려한 등장으로 인해 ODBC의 세상은 조금 흔들리고 있습니다. OLE DB는 ODBC보다 한층 이상을 뛰어넘는 모습을 보여주고 있으니 말입니다. 

놀라지나 마세요.... OLEDB는 말입니다.  이 녀석을 사용하면 말이죠. 그게 말입니다.... 두 - - 둥.....

이기종의 관계형 데이터베이스뿐 아니라, 비 관계형 데이터들에게도 접근할 수 있습니다.... 즉, SQL서버나, 오라클과 같은 RDBMS 뿐 아니라.. 메일폴더, 각각의 메일자체, 디렉토리, 웹 사이트등등.. 그러한, 비 관계형인 계층 구조적인 데이터들에게도 접근할 수 있게 한다는 것이지요.... 저의 경우 OLE DB란 단어를 처음 만난 것은 3~4년전 이었던 것으로 기억되는데요...  사실 그 때도 OLEDB를 통해서 관계형 데이터베이스 이외의 데이터들에게까지 접근할 수 있다는 이야기는 들었었지만, 어떻게 그것이 가능한지에 대해서는 그다지 많은 정보를 얻을 수 없었었던 기억이 있슴다.  하지만, 이제 ADO 2.5에 들어서며 이를 가능하게 하는 편리한 방법들이 등장하였다는 것이죠. 놀라시지 않나요? 전 무지하게 놀랬는데... 흠...

그렇다면, 놀래고 싶은 분들은 조금 놀래보시구요...
(진짜로 안 놀래다니.. 흠.. 일부러라도 놀라는 척 해주지..... -.-)
어쨋든 우리는 이제 OLE DB를 통해서데이터베이스외의 자료들에 대한 접근도 가능하게 된다는 것은  기억해 두시기 바랍니다. 물론, 앞으로도 대부분의 경우는 데이터베이스로의 접근을 위해 사용되겠지만, 기회는 열려져 있다는 것이죠. (익스체인지 서버관련 솔루션을 개발할 때는 100% 필수입니다. 이거..)

사실, 현재 2001년에 태오에게 주어진 임무가 바로 그러한 작업인데요.... Exchange 2000 Server 를 이용해서 웹 메일 시스템과 그룹웨어, 전자결재, KMS 를 구현하는 작업입니다. 그러다보니 데이터베이스가 아닌 메일 시스템에 접근할 방법이 필요하구요.. 저는 이를 OLEDB와 ADO2.5를 통해서 가능하게 하고 있답니다... ^^ 물론, MSDN을 참고해서요

자..... 다음의 그림은 UDA 아키텍쳐(Architecture) 입니다.

그림에서 볼 수 있는 것처럼 UDA 기술은 ADO와 OLE DB를 사용하여 SQL 데이터뿐 아니라 비 SQL적인 데이터들(메일, 텍스트, 디렉토리서비스등)에도 접근을 가능하게 하구요. 데이터를 처리할 수 있게 합니다. 또한, OLE DB를 통해서 기존의 ODBC를 통한 데이터의 연결도 이용할 수 있게 되어 있답니다. 이처럼 OLE DB를 통한 접근은 기존의 ODBC가 부족했던 점을 완전히 메꾸고 있구요... ODBC 때에 비해서 접근 속도도 많은 향상을 가져왔습니다. ..

그렇다고, 이 OLEDB 기술이 ODBC를 없애버리고 세상을 바꾸자는 의도를 가지고 있는 것은 아닙니다. 기존의 기술을 더욱 발전시키자는 데에 목적을 두고 있는 것이 OLEDB 기술인 것이랍니다. 유식하게 말하면, 온고지신(溫故知新)의 개념인 것이져.. 온고지신... 태오 한문도 쫌 함다...

이제 여러분은 OLE DB 라는 것을 사용하면 뭔가 상당한 이익이 있을 것이라는 막연한 기대를 가지게 되었을 것입니다. 하지만, 그것은 막연한 기대로 끝나지만은 않을 겁니다... 실제로 상당한 성능의 향상을 가져다 주니까요... 그렇다면, OLE DB 라는 것은 어떻게 사용할 수 있을까를 여러분이 이제 충분히 궁금해 하실 시간이 되었네요..

ODBC 를 잡은 것을 여러분이 ASP 코드에서 사용하기 위해선, 이미 해보신 분들은 알겠지만.. 다음과 같은 코드를 통해서 가능합니다... ADO의 Connection 개체를 통해서 말이지요.

adoCn.Open "DSN=MyDB" 'Access일 경우
(혹은adoCn.Open"DSN=MySQLDB;uid=xx;pwd=xx" 'SQL 서버일 경우 )

str = "Provider=SQLOLEDB;Data Source=(local);Initial Catalog=pubs;user ID=xx;password=xx;"
adoCn.Open strConnect

중요한 부분은 소스중에서 커넥션 객체의 Open 메소드에 사용하는 연결문자열인데요..  소스중에 Provider=SQLOLEDB;Data Source=(local);Initial Catalog=pubs;user ID=xx;password=xx; 라고  되어져 있는부분이 그것입니다.

즉, OLE DB를 사용하기 위해서는 이 연결문자열만 잘 구성하면 그것으로 OK 라는 이야기가 되지요. 그렇다면, 이제 여러분이 외워야 할것은 이 연결 문자열임을 알 수 있습니다.  그렇다면, 이 연결문자열이 의미하는 것을 이제조목 조목 알아봅시다...  문자열 내에서 각각의 정보는 세미콜론인 ; 로써 구분이 되는데요...

첫번째 정보는 프로바이더 정보입니다.

Provider가 바로 그것이지요....  만일, SQL 서버를 사용한다면 SQLOLEDB 라는 문자열을 사용해야지만 SQL 서버용 OLEDB를 이용할 수 있게됩니다.  만일, ORACLE를 사용하려 한다면 MSDAORA 라는 OLEDB 프로바이더를 지정해야 하지요... ^^  이러한 각각의 OLE DB 프로바이더 이름이나, OLE DB 프로바이더는 각각의 데이터베이스 업체에서 제공합니다.  이것은 MS 에서 제공하는 것이 아닙니다. 즉, 여러분의 회사가 Informix 를 사용하고 있는데...  OLE DB 를 사용하고 싶어졌다면 인포믹스 측에 연락해서 OLE DB 용 프로바이더를 제공해 달라고 부탁하시면 됩니다. 
현재즈음이면 대부분의 데이터베이스 업체가 OLE DB 공급자를 제공해 주고 있을 겁니다. 아마도..말이죠. 그리고, 그것을 받아서 서버에 설치하시면 해당 데이터베이스 서버용 OLE DB를 사용할 수가 있게 되는 것이지요. 기본적으로 Windows 2000 에서 제공하는 것은 MS의 제품관련 OLE DB 들이라는 것을 기억하세요... ^^ 
여기서는 SQL 서버에 접속하려 하기에 Provider=SQLOLEDB 라는 것을 지정하였던 것이죠...  중요... 이 문자열은 다닥다닥 붙여쓰셔야 합니다. ^^

두번째 정보는 Data Source 입니다.

물론, 정보를 지정하는데에 특별한 순서가 있는 것은 아닙니다만... 일반적으로 이런 순서로 지정합니다. 기분 나쁘시다면 순서는 여러분 맘대로 하셔도 돼요... ^^  Data Source=(local) 이것은 사용하고자 하는데이터베이스 서버가 설치된 서버의 이름을 지정하는 것입니다. (local)이라고 지정하면 현재의 자신의 서버에 데이터베이스 서버가 설치되어져 있을 경우에 가능하구요...  네트웍의 다른 서버에 데이터베이스 서버가 있을 경우는...  그 서버의 서버이름을 기입해 주시면 됩니다. 예를 들어 네트웍 상의 Sony 라는 서버에 데이터베이스 서버가 있다면  이 부분을 Data Source=Sony 라고 주시면 된 답니다. 어렵지 않죠?

세번째 정보는 사용할 데이터베이스 정보입니다.

데이터베이스 서버안에 존재하는... 여러 데이터베이스중에 어떤 데이터베이스를 사용할 것인지 정하는 것이지요.... 하지만, 인자이름이 조금은 외우기 부담스러운...  Initial Catalog 이네요.. 어쨋든 외워야 합니다...  해서 소스에서는 Initial Catalog=pubs 라고 하였습니다. SQL 서버에서 기본적으로 제공되는 Pubs 데이터베이스를 사용하겠다고 지정한 것이죠...

네번째, 다섯번째의 인자는 User ID와 password 입니다. 이것은 SQL 서버의 해당 데이터베이스로 접근할 수 있는 계정 아이디와 비밀번호를 적어주면 됩니다...  중요한 것은 위의 문자열들은 띄워쓰기를 꼭 지켜주어야 한다는 것입니다. User ID에서 User 라는 단어와 ID라는 단어사이에는 꼭 한칸을 띄워주어야 합니다.  
Initial Catalog 도 마찬가지 이구요. 대, 소문자는 구분하지 않아도 에러가 안 나지만...  띄워쓰기는 반드시 지켜주어야 합니다. ^^ 반드시, 꼭, 기필코, 여하튼, 결사코, 겁나게. 

어렵지 않죠??? 그럼 지금부터 30초 드리겠습니다. 이 문자열을 외우시기 바랍니다.... 
어어... 스크롤바 내리지 말고 위로 올려서 어서 외우세요.. 어~~ 외우라니깐요...

흠....

외우기가 어렵다구요..??? 조금은 그럴 수 있죠. 하지만, 외우셔야 합니다. 
하지만, 아무리 외워도 또 시간이 지나면 까먹죠... 그렇기에 쉽게 이 OLE DB 연결문자열을 만들 수 있는 방법을 알려드리겠습니다. 이 방법은 꼭 외워두세요...

1. 먼저 바탕화면에 새로운 텍스트 파일을 하나 만듭니다. 그리고, 그 파일의 이름을 바꾸시는데 그 이름을  
    OLEDB.UDL 이라고 지정합니다. 파일 이름은 뭐라해도 상관없지만 확장자는 반드시 UDL이어야 합니다. 
    그러면 다음 그림과 같이 아이콘이 바뀔 것입니다.

2. 그 아이콘에 마우스 우측 클릭해서 등록정보로 갑니다. 그러면 아래 그림처럼 Provider이라는 탭이 나올텐데, 그 탭으로 가면 현재 여러분의 시스템에서 지원되는 모든 OLE DB 공급자들이 나올겁니다. 우리는 여기서 SQL Server 을 사용할 것이기에 아래의 그림처럼 그것을 선택하시구요.  다음 탭인 Connection 탭으로 이동하세요 (혹은 Next >> 버튼을 누르세요)

3. Connection 탭으로 이동하시면 다음과 같은 화면이 나올 것입니다. 그림에도 표시해 두었지만 먼저 1번 칸에
    는 접근할 데이터베이스 서버의 이름을 기입해 주세요. 만일, 로컬 서버에 데이터베이스 서버가 설치되어져 
    있다면 (local)이라고 하셔도 됩니다. 2 번 칸에는 해당 DB 서버로 접근할 수 있는 계정 아이디와 비밀번호를 
    기입하시면 됩니다.

위와 같이 설정하시고 나면 3번의 "Select the database on the Server" 의 콤보박스를 클릭할 경우 여러분이 기입한 내용을 기반으로 해당 데이터베이스 서버에 지정한 계정 아이디와 비밀번호로 접근을 자동으로시도합니다... 만일, 위의 그림에서 지정한 부분중 틀린 부분이 있다면 다음과 같은 에러가 날 수도 있습니다.

이 에러화면은 계정의 아이디가 없거나, 비밀번호가 일치하지 않을 경우 입니다. 이런 경우는 계정을확인하시면 됩니다. ^^  만일, 모든 것이 잘 맞아 떨어졌다면 다음 그림처럼 위의 윈도우는 현재 DB 서버가 가지고 있는 데이터베이스들이 나온답니다.

4. 이렇게 디비들이 마구 나온다면... 접근이 제대로 된 것입니다. ^^ 성공축하....추카추카

그러면, 우리가 사용할 MyDataBase 를 선택하고 바로 밑의 버튼인 Test Connection 을 꼭 누르세요. 
그럼 현재까지 지정한 것들을 가지고 다시금, 완전히, 실제로 OLE DB 접근 테스트를 합니다.
그리고, 성공하면 다음과 같은 메시지가 나오지요. 꼭 이거 나와야 합니다.

오홋홋... 마치 ODBC 잡을때와 비슷한 절차를 거치고 있네요.. ^^ 하지만, 이 작업은 반드시 해야하는 작업이 아닙니다.. OLE DB 연결 문자열을 도저히 외울수 없는 분들에게 유용한 방법이지요....

이렇게 세팅을 끝내고 난 다음에는 뭘 어떻게 하느냐?

5. 이제 세팅이 끝난 뒤, 바탕화면에 존재하는 OLEDB.UDL 을 "메모장"으로 로딩을 합니다. 
    그림과 같이 말이지요.. ^^

그러면, 메모장에는 다음과 같이 OLEDB 연결 문자열이 만들어져 있는 것을 볼 수 있을 것입니다.

비밀번호는 제가 일부러 *** 처리했음을 양해바랍니다.... ^^  또한, Persist Security Info=False; 라는 부분은 우리에게 필요없는 부분이기에.. 그림에서는 그 부분을 지우고 보여드림도 양해바랍니다. 원래의 결과에서는 Persist Security Info=False; 라는 부분이 있을 겁니다. 하지만, 우리에게는 그것이 필요없으니 지우셔도 무방합니다. 있어도 무방하구요..  ^^

고로, OLE DB 연결문자열을 외우시기 싫거나, 자체 CPU가 딸려서 잘 외워지지 않는 분들은... 이러한 방법으로 언제나 연결 문자열을 만들어 내면 되는 것입니다.... ^^ 어때요? 쉽죠??

OLE DB를 통해서 데이터베이스를 접근하는 방법을 이제 장려해야 하겠다는 생각이 들으셨을 것이라 생각하구요.. OLE DB를 사용하기 위해서는 연결 문자열만을 외우면 된다는 것도아셨을 겁니다.

그리고, 윈도우 2000에서는 ODBC 보다는 OLE DB를 사용하는 것이... 훨씬 낫다는 것을 기억하세요... 여러가지 장점이 있으니까요... ^^ 그중에 하나는 ODBC의 경우 ASP에서 여러 개의 데이터베이스를 접근하기 위해선, 각각의 데이터베이스를 모두 ODBC잡아야 하는 반면, OLE DB 연결 문자열을 사용하면... 그러한 것이 하나도 없이 ASP 내부에서 여러 데이터베이스로 자유자재로 접근이 가능하게 됩니다. ^^

자... 이것으로 OLE DB 에 대한 이야기도 어느정도 이야기가 되었네요.. 더욱 궁금하신 것은 2001년 4월 초에 출시되는(된) 태오의 심혈의 대작... 두~~둥 

"taeyo's Advanced ASP to be professional"을 참고하세요

^^ 조금은 더 깊은 이야기가 있습니다. (과연 속아줄것인가?....)  그럼.. 이제 이러한 지식을 기반으로...  다음 강좌에서부터는 ASP에서 OLE DB를 이용해서 게시판을 만들어나가기 시작하겠습니다. 글 올리기를 시작으로 해서 말이지요... ^^  기대가 사정없이 되지요.. 크핫핫.... ...

그럼 다음 강좌에서..... 다시... 10000 나요~!

PS :Ms Access를 OLE DB로 연결하고 싶다면 Microsoft.Jet.OLEDB.4.0을 사용하심 됩니다. 해서, Ms Access 경우때의 연결문자열은 다음과 같이 만들어 사용하고는 합니다.

"Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\temp\Nwide.mdb"

여기서의 Data Source 는 데이터베이스 파일의 경로를 적어주시면 됩니다. 반드시 물리적인 경로를요

출처 : http://www.taeyo.net/Columns/View.aspx?SEQ=224&PSEQ=15&IDX=3

CRM(고객관계관리)·ERP(전사자원관리) 등을 포함하는 기업용 애플리케이션 분야에서 세계 3대 메이저 중 하나로 꼽히는 피플소프트의 한국 시장 진출이 초읽기에 들어갔다. <관련기사 본지 1월 27일 1면 참조>

　특히 피플소프트는 오라클· SAP 등과 같은 경쟁 기업들에 비해 뒤늦게 한국 시장에 진출했다는 점을 감안해 다국적 컴퓨팅 기업의 한국지사는 물론 국내 솔루션 업체를 파트너사로 확보해 시장 진입 초기부터 영업력을 발휘한다는 전략을 세우고 있어 주목된다.

　피플소프트는 오는 7월 한국 지사 가동을 목표로 초대 지사 대표에 이광재씨를 임명한 것으로 확인됐다. 이광재 피플소프트코리아(가칭) 대표는 현재 법인(지사) 설립을 위한 작업을 추진하고 있으며 국내 파트너 업체 선정과 관련해 본사와 커뮤니케이션 창구를 맡고 있는 것으로 알려져 있다.

　이광재 대표는 “기존에 JD에드워즈 사업을 해온 윌러스(대표 박병수) 외에도 본사 차원에서 업무 협력을 논의하고 있는 다국적 컴퓨팅 기업 U사 등 1∼2개 다국적 IT 기업의 한국 지사와 국내 대형 SI 업체 등을 대상으로 파트너 선정을 검토하고 있다. 늦어도 여름께 모든 준비를 끝내고 지사 활동을 본격 개시할 수 있도록 일정을 세워놓고 있다”고 밝혔다. 다만 “한국지사의 직접 영업을 위주로 할지 아니면 채널을 통한 간접판매를 택할 지는 아직 결정되지 않았다”고 덧붙였다.

　지금까지 국내에서 피플소프트에 대한 인지도는 인사·회계 관리 등 HRM(인사자원관리) 분야로 국한됐으나 세계 시장에서는 대학·공공 분야의 CRM 및 ERP 영역에서 오라클이나 SAP와 경쟁하는 글로벌 기업으로 꼽힌다. 특히 피플소프트는 지난해 9월 SMB 시장에서 영향력이 높은 ERP 업체 JD에드워즈를 인수하며 세계적인 엔터프라이즈 솔루션 기업으로 급부상해 주목받고 있다.

　업계에서는 비록 피플소프트의 한국 시장 진출이 경쟁사보다 한참 늦었지만 본사 차원에서 인수한 JD에드워즈의 ERP 솔루션을 사용하고 있는 국내 고객사가 적지 않다는 점에서 지사 설립 초기에도 적지 않은 영업력을 과시할 것으로 주목하고 있다. 현재 JD에드워드의 ERP 솔루션을 사용하고 있는 고객사는 두산 계열의 20여개사, 조선내화, 삼양사, 녹십자백사, 라파즈석고, 라파즈한라시멘트, 동방전자 등 60여개사 정도이다. 최근 두산에서 빌트원으로 대주주가 바뀐 윌러스가 영업 및 서비스를 맡고 있다.

　피플소프트는 CRM, ERP,HCM, SCM 엔터프라이즈 4대 솔루션을 보유하고 있으며 지사 출범 이후에는 JD에드워즈의 ‘피플 엔터프라이즈 원’, ‘피플 엔터프라이즈 월드’ 등의 솔루션과 통합한 제품으로 영업을 전개할 것으로 알려져 있다.

한국피자헛
사용자 편의성과 유연성 갖춘
Oracle JD Edwards EnterpriseOne 도입하여 독보적인 피자브랜드 입지 강화

■ (주)한국피자헛 Seoul, Korea

■ 산업 l 식음료 서비스
- 매장수 : 약 330 여 개

■ 오라클 제품 및 서비스
- Oracle JD Edwards EnterpriseOne
- Oracle Database 10g

■ 주요 도입 효과
- 엑셀로 관리한 데이터를 쉽게 입력할 수 있는 등 사용자 편의성 강화
- 뛰어난 유연성으로 EDI를 통해 3rd Party 시스템과 연계가 쉬움
- 결산일이 7일 이상 에서 1.5일로 줄어드는 등 경영관리업무 혁신
- 구현이 쉬우며 관리가 편리함
- 저렴한 비용

“한국피자헛은 지난 1993년부터 사용하던 Oracle JD Edwards World를 Oracle JD Edwards EnterpriseOne으로 업그레이드하여 업무효율성을 향상시켰다. Oracle JD Edwards EnterpriseOne은 관리나 구현이 쉽고 사용자 편의성과 유연성 뿐만 아니라 비용이 저렴해 중견.중소기업을 위한 최적의 솔루션이라고 할 수 있다.”

길재민 부장 _한국피자헛 정보지원센터 전산팀

22년간 독보적인 피자브랜드로 자리매김

(주)한국피자헛은 1997년 펩시 그룹에서 독립한 얌 브랜드(YUM Brands, INC.)의 한국 지사로, 1985년 이태원 1호점을 오픈하며 한국에 피자를 본격적 으로 소개한 이후 꾸준하게 업계 1위를 지키고 있다. 한국피자헛은 전국에 약 330여 개의 매장을 운영하고 있으며, 2004년 말에는 46%라는 시장 점유율을 기록하는 등 독보적인 위치에 있다.또 한국인이 좋아하는 다양한 피자를 출시해 경쟁 력을 확고히 하며 동시에 개발 메뉴를 전세계로 전파해 타 국가 피자헛에서 한국을 벤치마킹하고 있다.특히 한국피자헛은 전세계 80여 개국 중 에 미국, 영국에 이어 세 번째로 좋은 실적을 달성하며 지속적인 성장을 이뤄가고 있다.

Oracle JD Edwards EnterpriseOne으로 업그레이드

한국피자헛은 지난 2003년에 Oracle JD Edwards EnterpriseOne으로 업그레이드 하였다. 기존 시스템에서는 나라별로 서버를 따로 두고 운영 하였으나, Oracle JD Edwards EnterpriseOne으로 업그레이드 한 후에 시스템 서버는 각 로컬에 두지만 미국 본사에서 통합 관리를 하고 있으며 재무와 구매, Inventory 등의 업무를 효율적으로 처리하고 있다.

사용자 편의성 갖춘 재무분야 최고 솔루션

Oracle JD Edwards EnterpriseOne의 가장 큰 장점은 사용자 편의성이다. 기존 Oracle JD Edwards World는 외부 시스템과 연결 시 따로 프로그래밍 하는 등 불편한 점이 있었으나, 새로 도입한 Oracle JD Edwards EnterpriseOne은 재무 담당자가 엑셀로 관리한 데이터를 쉽게 시스템에 입력할 수 있으며, 하위 시스템과 연결이 따로 필요 없어 업무 효율성이 향상되었다. 또, 트랜잭션 타입별, document 타입별 로 각각 다른 회계계정코드와 자유자재로 연계(mapping)이 가능하여 실무자가 사용하기 편해졌다. 또다른 Oracle JD Edwards EnterpriseOne의 장점은 유연성이다. 기존에 Oracle JD Edwards World 를 사용할 때에는 Inventory나 구매 모듈에 연계하기 위해 협력사(third party)도 반드시 Oracle JD Edwards World를 사용해야기 때문에, 어려움이 많았으며 데이터와 시스템 오류가 빈번했으나 Oracle JD Edwards EnterpriseOne으로 업그레이드한 후, 협력사에서는 각기 사용하기 쉬운 시스템을 사용하고 이를 EDI(Electronic Data Interchange)를 통해 Oracle JD Edwards EnterpriseOne과 연결하여 사용과 관리가 쉬워지고 데이터 정합성과 신뢰성이 확보되었다. 이처럼 Oracle JD Edwards EnterpriseOne은 뛰어난 유연성을 갖추고 있어 다른 시스템과 연계가 쉬운 것이 가장 큰 장점이며, 이는 중견.중소기업에 꼭 필요한 요소라고 할 수 있다.

중견.중소기업을 위한 최적의 솔루션, Oracle JD Edwards EnterpriseOne

중견.중소규모 기업의 IT 환경은 대기업과 달리 쉽게 구현할 수 있어야 하며, 사용과 관리가 용이해야 한다. Oracle JD Edwards EnterpriseOne은 이러한 요구사항에 맞는 솔루션으로, 가볍고 사용하기 쉬우며, 비용도 저렴하다. 한국피자헛은 이번에 시스템을 업그레이드 하면서 하위 시스템과 독립적으로 운영이 가능하며, 여러 시스템과 연계가 쉬워 유연성이 뛰어난 Oracle JD Edwards EnterpriseOne의 장점을 십분 활용하고 있다.

출처 : 한국 IBM

1. 클라이언트 NLS_LANG

   많은 오라클 엔지니어들이 아직도 이경우 제대로 정리되지 않은 부분입니다.

   결론부터 말하면 DB의 CHAR SET이  UTF8이라고 하더라도

   클라이언트 LOCALE은 KSC5601 혹은 WIN949이어야 합니다.

   문서도 있는데 링크는 기억나지 않고^^;

   UTF8이 서버 로케일일 경우이건 뭐건, 클라이언트 로케일은 해당 국가 로케일이 되어야 합니다.

   간략한 테스트는

   LENGTHB와 CONVERT 함수를 이용해서 테스트를 해보면 됩니다.

   DB가 UTF8일 경우

   클라이언트 LOCALE이 UTF8로 올릴 경우 한글이 2바이트로 됩니다.

   CONVERT로 바꿀 때 SOURCE를 KOC5601로 처리해야 됩니다. (하지만 DUMP를 떠보면 다르게 나옵니다)

   DB가 UTF8이라고 클라이언트 로케일을 UTF8로 바꿀 경우 치러야 할 대가가 만만치 않습니다.

   특히 EXPORT,IMPORT할 때 NLS_LANG을 잘못한 경우...--;

2. CHAR TYPE 문제

   하나의 칼럼이 CHAR TYPE인데 이를 UTF8로 바꾼다면?

   해당 데이터가 오로지 영숫자만 있다면 상관없겠으나

   한글도 들어간 칼럼이라면?

   DATA TYPE 변경 없이 일괄적으로 칼럼의 LENGTH를 늘리면

   스페이스가 들어가는 경우가 발생합니다.

   즉, CONVERSION이 잘못된 경우이죠.

   이때는 먼저 SOURCE에서 CHAR -> VARCHAR2로 변경한 뒤에 작업하셔야 합니다.

   일반적으로 특수한 경우(좀있다 얘기하겠습니다)를 제외하고 이렇게 변경한 뒤에

   어플리케이션 영향도는 없다고 보셔도 됩니다.

   그리고 변경하는데 생기는 부하는 거의 없습니다. 단, 피크시간대는 절대 피하셔야죠

   LIBRARY CACHE 쪽에서 해당 테이블을 참조하는 오브젝트가 모두 재컴파일 됩니다.

3. VARCHAR2(4000)칼럼의 문제

   LOB나 LONG을 사용하지 않고 VARCHAR2로 칼럼을 정의하고 게시판 본문이나

   각종 텍스트를 처리하는 테이블이 있습니다.

   이 경우 UTF8로 넘어갈 때 BYTE가 늘어나 해당 레코드를 처리할 때 에러가 납니다.

   EXP를 사용할 경우 그냥 에러로그에 남으니까 그나마 낳습니다.

   DB LINK로 땡길 경우 전체 트랜잭션이 에러나면 많이 힘들게 되죠.

   그리고 실질적으로 VARCHAR2(4000)을 넘기 때문에 데이터가 잘리는 문제가 생깁니다.

   이를 해결하려면 LOB로 바꿔야 하는데 이경우 어플리케이션 테스트를 제대로 못하면 문제가 커집니다.

   JAVA같은 경우 TYPE문제가 걸리죠

   이경우 최선의 방법은 없습니다.

   저같은 경우 어플리케이션 담당자를 설득해서 해당 칼럼 데이터의 나머지를 버렸습니다.

   물론 당근으로는... LOB로 바꿀 경우 어플리케이션을 바꿔야 한다는 것. 하지만 일부 데이터의 OVER LENGTH부분을

   버리면 아무것도 손댈 필요가 없다는 것...

   아무튼, 이부분은 DBA가 단독으로 결정하면 안됩니다.

4. UTL_FILE을 이용한 FILE CONTROL 문제

   이건 상당히 골치 아픈 문제입니다.

   대상 DB와 어플리케이션이 UTL_FILE을 사용해서 데이터를 읽거나 쓰지 않는다면  여러분은 일단 복받으신 겁니다.

   일반적으로 소켓으로 주고받는 데이터(뭐 금융권 전문이나 애니링크같은)는 구분자가 아니라 자리수로 구분합니다.

   FILE에서는 한글2바이트,영문1바이트이기 때문에 그걸로 미리 자리수가 정해져 있죠.

   이를 UTL_FILE이나 LOADER로 올려서 SUBSTRB로 잘라서 쓰는 경우가 있습니다.

   그런데 디비에서 처리하면 한글3바이트,영문1바이트입니다. 즉, 정해진 자리수로 자를 수 없습니다.

   당연히 배치에서 데이터가 잘못 처리됩니다.

   이럴 때 첫번째로 생각하는 방법은 CONVERT로 KSC5601로 바꿔서 기존 데이터 처리 방식으로 처리하면 됩니다.

   하지만 이런 경우에도 글자는 깨집니다. 왜냐하면 SUBSTRB(SUBSTR 포함)는 해당 로케일을 따라가기 때문에

   CONVERT로 바꾼다고 해도 보장을 못합니다.

   이를 해결할려면 UTL_RAW 팩키지를 사용해야 합니다.

   특히, 잘라서 올리는 것만이 아니라 자리수에 맞춰서 UTL_FILE로 WRITE 할 경우 CONVERT를 제대로 안하면

   전문처리 등에서 대형사고를 일으킵니다.

5. PARTIAL MULTI BYTE 에러

   이는 KSC5601 -> UTF8로 DB LINK로 처리할 때 많이 생깁니다.

   원인은 KSC5601 자체 있습니다.

   UTF 코드는 자신이 파싱 못하는 문자는 받아들이지 않으나 KSC5601은 다 받아들입니다.

   즉, 파싱되지 않는 쓰레기 데이터도 해당 칼럼에 들어갑니다.(예를 들어 ¿ 같은 문자)

   그나마 눈에 보이는 문자면 다행이죠... 아예 조회시 누락되는 바이트도 있습니다.

   물론 TO_SINGLE_BYTE FUNCTION으로 대부분 해결됩니다. 그래서 가능한 이방식을 먼저 적용합니다.

   하지만 그렇게 되지 않는 경우도 발생합니다.

   이런 경우는 일일이 찾아서 해당 데이터를 고쳐야 합니다.

   제일 편한 방법은 EXPORT/IMPORT로 넣어서 ERROR LOG를 보면 됩니다.

   그런데 해당 사이트에 여러개의 DB가 있고 해당 데이터가 원천데이터가 아닌 경우는 끝까지 추적해서 그걸 잡아내지 않으면

   마이그레이션 이후에도 계속 에러납니다.

   예를 들어 UTF로 바꾼 DB는 정보계이고 계정계는 아직 KSC5601이라면 마감배치 돌릴 때마다 에러나겠죠?

6. COLUMN LENGTH의 문제

   한글은 2->3바이트, 영숫자는 1->1 바이트이므로 계산상 해당 칼럼을 1.5배로 늘려주면 아무 이상이 없어야 하는데요...

   안타깝게도 안그렇습니다. 위의 PARTITAL MULTI BYTE에러와 연관되는 문제인데... 1바이트로 처리되어야하는 문자가

   3바이트로 처리되는 경우가 발생합니다. 이것을 피하고 싶으면  TO_SINGLE_BYTE로 처리해야 합니다.

   그러나... 이경우 문제가 있습니다. 일단 처리시간이 오래걸립니다.(마이그레이션은 제한된 시간에 해야 합니다)

   그렇다고 기존 SOURCE를 전부 UPDATE처리하자니 뒷감당이 안됩니다.( 문제가 발생하는 레코드의 칼럼만

    변경하면 됩니다만 이것을 추적해서 찾을 시간이 없습니다. 물론 시간이 있다면 하시는게 베스트죠. 그러나 그럴 시간을

    확보할 수 있을까요?)

    결국 나중에는 2배로 늘리고, 다시 2.5~3배로 늘렸습니다. 시간이 부족하기 때문에 벌어진 일이죠.

    이렇게 해도 큰 문제가 없는 이유는 대부분 이런 문제를 일으키는 데이터는 조회조건에 걸리는 칼럼이 아니라

    조회결과로 걸리는 칼럼이기 때문입니다.(비즈니스 어플리케이션을 이해하신다면 수긍하실겁니다)

    이것은 편법입니다. 원칙적으로는 이런 데이터 클린징작업을 먼저 수행해야 합니다.

SQL*LOADER 사용시에 여러가지 적절한 옵션 사용과 테이블에 대한 설정값들을 변경시켜줌으로써 
많은 성능 향상을 가져올수 있다.

다음은 그 권장되는 설정법들을 설명한 것이다.

1. DIRECT PATH LOAD를 사용한다. Direct path load는 load되는 테이블이나 파티션에 exclusive access를 요구한다. 
추가적으로 트리거는 자동으로 disable되고 제약조건은 로드가 완료될때까지 defer(연기) 된다.
 

2. direct path load로 데이타를 로드시에 모든 CHECK 와 REFERENCE 무결성 제약조건은 자동으로 DISABLE된다. 
그러나 그밖의 다른 타입의 제약조건 NOT NULL, UNIQUE, PRIMARY KEY 조건들은 반드시 DISABLE 시켜준다. 
작업 완료후에 수동으로 enable시켜준다. 
 

3. 정렬된 순서로 데이타를 load한다. 미리 sorting 된 데이타는 정렬에 필요한 공간temporary 영역 사용을 최소화한다. 
SQL*LOADER 옵션에서 SORTED INDEXES 를 CONTROL파일에 기술한다.
 

4. 인덱스 MAINTANCE 를 연기(DEFERRING)하라. 인덱스는 데이타가 insert하거나 delete 또는 key 컬럼이 업데이트 
될때마다 자동으로 maintance 를 실시한다.따라서 많은 양의 데이타를 load할때 작업이 종료된 후에 maintance를 한다면 
좀더 빠를 것이다. SKIP_INDEX_MAINTENANCE = TRUE  를 설정하면 인덱스 세그먼트의 상태가 “ INDEX UNUSABLE”상태가 
되어있더라도 LOADER시작시에 인덱스 MAINTANCE를 SKIP한다. 
 

5. UNRECOVERABLE 을 사용해서 REDO 생성을 DISABLE시킨다. 모든 recover 시에는 redo log파일이 필요하다. 
그러나 redo log 생성은 부하가 많기 때문에 disable시키면 그만큼 속도는 빠르게 된다. 
그러나 LOADER 작업 중간에 FAILURE 가 발생한다면 처음부터 load작업을 다시 해야한다. 
따라서 리두로그를 생성하지 않기때문에 loader 작업 후에는 반드시 백업하도록 한다.
 

6. 단일 파티션에 loading 하도록 한다. 파티션 테이블에 데이타 load시 기타 사용자는 다른 파티션 에 접근 할 수 있다. 
APRIL 파티션을 로드시에 jan 에서 april 까지 쿼리를 실행하는 유저를 차단하지 못한다. 따라서 부하가 증가한다. 
 

7. Parallel 로 로드를 한다. 파티션으로 구성되어 있다면 parallel 로 다중 파티션을 로드할 수 있다. 
 

8. STREAMSIZE 파라미터는 SQL*LOADER client 에서 oracle server로 direct path stream buffer 의 크기(bytes)를 
지정한다. 기본값은 256000 bytes 이다.  
또한 columnarrayrows 또한 direct path column array 에 전송하는 row의 갯수를 지정한다.기본값은 5000이다.

9. 만일 load되는 데이타가 중복되는 날자값을 많이 가지고 있다면 DATE_CACHE 파라미터를 설정해서 DIRECT PATH LOAD
시에 더 나은 성능을 보장할 수 있다. CACHE에 CONVERION 되는 DATE 의 사이즈(엔트리)를 지정한다. (기본값은 1000)