This post is the second in a series of ten posts exploring some of the Oracle Universal Installer (OUI), Network Assistant (NETCA), Database Creation Assistant (DBCA), Database Upgrade Assistant (DBUA), and many more syntaxes you can use to script or speed up Oracle Installations. The complete series should look like:

1. Installation of 10.2 And 11.1 Databases
2. Patching 10.2 And 11.1 databases (this post!)
3. Cloning Software and Databases
4. Installing a 10.2 RAC Database
5. Add a Node to a 10.2 RAC database
6. Remove a Node from a 10.2 RAC database
7. Install a 11.1 RAC Database
8. Add a Node to a 11.1 RAC database
9. Remove a Node from a 11.1 RAC database
10. A ton of other stuff you should know

In the first post, you can find syntaxes to install a 10.2 or a 11.1 database, and how to apply a Patch Set on top of them. This post is way shorter and digs into a couple OPatch, DBUA, and OUI syntaxes. It explains how to apply a one-off patch, how to upgrade a database and how to uninstall a previous ORACLE_HOME.

Foreword

There are basically two ways to upgrade your Oracle Database Software to a new Patch Set level:

1. The In-Place Way: reuse the same ORACLE_HOME
2. The Out-of-Place Way necessitates that you create a new ORACLE_HOME for the new Patch Set

If the 10g OFA standard contains only the Base Release version, you will be able to perform an In-Place Upgrade. Thi approach, however, has several drawbacks:

• It requires that you stop all the components (Listeners, ASM, Instances, Database Console) during the software upgrade.
• It doesn’t leave the previous ORACLE_HOME install intact, and makes more complex the build of a rollback scenario.
• If you’ve installed a one-off patch, it is very likely the patchset will erase them, but Inventory will keep track of them.

For all those reasons, it’s safer to use a new ORACLE_HOME and so I won’t cover how to perform an In-Place update. Actually it’s not really different, so you should easily be able to build that scenario by yourself. And if you think: “Well, what the use of keeping only the major Database version in the OFA standard if you advise using a new ORACLE_HOME ?”, the answer is: “Once you’ve release the 10.2.0.3 ORACLE_HOME to use a 10.2.0.4 ORACLE_HOME, with that changed in the OFA standard, you’ll be able to use that ORACLE_HOME for the next Patch Set without reinstalling the software and the names will stay consistent!”. But enough of this foreword.

(more…)

Fedora 9 was released on the 13^th. I waited a whole three days to make sure I wasn’t going to be the beta-tester. Then I tried out the live release, and finally decided to upgrade my main workstation to Fedora 9 today. To be sure I wouldn’t mess stuff up, I used the DVD installer to upgrade.

The upgrade finished fine, but when I rebooted, XChat would not run.

[14:15:53]$ xchat
xchat: error while loading shared libraries: libperl.so: cannot open shared object file: No such file or directory

What did rpm have to say about this?

[14:26:31]$ rpm -q xchat
xchat-2.8.4-11.fc8.i386

[14:26:39]$

Hmm . . .  looks like the package did not get upgraded. Wondering how many others did not get upgraded, I did a quick check:

[14:26:39]$ rpm -qa | grep fc8|wc -l
139

Wow! 139 packages still carry the fc8 tag! Next I checked if the updates repository has the updates:

[root@rajlin ~]# yum update
...

...
Transaction Summary
===================================================================
Install     18 Package(s)
Update     148 Package(s)
Remove       0 Package(s)

While I didn’t check all the packages in the list, XChat is definitely there:

xchat                   i386       1:2.8.4-15.fc9   fedora            1.3 M

So did Fedora just push out a release with old packages just to stay on schedule, and is actually releasing packages now hoping nobody would notice? (more…)