Like everyone else I like to rant once in a while. I rant about the shortcomings in Oracle software, the tools and technologies I work with. But this time I want to rant about a decisively non-technical topic. Arguably it is something that everyone must have felt - at least once. It's about communicating clearly. Why don't people do it? Why don't they articulate whatever they are trying to say. Instead they spit out incoherently with thoughts coming across as sloppily slapped together expecting the other person to somehow put it all together. I am not talking about children; these are responsible adults who supposedly make up policies and act as thought leaders. Unclear thoughts and communication not only frustrates people; but is dangerous. It misdirects efforts leading to wastage and often utter failure.
Today I had on the receiving end of such a travesty. Earlier, a manager of an application team wrote to me this email (reproduced verbatim) about a requirement:
We are having a shortage of capabilities on the servers. So we want to increase the capabilities somehow. What do you recommend?
I was scratching my head. How can I comment or influence the capabilities of their applications? Perhaps they are asking about some limitations which might be solved by some Oracle technology features. So, I called them for a quick chat. After half hour I still wasn't clear about what limitations they are trying to solve.
And then, after one hour, I got it: they are talking about capacity; not capability! And not only that it's about the database server; not the app server. [Trying to pull my hair out at this time]
My recommendation would have been to send them to an English school; but, being occasionally wise, I kept it to myself.
OK; let's move on. I promised to have a DBA look at the capacity issue.
I recently spent a rather pleasant day at the scottish conference of the ukoug. This was held at the Radisson SAS Hotel just by the central rail station and split into a number of streams, from management through to dba. The organisation of the event was excellent, particularly given the fact that some of the [...]
Store expressions as virtual columns in Oracle 11g. October 2008
The first patchkit for 11g - 188.8.131.52 - came out a few weeks ago, for Linux systems. Unlike most other patchkits, this one contains some new functionalities. Oracle patchkits are usually only bugfixes with al patches regression tested collectively; not added features. This one does have some new (albeit minor) features.
The upgrade was relatively easy but took a long time - about 30 minutes. I encountered one issue and a roadblock. Here is the annoying roadblock
A Very Import Pre-req
Do not forget to check for this pre-requisite. This is the time_zone check, as specified in the patchkit readme file.
SQL> select version from v$timezone_file;
In my case it returned 4, which means no further action is necessary. Had it returned something else, I would have to follow the instructions mentioned in MetaLink Note 568125.1.
Asking for Email for Security Notification
It was interesting to note that the installer asked me to enter my Email address to send me updates on security. Funny; I get that already anyway. So I ignored and clicked "Next". Nope; it popped a little window asking me to confirm that I do not need email. Sure, I confirmed and pressed Next. No, the same issue, it asked me again to confirm and so on. Vicious circle!
There was a little checkbox below that said "track security via MetaLink" and asked my MetaLink password (not "id", which it presumed to be my email). I checked that box and entered my email and password, and it allowed me to go further.
This is a little awkward. Not everyone will want to get the email. And in any case, a mere email will explain little about the security issues. And why would anyone want to embed his/her MetaLink password in a response file?
Undocumented functions in Oracle are always fun, and you just may find something useful.
The caveat of course is that they are undocumented. They can change without notice between releases or patch levels, so building apps that depend on them may be unwise.
They are often quite useful from a DBA perspective when used in SQL scripts.
Here are a few that I've played with. These are all found in Oracle 10.2.0.3
These functions have one thing in common - they have a prefix of SYS_OP_
Some of these appear to be identical to documented functions.