× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



No, that's the big difference in IBM i. It's always live statistics. If you build indexes, the statistics (like column cardinality) is picked up at build, but stay live during the existence of said indexes.

RGZPFM only removes deleted records and may order the table physically to reflect a particular index, but that does not affect statistics.

On 04/19/2010 11:51 AM, Ryan Hunt wrote:
yes, the RUNSTATS type of functionality was what I was looking for. I'm
curious about your comments on indexes as this had been another route I was
looking into. In the land of MS SQL index builds/rebuilds will ALSO rebuild
the histograms (statistics) at the table level to relfect what the optimizer
built during the index creation/rebuild.

Any chance DB2/400 does this too and an RGZPFM on my largest tables will
indirectly build the stats I am looking for?

Thanks

Ryan

"Bruce Hoffman"
<bruce.hoffman@xxxxxxxxxxxxxxxxx> wrote in
message news:4BCC78D9.10300@xxxxxxxxxxxxxxxxxxxx
If you are talking about something like RUNSTATS on other Databases and
DB2's... not really.

The statistics on DB2 for i are live, all the time. The OS and DB2
engine control statistics collection on IBM i. Statistics are usually
collected on a when used basis. You can see this it the way that the SQE
handles the first few requests against an unindexed table, building
temporary (but system-wide) indexes once the optimizer decides that this
table might be used more than once or twice.

That being said, you can have some influence over statistics collection
at the table level using Client Access for i and through the use of
indexes (particularly EVI's).

On 04/19/2010 08:35 AM, Ryan Hunt wrote:
We are working on a new JDE install and the process involves a lot of
copying our main business data libraries from a prod LPAR to a test
LPAR,
running conversion scripts, and engaging in CRP testing. One thing I've
noticed is that the QDBFSTCCOL job generates a lot of activity once
users
get onto the system and try to use it. I think this probably makes
sense,
maybe the stats get abondoned during a RSTLIB on a library from a
foreign
system...or maybe it's the conversion scripts. Either way, the system
behaves like there are next to no stats once the queries start coming
in.

Anyway, I'm curious if there is a way to force statistics collections on
large business data libraries after the RSTLIB, data conversion
activies,
etc.

Thanks. RH




--
"When I die, I want to die like my grandmother who died peacefully
in her sleep. Not screaming like all the passengers in her car."
- Author Unknown

===========================================================
R Bruce Hoffman

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email:
MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.







As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.