more trouble with details...

I've said it before here and will say it again: the Oracle implementation of proxy logins is flawed from the start.

I've given at least one demonstration of why.  And why using ALTER SESSION SET CURRENT_SCHEMA is a much more manageable and secure alternative.

Despite that, folks insist and persist on using proxies...

Consider Tom Kyte's article on the latest Oracle magazine, with the examples of login A and login B.  I won't repeat the article here.  Just go read it - or better yet, open the mag next to the screen and look here and there. Yeah, like that. Works for me! ;)

In the article our technologist claims that this is the correct way to get a login to impersonate another.  Nothing wrong with the article, mind you!
It might be on paper and manuals, but day to day practicalities say it isn't, hence my disagreement.

For example of just a few glaring problems with the proxy login approach:

1. If we use the construct exampled by Tom in the article, we must connect to the database as
   connect a[b]/a.
   Ie, a completely non-standard, non-intuitive connect command, with the login name defined as a[b] - how many tools/apps do you know of that simply won't accept that sort of syntax for a login name?  I know a few, try any odbc connection and watch what happens.  Worse yet: try to explain to an end user their login name is a[b] from now on?  Good luck...
2. Once we are connected, access to system privileges - and ONLY those! - is controlled by a role that MUST be assigned to login B.  Not login A!  Ie, we want to restrict what login A can do - or indeed any other login that might also be a proxy - but we define that role and attach it to login B? It should be associated with A - and any other users that may need to be attached to login B.  Not to login B.
3. The role restriction is incomplete.  It works fine for system privileges, but it does NOT stop login A for example from being able to see all rows in ALL tables of login B!
   Try it - repeat the example from the Oracle magazine in your system, only this time add only SELECT privilege on a suitable table owned by login B.  Then login as A[B].
   You'll notice that regardless of what you put in the role, you'll be able to see ALL tables of login B, and SELECT/INSERT/UPDATE/DELETE from them all!
4. Worse: now go into v$session and v$process and see if you can see login A anywhere?  It's simply not there!  What you see is an additional login B.  So much for making it easy to identify who is who logged on to the database, eh?

By comparison, were we to use what I showed here a while ago and create login A as a simple user, then create a role, assign whatever we want to it - yes, system privileges, table access privileges, whatever! - then grant the role to login A only, we'd be able to simply create a login trigger for login A that does a

ALTER SESSION SET CURRENT_SCHEMA=B,

We would then be able to login to A - no need for fancy syntax - then we would be able to see all tables from login B that were granted to the role - and ONLY THOSE - as well as having whatever system privileges were granted to the role.  And anyone using v$session/v$process to monitor who is logged in, would see a login A - not login B!

I still think if Oracle made CURRENT_SCHEMA one of the context-controlled variables, the whole process would even be simpler: just give the correct schema to a custom context - together with any other variables, roles, etc, then simply make a login use that context as a default, like it is already possible to do. 

But I'll settle for a connect trigger for the time being, in the absence of  a better solution.

There are likely a lot of other examples of why using a login trigger doing an alter session set current_schema is a much better solution than the machiavelic proxy login a-la Oracle.
But to me the above are more than enough to shoot down the whole concept and use instead my approach.

And I couldn't care less if "triggers are evil" - or whatever the latest crusade is.

Sorry, but like I said before: the campaign to eradicate trigger use is ill-guided and ill-directed!
Yes, without a shadow of a doubt: triggers can be dangerous.
That is NOT a synonym for always dangerous!

On another note:

A coupla years ago I posted a performance screenshot from one of our prod db servers, at a supposedly idle time - Xmas eve, lunch-time.  In it was clearly shown the system was under quite a lot of I/O load, although not under any real stress.

That was enough for a lot of comments to start in the intervening time as to how "some DBAs never strive to improve their systems" and "always resist any change".  From the usual FUD sources.
Coincidental of course with Oracle trying to flog a bunch of Exa* whatever boxes on us, against my recommendations...  ("You're a *bad* dba, Nuno!" was the least that was invoked back then...).

Well, this was taken a few weeks ago during a restore from a backup into our development DW server, as part of a regular monthly refresh from the production backup.  Bear in mind it's a dev server, with no particular emphasis on its overall performance.

OK, so in two years we went from 300MB/s overall aggregate in production to 800MB/s in a non-critical, non-production server, with 670MB/s of those being in WRITES - not READS! - and with an overall busy time for disk devices of 21% while the CPU is nearly flat out.
You should see the production box now...

