wish list for 12c

Back in 2008 my wish list included sparse object allocation (deferred allocation in Oracle's translation).  And bingo, I got it in 11gr2! It was almost as if someone came here for inspiration!

Prior to that in my "No Moore" series I actually described the Exadata architecture, long before it became public.

Not that such a thing would ever be acknowledged by Oracle, we know that!  After all, I refused twice to become an Ace - and other such idiotic "rewards" Oracle thinks are important.
There is simply no way someone like me can possibly contribute anything of value to the product, is there now?

Still....    In the off chance that anyone with half a brain is listening - and before it gets claimed as someone else's idea - here is something that would be quite welcome. 

Recently I visited Tyler Muth's blog for one of his posts on storage performance.  I've known Tyler through the net for years and his messages are always full of great sense and value.  I always make time to read what he posts.  This time, while there I also noticed and commented on this.

Now, this is a subject that is dear to me.

I always had a great revulsion for the thousands and thousands of synonyms I see in many sites.  This is usually the case with sites who try to run multiple applications in a single instance, each under its own schema.

The problem of course is that you have to create an exclusion strategy to use synonyms.

You either use private synonyms - one set for each authorized application login - which usually results in millions of the little blighters.

Or you use public synonyms, one table at a time.  Presuming of course that two or more applications in that instance won't use tables of the same name.  Nine times out of ten you end up with a need for duplicate public synonyms, which of course is an impossibility...

Either way you end up with horrible maintenance overhead for setting up and keeping all the synonyms, assuming you can bypass the limitations of their use.

As well as potentially bad performance: SQL using synonyms is not always the best performing one.   Steve Adams pointed that problem out ages ago.

Now the problem here is that we want to provide logins that will "see" the application schema tables, without the need for the
<owner>.<table name>
syntax to be used in every SQL, and/or zillions of synonyms - public or otherwise.

You don't want that syntax as it will prevent you from running multiple copies of the SQL and application in a development database, for example: you most definitely don't want to go messing around with changing the SQL syntax itself!

One "traditional" way to do so - at least one that is often recommended -  is to use proxy logins, available in the latest versions of Oracle.

The problem with those is that a proxy login does not preserve any roles that you may have assigned to the proxy: the session "becomes" the target login, with the target's access rights!

Call me weird if you want, but having all logins become the application owner might constitute a slight security problem?

So: what do I do to circumvent all these problems?  I tried to explain in the reply at Tyler's, but here I'm detailing it a bit more.

Let's assume one application whose schema is called "PEOPLE_DATA".  And a couple user logins - or application logins - that will be called "PEOPLE_A", "PEOPLE_B". Let's assume also that this application has all its SQL written without the <owner>.<table name> object naming syntax.

We might want PEOPLE_B to have only read access to PEOPLE_DATA, while PEOPLE_A has read and write.

OK, how do I then go about this without recoding the entire application or creating a synonym storm?

Simple.

Create a database login trigger that recognizes the PEOPLE_A and PEOPLE_B login strings by looking at the SYS_CONTEXT contents.  I then simply do a

execute immediate 'ALTER SESSION SET CURRENT_SCHEMA=PEOPLE_DATA' ;

in my login trigger's PL/SQL code.

What does this do?  It keeps the original login active as PEOPLE_A or PEOPLE_B - with all its rights and roles intact - but assumes from now on for all SQL that the default schema is PEOPLE_DATA.
This effectively sets the default <owner> portion of all SQL for that schema.

And I can still create a role that grants read/write on all tables of PEOPLE_DATA schema and another to read only, and grant them respectively to PEOPLE_A and PEOPLE_B.
Unlike a proxy where the login user becomes another user, the session change of CURRENT_SCHEMA only alters the default SQL syntax: all other profiles, grants and roles associated with the logins stay as they were before!

PEOPLE_A and PEOPLE_B can now execute the application code without the need for a single synonym, under full control of the roles I created for them!

This now means that if I want to have two copies of PEOPLE_DATA in my development database, I can name their schemas (owners) PEOPLE_DATA_DEV and PEOPLE_DATA_TST.
And I can then have PEOPLE_A_DEV and PEOPLE_A_TST logins that are recognized by the trigger and set the current_schema to PEOPLE_DATA_DEV accordingly.  And so on for TST.

Now, some might want to create a straw man and claim that for thousands of logins this would make for a terribly complex login trigger.  To which my response is: care to explain how creating thousands of synonyms is simpler?
As well: bear in mind that most modern, large user applications do NOT login to the database, user by user.    They login through a set of pooled connections from an app server, which use a global login.  It is this global login that needs to be in the trigger!

I have now sucessfully setup various copies of our DW, Hyperion, and other schemas and applications in a single instance, without the need for a single synonym anywhere.  And with complete control through roles of every application login and what it can see.

But - and this is the subject of this wish list! - I recognize that it is not the ideal process!

To me, the ideal would be for Oracle to let me create multiple contexts, each allowing me to set a CURRENT_SCHEMA - and roles as well!- and then just grant the context(s) to the respective logins as part of their profile.

Unfortunately the context facility in Oracle- as of 11gr2 - does not allow me to set session parameters, or other useful stuff like roles.

Badly needed!

Because then we don't need login triggers: all we need is to set a default context for each login type and we have absolute control over what can be seen by whom, without a single synonym anywhere - other than cross-application ones which are perfectly legitimate!

Then, Oracle will truly support multiple application consolidation into single instances.  As is now, it's a bit of a joke, quite frankly...

(Yeah, yeah, I know: RAC solves all that.  And it brews coffee, too.  Go back to the start and re-read it all, if that's what you think!)


How about it, Oracle?   Here is something that would make early adoption of 12c a lot more desirable!
And look: given this is coming from a non-Ace site you can even find a way to invent some "monkey-du-jour" as the author of the idea and make him/her the travelling sales rep for the concept?

Because I really don't have the time nor the inclination for travelling, you know it!  Been there, done that:  incompatible with family life and I value that above all.

:-)




Speaking of which (travel, I mean): here are a few from this year's holiday trip to my youth paradise.


The nursery: Areia Branca beach and its sensational reefs:

Lovely place.  I always spend entire days here snorkelling around all those reefs and drop-offs.  Always lots to see.


Have you ever heard of giant clams?  The ones that in cheap Hollywood movies always "snag" a diver's foot and "drown" them?  This is what one looks like, when it is alive:

That baby was nearly one metre across!   And it was only about 10 metres from the shore, at Jaco National Park. The mottled grey stuff is the mantle, spread all around the two shells.  It is light sensitive, so if you wave a hand over it, it reacts!

Speaking of Jaco, this is what a sunrise looks like from over there:

Jaco is the little island on the extreme right.  Moments like this make it all worthwhile, believe me!


Matebian, a 2300metre high coastal mountain that many hold sacred due to the thousands that were killed here by the Indonesian invading military, back in the 70s and 80s:

And yet: when you wake up to this sort of view, peace can be one's only thought:

As such, folks:
pacem - and until the next time.

Catchyalata!

cloud services

In the last 48 hours or so there have been two interesting events in the Oracle and IT front in Sydney.

 
First one was the Oracle Cloud Summit at the Sofitel Wentworth.



Like so many other marketing events it had its fair share of "ooh-aahh" stuff.


You know, the usual:   "Exadata can finish work before it started",  "Exalogic can finish it before it was thought out in the first place", yadda yadda, ho hum...


But this one actually was a bit different.  You see, it looked mostly at cloud technology and how to implement it within the Oracle universe.


Now as I hinted here a number of times before, we have actually been gearing up for the private cloud for quite a while now.  And of course anything to do with that is always welcome material.


Within moderation, of course!  :)


