Hi Sara, Have you asked this of the "askus" address for U2 ? Or IBM support?
I'm not aware of any documentation of the status of transactions; that's why none appears in the UniVerse Internals class. It might be no bad idea to ask Leroy Dreyfuss (advanced technical support) directly. I think he still lurks here, but just in case I'm copying him on this email so he'll believe you when you say that I suggested that you contact him. He's been very helpful to me in the past, and was primarily responsible for "blue-washing" the internals class. Sorry I can't help, I'm on the road (as usual), currently in Dallas (Texas), next week in Vancouver. Regards, Ray > ----- Original Message ----- > From: "Sara Burns" <[EMAIL PROTECTED]> > To: [email protected] > Subject: RE: [U2] UV - Transaction Logging - Stale Transactions > Date: Tue, 27 Mar 2007 22:46:08 +1200 > > > 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/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
