Search

Top 60 Oracle Blogs

Recent comments

Oakies Blog Aggregator

RMAN Usage Survey

As part of a presentation I'm preparing, I would like to get an idea of RMAN usage in the Oracle Community.

If you can spare a couple of minutes, please fill out this 10 question multiple choice survey: RMAN Usage Survey

Update:

It seems I made a poor choice of online Survey site.

To get more than 100 responses to this survey, a "Professional" version must be purchased. At a rate of 1 or 2 surveys a year (for me) that is not exactly practical.

Sharing the Survey results also requires the Professional version.

Here's a summary of the results in MS Excel.

RMAN Usage Survey Results

Thank you!

Exception enhancements in 10g

A few small enhancements to exception handling/error messages. June 2004

Loading xml files with xml db

A tutorial on loading XML files into relational tables. March 2006

Unconventional Oracle Installs, part One

You have to watch this:

http://www.youtube.com/watch?v=CHzV4LZnvHc

We'll follow it up with a few other initiatives in order to help the big companies bring down the time spent to install Oracle from, say, 50 hours to one or two.

Perrow and Normal Accidents

While reading the book 'Deep Survival' (most kindly given to me at the UKOUG conference in Birmingham by Sir Graham Wood of Oracle after the fire in my house) I happened on a description on page 107 of a book called 'Normal Accidents' by a fellow named Perrow (get it? per row - a perfect name for database nerds).

Perrow's theses is that in any tightly coupled system - in which unexpected interactions can happen - accidents WILL happen, and they're NORMAL.

Also, he states that technological steps taken to remedy this will just make matters worse.

Perrow and IT systems
=====================
I have freely translated Perrow's thoughts into the following:

IT systems are tightly coupled. A change - a patch, a new application, or an upgrade - to a layer in the stack can cause accidents to happen, because they generate unexpected interactions between the components of the system.

This is normal and expected behaviour, and any technological gear added to the technology stack in order to minimize this risk will make the system more complex and therefor more prone to new accidents.

For instance, I find that two of the most complexing things you can do to an IT system are clusters and SAN's.

These impressive technologies are always added in order to make systems more available and guard against unexpected accidents.

Hence, they will, in and by themselves, guarantee other normal accidents to happen to the system.

Complexing and de-complexing IT systems
=======================================
So you could say that it's a question of complexing or de-complexing IT systems.

I have found four situations that can complex IT systems (I'm being a bit ironic here):

1. To cover yourself (politics).
2. Exploration.
3. SMS decisions.
4. Architects.

1. Reason One: To cover yourself (politics)
===========================================
You might want to complex systems in order to satisfy various parties that you depend on or who insist on buying certain things they've heard about at vendor gatherings:

"Yes, we've done everything humanely possible, including buying state-of-the-art technology from leading vendors and asking independant experts to verify our setup".

This is known as CYB (Cover Your Behind).

2. Reason Two: Exploration
==========================
Ah, the urge to explore unknown territories and boldly go where no man has ever gone before...

Because you can.

The hightened awareness thus enabled might be A Good Thing for your system and your customers.

It could also create situations that you and others find way too interesting.

Reason Two is often done by men, because we love to do stupid or dangerous things.

3. Reason Three: SMS decisions
==============================
A third reason for complexing IT systems could be pure ignorance in what is commonly referred to as Suit Meets Suit (SMS) decisions - where a person of power from the vendor side with no technical insight talks to a person of power from the customer side with no technical insight.

These SMS situations tend to cause considerable increases in the GNP (just like road accidents and fires) of any country involved because of all the - mostly unneccessary - work following.

The costs to humans, systems and users can be enormous. Economists tend to love it.

4. Reason Four: Architects
==========================
A fourth reason for complexing IT systems can be architects. Don't get me wrong: There are many good IT architects. The very best ones, though, tend not to call themselves architects.

One of my dear friends once stated that an architect is often a developer that can't be used as a developer any more. Very funny.

However, what I have witnessed myself is that the combination of getting further away from the technical reality and getting closer to the management levels (the C class, as it were) tend to make some architects less good at making architectural decisions after a while.

That's where the vendors get their chance of selling the latest and greatest and thus complexing new and upcoming systems.

Summary: The end of reasoning
=============================
Four reasons must be enough. There are probably more, but I cannot think of them right now.

Anyway, imagine what savings in costs and worries you can obtain by moving just a notch down that steep slope of complexity in your system.

You might be able to de-complex your system to a degree where it becomes
absolutely rock solid and enormously available.

That should be our goal in the years to come: To help our customers de-complex their systems, while of course trying everything we can to support those who chose to complex theirs.

Two new angles on tuning/optimising Oracle

Now and then some new angles and thoughts emerge in a field where a lot of people think there's not much new to be said.

Two examples:

1. James Morle told me a while ago, that he thinks all performance problems relate to skew, to latency, or to both. It's brilliant, I think. I hope James will one day write about it. He's a damn fine writer when he gets down to it.

2. This one from Dan Fink. Impressive piece, I think. Enjoy it.

http://optimaldba.blogspot.com/2007/12/how-useful-is-wait-interface.html

When I emailed Dan and told him I admired his angle on this, he responded:

"I think it is a matter of keeping an open mind and knowing that you have friends and colleagues who are open to new ideas. Support is absolutely critical, even when you don't necessarily agree with what is being said. That keeps the flow of information open.

I shall never forget walking into a conference room. In big letters on one of the whiteboards were the words "THINK OUTSIDE THE BOX". For emphasis...someone had drawn a nice large box around them! "

I like that one :-)).

