just some basic stuff

...that's been bugging me for a while, about time I blog about it.

This post is mostly for my own reference.

Although of course it might be useful for the odd budding dba out there who still believes the command line is a useful weapon in their armory.
Yeah, they do exist!

I'm one of them, thank you.

So, have you been using sqlplus of late? And been bugged by the default Oracle data format we all hate since R3?
Yes, that one: DD-MON-RR.
You know, good ole:


SQL> select sysdate from dual;
SYSDATE
---------
19-MAR-12


Annoying, isn't it? Particularly when you have to check the time, or sort things by date. It's not easy to read, and I'll leave it at that!

Of course, one can do:


to_char(sysdate,'YYYY-Mon-DD HH24:MI:SS')


whenever one selects SYSDATE, or any other date column. And get back a nicely formatted timestamp that actually means something in an ordered list:


SQL> select to_char(sysdate,'DD-MON-YYYY HH24:MI:SS') from dual;
TO_CHAR(SYSDATE,'DD-MON-YYYYHH24:MI:SS')
------------------------------------------------------------
19-MAR-2012 14:50:14


But I'm lazy and I hate typing too much. Besides, it's only too easy to mis-type some of that.

So, what are the options available for those of us who insist on using the command line tools?

First, we can always set a default, database-wide parameter - NLS_DATE_FORMAT - to the format mask above.

Something like:

NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'

Be that via spfile or init.ora.

And we'll promptly break ALL applications we may be running that rely on the 25 year old default date format!


Needless to say, there might be a few gentler ways of achieving this!...

Here is one - for good old SQL*Plus:

We can at login time alter our session - and ONLY our SQL*Plus session - to set the NLS_DATE_FORMAT parameter to an adequate format string.

sqlplus will execute at login time any commands it finds in the $ORACLE_HOME/sqlplus/admin/glogin.sql file.


But just like before: this is a global SQL*Plus setting, so ALL sessions - ours and ANY other batch or interactive SQL*Plus sessions will inherit this setting!


Fortunately, there is a way around that. SQL*plus can also look for a "local" login.sql file. Note that this one doesn't have the "g"-leading name!

But in order for it to recognize that file, we need to set an environment variable that tells it where to find our default *.sql files. It's called SQLPATH.

So, if we set for example


export SQL_PATH=$HOME/sql;.


then sqlplus will look at login time for a file called "login.sql" in either our $HOME/sql directory (where we stash all our home-brew scripts, right?) or in the current directory - the ";." bit in the command above.

If we then add a suitable alter session to that login.sql file, the default date format will change only for sqlplus client users.

Very useful. And sometimes it can still get us into strife!

How?

Well, that thing will apply to only ALL sessions of SQL*Plus executing under that login. Be they us, or a batch sql cron job, or something else running that command line program. And only to SQL*Plus!
If we use any other interactive client command line product, it won't recognize this change in default date format.

Ideally then we need something that can be recognized by all client tools we may be running from the command line, not just SQL*Plus.

It turns out there is such an animal. Yes, it is another environment variable. Or rather: two environment variables to be set.

Here they are - for my system:


$export NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'
$export NLS_LANG=AMERICAN
$unset SQLPATH
$sqlplus
SQL*Plus: Release 10.2.0.3.0 - Production on Mon Mar 19 17:19:04 2012
Copyright (c) 1982, 2006, Oracle. All Rights Reserved.
Enter user-name: / as sysdba
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bit Production
With the Partitioning, OLAP and Data Mining options
SQL> select sysdate from dual;
SYSDATE
--------------------
19-MAR-2012 17:19:12


These will apply to all client sessions - SQL*Plus or otherwise - started in that terminal and will not affect any other logins.

The interesting thing is that the manual where this is mentioned seems to imply that only NLS_DATE_FORMAT is needed. In fact you need both variables, otherwise the date format will be ignored!

So, how do you find quickly what NLS_LANG value to use?

Look it up in DATABASE_PROPERTIES:


1 select property_name,property_value
2 from database_properties
3* where property_name = 'NLS_LANGUAGE'
SQL> /

PROPERTY_NAME PROPERTY_VALUE
------------------------------ ------------------------------
NLS_LANGUAGE AMERICAN



And that's about it for now.


Guess who joined our family ranks recently:


That's Tiago(Diego) on the left: our new great dane, all 60Kgs(!)of it. Ziggy - our old standard schnauzzer - is on the right, getting very annoyed!
I call this one:
"you toucha my buddy, I breaka ya face!"
but you need to be from Australia to understand it! ¦D

Catchyalata, folks!

lose ends...

Finally worked out how to change the admin email ids in the blog!

For some reason I never quite fathomed, Google took the wrong email id for admin of this blog when they took over Blogger. With the result that for quite a while I had to login with a different address than my usual gmail and/or yahoo to administer this blog.

It's been a pain in the you-know-what to manage, with yet one more email account to forg^H^H^H^Hremember!

I finally had some time to waste, wading and searching through Google's tons of unrelated help screens to find out how to change the admin logon email to a new one. Sometimes I wish Google's programmers stopped trying to second guess what I want to see and just showed me what I asked for? No more, no less?...

Turns out the fix is a quite easy multi-step process, after all. So now I hope to have a more streamlined and accessible way to publish here. Which hopefully will be reflected on more postings from now onwards.

I'll also be posting more on trivia and day to day IT things rather than just databases and Oracle. It's a much better way to keep this blog active. And let's face it: Oracle databases are not such a big single part of my professional life anymore.

With my time being shared between Oracle, MSSQL, DB2, Data Management and Integration, backups and archival, SAN management and architecture and all sorts of other Data Centre activities, I find I have little spare time to dedicate to the latest watchamacallit CBO/trace/weirdo feature that no one in his right mind will ever bother with, other than in the academic sense! :-)

Don't get me wrong: academic is good! What I don't have time for is the last squiggly bit of analisys that it often demands.

Others can - and should! - do that. I have a Data Centre to help run - hopefully reliably and with good performance - and a bunch of Data Management and DW oriented folks that demand my help. They demand most of my time.

Speaking of which...

We are about to embark in another year of Sydney Oracle Meetup activites. It looks like it's gonna be an interesting one, we've got some really cool ideas for 2012.

And with the NSW Oracle User's Group finally showing a little bit of interest in our activities instead of the usual "who are they?" attitude (that serves no purpose whatsoever), things might even become a lot more interesting for everyone - their membership included. We shall see...

Meanwhile, just a quick shot from a time not so long ago when I had a proper 4WD and was allowed to use it for what it was designed for:



That was taken in a place called Catherine Hill bay, during one of our monthly land-based game-fishing escapades. Man, I miss those times! Nothing like a 20Kg yellowfin tuna heading for New Zealand to bang your eyes open in the early morning!

Then again nowadays I go to places like, this once a year or so:



Not so much for fishing anymore. Mostly, for underwater photography and general lazing about. It's the place where as a kid, I first developed a taste for diving. I am truly blessed that I can still go back and enjoy it, almost as it was back then.


Anyways: catchyalata folks, or likely sooner!

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!