Resolved Replication Error: (11125) Rlrecordgetlockmanage Error

[bob]

Hi,

HP-UX B.11.31
OpenEdge 10.2B

I'm doing some testing with OpenEdge Replication Plus at the moment.
I'm getting the errors shown below in the target database log file when the source tries to write to it.

The background to the problem is as follows:

1. As part of a testing process, we shutdown the source and target databases
2. Took backups of the source and target with probkup
   
3. Disabled replication on the target with: proutil DBNAME –C disablesitereplication target
4. Ran some updates on the target database.
5. Restored the backup of the target databases from step 2
6. Restarted the source and target databases

I ran the same tests yesterday and everything worked just fine, so I really don't get why this is happening:

(10404) SYSTEM ERROR: rlRecordGetLockManage error:  encountered unexpected end logical operation for trid 1866751589 recid 446855431 logicalOpId 7
(11125) rlRecordGetLockManage error: Unable to add lock info to rgl table trid: 1866751589 table 12 dbkey 446855429,dbkey> logOpId 8
(10428) Function dsaAIApplyNote failed in rpNOT_ProcessNoteBlock with error -1.
(-----) Diagnostic Dump of RLAIRollFState_t - After Apply Failure
(-----) 0000:  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 0101 0001 0200 0001 0000
(-----) 0020:  0000 0000 131a 9397 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
(-----) 0040:  0000 0000 0000 0000 0000 0000 0000 0000
(-----) Diagnostic Dump of RPAIBlock_t - After Apply Failure
(-----) 0000:  0000 2000 0000 0000 0000 0011 0000 0076 0000 0000 09dd a000 0000 0000 0000 0000
(-----) 0020:  0000 0000 0000 4eed 0000 0000 8faf 0018 2000 0000 0000 0000 0000 0000 0000 0000
(-----) 0040:  0000 0000 0000 0000 0000 0000 0000 0000
(-----) Diagnostic Dump of RPNote_t - After Apply Failure
(-----) 0000:  0000 0257 0000 003a 0000 0002 0000 003a 0000 0000 0000 0000 0000 0011 0000 0076
(-----) 0020:  0000 0000 09dd a000 0000 0000 0000 0000 0000 0000 0000 4eed 0000 0000 0000 7d08
(-----) 0040:  0000 0038 0002 003c 4600 0000 0000 0000 6000 0000 000c 76c0
(10495) Block processing ended in error at block 20205 in area 17.  Fathom Replication cannot continue.
(-----) Diagnostic Dump of RPAIBlock_t - Block processing error
(-----) 0000:  0000 2000 0000 0000 0000 0011 0000 0076 0000 0000 09dd a000 0000 0000 0000 0000
(-----) 0020:  0000 0000 0000 4eed 0000 0000 8faf 0018 2000 0000 0000 0000 0000 0000 0000 0000
(-----) 0040:  0000 0000 0000 0000 0000 0000 0000 0000
(10504) Unexpected error -1 returned to function rpAGT_AgentLoop.
(10506) The Fathom Replication Agent REPTST is ending.

Thanks for your help.

 

[TheMadDBA]

What are you are trying to do is very much not supported by OpenEdge Replication. If you so much as sneeze on the target database you are recreating it from source again.

It might be possible to do this with OS copies of the databases for before and after testing, but I would never try and do that for production use.

Progress KB - Replication synchronization fails after transitioning a source database to become a target database

 

[Rob Fitzpatrick]

It would be helpful to know your service pack, as lots of Replication bugs have been fixed in various SPs during the life of 10.2B.

I agree with TheMadDBA. I don't think your target DB is a valid replication target anymore. Probkup crash recovery would have altered it from its original state.

 

[bob]

Thanks for getting back to me everyone. I'll look into a different approach for the test we're doing.
Rob, we're running 10.2B01 at the moment.

 

[TomBascom]

If you are on 10.2 you should have service pack 8. Don't fool yourself into thinking that anything less is ok.

 

[Rob Fitzpatrick]

If you are on 10.2 you should have service pack 8.

Agreed. There have been lots of OE Repl fixes in 10.2B service packs.

Also, SP01 has a nasty probkup online bug that eventually uses up all of your _Connect records and requires a DB restart before more users can connect.

 

[bob]

Thanks. I'm going to recommend upgrading to the latest Service Pack as soon as possible.

 

[bob]

What are you are trying to do is very much not supported by OpenEdge Replication. If you so much as sneeze on the target database you are recreating it from source again.

It might be possible to do this with OS copies of the databases for before and after testing, but I would never try and do that for production use.

Progress KB - Replication synchronization fails after transitioning a source database to become a target database

I tried the OS-Copy, but Progress gave me error (888) regarding timestamp mismatches when I tried to restart the database.
Anyway, I think I'll try a different approach for these tests. Thanks again for your help.