Google - just another big, dumb, brutal organisation?

I found this article in The Economist interesting:

http://economist.com/business/displaystory.cfm?story_id=10328123

There's some truth there, I think. Google is buying stuff (like blogger), is making pirate copies (sorry: clones) of other companies' software and in general trying to be as dominant and brutal as Microsoft, IBM, Oracle and the others. Yawn.

What the Hell happened to "Don't do evil"? Why did Google sell out to the Chinese horror regime?

They're just after the money and the happiness of shareholdes. Boring stuff.

Mogens

Mobile phones, fats and backups

As with such things, life has been rather dull since the fire - relatively speaking. Fortunately, I had a wonderful thing happening to my mobile phone that brightened several of my days before Christmas.

It all started about half a year ago, when the menu button on my Nokia E60 stopped working. That's rather inconvenient, but I could still call people up and receive calls, so no big problem.

Then, one Saturday in December, the old team from the National Nurses' Dormitory in Copenhagen had our annual, traditional, Danish Christmas lunch in a place called Told & Snaps in Copenhagen. When the frist dish was brought in - pickled herrings, of course - my dear friend Ole and I decided to see if soft butter on the keys could bring the menu button back to life. So we, uhm, buttered the keyboard - and it worked! The menu button worked again!

Flushed with succes we decided to try and repair the problems I had with the microphone and loudspeaker in the E60. So we used fat (from a duck, I think) on the, eh, bottom of the phone. Didn't seem to have the desired effect. In fact, in the days that followed I had to shout louder and louder in order for people to hear me. It was getting silly - I had to be in the privacy of my car in order not to disturb the general population with my shouting.

But I could still send and receive SMS messages, so things were OK.

Then my wife Anette and I had dinner at restaurant Avanti and that's when Anette hit the oil lamp on the table so that the E60 became soaked in oil. The display looked like a lava lamp and the keys became very loooong and soooft to use.

During the night, while I was asleep, the E60 sadly expired.

That's when I discovered that my 800 contacts were residing inside the E60, not on the mini-SD-card. So I got a new phone from a friendly phone broker (an N-73, which seems to be a fine phone, by the way) but every call I received were wonderfully new and exciting since I didn't recognice any of the numbers.

Of course I didn't have any backup. I'm a man.

Then a miracle happened. Anette and some good Miracle folks managed to wake up the phone for a short while and unload my contacts. That was a good day.

So people have told me: This will teach you to remember to take a backup!

But look at it this way: I started carrying a mobile phone 25/8/370 back in 1991 and this was the first time I was in danger of losing everything. And I have never taken a backup.

Chances are it won't happen again anytime soon either, unless somebody steals it.

So I think I'll continue with my usual mobile phone backup strategy :-))).

Merry Christmas.

Mogens

The Fire, part II

Turns out there are many more good things to be said about this incident:

a. The entire house will be cleaned for Christmas.
b. All windows will be cleaned.
c. The entire first floor will be re-painted.
d. We'll get a complete list of our posessions.
e. Since the entire first floor has been emtied, we can now do all the things we always dreamed of doing up there.
f. My hand-made Italian shoes will be replaced, which is good, since little Viktor removed one of my shoe laces some months ago, and we haven't been able to locate it since.
g. We now live (with the consent of my wife Anette) on top of a bar, and the owner - Jytte - is one of the most heart-warming people I've ever met. Her magnificient helper Linda immediately moved out of her apartment so that we could stay there - just to mention one detail out of many.
h. Christmas will be special this year, no matter what happens. Just like in the movies, where the Christmas peace is secured in the last minute.

I cannot even begin to see the downsides of this unfortunate incident :-))).

Mogens

SQL Developer Migration Workbench

After years of relying on third party developers to create GUI tools for use in developing SQL on Oracle databases, the SQL Developer application was released by Oracle.

First released as Raptor, this is not new news. What is new however is version 1.2.

SQL Developer 1.2

Being a dyed-in-the-wool sqlplus and vi kind of guy, I have never made extensive use of SQL Developer, though I do use it a lot when browsing schemas and/or data.

What I discovered today however was just an amazing addition to SQL Developer.

With version 1.2 , the Migration Workbench has itself been migrated, into SQL Developer.

SQL Developer Migration Workbench

I had occasion today to make use of the migration workbench, and I was impressed with how simple it was to migrate SQL Server data to Oracle.

SQL Developer was able to connect directly to SQL Server, create a migration catalog, generate scripts to duplicate the SQL Server database objects in an Oracle Schema, and migrate the data.

The documentation for actually doing the migration is pretty good.

Setting up the native authentication was somewhat problematic however.

The SQL Developer documentation referenced earlier does a good job of showing you how to setup the JDBC connection, but does not explain how to setup Windows Authentication.

The solution was found after rooting around in the SQL Developer forum.

The JDBC driver used to connect SQL Developer to SQL Server is from the jTDS Project.

After extracting the jdbc driver from it, another file needs to be extracted where it can be used by SQL Developer.

This file is ntmlauth.dll, found in the x86/SSO path in the jtds zip file.

Assuming that SQL Developer was installed on a Windows box at C:\sqldeveloper, ntmlauth.dll needs to be copied to c:\sqldeveloper\jdk\jre\bin.

After doing that, Windows authentication from SQL Developer to SQL Server worked perfectly.

The entire process of migrating the data from SQL Server to Oracle was pretty much a point and click affair.