How did we prepare for the private cloud?  About 4 years ago we initiated an effort to consolidate the cacophony of database servers and releases we had floating around - a legacy of years of neglect in terms of architecture and lots of "let's use the cheapest services" without the slightest care as to an overall strategy and direction.


I was lucky enough to be backed and followed on by the next level of management who demonstrated a willingness to give it a go and expand the concept across to all IT services. 


Thanks for that, Chris.  With your help, ideas and unwavering support, we now have an ideal platform to expand on a private cloud service that not only works like a charm but - oh, surprise! - actually delivers! 


In the process we managed to get rid of pre-historic release 7 servers, hardware that was actually and literally rusting, and we managed to squeeze the best performance possible out of hardware and software-based virtualization.


We're at the point where we can provision IaaS easily and quickly for any ad-hoc business requests, with a full infra-structure framework capable of resilience, reliability and with performance near the top of what anyone else can do within our budgetary constraints. 


But the work is not yet finished.


One of the areas that now needs further thought and architecture is the inter-application data movement.  We have a multi-supplier data centre - IBM, Microsoft, EMC, Oracle, RH, etc, so I am always on the lookout for ways to provide multi-vendor data integration.


Hence why this summit was so relevant: for once, Oracle took the initiative and showed a lot of interesting technologies that can be leveraged to provide this.  As well as many other facilities.



