Re: Long Transaction Aborted / Happy Ideas Required

Actually a long transaction can happen in two ways: a) You do a begin work in dbaccess and forget about the session b) Actual work is causing the long transaction ... For situation a) you can add as many logs as you want but you cannot remove the long transaction, you would merely delay it by adding the logs ... Best way to find out which transaction is causing it is looking at onstat -x output ..(in the online log, you will find a transaction address when the long transaction message is written), you can now do a grep in the onstat -x output for that ... you will get a line having two hex valuessome flags and the type of transaction ... the second hex value is the rstcb address ..take that address and grep it out of onstat -u output ..this way you can find which session is causing the problem ...onstat -g ses/sql <sess_id> will give you the SQL. You can also find the transaction from the logical log file (do a onlog -n <last log id> ) and do a grep for CKPOINT ..the CKPOINT record should hold the OPEN TRANSACTION IDs and tell you from which log file it was started ..you can do a onlog output of that log and find out what that transaction did ... HTH Thanx much, Rajib Sarkar Advisory Support Engineer(Wells Fargo Bank) IBM Software Group -- Data Management Ph: 602-2172100, Fax: 602-2172100 www.ibm.com/software "Jose Luis Illera" To: "Informix General List" <informix-list@iiug.org> <illeraj@grupocp. cc: es> Subject: Long Transaction Aborted / Happy Ideas Required Sent by: owner-informix-li st@iiug.org 06/04/2002 02:16 AM Good morning friends, Is there a way to evaluate the logical-log space needed by a server beeing used by some applications, apart from a progressive growing/testing process???? The problem is I can't access directly to that server, so I have to suggest the operations to the customer and sit on my seat hand over hand expecting the results, without knowing exactly what they are doing. I hate this kind of situation but theese are the nowaday conditions. Up to now, I've sended them a document explaining the steps to increase the number of logical-logs, gave him a minimal space required based on the characteristics of our application, and suggested an iterative program of ten per cent growings. The first ampliation was not sufficient, and I've required them to send me the output of onstat -l and onstat -b to evaluate their configuration, but may I suggest them any operation able to catch the SQL which is producing the problem??. I know there must be an individual SQL because the app doesn't have explicit transactions in the program area involved in the problem. From evaluating the results of such an SQL I could be able to find the app specific log-space required, based on the number and size of records involved. Any other ideas? Thanks. Jose Luis. sending to informix-list

Rajib Sarkar wrote: > Actually a long transaction can happen in two ways: > a) You do a begin work in dbaccess and forget about the session > b) Actual work is causing the long transaction ... > < Snipped> For a. to cause a long transaction you would have to actually do some work, and not just do a "begin work;" e.g. begin work; update customer set fname = "Mashed" where customer_num = 101; This behaviour has been in place for quite a while now. TBP