728x90

Informix는 PDQ 값에 따라 가용한 스레드 수만큼 작업이 병렬로 수행됩니다.

PDQ 값은 세션에서 SET PDQPRIORITY 문장으로 설정할 수 있는데요. 프로시저가 컴파일될때 이 값이 인코딩되면서 카탈로그 테이블에 저장된다고 합니다.

Fernando 의 블로그에서 루틴의 PDQ값을 참조할 수 있는 자세한 설명을 보실 수 있습니다.

http://informix-technology.blogspot.com/2011/01/stored-procedure-pdq-pdq-dos.html

 

Stored procedure PDQ / PDQ dos procedimentos

This article is written in English and Portuguese Este artigo está escrito em Inglês e Português English version: A few years ago I needed...

informix-technology.blogspot.com

프로시저 내부 작업들이 병렬로 수행되는 것은 참 좋아보입니다만 시스템 자원을 과도하게 사용할 가능성도 생깁니다.

따라서 PDQ 값을 0또는 작은 값으로 설정하고 프로시저를 컴파일하는 것이 좋겠네요.

Informix의 각 데이터베이스 별로 sysprocplan과 sysprocedures 테이블이 존재합니다. 아래는 카탈로그 테이블들의 각 컬럼 값을 참조하여 PDQ값을 확인하는 사용자 정의 함수 코드입니다.

