What exact version of TimesTen is this (ttVersion output please)? Also, prior to the error in the logs, do you see any messages indicating that the subscriber is retrying the ALTER TABLE operation (you may need to look in the message log rather than the error log to see those)?
The issue here is that this failure has been categorised as a 'permanent' error and as such replication reports it and then continues. i.e. it considers this operation 'finished'. Most locking errors are considered as 'transient' and will be retired several times (holding up the entire replication flow) before begin declared as 'failed' but it maybe we are not doing it for this case (which would be a bug).
Please provide the information I requested above and then we can see if this is a bug or not.
Following are the details required.
Timesten Version is
TimesTen Release 22.214.171.124.8 (64 bit Linux/x86_64) (kodiak:53388) 2012-11-19T10:01:17Z
Instance admin: root
Instance home directory: /opt/TimesTen/kodiak
Group owner: kodiakgroup
Daemon home directory: /var/TimesTen/kodiak
There is no message in receiver side regarding the retry of the operation. Please refer below ttmesg.log output from receiver side
2014-01-23 13:00:04.98 Info: : 12348: 30141 ------------------: process exited
2014-01-23 13:00:04.98 Info: : 12348: Finished daRecovery for pid 30141.
2014-01-23 13:00:11.58 Info: REP: 30007: DG_222221:receiver.c(8508): TT16193: Adding definition for table: DG.SUBS_LOC_SVC_INFO
2014-01-23 13:00:11.58 Info: REP: 30007: DG_222221:meta.c(6634):DG.SUBS_LOC_SVC_INFO ptn 0: srcoff 0, destoff 0, length 64
2014-01-23 13:00:11.58 Info: REP: 30007: DG_222221:receiver.c(8972): TT16203: Passed extended comparison for table DG.SUBS_LOC_SVC_INFO
2014-01-23 13:00:12.67 Err : REP: 30007: DG_222221:receiver.c(11832): TT16094: Failed to execute SQL: ALTER TABLE "DG"."SUBS_LOC_SVC_INFO" DROP ("LOC_REQ_EXPIRY")
2014-01-23 13:00:12.69 Err : REP: 30007: DG_222221:receiver.c(7100): TT16187: Transaction 1390083931/185874; Error: transient 0, permanent 1 state 2 error message :
2014-01-23 13:00:17.78 Info: : 12348: 19999/0x1cd4eb0: sbCmdCompAllDepsRemove(): Dependency list length high water: 228
2014-01-23 13:01:00.37 Info: SRV: 18937: EventID=37| Client protocol version 41 is not supported by this server, which uses version 36. Attempting to renegotiate protocol level.
2014-01-23 13:01:00.40 Info: : 12348: maind got #15538.103502, hello: pid=18937 type=library payload=%00%00%00%00 protocolID=TimesTen 126.96.36.199.8.kodiak ident=%00%00%00%00
Please help us to resolve this issue.
1 person found this helpful
Since this definitely looks like it is a bug you need to log an SR with support so they can do any further diagnosis required, log the bug and follow it through to resolution. There really isn't anything more we can do via the forum.
Can you please provide some link or documentation or list the transient errors for which timesten replication agent will re-try to apply multiply time and which are categorised as permanent error? Is that that timesten replication agent will never apply re-try mechanism for any of the permanent error received? For re-try what is the maximum number of attempt replication agent will try to apply the transaction?.
Thanks and Regards,
The information on error classification as regards transient versus permanent and the associated retry policy is not currently documented. Please log an SR and request this information via the SR.
What I can say is that for transient errors, if the error persists after the retry policy has been applied then it will be considered as permanent. For permanent errors the operation is logged and rejected and will never be re-tried.