Upgradation Category

Archive for the ‘upgradation’ Category

problem with not setting COMPATIBLE parameter

Today i am trying to perform multiplexing one of my production database. My database is using pfile, so i created spfile using

SQL> create spfile from pfile;
File Created

After that i thought of bouncing database so as to make it use spfile and then change control_files parameter.

But to my surprise i got below error while shutdown

SQL> shutdown immediate
Database Closed
Database Dismounted
ORA-00600: internal error code, arguments: [kqrfrpo], [0x095FFA460], [8], [], [], [], [], []

so here you can see, instead of saying “Oracle Instance shutdown”, it throwed an error. Immediately i checked in alert log file for more details and i got “SQL statement not found” statement followed by some addresses of registries in trace file.

I started searching in My Oracle Support (earlier known as Metalink) and found that it is a bug in databases 9.2.0.4 and 9.2.0.6 and it is fixed in 9.2.0.7 patchset.

But my database is 9.2.0.8. really interesting, isn’t it?

SQL> select * from v$version;

BANNER
—————————————————————-
Oracle9i Enterprise Edition Release 9.2.0.8.0 – 64bit Production
PL/SQL Release 9.2.0.8.0 – Production
CORE    9.2.0.8.0       Production
TNS for Linux: Version 9.2.0.8.0 – Production
NLSRTL Version 9.2.0.8.0 – Production

I got a doubt on my compatible parameter and i found as below

SQL> show parameter compatible

NAME                                 TYPE                             VALUE
———————————— ——————————– ——————————
compatible                           string                           9.2.0.0.0

so from this we can understand that, someone who applied the patchset, didn’t modified this parameter which is causing prolems. finally i modified it to latest version and its resolved.

I had also seen many instances from my collegues who forgot to change this parameter and landed into unresolved problems.

So, Guys don’t ever miss this change while upgrading database to higher versions…

warning while upgrading to 9.2.0.4

DOC>#######################################################################
DOC>#######################################################################
DOC>  The following statement may cause an
DOC>  ORA-29554: unhandled Java out of memory condition
DOC>  error.
DOC>  If so, this is because there is insufficient system tablespace,
DOC>  shared or java pool size, or some other resource value is too small.
DOC>  An additional message describing the problem will be output by
DOC>  the statement.
DOC>#######################################################################
DOC>#######################################################################
DOC>*/

you may see above warning when upgrading 9.2.0.1 database to 9.2.0.4 at post installation script execution.

If you follow the upgrade document, you will see a note to have your SYSTEM tablespace left with atleast 10MB of free space and also shared and java pool with 150MB of size each.

If not, your script will fail here and don’t be panic. go back to your database and do the above mentioned modifications and re-ran the script.

Note: It is always preferred to follow upgrade document

How to check conflicts while applying CPU patch?

Hi Friends, today I want to bring an important update regarding Jul CPU 2011 patch applying.

most of the times, we will never check any conflicts for the patches when applying any CPU. ofcourse this conflict checking command is not there even in README.html file that is distributed with patch.

Please use below command to check the conflicts aganist the oracle_home and avoid to land in problems

step 1: unzip your patch zip file
step 2: run below command
$ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir <patch_directory>

Example:

$ unzip p9655017_10204_linux.zip
$ $ORACLE_HOME/OPatch/opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir 9655017
The other day, when I am doing patching on a RAC database, after executing the above conflict command, got below error

Following patches have conflicts. Please contact Oracle Support and get the merged patch of the patches :
6600051, 8836683
Whenever you get this type of error message, plz contact oracle support by raising a service request(SR)

In my case, Oracle support suggested to apply a merge patch 9347333 before applying Jul CPU 2011. Once done with applying merge patch, without any further issues I successfully applied CPU patch

Sometimes apart from above message you may see below warning messages which you can ignore

Summary of Conflict Analysis:

Patches that can be applied now without any conflicts are :
10013975, 10014009, 10014012, 10014015, 10325878, 10325885, 11787762, 11787763, 11787765, 11787766, 12419249, 12566121, 12566124, 12566126, 12566129, 12566131, 12566134, 12566136, 12566137, 12566139, 12566141, 12566142, 12566143, 7155248, 7155249, 7155250, 7155251, 7155252, 7155253, 7155254, 7197583, 7375611, 7375613, 7375617, 7609057, 8309592, 8309632, 8568395, 8568397, 8568398, 8568402, 8568404, 8836667, 8836671, 8836675, 8836677, 8836678, 8836683, 8836684, 8836686, 9173244, 9173253, 9442328, 9442331, 9442339, 9678690, 9678695, 9678697

Following patches are not required, as they are subset of the patches in Oracle Home or subset of the patches in the given list :
10249540, 8836681, 8568405

Following patches will be rolled back from Oracle Home on application of the patches in the given list :
10013975, 10014009, 10014012, 10014015, 10325878, 10249540, 8836681, 8568405, 7155248, 7155249, 7155250, 7155251, 7155252, 7197583, 7375611, 7375613, 7375617, 7609057, 8309592, 8309632, 8568395, 8568397, 8568398, 8568402, 8568404, 8836667, 8836671, 8836675, 8836677, 8836678, 8836683, 8836684, 8836686, 9173244, 9173253, 9442328, 9442331, 9442339, 9678690, 9678695

Hope this post helps you…..

How to migrate Oracle11gR1 database from 32-bit linux to 64-bit linux?

Many a times, we will get a requirement to migrate a database which is there in 32-bit linux to 64-bit. Till 10g, we used to use export/import for this. But Oracle 11g Release 1 provides you an easiest way. Here it is…………

1) First of all, please perform the steps described below:

1.1) Start SQL*Plus:

C:\> sqlplus /NOLOG

1.2) Connect to the database instance as SYSDBA:

SQL> CONNECT / AS SYSDBA;

1.3) Create a .trc file to use as a template to re-create the control files on the 64-bit computer:

SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

1.4) Shut down the database:

SQL> SHUTDOWN IMMEDIATE;

1.5) Perform a full offline database backup.

1.6) Backup your 32-bit Oracle Home (this step is optional since you can restore it from a fresh installation).

2) Install Oracle Database 11g Release 1 (11.1) for 64-bit Linux.

3) Copy the 32-bit datafiles to the new 64-bit Oracle home.

4) Copy the 32-bit configuration files to the 64-bit Oracle home:

4.1) If your 32-bit initialization parameter file has an IFILE (include file) entry, then copy the file specified by the IFILE entry to the 64-bit Oracle home and edit the IFILE entry in the initialization parameter file to point to its new location.

4.2) If you have a password file that resides in the 32-bit Oracle home, then copy the password file to the 64-bit Oracle home. The default 32-bit password file is located in $ORACLE_BASE/$ORACLE_HOME/database/pwdSID.ora., where SID is your Oracle instance ID.

5) “This step is required on Windows platforms only”. In the 64-bit Oracle home, add the _SYSTEM_TRIG_ENABLED = false parameter to the $ORACLE_HOME/database/$ORACLE_SID/init.ora file before changing the word size. It is recommended to set _SYSTEM_TRIG_ENABLED=FALSE in the following document though:

=)> Oracle® Database Platform Guide
11g Release 1 (11.1) for Microsoft Windows
Part Number B32010-02

==)> Migrating an Oracle Database 11g Release 1 (11.1) Database

Note: On Linux/Unix there is not need to add _SYSTEM_TRIG_ENABLED=FALSE to init.ora file, when the database is started in upgrade mode _SYSTEM_TRIG_ENABLED is automatically set to FALSE.