CREATE FUNCTION get_proc_pdq_value(v_proc_name VARCHAR(128))
RETURNING SMALLINT;
DEFINE v_ret_pdq_value SMALLINT;
SELECT
 CASE data[1,3]
     WHEN "AAA" THEN 0
     WHEN "AQA" THEN 1
     WHEN "AAE" THEN 1
     WHEN "AgA" THEN 2
     WHEN "AAI" THEN 2
     WHEN "AwA" THEN 3
     WHEN "AAM" THEN 3
     WHEN "BAA" THEN 4
     WHEN "AAQ" THEN 4
     WHEN "BQA" THEN 5
     WHEN "AAU" THEN 5
     WHEN "BgA" THEN 6
     WHEN "AAY" THEN 6
     WHEN "BwA" THEN 7
     WHEN "AAc" THEN 7
     WHEN "CAA" THEN 8
     WHEN "AAg" THEN 8
     WHEN "CQA" THEN 9
     WHEN "AAk" THEN 9
     WHEN "CgA" THEN 10
     WHEN "AAo" THEN 10
     WHEN "CwA" THEN 11
     WHEN "AAs" THEN 11
     WHEN "DAA" THEN 12
     WHEN "AAw" THEN 12
     WHEN "DQA" THEN 13
     WHEN "AA0" THEN 13
     WHEN "DgA" THEN 14
     WHEN "AA4" THEN 14
     WHEN "DwA" THEN 15
     WHEN "AA8" THEN 15
     WHEN "EAA" THEN 16
     WHEN "ABA" THEN 16
     WHEN "EQA" THEN 17
     WHEN "ABE" THEN 17
     WHEN "EgA" THEN 18
     WHEN "ABI" THEN 18
     WHEN "EwA" THEN 19
     WHEN "ABM" THEN 19
     WHEN "FAA" THEN 20
     WHEN "ABQ" THEN 20
     WHEN "FQA" THEN 21
     WHEN "ABU" THEN 21
     WHEN "FgA" THEN 22
     WHEN "ABY" THEN 22
     WHEN "FwA" THEN 23
     WHEN "ABc" THEN 23
     WHEN "GAA" THEN 24
     WHEN "ABg" THEN 24
     WHEN "GQA" THEN 25
     WHEN "ABk" THEN 25
     WHEN "GgA" THEN 26
     WHEN "ABo" THEN 26
     WHEN "GwA" THEN 27
     WHEN "ABs" THEN 27
     WHEN "HAA" THEN 28
     WHEN "ABw" THEN 28
     WHEN "HQA" THEN 29
     WHEN "AB0" THEN 29
     WHEN "HgA" THEN 30
     WHEN "AB4" THEN 30
     WHEN "HwA" THEN 31
     WHEN "AB8" THEN 31
     WHEN "IAA" THEN 32
     WHEN "ACA" THEN 32
     WHEN "IQA" THEN 33
     WHEN "ACE" THEN 33
     WHEN "IgA" THEN 34
     WHEN "ACI" THEN 34
     WHEN "IwA" THEN 35
     WHEN "ACM" THEN 35
     WHEN "JAA" THEN 36
     WHEN "ACQ" THEN 36
     WHEN "JQA" THEN 37
     WHEN "ACU" THEN 37
     WHEN "JgA" THEN 38
     WHEN "ACY" THEN 38
     WHEN "JwA" THEN 39
     WHEN "ACc" THEN 39
     WHEN "KAA" THEN 40
     WHEN "ACg" THEN 40
     WHEN "KQA" THEN 41
     WHEN "ACk" THEN 41
     WHEN "KgA" THEN 42
     WHEN "ACo" THEN 42
     WHEN "KwA" THEN 43
     WHEN "ACs" THEN 43
     WHEN "LAA" THEN 44
     WHEN "ACw" THEN 44
     WHEN "LQA" THEN 45
     WHEN "AC0" THEN 45
     WHEN "LgA" THEN 46
     WHEN "AC4" THEN 46
     WHEN "LwA" THEN 47
     WHEN "AC8" THEN 47
     WHEN "MAA" THEN 48
     WHEN "ADA" THEN 48
     WHEN "MQA" THEN 49
     WHEN "ADE" THEN 49
     WHEN "MgA" THEN 50
     WHEN "ADI" THEN 50
     WHEN "MwA" THEN 51
     WHEN "ADM" THEN 51
     WHEN "NAA" THEN 52
     WHEN "ADQ" THEN 52
     WHEN "NQA" THEN 53
     WHEN "ADU" THEN 53
     WHEN "NgA" THEN 54
     WHEN "ADY" THEN 54
     WHEN "NwA" THEN 55
     WHEN "ADc" THEN 55
     WHEN "OAA" THEN 56
     WHEN "ADg" THEN 56
     WHEN "OQA" THEN 57
     WHEN "ADk" THEN 57
     WHEN "OgA" THEN 58
     WHEN "ADo" THEN 58
     WHEN "OwA" THEN 59
     WHEN "ADs" THEN 59
     WHEN "PAA" THEN 60
     WHEN "ADw" THEN 60
     WHEN "PQA" THEN 61
     WHEN "AD0" THEN 61
     WHEN "PgA" THEN 62
     WHEN "AD4" THEN 62
     WHEN "PwA" THEN 63
     WHEN "AD8" THEN 63
     WHEN "QAA" THEN 64
     WHEN "AEA" THEN 64
     WHEN "QQA" THEN 65
     WHEN "AEE" THEN 65
     WHEN "QgA" THEN 66
     WHEN "AEI" THEN 66
     WHEN "QwA" THEN 67
     WHEN "AEM" THEN 67
     WHEN "RAA" THEN 68
     WHEN "AEQ" THEN 68
     WHEN "RQA" THEN 69
     WHEN "AEU" THEN 69
     WHEN "RgA" THEN 70
     WHEN "AEY" THEN 70
     WHEN "RwA" THEN 71
     WHEN "AEc" THEN 71
     WHEN "SAA" THEN 72
     WHEN "AEg" THEN 72
     WHEN "SQA" THEN 73
     WHEN "AEk" THEN 73
     WHEN "SgA" THEN 74
     WHEN "AEo" THEN 74
     WHEN "SwA" THEN 75
     WHEN "AEs" THEN 75
     WHEN "TAA" THEN 76
     WHEN "AEw" THEN 76
     WHEN "TQA" THEN 77
     WHEN "AE0" THEN 77
     WHEN "TgA" THEN 78
     WHEN "AE4" THEN 78
     WHEN "TwA" THEN 79
     WHEN "AE8" THEN 79
     WHEN "UAA" THEN 80
     WHEN "AFA" THEN 80
     WHEN "UQA" THEN 81
     WHEN "AFE" THEN 81
     WHEN "UgA" THEN 82
     WHEN "AFI" THEN 82
     WHEN "UwA" THEN 83
     WHEN "AFM" THEN 83
     WHEN "VAA" THEN 84
     WHEN "AFQ" THEN 84
     WHEN "VQA" THEN 85
     WHEN "AFU" THEN 85
     WHEN "VgA" THEN 86
     WHEN "AFY" THEN 86
     WHEN "VwA" THEN 87
     WHEN "AFc" THEN 87
     WHEN "WAA" THEN 88
     WHEN "AFg" THEN 88
     WHEN "WQA" THEN 89
     WHEN "AFk" THEN 89
     WHEN "WgA" THEN 90
     WHEN "AFo" THEN 90
     WHEN "WwA" THEN 91
     WHEN "AFs" THEN 91
     WHEN "XAA" THEN 92
     WHEN "AFw" THEN 92
     WHEN "XQA" THEN 93
     WHEN "AF0" THEN 93
     WHEN "XgA" THEN 94
     WHEN "AF4" THEN 94
     WHEN "XwA" THEN 95
     WHEN "AF8" THEN 95
     WHEN "YAA" THEN 96
     WHEN "AGA" THEN 96
     WHEN "YQA" THEN 97
     WHEN "AGE" THEN 97
     WHEN "YgA" THEN 98
     WHEN "AGI" THEN 98
     WHEN "YwA" THEN 99
     WHEN "AGM" THEN 99
     WHEN "ZAA" THEN 100
     WHEN "AGQ" THEN 100
 ELSE
     -1
 END pdq_value
INTO
 v_ret_pdq_value
FROM
 sysprocplan p, sysprocedures f
WHERE
 p.planid = -2 AND
 f.procid = p.procid AND
 f.procname = v_proc_name;
IF v_ret_pdq_value = -1
THEN
 RAISE EXCEPTION -746,0,'Could not decode PDQ value. Please check query';
ELSE
 RETURN v_ret_pdq_value;
END IF
END FUNCTION;

과연 일반 사용자들은 짐작조차 할 수 없겠군요. 어쨌든 이 함수를 사용해 각 함수나 프로시저의 PDQ값을 참조하여 재컴파일 등을 고려해볼 필요도 있겠습니다.

제가 프로시저를 재컴파일한 테스트 결과를 공유드립니다.

$ dbaccess testdb -
Database selected.
> select get_proc_pdq_value('temp_test') from systables where tabid = 1;
(expression)
          80
1 row(s) retrieved.
> set pdqpriority 100;
PDQ Priority set.
> update statistics for routine;
Routine Statistics updated.
> select get_proc_pdq_value('temp_test') from systables where tabid = 1;
(expression)
         100