One that particularly struck me as incredibly useful was GoldenGate.  Not only is the software child's play to install - although I'm sure adding it to OUI will take away that advantage!... - but it's also dirt easy to configure and get going and it provides an amazing range of features.


I definitely recommend anyone reading this to spend some time investigating this technology.  Not only can it be used to do seamless upgrades - the case study shown in the summit - but it also can be leveraged to provide Dataguard-like resilience to MSSQL, Postgres, DB2, and so on.  As well as allow data transport - filtered or not is a config option - between any of those two!


Now, that is COOL!  One word in my dictionary sums it up:   AWESOME!




The other event was the Sydney Oracle Meetup tele-presentation by Chris Muir  on JDeveloper and web services.


Now don't get me wrong here: I still think that web services, SOAP and all the other alphabet soup that surrounds it is nothing more nothing less than an evolution/re-hash of good old EDI.
In simpler terms: nothing new in concept.  But of course using modern technologies.


I don't mean that in any way in a derogatory sense:  EDI is a necessary technology.  In particular, with the cloud taking off as it is,  EDI becomes even more relevant.


Whatever format its provision takes.


Web Services, SOAP, RPC, XML-based, JAX-WS, who cares: those are just vehicles.  What's important is the trip and the destination!


Chris's presentation re-inforced this feeling: he spends the first half of it actually discussing the whole concept and how it can be approached with a number of architectures and technologies.  And then he shows how easy it can be to implement with JDeveloper.


My use of JDeveloper is admitedly very small.  I used it nearly 10 years ago to show a bunch of websphere fanatics how I could produce a fully functioning web application made up of a number of inter-connected screens in one 10th of the time it took them to decide where to go for coffee!


The tool was already interesting back then.  But now it can do a LOT more.  I was glad the idea of using wizards for code frame generation was still there, although of course much better and much more sophisticated.


Chris did a great job of showing us how JDeveloper can help reduce the coding complexity of the many alphabet soups that seem to surround any web-related project nowadays.


He also showed how it can be used to produce a fully functioning PLSQL-based web service, re-jigged to work in a JAX-WS environment straight out of the stored code in the DB.


THAT was cool!


Note: Chris was careful enough to point out the shortcomings and there are a few.  But provided we are aware of them, it's possible to work around by design/coding.


He then provided some welcome insights into the actual process of actual web services provisioning projects and the possible gotchas that one can expect in such cases.  That was exceedingly useful, in particular in view of the current evolution of our IaaS provision!


Thanks for that, Chris: owe you a drink next time you're in Sydney.


This concept of tele-presentations is actually working a treat for us.  With the tirany of distance affecting greatly the number of opportunities for networking at this level, this technology is actually enabling us to provide a great service to the Sydney Meetup members.  Great idea, Yury!






But enough of the boring stuff.


This is in one of our centres:

I like it: original, intriguing, and yet quite easy on the eye.


Although of course this may be a lot more striking:

a Space Invaders image if I ever saw one, complete with "mothership"!  ;)


But you want weird?  Here it is:

Sydney's  Saint Mary in full "Sydney light show" regalia!



Catchyalata, folks!

cost claims and the law...

Been a long time since last post.  It's been a busy period since the start of 2011.


Mostly because we are in a period of turmoil when apparently every man and his dog is trying to get into our site for "outsourcing".  Even though that is most definitely not what we are doing.  But never let reality interfere with a good dose of marketing...


We've seen a lot of "cloud computing" and SaaS offers.  But also extended to services.


