RE: SQL vs. traditional I/O? -- MIDRANGE-L

It depends on what you want to test. I think Mark P. said it well - when doing regression testing, I guess I'd call it, you want to start from the same point. In this case, if you are comparing just how each engine works as a unit or component, you'd probably want to eliminate other variables. But that's only one kind of test. Another kind is what you ARE doing, which is repeated runs, to see what happens then. Even here, you might want to clear the air. When I was testing in the DB lab at IBM, we often had warmup runs that we excluded from the results, so that we could test, as much as possible, a steady-state environment.

Then there's the need to do real-world simulations. That's even harder. Just look at the work the TPC organization does for benchmarks.

Lots of reasons to do things different ways. But in your valid quest for meaningful information we want also to be sure we minimize random influences.

In the case of your tests that use SELECT INTO, it may be that the SQL engine is still doing some open/close activity. It'd be useful to run the DBMON against your program, to see what is really going on with SQL. This run would not be useful for performance comparisons, only to gather information on how it is running. Oh, and, before using DBMON, maybe STRDBG would give a hint of things. And it is possible with QAQQINI settings to get even more information in the job log. Most of those settings are documented and available in InfoCenter and probably somewhere at <www.iseries.ibm.com/db2>.

Vern

At 03:43 PM 7/23/2004, you wrote:

> From: Vern Hamberg
>
> Joe, it's not really caching, it's just the result of data being in
memory
> that is available to all processes. Unit testing would need you to
CLRPOOL
> and SETOBJACC *PURGE in order to compare apples to apples. Another
kind of
> testing would be what you are doing now, to show what happens when you
> leave things in memory.

Um, why would I need to CLRPOOL to compare "apples to apples"?  Are you
saying that somehow CLRPOOL will make SQL run better?  Why?  Does SQL
not know how to take advantage of memory?  If so, that's a knock on SQL,
not my testing.  Since I would never be doing a CLRPOOL in production,
why would I do it in a test?

Just trying to find out what you consider "apples to apples" to really
mean.

Joe

--
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.