Category: Oracle

That’s the second week of disaster recovery testing over. It went a lot better this time. We can definitely recreate out production RAC, cold-failover clustered infrastructure and our application server layer, which is a massive relief.

There have been lots of lessons learnt, and lots of new documents generated. I’m hoping the next test in a few weeks will be a walk in the park 🙂

You get so complacent about your documentation until someone else has to follow it. As part of the “What happens if I get hit by a bus?” paranoia that these tests produce, I’ve started capturing screen shots of all the Linux OS installations. I did a load at the weekend that will be used to create a “fool-proof” idiots installation guide for work, but I also captured some images with less sensitive information to produce some pages for my website. They’ll just be pages full of images, like the Solaris install article, but they might come in handy if people are unfamiliar with the OS installation process. I’ll write a post when they are done…

Cheers

Tim…

PS. All weekend PC support duties were completed. My Dad now has ADSL and some AntiVirus software. The world can sleep safe tonight! 🙂

Here’s a not-so hypothetical situation:

You install your 10g RAC on Tru64 and dutifully write down exactly what you did. Once it’s working you feel happy you could repeat the process. Indeed, you have to when you install your test and production environments. Everything works and your documentation looks good.

Fast forward to a disaster recovery test and your installation procedures don’t work anymore!

Question:
The same kit is working in production, so what’s the difference?

Answer:
The software was installed on the production system, but the kit was later upgraded (more CPUs and memory) to it’s current configuration.

When attempting a fresh install on the revised configuration Oracle seemingly uses a different bunch of flags during the linking phase, which doesn’t affect the software installation, but results in “ORA-12547: TNS:lost contact” when the DBCA attempts to connect to an instance. This is repeatable from SQL*Plus.

A quick relink using the following commands and everyone is happy.

cd $ORACLE_HOME/rdbms/lib
make -f ins_rdbms.mk numa_off
make -f ins_rdbms.mk ioracle

So, back to the question that is the title of this post.

Question: Could you reinstall your Oracle software without a problem?
Answer: If you’ve dabbled with the hardware, maybe not 🙂

Cheers

Tim…

When you run installations and patches you often have log files full of error messages that can be ignored, such as dropping objects that don’t exist prior to creating them, or in some cases creating objects that already exist. As a result, trying to identify “real” errors is like looking for a needle in a haystack.

It would be nice if these meaningless errors could be supressed. I guess it would be a little like the IGNORE=Y option in the import utility.

Of course, there is a judgement call about what constitutes a real error. In some cases, an object not being present when you try to drop it signifies something is very wrong, but for many scripts it’s no big deal.

If Oracle included a “DROP object IF EXISTS” syntax like mySQL, and maybe even a “CREATE object IF MISSING” syntax, it would be a real bonus.

I feel an enhancement request coming on 🙂

Cheers

Tim…

Update: The enhancement request has now been logged on Metalink (ER# 5151826) 🙂

I’m pretty pissed off this morning. It seems I’m at the center of some “Oracle on FC5” conspiracy because a few idiots can’t be bothered to read articles properly. The article in question is:

https://oracle-base.com/articles/10g/oracle-db-10gr2-installation-on-fedora-5.php

The original warning at the top of the article read:

“THIS IS A DRAFT DOCUMENT. It will be revised when the final version of FC5 is released.”

Apparently, this meant it was a fully finished article that should be trusted implicitly! See the conspiracy:

comp.databases.oracle.server

Also, it seems I should reply to comments while I’m sleeping.

Oracle community… My arse!

Tim…

I received a desupport notice this morning for, amongst other things:

• iSQL*Plus version 10.2
• SQL*Plus Windows GUI version 10.2

This sounded a bit odd, as both are the latest versions of the products. I checked the desupport date and in both cases it was 31-July-2010. This just seems plain stupid to me. Why produce a desupport notice for a product, when there is currently no natural upgrade or replacement available. Surely it would be better to wait for the release of Oracle 11(x) Database before issuing this notice.

I guess we can expect the desupport notices for the next version of the database before it’s actually released!

Cheers

Tim…

Update: I just noticed that Laurent Schneider has written something about this. Although I believe SQL Developer is an acceptable replacement for the GUI SQL*Plus, I don’t like the thought of having to have Oracle Application Express (HTML DB) to replace iSQL*Plus.

Access to all sites is fine, including Oracle sites, but Metalink is freaking out and causing me to constantly re-login to my proxy… Wierd…

Some time towards the end of last week I saw a blog post saying a new early adopter release of SQL Developer was available. I went to OTN to download it today, and there is now an official production release available. That came out pretty sharpish! 🙂

Cheers

Tim…

Yesterday was a tough day…

I had a call at 02:30 about an extract job (written in Java) that was taking hours to run. After 2 hours of pratting about trying to get it working I gave up and went back to bed. As soon as I got to work I recoded the process in PL/SQL. It was a case of “if it compiles it must work”, because we had very little time to test the process before the next run was required. Fortunately, it worked fine. Did it improve the situation? The original extract took several hours, the PL/SQL version took 23 seconds. Sweet!

What was slowing down the original process? Some bright spark thought it would be better to pull back a huge table into an array and loop through it to searching for data, rather than writing a query to pull back a single row. This action was repeated for every line written to the extract file. There were an assortment of other classic bits of code also, including (the names have been changed to protect the “not so” innocent):

switch (getType())
{
case TYPE_CONST1:
sb.append(TYPE_CONST1);
break;
case TYPE_CONST2:
sb.append(TYPE_CONST2);
break;
}

Now, I’m no Java Guru, but for a mandatory item with only two allowed values, I instantly spotted that this actually meant:

sb.append(getType());

Conclusion: If you want data-intensive code to run fast, put it in the database and get someone who understands databases to write it!

Once all the fuss was over, I noticed that the front page of my website wasn’t working properly. It turned out that the OTN RSS news feed was broken, and my dodgy PHP code didn’t trap the error very well. I fixed the error trapping and informed Oracle about the news feed. Within a few minutes the OTN news feed was restored, so all was fine again.

Conclusion: My PHP isn’t as good as my PL/SQL 🙂

Cheers

Tim…