The funny thing of course is when we actually see the prices being proposed, it quickly becomes clear that the whole SaaS and cloud thing is nothing more nothing less than a complete rip-off, proposed and promoted by folks who haven't got a clue what IT is all about.


I'm quite sure I'm an "original", but when the entire SaaS replacement for one of our applications costs per year twice to three times what we currently pay in combined maintenance and support fees, someone has to do a lot of explaining as to *exactly where* is the ROI coming from?



But we already knew this was going to be the case. 


And claims along the lines of "outsource the expensive dbas" do little to reassure anyone that these people know what they are talking about.  If nothing else because the so-called "expensive" dbas are a tiny fraction of the total costs AND are shared by ALL applications.


But more on that right now.


You see, for the last umpteen years we have been hearing the IT pundits claiming how expensive it is to hire personnel. 

Then we check what the service providers and hiring agencies are charging for their contract services - around $1500/day for a reasonably capable professional. 


And we check how much are the hiring agencies paying for a person of the same calibre - around $500/day.


Call me a mathematical genius if you like, but I can see a discrepancy there of nearly $1000/day.  Where is all that moolah going to? 


 Ah yes: the "hidden costs" you say?  Let me enlighten you about those. 

 
Around three weeks ago a seminal court case in NSW was won by the contractor.  Who happened to be nailed by a hiring agency for going direct with a client.   Apparently, there was a clause in the contract that claimed this was illegal.


It turns out - after 2 years in court! - that not only is it perfectly legal for a contractor to go direct, but also ALL exclusivity clauses in hiring agency contracts are completely illegal, invalid and unenforceable, as of the end of that court case.


And one of the more convincing arguments  in favour of the contractor was that it was her who negotiated the last two renewals: the hiring agency simply rubber-stamped them while continuing to charge the huge margins.


"hidden costs", eh? 



More like TOTAL RIP-OFF, in plain old English...


I'll bet there will be a lot of noses out of joint over that one!  But I predict the days of $1000/day mark-up by hiring companies will soon be gone. 


Of course: in the process we'll be treated to another bout of offshoring at $200/day.


But anyone buying into that sort of deal better be aware of the old adage:



"you pay peanuts, you get..."!




Anyways, enough of the politics of IT in this state.  It's really not worth wasting any time on, for its sheer stupidity.




This showed up recently near our local coffee shop:

Yikes!    :)




And for those who watched the movie, this was recently at the Australian Museum:

Hehehe!




Catchyalata, folks!

last 2010 huzzah

2010 was a bit of a roller coaster...

First, the passing of four very good friends and colleagues:

- John Alexander Wildgoose, a fellow dba and IT pro as well as my long time golf buddy and friend.
- Dr. Paulo Abrantes, a very good adolescence friend I hadn't seen in many years, who quietly passed away recently. I do miss our talks about the future, Paulo.
- Noel Vanspaal, my database technology mentor and someone I respect professionally more than any other. Over more than 25 years Noel always had a moment to discuss any weird and wonderful issue I came up with, often followed by the sharing of a fiery curry from his native Madras, prepared by his wonderful wife Renata. We shared a similar professional background and had a perfect empathy in what relates to database issues and their resolution.
- Carlos Correia, my uncle and fishing mentor who also got me into the DIY bug and taught me how to catch just about any fish in any situation.

Vale, each and every one of you. I miss your presence and company but your friendship and fellowship will never leave.

And please: can it stop now? Had enough losses, thank you...
.
.
.

On the other hand I have had the great fortune and joy of meeting again many of my high school friends and colleagues from East Timor and some from my native Mozambique.
Amazing how our lives have branched out from each other, and yet after all these years we could still find so many things in common.
We are now all in touch regularly through Facebook and other social networking sites. And that has helped tremendously in coping with the above losses.

Still, that's all beyond the purpose of this blog. Meant more as an explanation of why it's been so hard for me to find the time to come here and talk about dba work.






On this one, I just wanted to show you the sort of performance we're getting in our main DW production node. Please understand: this is not some fancy-shmancy multi-million dollar RAC environment with everything in hardware-land thrown at it and infinite cost limits.

Far from it.

It's a simple Aix LPAR (a Unix VM in IBM parlance) with between 2 and 4 cores assigned to it, varying with the load we put on the system overall.

