Re: Disk Layout

Mark - Do I read this right to say you fragmented a table over three dbspaces *on the same disk* and got tripleish the performance compared to one dbspace? That's amazing. It seems like the three threads concurrently reading the same disk should bounce the heads all over the place yielding poorer performance. Questions: 1. How did you have the RA parameters set? This may have masked the random access issue. (Triple the scan threads = triple the readahead...) 2. Was the disk on the other side of a particularly smart or heavily cached storage array? 3. How about PDQ - could that have bought you some processing efficiency (at the expense of OLTP) that wasn't available with one scan thread? 4. Do you have any other ideas as to why this is? Most Curious. Thanks - Greg Mark D. Stock wrote: snip..... > > This is a bad example, and not the way you think. I ran a similar test > on a disk in an old Sun box this week, and got a figure of about ten > dbspaces. We fragmented a table over just three dbspaces (yes, on the > same disk) and saw our benchmark script's performance increase by a > factor of three! Now that's linear scaleability. ;-) > snip.....