1 row(s) retrieved.
> set pdqpriority 0;
PDQ Priority set.
> update statistics for routine;
Routine Statistics updated.
> select get_proc_pdq_value('temp_test') from systables where tabid = 1;
(expression)
           0
1 row(s) retrieved.
728x90
728x90

index page 최대 개수에 대해 조사하다보니 extent 할당에 대해서도 우연히 문서를 읽게 되었습니다.

IBM Knowledge Center에 따르면 11.70.xC1 버전부터 partition header pages의 공간이 부족해지면 secondary header pages가 자동으로 할당된다고 합니다.

https://www.ibm.com/support/knowledgecenter/SSGU8G_11.70.0/com.ibm.perf.doc/ids_prf_309.htm

If you have a table that needs more extents and the database server runs out of space on the
partition header page, the database server automatically allocates extended secondary partition
header pages to accommodate new extent entries.
The database server can allocate up to 32767 extents for any partition, unless the size of a table
dictates a limit to the number of extents.

따라서 11.70 버전부터 extent가 최대 32,767개 까지 할당됩니다. 관리할 점은 줄었네요.

그렇지만 성능을 고려한다면 개수를 적게 유지하는 것이 좋겠죠.

 

아래와 같이 데이터를 대량으로 입력해서 extent 개수를 많이 늘려보았습니다.

일반적으로는 EXTENT DOUBLING 규칙에 의해 extent 크기가 2배씩 커지지만 작은 페이지 크기로 일정하게 할당되도록 NO_EXTENT_DOUBLING 옵션을 활성화 했습니다.

참고로 NO_EXTENT_DOUBLING 옵션은 11.70.xC9부터 사용가능합니다.

drop table "informix".log_01;
create table "informix".log_01
  (
    col1 varchar(50),
    col2 varchar(32),
    col3 varchar(5),
    col4 varchar(5),
    col5 varchar(10)
  ) in dbs1 extent size 16 next size 16 lock mode page;
  ...

아래의 SQL문장으로 1천만건의 레코드를 입력합니다.

$ nohup dbaccess -e demo /informix/skjeong/insert1.sql > /informix/skjeong/insert1.log 2>&1 &
$ cat insert1.sql
insert into log_01
select 'dolore eu fugiat nulla pariatur. Excepteur sint oc',
       '180e70d7-8684-4674-8d42-3c1e5f3b',
       'labor',
       'eiusm',
       level
from sysmaster:sysdual
connect by level <= 10000000;

데이터 입력중에 oncheck 명령으로 테이블의 extent 수를 확인해보았습니다.

와우! 2356개입니다. EXTENT DOUBLING이 되고 한계가 3만2천개라면 거의 제한이 없는 것으로 봐도 되겠지요.

TBLspace Report for demo:informix.log_01
    Physical Address               2:5
    Creation date                  02/17/2020 13:23:41
    TBLspace Flags                 901        Page Locking
                                              TBLspace contains VARCHARS
                                              TBLspace use 4 bit bit-maps
    Maximum row size               107
    Number of special columns      5
    Number of keys                 0
    Number of extents              2356
    Current serial value           1
    Current SERIAL8 value          1
    Current BIGSERIAL value        1
    Current REFID value            1
    Pagesize (k)                   2
    First extent size              8
    Next extent size               128
    Number of pages allocated      301056
    Number of pages used           301056
    Number of data pages           300981
    Number of rows                 5422921
    Partition partnum              2097154
    Partition lockid               2097154
    Extents
         Logical Page     Physical Page        Size Physical Pages
                    0         6:5000427           8          8
                    8         6:5000483           8          8
                   16         6:5000611          16         16
                   32         6:5000851          32         32
                   64         6:5001395          64         64
                  128         6:5002675         128        128
                  256         6:5004083         128        128
                  384         6:5005363         128        128
                  512         6:5006515         128        128
                  ...
728x90
728x90

예전에 Ben Thompson의 블로그에서 Index fragment의 page limit에 대한 글을 읽었습니다.

2014년의 글인데 Index의 페이지 수가 12.1버전부터 2^31 (2,147,483,647)개로 증가했다는 것이지요.

IBM Knowledge Center에도 문서화되어 있습니다.

https://www.ibm.com/support/knowledgecenter/SSGU8G_12.1.0/com.ibm.adref.doc/ids_adr_0718.htm#ids_adr_0718__table

 

블로그의 저자인 Ben은 11.7 버전에서도 테스트해보았다는 내용이 있습니다. 그러나 IBM 문서에는 해당 내용이 없어서, IBM Community에 자문을 구하고자 질문을 올렸고 Art와 Ben이 몇가지 조언을 주어서 직접 테스트를 하게 되었습니다.

 

테스트 환경은 인포믹스 11.50.FC6과 11.70.FC5이고, 테스트 시나리오를 위해 고객사의 테이블 스키마를 사용했습니다.

고객은 인포믹스 11.7 버전을 사용하고 있고, 매달 생성하는 테이블이 있는데 최근 몇달간의 데이터를 보니 약 4억4천만건의 레코드가 저장되고 있더군요.

문제는 테이블은 라운드 로빈(round robin) 형태인데 primary key에 해당하는 unique index는 분할되지 않아 기존에 알고 있던 한계치인 2^24 (16,775,134) 개에 육박하고 있다는 점입니다.

그런데 막상 IBM Knowledge Center의 11.7 버전의 문서에는 인덱스 페이지 수의 제한은 나와있지 않고..

 

