Re: RAC in NAS

  • From: Mogens Nørrgaard <mln@xxxxxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Tue, 01 Aug 2006 18:44:56 +0200

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@xxxxxxxxx <mailto:jkstill@xxxxxxxxx>> 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...


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


Other related posts: