Hi, Some extra info from the DBA:
> How big is the GRID_YIELD table? See the (tkprof made) summary of a trace file which I sent before. The table uses 432717 blocks of 16k, so roughly 6.4GByte in size (gross). In the test 226541 blocks were read from disk, so the reaining were already in cache. > How does he know the whole dataset may fit in the cache? The buffer cache is roughly 8G, the dataset is 6.4G. So it MAY fit. In fact, in case of this type of queries (see the summary of tkprof) Oracle will not keep the data set in cache as a whole. It just reads some blocks, processes them and let them go waiting for new ones to process. I believe there is not at all a neccessity to keep the data set in cache. > This certainly doesn't seem like a system where the entire dataset is in the cache... I agree. See above. > ..., this looks like an I/O bound full table scan. Sure, the test query has been designed to do a full table scan. I agree, the system looks like I/O bound on a level of 20 - 50 MB/sec. This is exactly what we want to improve, at least to a much higher level. > Is the system running other queries simultaneously? I emphasize that the tests run, at regular intervals, on a production site. Other processes/queries may run in the meantime. They may influence the test run (and sometimes they do). And further: > The iostat is interesting because it appears to show a very uneven pattern of reads and writes. The writes are what I find curious. > Why is the system performing so many writes? Is this log activity or perhaps sorts being pushed out to temp tablespaces? Every time when the test runs, it makes a trace file (a detailed log). The size of the trace files so far varies a bit: 321730 - 32840747 bytes. If there were no logging, the test run itself would not produce a write, except on in the end (logging one row in an table). I hope this clears up some things...... Cheers, Andre
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
