pajama

문자열에서 특수문자를 제거하는 방법을 찾아보았습니다. 엔터나 탭같은 보이지 않는 문자를 '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

안녕하세요. 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

안녕하세요. 인포믹스가 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을 사용하는 것도 좋은 선택이 될 것 같습니다.

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

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

안녕하세요.

인포믹스에서 문자열을 구분자로 나누는 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

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

Technote (troubleshooting)

simple.java

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

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

안녕하세요. 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);

(ｅxpression)  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 명령이 추가됨으로써 인스턴스가 온라인인 상태에서 파일을 교체할 수 있어, 스토리지 위치를 변경할 때 유용하게 사용할 수 있을 것 같습니다.

안녕하세요. 우연히 IBM 문서에서 발견한 내용을 소개해 드립니다. 이렇게 매뉴얼을 정독하지 않은 티를 내게 되는군요.

인포믹스에서 UNIQUE 제약조건과 UNIQUE 인덱스의 기능에 차이가 있다는 내용입니다.

평소에 두개의 기능이 다를 것이라고 생각하지 않았는데, 알고나니 개발할 때 이런 점까지 고려해야 되나 생각이 들기도 하네요.

문서에서 설명한 주요 기능의 차이는 아래와 같습니다.

In DML statements, enabled unique constraints on a logged table are checked at the end of a statement, but unique indexes are checked on a row-by-row basis, thereby preventing any insert or update of a row that might potentially violate the uniqueness of the specified column (or for a multiple-column column constraint or index, the column list).

요약하자면, 로깅 모드 (unbuffered, buffered) 테이블에서는

unique 제약조건에서는 insert나 update 문장 실행의 끝날때 중복여부를 확인하고,

unique 인덱스에서는 row-by-row, 건건이 실행할 때마다 중복값을 확인한다는 차이가 있다는 것입니다.

위의 IBM 문서에 기반한 내용으로 아래의 시나리오를 만들어 봤습니다.

시나리오 #1 ==================

1. 정수형(integer) 데이터 타입 1개를 포함한 테이블 작성

> create table test (c int);

2. 테스트 데이터 10만개 입력

> insert into test select level from sysmaster:sysdual connect by level <= 100000;

3. 해당 컬럼에 UNIQUE 인덱스 생성

> create unique index test_idx on test(c);

4. UPDATE 문장 실행

> update test set c=c+1;

  346: Could not update a row in the table.    << UPDATE 문장 실행 즉시 오류가 발생합니다.

  100: ISAM error:  duplicate value for a record with unique key.

============================

시나리오 #2 ==================

1. 정수형(integer) 데이터 타입 1개를 포함한 테이블 작성, 해당 컬럼에 UNIQUE 제약조건 설정.

> create table test (c int, unique(c));

2. 테스트 데이터 10만개 입력

> insert into test select level from sysmaster:sysdual connect by level <= 100000;

3. UPDATE 문장 실행

> update test set c=c+1;

100000 row(s) updated.    << 약 3~7초 정도 경과후 중복값 오류 없이 UPDATE가 실행됩니다.

============================

여기서 시나리오 2번에서 오류가 발생하지 않았으니 unique 제약조건으로 선언하는 것이 낫겠다는 생각이 들기도 합니다.

그러나 몇가지 고려할 사항이 있습니다.

unique 제약조건이 정의되어 있으면 UPDATE/INSERT 문장이 수행되는 도중에 중복값이 발생하더라도

오류가 곧바로 발생하지 않습니다. 아래에서 극단적인 예를 들어보겠습니다.

> drop table test;

> create table test (c int, unique(c));

> insert into test select level from sysmaster:sysdual connect by level <= 100000;

100000 row(s) inserted.

$ echo "update test set c=3;" | timex dbaccess stores_demo

Database selected.

  268: Unique constraint (informix.u160_134) violated.

  100: ISAM error:  duplicate value for a record with unique key.

Error in line 1

Near character position 18

Database closed.

real 37.48

user 0.02

sys  0.03

시나리오 #2의 내용과 동일한 테이블과 데이터를 만들고 같은 값 3으로 UPDATE를 실행했습니다.

unique 제약조건이 있기 때문에 사실 수행될 수 없는 문장입니다.

그러나 수행이 이뤄지고 마지막에 중복값을 확인하기 때문에 약 37초가 소요되었습니다.