Kevin Closson would - rightly so! - say we're CPU-starved.  Of course.  But then again this is a restore from a compressed backup, where CPU in user mode is being pushed to expand the data.  And it is only run once a month, so I'm not really that worried about what it uses then - for the 3/4hour it lasts. Not worth any battles to fix that!

This was achieved with NO upgrade to hardware whatsoever.  The OS was upgraded to Aix 7.1 and Oracle upgraded to 11.2.0.3, that's all.  Plus a lot of work on how we split our Aix box into lpars and what is assigned to each in terms of memory, CPU, disk controllers, SAN LUNs, etcetc.
Cost?  3/4 of NULL == NULL.  Other than my time of course, which is part of my normal salary - I'm not a contractor here.

We do not strive for improvements, eh?  Sure...  Any other pearls of idiocy?


Anyways, on to some fun.  This fella showed up in a local park a while ago:

Lovely animals.  And of course, Victoria the Littoria is still around:

Catchyalata, folks!

Exadata "marketing" and reality

Sorry for the marked absence of posts, folks.  This year we've been upgrading all our Oracle dbs to 11.2.0.3 and all our MSSQL dbs to 2008R2 - hectic is an understatement for how things have been!

On top of that we've been told we may need to increase the size of our main Oracle dbs by 10X in the next 2 years. So, in the process of upgrading I had to ensure the groundwork for that sort of expansion was in place.  Not easy - believe me - when one doesn't even know what the hardware platform is going to be for that expansion!

All we can do is make sure whatever that ends up being, the database setup and structure will be such that the future hardware will be able to respond to the increased workload, without any artificially imposed database-related restrictions.

I'm thinking small detail things.  Like for example: ensuring all relevant tablespaces are using ASSM and bigfiles.  And so many other little doo-dahs without which, no matter what the hardware, we'd hit the wall if we didn't do it upfront.

Of course we are now going through the pains of selecting a future platform.  Which might be "IaaS"!...

For the Oracle space, we are starting from a highly evolved IBM Aix 7.1 P6 elastic private cloud platform that contains not only our database servers but also *all* our Oracle-related application servers as well as all the SOA-related midleware, with a few exceptions covered in Linux and/or VMware.

And of course: in the last few months we have been subjected to intense bombardment from what Oracle calls Exadata "marketing".  Almost constantly...

In the last week or so, I've seen even more incredible claims being made for the Exadata platform.Go read that dross now, please.  But come back here after you finished: I'm not done with it yet. Far from it!

I've already commented in a couple of places on its totally wrong conclusions.  But in all fairness to the owners of those blogs: I should also comment here rather than impose my views on theirs!
Sorry, folks. Consider this my apology for not having had the time to do it earlier!

Let me just say this upfront: I do NOT HAVE ANYTHING AGAINST Exadata - the product!  There: is that sufficiently CLEAR?

Exadata is a great piece of gear, eminently suitable to the task it was designed for.  Which is to be a database machine.

If it is the best or most cost effective for such is debatable and I am open to other opinions.  But without a doubt it is one of the best database machines ever made available.

And for those who have followed this blog for years, you can see how much I like the design: I made the "No moore" series of posts in 2006 and early 2007, describing portions of its architecture LONG before Exadata existed as a product!

As such, I have an axe to grind when I see its value being totally mis-represented in the above piece of imbecile marketing from Oracle!

I don't know who came up with the idea for that TCO "comparison". But let me just say something very clear about it:

its total and undeniable IDIOTIC approach to "comparison", if anything, will hurt Exadata more than favour it!

At least amidst folks who haven't yet outsourced their entire thought process!

Why?

Well, let me just say something that is VERY obvious:  would you do a TCO comparison between a F1 racing vehicle and a family SUV and then claim that because the F1 vehicle can run at 300mph the SUV is of little value to go shopping on weekends and ferry the kids to-and-from school?
 
No?  How DARE you!
Why not?

Let me hazard a guess: because such a comparison would be totally and completely imbecile?

Narh!, of course not!  :)

You see: Exadata is a database machine.  Like the Britton-Lee boxes of the 70s/80s.  Which later were absorbed by Teradata while their OS and software became Sybase.

As such, it is a very highly SPECIALIZED piece of machinery.  Made to do one task - and one task only - very, very well and very, very fast!

No doubt or qualm whatsoever about that from me.  Far from it, in fact!

