Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: SAME methodology opinions?
"Tanel Poder" <tanel@@peldik.com> wrote in message news:<3e6dec1d_1_at_news.estpak.ee>...
> Hello!
>
> Simple, I keep hearing this too much, that adding more cache, memory, CPU is
> all you need and forget about planning your IS/DB/HW.
> And I just talked to a Hitachi salesman few weeks ago, that told me the same
> story.. especially with the one that EMC can't handle IO at all, etc..
>
> I'm not against the SAME methodology at all - it can help to lower the
> administration costs of small to medium databases with small performance
> impact. Of course, if one doesn't/can't plan a physical database structure
> properly, SAME would be a safe bet. But if you do have a little common sense
> and understanding of RDBMS'es, you can achieve better results with separate
> disks. The question is, which is more expensive, DBA knowledge for planning
> or hardware (software/licenses).
>
> But what I'm strongly against, is the idea that cache is the cure for all
> worlds problems, e.g. if your DB gets slow, just get more cache (or even buy
> CPUs). As long as you don't cache every single bit of your data, the disks
> will always be a bottleneck.
>
> Tanel.
>
Thanks for sharing Tanel. I never think technology or money should replace DBA knowledge. But like it or not, it is gradually shifting the focus. As a DBA myself, I do not like the thought, but it is moving toward that direction.
20 years ago, you see "tune up" sings in every gas station in the U.S. Now you see none. Because technology replaced it.
As a matter of fact, for non IO bound DB, with SAME and RAID 5, I can get avg IO service time to be under 2-5 ms constantly. I just don't think where you put your redo or temp segment is that important in that case. I'd rather DBAs spending more time on availability than trying to save another 0.5 ms in this scenario.
But on the flip of this scenario, in a highly IO bound DB, cache will only delay your problem. It won't cover it up. In that case, DBA knowledge still prevails. In this regards, everything you and other said is correct. Received on Tue Mar 11 2003 - 14:12:44 CST