Commodity or Simplicity ?

Just had a good chat with Anjo -MiracleBV-YAPP- Kolk, and we got some good soundbytes and possibly a presentation topic:

1st: IT is now a commodity, but that doesnt necessarily mean that IT is more simple.

For business (outsource-)decision makers this means that outsourcing IT to the cheapest provider is means exactly that: Cheap (and nothing else, let alone anything would work as expected - to make anything work is an Extra $$$).


2nd: Ppl are used to app-store style solutions.

We should keep that in mind when building customer faceing systems.
If it doesnt work immediately, the user will simply try to download another app. If there is no friedlier alternative, the user will become very unhappy, and possibly do a Youp[link].


Read the Title again: if you have the choice between "Commodity" and "Simplicity".
Simplicity may work better.

From Google to oracle

A recent article in the Register throws some light on the different approaches by Google and M$. The article and its links are worth a careful read, no matter what hat you wear.

Reading break....



(go on, read it...! that stuff is much more important then my ramblings)


Me, of course I only read and retain what I want to agree to ...
Not hampered by too much knowledge of my own, here is my colored and limited interpretation:

The Micro$oftee boasts in management-speak about the "tremendous set of applications" and the problem to come up with "one set of KPIs that works" (sic).

The Geekle is very much focussed on performance and smooth global deployment. He speaks of "forcing developers into a confined space", and of "GFS as a baseline service".

Two items struck me in particular.


Firstly, one of the key-items put forward by the Google engineer is to "limit" the developers. The Google platform offers a very limited set of "services" to the developer and the challenge is to keep the developers inside that box.
Hearding Toads comes to mind.

The Confinement, the Limitation shows the Master


The other keyword that ticked my fancy was "GFS". The Google File System.
There is nothing that isolates infrastructure more elegantly then a file system.
The "everything is a file" adage that came with Unix is unbeatable.
A database consists of files.
A VM is a set of files.

And a "Global File System" is a very useful, and a conceptually clean "layer" to deal with.

Those of us in the process of building "farms", "estates", "grids" and "clouds" would do well to study some of the Google approach. Oracle and its practitioners (that is us) may well be able to learn a trick of two from the Google Approach.

Limitation : reduce the number of different components. But scale horizontally by having many of them.

Simplicity and Confinement : do a few things, but do them simple and do them really really well (and Often, and Fast).

Layering : Isolate everything in a "File System"


In my opinion, the "limitation" and the relative simplicity of the google platform is one of its key success factors.

That Simplicity, and the hiring of all the brightest brains on the planet.
I have seen some very good minds leave to join Google, but I never heard of a manager going there...

Oracle Cost Base Optimizer - getting sucked in

The CBO is Truly Brilliant.
Oh Yes, it is.

Rant ?
me Rant ?
Never. I dont waste engergy that way.
Mind you, CBO is a worthy adversery when it comes to wasting energy. Especially after upgrades to 10g [link?].

Very Clever, the CBO.
The CBO will get it "mostly right in most of the cases" (famous quotation needed, but it is true). However those few cases where the CBO gets it wrong can really ruin your reputation.

I would always maintain that we paid Oracle to do the hard work for us, and I would not get sucked into doing arcane bespoke stuff with stats and hints and outlines and whatever to make a query do the bleeding obvious. Meanwhile, I spent hours tweaking all of the above, and reading near-scientific stuff trying to understand CBO just a bit better still. And now I finally got sucked in: I will join the ranks of those who have ranted presented on the CBO...

I must be careful here: Nobody ever got praised for pokeing fun at large vendors. The Real Application CBO is like those other Real Application Thingies: Oracle is Soooo Proud of it. No other database-vendor even comes close in ingenuity, in sheer intelligence, and in cunning engineering where query optimization is concerned.
So yes, I admit it, the CBO is Brilliant.
If it gets it right.

I did it again today:
A customer-meeting got sidetracked into "performance" and I spent 20 min explaining that when CBO made some seemingly inefficient decisions, it was not the CBO at fault. CBO tries as best it can. CBO will be using spfile-parameters, system-stats, object-stats, histograms, session-parameters, where-clauses, hints, outlines, and sql-plans and whatever other information it can glean from looking at the stars or tealeaves or whatever. So, if it is not the CBO at fault, it must be us, right ? We should have read the manual, the whitepapers, metalink, and followed the instructions available.

