IDS on HP-UX ia64

Is anybody using IDS on HP-UX Itanium, particularly with EMC Clariion? Would ove to swap stories and compare notes. Please send me a private. thx N

It's IDS 10.0FC10W2 on HP-UX 11.23 ia64. Here's one of the issues I'm looking at: long-running UPDATE STATS. This index for example takes ages. It has only about 600,000 pages: cust_id, login_time(LOW)...SUCCESSFUL (3156.161 Secs) If I run it again immediately, ie without bouncing Informix: cust_id, login_time(LOW)...SUCCESSFUL (10.322 Secs) # 300 times faster!!!!! I can see from onstat -D that the second run did no page reads so this is clearly due to the IDS cache: the time zooms straight back up to 3,200-odd seconds if IDS is bounced. If i unload the table and create a copy: cust_id, login_time(LOW)...SUCCESSFUL (88.597 Secs) The index on the original is not *that* fragmented - takes up about 400,000 pages after rebuild as opposed to 600,000 before ... If I watch the UPDATE STATS I see it crawl on the original table but fly on the new one. I should add that for ages I've suspected a disk problem this platform. But if this is a disk, rather than Informix, problem it's one that allows an index scan on a recently-built index to fly, and an older one to crawl. Any thoughts? Thanks, Neil

The index may not be fragmented, but perhaps the table is! Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) See you at the 2010 IIUG Informix Conference April 25-28, 2010 Overland Park (Kansas City), KS www.iiug.org/conf Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Mon, Mar 8, 2010 at 6:37 PM, Neil Truby <neil.truby@ardenta.com> wrote: > It's IDS 10.0FC10W2 on HP-UX 11.23 ia64. > > Here's one of the issues I'm looking at: long-running UPDATE STATS. > > This index for example takes ages. It has only about 600,000 pages: > cust_id, login_time(LOW)...SUCCESSFUL (3156.161 Secs) > > If I run it again immediately, ie without bouncing Informix: > cust_id, login_time(LOW)...SUCCESSFUL (10.322 Secs) # 300 times > faster!!!!! > > I can see from onstat -D that the second run did no page reads so this is > clearly due to the IDS cache: the time zooms straight back up to 3,200-odd > seconds if IDS is bounced. > > If i unload the table and create a copy: > cust_id, login_time(LOW)...SUCCESSFUL (88.597 Secs) > > The index on the original is not *that* fragmented - takes up about 400,000 > pages after rebuild as opposed to 600,000 before ... > If I watch the UPDATE STATS I see it crawl on the original table but fly on > the new one. > > I should add that for ages I've suspected a disk problem this platform. > But if this is a disk, rather than Informix, problem it's one that allows > an > index scan on a recently-built index to fly, and an older one to crawl. > > Any thoughts? > > Thanks, Neil > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list >

"Art Kagel" <art.kagel@gmail.com> wrote in message news:mailman.6.1268095449.1071.informix-list@iiug.org... The index may not be fragmented, but perhaps the table is! It doesn;t appear to be, at least not from the oncheck: Before: Number of pages used 483601 Number of data pages 483481 Number of pages allocated 221507 After: Number of pages allocated 484032 Number of pages used 483602 Number of data pages 483482 In any case wouldn;t an UPDATE STATS (LOW) (as executed by dostats of course!) simply scan the indexes. I copied the table to another db using onunload/onload, sort of expecting this too to speed everything up, but in fact it retains the original speed ....

Hello Neil, i would try and rule out HP; try it on linux and see if you get the same results. NO FILESYSTEM please this may spoil your measurement due to filesystemcache!!! On hp i would monitor i/o since you bounce and slow.... sounds like that it is doing one page read a time or something. sar/iostat may give some light. When it is reading 1 page at a time (iostat/sar may tell this!!) the number of requests on a device may be as low as 200 600000/200=3000 secs which comes close to your observation. When that is the case you could open a case @ ibms and request that they make update stats low faster somehow.... How big is your buffer cache; i would rule bits and pieces out there too; eq decrease buffer cache so the whole index does not fit in there hmm make it real small say 1000 pages. then repeat the test; you'll probably get the same results... If raw and kaio then i would try and switch it off then check using top or??? maybe you will see a 100% waiting on i/o????. Superboer On 9 mrt, 01:51, "Neil Truby" <neil.tr...@ardenta.com> wrote: > "Art Kagel" <art.ka...@gmail.com> wrote in message > > news:mailman.6.1268095449.1071.informix-list@iiug.org... > The index may not be fragmented, but perhaps the table is! > > It doesn;t appear to be, at least not from the oncheck: > > Before: >    Number of pages used           483601 >    Number of data pages           483481 >    Number of pages allocated      221507 > > After: >    Number of pages allocated      484032 >    Number of pages used           483602 >    Number of data pages           483482 > > In any case wouldn;t an UPDATE STATS (LOW) (as executed by dostats of > course!) simply scan the indexes. > > I copied the table to another db using onunload/onload, sort of expecting > this too to speed everything up, but in fact it retains the original speed > ....