이런 상황을 가정하고 아래의 테이블을 만들었습니다.

create table log_12
  (
    col1 varchar (50),
    col2 varchar (32),
    col3 varchar (5),
    col4 varchar (5),
    col5 varchar (10)
   .....
  ) fragment by round robin in dbs1, dbs2, dbs3
extent size 16000000 next size 10000000;​

데이터 입력 시간을 절약하기 위해, 더미 데이터를 약 5억건 입력하고 아래 인덱스를 만들었습니다.

create unique index log_12_pk on log_12 (col1, col2, col3, col4, col5) in idx1;​

11.5에서는 인덱스의 페이지 수가 2^24 (16,775,134)개에 도달하자 인덱스를 생성하는 트랜잭션은 롤백되면서 online.log에는 아래와 같은 메시지가 출력되었습니다.

15:22:42 partition 'demo: informix.log_12_pk': no more pages

11.7에서는 인덱스 생성이 완료되었고, 인덱스에 35,999,944개의 페이지가 할당되었습니다.

아래는 oncheck -pt의 결과물의 일부입니다.

                  Index log_12_pk fragment partition idx1 in DBspace idx1
    Physical Address               5:5
    Creation date                  02/14/2020 16:47:53
    TBLspace Flags                 801        Page Locking
                                              TBLspace use 4 bit bit-maps
    Maximum row size               107
    Number of special columns      0
    Number of keys                 1
    Number of extents              2
    Current serial value           1
    Current SERIAL8 value          1
    Current BIGSERIAL value        1
    Current REFID value            1
    Pagesize (k)                   2
    First extent size              8672897
    Next extent size               5420560
    Number of pages allocated      35999944
    Number of pages used           35705525
    Number of data pages           0
    Number of rows                 0
    Partition partnum              5242882
    Partition lockid               2097217
    Extents
         Logical Page     Physical Page        Size Physical Pages
                    0              5:53    23999947   23999947
             23999947               9:3    11999997   11999997

인포믹스 11.7 이상이라면 인덱스 페이지 수 제한을 걱정하지 않아도 되겠군요.

 

추가로 IBM에 공식적으로 문의한 결과, 11.7 문서화에 명시되지 않았을 뿐 인덱스 페이지 수 제한은 12.1 버전과 마찬가지로 2^31 (2,147,483,647)개임을 확인했습니다.

728x90
728x90

문자열에서 특수문자를 제거하는 방법을 찾아보았습니다. 엔터나 탭같은 보이지 않는 문자를 'nonprintable character'라고 부르기도 하는데요. 인포믹스에서는 이런 문자열을 확인하려면 데이터를 파일로 내려받습니다.

> insert into test values ('a'||chr(10)||'bcd'||chr(9)||'efg');
1 row(s) inserted.
> select * from test;
a  a
bcd     efg
$ echo "unload to test select * from test" | dbaccess -X kr_iis
Database selected.
1 row(s) unloaded.
Database closed
$ cat test
a\0abcd\09efg|

dbaccess 유틸리티에서 -X 옵션을 사용하면 nonprintable character를 16진수 형식으로 보여줍니다.

화면에는 표시되지않고 UNLOAD를 사용하여 파일로 내려받았을 때 보입니다.

 

REPLACE를 사용해서 일일이 특수문자를 치환할 수도 있지만, REGEX_REPLACE 함수를 사용해서 아래처럼 간단하게 사용할 수도 있습니다. 오라클의 REGEXP_REPLACE와 사용법은 동일합니다. ( chr(1) 부터 chr(31) 까지 )

> SELECT REGEX_REPLACE (A, '['||CHR(1)||'-'||CHR(31)||']','') FROM TEST;
(expression)  abcdefg

 

범위를 세분화하려면 아래와 같이 사용할 수도 있습니다. ( chr(1) 부터 chr(9), chr(11) 부터 chr(31) )

> SELECT REGEX_REPLACE (A, '['||CHR(1)||'-'||CHR(9)||']|['||CHR(11)||'-'||CHR(31)||']','') FROM TEST;
(expression)  a
bcdefg

 

사용방법은 아래 사이트를 참고했습니다.

https://www.ascii-code.com/

http://mrrame.blogspot.com/2010/05/oracle-how-to-replace-non-printable.html

728x90
728x90

안녕하세요. IBM Community에서 Informix의 rowid를 참조하는 내용이 있어 공유하고자 합니다.

원래 글의 내용은 Informix page 할당 개수의 한계에 관련된 질문이었는데 파티션된 테이블의 rowid에 대한 내용이 중간에 언급되었습니다.

인포믹스의 파티션된 테이블은 rowid 컬럼이 존재하지 않는데, 파티션 테이블에 rowid를 표시되도록 하려면 아래의 명령으로 숨겨진 ROWID 컬럼을 추가할 수 있습니다.

ALTER TABLE frag1 ADD ROWIDS;


그런데 ifx_row_id라는 숨겨진 컬럼이 있다고 합니다. 이리저리 자료들을 찾아보니 11.50 버전부터 지원되었다고 하는데요. IBM에서 공식적으로 문서화되지 않았습니다.

기존 테이블에 rowid 컬럼을 추가하지 않고도 rowid를 대체하여 사용할 수 있습니다.

보여지는 형식은 <partnum>:<rowid> 입니다.

특징으로는 아래와 같이 SEQUENTIAL SCAN이 발생한다는 점입니다.

