-
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.
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
-
Originally Posted by PAVB
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...
Assistance is Futile...
-
Originally Posted by PAVB
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.
Instead of the above dribble, why not contribute something useful?
-
Up in the fourth post Davey said "tune your code to do less IO"
There is where this whole thing should have ended
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
-
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
-
Originally Posted by raviindbaworld
wht can be the reason for this ? IS it problem with redologs ? ... The server configuration 72 hyperthreaded cpu's with a huge hard disk capacity.
Run statspack to find out the kind of i/o you're waiting on. Huge disk capacity != huge disk bandwidth.
-
Originally Posted by ixion
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.
I think one can tune inserts and updates...since you can generate explain plan for them.
what about nolloging, parallism, indexes, paralell dml?
Life is what is happening today while you were planning tomorrow.
-
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.
Pablo (Paul) Berzukov
Author of Understanding Database Administration available at amazon and other bookstores.
Disclaimer: Advice is provided to the best of my knowledge but no implicit or explicit warranties are provided. Since the advisor explicitly encourages testing any and all suggestions on a test non-production environment advisor should not held liable or responsible for any actions taken based on the given advice.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|