In this same box we run two i-series JD Edwards databases and applications, two other smaller Oracle databases and the main DW (1.8TB of it). As well as a SOA app server.

On the storage front, we have a Clarion SAN shared with every other server in our data centre.

Let me just stress that out again in case it was not clear: EVERY OTHER server.

That's Aix, Linux, Windows, you name it.

Yes.

You see: we like to run our data centre as a private cloud.

It was that way, long before this expression became common place with people who haven't got a clue what weather patterns are...

So, let me see: the performance has to be abysmal, right?

Because in-house is necessarily bad: outsourced services are much more "specialized" and "cost-efficient", isn't it?

Well, not just quite. You see: it's not enough to quote from "white papers".

I submit the following to your appreciation. It is a 30 second summary sample of the "topas" tool supplied with Aix, from our DW database node. Taken the 24th Dec 2010, around lunchtime. A timeframe that I'd dare suggest is slightly "idle" by definition.

Here it is:

Most Oracle experts nowadays claim that one CPU core is capable of 200MB/s sole absolute max I/O capacity. That's assuming it's not doing anything else.

We have 2 cores here busy as heck with PL/SQL packages. I'd dare say 300MB/s of aggregate mixed reads and writes - that's MegaBytes per second, Virginia! - sustained over a period of 30 seconds WITH an average of 1.1% I/O wait time, is not bad at all.

That's on an idle Xmas eve, in a server that cost half a megabuck and is being shared with 5 other applications and everything and the kitchen sink in the SAN.

I may be an eternal optimist but this nicely fits my definition of "running very well, thank you!".

Check out the number of luns involved in the I/O and the iops and MB/s each is pumping. Pretty even, eh?

But you should listen to the SAN experts telling me I should "balance my I/O". And the Oracle "experts" telling me I should use ASM/RAC/whatever-technology-de-jour they are flogging that week.

Interesting that NOT ONE of those "experts" has EVER asked to see the performance figures of the system.

They just jump straight into "it must be bad" mode.




On a really busy day this system pumps out in excess of 500MB/s, with around 5% I/O wait time aggregate for periods in excess of 1 hour, solid.

But you should hear the "architects" I've been seeing in the last three months telling me the performance would be much better if we outsourced our systems to people who are "experts" on the subject.   For a "lot less cost", of course.

(Interestingly, NOT ONE of them has asked to see the actual current system and its performance figures...)

I suppose that'd involve using a cloud as well because it is "cheap"?

Hang on, but we ARE using a cloud! And we have shared the cost of this infrastructure with our ENTIRE data centre storage resources.  Prove to me you can do it cheaper first!



Hey, I defy ANY "expert" out there to produce a set of figures like this from an EQUIVALENTLY specified system, under the SAME load constraints and sharing the SAME infra-structure cost with everyone else.




And that is the simple reality, folks. Fact, not fiction.
Actual load figures. Not white papers.

You see: I like to show results, not theories.
And I demand to see facts backing anyone else's theories.



Nuff said.

Have a great 2011 everyone!

finally back!

A thousand apologies for the lack of news. Well, it's been a wild ride since the last post, way back in March!

On the work front:

We finally finished the new DR site. And it's all working fine.
Not just that, though: a LOT more!

If you go here you'll see in the files area a presentation on how we do SAN-driven DR database replication. It works with SE Oracle, EE, or any other kind of Oracle licence, if you have a SAN. A little better than Dataguard, which only works in EE.

But I'm quite sure it's all "bad practices" of a dba 1.0 dinossaur. Never mind it's saved us a bundle in licensing costs, as well as being a lot easier to manage and upgrade. Ah yes, that's right: "dbas are expensive". So are Oracle licensing costs - much more, in fact, than it cost to pay me to get this going - in case someone at Oracle hasn't noticed!...

We are also now actively using the lpars and micro-lpars of our Power6 IBM i570 super-server. This system is simply awesome! We can basically carve it in many little or big individual lpars, independently bootable, some with AS400 (i-series) OS in it, others with AIX and/or Linux.

And at any time we can use the hypervisor console to allocate/apportion resources to each virtual box, dynamically or statically and on a schedule, depending on the capabilities of the application software running on each partition. It's mind-blowing! I'm having a lot of fun with this, and so are the "Unix boyzz" at our site!

