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.
Wallets for encrypting database connections? No, not any more…!
When you want to encrypt your client connections to the database, one used to create Oracle Wallets. With an Oracle wallet you run ‘SQL*Net over an SSL connection’. Your tcp connection will be transformed to tcps.
This is not necessary if you easily want to encrypt all your connections to the database. You do not use tcps, you still use tcp, but you encrypt SQL*Net traffic, which is a different approach.
If you use “Native Oracle Net Services encryption and integrity”, you can encrypt all SQL*Net traffic from a client, for all connections to a database and it’s even also configurable per WebLogic Connection Pool. Continue reading
Following is tested with Oracle 12.1 on Linux 6 (on Exadata) and a Windows 10 client.
“Yet another blog on how to authenticate database users against Active Director using Kerberos…”
I have read and tried a view blogs on how to get this done, but somehow I have found them a bit limited because they talk about a simple configuration with one database on one host. When you have to deal with multiple hosts and multiple databases per host, you need to take some things into account.
Lets start with some explanations, a walk through is below that.
- Unsupported ParametersThe following parameters are no longer supported:
No it’s not!
If you leave it out, you will get:
Password for airell@[logging]:
In stead of:
Password for airell@DOMAIN.LOCAL:
If you leave it out, one must not use the MIT layout… but where is the non-MIT layout described? It looks like the domain must be present on the first line of the file… for now, I will still use the MIT layout.
REHL 7 and Oracle Linux 7 was not released when Oracle database 188.8.131.52 came out, so the installer does give some issues in the pre-requisites and when installing the software. I advice to do a software only installation first, because of an issue that you will need to fix with a patch after software installation, but before creating a database.
These issues popped-up when I was installing a 184.108.40.206 database on RHEL7 (not a Certified product combination!), but the solutions given for 220.127.116.11 worked for it as well:
- elfutils-libelf-devel package missing;
- compat-libstdc++ package missing;
- pdksh package missing;
- “Error in invoking target ‘agent nmhs’ of makefile” when installing.
- This one also counts for installing Oracle Fusion Middleware.
Yes, APEX uses a lot of cursors and if you dive into APEX tuning docs, this is also explained in the Application Express (APEX) Performance Tuning and Scalability Factors (Doc ID 1418234.1):
“(…) APEX applications (and mod_plsql applications, for that matter) do not reuse session cursors. This is the nature of the architecture (…)”.
So the Oracle database will get a lot of open cursors to handle. Sometimes you will read it can be fixed by raising the APEX/ORDS listener “jdbc.MaxLimit”. It’s probably a bit low by default for production systems and it can be raised to 25 or 50 or something whatever your need is, but that will not fix the ORA-01000. Continue reading
Official Oracle support notice: “There is no way to disable ADG, just prevent its usage by ensuring the physical standby database is always mounted when Media Recovery (MRP) runs“.
I think it’s to easy to get Active Data Guard running. If you accidentally open your standby database (first) and get Data Guard up and running, you automagically have made your standby database read only mode and have the Active Data Guard enabled.
There is a ‘underscore’ parameter which can be set to disable ADG. This means that a standby database can not be opened and keeps being in mount mode; yeah!
Unfortunately it’s an ‘underscore’ parameter and Oracle support does NOT(!) advices it to use it: Doc ID 2269239.1:
NOTE: Hidden parameter “_query_on_physical” is NOT an option to prevent Active Data Guard usage. It should NOT be used at all in any version of the Oracle Database. It is unsupported to be set unless Oracle Support advises it for diagnostic reasons. Continue reading
I recently upgraded by OVM to 3.4.3(.1511), but now my Oracle Enterprise Linux 6.9 PVM guests won’t start up any more. They don’t finish the ‘Starting automount’ in the boot / startup screen. It does not fail, it just won’t continue.
There is nothing special in the /etc/fstab I guess… : Continue reading
for part 1, click here…
In this blog post I will describe a few cases with extended (distance) Oracle clusters using examples with different storage, controller, failgroup configurations and where you have data blocks you left when failure happens. Continue reading