After starting 10.2.0.3 in upgrade mode with 11.1.0.6 software alert log file shows:
==============================================================
” ALTER SYSTEM SET _system_trig_enabled=FALSE SCOPE=MEMORY;
Autotune of undo retention is turned off.
ALTER SYSTEM SET _undo_autotune=FALSE SCOPE=MEMORY;
ALTER SYSTEM SET undo_retention=900 SCOPE=MEMORY;
ALTER SYSTEM SET aq_tm_processes=0 SCOPE=MEMORY;
ALTER SYSTEM SET enable_ddl_logging=FALSE SCOPE=MEMORY;
Resource Manager disabled during database migration: plan ” not set
ALTER SYSTEM SET resource_manager_plan=” SCOPE=MEMORY;
Resource Manager disabled during database migration
Starting background process FBDA “
==============================================================

6) Go to the 64-bit ORACLE_HOME/rdbms/admin directory from the command prompt.

7) Start SQL*Plus:

SQL> sqlplus /NOLOG

Connect to the database instance as SYSDBA:

SQL> CONNECT / AS SYSDBA;

9) Re-create the 64-bit control files using the CREATE CONTROLFILE command using the trace file created in the step “1.3)“ as follow:

9.1) Edit the as follow:

9.2) If it is required, please change the paths to the datafiles, log files and control files to point to the Oracle home on the 64-bit computer. This creates the new control file in ORACLE_HOME/database.

9.3) Here is an example of a database named “orcl32″ on a 32-bit computer moving to “orcl64″ on a
64-bit computer:

CREATE CONTROLFILE REUSE DATABASE “T1″ NORESETLOGS NOARCHIVELOG
MAXLOGFILES 32
MAXLOGMEMBERS 2
MAXDATAFILES 32
MAXINSTANCES 16
MAXLOGHISTORY 1815
LOGFILE
GROUP 1 ‘/oracle/product/11.1.0/oradata/orcl64/REDO03.LOG’ SIZE 1M,
# was ‘/oracle/product/11.1.0/oradata/orcl32/…LOG’
# on the 32-bit computer
GROUP 2 ‘/oracle/product/11.1.0/oradata/orcl64/REDO02.LOG’ SIZE 1M,
GROUP 3 ‘/oracle/product/11.1.0/oradata/orcl64/REDO01.LOG’ SIZE 1M
DATAFILE
‘/oracle/product/11.1.0/oradata/orcl64/SYSTEM01.DBF’,
# was ‘/oracle/product/11.1.0/oradata/orcl32/…DBF’
# on the 32-bit computer
‘/oracle/product/11.1.0/oradata/orcl64/RBS01.DBF’,
‘/oracle/product/11.1.0/oradata/orcl64/USERS01.DBF’,
‘/oracle/product/11.1.0/oradata/orcl64/TEMP01.DBF’,
‘/oracle/product/11.1.0/oradata/orcl64/TOOLS01.DBF’,
‘/oracle/product/11.1.0/oradata/orcl64/INDX01.DBF’,
‘/oracle/product/11.1.0/oradata/orcl64/DR01.DBF’
CHARACTER SET WE8ISO8859P1;

9.4) For additional information please check the next note:

10) Having a copy of the initialization parameter file (from the 32-bit computer), please include the new control file generated in the preceding step.

11) Shut down the database:

SQL> SHUTDOWN IMMEDIATE;

12) Start the database in UPGRADE mode to run utlirp.sql:

SQL> STARTUP UPGRADE;

You might need to use the PFILE option to specify the location of your initialization parameter
file.

13) Set the system to spool results to a log file for later verification of success. For example:

SQL> SPOOL mig32-64.log;

14) Enter the following command to view the output of the script on-screen:

SQL> SET ECHO ON; 

Handling for JVM during Migration

When migrating a database from 32 to 64bit (or vice versa) additional actions

are required for java.  In theory the format of java shared data objects (SRO)

is not compatible between 32 and 64 bit and so these objects need to be dropped

and regenerated.  In practice it may be the case prior to release 11 such

objects could interoperate but if so this would only be by chance and should

not be relied on.

The steps to do the regeneration are as follows.  These should be done

immediately before running utlirp.  They may take several minutes to complete.

They must be done connected as SYS.

