pajama

Troubleshooting

https://www.ibm.com/support/pages/informix-fails-exception-javasqlsqlexception-blob-not-found

https://www.databaseadm.com/article/11187195/temporary+files+are+not+getting+deleted

안녕하세요.

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

안녕하세요. 오라클 데이터베이스에서 Microsft Access (mdb) 파일을 조회하는 기능을 테스트해보았습니다.

테스트 환경은 윈도우 10 64비트, 오라클 데이터베이스 11gR2 64비트 입니다.

먼저 Database Gateway가 설치되어야 합니다. 오라클 기본 설치 구성 중 제외하지 않았다면 사용할 수 있습니다.

mdb 파일은 odbc 를 통해 접근할 수 있으므로 DG4ODBC 설정을 했습니다. 10g에서는 HSODBC라고 하죠.

참고로 Database Gateway는 Oracle Document 232482.1에 따르면 별도의 라이센스는 필요하지 않다고 합니다.

아래는 해당 문서 내용의 일부입니다.

The purpose of this note is to clarify the licensing considerations for the Oracle Database Gateway products, such as ODBC, SQL Server, Sybase, DRDA, and more.
The licensing applies to both Enterprise and Standard RDBMS editions.

The Oracle Database Gateway for ODBC (DG4ODBC) is included in your Oracle Database Server license without extra cost. If DG4ODBC is installed on a different machine from where the Oracle Database Server is installed then it is still covered by the Oracle Database Server license and that install of DG4ODBC does not need a separate license.

오라클 데이터베이스 설치는 전부 기본 설정으로 했고 아래의 설정파일만 수정했습니다.

1. %ORACLE_HOME%\network\admin\tnsnames.ora

2. %ORACLE_HOME%\network\admin\.ora

3. %ORACLE_HOME%\network\admin\initdg4odbc.ora

4. odbc 데이터소스를 정의한 화면입니다. sample.mdb 파일을 선택하고 확인을 누릅니다.

5. sample odbc 데이터소스에 대한 데이터베이스 링크를 만들고 SQL을 실행한 화면입니다.

linux에서 먼저 시도해봤는데 오류 해결방법을 아직 찾지 못해 윈도우로 해보니 비교적 쉽게(?) 되네요.

참고:

Database Gateway and Generic Connectivity (DG4ODBC) Licensing Considerations (Doc ID 232482.1)

https://docs.oracle.com/cd/E11882_01/gateways.112/e12013/configodbc.htm#OTGIS110

https://stackoverflow.com/questions/24081001/how-to-query-an-external-ms-access-db-from-an-oracle-db

데이터베이스 마이그레이션, 리스토어(RESTORE) 작업으로 인해 루틴이 INVALID 상태로 빠지는 경우가 있습니다. 아래에서 설명하는 sysproc.admin_revalidate_db_objects 프로시저를 사용해 오브젝트 별 또는 일괄로 루틴들을 재컴파일 할 수 있습니다.

Question

DB2 Package could be revalidated by either the REBIND or the BIND command, however it may not work for SQL routines, how to mark a routine to be VALID?

Cause

Answer

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

회사 내부 네트워크에서 회사내에 있는 가상 PC의 윈도우 터미널에 접속이 되지 않아 라우터의 설정을 좀 찾아보았습니다.

찾아보니 NAT Hairpin에 대한 설명을 찾을 수 있었고, WinBox에서 NAT Rule을 설정하는 방법을 찾아서 적용해 보았습니다.

아래는 EdgeRouter 매뉴얼에서 NAT Hairpin 을 설명한 글입니다.

일반적으로 NAT 포트 포워딩 룰은 *네트워크 바깥*에서 *네트워크 안*으로 hostname 또는 라우터의 퍼블릭 주소를 통해서 사용됩니다. 하지만 같은 로컬 네트워크 내의 로컬 서버의 주소는 더 사용하기 쉬운 NAT 헤어핀이 적용됩니다. 예를 들어, 사용자의 랩탑과 메일 서버가 같은 로컬 네트워크 내에 있는 경우, 혼란을 피하기 위해서 같은 로컬 내트워크 내에 있을 때나 그렇지 않을 때나 같은 서버명을 사용하기를 선호할 것입니다.

아래는 NAT Hairpin 설정 절차 예제입니다.

이 설정은 요약하자면 내부에서 외부 네트워크를 거쳤다가 다시 내부 네트워크로 접속하게 하는 것입니다.

I solved the problem. 

 Fewi, thanks for your hints mate!

/1. Services hairpin to .10
     chain=dstnat action=dst-nat to-addresses=192.168.10.10 protocol=tcp 
     dst-address=!192.168.10.0/24 dst-address-type=local 
     dst-port=80,21
/2. NAT all traffic from local to internet
     chain=srcnat action=masquerade src-address=192.168.10.0/24 
     out-interface=WAN 
