We've had some good successes with the Universal Driver Heavy, including my own personal favourite - installing it on an AREV 2.12 site despite the warnings on the tin! It took a bit of tweaking but we got there.
Anyways on two separate sites recently we needed to replay the journal files to bring the secondary server back up to synchronicity with the primary server and on both of these sites the process would fail, resulting in us having to copy the secondary from the primary - thus rather removing the point of having the UDH in the first place.
We'd start the UDH and launch the manager to instruct the service to go into mirroring and it would happily start chugging along doing something - perfmon showed a lot of I/O and CPU activity associated with the LH31SRVC.EXE so we were confident that it was trying to do something, but after a short while the LH Manager would start to display REV_LOADREC errors and crash. Now we well knew that this meant that the LH Manager could not contact the service and sure enough the service was no longer in memory but it had exited so cleanly that there were no reports of errors in the UD Log OR the Event Log.
Given the complete lack of available diagnostic information we were initially stumped until the idea of running the service in debug mode was mooted. So opening a command prompt we changed to the UDH directory and executed LH31SRVC.EXE -debug.
The service started reading through the journal files and optmising them. The numbers crept up, 10, 20, 30, 40 and then at 44 the UDH just abended. Well, exited is probably more accurate as there were no errors to speak of. It would seem that something in the 44th file was causing problems for the UDH.
Revelation are understandably keen to ensure that the UDH is as stable as possible so the files were mailed to Revelation who tested them on the latest 4.6 build of the UDH (after writing a utility to make the journal files the correct format) and discovered the same error. At this point they lept into sleuth mode and within hours were able to declare that the UDH replay had some fairly fatal problems when row id length exceeded 512 bytes!
Now given that the maxiumum row id size has been documented as 50 characters we were surprised by this strangely excessive row id length, but the fix was confirmed and in future releases of the LH driver a maximum row id length of 512 bytes will be enforced - attempts to write with a longer id will cause the ELSE branch of the write to trigger.
Mind you these investigations did trigger an interesting discovery. Given that the maximum row id size was 50 bytes, the system verify routines would report a GFE if any such row ids were encountered. So if you've ever had a mysterious GFE which didn't seem to be there then check the size of your row ids! We had to develop a routine to do such a thing but that's a subject for another blog post!
Anyways on two separate sites recently we needed to replay the journal files to bring the secondary server back up to synchronicity with the primary server and on both of these sites the process would fail, resulting in us having to copy the secondary from the primary - thus rather removing the point of having the UDH in the first place.
We'd start the UDH and launch the manager to instruct the service to go into mirroring and it would happily start chugging along doing something - perfmon showed a lot of I/O and CPU activity associated with the LH31SRVC.EXE so we were confident that it was trying to do something, but after a short while the LH Manager would start to display REV_LOADREC errors and crash. Now we well knew that this meant that the LH Manager could not contact the service and sure enough the service was no longer in memory but it had exited so cleanly that there were no reports of errors in the UD Log OR the Event Log.
Given the complete lack of available diagnostic information we were initially stumped until the idea of running the service in debug mode was mooted. So opening a command prompt we changed to the UDH directory and executed LH31SRVC.EXE -debug.
The service started reading through the journal files and optmising them. The numbers crept up, 10, 20, 30, 40 and then at 44 the UDH just abended. Well, exited is probably more accurate as there were no errors to speak of. It would seem that something in the 44th file was causing problems for the UDH.
Revelation are understandably keen to ensure that the UDH is as stable as possible so the files were mailed to Revelation who tested them on the latest 4.6 build of the UDH (after writing a utility to make the journal files the correct format) and discovered the same error. At this point they lept into sleuth mode and within hours were able to declare that the UDH replay had some fairly fatal problems when row id length exceeded 512 bytes!
Now given that the maxiumum row id size has been documented as 50 characters we were surprised by this strangely excessive row id length, but the fix was confirmed and in future releases of the LH driver a maximum row id length of 512 bytes will be enforced - attempts to write with a longer id will cause the ELSE branch of the write to trigger.
Mind you these investigations did trigger an interesting discovery. Given that the maximum row id size was 50 bytes, the system verify routines would report a GFE if any such row ids were encountered. So if you've ever had a mysterious GFE which didn't seem to be there then check the size of your row ids! We had to develop a routine to do such a thing but that's a subject for another blog post!
Labels: UDH, Universal Driver Heavy
| Making Databases Happen |
USA +1 267 238 3814
|
0 Comments:
Post a Comment
Subscribe to Post Comments [Atom]
<< Home