Forced traces U00003516 UCUDB: ... function 'DELETE' = '0'
Article ID: 258906
Updated On:
Products
Issue/Introduction
After zero downtime upgrade from 12.3.2 to 12.3.9 HF2, there are forced traces once or twice a day. The logs show this:
20221216/010304.248 - U00015006 System forced memory trace dump.
20221216/010304.249 - U00015006 System forced memory trace dump.
20221216/010304.250 - U00003631 Dump caused by:
20221216/010304.250 - U00003516 UCUDB: Affected lines in function 'DELETE' = '0'
20221216/010304.250 - U00011801 Error in Server routine 'JPEXEC_R', Server: 'PROD#WP020' AE system: 'PROD'.
Is there any impact to this?
Environment
Release : 12.3.9 HF2
Resolution
Turn on a database=4, tcp/ip=2 and looking at the WP traces:
The hangup is coming on this statement that WP4 tried to run:
20221220/211707.084 - U00009909 TRACE: (BINDPAR: EH_AH_Idnr 0x7f99fe415c9c 00004
00000000 F49A1B62 >ôš.b<
20221220/211707.084 - >1645976308<
20221220/211707.084 - U00009909 TRACE: (BINDPAR: ROWID 0x7f99f9402bc0 00018
00000000 4141414A 5A704143 44414142 534F4A41 >AAAJZpACDAABSOJA<
00000010 414A >AJ<
20221220/211707.084 - DELETE FROM EH WHERE EH_AH_Idnr = ? AND ROWID=?
20221220/211707.085 - UCUDB32 DLTE RET 3516 HSTMT: 0x00000002ace070 VALUE: (nil) ALL: 0.00106 DB: 0.00090 ODBC: 0.00001 UDB: 0.00016
The RET 3516 corresponds as well with the U code for the error message:
20221220/211707.097 - U00003516 UCUDB: Affected lines in function 'DELETE' = '0'
In this case, the customer chose not to further troubleshoot this for RCA or possible bug as 12.3 is out of maintenance and they'll be updating to 21.0 soon.
There should be no impact with this 'DELETE' = '0' forced trace except that the trace file is created. For some reason the record is having a delete tried twice in the same transaction and the record doesn't exist. There is no impact to logic or processing.
Feedback