/3. NAT all traffic from local to local
     chain=srcnat action=masquerade protocol=tcp src-address=192.168.10.0/24 
     dst-port=80,21 

 192.168.10.0/24 is the local network segment.
192.168.10.10 is the local IP of the WEB/FTP server
There are TWO rules to be added, 1. and 3. above. Rule 2 is also necessary and is the well known rule which provides NAT for the local clients to the internet.
Rule 1. hairpinning, helped with the client's packet to reach the server. Rule 3. is for the server's response to reach back the local client.

I hope this will be helpful to others and I also hope in the near future this is documented in under wiki or in the user manual to become common knowledge to the user. 

위의 IP 주소에서 내부 IP 대역을 써주시면 됩니다. 참고되시길 바랍니다.

https://wiki.mikrotik.com/wiki/Hairpin_NAT

https://forum.mikrotik.com/viewtopic.php?f=13&t=36548#p179950

https://docs.buf4.com/edgemax/edgerouter-configuration/_204952134-EdgeRouter-NAT-Hairpin-Nat-Inside-to-Inside-Loopback-Reflection-.html

http://www.2cpu.co.kr/bbs/board.php?bo_table=QnA&wr_id=384899

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

안녕하세요. 인포믹스 12.10.FC12, 12.10.FC12W1, 14.10.FC1 버전에서 발생하는 문제를 소개드립니다.

문제가 발생한 이후부터는 인포믹스 프로세스가 시작되지 않으므로 매우 치명적인 결함입니다.

문제가 발생할 수 있는 조건은 아래와 같습니다.

1. 해당 테이블에 VARCHAR 컬럼을 추가한다.

2. 추가한 VARCHAR 컬럼의 사이즈를 축소한다.

위와 같은 상황에서 UPDATE 문장을 실행하면 오류가 발생하면서 인포믹스 프로세스가 다운됩니다.

그러나 항상 다운되는 것은 아니고 대상 테이블에 저장된 데이터 길이에 따라 다운될 수도, 다운되지 않을 수도 있습니다.

아래는 인포믹스 12.10.FC12와 14.10.FC1 버전의 환경에서 다운되는 현상을 재현했을 때의 로그 메시지입니다.

## 12.10.FC12W1

11:20:01  Assert Failed: Buffer modified in inconsistent chunk.

11:20:01  IBM Informix Dynamic Server Version 12.10.FC12W1WE

11:20:01   Who: Session(87, informix@pilma01, 39452766, 700000020593858)

                Thread(222, sqlexec, 700000020553068, 10)

                File: rsdebug.c Line: 1047

11:20:01   Results: Chunk 13 is being taken OFFLINE.

11:20:01   Action: Restore space containing this chunk from the archive.

11:20:01  stack trace for pid 36175890 written to /work2/ifx1210fc12w1we/tmp/af.4c6a350

11:20:02   See Also: /work2/ifx1210fc12w1we/tmp/af.4c6a350, shmem.4c6a350.0

11:20:10  Buffer modified in inconsistent chunk.

11:20:11  Assert Failed: INFORMIX-OnLine Must ABORT

        Critical media failure.

11:20:11  IBM Informix Dynamic Server Version 12.10.FC12W1WE

11:20:11   Who: Session(87, informix@pilma01, 39452766, 700000020593858)

                Thread(222, sqlexec, 700000020553068, 10)

                File: rsmirror.c Line: 2080

11:20:11  stack trace for pid 36175890 written to /work2/ifx1210fc12w1we/tmp/af.4c6a350

11:20:12   See Also: /work2/ifx1210fc12w1we/tmp/af.4c6a350

11:20:19  Thread ID 222 will NOT be suspended because

          it is in a critical section.

11:20:19   See Also: /work2/ifx1210fc12w1we/tmp/af.4c6a350

11:20:19  rsmirror.c, line 2080, thread 222, proc id 36175890, INFORMIX-OnLine Must ABORT

        Critical media failure..

11:20:19  Fatal error in ADM VP at mt_fn.c:14593

11:20:19  Unexpected virtual processor termination: pid = 36175890, exit status = 0x1.

11:20:19  PANIC: Attempting to bring system down

## 14.10.FC1DE

12:46:54  Assert Failed: Buffer modified in inconsistent chunk.

12:46:54  IBM Informix Dynamic Server Version 14.10.FC1DE

12:46:54   Who: Session(46, informix@ifxdb1, 62804, 0x4526fbc8)

                Thread(55, sqlexec, 4522d8c8, 1)

                File: rsdebug.c Line: 908

12:46:54   Results: Chunk 1 is being taken OFFLINE.

12:46:54   Action: Restore space containing this chunk from the archive.

12:46:54  stack trace for pid 62571 written to /opt/IBM/Informix_Software_Bundle/tmp/af.41fb7ad

