Oracle Patch

Oracle Patch

As of 14 July 2009, Oracle is now introducing a new method for patching, patch set updates, or PSU. According to MOSC notes 854428.1 and 850471.1, Oracle PSU is a new patching strategy whereby the DBA can choose only "recommended" and "proactive" patches, instead of all of the patches in a quarterly Critical Patch Update (CPU).



An Oracle PSU contains recommended bug fixes and "proactive" cumulative patches, a nice change that makes it simple for the DBA to choose to apply "priority" patches.


The Database Patch Set Updates and Critical Patch Updates that are released each quarter contain the same security fixes. However, they use different patching mechanisms, and Patch Set Updates include both security and recommended bug fixes. Consider the following guidelines when you are deciding to apply Patch Set Updates instead of Critical Patch Updates.


• Critical Patch Updates are applied only on the base release version, for example 10.2.0.4.0.


• Patch Set Updates can be applied on the base release version or on any earlier Patch Set Update. For example, 11.1.0.7.2 can be applied on 11.1.0.7.1 and 11.1.0.7.0.


• Once a Patch Set Update has been applied, the recommended way to get future security content is to apply subsequent Patch Set Updates. Reverting from an applied Patch Set Update back to the Critical Patch Update, while technically possible, requires significant time and effort, and is not advised.


• One-off patch is specific bug fix for requested customer.




There are critical and DB patches are there and it’s applied to Oracle binaries, DB dictionary and agent services. If you are using RAC patches are available for cluster services also. Mostly it will be consolidated in critical patches which will be released every quarter. You need to have metalink access to download the patches and corresponding document. You need to read and understand carefully this document before attempting applies patches. You may try the patches on testing environment before applying in live.


Patch will be released in January, April, July and October on each year. Doc Id: 1291877.1

imp partition table in different schema

Query I used in par file



file='/oracle/export/tab/tab3a.dmp'
log='/oracle/export/tab/tab3a.log'
tables=esam.summary
query="where TID IN ('010003050000','010003080000','010003090000') AND SUMMARY_PERIOD BETWEEN '01-oct-2010' AND '31-dec-2010'"


exp “'/ as sysdba'" file='/oracle/export/tab/tab3a.dmp' log='/oracle/export/tab/tab3a.log'

Export log


. . exporting table SAM_SUMMARY
. . exporting partition SAM_SUMMARY_04_2002 0 rows exported
. . exporting partition SAM_SUMMARY_05_2002 0 rows exported
. . exporting partition SAM_SUMMARY_06_2002 8000 rows exported


Import into different schema on different server



imp "'/ as sysdba'" file='/oracle/export/tab/tab3a.dmp' log='/oracle/export/tab/tab3a.log' from user='esam' touser='nmapp' ignore=y commit=y


Import log


Export file created by EXPORT:V10.02.01 via conventional path
import done in US7ASCII character set and AL16UTF16 NCHAR character set
import server uses WE8ISO8859P1 character set (possible charset conversion)
IMP-00032: SQL statement exceeded buffer length
IMP-00008: unrecognized statement in the export file:
LESS THAN (TO_DATE(' 2010-04-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')) PCTFREE 0 PCTUSED 95 INITRANS 5 MAXTRANS
255 STORAGE(INITIAL 8388608 FREELISTS 3 FREELIST GROUPS 3 BUFFER_POOL DEFAULT) TABLESPACE "SAM_SUMM_DBF_2010" NOLOG...
 . importing ESAM's objects into NMAPP
Import terminated successfully with warnings.

Cause: Import utility verifies the syntax of all SQL statements in the dump file. Import utility uses default buffer size is 64k, if the SQL statement in the dump file exceeds the default buffer size, then import will be failed and raise 31 & 8 error..



Solution: increase the buffer size

imp "'/ as sysdba'" file='/oracle/export/tab/tab3a.dmp' log='/oracle/export/tab/tab3a.log' from user='esam' touser='nmapp' ignore=y commit=y buffer=100000


Import log


IMP-00003: ORACLE error 959 encountered
ORA-00959: tablespace 'SAM_SUMM_DBF' does not exist
Import terminated successfully with warnings.

My partition table having 50 partitions in prod and each partition in different tablespace but those tablespace doesn’t exist in QA.


Solution: Here we have 2 options to done this job.

1. Create missing tablespace in target, and then run import with buffer size.


2. Reff metalink document (ID: 372992.1) to import partition tables in different tablespace


                     a. Run the import utility with show=y or indexes=filename.sql
                     b. Save the ddl to a script file
                     c. Run the script in target db..

imp "'/ as sysdba'" file='/oracle/export/tab/tab3a.dmp' log='/oracle/export/tab/tab3a.log' from user='esam' touser='nmapp' ignore=y commit=y buffer=100000



this time partition tablespace are imported successfull without any mistake..
:-) feel happy now

------------------------------->>>>>>><<<<<<<<<<<<<<<<<<<---------------------------------------

ORA-27041 in DR

Error: ORA-01186, ORA-01116, ORA-01110, ORA-27041

Overview of the problem

Tablespace was dropped on Primay and archived logs not applied to DR and the below data file was removed from OS level on DR site and below are the errors on DR alert log and DR went down and not starting..

MRP process failling with below error since it could not able to find those datafile physically on DR

ORA-01186: file 35 failed verification tests  

ORA-01116: error in opening database file 35
ORA-01110: data file 35: '/db01/oradata/warm/ASAM200901_f01.dbf'
ORA-27041: unable to open file
IBM AIX RISC System/6000 Error: 2: No such file or directory

Solution: On DR database:

a. Set standby file management from 'AUTO' to 'MANUAL'

            SQL> alter system set standby_file_management='MANUAL';

b. Drop those datafiles what ever appered in the error

SQL> alter database datafile '/db01/oradata/warm/ASAM200901_f01.dbf' offline drop;

SQL> alter database datafile '/db01/oradata/warm/ASAM200901_f02.dbf' offline drop;

c. Recover the DR database 

            SQL> alter database recover standby database;

You may see below errors in alert log and these may be ignored:

Managed Standby Recovery not using Real Time Apply

parallel recovery started with 7 processes
ORA-279 signalled during: alter database recover standby database...
Managed Standby Recovery not using Real Time Apply
MRP0: Some datafile enqueues are still held! Retry recovery...

Thu Feb 12 00:28:39 2010
Errors in file /oracle/admin/asam/bdump/asam_mrp0_770128.trc:
ORA-01124: cannot recover data file 1 - file is in use or recovery
ORA-01110: data file 1: '/db02/oraundo/system01.dbf

d. restart the mpr process..

      SQL> exit
      $ sqlplus "/as sysdba"
      SQL> alter database recover managed standby database disconnect from session;

You should be seeing below in alert log:

Thu Feb 12 00:31:03 2010
Recovery deleting file #35:'/db01/oradata/warm/ASAM200901_f01.dbf' from controlfile.
Recovery deleting file #125:'/db01/oradata/warm/ASAM200901_f02.dbf' from controlfile.
Recovery dropped tablespace 'MTL201026'
Media Recovery Log /db01/oraarch/asam020_1_632092_602170022.arc
Media Recovery Log /db01/oraarch/asam020_1_632093_602170022.arc
Thu Feb 12 00:31:15 2010

we can confirmed the MRP process restarted and we can switch back the file management to 'AUTO'.

       SQL> alter system set standby_file_management='AUTO';
       SQL> exit;
       $ ps -ef|grep mrp

 you see the MRP process..

We also have one more alternate option to fix this problem...

Create standby control file in primary and recovery the standby database, if this option doesn't work then use rman backup and start Point Of Recovery use roll forward..