What it is NOT  by ANY stretch of the imagination - other than what passes for the mind of the imbecile who created the above marketing piece - is this: a general purpose computing platform!

And if one buys a Exadata box in the hope of using it to run a series of applications against Oracle databases, they may end up having a slight problem trying to run such applications inside the Exadata hardware!

Mostly because it cannot run ANYTHING other than Oracle databases!

As such, to come up with a TCO comparison that CLEARLY and obviously ommits the ADDITIONAL cost of purchasing the NECESSARY application running hardware to match and drive the Exadata database machine, is my definition of complete lah-lah-land.

And a great dis-service to the Exadata folks and those who have invested time in learning its intrincate internals!

You see: the IBM P7 hardware is what normal folks - not lunatic and totally IT-ignorant marketeers - call general purpose computers.

In simple terms: you can run just about ANY piece of application AND database software in them.
Same box, virtualized, in just about any quantity and mix!  In fact, they actually can do more: they can even run DB2, Oracle, Peoplesoft, SAP, Confusion, whatever, ALL at the same time and concurrently, in the same box.

Heck: our P6 - the previous generation - runs AS400 emulation with DB2, Oracle 10g for Peoplesoft AND Peoplesoft application servers, a 11gr2 DW, a general purpose 11gr2 database for about 10 other applications, Apex web servers - AND a large mix of application servers,  ALL in the same box, without missing a beat.  Our uptime before we re-loaded it with 11gr2 and Aix 7.1 was in excess of 3 years.  I don't even know what that is, in days! But I'm willing to bet around 1000?

In simple terms again: general purpose computers are a SUV that can be used for a great many tasks.

Hence their intrinsic value: one doesn't have to buy ANY OTHER processing platform!

You buy an IBM P7, you don't need to buy another computer: it's all there to run ALL your general data centre needs, from data processing - to number-crunching - to output preparation.  Virtualized or not for quick provisioning, is entirely your CHOICE.

OF COURSE, you need to buy storage!  That is NOT the point! We are talking computers, not disk farms!

Try that with Exadata?  Slightly difficult, isn't it?  It only runs Oracle databases- not DB2, not ANYTHING else.

What's that you saying? Exadata has all the storage needed?

:)     REALLY???  All of it?

Where then do you store the interface data files and data sources/sinks for your databases? And the software for your applications?  And all the rest needed to run a COMPLETE data centre - not just one piece of it?

To do anything with Exadata, one MUST spend ADDITIONAL money purchasing the hardware to do the rest!

Now, mr Imbecile Marketeer: WHY was that ADDITIONAL cost NOT taken into consideration in that idiotic TCO comparison?


Does it even register with this kind of person the dis-service they have just given to Exadata and the folks who invested their time on it?

Because ANY "decision maker" with one picogram of intelligence will CLEARLY see the imbecile nature of that comparison and how useless it really is.

And very likely promptly dismiss any thoughts of purchasing such hardware from a company that promotes this sort of idiocy!

Sorry, but it needed to be said.  I'm sick and tired of these idiotic "campaigns" designed to seduce IT-ignorants based on "Ooooh-Aaaah!" instead of solid, simple, TRUE AND SENSIBLE FACTS!
 And there are PLENTY of such to support Exadata without resorting to imbecile arguments!

Enough is enough!

And that's about it for the time being.

I've been somewhat active this year with the SydneyOracle Meetup folks and we still have one more meeting before the end of the year.
It's been a lot of fun, with lots of new folks and students showing up.
And a bit challenging: we have to structure our presentations in such a way that they can be interesting for students and beginners, mid-journeyman and folks that have been at it for a LONG time! 

But we've had a lot of help and the good folks at Pythian have been very gracious in continuing their sponsoring of our meetings.  Thanks heaps, Paul, Alex, Yury and the rest of the gang!

(Hello, mr Oracle: it might be in YOUR interest to also sponsor here and there. After all it's YOUR software that we are talking about.  And we have a LOT more attendees than that nonsense you sponsor under the flag of "Australian Users Group".
Just saying...)


Or rather - see who came visit after a nearly two year absence due to a dishonest builder destroying their habitat near my house:

Yes!  The little green tree frogs that were so frequent around here are finally back!  Stuff you and your construction company very much, mr Triguboff: you're right up there with the Scott Cassins of this world, in my book...

These little fellas are between 1/3 and 1/2 inch long and are absolutely GORGEOUS to observe in their natural environment.  Live and let live.

