IBM Informix Dynamic Server Version 12.10.UC4W1
Heinz Weitkamp reported assert failures (PTOCOPYVC collen > max_vc_len, physical_scan decompress_row) that sometimes crashed 12.10.UC4W1. Mark Jalkiewicz suggested a row-versioning or decompress defect, finding the table via the af file, and opening a ticket or reorganising the table. SangGyu Jeong cited APARs IT04586 and IT03514 and advised 12.10.xC5 or higher. Heinz would review the options.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi there, operating system: SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 4 We occasionally have the following problem with a database: 02/07/20 11:51:44 rowalter: PTOCOPYVC: collen (0xb4) > max_vc_len (0x33) (cmpoff: 0x22, uncmpoff 0x22 02/07/20 11:51:44 Assert Failed: physical_scan: decompress_row, source = 0x53c48174, target = 0x5a019018 02/07/20 11:51:44 IBM Informix Dynamic Server Version 12.10.UC4W1 02/07/20 11:51:44 Who: Session(3430799, jbosscod@srvms1appserver.intern.westfleisch.de ,-1, 0x577c7c50) Thread(3435541, sqlexec, 4eb69b58, 8) File: rsseqscan.c Line: 1237 02/07/20 11:51:44 Results: Record not read 02/07/20 11:51:44 Action: Please notify IBM Informix Techical Support. 02/07/20 11:51:44 stack trace for pid 14419 written to /opt/informix/tmp/af.6ffd4129 02/07/20 11:51:44 See Also: /opt/informix/tmp/af.6ffd4129 02/07/20 11:51:48 uncompress_row: Column data length exceeds the maximum length 02/07/20 11:51:48 physical_scan: decompress_row, source = 0x53c48174, target = 0x5a019018 Not always, but the error message also caused the database to crash. Does anyone have any experience with it. Thanks in advance for hints Greeting Heinz ------------------------------ Heinz Weitkamp ------------------------------ #Informix
Heinz, whatever column in the table has a length of 0xb4 (probably a varchar) it may have a problem with the row versioning if the table was altered in the past or it's a defect with decompress . Examine the af.xxxx file and look to see if it identifies the table or look for the session id 3430799 in the file and that should reveal the table name Best bet is to open a ticket with support or reorg the table (which is probably quicker) if you can manage to select all data from it. ------Original Message------ Hi there, operating system: SUSE Linux Enterprise Server 11 (x86_64) VERSION = 11 PATCHLEVEL = 4 We occasionally have the following problem with a database: 02/07/20 11:51:44 rowalter: PTOCOPYVC: collen (0xb4) > max_vc_len (0x33) (cmpoff: 0x22, uncmpoff 0x22 02/07/20 11:51:44 Assert Failed: physical_scan: decompress_row, source = 0x53c48174, target = 0x5a019018 02/07/20 11:51:44 IBM Informix Dynamic Server Version 12.10.UC4W1 02/07/20 11:51:44 Who: Session(3430799, jbosscod@srvms1appserver.intern.westfleisch.de ,-1, 0x577c7c50) Thread(3435541, sqlexec, 4eb69b58, 8) File: rsseqscan.c Line: 1237 02/07/20 11:51:44 Results: Record not read 02/07/20 11:51:44 Action: Please notify IBM Informix Techical Support. 02/07/20 11:51:44 stack trace for pid 14419 written to /opt/informix/tmp/af.6ffd4129 02/07/20 11:51:44 See Also: /opt/informix/tmp/af.6ffd4129 02/07/20 11:51:48 uncompress_row: Column data length exceeds the maximum length 02/07/20 11:51:48 physical_scan: decompress_row, source = 0x53c48174, target = 0x5a019018 Not always, but the error message also caused the database to crash. Does anyone have any experience with it. Thanks in advance for hints Greeting Heinz ------------------------------ Heinz Weitkamp ------------------------------ #Informix
Hello Heinz, This problem is probably a defect of informix. It looks similar to what is described in the APAR below. Commonly, Informix 12.10.xC4 and below are in use and last commited function is enabled. In this state, AF occurs when an alter operation is performed on a compressed or uncompressed table. IT04586: ASSERT FAILED: PHYSICAL_SCAN: DECOMPRESS_ROW, SOURCE = 0XXXXXXXX X, TARGET = 0XXXXXXXXX WHEN USELASTCOMMITTED "ALL" , COMPRESSION https://www-01.ibm.com/support/docview.wss?uid=swg1IT04586 IT03514: ASSERT FAILED ROWALTER: PTOCOPYVC: COLLEN (X) > MAX_VC_LEN (Y) FOLLOWED BY ASSERT FAILED PHYSICAL_SCAN: DECOMPRESS_ROW https://www-01.ibm.com/support/docview.wss?uid=swg1IT03514 If possible, I would recommend Informix to apply patch 12.10.xC5 or higher. In this case, of course, it is recommended to ask IBM to open the case. If that's hard to do, you might need to migrate your data to a new table. ------------------------------ SangGyu Jeong Software Engineer Infrasoft Seoul Korea, Republic of ------------------------------
Hello Mark, many thanks for your response. I will review your tips on what is possible for me. Greetings Heinz WESTFLEISCH SCE mit beschränkter Haftung, Hauptsitz: Brockhoffstr. 11, 48143 Münster Amtsgericht Münster: Gen.-Reg. 448 Aufsichtsratsvorsitzender: Josef Lehmenkühler Vorstand: Dirk Niederstucke (Vorsitzender); Peter Piekenbrock; Gerhard Meierzuherde; Carsten Schruck, Johannes Steinhoff, Steen Sönnichsen (Geschäftsführer) ------Original Message------ Heinz, whatever column in the table has a length of 0xb4 (probably a varchar) it may have a problem with the row versioning if the table was altered in the past or it's a defect with decompress . Examine the af.xxxx file and look to see if it identifies the table or look for the session id 3430799 in the file and that should reveal the table name Best bet is to open a ticket with support or reorg the table (which is probably quicker) if you can manage to select all data from it. #Informix