QUERY: (OPTIMIZATION TIMESTAMP: 01-02-2020 17:27:54)
------
select ifx_row_id from systables where ifx_row_id='1048900:1301'
Estimated Cost: 7
Estimated # of Rows Returned: 1
  1) informix.systables: SEQUENTIAL SCAN
        Filters: informix.systables.ROWID = '1048900:1301'


반면에 ROWID 컬럼은 INDEX SCAN을 합니다.

QUERY: (OPTIMIZATION TIMESTAMP: 01-02-2020 17:51:25)
------
select * from systables where rowid=2058
Estimated Cost: 1
Estimated # of Rows Returned: 1
  1) informix.systables: INDEX PATH
    (1) Index Name: (ROWID)
        Index Keys: ROWID
        Lower Index Filter: informix.systables.ROWID = 2058

ifx_row_id 컬럼은 일반적인 사용자 업무에 사용되기보다는 마이그레이션등의 작업에 이용할 수 있는 옵션이 될 수 있을 것 같습니다.


아래 APAR를 보면 WITH ROWIDS 옵션을 쓰기보다 일반 컬럼을 primary key로 사용할 것을 권고하고 있습니다.

IC94738: IFX_ROW_ID UNDOCUMENTED FEATURE IS DOING SEQUENTIAL SCAN INSTEAD OF READING DIRECTLY IN THE APPROPRIATE PAGE

Using the WITH ROWIDS Option
Nonfragmented tables contain a hidden column called rowid, but
by default, fragmented tables have no rowid column. You can use
the WITH ROWIDS keywords to add the rowid column to a fragmented
table. Each row is automatically assigned a unique rowid value
that remains stable for the life of the row and that the
database server can use to find the physical location of the
row. Each row requires an additional four bytes to store the
rowid.
Important: This is a deprecated feature. Use primary keys as an
access method rather than the rowid column.

https://www-01.ibm.com/support/docview.wss?uid=swg1IC94738

728x90
728x90

안녕하세요. 인포믹스가 14.10 버전이 되면서 새로운 기능이 활발하게 추가되고 있습니다.

이번에 소개드릴 내용은 14.10.xC2 버전부터 적용되는 사항으로 Developer Edition과 Innovator-C Edittion의 시스템 자원 사용의 제한 사항이 완화되었다는 내용을 소개드리려고 합니다.

 

일반적으로 제품군이라고 하면 Workgroup이나 Enterprise에 익숙하실텐데요.

Developer와 Innovator-C 는 무료 에디션으로 사용목적에 따라 구분될 수 있습니다.

아래는 Carlton Doe씨가 정리한 문서 내용에서 Developer Edition과 Innovator-C Edition을 정의한 것입니다.

http://www.iiug.org/en/2019/10/08/compare-informix/

 

  • IBM Informix Developer Edition — For application development and testing only, this edition packs the full suite of IBM Informix functionality into an attractive price point: free! The Developer Edition includes all the functionality available in the IBM Informix Enterprise Edition however there are scalability constraints including processing, memory, storage, and connection limitations. It is available on a wide range of operating systems. Since the intent of the IBM Informix Developer Edition is for system development and test only, it cannot be used in a production environment, and there is no optional support package. Customers can migrate to or from the Developer Edition directly to / from any other edition simply by re-executing the new Edition Installer to install the appropriate license key.
  • IBM Informix Innovator-C Edition — For customers looking for a robust database environment that can support small production workloads, this edition provides the most widely used data processing functionality. Available on all supported platforms, this edition is limited to one core and a total of 2GB of RAM operating from the same install. The IBM Informix Innovator-C Edition can be used for small end-user production workloads without a license fee. Redistribution requires a separate license. Support is community-based though an optional for-charge service and support package is available for the IBM Informix Innovator-C edition. This Elite Software Support package provides full support and product updates for the term of the contract. For more information about this package, see IBM Elite Support for IBM Informix Innovator-C Edition. Community support is available through discussion forums hosted by the International Informix User Group (IIUG). Customers can migrate to or from the Innovator-C Edition directly to / from any other edition simply by re-executing the new Edition Installer to install the appropriate license key.

 

위의 내용처럼 Developer Edition은 개발 및 테스트 용도로만 제한됩니다. 그러나 Innovator-C Edition은 소규모 운용환경에서도 사용할 수 있다고 합니다. 중요한 것은 라이센스 비용없이 사용할 수 있다는 점입니다.

 

이런 점에서 구미가 당길만 하지만 무료이다보니 기능 제한이 다소 있습니다.

몇가지 예를 들면 onbar 백업이 되지 않고, table/index partitioning, 컬럼 레벨의 암호화 기능을 사용할 수 없습니다.

그러나 14.10.xC2 버전부터 cpu thread를 2개, shared memory를 8GB 까지 설정할 수 있고 스토리지를 50GB까지 사용할 수 있습니다.

 

사용자의 입장에서 라이센스 비용이 전혀 들지 않는다는 점은 상당한 장점입니다.

최근에는 CPU 파워가 상당히 좋아졌기 때문에 데이터 사이즈를 관리할 수 있다면 Innovator-C Edition을 사용하는 것도 좋은 선택이 될 것 같습니다.

 

위에서 설명한 에디션별 비교표는 위의 링크에서 직접 보실 수 있습니다.

꾸준히 업데이트 되고 있으니 참고해보세요.

 

Compare_IBMIfmx_v20_preprod.pdf
0.10MB

728x90
728x90

안녕하세요.

