During upgrade of Database from 12.1 to 12.2 I received a error during upgrade, I will share the solution since I didn’t not find nothing about it on MOS and Internet (googling).
I don’t know if this is a relevant info, but when I installed the Oracle 12.1 I performed a uninstall of APEX from the CBD and it was installed on PDB only.
Using procedure from below link.
Severe errors encountered during exection of “PDBS Recompile Invalid Objects”
The errors was found on log file “/u01/app/oracle/cfgtoollogs/dbua/upgrade2017-04-17_07-39-02-PM/prdcdb/PDBSUtlprp2R0.log”.
SQL> Rem ===================================================================== SQL> Rem Run component validation procedure SQL> Rem ===================================================================== SQL> SQL> SET serveroutput on SQL> EXECUTE dbms_registry_sys.validate_components; ...(22:53:11) Starting validate_apex for APEX_050100 ORA-20001: MISSING GRANT: grant execute on "MDSYS"."SDO_DIM_ARRAY" to APEX_050100 ORA-20001: MISSING GRANT: grant execute on "MDSYS"."SDO_DIM_ELEMENT" to APEX_050100 ORA-20001: MISSING GRANT: grant execute on "MDSYS"."SDO_ELEM_INFO_ARRAY" to APEX_050100 ORA-20001: MISSING GRANT: grant execute on "MDSYS"."SDO_GEOMETRY" to APEX_050100 ORA-20001: MISSING GRANT: grant execute on "MDSYS"."SDO_ORDINATE_ARRAY" to APEX_050100 ORA-20001: MISSING GRANT: grant execute on "MDSYS"."SDO_POINT_TYPE" to APEX_050100 ...(22:53:11) Checking missing sys privileges ...(22:53:11) Recompiling ...(22:53:11) Checking for objects that are still invalid ...(22:53:12) Key object existence check ...(22:53:12) Setting DBMS registry for APEX to INVALID ...(22:53:12) Exiting validate_apex PL/SQL procedure successfully completed.
How do I Fix it:
$ sqlplus / as sysdba Connected to: Oracle Database 12c Enterprise Edition Release 18.104.22.168.0 - 64bit Production SQL> alter session set container=COMMON_APPS; Session altered. SQL> grant execute on "MDSYS"."SDO_GEOMETRY" to APEX_050100; Grant succeeded. SQL> grant execute on "MDSYS"."SDO_DIM_ARRAY" to APEX_050100; Grant succeeded. SQL> grant execute on "MDSYS"."SDO_DIM_ELEMENT" to APEX_050100; Grant succeeded. SQL> grant execute on "MDSYS"."SDO_ELEM_INFO_ARRAY" to APEX_050100; Grant succeeded. SQL> grant execute on "MDSYS"."SDO_GEOMETRY" to APEX_050100; Grant succeeded. SQL> grant execute on "MDSYS"."SDO_ORDINATE_ARRAY" to APEX_050100; Grant succeeded. SQL> grant execute on "MDSYS"."SDO_POINT_TYPE" to APEX_050100; Grant succeeded. SQL> exit Disconnected from Oracle Database 12c Enterprise Edition Release 22.214.171.124.0 - 64bit Production
Click and Retry and errors is gone.
SQL> Rem ===================================================================== SQL> Rem Run component validation procedure SQL> Rem ===================================================================== SQL> SQL> SET serveroutput on SQL> EXECUTE dbms_registry_sys.validate_components; ...(22:59:11) Starting validate_apex for APEX_050100 ...(22:59:11) Checking missing sys privileges ...(22:59:11) Recompiling ...(22:59:12) Checking for objects that are still invalid ...(22:59:12) Key object existence check ...(22:59:13) Setting DBMS Registry for APEX to valid ...(22:59:13) Exiting validate_apex PL/SQL procedure successfully completed.
The upgrade finished successful.
Starting with Oracle Grid Infrastructure 12c Release 2 (12.2), Oracle Grid Infrastructure software is available as an image file for download and installation.
You must extract the image software into the directory where you want your Grid home to be located, and then run the gridSetup.sh (no more runInstaller) script to start Oracle Grid Infrastructure installation.
Before Install (Important):
Since it’s only a image and you just unpack it, if download is corrupted then you will get a corrupted Oracle Home.
Then I recommend you perform a check before.
grid@lpi-oracle:/u01/mount> unzip -t aixppc64_12201_grid_home.zip |grep -v OK Archive: aixppc64_12201_grid_home.zip No errors detected in compressed data of aixppc64_12201_grid_home.zip.
How to Install
Just unpack the zip image on new OH.
If you unpack on /tmp/grid and run gridSetup.sh the new OH will be /tmp/grid.
grid@lpi-oracle:/u01/mount> unzip aixppc64_12201_grid_home.zip -d /u01/app/grid/product/12.2.0/grid/ creating: /u01/app/grid/product/12.2.0/grid/OPatch/ inflating: /u01/app/grid/product/12.2.0/grid/OPatch/README.txt creating: /u01/app/grid/product/12.2.0/grid/OPatch/auto/ creating: /u01/app/grid/product/12.2.0/grid/OPatch/auto/core/ creating: /u01/app/grid/product/12.2.0/grid/OPatch/auto/core/bin/ inflating: /u01/app/grid/product/12.2.0/grid/OPatch/auto/core/bin/opatchauto.sh inflating: /u01/app/grid/product/12.2.0/grid/OPatch/auto/core/bin/opatchautoCopy.sh . . . finishing deferred symbolic links: /u01/app/grid/product/12.2.0/grid/bin/lbuilder -> ../nls/lbuilder/lbuilder /u01/app/grid/product/12.2.0/grid/javavm/admin/cbp.jar -> ../../javavm/jdk/jdk8/admin/cbp.jar /u01/app/grid/product/12.2.0/grid/javavm/admin/classes.bin -> ../../javavm/jdk/jdk8/admin/classes.bin /u01/app/grid/product/12.2.0/grid/javavm/admin/lfclasses.bin -> ../../javavm/jdk/jdk8/admin/lfclasses.bin /u01/app/grid/product/12.2.0/grid/javavm/admin/libjtcjt.so -> ../../javavm/jdk/jdk8/admin/libjtcjt.so /u01/app/grid/product/12.2.0/grid/javavm/lib/jce.jar -> ../../javavm/jdk/jdk8/lib/jce.jar /u01/app/grid/product/12.2.0/grid/javavm/lib/security/US_export_policy.jar -> ../../../javavm/jdk/jdk8/lib/security/US_export_policy.jar /u01/app/grid/product/12.2.0/grid/javavm/lib/security/cacerts -> ../../../javavm/jdk/jdk8/lib/security/cacerts /u01/app/grid/product/12.2.0/grid/javavm/lib/security/java.security -> ../../../javavm/jdk/jdk8/lib/security/java.security /u01/app/grid/product/12.2.0/grid/javavm/lib/security/local_policy.jar -> ../../../javavm/jdk/jdk8/lib/security/local_policy.jar /u01/app/grid/product/12.2.0/grid/javavm/lib/sunjce_provider.jar -> ../../javavm/jdk/jdk8/lib/sunjce_provider.jar /u01/app/grid/product/12.2.0/grid/jdk/jre/lib/ppc64/classic/libjvm.a -> libjvm.so /u01/app/grid/product/12.2.0/grid/jdk/jre/lib/ppc64/j9vm/libjvm.a -> libjvm.so /u01/app/grid/product/12.2.0/grid/jdk/jre/lib/ppc64/libjsig.a -> libjsig.so /u01/app/grid/product/12.2.0/grid/lib/libjavavm12.a -> ../javavm/jdk/jdk8/lib/libjavavm12.a /u01/app/grid/product/12.2.0/grid/lib/libodm12.so -> libodmd12.so
You can’t change ORACLE HOME during installation, you can set ORACLE_BASE only.
Note: Download and copy the Oracle Grid Infrastructure image files to the local node only. During installation, the software is copied and installed on all other nodes in the cluster.
Another new important Feature.
Starting with Oracle Grid Infrastructure 12c Release 2 (12.2), Oracle Grid Infrastructure installer supports the option of deploying Oracle Domain Services Clusters and Oracle Member Clusters.
Two ways to Deploying a Grid Installation for a Cluster:
Oracle Standalone Cluster – Default Installation of Oracle Clusterware
Oracle Cluster Domain – If you have multiples Oracle Clusterware Installation in your infraestructure and want manage it as single Cluster, then you must start think deploy a Cluster Domain.
Multiple cluster configurations are grouped under an Oracle Cluster Domain for management purposes and make use of shared services available within that Oracle Cluster Domain. The cluster configurations within that Oracle Cluster Domain include Oracle Domain Services Cluster and Oracle Member Clusters.
Later I will create a new post explaining the new installation feature Oracle Domain Services Clusters and Oracle Member Clusters.
The Oracle Grid Infrastructure software owner (typically, grid) must be a member of the OSDBA group. Membership in the OSDBA group enables access to the files managed by Oracle ASM. If you have a separate OSDBA group for Oracle ASM, then the Oracle Restart software owner must be a member of the OSDBA group for each database and the OSDBA group for Oracle ASM.
If grid user is not a member of dba os group, then DBCA will fails at end of database creation and DBCA will perform rollback of database creation (database will not be created).
The error below will be raised:
srvctl start database -d prdcdb PRCR-1079 : Failed to start resource ora.prdcdb.db ORA-01017: invalid username/password; logon denied CRS-5017: The resource action "ora.prdcdb.db start" encountered the following error: ORA-01017: invalid username/password; logon denied . For details refer to "(:CLSN00107:)" in "/u01/app/grid/diag/crs/db-oracle/crs/ trace/ohasd_oraagent_grid.trc".
To fix the issue you must add user “grid” to OSDBA group “dba” and relink RDBMS Binaries.
# id grid uid=205(grid) gid=202(oinstall) groups=208(asmdba),209(asmadmin),210(asmoper) # usermod -a -G dba grid (linux) # id grid uid=205(grid) gid=202(oinstall) groups=203(dba),208(asmdba),209(asmadmin), 210(asmoper) # su - oracle oracle@db-oracle:/home/oracle> export AIXTHREAD_SCOPE=S oracle@db-oracle:/home/oracle> export ORACLE_BASE=/u01/app/oracle oracle@db-oracle:/home/oracle> export ORACLE_HOME=$ORACLE_BASE/product/12.1.0/ dbhome_12102 oracle@db-oracle:/home/oracle> export PATH=$ORACLE_HOME/bin:$PATH oracle@db-oracle:/home/oracle> relink all writing relink log to: /u01/app/oracle/product/12.1.0/dbhome_12102/ install/relink.log
If there are no errors reported in $ORACLE_HOME/install/relink.log, then retry to create the database with dbca.
For those who unfamiliar with Oracle Patch is little confusing what patch to apply when get a table with different patch in the same version.
I will try clarify some doubts.
Note: You must provide a valid My Oracle Support login name in order to access below Links.
Patch version numbering changed
In November 2015 the version numbering for new Bundle Patches, Patch Set Updates and Security Patch Updates for Oracle Database changed the format from 5th digit of the bundle version with a release date in the form “YYMMDD” where:
- YY is the last 2 digits of the year
- MM is the numeric month (2 digits)
- DD is the numeric day of the month (2 digits)
More detail can be found here: Oracle Database, Enterprise Manager and Middleware – Change to Patch Numbering from Nov 2015 onwards (Doc ID 2061926.1)
Changes on Database Security Patching from 126.96.36.199 onwards
Starting with Oracle Database version 188.8.131.52 , Oracle will only provide Patch Set Update (PSU) patches to meet the Critical Patch Update (CPU) program requirements for security patching. SPU (Security Patch Update) patches will no longer be available. Oracle has moved to this simplified model due to the popularity of the PSU patches. PSUs are Oracle’s preferred proactive patching vehicle since their inception in 2009.
Where to find last Patches for Database?
What Patch to apply PSU, GI PSU,Proactive Bundle Patch, Bundle Patch (Windows 32bit & 64bit)?
When using the Patchset Assistant the assistant show below table:
In this case I search for last patch for 184.108.40.206.
Understanding the Patch Nomenclature :
New Patch Nomenclature for Oracle Products (Doc ID 1430923.1)
Note: As of April 2016, the Database Patch for Engineered Systems and Database In-Memory has been renamed from “Bundle Patch (BP) ” to “Database Proactive Bundle Patch”.
Note: Windows Platform must use “Bundle Patch (Windows 32bit & 6bit)”.
Database patch content:
- SPU contains only the CPU program security fixes
- PSU contains the CPU program security fixes and additional high-impact/low-risk critical bug fixes
- Proactive Bundle Patch (PBP) includes all PSU fixes along with fixes targeted at the specific Bundle Patch environment.
They are cumulatives,so if you have a OH (220.127.116.11) in base release (i.e no fix) and apply the last PSU or PBP it will fix all bugs from base release until current version of patch.
Where to apply each Patch?
- PSU – Can be applied on Database Servers, Client-Only and Instant Client.
- GI PSU – Can be applied on GI Home (Oracle Restart or Oracle Clusterware) in conjunction with RAC, RACOne, Single Instance home, Client-Only and Instant Client.
- Proactive Bundle Patch – Can be applied on GI Home in conjunction with RAC, RACOne, or Single Instance home, Client-Only and Instant Client.
An installation can only use one of the SPU, PSU or Proactive Bundle Patch patching methods.
How to choose between them?
The “Database Proactive Bundle Patch” requires a bit more testing than a Patch Set Update (PSU) as it delivers a larger set of fixes.
If you are installing a new fresh installation you should to apply Database Proactive Bundle Patch.
PSU is addressed to environments sensitive to changes, because it required less testing.
I have Applied “Database PSU” how to move to “Database Proactive Bundle Patch”?
Moving from “Database PSU” to “Database Proactive Bundle Patch”
- Back up your current setup
- Fully rollback / deinstall “Database PSU”
- If using OJVM PSU that is likely to require OJVM PSU to be rolled out too
- Apply / install the latest “Database Proactive Bundle Patch”
- Apply any interim patches also rolled out above (including OJVM PSU if that was installed)
Note from Oracle: It is not generally advisable to switch from “Database PSU” to “Database SPU” method.
The below note can clarify any doubt on this post.
Oracle Database – Overview of Database Patch Delivery Methods (Doc ID 1962125.1)
GI PSU and Proactive Bundle Patch are supported by OPlan.
OPlan is a utility that facilitates the patch installation process by providing you with step-by-step patching instructions specific to your environment.
In contrast to the traditional patching operation, applying a patch based on the README requires you to understand the target configuration and manually identify the patching commands relevant to your environment. OPlan eliminates the requirement of identifying the patching commands by automatically collecting the configuration information for the target, then generating instructions specific to the target configuration.
Documentation isn't much clear about concept and purposes of Oracle Flex Cluster.
Because that I recommend you read below Oracle White Paper before start with Oracle Clusterware 18.104.22.168.
Some books (about clusterware 12c) link are making mistakes on this new architecture.
Hope this helps