While upgrading 10.2.0.5 database to 11.2.0.3 + Patch 8 on Windows 2008 R2 I got an error message
ORA-00942: table or view does not exist while DBUA was executing “Upgrading Oracle Server” step.
I ignored the error and proceed with an upgrade. A quick grep of the log revealed this:

[excerpt from ORACLE\cfgtoollogs\dbua\ACMEDB\upgrade1\Oracle_Server.log]

....
Rem
Rem Set capture file id equal to replay file id. This is the correct behavior
Rem for non-consolidated replays. Since this is an upgrade, this rule holds.
Rem
update sys.WRR$_REPLAY_DIVERGENCE set cap_file_id = file_id;
update sys.WRR$_REPLAY_DIVERGENCE set cap_file_id = file_id
*
ERROR at line 1:
ORA-00942: table or view does not exist
...
...

It’s a known bug according to MOS Note 1465852.1 “ORA-00942 reports during upgrade to 11.2.0.3 using manual or DBUA”. This bug affects only Oracle 11.2.0.3 for Windows and only if Patch bundle is installed before the upgrade. That was exactly my scenario, I installed 11.2.0.3 and then Patch 8.
According to MOS note we can ignore the error if remaining installation steps finish without errors and if components are valid afterwards:

select comp_name,status,version from dba_registry;

After upgrade we must run scripts that’ll rebuild DB Replay repository objects; just to be sure that we remove any depricated data from repository tables:

cmd>@%ORACLE_HOME%/rdbms/admin/catnowrr.sql
cmd>@%ORACLE_HOME%/rdbms/admin/catwrr.sql

A month ago I hit Bug 13902704 “SRVM.JAR IS LOCKED BY OPATCH 11.2.0.3.0” while trying to apply Patch 3 (Patch# 13570057) on top of 11.2.0.3 (Windows 7 x64 & 2008 R2). With Sysinternals Procmonitor (better than Process Explorer for tracing file usage) I soon found out that opatch 11.2.0.3 itself is locking out of the game install process.
Opatch greeted me with the error shown in the screenshot’s:

Ok, I said to myself, I’ll wait for Patch 4 (13783453), someone at Oracle will certainly notice such an apparent bug. It didn’t happen and I’m not surprised anymore. It’s not that nobody outside of the Oracle Corp. patches Oracle kernel, it’s more likely no one from Oracle Corp. is testing patch installation anymore. At least not in live.
Anyway, according to support note 1446273.1 the workaround for the bug is simple file rename before and after opatch apply:

cmd> move %ORACLE_HOME%\OPatch\jlib\oracle.opatch.classpath.jar %ORACLE_HOME%\OPatch\jlib\oracle.opatch.classpath1.jar
cmd> opatch apply
cmd> move %ORACLE_HOME%\OPatch\jlib\oracle.opatch.classpath1.jar %ORACLE_HOME%\OPatch\jlib\oracle.opatch.classpath.jar

Bug will be fixed in the next opatch release.

Several months ago I got a brand new Lenovo Think Centre workstation at workplace with Windows 7 Enterprise Edition (x64). Of course, the first thing I always do is to install a bunch of Oracle software that serves as a playground. So, I installed 10gR2 and 11gR2 and created test databases for both versions. In addition to RDBMS I installed several other tools that I use more or less on a daily basis, or that I need while reproducing end user errors.
Everything worked as expected. At least at the beginning. After awhile, I noticed unsuspected error while connecting locally as sysdba on 11g instance.
I could successfully “connect / as sysdba” for two or three times in a row after fresh OS reboot, then when I tried to connect for third or forth time in a row as sysdba, I got ORA-01031 error out of the blue sky:

Being a member of ORA_DBA OS group, having SQLNET.AUTHENTICATION_SERVICES = (NTS) in SQLNET.ORA, not having any issues with 10g database, just with a 11g, having the same issue while being a standalone machine as well as being a domain member workstation…
I soon run out explanation other than: “…it must be something about BEQ protocol in 11g and/or some OS specific issue, I’ll troubleshoot later…”. Well, a lot later :-).
Today, I noticed Miladin Modrakovic recently wrote a blog post about errorstack tracing. Hmm…could this help me resolve my sporadic ORA-1031 errors while trying to connect locally as sysdba.

