Re: DD_HASHSIZE , DD_HASHMAX
Well it's been a while since I used v7, but it looks like a couple of columns are missing.
However given the header for an onstat -g dic
list# size refcnt dirty? heapptr table name
I'm going to presume the first colum in your example is actually the refcnt.
In that case, it appears that all of the entries below are marked as dirty, being marked dirty that means that they are candidates for removal from the cache as soon as the refcnt is 0. Therin lies the problem, most of entries below have relatively high refcnt entries. what does an onstat -g ses |wc -l return? It's looking like you have an application, or group of applications, that are staying attached to the database, but never closing cursors.
The other mystery though is what is causing the entries to be marked dirty in the first place? Being marked dirty indicates that IDS has determined the entry in question is no longer valid. I would highly recommend you contact IBM Technical support and open a case on this.
----- Original Message ----
From: "tichman@excite.com" <tichman@excite.com>
To: informix-list@iiug.org
Sent: Tuesday, January 16, 2007 10:58:12 AM
Subject: Re: DD_HASHSIZE , DD_HASHMAX
Mark,
the table xxacct is cached moer than once in this extract.
Thanks
426 yes 95e02820 xxx@xxxshm:xxxx.xxacct
147 yes 9f220680 xxx@xxxshm:xxxx.xxacct
12 yes b0df9820 xxx@xxxshm:xxxx.xxcattr
1 yes ce4e2020 xxx@xxxshm:xxxx.xxpecl
9 yes b9414020 xxx@xxxshm:xxxx.xxdraw
30 yes 89383820 xxx@xxxshm:xxxx.xxcust
301 yes b0654820 xxx@xxxshm:xxxx.xxacct
114 yes 833e1c20 xxx@xxxshm:xxxx.xxacct
2 yes 9f335020 xxx@xxxshm:xxxx.xxcattr
96 yes 6fb19420 xxx@xxxshm:xxxx.xxtacc
10 yes bb61a020 xxx@xxxshm:xxxx.xxcust
25 yes 9f220ec0 xxx@xxxshm:xxxx.xxacct
2 yes b22813f8 xxx@xxxshm:xxxx.xxacct
7 yes 865ba020 xxx@xxxshm:xxxx.xxacct
17 yes 8cdccc20 xxx@xxxshm:xxxx.xxacct
1 yes b5744020 xxx@xxxshm:xxxx.xxacct
21 yes 97da0420 xxx@xxxshm:xxxx.xxterms
21 yes 98e0a020 xxx@xxxshm:xxxx.xxend
8 yes 81446c20 xxx@xxxshm:xxxx.xxacct
2 yes 8b941020 xxx@xxxshm:xxxx.xxacct
12 yes a9974c20 xxx@xxxshm:xxxx.xxacct
1 yes 778eec20 xxx@xxxshm:xxxx.xxacct
1 yes 760e5020 xxx@xxxshm:xxxx.xxhist
1 yes a6ec5020 xxx@xxxshm:xxxx.xxterms
3 yes a1e60020 xxx@xxxshm:xxxx.xxend
33 yes c2edb020 xxx@xxxshm:xxxx.xxacct
Mark Jamison wrote:
> Could you shoot a small portion of the onstat -g dic output where you are seeing duplicates?
>
> Thanks much
>
>
> ----- Original Message ----
> From: "tichman@excite.com" <tichman@excite.com>
> To: informix-list@iiug.org
> Sent: Tuesday, January 16, 2007 10:02:21 AM
> Subject: Re: DD_HASHSIZE , DD_HASHMAX
>
> We have two databases on the instance but all the tables in onstat -g
> dic show that they are from one DB. We do not perform any remote
> queries and the instance has been up for 11 days. For some reason it
> seems to be adding more duplicates to the list even though none of the
> duplicated tables is being altered in any way.
>
> Mark Jamison wrote:
> > A few questions.
> >
> > #1 How many Databases do you have in the instance.
> >
> > #2 Do you perform any remote queries to other instances from the instance.
> >
> > #3 How long has the instance been up.
> >
> >
> > Multiple copies of the same table usually indicates that you have multiple versions of the table, and applications still have cursors attached against them, for example if you have run an alter table. Now those App's should be getting 710 errors, but until those applications actually end, the refcount for the DD entry will still be set to 1, or greater, which means the DD Entry cannot be cleaned out of the cache. I haven't tested the impact of an in-place alter though.
> >
> >
> > ----- Original Message ----
> > From: "tichman@excite.com" <tichman@excite.com>
> > To: informix-list@iiug.org
> > Sent: Monday, January 15, 2007 6:39:20 AM
> > Subject: DD_HASHSIZE , DD_HASHMAX
> >
> > We are running 7.31.UD3 on Solaris 5.9.I am investigating the optimal
> > setting DD_HASHSIZE and DD_HASHMAX. Currenlty they are set at the
> > default (31 and 10).We have approximately 430 tables in the database
> > but when we run onstat -g dic I get 2400 data dictionary entries which
> > seems very high to me. I then noticed that there are multiple entries
> > for some of the tables in the onstat -g dic output. Is this normal?
> >
> > _______________________________________________
> > Informix-list mailing list
> > Informix-list@iiug.org
> > http://www.iiug.org/mailman/listinfo/informix-list
> >
> >
> >
> >
> >
> > --0-1394698818-1168958768=:58071
> > Content-Type: text/html; charset=ascii
> > Content-Transfer-Encoding: quoted-printable
> > X-Google-AttachSize: 2029
> >
> > <html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt">A few questions.<br><br>#1 How many Databases do you have in the instance.<br><br>#2 Do you perform any remote queries to other instances from the instance.<br><br>#3 How long has the instance been up.<br><br><br>Multiple copies of the same table usually indicates that you have multiple versions of the table, and applications still have cursors attached against them, for example if you have run an alter table. Now those App's should be getting 710 errors, but until those applications actually end, the refcount for the DD entry will still be set to 1, or greater, which means the DD Entry cannot be cleaned out of the cache. I haven't tested the impact of an in-place alter though.<br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;"><br><br><div style="font-family: times
ne
w
> > roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: "tichman@excite.com" <tichman@excite.com><br>To: informix-list@iiug.org<br>Sent: Monday, January 15, 2007 6:39:20 AM<br>Subject: DD_HASHSIZE , DD_HASHMAX<br><br><div>We are running 7.31.UD3 on Solaris 5.9.I am investigating the optimal<br>setting DD_HASHSIZE and DD_HASHMAX. Currenlty they are set at the<br>default (31 and 10).We have approximately 430 tables in the database<br>but when we run onstat -g dic I get 2400 data dictionary entries which<br>seems very high to me. I then noticed that there are multiple entries<br>for some of the tables in the onstat -g dic output. Is this normal?<br><br>_______________________________________________<br>Informix-list mailing list<br>Informix-list@iiug.org<br><a target="_blank" href="http://www.iiug.org/mailman/listinfo/informix-list">http://www.iiug.org/mailman/listinfo/informix-list</a><br></div></div><br></div></div></body></html>;
> > --0-1394698818-1168958768=:58071--
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list
>
>
>
>
>
> --0-545152270-1168964260=:96334
> Content-Type: text/html; charset=ascii