On another front: we now have a Wintel super-server running VMware, with a few *big* virtual boxes quite happily running SQLServer full systems in them! With SS2008 and Windows Server 2008, it's all quite possible and manageable *if* we take care in allocating resources, disk and memory.

The secret to acceptable performance is to be liberal with the disk allocations, reserving individual SAN LUNs to each of the major I/O impact areas in the SQL Server instances. Namely: the Windows paging file, the tempdb, the log files and the high volatility data files. Plus a few other odds and ends that I won't go into now. And the server VMs are now all referrable via virtual aliases by the app servers.

All this is not just some gratuitous pandering to the "cloud" nonsense. It has a very definite purpose: we can use the virtualization setup to quickly and efficiently clone to DR any environment we need, if/when needed, without any major impact on operations or major scripting hurdles, with just a few mouse clicks! A couple of them and hey presto: the app and the db server are anywhere we want them to be.

Now, to me that's what virtualization is all about. Not the ridiculous claims about "cost reduction and efficiency increase through cloud" and all that jazz: they are true, but not the main driver for this sort of work.

It's been a crazy ride to get all this working, particularly since we still have to provide a fully functional environment to the business. But we're almost done, and it's working like a charm.

And *NO*: it neither cost a fortune in licensing, nor hardware or human resources. And at least having done it in-house, we *know* its limitations and short-comings as well as the ins-and-outs. Which is something outsourcing would never give us! So please, spare me the "cost" comments, OK? You don't know what cost-to-delivery means, if you think this sort of thing is expensive because it was done in-house!



On the personal front:


I was dragged kicking and screaming by some very old friends to spend 10 days in one of the places where I grew up: East Timor!

A group of high school colleagues decided to organize a meetup of students from the 60s and 70s at our old high school in Díli (pronounced dilly). Strangely enough, if you check the meaning of that sound, it accurately reflects what the place is: extraordinarily *delightful*! We had people from all over the world: Cape Verde in Africa's West Coast, Portugal, Mozambique, Timor, Australia, USA, UK, you name it!

I was very reluctant to go there: the place holds some great teenager memories for me and I wasn't sure I'd feel OK when I found out things were a lot different now. They had to be: it's been 41 years since I left and there have been two wars and 25 years of foreign occupation in-between!

I needn't have worried.

Díli is still as amazing a place as it ever was! With the most stunning smiles, stunning sunsets, pristine beaches and coral reefs I've ever seen, and I've been to a LOT of such places. Probably the only place that even *remotely* approaches it in raw beauty is Fiji.

Sure: not all is perfect. The madness of destruction heaped on ET (as we like to call it) by the pro-Indonesian militias after the independence referendum in 99 has left huge, ugly marks... In the city, the country and the people.

But like all other such ugly things, we humans tend to forget them and only recall what is lovely. And there is much to fall in love with, over there. As I hope some of the pics below will convey to you.


East Timor is one of the few places in the Indo-Pacific where coastal coral reefs can still be seen without any human-induced or crown-of-thorns starfish damage:



I call this one "Fallen Star". One of the many species of starfish at the Areia Branca beach.



A volute shell attacking a starfish. This one was a lucky find: this kind of thing is very hard to see live.



Nobel peace prize laureate and current president of East Timor, José Ramos Horta: a high-school colleague and a friend, despite our ideology differences. And Fernanda, a childhood friend who was instrumental in convincing me to go - may your God bless you!



So many great old friends from 41 years ago...



The bay of Díli is a stunning place, every bit as lovely now as back then:



Arbiru Beach Resort, where we stayed. It belongs to a great friend I call my only brother:



This was a very emotional moment: that's the tree I climbed as a teenager to watch the boats entering the harbour. The dark yellow house behind it is where I lived with my parents...



Our old high school, the current university. As lovely now as it was back then.



The view from the city to the Christ statue on the other side of the bay, where the sixth photo above was taken from:



A typical daily sight in Díli. Words fail me to describe its beauty:



And so many others. So many great moments with great old friends, so many emotions...
Catchyalata, folks!

some interesting developments

Apologies for the lack of posts in the last coupla months.