First, I issued:

SQL> alter system set events '1031 trace name errorstack level 3; name library_cache level 10';

and then I was trying to connect without a password:

Now, I should have a trace file generated for the ORA-01031 error, so I looked in alert.log for trace file:

...
Wed Nov 02 14:42:43 2011
Errors in file E:\ORACLE\diag\rdbms\test11\test11\trace\test11_ora_1936.trc:
ORA-01031: insufficient privileges

It took me some time glimpsing through file test11_ora_1936.trc as it was about 38MB in size.
When I saw tnsManager entry in error stack, I knew something weird is going on…

What the heck is tnsManager* doing in the trace file, if I’m not using this service at all in my 11g installment.
It turned out that I somehow forgot that I setup TNS_ADMIN variable system wide pointing to the tnsManager home directory. In that directory sqlnet.ora file was not setup properly (NTS was turned off), don’t have a clue why 10g worked despite that and why 11g worked sometimes. The bottom line is that thanks to error stack trace I was able to pinpoint the problem.

Finally, I disabled tracing with:

sql> alter system set events '1031 trace name errorstack off; name library_cache off';

As Miladin pointed out in his blog, errostack tracing is useful also for other common errors, such as ORA-00942, where Oracle reports error and then it’s up to you to pinpoint which permission is missing and this is more often than not a pain in the *ss.

Side note*: if you’re not familiar with tnsManager then you don’t know what you’re missing, it’s a great little gem….

After I prepared my new Windows 7 Enterprise x64 workstation with a bunch of 64-bit Oracle software, I also needed connectivity to Oracle from various 32-bit software. So, I downloaded and installed the latest and greatest 32-bit Oracle11g instant client (11.2.0.2.0) from OTN with all the goodies, including ODBC driver that I need for troubleshooting support issues of our MS Access 2003/2007/2010 users.

I opened 32-bit ODBC administrator (Windows\SysWOW64\odbcad32.exe) and when I tried to add System DSN with instanclient 11.2 driver I was stopped with the error:

The setup routines for the Oracle in instantclient_11_2 ODBC driver could not be loaded due to system error code 14001.

as shown below :

followed by instruction to check the Event log:

and so I did…

The “Microsoft.VC80.MFC” part of the error message in Event Log was saying that some C++ redistributable libraries were missing. With some trial and miss I found out that I need to install 32-bit Microsoft C++ 2005 SP1 Redistributable Package (x86) on my Windows 7 x64.

I downloaded “Microsoft Visual C++ 2005 SP1 Redistributable Package (x86)” from Microsoft Download Center:

Notice the match of version numbers of libraries as shown on the last two pictures (8.0.50727.762)!

After I installed 32-bit C++ 2005 libraries on my Windows7 x64 workstation I was able to use 32-bit ODBC driver with my Instant client 11g installation.

Until now, I was trying to avoid SUSE/OpenSUSE Linux distros for reasons that goes beyond technology. I must say OpenSUSE pleasantly surprised me with the installation process. Little that I can complain about. Of course, installing Oracle XE 11.2 (beta) was my first post-installation step:

$ cd Downloads
$ wget  http://ftp.novell.com/partners/oracle/sles-11/orarun-1.9-172.20.21.54.x86_64.rpm

[->Download Oracle XE 11.2 Beta into "Downloads" directory from otn.oracle.com.]

$ unzip linux.x64_11gR2_OracleXE.zip

Check if bc (GNU command line calculator) is installed and if it's not install it:

$ sudo zypper install bc

then it's as easy as:

$ sudo zypper install oracle-xe-11.2.0-0.5.x86_64.rpm 
$ sudo zypper install orarun-1.9-172.20.21.54.x86_64.rpm
$ su -
# /etc/init.d/oracle-xe configure
# exit
$ nano $HOME/.bashrc

and add line at the end of file:

. /u01/app/oracle/product/11.2.0/xe/bin/oracle_env.sh

Optionally, you can configure Apex. You’ll find shorcut “Get Started with Oracle Database 11g Express edition” in Application panel. Don’t forget to turn off firewall (or better yet configure firewall to allow access to 8080 or whatever port you chose).

If you want to add your account to dba group that’ll allow you to connect “/ as sysdba” without a password, then:

$ su -
# usermod -a -G dba alesk