Printable View
Focus! Focus! you have to read the original question.
You guys can't just machine-gun answer anything that comes to your minds LOL ... very good answers I would say, for a totally different set of questions!!!
The guy wanted to "decrease I/O"... now, go ahead.
Man, this is getting better by the minute :) I'm loving it.
His question seems to suggest to me that he is looking to reduce Waits for I/O (WIO in the title), so therefore, speading I/O around different filesystems would be a valid answer to the question...Quote:
Originally Posted by PAVB
Instead of the above dribble, why not contribute something useful?Quote:
Originally Posted by PAVB
Up in the fourth post Davey said "tune your code to do less IO"
There is where this whole thing should have ended ;)
I disagree.
How do you Tune an insert to do less I/O or an update or a delete???
I/O sometimes can not be avoided in order to do meaningful work (hmm what ever that means)... In those cases when the I/O waits are high then proper disk managment and analysis of the system layout is required to improve system performance and response times.
well you can, better indexes etc, use better structures - but agree, look a the io sub system as well, always an important part
Run statspack to find out the kind of i/o you're waiting on. Huge disk capacity != huge disk bandwidth.Quote:
Originally Posted by raviindbaworld
I think one can tune inserts and updates...since you can generate explain plan for them.Quote:
Originally Posted by ixion
what about nolloging, parallism, indexes, paralell dml?
Well, tuning insert - OK direct load insert could do
Tuning deletes - index and truncate where appropriate
but this is not what ixion means I believe, just there is a job to be done and sometimes we can do nothing about that.
Then we can look at the layout.
If it's good as well, then we go for faster disks and more cache
Guys... I still don't get it.
Poster has a single query which performance is loosing steam. "Used" to run OK, now is getting lazy.
Tell me the truth, when this happens in your own shop... is the first thing you do to go and check physical layout?
Wouldn't any fo the following actions come before looking at physical layout in you standard troubleshooting approach??? 1) Explain plan the query and comopare it with baseline (if you have it)... 2) Look if performance stats are up-to-date... 3) Review Change Control logs looking for what changed since the query was performing OK... 4) Trace the query... 5) Look at run book looking for new processes added since query was performing OK... /// Etc Etc Etc
Shouldn't you be aware of any disk bottle neck well in advance and not waiting for a crappy piece of SQL to sound the alarm? Believe me, in our shop we know what is happening with our physical I/O without having to wait for a query to blow it out.