Re: RAC in NAS

Isn't the problem - rather than lack of education - intellectual laziness among ourselves and our brothers? You could actually BUY the hard-nosed books and READ the boring websites with all the long and winding math-stuff, etc in them and get smarter, but it would require you to STUDY instead of going to bloody classroom, where you just sit for several days and think about the next break and where the answers to the pre-planned exercises are.... Whenever there's been a cut-down in education budgets in all my years in this Oracle world, it has had absolutely no impact on the quality of service or the ability of people to solve problems when they had to. It still comes down to what the individual wants to achieve.

If you want to become fantastic, there's no way that will happen by insisting on attending all the standard stuff, which is just Lowest Common Denominator.

Oh, by the way, I must admit that I have had some astonishing meetings and non-meetings with Technical Architects. I refuse to think that they, as a whole, are dumber than the rest of us. Somehow, though, they end up in a situation where they have to look smart both to management and techies, and that turns out to be very difficult to most people (and probably very few of us could do that either).

I remember Tim Gorman's mail footer in the 90's while he (and I) were still in Oracle: "Building tomorrow's legacy systems. One crises at a time."

Mogens

Mark Brinsmead wrote:

> Comments inline below...
>
> On 7/31/06, *Jared Still* <jkstill_at_gmail.com
> <mailto:jkstill_at_gmail.com>> wrote:
>
>
>
> Small wonder. The technical architects are not usually experts
> in storaage. That is, down to the detail level.
>
>
> It's pretty tough to be an expert "down to the detail level". I know
> that *I* cannot
> claim to be. For this you would probably need proprietary information
> about
> about the internal implementation of a given storage solution.
> Something you
> *quite* unlikely to get from sales reps.
>
> At the same time, I am often astounded by the apparent ignorance of
> even the storage basics. Like placing 60TB of storage for 24x7 systems
> into a single (midrange) disk array with a *maximum* throughput of
> 400MB/s.
> Without any *thought* of how the data will be backed up, let alone
> recovered.
>
> (400MB/s *sounds* like a lot of bandwidth, but we need to leave some for
> the *application* to use... And in the instance I am thinking of,
> this was
> only onle application of several dozen sharing a "corporate" backup
> infrastructure with a maximum throughput of only about 80MB/s...)
>
> And then there are the guys who will cheerfully place a 400GB database
> on a (single) 750GB ATA disk drive. No problem -- after all, there's
> plenty
> of room for growth, isn't there?
>
> "Detail level" expertise is certainly helpful, but really, all you
> need to avoid
> some of the more common blunders I have seen is an understanding of
> basic disk drive geometry (there's this "spinning thingy", and then
> there's
> this "seeking thingy", and that's about it...) and some grade-5 (well,
> these
> days, maybe it's grade-8) math skills.
>
> I mean, staying away from the "rediculous" situations is not rocket
> science...
>

--
http://www.freelists.org/webpage/oracle-l