Of course you should update to Enterprise Manager 13.4 (or later) after the 12th of January 2021. Ok, so you don’t want to or you can not do this at this moment or I need it NOW!
There are two things happening here. 1) Adobe implemented a kill-switch that you can not use Flash anymore after the 12th of January and 2) your browser stopped supporting/running Flash.
This blog post is about issue 1. The ‘kill-switch’.
Adobe’s Flash “Enterprise Enablement”
What?! Yes, you can still run Enterprise Manager with Flash after the 12th of January 2021, but you need to do something called “Enterprise Enablement” and have sites be placed on the Flash Allow List.
Read about it in the Adobe Flash Player Administration Guide for Flash Player 32.
Create a Flash Allow List
Be warned, outdated Flash is unsafe…! Enable it for EM only (AllowList it).
Flash implemented a kill switch, so you can not use Flash anymore after the 12th of January. Luckily you can allow site to still run Flash!
Create the following file
mms.cfg as Administrator and save it in
I have created a script to add trusted certificate chains to an orapki wallet from the Linux command line, and there is no web browser needed. It reads sites from a list and adds the certificate chains of those sites to an
orapki (auto login) wallet.
Start the script with
./certs_to_wallet.sh <path to wallet> . This will prompt you for a NEW wallet (auto login) creation. The old wallet will be backed-up. In case of permission of password errors, the backup will be restored.
It reads a
wallet_sites.lst file from the current directory or the wallet directory. The wallet directory takes preference, so you can have a list of sites per wallet. A site per line will be processed and the certificate chain will be added to the given wallet (the last line should be empty).
This weekend Oracle updated to oVirt 4.3, Yeah! See instruction below how to upgrade to oVirt 4.3 and if/when you version locked the sos package.
Oracle was still using oVirt Release 4.2 repositories for Oracle Linux 7.7. The vdsm-4.20.46 conflicted with sos 3.7-11 from the ‘latest’ Oracle Linux 7 repository, which features Oracle Linux 7.7, not 7.6.
The fix is in vdsm-4.30.something, from the oVirt 4.3 repo’s, and now they are offering it!
When you get ‘Command returned failure code 1 during SSH session’ during adding a KVM host with the Oracle Linux Virtualization Manager, there might be something wrong with the libvertd deamon on the host you want to add.
I had this issue with adding a Oracle Linux 7.7 host.
Please check on the KVM host the following:
Although the PGA_AGGREGATE_LIMIT is set and Oracle decided to kill the process/session that was using so much, it sometimes still exceeds and grows and eventually exhausting all the memory.
SQL> show parameter pga_aggregate_limit
NAME TYPE VALUE
------------------------------- ----------- ------------------------------
pga_aggregate_limit big integer 14G
SQL> select round(pga_used_mem/1024/1024) PGA_USED_MEM
from v$process p join v$session s on p.addr = s.paddr
where s.sid = 259;
From the alert log:
KILL SESSION for sid=(259, 29568):
Reason = alter system kill session
Mode = KILL HARD SAFE -/-/-
Requestor = USER (orapid = 25, ospid = 4952, inst = 1)
Owner = Process: USER (orapid = 148, ospid = 5628)
Result = ORA-31
The culprit here is the ORA-31 error. This is the ‘marked for kill’ message. So the process is not killed, but only marked for kill:
When you want to flush or purge just a single (or a few) statement from the Shared Pool you can use the following query (all on a single line in SQL Developer e.g.):
exec for c in (select address, hash_value from v$sqlarea where sql_id='3hab0nxcfsxyj') loop sys.dbms_shared_pool.purge(c.address||','||c.hash_value,'C'); end loop;
-- If and only if the first argument is a cursor address and hash-value,
-- the flag parameter should be set to 'C' (or 'c').
In the Oracle JVM Web Services Call-Out Utility Developer’s guide, it states that the install_ojvmwcu.sql script must be run, but if you do that, it will ask you for a value. Which value?
In 184.108.40.206 the script has been changed, but the documentation hasn’t. The value it is asking for is a password, the password of the OJVMWCU_INSTALL user. Hang on? According to the docs this user must be created manualy first… not any more.
The “install_ojvmwcu.sql” calls “@configure_ojvmwcu.sql &1”, that’s where the “Enter value for 1:” comes from.
The “configure_ojvmwcu.sql” contains:
install_schema VARCHAR2(20) := 'OJVMWCU_INSTALL';
procedure create_user as
user_exists integer := 0;
select count(1) into user_exists from dba_users where username = install_schema;
if user_exists != 0 then
execute immediate 'drop user ' || install_schema || ' cascade';
execute immediate 'create user ' || install_schema || ' identified by &1';
Aha! The &1 the password of the OJVMWCU_INSTALL user, if it’s there it will be dropped and it will be created.
So, run “install_ojvmwcu.sql password” for installing and creating the OJVMWCU_INSTALL user automagically. After that, grant users with “@grant_ojvmwcu.sql user”.
Oh, run an “utlrp” (recompile invalid objects) after running the install_ojvmwcu.sql script.
During an upgrade to 220.127.116.11 and in the step running GRID root scripts, the upgrade fails with:
[DCS-10001:Internal error encountered: Fail to run root scripts..]
After that if you run the upgrade again, you will get the following error:
[DCS-10001:Internal error encountered: Fail to extract the GI clone file.]
When I got there error’s, I found in the logging (/u01/app/18.104.22.168/grid/install/root_<host_name>_<date>_<time>-<more_numbers>.log) that there was no PKI trust set up between the ODA and ‘itself’ (aka passwordless login). The Oracle GRID upgrade works by accessing all the nodes in it’s cluster via ssh, including itself. But This was a single (non HA) machine (X6-2M), so did not expect it. Continue reading
A small walkthrough in ‘clearing’ the ORA-13785 error. This might be in the alert log or when you run DBMS_SPM.REPORT_AUTO_EVOLVE_TASK without and object ID. It probably defaults with object ID ‘1’, which is the last run evolve task(?).
The ‘SYS_AUTO_SPM_EVOLVE_TASK’ ‘root object ID’ (I’m not sure if it is called like this) seemed missing, adding it and resetting and resuming SPM resolved the error. This is all done with trial and error, cross checking a working 12c database and a lot of common sence. BACKUP FIRST! It also includes ‘recreating’ the ‘root object ID’ for ‘SYS_AUTO_SQL_TUNING_TASK’ which I found also missing. Continue reading
Shown are the latest kernel versions as of the 9th of January which have Meltdown and Spectre patches.
Kernel versions can be found when running the `uname -r` command.
After the kernel is installed one can find the kernel/packages changelog and security info with the following commands and see in the page table isolation has been activated:
# yum updateinfo list
# yum updateinfo list cves
# yum updateinfo list kernel-uek
# yum updateinfo list --sec-severity=Important
# yum updateinfo info --sec-severity=Important
CVE-2017-1000407 Important/Sec. kernel-uek-4.1.12-112.14.13.el7uek.x86_64
# dmesg | grep isolation
[ 0.000000] Kernel/User page tables isolation: enabled
# rpm -q --changelog kernel | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'
# rpm -q --changelog kernel-uek | egrep 'CVE-2017-5715|CVE-2017-5753|CVE-2017-5754'
Oracle Linux version 6
Kernel: 2.6.32-696.18.7 (errata: ELSA-2018-0008), 2018-01-04.
Kernel-uek: 4.1.12-112.14.10 (errata: ELSA-2018-4006), 2018-01-09.
Oracle Linux version 7
Kernel: 3.10.0-693.11.6 (errata: ELSA-2018-0007), 2018-01-04.
Kernel-uek: 4.1.12-112.14.10 (errata: ELSA-2018-4006), 2018-01-04.
Oracle VM version 3.4
Xen: 4.4.4-155.0.12.el6 (errata: OVMSA-2018-0006), 2018-01-08.