12:46:54   See Also: /opt/IBM/Informix_Software_Bundle/tmp/af.41fb7ad, shmem.41fb7ad.0

12:46:57  Buffer modified in inconsistent chunk.

12:46:58  Assert Failed: INFORMIX-OnLine Must ABORT

        Critical media failure.

12:46:58  IBM Informix Dynamic Server Version 14.10.FC1DE

12:46:58   Who: Session(46, informix@ifxdb1, 62804, 0x4526fbc8)

                Thread(55, sqlexec, 4522d8c8, 1)

                File: rsmirror.c Line: 2062

12:46:58  stack trace for pid 62571 written to /opt/IBM/Informix_Software_Bundle/tmp/af.41fb7ad

12:46:58   See Also: /opt/IBM/Informix_Software_Bundle/tmp/af.41fb7ad

12:47:02  Thread ID 55 will NOT be suspended because

          it is in a critical section.

12:47:02   See Also: /opt/IBM/Informix_Software_Bundle/tmp/af.41fb7ad

12:47:02  Starting crash time check of:

12:47:02  1. memory block headers

12:47:02  2. stacks

12:47:02  Crash time checking found no problems

12:47:02  rsmirror.c, line 2062, thread 55, proc id 62571, INFORMIX-OnLine Must ABORT

        Critical media failure..

12:47:02  The Master Daemon Died

12:47:02  PANIC: Attempting to bring system down

관련 내용으로 IBM에 기술지원을 요청했었습니다.

해당 문제는 해외에서 발생한 사례가 이미 있었다고 하고 재현 시나리오도 구체적이진 않지만 존재했습니다.

관련 문제를 서술한 문서의 링크는 아래입니다.

http://www-01.ibm.com/support/docview.wss?crawler=1&uid=swg1IT27997

장애 재현시의 메시지 로그에서 보이는 assert failure file 내용을 살펴보니 해당 사용자 스레드의 stack trace를 확인할 수 있었습니다.

0x00000001000af9cc (oninit)afstack

0x00000001000aeb5c (oninit)afhandler

0x00000001000af038 (oninit)affail_interface

0x00000001001b8844 (oninit)buffcheck

0x00000001002371a0 (oninit)buffput

0x0000000100b88640 (oninit)ckpgversion

0x0000000100b87af4 (oninit)rewrecord

0x0000000100b870ec (oninit)rsrewrec

0x000000010071ab00 (oninit)fmrewrec

0x00000001008382a0 (oninit)aud_sqisrewrec

0x0000000100d40a90 (oninit)doupdate

0x0000000100d3ff2c (oninit)chkrowcons

0x000000010114ea04 (oninit)dodmlrow

0x0000000101150eac (oninit)dodelupd

0x000000010083ee30 (oninit)aud_dodelupd

0x0000000100d1ec24 (oninit)excommand

0x00000001008c8590 (oninit)sq_execute

0x00000001008103ac (oninit)sqmain

0x00000001014d6898 (oninit)listen_verify

0x00000001014d530c (oninit)spawn_thread

0x0000000101482ae0 (oninit)th_init_initgls

0x00000001018f86e0 (oninit)startup

defect IT27997에 대해 서술한 내용과 상당히 유사한 stack trace 임을 알 수 있었습니다.

stack trace 중에서 ckpgversion function 부분이 문제인 듯 합니다.

그리고 12.10.FC12 버전부터 In-place alter 기능이 개선되었다고 알려져있는데, 이 개선으로 인해 defect가 발생한 것이 아닌가 생각도 듭니다. 물론 제 추측이기 때문에 정확한 원인으로 보기는 어렵습니다.

IIUG2018의 발표자료중 Jeff McMahon and Nick Geib가 발표한 What’s New in Informix 장표를 살표보면 VARCHAR 에서 VARCHAR 간 (smaller or larger) 사이즈를 변경하는 유형도 In-place alter 방식으로 이루어진다고 나와 있습니다.

아래는 위의 IT27997의 내용을 토대로 작성한 장애재현 스크립트 내용입니다.

테스트용 데이터는 60자 고정길이 필드 한개로 만드시면 재현이 쉽습니다.

drop table test;

create table test (a varchar(60));

load from test.unl insert into test;

alter table test add b int;

alter table test add c varchar(5);

alter table test add d varchar(5);

alter table test add e varchar(5);

alter table test modify c varchar(1);

alter table test modify d varchar(1);

alter table test modify e varchar(1);

update test set a=' qui officia deserunt mollit anim id est laborum.Lorem ip';

해당 문제는 12.10.FC12 및 12.10.FC12W1 에서 발생하는 문제이므로 해당버전을 사용중이라면 IBM에 패치버전을 요청하시거나 12.10.FC11 이하 버전으로 다운그레이드하면 문제가 발생하지 않습니다.

참고가 되시길 바랍니다.

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