begin

  update obj$ set status=5 where obj#=(select obj# from obj$,javasnm$

    where owner#=0 and type#=29 and short(+)=name and

    nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');

  commit;

  declare

    cursor C1 is select

       'DROP JAVA DATA "' || u.name || '"."' || o.name || '"'

       from obj$ o,user$ u where o.type#=56 and u.user#=o.owner#;

    ddl_statement varchar2(200);

    iterations number;

    previous_iterations number;

    loop_count number;

    my_err     number;

  begin

    previous_iterations := 10000000;

    loop

      -- To make sure we eventually stop, pick a max number of iterations

      select count(*) into iterations from obj$ where type#=56;

      exit when iterations=0 or iterations >= previous_iterations;

      previous_iterations := iterations;

      loop_count := 0;

      open C1;

      loop

        begin

          fetch C1 into ddl_statement;

          exit when C1%NOTFOUND or loop_count > iterations;

        exception when others then

           my_err := sqlcode;

           if my_err = -1555 then -- snapshot too old, re-execute fetch query

             exit;

           else

             raise;

           end if;

        end;

        initjvmaux.exec(ddl_statement);

        loop_count := loop_count + 1;

      end loop;

      close C1;

    end loop;

  end;

  commit;

  initjvmaux.drp('delete from java$policy$shared$table');

  update obj$ set status=1 where obj#=(select obj# from obj$,javasnm$

    where owner#=0 and type#=29 and short(+)=name and

    nvl(longdbcs,name)='oracle/aurora/rdbms/Compiler');

  commit;

end;

/

create or replace java system

/

15) Recompile existing PL/SQL modules in the format required by the 64-bit Oracle Database (utlirp.sql script changes the words size):

SQL> @utlirp.sql;

16) Turn off the spooling of script results to the log file:

SQL> SPOOL OFF;

17) Check the spool file and verify that the packages and procedures compiled successfully. Correct any problems you find in this file.

18) Shut down the database:

SQL> SHUTDOWN IMMEDIATE;

19) Start the database:

SQL> STARTUP;

20) Recompile existing PL/SQL modules in the format required by the 64-bit Oracle Database (utlrp.sql script recompile the invalid objects):

SQL> @utlrp.sql;

21) “On Windows platforms only, if you added the “_SYSTEM_TRIG_ENABLED = FALSE” parameter to your initialization parameter file in step “5)” above, remove the parameter from the initialization parameter file, and then shut down and restart the database.”

For more info, refer to MOS doc 548978.1

Major Change from 11.2.0.2 patchset

I hope all are aware that we have a 11gR2 patchset available 11 months back. The patchset release is 11.2.0.2

Oracle brought a huge change in patch set installation starting from 11.2.0.2. In past releases patchsets used to have files to fix bugs in lower versions. But from this version, patchset also includes full database software.
This is the reason why you will see 4.8 GB size when you try to download 11.2.0.2 patchset.
Because the release 11.2.0.2 patch set is a full installation package, You are no longer required to install the base release, and then apply the patch set. If you don’t have an existing database, after installing this patchset, we can create a new database. But if we have an existing database with 10g or 11.2.0.1 versions, we can use any of the following upgrade methods

1. Out-of-place upgrade – In this way, we will install the patch set into a new, separate Oracle home location. As it is already consists of latest version 11.2.0.2, we can directly start upgrading database using DBUA or manual mode. This will avoid patching the existing base version of oracle software. Oracle recommends that we perform an out-of-place patch set upgrade, because this patch set application option requires much less downtime.  But the prerequisite for this method is that we have sufficient free disk space to accommodate two Oracle home directories at the same time.

2. In-place upgrade – In this way, we will install the patch set into an existing Oracle home location. Oracle recommends that we select this option only if you do not have sufficient free disk space to perform an out-of-place upgrade, as the upgrade removes the existing Oracle installation. This patch option requires less disk space, but requires more time, and is riskier, because if you encounter an installation failure, then you must recover the entire existing Oracle home from a backup. If you choose this more risky option, then before you begin the patch installation, complete the following tasks:
Make a complete backup of your existing Oracle home
Read through the entire Upgrade Guide section dealing with in-place upgrades
Direct upgrade from previous releases: You can upgrade from a previous Oracle Database release directly to the latest patch set, without having to install the base release. For example, if you want to upgrade from Oracle Database 10g Release 2, then you can upgrade directly to Oracle Database 11g Release 2, patch set 2 (11.2.0.2) using an out-of-place upgrade.

