While trying to add an additional OMS to the current OEM 13.3 GCDomain using the provisioning console there’s an error in the Install homes step.
The error contains the following message:
Caused by: oracle.sysman.oii.oiif.oiifb.OiifbEndIterateException:
oracle.sysman.oii.oiif.oiifb.OiifbEndIterateException: SEVERE:Values for the following variables could not
be obtained from the command line or response file(s):
Silent install cannot continue.
This issue is related to Bug 28290139 and the workaround can be found in MOS 2432095.1 After performing the workaround the OMS addition job needs to be executed from scratch. This resolves the issue.
I recently had an issue in OEM 12c while creating a Metric Extension that was returning more than 5000 records. In OEM 12c versions 188.8.131.52 and 184.108.40.206 there a flood control mechanism in order to limit the maximum number of rows for a metric.
You can also verify this in the agent_inst/sysman/log/gcagent.log file:
2018-10-08 13:38:50,330 [66:F119EDFE:GC.Executor.1 (host:hostname:ll_host_config) (host:hostname:ll_host_config:ECM_OS_COMPONENT)] WARN – Result set exceeding min flood control level
The solution is provided in the MOS Doc Id 1499381.1
We didn’t want to proceed to apply the patch but rather we limited the number of rows from the Metric Extension.
This OMS patch is available also for 13.1 version and the bug states that is fixed in 13.2 versions.
There’s an issue in EBS 12.2 and database 220.127.116.11 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.
I recently had an issue with an OEM agent 18.104.22.168 version running on Solaris. Looks like there’s a Java related bug which causes the agent to consume high amounts of CPU in the box. But the interesting part is this only happens when Listeners are being monitored. If you blackout the Listener targets this stops.
If this’s the case then you are hitting Bug 15953286.
The solution is comprised by various steps outlined on MOS “EM 12c: Enterprise Manager 12c Cloud Control Agent CPU Spiking and High Utilization on Solaris with Many Database and Listener Targets (Doc ID 1536871.1)”.
How many times we have calls from users complaining about their process that failed due to an ORA-01555 error?
We know that if the queries are not well tuned and they modify a lot of data, the image held in the UNDO Tablespace could not be consistent with the real data. But have you ever seen this error right away after executing a SQL statement against a table?
I just did couple of days ago. Here’s the story:
ORA-01555 error appeared in the alertlog’s database with a query duration of 0 seconds.
ORA-01555 caused by SQL statement below (SQL ID: d3rt4tyudufeu, Query Duration=0 sec, SCN: 0x034f.34f660b4)
Any queries plus an analyze table failed right away with ORA-01555:
ERROR at line 1: ORA-0155: snapshot too old: rollback segment number 10 with name “SYSSMU11_1072300523734$” too small
After researching a bit on MOS, found a note regarding a bug.
Some minutes later we also started to receive ORA-600 errors related so scn numbers.
ORA-error stack (00600[ktbdchk1: bad dscn])
The MOS note mentions the ORA-01555 and the ORA-600 errors as part of bug 22241601 with a Dataguard configuration. Is worth to mention that yes, we were doing switchover testing recently in this 22.214.171.124 environment.
ALERT Bug 22241601 ORA-600 [kdsgrp1] / ORA-1555 / ORA-600 [ktbdchk1: bad dscn] / ORA-600  due to Invalid Commit SCN in INDEX (Doc ID 1608167.1)
The solution is to apply the patch but there’s also a tested workaround that is to rebuild online all the indexes of that table.
Hope this helps.
Over the weekend one of the databases hung due to the flash recovery area was 100% full. I noticed one J001 process consuming significant CPU and I/O resources. Turns out this process was the automatic segment advisor job that runs on the weekend maintenance window.
The SQL executed was something like:
CREATE TABLE .dbms_tabcomp_temp_uncmp
SELECT /*+ FULL(.
After reading Oracle note Id 13463481.8 and confirming this with an SR, this is related to a bug for 126.96.36.199 version and fixed in 188.8.131.52. This bug generates excessive amount of redo when running the compression advisor on a table with a LOB column in a database running in ARCHIVELOG mode.
As we can’t just apply the required patch to the ORACLE_HOME right away, we decided to perform the workaround of disabling the automatic segment advisor task. The compression advisor is part of the segment advisor and is not possible just to disable one or the other.
To disable the segment advisor:
client_name => ‘auto space advisor’,
operation => NULL,
window_name => NULL);
/ 2 3 4 5 6 7
PL/SQL procedure successfully completed.
After executing the procedure, verify that the “auto space advisor” is disabled.
SQL> SELECT client_name, status FROM dba_autotask_client;
auto optimizer stats collection ENABLED
auto space advisor DISABLED
sql tuning advisor ENABLED
Although the advisor will not automatically run, you can always run it manually on the segments or indexes you want to be analyzed.