2009/02/12

do as they do, not as they say...

Yeah, well: I never said this blog would be a regular thing, so there!

<rant>
I'm not sure what is going to happen to the world economy. I keep hearing about these fantastic rescue packages that seemly no one has to pay for?

Recently, I was reminded of why I am so cynical of modern theories of education and economy. I do have a lot of respect for the engineers who made the moon landings possible and yes: I also do not believe nowadays they would be possible, with the incredibly sub-standard education kids have had for the last 25 years.
My kids "hate" me for my fixation with them learning basic science and maths that is way above what their school demands. I don't care.
</rant>

Life's been hectic at work with the econolypse of the past few months really affecting all our plans for 08-09 and beyond.


On the other hand, it's been a great wake up call to the powers that be - PTB for short, the folks who sign cheques - that our IT applications were getting somewhat stale.


There has been a big effort here to consolidate the dozens of MSSQL licenses that proliferated in this place when dbs were being installed by a bunch of click-happy cowboys.


However, the last few projects have all been based on MSSQL-based applications. Let's just say they were not "best of breed" and leave it at that for sanity sake.


Slight snags like needing dedicated servers in order to perform at any acceptable level, have higlighted that most MSSQL-bred applications just don't like to share the db server at all.


Consolidation of servers, something that MSSQL 2005 made eminently possible, is still a swear expression in the circles these apps frequent.


Result? Proliferation of licenses, waste of resources.


You know the scenario.





What is however very surprising is some of the companies Oracle bought in recent times, with a past history of MSSQL use, are actually trying to spread this state of affairs to the Oracle universe!


Obviously, the whole Oracle mantra that we should consolidate apps into a small number of databases has been lost on these people.


Case in point?


Hyperion.


As part of a global effort to standardize on a single financial reporting system for our DW data, the PTB (see above) decided to invest on a Hyperion pilot project.


OK, so we set up a database for a development environment.


There was a note on the "dba guide" - folks, have a look at it: to call THAT a "guide"...- that Hyperion "recommends" the HFM schema (financial analysis) reside in a different Oracle instance than the FDM schema (data supporting the HFM).


We have heard this one many times from the MSSQL-oriented brigade. It's their way of creating FUD to ensure they get a whole system dedicated to their products just in case it turns out they can't cope with real life loads.


What I didn't realise is this was now the attitude inside Oracle!


As soon as their installer guy got a whiff there was only going to be a single development instance, with the HFM and FDM schemas each in their own tablespace, the "veiled threat" came up:


"If you do not follow our recommendation and install HFM and FDM in a single instance, when you call our support with a performance problem they won't even look at it until you separate everything!"


Lovely...


For starters:


a recommendation is *NOT* the same as a requirement.


If Hyperion REQUIRES dedicated instances or else they won't support it, then do NOT call it a "recommendation"!


And of course:


Tom Kyte, Cary Millsap, Anjo Kolk, Jonathan, the dozens of other performance tuning experts out there who always taught us to analyze waits and apply a scientific approach to analyzing a performance problem:


You were ALL WRONG, folks!


The Hyperion boyz say you MUST separate everything into their own instance if you have a performance problem, or they won't even look at it to start with!


What's worse: this mob works for Oracle now, so presumably this will be the Oracle official line on this subject?


There you go: who the heck needs all those fine analysis tools and all that dba 2.0 nonsense built into Grid and OEM?


We won't even look at it until you separate each schema into a single instance!


There!




Amazing...




I'm sure it's my fault, of course: I eagerly await the "official" Oracle blog entries, insinuating that only "out of date dbas who don't want to learn new things" would consider consolidating their applications into a smaller number of instances.



Ah yes: sorry folks, all that stuff about having a single RAC instance to run all appps was just a bad taste joke, after all!



Unreal!







Anyways...


A little bit of sanity might remain if we look outside of the Oracle insanity. I did. And took a few images. Not much: it's been too hot to do b&w development and the BTUs generated by my scanning setup are not helping with temps around 40C...

I'll get more active as Autumn sets in but for the time being here are a couple I find nice:



This is a detail of a street organ in the Canberra Floriade, last October. These devices were one of the few ways the so-called plebes in the 19th century could hear the music the better off folks listened to in expensive concerts. For that reason, I called this one:

"Fanfare of the common man"




These things produce some of the nicest, feel-good, happiest sounds one can listen to.

It should be mandatory for everyone to sit in front of these every month, for a while:
I'm sure there would be a lot less wars!







This one I just couldn't resist. I called it:

"Ah! Love!...".



The bike looks like it's fallen for the other one. ;)



I'll be back soon with more news. There is a stack of SAN stuff to talk about for those who might be interested in running with SAN-mirroring active. Some nasty config snags. Will talk about it once I get all the relevant data.


Catchyalata, folks!