수행시간은 시스템 성능에 따라 차이는 있겠지만 수행중 오류가 발생하고 변경사항이 rollback 되었음을 확인할 수 있습니다.

여기서 몇가지 더 의문이 생겼습니다.

그럼 primary key 제약조건에서는 어떨까?

unique 제약조건과 동일하게 268 오류가 발생했습니다.

그러면 unique 인덱스, primary key 제약조건을 만들었을때는?

마찬가지로 268 오류가 발생했습니다.

그럼 unique 인덱스, primary key 제약조건을 만들고 UPDATE 문장에 unique 인덱스를 사용하도록 힌트를 주었다면?

UPDATE 문장에서 INDEX를 강제로 사용하면 달라지지 않을까 예상했지만,

역시 아래와 같이 268 오류가 발생했습니다.

> drop table test;

> create table test (c int);

> insert into test select level from sysmaster:sysdual connect by level <= 100000;

> create unique index test_pk on test(c);

> alter table test add constraint primary key (c) constraint test_pk;

$ echo "update {+ explain index(test test_pk)} test set c=3;" | timex dbaccess stores_demo

Database selected.

  268: Unique constraint (informix.test_pk) violated.

  100: ISAM error:  duplicate value for a record with unique key.

Error in line 1

Near character position 50

Database closed.

real 39.24

user 0.02

sys  0.03

결론적으로 unique/primary key 제약조건이 설정된 경우에는

UPDATE/INSERT 문장이 실행된 이후에 중복값이 검사된다는 것입니다.

속성이 유일한 값이다보니 UPDATE가 드물긴 하겠지만, unique index와는 작동 방식이 다르니 참고할 필요는 있을 것 같습니다.

** 참고

https://www.ibm.com/support/knowledgecenter/en/SSGU8G_12.1.0/com.ibm.sqls.doc/ids_sqs_0517.htm

안녕하세요. 2019년 2월자 IIUG insider에 따르면 인포믹스 14 버전이 2019년 상반기에 출시될 예정이라고 합니다.

작년에 IIUG World 컨퍼런스에서도 소개가 된 내용인데 버전 숫자까지 공개된 것은 처음이네요..

라고 생각했지만 웹에서 검색해보니 이미 작년부터 14.10 버전이야기가 나오고 있었네요.

서양에서는 13이라는 숫자를 확실히 싫어하는 걸까요?

곧 IBM에서 EAP(Early Access Program)도 시작하지 않을까 생각했는데,

이미 CURSOR 등의 회사나 고객사에서 베타테스트를 진행하고 있었던 모양입니다.

https://www.cursor-distribution.de/en/community/community-informix

아래 링크에서 인포믹스 14.10 버전의 새로운 기능을 확인하실 수 있습니다.

http://www.iiug.org/en/2019/02/04/iiug-insider-issue-222-january-2019/

Enhances log replay performance of remote secondary servers and OLTP transactions

• • • Up to 5x improvement in replication enables client applications to sustain near zero latency between primary and secondary servers allowing faster recovery time objective in disaster scenarios.
    • Up to 10% faster than 12.10 for standard OLTP transactions

Provides higher security for encryption keys and integrated backup encryption

• • • By supporting remote storage of encryption at rest keys in Amazon Key Manager, an additional layer of security is applied to Informix server encrypted data. Three ciphers AES128, AES192 and AES256 are supported.
    • By supporting remote key management server to generate encryption keys and reducing DBA effort to encrypt Informix data backups, data security in backup media is enhanced without the risk of losing keys. The encryption key is itself encrypted (called Envelop Encryption).
    • Transport Layer Security (TLS) to 1.2 for a higher level of network transport security.

Enhances usability, streamlines administration, and increases uptime

• • • By supporting additional in-place alter operations on tables and data types, database downtime is avoided

Provides a new centralized and graphical administration tool called InformixHQ

• • • InformixHQ is a modern web console for visualizing, monitoring, and managing your Informix server instances. It is purpose built for ease-of-use, scale-out, and optimizing DevOps needs.
    • It provides critical performance management capabilities, monitoring how key performance metrics are changing overtime and tracking how efficiently Informix is running your workload even when you’ve stepped away from your screen. Its monitoring system feeds directly into a customizable alerting system so you can be immediately alerted via email, Twilio, or PagerDuty whenever an issue occurs on one of your Informix database server instances.
    • It is designed to be scalable to efficiently manage and monitor as many Informix database server instances as you run.
    • It enables collaboration between the DBAs, the app developers, the ops engineers, and management and accessed from any desktop, laptop, or mobile device.
    • InformixHQ is the path forward for graphical monitoring, alerting, and administration of your Informix database servers.