Recently I spent some time down the South Coast, near the industrial town of Port Kembla.  It's amazing how this sort of thing can exist only a couple of miles from a major industrial complex:

Suddenly, there were people, seaguls, a pelican and a mini-horse in the frame!  All in perfect communion, all unaware of what goes on further down the estuary.  I love this place!


Anyways: catchyalata, folks!

An only too easy trap...

The few who follow this blog know I don't at all like the way Oracle is slowly forcing customers to use the OCM and direct Oracle support links, for patching and upgrades.

Why?

It's very simple: our db servers are in an intranet, in a designated set of subnets that will N-E-V-E-R be open to anything past the DMZ. And even then only as the originators and to a known IP address.

This, I stress again, will N-E-V-E-R change!

There have been numerous attempts from external "con-sultants" to change this state of affairs. Under all sorts of argumentation - including the tired old "your dba is an incompetent" - and all have resulted in nothing.

Nuff said?  Now, to this blog entry.

As part of our 11.2.0.3 upgrade to our 10.2.0.3 db servers, I have downloaded the April 2012 PSU for Oracle on Aix and tried to install it.

Not because I am terribly fond of the latest-whitest-brightest mantra but because in the list of fixed bugs there are a few that might be relevant to our processes.  And I prefer to be pro-active than reactive.

Yes, I DO read the readme files! I don't need some idiotic piece of Oracle software to do it for me.

It's a quaint concept, but it comes with the territory of hiring someone who can actually read and think at the same time. Rather than just push buttons.

So how come I "tried" to install the PSU? Well, you might say that something went amiss.

To put it simply: the opatch program version released with the standard 11.2.0.3 distribution is actually release 11.2.0.1.7 of opatch!

And the April PSU patch for 11.2.0.3 requires which opatch release?

...
...
...

what for it...

...
...
...

opatch 11.2.0.3!

Wonders will never cease!...

Unbelievable that in this day and age something so wrong as this can evade the so-called QA of Oracle software releases.

Ah well...

So, after a quick call to Oracle Support I got back the URL to download the correct version of opatch. Yes, I DO know the URL is also embedded in the readme file for the PSU!

How about making it the FIRST paragraph of the pre-requisites section of the readme, mr Oracle?
Narh! Too common sense and easy, isn't it?

Anyways: downloaded and installed opatch following the readme instructions. Which promptly wiped out the existing OPatch directory under $ORACLE_HOME.

One wonders what would have happened to any patches I might have installed in between initial 11.2.0.3 and the PSU, mr Oracle?

Details, Nuno. Details... Why worry about what could have happened?

Besides, the readme for the PSU explains what to do in case that happens and how to recover from it.

Only it's hidden away at the end of the file.

Instead of being RIGHT UP FRONT where it would have been easy to find and useful.

Isn't it mr Oracle?

Ah yes: we need to impress on folks the "need" for Oracle-managed services instead of relying on those pesky dbas that actually check what the heck is going on in their systems, isn't it?  So, let's lay down a trap for them.

As if...

But, I digress.  I was finally able to run the correct opatch for the PSU I was installing.

Only to be greeted with a bunch of questions about how to get my db servers to connect to www.oracle.com!  Apparently, THE "new" feature of opatch 11.2.0.3!

When is it gonna dawn on the idiotic marketeers of Oracle that there is simply NO WAY a lot of customers out there will ever authorize their db servers to directly connect to the Internet?  Proxy or no proxy?

No! We do NOT want to connect to your "management services"!!!


Nor is that in any way, shape or format desirable or even in scope.  As such, kindly STOP THE NONSENSE once and for all!

Here is a hint, mr Oracle: STOP trying to force on us how we should run our data centres!

Or we'll simply move to DB2 or MSSQL.  Where we are not told how to setup our computers: it's a lot simpler there and no one is forcing us to do things their way.

Capice?

Don't say I didn't warn...

Anyways, enough of the Oracle marketing lunacy.


I like this:

This couple just hopped out of the trike and started to exercise right in the middle of the Sydney CBD. After a while, they both hopped back in and kept going. WTH????
One of my cyberfriends has tried the leg position of the guy in the photo. Only to end up with a persistent joint pain! :-)

One sees the weirdest things on top of the Sydney CBD buildings:

All we have to do is look up!

Catchyalata, folks.

Finally!

Regular readers of this irregular blog will recall it's a loooong time since I had anything positive to say about Oracle and its marketing and support organization.