인포믹스에서 문자열을 구분자로 나누는 regex_split 함수 기능을 테스트 해봤습니다.

 

SQL에서는 아래와 같이 사용합니다.

select * from table(function regex_split('SMITH,ALLEN,WARD,JONES',',')) as list (name);

 

name  SMITH

name  ALLEN

name  WARD

name  JONES

 

처음 regex_split 함수를 호출하면 datablade 모듈이 설치되는 것을 로그 메시지에서 확인할 수 있습니다.


08/02/19 16:42:52  INFO (autoregexe 5) (EXECUTE FUNCTION sysbldprepare ('ifxregex.*', 'create'))

08/02/19 16:42:52  Loading Module <$INFORMIXDIR/extend/ifxmngr/ifxmngr.bld>

08/02/19 16:42:52  The C Language Module </work2/INFORMIX/1210FC10WE/extend/ifxmngr/ifxmngr.bld> loaded

08/02/19 16:42:57  Logical Log 843 Complete, timestamp: 0x2c72e48.

08/02/19 16:42:58  Loading Module <$INFORMIXDIR/extend/ifxregex.1.00/ifxregex.bld>

08/02/19 16:42:58  The C Language Module </work2/INFORMIX/1210FC10WE/extend/ifxregex.1.00/ifxregex.bld> loaded



프로시저를 사용한다면 인자로 변수리스트를 받아 처리하면 될 것 같네요.

CREATE PROCEDURE customer_details(v_list CHAR(30))

 

   ...

 

select customer_num, fname

into v_customer_num, v_fname

from customer

where customer_num in

select * from table(function regex_split(v_list,',')) as list (value);

 

   ...

 

END PROCEDURE;

 

위의 regex_split 함수 기능은 인포믹스 12.10.xC8 이상의 버전부터 지원됩니다.


https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.dbext.doc/ids_dbxt_557.htm

728x90
728x90

jdbc tracing 기능을 사용하는 방법을 설명하는 글입니다. 샘플 자바 코드를 첨부하였습니다.


Technote (troubleshooting)


Problem(Abstract)

How to enable JDBC tracing for debugging JDBC related issues from version 3.00.JC1 onwards.

Resolving the problem

INTRODUCTION


From version 3.00.JC1 of IBM® Informix® JDBC Driver onwards, debug drivers are no longer shipped.
Informix JDBC Driver now supports SQLIDEBUG. You no longer need to set values for TRACETRACEFILE or PROTOCOLTRACEPROTOCOLTRACEFILE. You only need to set SQLIDEBUG.

STEPS

Using a simple java program called simple.java as an example, the following steps show how to create a trace with the Informix JDBC Driver.

Example:


1. Set the CLASSPATH to the Informix JDBC Driver package.

c:\Infx\Java>set
CLASSPATH=C:\infx\JDBC3.00JC3\lib\ifxjdbc.jar;C:\infx\JDBC3.00JC3\lib\ifxjdbcx.jar;.

2. Compile simple.java

c:\Infx\Java>javac simple.java

3. Ensure that SQLIDEBUG is set correctly

