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