FAQ

해당 현상확인 결과, CHARACTERSET – KO16MSWIN949 / NCHARACTERSET – AL16UTF16의 경우,
정상적으로 중국어 입력이 불가한 것으로 판단되었습니다.

OCI를 사용하여 직접 SQL 문장(INSERT INTO 테이블 VALUES ('값'))을 실행할 경우, 중국어 문자 입력이 정상적으로 이루어지지 않을 수 있습니다. 이는 OCI의 문자셋 처리 방식과 관련이 있습니다.

1. OCI의 문자셋 처리 방식
OCI에서는 NLS_LANG 환경 변수를 사용하여 클라이언트 문자셋을 설정합니다.
OCI에서는 문자셋을 기반으로 문자열을 해석하는데, SQL 문장 내부의 문자열 리터럴('중국어문자')이 클라이언트 문자셋으로 변환된 후 서버로 전달됩니다.
서버에서 NLS_CHARACTERSET에 따라 해당 문자열을 다시 변환하여 저장하는 과정에서,
클라이언트 문자셋과 서버 문자셋이 일치하지 않으면 문자 손실이 발생할 수 있습니다.

특히, VARCHAR2 타입은 NLS_CHARACTERSET(예: KO16MSWIN949)으로 저장되므로, 중국어 입력이 제대로 저장되지 않을 가능성이 높습니다.
NVARCHAR2는 NLS_NCHAR_CHARACTERSET(예: AL16UTF16)으로 저장되지만,
SQL 문장에서 직접 N'중국어' 입력 시에도 클라이언트 문자셋과의 불일치로 인해 깨질 수 있습니다.

2. JDBC와의 차이점
JDBC에서는 oracle.jdbc.defaultNChar=true / charactersetEncoding등의 Connection Property를 통해,
NVARCHAR2 컬럼에 대한 처리를 명확하게 지정할 수 있습니다.
따라서, JDBC는 바인드 변수를 사용하지 않더라도 비교적 정상적으로 중국어를 입력할 수 있습니다.
하지만 OCI에서는 이러한 설정이 제한적이며, 직접 SQL 문장을 통한 입력 시 깨질 가능성이 높습니다.

3. 해결 방법: 바인드 변수 사용
따라서 OCI 환경에서 중국어를 올바르게 입력하려면 반드시 바인드 변수를 사용해야 합니다.
OCI는 OCIStmtBindByName 또는 OCIStmtBindByPos를 통해 명시적으로 문자열의 문자셋을 지정할 수 있으므로, 바인드 변수를 사용하면 입력이 정상적으로 처리됩니다.

Orange 에서 Insert 구문에 대해서도 중국어에 대해 직접 입력대신, Bind 변수 사용시 정상적으로 입력되는 것을 확인하실수 있습니다.

예를 들어,

SELECT A, B, C WHERE C=N'중국어';  대신

SELECT A, B, C WHERE C=:a; 입력후 :a 에 대해 '중국어' 를 입력하시면 정상적으로 사용 가능합니다.

해당 현상은 사내에서 증상 재현을 하여 시도해본 결과 아래와 같았습니다.

MySQL ODBC Driver 8.0.40  ==> 오류

MySQL ODBC Driver 8.0.32  ==> 오류

MySQL ODBC Driver 8.0.22 ==> 정상 출력

innodb status 외에 다른 메타 정보를 조회 시에도 비슷한 증상이 발생할수 있으며, 

Orange -Option > Common -> Session -> Long Size를 적절하게 조정 하였음에도 ( 기본값 80이 아닌 큰 값 ) 

값이 출력되지 않는다면 ODBC Driver의 버전 교체를 시도해 보시기 바랍니다.

Orange 에서는 Oracle의 Number(*,0)과 Number에 대한 구분을 정확하게 하지 못합니다.

Orange에서는 Oracle Client를 사용하여 접속하고 있으며,
Oracle에서 제공하는 Oracle Client Interface 의 함수 OCIAttrGet(),

ODBC나 JDBC 접속시 SQLDescribeCol() 함수를 사용하고 있으며,

이 경우 Oracle에서 Scale 과 Precision 값에 대해, 0을 기본 값으로 전달하고 있습니다.

하여, DBMS_METADATA.GET_DDL 함수를 사용한 Script와 동일하게 표현하지 않습니다.

7.0 부터는 Script를 제외한,

Column Definition 및 Schema browser의 하단 Properties 에서는 NUMBER(*,0) 등을 표기하도록 수정처리 되었으나,
Description Tool 에서도 Script 조회에서는 해당 부분이 적용되지 않고 있습니다.

그럼에도 불구하고 오렌지에서 해당 함수들을 사용하는 이유는,

SQL 실행없이 속성값을 조회하며, 그 외 리소스 절약 등 실시간으로 현재 세션의 메타데이터 조회가 가능하기 때문이며,

성능 및 리소스 최적화 측면에서 해당 함수를 사용하는 게 훨씬 효율 적인 방법이기에 채택된 것입니다.

Oracle 에서 ASH Monitor를 사용하기 위해서는 Oracle Server에서 DIAGNOSTIC PACK 사용을 활성화 하여야 하며, statistics_level 이 BASIC이 아닌 값으로 설정 되어야 합니다. 아래의 조건들을 확인하여 ASH Monitor를 사용할수 있는 상태로 서버의 설정값을 변경해주어야 합니다.

1.  아래의 SQL을 실행하여 해당 파라미터가 NONE 으로 조회되는 경우 SYS.V_$ACTIVE_SESSION_HISTORY에 데이터가 쌓이지 않음 ( ASH Monitor 사용 불가 )

SELECT name

     , value

     , display_value

     , description

  FROM v$parameter

 WHERE name like '%control_management_pack_access%'  ;

1)  NONE : DIAGNOSTIC 과 TUNING PACK 비활성화 해당 기능 사용 불가

 -> 해당 조건이 NONE 일 경우, SYS.V_$ACTIVE_SESSION_HISTORY 뷰에 데이터가 누적되지 않습니다. ( ASH Monitor 사용 불가 )

2)  DIAGNOSTIC : DIAGNOSTIC PACK 만 활성화, TUNING PACK 비활성화

3)  DIAGNOSTIC+TUNING : DIAGNOSTIC 과 TUNING PACK 모두 활성화,  AWR , ASH , SQL Tuning Advisor 등을 모두 사용가능

아래의 명령어중 하나를 사용하여 해당 기능을 활성화 해주셔야 합니다.

1-1. DIAGNOSTIC 과 TUNING PACK 을 모두 활성화 합니다.

alter system set control_management_pack_access = 'DIAGNOSTIC+TUNING' SCOPE=BOTH;

1-2.  DIAGNOSTIC PACK 을 활성화 합니다.

alter system set control_management_pack_access = 'DIAGNOSTIC' SCOPE=BOTH;

2. 아래 SQL을 실행하여 파라미터가  BASIC 으로 조회되는 경우 ( ASH Monitor 사용 불가 ) 

SELECT name

     , value

     , display_value

     , description

  FROM v$parameter

 WHERE name = 'statistics_level'  ;

1) TYPICAL: 기본값이며 ASH 데이터가 수집됩니다.

2) ALL: 더 자세한 통계 정보를 수집합니다.

3) BASIC: ASH 데이터를 비활성화하므로 설정을 변경해야 합니다. ( ASH Monitor 사용 불가 ) 

아래의 명령어중 하나를 사용하여 해당 기능을 활성화 해주셔야 합니다.

2-1. ALTER SYSTEM SET STATISTICS_LEVEL=TYPICAL;

2-2. ALTER SYSTEM SET STATISTICS_LEVEL=ALL;