Yeah... Aka: Oracle Enterprise Damager...
For those who might not know - yes, quite a few of the so-called "cognoscenti" are not all-knowing! - we've been engaged in using grid control to monitor all our db servers for quite a while.
That's both MSSQL and Oracle RDBMS servers.
For 4 years now!
In a nutshell and to cut a very long story short:
- we started with 10g. The lesser said
It's interesting how from time to time something happens that makes sense and seems logical afterwards, but at the time it causes a bit of a surprise. Part of the fun of working with this type of software!
A few days ago we had an incident in an Oracle DW database wheb a developer tried to load an infinitely big file from a very large source. Yeah, you got it: big-data-ish!
Suffice to say:
Dang, been a while since the last posts! A lot of water under the bridge since then.
We've ditched a few people that were not really helping anything, and are now actively looking at cloud solutions, "big data" use, etcetc.
Meanwhile, there is the small detail that business as usual has to continue: it's very easy to parrot about the latest gimmick/feature/funtastic technology that will
Some quick and basic Unix and ksh stuff that crossed my path recently.
As part of the move of our Oracle dbs to our new P7+ hardware (more on that later...), I'm taking the opportunity to review and improve a few of the preventive maintenance and monitoring scripts I have floating around.
Some were written a few years ago by other dbas and have been added to by myself as needed. Others were
First of all, apologies for the long delay between posts. We've been evaluating various avenues for the cycle of hardware and software refresh in our data centres and for obvious reasons I could not make any public postings or comments that might be mis-interpreted by the various suppliers.
In these situations there is a confidentiality protocol that must be followed and simply cannot be broken.
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
Sorry for the marked absence of posts, folks. This year we've been upgrading all our Oracle dbs to 184.108.40.206 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
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.
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
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.
...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