Thanks for your responses. The application is a mixture of mainly old and a few new programs. Some of the new programs do use Begin Transaction, Commit, End Transaction etc, but the vast majority do not. We use a number of SQL select statements, but very few SQL update statements.
Files are copied between file systems at the Linux level to create a training account from the production account, but when that is done, the transaction logging information in the file header is overwritten using WRITEBLK in a BASIC program. (To remove this in production prior to taking a snapshot would present a major issue due to the timing and increased complexity of creating backup snapshots. The copy is always done from a snapshot taken when UniVerse is shut down,) We have over 5000 programs and over 1000 data files. This makes any attempt to resolve the cause of a log file staying in a NeedSync state more difficult. We would also appreciate it if someone could provide documentation on how to decode the status of transactions from the log files. This may allow us to develop some diagnostic tools. The facilities that come with uniVerse seem very limited (primitive) compared to Oracle/SQL Server tools. We usually have approximately 2400 available log files, each of which is 2 Meg in size. This does give us a reasonably large margin, (just under 5 Gig). Daily updates to transaction log files can vary between about 2 Gig up to 15 Gig in a 24 hour period. We are also reliant on the log files re-cycling properly to send full log files to a DR site. The only method where we have been able to duplicate the problem at will on a development server is to write a program that updates records within a transaction, and has an input statement before the commit. We then killed the process at the Linux level (kill -9). On examining the uvdeadlock.log we could see the record locks being cleaned up. This evidence is not visible in production, although there is evidence a process may have been cleared up within the likely timeframe for the error. The "uvchkd.info" file contained many messages like "Fri Mar 23 21:54:02 2007: (Info) Log file 90563 has 4 pending transaction(s)." Unfortunately there seems to be no way to identify the user, key or file(s) involved. This makes further investigation difficult. We have some indication in the past that defunct sessions may have had some impact but could not locate any such in the latest case. Sara Burns (SEB) IS Development Manager Public Trust Phone: +64 (04) 978 4534 (DDI) Mobile: 029 978 4534 <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > The information contained in this communication (including any attachment) is confidential. If you are not the intended recipient, please destroy this communication. You must not disclose, copy or use in any way the information contained in this communication. Any views expressed in this communication are not necessarily the views of Public Trust. No representation is made that this communication is free of error, virus or interference. . ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
