Patch Set Updates (PSU) :
=========================
Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule.
PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October.
The contents of the PSU include :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Critical technical issues with fixes that may affect a large number of customers and that are already proven in the field
- Critical Patch Update fixes
Example:
PSU 11.2.0.3.3 contains all molecules previously released in CPUApr2012, new CPUJJul2012 molecules and Generic Recommended Bug Fixes
The PSU and CPU released each quarter contain the same security content.
- A PSU can be applied on the CPU released at the same time or on an any earlier CPU for the base release version.
A PSU can be applied on any earlier PSU or the base release version. CPUs are only created on the base release version.
- Once a PSU has been installed, the recommended way to get future security content is to apply subsequent PSUs.
Reverting from PSU back to CPU, while possible, would require significant effort, and so is not advised.
For more information, please refer :
Note 854428.1 Intro to Patch Set Updates (PSU)
With PSU, Oracle has made it easier for customers to obtain and deploy fixes for known critical issues encountered in targeted environments and configurations, this provide proactive patch recommendations to customers seeking to upgrade or to improve the stability of their current environments.
PSU's are a combination of Oracle Recommended Patch Bundle and CPU
Oracle continues to recommend one-off patches; and when these one-off patches meet the PSU inclusion criteria, they are incorporated into the next PSU to be released.
The PSU's are regression tested so the chances of a bug fix creating a change in behaviour won't occur as :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
They will fix a set of critical issues commonly encountered in targeted environments and configurations.
They will stabilize production environments because the patches address the known critical issues.
They will help save time and cost by eliminating rediscovery of known issues.
They are tested as a single combined unit, resulting in increased quality and eliminating the risk of combining patches that are only independently tested.
They make it easier to identify patches applicable for a targeted environment/configuration.
Please mark the the thread as Helpful or Correct to help other users to find questions that were answered.
he following steps load modified SQL files into the database. For a RAC environment, perform these steps on only one node.
For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql cpu apply
SQL> QUIT
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./
The need to have the same password for Apps and Applsys is because when you sign on to apps, intially it connects to a public schema called APPLSYSPUB. This validates AOL username and password that we enter (operations/welcome using guest user account. Once this is verified we select responsibility, this is validated by APPLSYS schema and then it connects to APPS schema.
Since it uses both applsys and apps during signon process this expects both the password to be identical. Try changing apps password to something else and try to login, the validation at the last stage would fail. This would result in failure of application login. Apps is a universal schema has synonyms to all base product tables and sequences. This also has code objects for all products (triggers, views, packages, synonyms etc.). Applsys schema has applications technology layer products like FND and AD etc.
=========================
Patch Set Updates (PSUs) are proactive cumulative patches containing recommended bug fixes that are released on a regular and predictable schedule.
PSUs are on the same quarterly schedule as the Critical Patch Updates (CPU), specifically the Tuesday closest to the 15th of January, April, July, and October.
The contents of the PSU include :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Critical technical issues with fixes that may affect a large number of customers and that are already proven in the field
- Critical Patch Update fixes
Example:
PSU 11.2.0.3.3 contains all molecules previously released in CPUApr2012, new CPUJJul2012 molecules and Generic Recommended Bug Fixes
The PSU and CPU released each quarter contain the same security content.
- A PSU can be applied on the CPU released at the same time or on an any earlier CPU for the base release version.
A PSU can be applied on any earlier PSU or the base release version. CPUs are only created on the base release version.
- Once a PSU has been installed, the recommended way to get future security content is to apply subsequent PSUs.
Reverting from PSU back to CPU, while possible, would require significant effort, and so is not advised.
For more information, please refer :
Note 854428.1 Intro to Patch Set Updates (PSU)
With PSU, Oracle has made it easier for customers to obtain and deploy fixes for known critical issues encountered in targeted environments and configurations, this provide proactive patch recommendations to customers seeking to upgrade or to improve the stability of their current environments.
PSU's are a combination of Oracle Recommended Patch Bundle and CPU
Oracle continues to recommend one-off patches; and when these one-off patches meet the PSU inclusion criteria, they are incorporated into the next PSU to be released.
The PSU's are regression tested so the chances of a bug fix creating a change in behaviour won't occur as :
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
They will fix a set of critical issues commonly encountered in targeted environments and configurations.
They will stabilize production environments because the patches address the known critical issues.
They will help save time and cost by eliminating rediscovery of known issues.
They are tested as a single combined unit, resulting in increased quality and eliminating the risk of combining patches that are only independently tested.
They make it easier to identify patches applicable for a targeted environment/configuration.
Please mark the the thread as Helpful or Correct to help other users to find questions that were answered.
he following steps load modified SQL files into the database. For a RAC environment, perform these steps on only one node.
For each database instance running on the Oracle home being patched, connect to the database using SQL*Plus. Connect as SYSDBA and run the catbundle.sql script as follows:
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql psu apply
SQL> QUIT
cd $ORACLE_HOME/rdbms/admin
sqlplus /nolog
SQL> CONNECT / AS SYSDBA
SQL> STARTUP
SQL> @catbundle.sql cpu apply
SQL> QUIT
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir ./
The need to have the same password for Apps and Applsys is because when you sign on to apps, intially it connects to a public schema called APPLSYSPUB. This validates AOL username and password that we enter (operations/welcome using guest user account. Once this is verified we select responsibility, this is validated by APPLSYS schema and then it connects to APPS schema.
Since it uses both applsys and apps during signon process this expects both the password to be identical. Try changing apps password to something else and try to login, the validation at the last stage would fail. This would result in failure of application login. Apps is a universal schema has synonyms to all base product tables and sequences. This also has code objects for all products (triggers, views, packages, synonyms etc.). Applsys schema has applications technology layer products like FND and AD etc.
No comments:
Post a Comment