| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Oracle 10g - Diminishing DBA roles ...
Comments as ever - NB taking this somewhat away from the subject line..
Howard J. Rogers wrote:
> Taking them one at a time:
>
> ASSM - Hopeless
I sort of disagree. I suspect that it is perfect for where sites are experiencing the problem for which it was designed, otherwise not one of Oracles finest.
> ASM - Brilliant. No more worrying about I/O bottlenecks
I'd be spending all my time worrying about a version 1.0 LVM working correctly. That and I am highly sceptical that abstracting the physical relationship between files and disks isn't a way of hiding io problems effectively from the administrators/analysts responsible for a system. I suppose at least with ASM you can't put other apps on the same disks.
> ASSM *and* ASM together - Really quite a good idea
> Function Based Indexes - Brilliant. How else can I do case
insensitivity
> without clobbering my database with full table scans?
Absolutely.
> Wait Interface - Brilliant. You can't tune without it.
A bit of an achilles heel waiting to happen methinks though. I see more and more proposals for multiple system, multiple tier, multiple technology it systems (I refuse to use the word solutions). If the problem is outside the db then timing data from the database can certainly inform you of that, if there are n other uninstrumented tiers out there then pinpointing the problem still tends to be a rather unfortunate matter of checklists, ratios and guess work (sar or vmstat anyone? timing information from ejbs/.net assemblies?). Now if you work in a silo'd environment where you can say "look its not the db it must be someone elses problem" then you might be ok but thats not really a very professional attitude. Why is it an achilles heel, well what would it take in an ideal world to tune right? The answer consistent complete and correlated timing information from the entire tecnology stack. This can (in my view) only be done by one vendor - and that vendor is located in another location starting with red....
> Bitmap Indexes - Extraordinarily brilliant in the right circumstances
(ie,
> No DML). Billions of records selected against for multiple different
> conditions, and the answer pops out in seconds.
Agreed.
> Writers don't block readers - Rather like Oxygen, we wouldn't be here
> without it.
Oh we'd be here - we'd just be coding differently. Databases that don't do this *do* work - they just work differently (and IMO not so well but I bet you a dime to a dollar that in most cases poor performance isn't due to the platform but the app code).
> Flashback - Superb. One of the main reasons for upgrading to 9i. No
more
> incomplete recoveries due to user stuff-ups.
I disagree. In theory of course you are correct.
t0 - user A drops table tab1. t0 + 5mins - dba issues flashback commandt0 (close of business) - user A buys dba beer.
In fact what is likely to happen is
t0 - user A updates table tab1 incorrectly. t0 + 0 - t0 + 5mins - users A,B,C,D... update other tables based on bad info t0 + 5mins - what does dba do now?
or
t0 - user A drops table tab1. t0 + 5mins - dba issues flashback command t0 + 6mins - dba discovers user lied about t0 andinsufficient retention was specified.
Its scenario 2 that really worries me of course because the chances are that of course it isn't t0 + 5mins but t0 + 5 days before you discover the problem. I'm sure people do lose data and business due to dropped tables, but its the screwed up updates/deletes etc that really hurt - and so far as I can see guaranteeing consistency after further business transactions have happened is well nigh impossible. Obviously you aren't in a worse position than you were before flashback - but in many cases you won't be any better off. I have the sneaking suspicion as well that using flashback has the possibility to screw you in subtle and unexpected ways in that sort of scenario.
> Logical Standby - Finally! At last! Brilliant! (when the bugs have
gone). A
> disaster recovery mechanism that isn't just a lot of expensive
hardware
> sitting idly by, waiting for an asteroid strike. This expensive
hardware is
> actually usable.
Possibly - I'd wait for the bugs to go first...
> Log Mining - Brilliant. Auditing, diagnostics, and a recovery
mechanism in
> one... things don't get much better than this.
Agreed.
> Cache Advice views - Hmmmmmm... OK. Not my cup of tea.
I like them *at the setup stage* when you have bought a new app. What is the pga requirement for the new system, what about the buffer cache requirement. Have a good stab at it , run the app for a business cycle and take a look at the views to see how badly wrong you got it. They aren't an ongoing tuning tool though I agree.
> So, most of them are really quite extraordinarily useful. And if you
aren't
> using them, you ought to be asking yourself why ("The application
doesn't
> need them" is a valid answer, but rather suggests your application is
a bit
> long in the tooth).
>
> I would mortgage my cat to upgrade to 9i for Flashback alone. I would
seek
> offers for my goldfish to upgrade to 10g for ASM alone.
I hope the one isn't inside the other?
> > For that matter, How
> > many DBAs really understand those?
>
> 100% of them do. Because anyone who doesn't understand them isn't
actually a
> DBA. A junior DBA, perhaps. A 'thinking about it and maybe one day'
DBA.
> But no, they're not a DBA as such.
>
> > Even if somebody does( Docs,
> > Training, Google Search...), Do they really know how to use it ?
>
> Of course. Because real DBAs have PCs at home where they test and
research
> and work things out. So even if their particular work requirements
mean
> they don't get to implement something in real-life practice, they're
ready
> for the day when business requirements change.
Over stated *a little* I think - yes of course you test, research etc. I've never been exposed to the partitioning option *in practice* - yes I know how it works, but there is a difference between running the hr schema samples and homegrown tests and looking after an app that uses the feature (or modifying a supplied app so it performs acceptably :)).
-- Niall Litchfield Oracle DBA http://www.niall.litchfield.dial.pipex.comReceived on Mon Sep 20 2004 - 04:52:04 CDT
 |
 |