Oracle says “we implemented this procedure of including full software in patchset as most of our customers prefer it as it gives the benefit of less downtime. Also this will continue for all the patchsets released here after”

Problem in upgrading 10g to 11g on Linux

Hi Friends,

I have got a new learning yesterday when i about to upgrade a 10g (10.2.0.4) database to 11g (11.2.0.1). Let me explain what I did.

1. I am already having a 10.2.0.4 database
2. I installed 11g software in another location
3. I changed environmental variables pointing to new 11g home
4. I started DBUA, where it failed with following error

An unexpected error has been detected by HotSpot Virtual Machine:
#
# SIGSEGV (0xb) at pc=0xa2bbd36e, pid=19555, tid=3085252272
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_17-b02 mixed mode)
# Problematic frame:
+# C [libnnz11.so+0x3c36e]+

Note: The error shown here may not be same when you face this problem.

After analyzing the error through google and oracle support, I got to know that it is because of a BUG 8670579 and will be fixed by applying a patch to newly installed 11g software.

Then i download the software from Oracle support (metalink) – p8670579_112010_LINUX.zip

I recommend to apply patch following README document (basic steps are as follows)

[oracle@server1 ~]$ export ORACLE_HOME=/u03/ora11g
[oracle@server1 ~]$ opatch lsinventory
Invoking OPatch 11.1.0.6.6

Oracle Interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation.  All rights reserved.
Oracle Home       : /u03/ora11g
Central Inventory : /home/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.6
OUI version       : 11.2.0.1.0
OUI location      : /u03/ora11g/oui
Log file location : /u03/ora11g/cfgtoollogs/opatch/opatch2011-02-03_08-09-14AM.log

Patch history file: /u03/ora11g/cfgtoollogs/opatch/opatch_history.txt

Lsinventory Output file location : /u03/ora11g/cfgtoollogs/opatch/lsinv/lsinventory2011-02-03_08-09-14AM.txt

——————————————————————————–
Installed Top-level Products (1):

Oracle Database 11g                                                  11.2.0.1.0
There are 1 products installed in this Oracle Home.
There are no Interim patches installed in this Oracle Home.
——————————————————————————–

OPatch succeeded.

[oracle@server1 ora11g]$ unzip -d /u03/ora11g /u01/p8670579_112010_LINUX.zip
Archive:  /u01/p8670579_112010_LINUX.zip
   creating: /u03/ora11g/8670579/
   creating: /u03/ora11g/8670579/files/
   creating: /u03/ora11g/8670579/files/lib/
   creating: /u03/ora11g/8670579/files/lib/libnnz11.a/
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/ahseteco.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/am11rkg.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/amsha.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/cpui32.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/sha.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/x931rand.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/am11dkg.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/am931rnd.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/amsharnd.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/ghash.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.a/shacomm.o
  inflating: /u03/ora11g/8670579/files/lib/libnnz11.so
   creating: /u03/ora11g/8670579/etc/
   creating: /u03/ora11g/8670579/etc/config/
  inflating: /u03/ora11g/8670579/etc/config/inventory.xml
  inflating: /u03/ora11g/8670579/etc/config/actions.xml
  inflating: /u03/ora11g/8670579/etc/config/deploy.xml
   creating: /u03/ora11g/8670579/etc/xml/
  inflating: /u03/ora11g/8670579/etc/xml/GenericActions.xml
  inflating: /u03/ora11g/8670579/etc/xml/ShiphomeDirectoryStructure.xml
  inflating: /u03/ora11g/8670579/README.txt
[oracle@server1 ora11g]$

Shutdown all the previous versions of oracle databases and also stop listener, EM and Grid control services (if running any). After that run below command