OK, real reason for this post: a plug for OUG Scotland.

I still need to write the abstract and the ppt, and wanted to aim it more towards efficient indexing, refer to Tapio and Richard Foote. Show CBO the obvious route (you can lead a clever horse to water) and it might just get it right... But my ppt will probably involve "how I fought the CBO".
Thomas already put up the title as a CBO related item...

These guys and many other good writers have basically said all there is to say already. And I am not qualified to tell you much on gathering stats or how to tweak parameters. Nor can I teach you about high-tech-hinting[link needed]. Others have done that before me, and did a much better job then I could hope to do.

I know my limitations.

I am going to take as Simple an approach as I can.

Touting for Business

For the moment, October is heating up with a very full Agenda.

Remember, I must also bring in some bacon for my bosses. Hence keep an eye on my billability. Combined with various other activities and just-one-more-presentation popping up, It looks like October is counted for.

November, by contrast looks Quiet. First three weeks of November see a surprising drop in demand (demand for my services, that is). I am looking forward to doing some Research and Development, and to refresh my Hands-On experience.

But... as a good consultant, with respect to Shareholder value (not to mention my managers-managers-bosses who want to retire early) I should be charging my time Adding Value to some Customer (Mind you, November, and I'm stocked up on firewood...)


Anyway, need to get serious. Hence this simple Tout:

Hire Me. (in November)

I can poke fun at your vendors.
I can make your Architects Cringe.
I can make your DBA's laugh (or cry)

Simply put: I am an Oracle DBA.
For more of my credentials: see the right-hand side of this blog, or just Google me

NB: No FUD here, I will not stick around to eat all of your budget: I'm booked for the last week of November. Then I'm going to UKOUG (that takes care of 1st week of December), and then I'm booked for at least one week in December. And Christmas is approaching.

After the Holidays, I already have Various part-time commitments for January and February, so that looks good (to my manager).

But November has some space.
Hence the shout.

Layered Approach, sometimes...

One of my current jobs is a typical fix-it-when-it-breaks thing. Various release of The System go "Suck-it-and-see" into testing and then into Live...

So there is me politely telling the developers which queries and constructs (redundant running totals, Locking!) are showing up as problematic in live or test-environments.

I generally add recommendations like: Please include the month as a selection-criteria (all and sundry is partioned on month, sometimes a date, somtimes a yuyymm integer, and a few forgotton exceptions). Or I suggest to add a field to an index to get index-only lookup. And yes, I often suggest IOTs (my Pet Topic!). Great for lookup tables or parent-child constructions with read-mostly data.

Developers/analists/architects then politely refuse to follow my recommendations. and using their obscure business-knowledge, they find plausible excuses such as:

"That will never happen in real-life" (it just did...), or

"That table will never grow bigger" (so why did it just explode ...), or

"that functionlity is never supposed to be used" (love that one: user has entered the wrong menu...), or

"pigs can never sometimes fly, you know..." (yep, if I throw you out of the window and into the river...)

Design for this project is done elsewhere, and we follow a "Layered" approach. That means no database-person gets anywhere near the morons in charge "architectural decision layer", nor does anyone using or operating the system in real-life get consulted.
Because that would not be J2EE compliant, would it ?


I am greatly in favour of "layered" approaches: Cold-weather clothing needs to be layerd to Isolate. All data should be stored in a File - that is a proper, abstract, layer between "data" and "bytes". Hence my desire for a proper Clustere file system to replace the muddling with Raw devices or ASM.

But Isolation is not always a good thing. Sometimes, you need to abandon a few layers to make things work.

Layers of management ?
Only if they stay well out of may way (and out of my margin)

Layers of objects ?
Only if you can afford to do all those JNDI lookups inside your 100ms SLA

Layers of Design-expertise ?
Only if the architects engange the Relevant Expertise. Early.

But then, as the guy opposite my desk repeatedly said: Respect for the zombies. All those incompetent layers of gremlins will always make a mess of things and keep us in a job.


Loose ends

I just got told to update my bloggie-thingy, as is is now a month old. But I have very little content at the moment. And have had to run after all sorts of family- and work-related stuff. More later..