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 CBO version 12 - secret preview

Tanel Poder has the scope on this.

He got his hands (and eyes, and brain) on something that seems to have escaped from an Oracle Lab.

Have a look.

Nice one Tanel!

Simplicity is Crucial in Database Deployment

While visiting the homepage of our beloved vendor, I came across this link to "Gartner".

Gartner Research is among the most used and cited in the IT industry, so I was curious to see what was there. The title was promising:

Oracle RAC Moved to Mainstream Use

I had a good read and the one thing that struck me was the number of mentions (warnings) of "complexity" and "need for training". There is also the "confusion between ASM and CFS" to notice.

Of course, I only read what I want to read, and conclude what I want to conclude, but I will stay firmly on my view "Simplicity is King" (but complexity sells better).

compliments to metalink support

Metalink is a very positive experience.

My compliments to Oracle for their state-of-the-art 3rd generation pro-active Support system.

The good old metalink interface was Snappy and Fast and the new flash(?) interface is so clever it is just a doddle (albeit a bit obese, I do alway request for a mega-size hi-res screen, and a 3Ghz Dual-core machine, just in case).

You will notice that I cram in as much positive words as I possibly can, just to make it look like I really am a fantastic supporter of this excellent metalink support system. The search engine will love this. And may the gods of google and Redmond reward me with oodles of Good Karma, and lunches, and plane-tickets, for all this forward-facing and link-enhancing Feedback. if only I wasnt so lazy with links...


Anyway, the Rant...

Last week I had one of those refreshingly positive Metalink experiences.

An issue with "system statistics". The details are rather client/app specific, hence no further details (yet).

System_statistics?
You know, the stats that replace Multi-block-read-count and ind_cost_adjust_perc. The stats that tell the Cost-Based-Optimizer about the underlying hardware.

System stats are the stats that get stored in SYS.AUX_STATS$ with items like CPUSPEED, MBRC, SREADTIM and MXTHR (another great feat of engineering-in-progress, the CBO). For those of you who think I'm talking about stats on the SYS schema, or just the auto-gather job: Get the Book By Christian Antognini. He has what I think is a good explanation, and the Best Strategy (best practice, if you want management speak) for gathering system-stats.


OK, so we have an Issue with this gather_system_stats. And nor metalink nor google came up with a satisfactory answer. Even a phone-call to an ACE director didnt give me a resolve (but at least we agreed on possible approaches, Thx Anjo!)

So what is a consultant to do ? I reluctantly opened an SR...

After two polite and cheerful acknowledgements (Hi I'm Joe and I will help you.... Hi I'm Tom and I will help you....) but no answer whatsoever, the third "Support Analyst" had actually searched metalink and typed (pasted) some reply. Thank you.

His first reply was to read 10 or so notes on Metalink, all related to "object stats", e.g. gather_schema and gather_table stats. My colleages had already read all of those, and I had read most. I sacrificed my time on a double-check but our answer wasnt in there.

So I had to update the SR and politely point out that my question was about SYSTEM statistcs. The ones stored in SYS.AUX_STATS$, and gathered by dbms_stats.gather_SYSTEM_stats. The stats that represent the underlying hardware configuration.

Next reply from the analyst (more metalink searching on his part) was that the gathering of stats on the SYS schema was explained in ML notes Eeeeeeh.1, Grrrrr.1 and Zzzz.1... with some obviously sensible and MC (Metalink-Correct) caveats and version-dependency remarks.

I then Icey-Politely stated I did not want to offend him, but that I would really appreciate it if he read the question and my replies again, carefully. Please-pretty-please.

Maybe the question was not that trivial, after all. I had spent a full evening in an Ice-cold shopping centre with wifi trying to find the answer myself on both metalink and google.

One Weekend further, a support analyst called my mobile number. Relief. This person at least knew approximately what system-statistics were. And he called mainly to confirm and assure that he actually understood the question (Yay - Progress!). He Did understand the Issue. And the question. And he is now looking for an answer inside Oracle.

The secret of using the CBO is to not let it eat up your time and effort. And in writing this, the CBO just cost me another 30min of my life. My mistake.

Am I Positive about Metalink ?
You Bet !

That fact alone that someone now read and understood the question, and the actual effort he displayed to now find an answer is Refreshing. It restores my faith in online-support.

And metalink-alone justifies the flat-screen TV I've requested on my desk.

Irony anyone ?
(I never was good at jokes)