Re: dbexport/dbimport problems

Isn't it weird how OnLine keeps on contradicting itself? I'd have read this scenario as quite the reverse: > When users start using this table, each indexed access will read 5 (say) > index pages from the last disk and one page from one of the other four. > Therefore the last disk will be accessed 20 times more than the other > four causing a bottleneck My interpretation would be this: because the same top-level leaves will tend to be traversed more often, and because index size is usually very much smaller than row size (and therefore you read relatively fewer pages and tend more to re-read the same ones, because any given index is more likely to share a page with one you've already read) - after all, in this illustration we are assuming a data size: index size ratio of 4:1 (which IME is conservative) - the index pages will (a) require fewer page reads than the data pages, and (b) tend to get buffered more. Therefore if anything the disk with the *index* pages on it will get hit less. When I was at Informix I had a client running their own benchmarks. Of OnLine tuning they said, "Well if we have a performance problem we ring Tech Support, write down their advice - and do the reverse. And it never fails." This isn't Tech Support not doing their job (actually I'd replace "never fails" with "doesn't often fail"); it's the noble art of tuning OnLine. I'd bet that for different applications and different load profiles, both David's theory and mine could be proved to work. akent@cix.compulink.co.uk (Andy Kent) -------------------------------------