c:\Infx\Java>grep SQLIDEBUG simple.java  
conn=DriverManager.getConnection("jdbc:informix-sqli://irk:1526/sysmaster:INFORMIXSERVER=irk940;USER=informix;
PASSWORD=ximrofni;SQLIDEBUG=C:\\infx\\java\\trace");

Note: SQLIDEBUG is set in the connection string. It points to where the trace file will be found with a certain format i.e. trace.xxxxxxx

4. Remove or move all other trace files

c:\Infx\Java>del trace*

5. Run java.simple

c:\Infx\Java>java simple
systables
syscolumns
...
...
oledbordinals


6. Then locate the trace file

c:\Infx\Java>dir trace*
Volume in drive C has no label.
Volume Serial Number is B823-46D8

Directory of c:\Infx\Java

04/04/2006 14:12 20,560 trace1144156355642.0
1 File(s) 20,560 bytes
0 Dir(s) 4,067,995,648 bytes free


c:\Infx\Java>

7. You will be able to see that a trace file has been created however
you will not be able to read the file.

8. Send the trace file to your local technical support office for analysis.

Note: The code simple.java is found in the attachments

simple.java



출처 : https://www-01.ibm.com/support/docview.wss?uid=swg21237681

simple.java
0.0MB
728x90
728x90

iiug.org에서 onbar에서 사용되는 XBSA API에 대한 설명을 발췌하였습니다. 

onbar 명령으로 백업을 수행하면 onbar 프로세스는 백업 솔루션의 프로세스와 통신하게 되는데, 그 과정에서 아래의 API들을 사용하게 됩니다.

onbar로 백업을 하고 계신 곳에서는 백업 로그에서 아래의 일부 API 이름을 보셨을 겁니다.


Onbar can communicate with multiple storage managers. The reason we can pull this off is because recently a standard api has been developed so that different vendors can communicate with each other. This standard/language is know as XBSA. Below are the XBSA calls that onbar uses in order to backup and restore dbspaces to/from the online engine. The functions below are the complete set of XBSA call. It is mearly the calls that onbar uses.


  • BSABeginTxn()- starts an XBSA API transaction.
  • BSACreateObject()- Creates an XBSA object. This basically tells that storage manager to make room for a new backup. The storage manager passes back the copyid (inside the objectdescriptor) that is the unique identifier that onbar uses when it need to get that back/object.
  • BSAEndData()-Tells the storage manager that there is no more data to send. (we are finished sending data associated with that particular object)
  • BSAEndTxn()- Tell the storage manager that we are finished with a backup transaction.
  • BSAGetData()- This function returns a single buffer of data from that storage manager. We pass it the copyid (in the object descriptor) and the storage manager is responsible for finding the requested data.
  • BSAGetObject()- Called to gather information about a particular storage manager object (ie, date created , size, owner etc).
  • BSAInit()- connects to the storage manager and starts a session. This function will return a 'handle' that is a unique identifier associated to that session.
  • BSAQueryApiVersion()- Called to validate which version of the XBSA libraries onbar is talking to.
  • BSASendData()- Sends a buffer full of data to the storage manager.
  • BSATerminate()- Terminates a session with the storage manager. It also frees up and resources that were allocated in the BSAinit call.


Below is a simplistic diagram on how an XBSA application goes. onbar (which is an XBSA applicalion in it self) follows this flow chart as well when creating/restoring archives. onbar will loop calling BSASendData (and BSAGetDATA) until the is no more data to process.




출처 : http://www.iiug.org/onbar/xbsa.html

728x90
728x90

안녕하세요. IBM Informix 12.10.xC10 버전부터 기본(Primary)/미러(Mirror) 청크(Chunk)를 교체하는 기능이 생겨 테스트를 해봤습니다.


제가 미러 청크를 만든 방법과 교체한 내용을 소개해 드리겠습니다.


1. onCONFIG 옵션 변경

미러 청크를 사용하려면 onCONFIG의 MIRROR 옵션을 1로 변경해야 합니다.

그리고 처음 미러 청크를 만드는 경우라면 MIRRORPATH는 공란으로 두어야 합니다.

MIRRORPATH는 root dbspace에 대한 청크 경로이므로 공란으로 두지 않으면 Informix 인스턴스가 시작되지 않습니다.


2. 기존의 청크에 미러 청크 생성하기

미러 청크를 생성하는 것은 onspaces 명령이나 sysadmin api를 통해 가능한데 여기서는 onspaces 명령으로 해보겠습니다.


먼저 기본 청크 경로를 확인합니다.


$ onstat -d


IBM Informix Dynamic Server Version 12.10.FC12W1WE -- on-Line -- Up 00:01:25 -- 227552 Kbytes


Dbspaces

address          number   flags      fchunk   nchunks  pgsize   flags    owner    name

700000020476028  1        0x4000001  1        2        4096     N  BA    informix rootdbs

7000000205abbe0  2        0x5000001  2        1        4096     N PBA    informix plog

700000020476dc8  3        0x4000001  3        1        4096     N  BA    informix llog

700000020477bf0  4        0x4000001  4        1        4096     N  BA    informix datadbs1

70000002058f850  5        0x4000001  5        1        4096     N  BA    informix datadbs2

70000002058fa90  6        0x4000001  6        1        4096     N  BA    informix datadbs3

70000002058fcd0  7        0x4000001  7        1        8192     N  BA    informix data8dbs1

700000022733028  8        0x4000001  8        1        8192     N  BA    informix data8dbs2

700000022733268  9        0x4000001  9        1        8192     N  BA    informix data8dbs3

7000000227334a8  10       0x2001     10       1        8192     N TBA    informix tmpdbspace

7000000227336e8  11       0x4008001  11       1        4096     N SBA    informix sbspace1

700000022733928  12       0xa001     12       1        4096     N UBA    informix tmpsbspace

 12 active, 2047 maximum


Chunks

address          chunk/dbs     offset     size       free       bpages     flags pathname

700000020476268  1      1      0          38912      5453                  PO-B-D /opt/IBM/informix/storage/rootdbs

700000022735028  2      2      0          16384      0                     PO-BED /opt/IBM/informix/storage/ol_informix1210_4_plog_p_1

700000022736028  3      3      0          151426     1373                  PO-BED /opt/IBM/informix/storage/ol_informix1210_4_llog_p_1

700000022737028  4      4      0          16384      15145                 PO-BED /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1

700000022738028  5      5      0          16384      16331                 PO-BED /opt/IBM/informix/storage/ol_informix1210_4_datadbs2_p_1

700000022739028  6      6      0          16384      16331                 PO-BED /opt/IBM/informix/storage/ol_informix1210_4_datadbs3_p_1

70000002273a028  7      7      0          8192       8139                  PO-BED /opt/IBM/informix/storage/ol_informix1210_4_data8dbs1_p_1

70000002273b028  8      8      0          8192       8139                  PO-BED /opt/IBM/informix/storage/ol_informix1210_4_data8dbs2_p_1

70000002273c028  9      9      0          8192       8139                  PO-BED /opt/IBM/informix/storage/ol_informix1210_4_data8dbs3_p_1

70000002273d028  10     10     0          9216       9163                  PO-BE- /opt/IBM/informix/storage/ol_informix1210_4_tmpdbspace_p_1

70000002273e028  11     11     0          16384      11822      11879      POSB-D /opt/IBM/informix/storage/ol_informix1210_4_sbspace1_p_1

                                 Metadata 868        4138       868

70000002273f028  12     12     0          16384      11879      11879      POSB-- /opt/IBM/informix/storage/ol_informix1210_4_tmpsbspace_p_1

                                 Metadata 868        4138       868

700000022734028  13     1      0          16384      11097                 PO-BED /opt/IBM/informix/storage/ol_informix1210_4_rootdbs_p_1

 13 active, 32766 maximum


NOTE: The values in the "size" and "free" columns for DBspace chunks are

      displayed in terms of "pgsize" of the DBspace to which they belong.



Expanded chunk capacity mode: always



여기 예에서는 datadbs1 dbspace의 청크에 미러 청크를 생성해보겠습니다.


$ onspaces -m datadbs1 -p /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1 -o 0 -m /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1_mirror 0


WARNING: Turning mirror on for 'datadbs1'.


Do you really want to continue? (y/n)y

Verifying physical disk space, please wait ...

The Space "datadbs1" is now mirrored.


명령을 실행하면 미러 청크를 만들것인지 확인하는 메시지가 나옵니다.

여기서 'y' 를 입력하고 엔터를 누르면 미러 청크가 생성됩니다.


3. 생성한 미러 청크 확인

onstat -d 명령으로 미러 청크가 생성되었는지 확인합니다.

미러 청크의 경우 flags 값의 맨 처음 값이 M으로 표시됩니다.


$ onstat -d

...

Chunks

address          chunk/dbs     offset     size       free       bpages     flags pathname

700000020476268  1      1      0          38912      5453                  PO-B-D /opt/IBM/informix/storage/rootdbs

700000022735028  2      2      0          16384      0                     PO-BED /opt/IBM/informix/storage/ol_informix1210_4_plog_p_1

700000022736028  3      3      0          151426     1373                  PO-BED /opt/IBM/informix/storage/ol_informix1210_4_llog_p_1

700000022737028  4      4      0          16384      15145                 PO-B-D /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1

700000022e2e028  4      4      0          16384      0                     MO-B-D /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1_mirror



onstat -m 명령으로 로그 메시지를 확인해보면 아래와 같이 나옵니다.


$ onstat -m


IBM Informix Dynamic Server Version 12.10.FC12W1WE -- on-Line -- Up 00:03:19 -- 227552 Kbytes


Message Log File: /opt/IBM/informix/ol_informix1210_4.log

11:33:05  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 18, Llog used 2


11:33:06  Checkpoint Completed:  duration was 0 seconds.

11:33:06  Thu Apr 11 - loguniq 808, logpos 0x3b94050, timestamp: 0x69dc6db Interval: 284


11:33:06  Maximum server connections 0

11:33:06  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 1, Plog used 0, Llog used 3


11:33:06  The Space "datadbs1" is now mirrored.


11:33:06  Space 'datadbs1' -- Recovery Begins(700000020552ec8)

11:33:06  Chunk Number 4 - '/opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1_mirror' -- Recovery Begins(700000020552ec8)

11:33:23  Chunk Number 4 - '/opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1_mirror' -- online

11:33:23  Checkpoint Completed:  duration was 0 seconds.

11:33:23  Thu Apr 11 - loguniq 808, logpos 0x3b97018, timestamp: 0x69dc6e8 Interval: 285


11:33:23  Maximum server connections 0

11:33:23  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 0, Llog used 3


11:33:23  Space 'datadbs1' -- Recovery Complete(700000020552ec8)


Recovery Complete 메시지가 보이는 순간부터 미러링(Mirroring)이 시작됩니다.



4. 기본 청크와 미러 청크 교체하기

기본 청크와 미러 청크를 교체하려면 sysadmin의 task function의 swap_mirror 명령을 사용합니다.


$ dbaccess sysadmin -


Database selected.


> execute function task('modify chunk swap_mirror',4);




(expression)  Primary/mirror swap for chunk 4 succeeded.


1 row(s) retrieved.



5. 기본 청크와 미러 청크가 교체되었는지 확인

onstat -d 명령으로 기본 청크와 미러 청크가 교체되었는지 확인합니다.


$ onstat -d


...

Chunks

address          chunk/dbs     offset     size       free       bpages     flags pathname

700000020476268  1      1      0          38912      5453                  PO-B-D /opt/IBM/informix/storage/rootdbs

700000022735028  2      2      0          16384      0                     PO-BED /opt/IBM/informix/storage/ol_informix1210_4_plog_p_1

700000022736028  3      3      0          151426     1373                  PO-BED /opt/IBM/informix/storage/ol_informix1210_4_llog_p_1

700000022737028  4      4      0          16384      15145                 PO-B-D /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1_mirror

700000022e2e028  4      4      0          16384      0                     MO-B-D /opt/IBM/informix/storage/ol_informix1210_4_datadbs1_p_1



onstat -m 명령으로 로그 메시지를 확인해보면 아래와 같이 나옵니다.


$ onstat -m


...

11:36:36  Primary/mirror swap for chunk 4 succeeded.

11:36:36  Checkpoint Completed:  duration was 1 seconds.

11:36:36  Thu Apr 11 - loguniq 808, logpos 0x3b9a07c, timestamp: 0x69dc70c Interval: 286


11:36:36  Maximum server connections 1

11:36:36  Checkpoint Statistics - Avg. Txn Block Time 0.000, # Txns blocked 0, Plog used 6, Llog used 3


미러링은 일반적으로 디스크 오류가 발생했을 때 데이터베이스 서버를 온라인에서 복구하기 위한 기능이지만,

swap_mirror 명령이 추가됨으로써 인스턴스가 온라인인 상태에서 파일을 교체할 수 있어, 스토리지 위치를 변경할 때 유용하게 사용할 수 있을 것 같습니다.


728x90

+ Recent posts