Enhances Unicode support to current V11.0

• • • Ability to support storage and processing for text characters that are new over the last 10 years. The new scripts and characters in Version 11.0 add support for lesser-used languages and unique written requirements worldwide.

Enhances time series granularity and spatial projection

• • • Supporting Sub-second timestamps allow for very high speed event generation
    • Support for more geodetic and projections systems enables you to track packages in a shipping depot using your own coordinate system

Increased hardware limits at the Workgroup Edition level

• • • New limits 24 cores / 32GB RAM enable higher performance and scalability for your critical applications providing even higher return on your Informix investment.

Includes storage optimization at the Enterprise Edition level

• • • All Informix Enterprise edition deployments now benefit from the well proven data compression technology already built in Informix.
    • Data compression reduces primary, secondary, backups and log storage while simultaneously enhancing performance by reducing I/O operations.
    • Customers have reported average 4x reductions in database size while experiencing faster I/O operations and faster backups.

Common table ｅxpression

• • • By implementing the SQL standard CTE, application developers improve readability and maintenance of complex queries, able to re-use CTE result-set multiple times in one query, Pipeline aggregations and write powerful recursive queries.
    • Complex queries can be divided into simple, ad hoc, logical building blocks. These simple blocks can then be used to build more complex, interim CTEs until the final result set is generated.

Setting up Informix instance/or database level replication using Enterprise Replication

• • • Single command that automates setting up of Enterprise Replication and data migration between two Informix server instances located either on-prem or in the cloud. This command automates tasks such as defining Enterprise Replication domain between the two servers, adding key columns for the tables, creating required storage spaces for the databases, copying database schema from source server to target serve, creating replicate definitions and finally synchronizing data between source and target server instances, all in a transactional, flexibly phased manner, with no downtime.

** 출처

http://www.iiug.org/en/2019/02/04/iiug-insider-issue-222-january-2019/

http://www.hamburg-data.de/en/news/136-soon-informix-14-10

https://www.cursor-distribution.de/en/community/community-informix

인포믹스 11버전부터 데이터베이스 관리를 위한 sysadmin 데이터베이스가 있습니다.

sysadmin 데이터베이스에는 인포믹스 상태 정보를 보관하기 때문에,

계속해서 데이터가 유입된다면 데이터를 주기적으로 삭제하거나, 처음부터 여유있는 데이터 파일에 배치하는 것이 좋습니다.

그래서 sysadmin 데이터베이스를 스크립트를 사용하거나,

sysadmin 데이터베이스의 admin/task 프로시저를 사용해서 재생성할 수 있습니다.

1. 수동으로 sysadmin 데이터베이스 다시 만들기

IBM의 Technote에 따르면 $INFORMIXDIR/etc/sysadmin에 sysadmin 데이터베이스를 재생성하기 위한 스크립트가 있습니다.

아래의 명령을 순서대로 실행합니다.

cd $INFORMIXDIR/etc/sysadmin;

dbaccess - db_uninstall.sql;

dbaccess - db_create.sql;

dbaccess sysadmin db_install.sql;

dbaccess sysadmin sch_tasks.sql;

dbaccess sysadmin sch_aus.sql;

dbaccess sysadmin sch_sqlcap.sql;

dbaccess sysadmin start.sql;

여기서 db_create.sql 파일 내용을 살펴보면 데이터베이스를 생성하는 구문이 있습니다.

CREATE DATABASE sysadmin WITH LOG;

파일 내용을 수정해서 이 구문으로 dbspace를 지정할 수도 있을 것입니다.

2. sysadmin 데이터베이스의 프로시저를 사용해 sysadmin 데이터베이스 이동하기

sysadmin 데이터베이스에 admin/task 프로시저를 사용해서 sysadmin 데이터베이스를 재생성할 수 있습니다.

execute function task("reset sysadmin", "admindbs"); 

dbspace 명을 지정하지 않으면 rootdbs에 만들어집니다. 재생성이 완료되면 스케줄러가 자동으로 재시작됩니다.

** 참고

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

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