Oracle 11gR2 buzz and my "Thank You" to Oracle

re-Hi all, and nice to see everyone busy downloading/tweaking the 11gR2.

Must say I havnt really kept up with all the buzz, but when I looked at the new features I tried to be a-typical: I'll not go and sing praise to all the new complexities yet. I'm sure they are fine and wont cause serious trouble. They will come my way in due course.

My 11gR2 buzz ?
I'm on the lookout for the simple stuff that may just be of benefit to a large number of DBA grunts like me. For the moment, I will have to let someone else study the new intricacies of the upgraded root.sh script (Hi Martin, Jason!)

---

I have to fuss-up that the most high-tech "fixes" I did in the last year was around conventional locking (TX Enqueue, just app-logic, talk to the vendor), Dynamic-SQL (politely lean on the vendor of the app) tweaking CBO (and not even subtle, just applied some Tapio[link]) and the (system-)statistics. Most of my work didnt come close to proper rocket science, any of you could have done it. The bulk of my assignments seem to involve pushing people, rather then data-blocks. And my email-cc skills have greatly improved in the last months. Sigh.

---

Reading the "wotsnew", I still found several gems of simple (I hope) and possibly very usefull features.

There is at least one client that will be interested in "Instance Caging". The site that can benefit from this as the Developers have 100 small, but sometimes nasty databases running on a single machine with 24 CPUs. And sometimes they have an "oops" moment and one instance affects the whole (development) system. Reading up on "instance caging", it is dependent on Resource-manager. That sort of locks me in, I now Have to use this Resource manager malarky... (Guess I'm a Lazy Luddite at heart)

The IGNORE_ROW_ON_DUPKEY_INDEX may well be an instant hit. I will not be able to resist abuse of that one! The benefits are Obvious.
But... (there are at least two buts)
This new hint will lead to a lot of lazy-programmer-style stuff. Potentially as dangerous as the "whenever others" that Tom Kyte is sometimes on about.
And, on a more Friday-philosophical level [link to MWidlake], I dont like the fact that a Hint has an impact anywere but on the optimizer.
I can not stop Oracle from developing (useful!) stuff like this, but it puts "Hints" in a whole different part of the game. Food for thought there.

So let me politely say "Thank You" to Oracle for the new, simple, and easy-to-use(?) features. There are a few more ones, I will explore them further when time permits.

First got to do some prio stuff, such as booking trips and updating the Agenda [link]. Hope to see some of you in Real Life on a conference, a SIG, or a Gig somewhere.

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)

Serious Work

Two remarks about Work.

Working in IT can suck you in big time.

I just spent one of those weeks of late-nights hammering on a problem for one specific client, working from the Rotterdam Office of my employer.
And in the same three day-week, every third manager and every third Secretary in the dutch subsidiary got fired. A bit like shooting ducks at the fair, I guess. Hence two remarks.

Firstly, the people-cleanup.

The culling is a tragedy for those involved, but Especially for the Secretaries.
Personally, I welcome a good management cleanup. We had a lot of duh-livery managers, and a reduction in overhead was long overdue.
But firing Secretaries in this climate is "not done". It may be that I have not worked enough billable hours, it may be the boss did not keep our "utilization" on par, but it is definitely not the fault of the Secretaries, and firing them isnt going to help.

Also you can fire 1 extra manager and keep 3 good, useful secretaries.

Secretaries are the fabric of the company, they Really know how things work, and they are immensely valuable in emergencies. Whether you are stuck on an airport or need a replacement for a broker laptop power-supply: Call the Secretary.
The indians may mean well, and have nice callcentre-scripts, but all they are allowed to say, sir, after 30 min, sir, of phone-confusion, sir, is "you must contact business secretary and order replacement, sir..."
The secretary knows that the power-supply-thingies break down, and has a few spareparts laying around!

Hence my deep Respect to all Secretaries, past present and future.


Secondly, the we-feeling.

Our new NL-top-dog is much impressed by the "we feeling" in our company.
Right, well, the secretarial staff will agree....

I know it sounds funny in (northern)english, due to the various meanings of "wee". But he wants to compliment the remaining staff on the "team spirit". It just sounds funny if you litteraly translate from dutch...

The thing that gave me a real boost in the last week was the Dedication of a small team that laboured on, regardless of the organisation falling apart. Regardless of tears at the coffee machine, regardless of losing a few good bosses, regardless of uncertainty about who would sign off our expenses, regardless of the vendor documentation providing the wrong scripts, regardless of the client trying to prevent them from work by calling every 5 min.

We had a customer that had got himself in a real twisted problem, mainly due to ignoring good advice for years. And now we had to bail him out of it.
Never ever had they listened to good advice. But of course we would take the blame, that is what the IT supplier is for.
An "I told you so" attitude never got you anywhere.
But Helping a customer in need Might get you somewhere.

So when things really broke down, some of our brilliant brains actually managed to puzzle him out of a bad spot. They figured out which tables and un-documented relations (and bolted-on triggers!) had caused the poblems. And they retrieved exactly the right records to resume normal operations.
That is the sort of team you can win a war with.

And for those in the know: Brains always are better then Iron.

Iron, Big, Brute-Force, Expensive Iron, may look good and make you friends at hardware-vendors.

But Brains will win the day.

Planboard

Today's image is a plan board. This is of course to promote the Planboard DBA symposium. A relatively small-scale, Dutch event by "planboard". The small scale of the event makes for excellent knowledge transfer (I expect many questions that I cannot answer...) and good networking.

Kuddos to Planboard for this initiative, and my gratitude to those who have convinced their budget-holders that these events are Valuable. Believe me, they are! And they are cheaper then training too.

It is something the UKOUG has noted as well. Small and targeted events, Special Interest Groups if you like, often are the most valuable meeting.
I'd be tempted to report on a discussion I had with two DBA's over lunch at the Scottisch DBMS SIG. They might just have solved a nagging listener-connection problem from a good discussion with Joel Goodman and a few others.

And that is the kind of value you get from SIGs and Symposia.