Mind you: it's not a problem with the folks that man the fort at MOS - or whatever the blessed thing is called this week!

In general I've found them competent and helpful and have actually recommended quite a few for service awards. They know who they are.

It's more to do with those who are supposed to get us technical information and instead regularly regurgitate tired old MOTS - as in More Of The Same - marketing nonsense.

Understand this, please: I have nothing against RAC, Exa%, (con)Fusion and all the other bits and pieces that Oracle has been flogging for the last 9 years or so.

Each has its application and place in this world of IT.

But when I ask their techos and support for information on 11gr2 upgrades, I do NOT want to hear an endless mantra and an interminable peroration on the subject of how well RAC/Exa% brews coffee and works at Telstra/Westpac/CommBank/Amazon/eBay/bleeding-whatever!

Those businesses have nothing in common with what we do, nor is anything they do even remotely relevant to us!

It was therefore with the usual dose of suspicion I received an invitation to attend the recent "Upgrade to 11gr2" seminar in Sydney.

Now, most of you folks know I am not the earliest adopter of new releases. Mostly because I used to do it. Until one day I grew a conscience. And point blank refused to introduce even more bugs at my consultancy's clients. Moving right along, nothing to see here...

11gr2 however has been in my sights for a long time - it really has some nice features - and now that our 10gr2 is about to go the way of the dodo in terms of support, it's time to start looking into it.

Yes, that's right: I'm going to skip 11r1! I know it's nowadays very stable but I have to think ahead more than 1-2 years: whatever upgrade I do now has to last until at least 2016 or thereabouts - we cannot afford the constant re-testing of yearly database software upgrades!

Now, from past experience I know how quickly local "seminars" can degenerate into "dba1.0 vs 2.0" deranged nonsense and other such childish attacks on every dba that doesn't burn a candle to the great RAC/Exa% marketing altar - at least twice a day.

As such I was ready for another day of boring marketing nonsense - hey, I was tired and I needed a break from work, OK?

Needn't have worried. Mike Dietrich and his boss Roy Swonger delivered a sensational seminar, full of exceptionally useful and pertinent information!

And I mean U-S-E-F-U-L!

All the way down to expected problem areas, known bugs and gotchas, snags to be aware of, impact on typical applications, good/bad things to do. All very down to earth and all very techo stuff.

And they did it all without ONCE mentioning we should be upgrading to ASM/RAC/grid/cloud/Fusion/Exa%/whatever!!!

AMAZING!

But not only that. They actually made the contents of their presentation (wow, that link is in Apex!) public and available to all.

MAN! What is going on, mr Oracle? Useful, pertinent and helpful stuff in a technical seminar?

I am almost speechless!

In passing, I must acknowledge and thank the local marketing folks for organizing this and inviting me to attend. They knew we were looking into 11gr2 and this ended up being incredibly spot-on!

I was going to take an ultra-conservative approach to our upgrade process, which would have lengthened it beyond what I'd really like.

But after this seminar I got such great feedback and good information on the concerns I had that I was confident enough to simplify the process somewhat.

Which I did, following the advice from Mike and Roy. And tried and tested it in a small db that I could easily adapt to our brand new sandpit server where I "break" new software.

I'm extremelly glad to report it all worked exactly as those folks said it would, all the way down to the smallest details including the gotchas and little nags that upgrades always bring.

Can only highly recommend other folks looking into upgrading to 11gr2 - or even 11gr1 - to actually download and read the presentation above. Careful: give yourself plenty of time - it is HUGE! Or definitely attend the seminar if it comes your way.

Job well done, Mike and Roy. Thanks heaps for the great information and suggestions and your help in answering some of my concerns.

Made the day worthwhile. Although very tiring! ;-)



Anyways, on to the normal close: some images concocted by yours truly here and there.

This one is from last Xmas, at work:



I love those decorations. Mind you: they are hard to grab in colour, indoors and without flash. But with patience it works.



I like the way some lenses give an almost "night light" effect:



Usually folks shun these cheap lenses but used in context they can be useful to convey and highlight an "end of day" feeling.

The street organ at the Canberra Floriade:



I go there on purpose every year to see this thing and listen to it. It is truly a marvel of engineering and music.

And there is plenty of other fun stuff to do nearby:



although not quite for my age and size anymore... ;-)

Once the Floriade day is over, nothing better than a great steak at:



Catchyalata, folks!

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!