RE: System slow-down - disk usage?

I also have an interest in understanding SETLL under the covers.

I decided to go with Write vs SetLL/Write and catch the duplicate key error. However, I'm still trying to wrap my head around what the system is doing when I SETLL on such a big file (even though I'm no longer doing it). It's not actually moving data to main storage, right? And if it is, how is it different than a READ? So, if it's not moving data into main storage, is the bottleneck simply the system attempting to position the file cursor?

In our current situation, our file is 40 million records. File input & previous file (for duplicate checking) are keyed the same. So on the 40 millionth record being processed, when the program issues a SETLL, it will move to the beginning of the file and go through the whole file, not find a match, and position to EOF?

Also: Crispin, your test seems to match what Barbara Morris had said in another forum (link provided earlier in thread).

Thanks,
Kurt


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Luis Rodriguez
Sent: Thursday, June 17, 2010 1:05 PM
To: Midrange Systems Technical Discussion
Subject: Re: System slow-down - disk usage?

Crispin,

Check this, I think it could be of help.

http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performance_DDS_SQL.pdf

<http://www-03.ibm.com/systems/resources/systems_i_software_db2_pdf_Performance_DDS_SQL.pdf>
Regards,

Luis Rodriguez
IBM Certified Systems Expert - eServer i5 iSeries


On Thu, Jun 17, 2010 at 12:50 PM, Crispin Bates <cbates@xxxxxxxxxxx> wrote:

----- Original Message ----- >

----- Original Message -----
From: "Charles Wilt" <charles.wilt@xxxxxxxxx>

Crispin,

Slight correction, chain is faster only if the key being searched for
doesn't exist AND the key is greater than anything else in the file.

Otherwise SETLL is faster.

Charles

Charles,

Forgive me for being dumb. Isn't what you said more likely to result in
SETLL being faster?

"If the key being searched for doesn't exist AND the key is greater than
anything else in the file"

Surely that would mean that SETLL would not have to reposition because it
was already at end of file? Or am I completely missing what you are saying
(quite likely)?

But that is just anecdotal, as I don't know if SETLL still has to position
to end of file even if there is no key higher.

FWIW, I took a file with 15 Million records, and ran a test of CHAIN vs.
SETLL to determine if the record existed in the target file. I read the
input file in Primary Key sequence, and effectively wrote every record
found. The target file started off with 0 records, and had the same Primary
Key.

For CHAIN, it took 10:33
For SETLL it took 11:31

This system is our QA system, nothing else was running. It's a partition on
a 570 with 6GB of ram and 1.5 TB of DASD (44% utilization), running i
6.1.1.

Based on that, using a CHAIN produced almost 1000 more writes/sec. But, it
matches your statement of there being no record with a greater key. I'm
just
not sure I understand why...

Of course, it could be completely different on another system.

I decided to take the WRITE out, and do the same READ/CHAIN vs. READ/SETLL
when the data existed in the to file for every record. I wanted to see the
impact of the CHAIN reading in the data.

I don't think anyone will be surprised at...

CHAIN 8:45
SETLL 7:15

Personally, I always thought that a SETLL would be better performing,
because no data is read into the buffer, the pointer is just moved. But it
seems that is not always the case, if there is no record to be found, CHAIN
appears to be slightly quicker...

Crispin.


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