[oracle@server1 ora11g]$ cd 8670579
[oracle@server1 8670579]$ ls
etc  files  README.txt
[oracle@server1 8670579]$ opatch apply
Invoking OPatch 11.1.0.6.6

Oracle Interim Patch Installer version 11.1.0.6.6
Copyright (c) 2009, Oracle Corporation.  All rights reserved.
Oracle Home       : /u03/ora11g
Central Inventory : /home/oracle/oraInventory
   from           : /etc/oraInst.loc
OPatch version    : 11.1.0.6.6
OUI version       : 11.2.0.1.0
OUI location      : /u03/ora11g/oui
Log file location : /u03/ora11g/cfgtoollogs/opatch/opatch2011-02-03_08-14-07AM.log

Patch history file: /u03/ora11g/cfgtoollogs/opatch/opatch_history.txt
——————————————————————————–
The patch has more than one Archive Action but there is no Make Action.
——————————————————————————–
ApplySession applying interim patch ’8670579′ to OH ‘/u03/ora11g’

Running prerequisite checks…

OPatch detected non-cluster Oracle Home from the inventory and will patch the local system only.
Please shutdown Oracle instances running out of this ORACLE_HOME on the local system.
(Oracle Home = ‘/u03/ora11g’)
Is the local system ready for patching? [y|n]
y
User Responded with: Y
Backing up files and inventory (not for auto-rollback) for the Oracle Home
Backing up files affected by the patch ’8670579′ for restore. This might take a while…
Backing up files affected by the patch ’8670579′ for rollback. This might take a while…

Patching component oracle.network.rsf, 11.2.0.1.0…
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/ahseteco.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/am11rkg.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/amsha.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/cpui32.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/sha.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/x931rand.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/am11dkg.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/am931rnd.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/amsharnd.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/ghash.o”
Updating archive file “/u03/ora11g/lib/libnnz11.a”  with “lib/libnnz11.a/shacomm.o”
Copying file to “/u03/ora11g/lib/libnnz11.so”
ApplySession adding interim patch ’8670579′ to inventory

Verifying the update…
Inventory check OK: Patch ID 8670579 is registered in Oracle Home inventory with proper meta-data.
Files check OK: Files from Patch ID 8670579 are present in Oracle Home.

The local system has been patched and can be restarted.
OPatch succeeded.

After this step I am successful in invoking DBUA and completed my database upgrade to 11.2.0.1 version.

Hope this post will help you…….

Error while applying patchset to 10g database

Hi Friends, its been quite long time that we talked about technical articles….(its just because i got busy with new responsibilities). From now i will make sure, i will post some helpful posts regularly

Today, lets discuss about an error that occurs on windows box when you try to install patchset…

As we all know whether it is windows or unix machine, we need to stop all services before installing patchset software. Recently i was doing this in one of my prod env (windows box) and all of a sudden during installation, i got below error

“Error in writing to file D:\Oracle\product\10.2.0.2.0\bin\oraevrus10.dll”

I ignored this error thinking nothing will happen…but its my biggest mistake (thats the reason DBA should never think, he should know…and that knowing comes only by practise or testing in test machines)

After i ignore that error, everything went fine and when i try to run any command like sqlplus, dbca etc..i got below error message in a popup window

The procedure entry point kglsim_cln could not be located in the dynamic link library orageneric10.dll

This will happen because of the error i ignored during installation and that error will occur because one of oracle service will not be stopped sometimes (thats why i hate oracle administration on windows box )

I fighted alot with that and finally came with an idea of re-installing the patchset again. But to do this, we need to reboot the server. I am having 3 more databases of other versions on the same machine, but i can’t proceed further without downtime which was even confirmed by oracle support.

I informed the client about this and to my luck i got downtime (please do remember, this might not happen always. so we need to very careful and whenever you are doing the same activity in future, make client aware that you may require downtime)

After reboot, i started OUI and reinstalled the files and it went successful….

Note: After installing patchset, don’t forget to upgrade your database