Re: what is holding the log in this session
Ok, duh. onstat -x tells me stuff. I'm not used to using it because our
main database is not logged.
Anyway, according to this output of onstat -x |grep userthread address,
there is no transaction, and no log where it began. So maybe this time it
wouldn't give a long transaction. I don't intend to find out because I
will ensure our logs don't get to the 45% mark before this darn job
finishes. I wish I would've thought to use the onstat -x command before.
Unless there is some bug we're running into.
7000002a22bdee8 A---- 7000002a228ad30 3 0 0 0x0
NOTRANS 0
----- Original Message -----
Subject: Re: what is holding the log in this session
Date: Mon, March 3, 2008 8:34
From: "Superboer" <superboer7@t-online.de>
wild guess... hmmm could be that it is extending extents of a table/
> index....
>
> only thing i can think of is make sure that the initial/next extent
> size is properly set...
> you may have to do a onstat -lx and search for the log where the trx
> began.
>
>
>
> Superboer
>
> way fast=http://www.clipjes.nl/clip/nederlands/n/normaal_-
> _oerend_hard.html
>
> On 3 mrt, 13:57, "Floyd Wellershaus" <fl...@fwellers.com> wrote:
> > I have a session that is running stuff from ec code in an ids10 non
logged
> database. I know that at the beginning of the program, some indexes are
created,
> and lots of inserts happen to a table.
> > This is a batch process that takes over 24 hours to run. It has
continued to abort
> with long transaction.
> >
> > So I have added more logs and am watching it. It is not actually
filling the logs,
> other processes are, but what I want to know is, what thing is causing a
log to
> act like this transaction is going on, that keeps this whole process
tied to that
> log ?
> >
> > Are there any onstats I can do to look in the logs or anyway find out
what is
> happening here ?
> > I really can't make heads or tails out of onlog to be able to tie it
to a sid or
> see if it's an open transaction etc..
> >
> > Thanks for your advice.
> >
> > Floyd
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
> wouldn't give a long transaction. I don't intend to find out because I
> will ensure our logs don't get to the 45% mark before this darn job
That sounds good! can it be that your table(s) have the proper extend
size now??
> I understand that DDL has to be logged, but once it's logged, why would it
> hold onto the log as an uncommitted transaction ?
an example on an instance with say 6 log logs of 1 MB each:
dbaccessdemo7 <<!
N
!
dbaccess stores_demo <<
create table tessie
(
customer_num int,
fname char(15),
lname char(15),
company char(20),
address1 char(20),
address2 char(20),
city char(15),
state char(2),
zipcode char(5),
phone char(2000)
);
insert into tessieselect a.*
from
customer a ,
customer b ,
customer c ,
customer d
!
will get a long trx rollback....
in the past: if you created the table and gave it the proper extend
size but did not
force a checkpoint you still would get a long trx rollback....may be
still today??
so size your table do a checkpoint and you would probably... not see
this.
Superboer
way fast=http://www.clipjes.nl/clip/nederlands/n/normaal_-
_oerend_hard.html