Not only have I been very busy at work, but also a very dear old friend has passed away after a short tussle with cancer. That affected me a lot more than I thought.

Vale, John Alexander Wildgoose.

My fierce Scot friend, IT colleague of 29 years and long time golfing buddy. A master of the comic understatement, his last words to me were: "Well, if this is what dying is about, I'm bored stiff!".
We'll meet again in that ideal superb golf course we talked about, I'm sure. I'll always be proud to have counted you as a friend.



But, back to the grind...

If you haven't yet seen Dan Morgan's page on patches and their use, you owe it to your peace of mind to do it! When is it gonna down on Oracle that MOS is a disaster and the entire design and development team MUST be sent packing?

Anyways... Been tremendously busy with the relocation of our DR site to a new installation over the Xmas/NY break. The need to do this was somewhat unexpected for a number of reasons, and caused us to have to postpone other important work to the start of this year.

The end result being we've been flat out since the start of 2010!

One of the interesting results of this is that we were finally able to use direct dark fibre SAN-based asynchronous replication as the mechanism to transfer data to our DR standby database. This is now done by a set of scripts that control the SAN from the Unix command line, sending out backups and redo log archives on a schedule. These are then rolled forward into our DR instance.

It all works like magic and very, very fast! Somewhat a poor man's auto Dataguard, but a LOT faster!


I'll have to do a session on all that for the Sydney Oracle Meetup folks.

If you are a Sydney DBA with a penchant for "geek" stuff as opposed to certifications, I urge you to join this group: we do some sensational technical talks and there is very little marketing nonsense in our meetings.



Another thing we've managed to get going in the last couple of months is the archival of some of our DW data using partitioning.

Not only were we able to achieve full swap-out-in of data on demand, the performance of existing queries on the partitioned data - with only very minor syntax changes - went up anywhere from twice as fast to 10 times faster. With most in the last category!!!

Even more amazing: that was achived with a single local PK index as opposed to the prior 8 indexes on the non-partitioned table!

This is a perfect vindication and confirmation of my earlier posts on the "nomoore" series.

In there I mentioned the need with vldb to start thinking less in terms of indexing for performance and more in terms of classifying and "binning" very large data sets following classic library techniques. Oracle partitioning is a very good tool to achieve that.

Combined with carefully thought out local indexing, the performance improvements can be quite extraordinary, even dramatic.

As a small side note: we also found a number of bu^H^Hfeatures, particularly in how data pump handles subpartitions and also statistics gathering issues with said sub-partitioning.

Fortunately, all of them solved now!

While I'm here, I must acknowledge and thank Doug Burns for his superb series on partitioning and its statistics: if you haven't read it yet, go there right after this!

Doug has now indexed them and it's easy to follow. Worth your time, I guarantee!


Now the good side of all this is that senior management has finally acknowledged that maybe there is a bunch of committed, competent and enthusiatic people in this team and they have decided to invest some decent funds into our side of IT this year. Instead of listening in to the usual nonsense from external "consultants" with no clue whatsoever about our environment and conditions.

(Yes yes:we'll be in the "cloud". Just not yet, ok?)

There will be some very interesting developments in our DW setup as a result! Not the least of which is we'll upgrade to 11g.

But only r1: r2 is too new for the guys in the US to use and they were burned already by Oracle's usual bu^H^Hfeatures...

As a result, "once bitten twice shy" has taken over and the powers that be don't want the bleeding edge ever again.

Ah well: could have told them as much two years ago when they decided to adopt - untested - 11gr1, because the Oracle rep "recommended they went that way, *everyone else* was".

Yeah! Like...

Live and learn, I suppose. They learned...




On the photography front, I've been having a lot of fun with some small p&s cameras from the film era. Combined with modern film and scanning technique, the results with a humble Oly mjuIII can be quite pleasing, even if not top notch technical quality:




This tree has somehow survived and thrived in a very unfriendly concrete environment...



The front of our place is coming together quite pleasantly. Finally!
Only taken 5 years...



These local swamp hens like to stretch and spread their wings when the weather is very hot: it helps them keep the "Celsius stuff" under control!



If you look close, that seagull looks like it's laughing at the rowers. I called this one:
"amateurs!..."

;)


Cathchyalata, folks!