Same kind of problem as with indexes.( I.e, the path to the index is part of the file header. If the primary data file is copied, the duplicate is still indexing on the old index until you use SET.INDEX to correct it.I think there's a UV enhancement request for allowing index pathnames to be relative instead of absolute path.)
Which brings us to a need for a tool to verify & possibly correct the log numbers in UV.TRANS and the UV.TRANS id (info buried in the file headers themselves.) There is a need for flexability, especially after some kind of disaster and file systems are being rebuilt. There is a enhancement request in the works on this too. cds -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Perry Taylor Sent: Monday, March 26, 2007 11:41 AM To: [email protected] Subject: RE: [U2] UV - Transaction Logging - Stale Transactions Sara, We had occasional instances of this in the past. We finally tracked the cause down to one of our developers copying transaction logging-enabled files between servers without disabling them first. Not sure if this is happening in your case. Hope this helps. Perry -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stevenson, Charles Sent: Monday, March 26, 2007 1:26 PM To: [email protected] Subject: RE: [U2] UV - Transaction Logging - Stale Transactions Are you using logical transactions? I.e., basic TRANSACTION START/COMMIT? Or SQL SELECT? That will automatically start a transaction (on 10.0.16 anyway) and hold it open until the SELECT ends, even tho no updates occur. If logs fill while a logical transaction is in process, the log will remain in NeedSynch state. That's my 1st guess. Cds -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sara Burns Sent: Sunday, March 25, 2007 4:19 PM To: [email protected] Subject: [U2] UV - Transaction Logging - Stale Transactions Late last year we upgraded from UV 10.0.11 on AIX to UV 10.1.16 on Red Hat Linux. At the same time we implemented Transaction Logging. We have a dispersed network with users throughout the country at about 40 sites using VOIP for our data and voice transmission. These sessions do sometimes get dropped due to network glitches and users do sometimes terminate their sessions without logging off correctly. All has gone reasonably smoothly but we are finding that we sometimes get Stale Transactions. This means that all subsequent transaction logs are in the NeedSync state and the Available log files may be exhausted - at which stage everything stops. We have now got a large pool of log files available. Does anyone have any hints to investigate what is causing the Stale Transaction so that it can be corrected so all logs can be Released ready for reuse. We have found that on at least one occasion they did free themselves but we usually require a restart of UniVerse to get the process working again. We do have a scheduled restart at midnight while we obtain a snapshot. This is obviously releasing something we cannot see. It would be preferable to be able to remove the cause so a consistent set of logs can be created as these are also sent to our DR site. The manual indicates that when you re-enable transaction logging you will be asked if you wish to terminate pending (prepared) stale transactions. In our case we now have so many log files the process has not stopped. Due to our many dependant systems, internal and external, it is undesirable to Disable the Transaction Logging system during active use. This would be a last resort. In the latest episode there were no entries in the lock tables, no semaphores set and we cleaned out every process we could find that was not us or the various uv daemons. Any suggestions would be appreciated. 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/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. ZirMed, Inc. has strict policies regarding the content of e-mail communications, specifically Protected Health Information, any communications containing such material will be returned to the originating party with such advisement noted. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. ------- 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/
