Tag: EBS

OEM 13c – AMP EBS Discovery Error Due To Lack Of Privileges

We recently had to enable monitoring for an EBS 11i system using the Application Management Pack. Even though the EM_MONITOR user was already provisioned by the EBS patch, the discovery was failing due to lack of privileges on several FND tables.
My Oracle Support shows several bugs related to missing privileges like the one below, but I wasn’t able to find one for 11i.

Patch 21951154: 1OFF:12.2.0: READ ACCESS NOT PRESENT FROM EM_MONITOR USER FOR FOLLOWING TABLES

I decided to manually track the missing privileges on these tables and here’s the list I found in order to make the discovery work.
GRANT SELECT ON “APPLSYS”.”AD_APPL_TOPS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”AD_FIXED_ISSUES” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”AD_PATCH_DRIVER_LANGS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”AD_PATCH_RUNS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”AD_PATCH_RUN_BUGS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”FND_LOG_EXCEPTIONS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”FND_LOG_UNIQUE_EXCEPTIONS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”FND_NODES” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”FND_PROFILE_OPTIONS_TL” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPLSYS”.”FND_USER” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “APPS”.”HR_OPERATING_UNITS” TO “EM_OAM_MONITOR_ROLE”;
GRANT EXECUTE ON “APPS”.”JTF_DIAG_DEPENDENCIES” TO “EM_OAM_MONITOR_ROLE”;
GRANT EXECUTE ON “APPS”.”JTF_DIAG_INPUTS” TO “EM_OAM_MONITOR_ROLE”;
GRANT EXECUTE ON “APPS”.”JTF_DIAG_INPUTTBL” TO “EM_OAM_MONITOR_ROLE”;
GRANT EXECUTE ON “APPS”.”JTF_DIAG_VERSION” TO “EM_OAM_MONITOR_ROLE”;
GRANT EXECUTE ON “APPS”.”JTF_DIAG_VERSION_NT” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”ALL_IND_COLUMNS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”ALL_OBJECTS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”ALL_QUEUES” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”ALL_TRIGGERS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_DATA_FILES” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_OBJECTS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_PROCEDURES” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_SOURCE” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_TAB_PRIVS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_TEMP_FILES” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_USERS” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”DBA_USERS_WITH_DEFPWD” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”GV_$INSTANCE” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”GV_$LOGFILE” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”GV_$SESSION” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”V_$INSTANCE” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”V_$THREAD” TO “EM_OAM_MONITOR_ROLE”;
GRANT SELECT ON “SYS”.”V_$VERSION” TO “EM_OAM_MONITOR_ROLE”;
Hope this helps to your discovery.
Thanks,
Alfredo

EBS ADOP Phase Failing Due to ORA-600 Error

There’s an issue in EBS 12.2 and database 12.1.0.2 versions related to Materialized Views. While executing ADOP (prepare, apply, finalize or cutover) phases, the cycle could fail due to an ORA-600 : internal error code, arguments: [kqllod:no stub for dependency parent] error.
After working with Oracle, they provided information about BUG 27883586 related to MView Refresh or Create while they are editioned.
The solution is to apply patch 27883586 to the database which is currently available for August 2017 release and then recreate the MViews. Oracle also released a merge patch on top if this (28820125).
If you need it for a different release, please contact Oracle to provide it.
Happy patching,
Alfredo

ORA-04045 When Running ADOP PHASE=ACTUALIZE_ALL




Oracle’s documentation recommends to execute actualize_all in
order to purge old editions in the DB accumulated during previous patching
cycles.




There’s a problem with EBS version 12.2.4 that when running adop
phase=actualize_all you get an ORA-04045 errors during
recompilation/revalidation of .




You can try to manually recompile objects but all of them fail
with the same error. This is documented under bug 24489846.




Follow the instructions on the MOS note id 2187877.1.




I also recommend to open an SR as this bug is still open as of
May 2018.




Thanks,

Alfredo

TXK patch failing with ORA-600

I got an error during an TXK patch in a 12.2 EBS instance.
This happened while executing file xdotmgen.ldt.
Error: FAILED: file xdotmgen.ldt on worker 1 for product fnd username APPS.
Uploading from the data file
….
Uploading from staging tables Error during uploading. ORA-00600: internal error code, arguments: [17273], [0x13C88677A0], [0], [7], [], [], [], [], [], [], [], []

After looking at MOS Note Id 1953472.1, it turns out to be due to a couple of invalid objects in the database.
The solution worked and were able to continue with the ADOP cycle.
ALTER PACKAGE APPS.FND_EXECUTABLES_PKG COMPILE BODY;
ALTER PACKAGE APPS.FND_SEED_STAGE_UTIL COMPILE BODY;
Thanks,
Alfredo

Oracle EBS 12.2 EBS Technology Codelevel Checker ETCC

Looks like this is my first post about Oracle EBS. Yeah, looks like now I’m more on the dark side of the force.
This is the time for ETCC. ETCC is a set of 2 scripts. One is going to check the recommended patches for the DB stack and the other one is going to check for the recommended patches for the Middleware stack.
It does not connect to the internet to verify the latest patches. So you must verify and download the latest version of this (patch 17537119).
The scripts are:
– checkDBpatch.sh
– checkMTpatch.sh
You just execute these scripts and provide the information that is being asked. They are going to spool a report like list with the recommended patches for your stack.
Keep in mind that they make use of utilities like OPatch, so is recommended you have the latest version in your DB Oracle Home.
Identifying database release.
  Database release set to 12.1.0.2.
  Connecting to database.
  Database connection successful.
  Checking for DB-ETCC results table.
  Table to store DB-ETCC results already exists in the database.
  Checking if InMemory option is enabled.
  Obtained list of bugfixes to be applied and the list to be rolled back.
  Now checking Database ORACLE_HOME.
  The opatch utility is at the required version.
  Found patch records in the inventory.
    Missing Bugfix: 11111111  ->  Patch 12345678
    Missing Bugfix: 22222222  ->  Patch 45678912
    Missing Bugfix: 33333333  ->  Patch 98765432
    Missing Bugfix: 44444444  ->  Patch 98765432
  Generating Patch Recommendation Summary.
  ================================================================================
  PATCH RECOMMENDATION SUMMARY
  ================================================================================
  The default patch recommendations to install these missing bugfixes are:
  ——————————————————————————–
  Oracle Database Release 12.1.0.2  (No PSU applied)
  ——————————————————————————–
    Patch 12345678
      – Filename: p12345678_121020_Linux-x86-64.zip
    Patch 45678912
      – Filename: p45678912_121020_Generic.zip
    Patch 98765432
      – Filename: p98765432_121020_Linux-x86-64.zip
  Apply the required patches and rerun this script.
As a side note, I noticed that with TXK Delta 10 if you try to start an ADOP cycle it is going to check if ETCC was recently executed and all the recommended patches are in place.
Looks like is some way to enforce that all the tech stack patches are current.
Thanks,
Alfredo