Monday Nov 23, 2015

Network ACLs and Database Upgrade to Oracle 12c

What has been changed in Oracle Database 12c with Network ACLs?

Starting from 12c, network access control in the Oracle database is implemented using Real Application Security access control lists (ACLs). Existing 11g network ACLs in XDB will be migrated. Existing procedures and functions of the DBMS_NETWORK_ACL_ADMIN PL/SQL package and catalog views have been deprecated and replaced with new equivalents

In 12c, a network privilege can be granted by appending an access control entry (ACE) to a host ACL using DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE.  If you append an ACE to a host that has no existing host ACL, a new host ACL will be created implicitly. If the host ACL already exists, the ACE will be appended to the existing ACL.

(both paragraphs taken from MOS Note: 2078710.1)

What happens during/after upgrade?

  • Existing network ACLs will be migrated from XDB in Oracle 11g to Real Application Security in Oracle 12c.
    All privileges of the existing ACLs will be preserved
  • Existing ACLs will be renamed
  • Mapping between the old / new names is reflected in DBA_ACL_NAME_MAP.


Issues before/during Database Upgrade?

First of all the current preupgrd.sql does not warn you correctly if such ACLs exist. This fix gets added to the preupgrd.sql. But you'll need to download the most recent version from MOS Note 884522.1. The one from January 2015 does not have it yet. But this is addressed and will be implemented soon.

Here's an issue which happened to one of my very experienced colleagues from Oracle Consulting in an upgrade project:

"Customer had network ACLs defined and Privileges (resolve,connect) granted for several hosts to several DB users in

With the first DB, we observed the ACL renaming as you described it, but, much worse: 4 out of 9 privileges granted were completely gone away after the upgrade performed by DBUA (to We then were able to evaluate the missing privileges and re-grant them again. Warned by that, for the next databases to be upgraded, we copied all the content of the DBA_NETWORK_ACLS and DBA_NETWORK_ACL_PRIVILEGES to helper tables in order to be able to restore lost privileges (which was a good idea, as in one of the databases, only 87 out of 240 formerly existing privileges survived the upgrade)." 


Check for existing Network ACLs before the upgrade or get the most recent preupgrd.sql once it contains the check.

Preserve the existing network ACLs and privileges (DBA_NETWORK_ACLS and DBA_NETWORK_ACL_PRIVILEGES) in a intermediate staging table to have the possibility to restore them afterwards in case the automatic migration fails or does not happen.

If you encounter a situation where your Network ACLs don't get migrated correctly, disappear and/or don't exist in the mapping table DBA_ACL_NAME_MAP afterwards please open an SR and let Oracle Support check. There are known issues with mappings and migrations not done correctly (find some bugs below) so needs to be verified if you have hit a known issue or encountered a new one.

More Information?



Thursday Nov 19, 2015

Why you should remove APEX from the CDB$ROOT

Upgrade Blog posts about Oracle Application Express:

Oracle APEX (Application Express) is great piece of software. But it gets installed by default into the container database's CDB$ROOT unless you'd customized your CDB creation via scripts in Oracle See: 

on how to customize a Single/Multitenant Database with less options.

But that is not the topic I would like to write about. I came across an pitfall in the past days twice.

Think of having a local APEX (Application Express) application in a standalone database or already inside a PDB. You'd like to plug it into a CDB, regardless if this CDB is local or in the Oracle DBaaS Cloud. But your current APEX is on a lower version than the APEX inside the target CDB.

Let's assume you'd like to migrate this standalone database or PDB over into the cloud. But as soon as you plug it in - even though you'll have Oracle Database in both sites locally and in the cloud, you can't open your PDB in read/write mode. It will open RESTRICTED only.

Then you'll check PDB_PLUG_IN_VIOLATIONS and get a plug in error:

"APEX mismatch: PDB installed version CDB installed version" 

Reason is simply that an Oracle Database standard deployment will contain APEX 4.2.0 whereas the Oracle Cloud deployment in this scenario uses the more recent APEX version 5.0 already.

Having APEX installed into the CDB$ROOT was not a great idea. Actually it will cause you a lot of trouble and does not make much sense in the idea of Multitenant concept.

Oracle APEX Multitenant

I see why it has been done this way as not having APEX in the CDB$ROOT would have meant not having it in the PDB$SEED either - and all further provisioned PDBs would not have had APEX deployed by default. In this case every PDB would have required a separate APEX installation - but then you'd get the freedom of different APEX versions within the same Multitenant environment. And way more freedom during unplug/plug. But I'll elaborate this further down below.

Different APEX versions in Multitenant

First of all check your current APEX version with this query:


-------- ------------ -------

Find out in which container APEX is currently installed into:

SQL> select r.COMP_NAME, r.VERSION, c.NAME, c.CON_ID from CDB_REGISTRY r, V$CONTAINERS c where r.CON_ID=c.CON_ID and r.COMP_ID='APEX' order by CON_ID;

COMP_NAME                   VERSION   NAME      CON_ID
--------------------------- --------- --------- ------
Oracle Application Express  CDB$ROOT       1

Then choose the best solution for your environment to avoid trouble with APEX in a Multitenant environment.


Migrate a PDB with containing an APEX 4.2 deployment into another CDB with APEX 5.0 already installed in the CDB$ROOT container (the standard deployment in the Oracle DBaaS Cloud).

Two Solutions

Basically I see two potential solutions:

  1. Remove APEX from the CDB$ROOT before plug in your PDB with a different APEX version
  2. Upgrade your APEX installation in the PDB after plugging it into the CDB to match the CDB's APEX version

Solution 1 - Remove APEX from the CDB$ROOT 

I'd prefer Solution 1 as this will give you way more freedom. It will even allow you to have different APEX versions in the same Multitenant environment in different PDBs. But you'll have to do this steps right after creation of the container database - or before you worked with APEX in any of your PDBs as the following steps will remove APEX from all your PDBs!!!! If you already have APEX applications inside one of your PDBs you must export them before the APEX removal. Keep in mind that the "application export" facility in APEX 4 does not carry your image files automatically (APEX 5 is smarter).

Remove APEX from CDB$ROOT will remove it from all PDBs as well

The Oracle Documentation describes the path pretty straight forward. 

  1. Make sure to change into the local $ORACLE_HOME/apex directory first before starting SQL*Plus as otherwise the removal process won't work and error out - I'd assume that path variables are not carried on correctly. 
    cd $ORACLE_HOME/apex

  2. Connect to your CDB$ROOT:
    sqlplus / as sysdba

  3. Run the "Remove APEX from the CDB$ROOT" script:
    SQL> @apxremov_con.sql

  4. Check afterwards if APEX has been removed - also check for invalid objects. If necessary recompile. 
    In my tests two objects were INVALID after the removal but could be easily fixed
    (this part is not mentioned in the documentation):

    no rows selected

    SQL> select object_name, status from dba_objects where status='INVALID';

    OBJECT_NAME                      STATUS
    -------------------------------- -------------
    APEX_SPATIAL                     INVALID

    SQL> @?/rdbms/admin/utlrp.sql

    SQL> select object_name, status from dba_objects where status='INVALID';
    no rows selected

  5. Once you have done this your PDB containing the APEX application should not give you APEX errors anymore upon plugin as there's no mismatch anymore between CDB$ROOT's and the PDB's APEX.

  6. Just in the case - independently of my example - you'd like to install APEX now locally into a PDB then you'll have to use the apexins.sql script:

    cd $ORACLE_HOME/apex
    sqlplus / as sysdba
    SQL> alter session set container=PDB1;
    SQL> @apexins.sql SYSAUX SYSAUX TEMP /i/

    Be aware - this step may run a long time (in my VBox image it took over 22 minutes to complete).

    timing for: Complete Installation
    Elapsed: 00:22:16.29

    Check the existence of the component finally:

    SQL> select comp_id, status , con_id from cdb_registry where comp_id='APEX';

    --------- ------- -------
    APEX      VALID         3

Solution 2 - Upgrade APEX in the PDB after plugin

Even though I'd prefer solution 1 there may be some cases where you'll have to deal with Solution 2 and upgrade APEX after plugin. One simple reason could be that somebody uses APEX already in another PDB and you can't export and preserve it for later import - then you better don't follow Solution 1 then as it will force you to test your backup/restore strategy concept soon after ... 

  1. Run apexins.sql (from the APEX 5.0 installation - $ORACLE_HOME/apex) only in this particular PDB after plugin. You'll have to use

  2. The documentation
    may not be correct mentioning all parameters without the --p option. Jason Straub corrected it:

    host &OH_HOME/perl/bin/perl -I &OH_HOME/rdbms/admin &OH_HOME/rdbms/admin/ -b apexins -c '<PDB_name>' apexins_nocdb.sql --pSYSAUX --pSYSAUX --pTEMP --p/i/

    whereas &OH_HOME represents the full path to the Oracle home.

More Scenarios 

If you look at some of the potential scenarios you may see when trying to move PDBs around including APEX applications it is pretty obvious why having APEX only locally inside each PDB is a wise move. It will give you way more flexibility, less trouble, actually less upgrades (and APEX upgrades can take a while) - and simply less headache.

Assume that my CDB1 and CDB2 below are at the same database version - having different database versions will require upgrade/downgrade tasks in addition. 

APEX installed commonly within CDB$ROOT

  • CDB1 has APEX 4.2 in CDB$ROOT
    CDB2 has APEX 5.0 in CDB$ROOT
    • Unplug a PDB from CDB1 and want to plug it into CDB2 but you'll get an error in PDB_PLUG_IN_VIOLATIONS:
      “APEX mismatch: PDB installed version CDB installed version”
    • That is actually the simple case as you'd only have to upgrade APEX inside the PDB:
      host &OH_HOME/perl/bin/perl -I &OH_HOME/rdbms/admin &OH_HOME/rdbms/admin/ -b apexins -c '<PDB_name>' apexins_nocdb.sql --pSYSAUX --pSYSAUX --pTEMP --p/i/

  • CDB1 has APEX 5.0 in CDB$ROOT
    CDB2 has APEX 4.2 in CDB$ROOT
    • You unplug a PDB from CDB1 and want to plug it into CDB2 - but you can't actually plug in.
    • As APEX can't be downgraded to 4.2 in your PDB you'll have to upgrade APEX in the CDB2 to 5.0 first
    • Then you can plugin your PDB into CDB2

APEX installed locally within the PDB only

  • CDB1 has APEX in CDB$ROOT
    CDB2 has NO APEX in CDB$ROOT
    • Unplug a PDB with an APEX application from CDB1 and want to plug it into CDB2- fails
    • You will need to install APEX into CDB2's CDB$ROOT before being able to plug in the PDB
      • And it has to be the same version of APEX as used in CDB1

  • CDB1 has NO APEX in CDB$ROOT
    CDB2 has APEX  in CDB$ROOT
    • Unplug a PDB from CDB1 (having APEX locally in the PDB only) and want to plug it into CDB2 - works if ...
      • the PDBs local APEX version match the CDB2's common APEX version
      • If they don't match ...
        • PDB has APEX 4.2
          CDB2 has APEX 5.0
          Works, but you will need to upgrade APEX in the PDB after plugin
        • PDB has APEX 5.0
          CDB2 has APEX 4.2
          Fails, and you'll have to upgrade CDB2s common APEX 4.2 to 5.0 first before being able to plugin.

  • CDB1 has NO APEX in CDB$ROOT
    CDB2 has NO APEX  in CDB$ROOT
    • That is actually the best case as you don't have to care.
      • The only thing you will need to be aware of is that you'll need to patch your ?/apex home in case that PDB has a higher APEX version already than the one we ship by default 

More Information

You can find more information via these links:

And Finally ...

I'd recommend to NEVER have APEX in any CDB$ROOT. I see the advantage of having it as a new PDB will always have APEX provisioned with it. That is convenient, no doubt. But honestly if you really need APEX in most or all of your PDBs then create your own PDB$MASTER and provision from this one instead of using the PDB$SEED. In all other cases it's by far easier to install APEX inside the PDB when you really need it. Even with the penalty that it requires some extra 10 or more minutes until it is ready to go.

Given also the fact that APEX upgrade may take a while as well (see this blog post:  ) there's another advantage which personally I consider way more important:

Having APEX locally in the PDB only offers you way more freedom and flexibility. All the complicated scenarios come up only when either the source has no APEX in the CDB$ROOT (APEX locally in the PDB) but the target has any version (most likely a different one) or the target has no APEX in the CDB$ROOT but the source had it. And even more fun, both CDBs have APEX in the CDB$ROOT but at different versions.

This can be totally avoided by NEVER having APEX installed in your CDB$ROOT.

Which means also for the Oracle Cloud DBaaS databases:
Remove APEX from the CDB$ROOT and install it into your PDB before really starting up doing APEX stuff inside. APEX is such cool piece of software - and it's free - and powerful - and easy!!!

And (thanks to Jason again for this hint) if you look into the APEX 5.0 Installation Guide you'll find this tip:


Oracle recommends removing Oracle Application Express from the root container database for the majority of use cases, except for hosting companies or installations where all pluggable databases (PDBs) utilize Oracle Application Express and they all need to run the exact same release and patch set of Oracle Application Express. To learn more, see "Installing Application Express into Different PDBs."


Monday Nov 16, 2015

UPDATE: _rowsets_enabled in Oracle Database 12c

Last week I did post this entry with a strong recommendation to disable _rowsets_enabled in Oracle Database

Today I can give you an update, more insight information and better workarounds.

Credits go to our DWH and Optimizer people (thanks to Hermann, Angela, Nigel and Mohammed).

When is the problem happening?

When a hash join operation receives rowsets from its right input but then produces one row at a time as output. This explains why one of the bugs had as potential workaround hash_join_enabled=false (and please don't use this as a w/a!!!).

Different Workarounds 

  • Set
    event = "10055 trace name context forever, level 2097152"
    in your spfile. This will disable rowsets only for the specific situation where the problem happens.

    An important comment from Angela if you intend to set this event via an ALTER SESSION command:
    "Note that if the event is set with an alter session, it will not take effect unless the query or queries are recompiled, such as by changing the query text (by adding spaces or comments) or by flushing the shared pool."

  • Set
    in your spfile. But this will switch off the entire feature, not only the particular situation where the problem happens.

  • Apply the fix for
    (as of Nov 16, 2015 in regression testing and not available yet) as soon as it is available.

Thanks again to the Optimizer folks for their quick reaction!!!


Tuesday Nov 10, 2015

Switch off "_rowsets_enabled" in Oracle Database 12c

Please find a recent update here:



Twitter is a good thing. I get alerted on things I haven't seen before. And sometimes some things are more than interesting.

This one is actually proven by Jonathan Lewis - and you can read all the details in Jonathan's blog post here:

There seems to be a realistic chance to get wrong query results displayed (regardless of using SQL*Plus or a JDBC or any other client - see the comment by Stefan Koehler below Jonathan's posting) because of the row sets feature in Oracle 12.1 allowing faster initial processing of query results.

You'll find this in the query information (marked in bold red):

Column Projection Information (identified by operation id):
   1 - "K"."KONTO_ID"[NUMBER,22]
   4 - (#keys=1) "KP"."KONTO_FK"[NUMBER,22],
   5 - (rowset=256) "KP"."KONTOPOSITION_ID"[NUMBER,22],
   6 - (rowset=256) "KWP"."KONTOPOSITION_FK"[NUMBER,22],
   8 - "K"."KONTO_ID"[NUMBER,22] 

Roy did some analysis yesterday as well (and now our Optimizer Support Experts look into this case to check whether any other wrong query result bugs are related to this topic). Because there are some open WRONG RESULTS bugs in this area, some of which were filed within the past week, we'd recommend to switch this feature off at the moment.  For instance these bugs are related to this misbehavior:

Recommendation - Updated (Nov 15, 2015)

Please read the update blog post here:


Friday Nov 06, 2015

Oracle Database Release Status - MOS Note:742060.1

Almost every day I get at least one email by somebody asking things such as ...

  • What is the current status of Oracle 
  • Is Oracle Standard Edition One under Extended Support's treatment?
  • Do I get bug fixes for Oracle
  • And is it really true that I don't get bug fixes for Oracle anymore???

All valid questions - and all of them get answered within this reference note called:

Why am I writing this?

Simply because the Lifetime Support Policy Brochure only has now a link to a central MOS note added - but no explanatory text such as "Full Extended Support coverage will only apply to the terminal release". And the link is added in the right bottom corner underneath the table on (real) page 6 (the document's pagination doesn't count pages 1 and 2 as 1 and 2 for whatever reason). 

MOS Note:742060.1 has now an updated chart displaying clearly the Support Periods:

Oracle Release Chart

And a nice overview table clearly showing the Patching End Dates as well:

Oracle Patching End Dates for the Database

MOS Note:742060.1 is clearly THE REFERENCE in terms of questions such as:

  • How long will I get bug fixes for release X?
  • When is Premier Support ending for release Y?
  • Do I get Waived Extended Support for release Z?

Tuesday Oct 20, 2015

Where do these large trace files come from in Oracle 12c?

Just had an observation about very large trace files on one of my customers I'm working with at the moment. When I write "very" I mean "VERY" as some grew over 10GB within a few hours.

Growth - Trace Files - (c) Mike Dietrich

The files contained a ton of such messages:

----- Cursor Obsoletion Dump sql_id=5p8a9d4017bq3 -----
Parent cursor obsoleted 1 time(s). maxchild=1024 basephd=00007FFB8AD45CB0 phd=00007FFB8AD45CB0

After doing a bit of research I came across this document and an explanation:

MOS Note:1955319.1;
Huge Trace Files Created Containing "----- Cursor Obsoletion Dump sql_id=%s -----"

Well, we introduced an Enhancement - via an unpublished bug (and I'd guess it is undocumented then) in Oracle Database to improve cursor sharing diagnostics by dumping information about an obsolete parent cursor and it's child cursors after the parent cursor has been obsoleted N times.

You can control this behavior by altering the value for:

alter system set "_kks_obsolete_dump_threshold" = 0;

Possible value range is 0..8 whereas 0 means: switch the obsolete cursor dump off completely, and other values (N) defined the number of invalidations after which the cursor will be dumped.

The default in Oracle Database is 1 meaning this will happen after every single invalidation

Just be aware that the underlying cursor sharing problem needs to be investigated always.


Friday Oct 16, 2015

Ouch, this hurts: bug 20880215 - patch Oracle 12c


Just realized that my preivous blog post heading was misleading: it said "patch AFTER upgrade" which is misleading. You should apply this patch BEFORE you upgrade but of course to your new/future Oracle 12c home. If you hit the issue then apply the patch after upgrading to remedy it. Sorry for the confusion.

No updates for over a week? Sorry for that but too many workshops, swamped with OOW prep work - and a wonderful issue with the browser cache and the blog software putting all my new blog post work directly into /dev/null.

Thanks to Marcel Paul for highlighting this issue to me. I really benefit from such emails as I can learn a lot from those - and furthermore distribute information to many other tech folks as well.

Actually Marcel updated me as a follow up to me recent blog post:

describing an issue which will require to apply a patch before upgrade if you are not on Oracle or higher - and the below issue is related to this one but requires a patch AFTER upgrade, regardless what your source version was.


Marcel let me know about an issue they saw with their upgrade from Oracle to Oracle after the upgrade causing a core dump and potential table metadata corruption when you'll ADD a column to a table with a DEFAULT and ENABLE NOVALIDATE. This issue gets treated as bug 20880215 (ORA-7445 [QCSISCOLINFRO()+358] FOR ADD COLUMN WITH DEFAULT AND ENABLE NOVALIDATE)

Test Case

Very simple test case done by Marcel (thanks again!) - I could verify it within 30 seconds. 

create table dummy(code varchar2(5), text varchar2(30));
insert into dummy(code, text) values ('CD1','Hello World');
select * from dummy;
alter table dummy ADD condition varchar2(3) DEFAULT 'YES' not null enable novalidate;
select * from dummy;


First of all the client (in my case SQL*Plus) will disconnect with the meaningless ORA-3113. So lets have a look into the alert.log for more useful information:

Wed Oct 14 15:06:59 2015
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x4] [PC:0xCDB0046, qcsIsColInFro()+358] [flags: 0x0, count: 1]
Errors in file /oradata/diag/rdbms/cdb2/CDB2/trace/CDB2_ora_2424.trc  (incident=3433) (PDBNAME=CDB$ROOT):
ORA-07445: exception encountered: core dump [qcsIsColInFro()+358] [SIGSEGV] [ADDR:0x4] [PC:0xCDB0046] [Address not mapped to object] []
Incident details in: /oradata/diag/rdbms/cdb2/CDB2/incident/incdir_3433/CDB2_ora_2424_i3433.trc

Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.

Wed Oct 14 15:07:08 2015
Dumping diagnostic data in directory=[cdmp_20151014150708], requested by (instance=1, osid=2424), summary=[incident=3433].

So we've got a core dump. And whatever we query now from the table involving the column "condition" we'll get the same error.


Apply the fix for bug 20880215 (ORA-7445 [QCSISCOLINFRO+358] FOR ADD COLUMN WITH DEFAULT AND ENABLE NOVALIDATE). You may have to request the fix for your platform if it hasn't been done yet. 

Further Information

A request for inclusion into the next Bundle Patches had been filed as well.


Tuesday Oct 06, 2015

New in Oracle 12c: _optimizer_gather_stats_on_load

Received an email from Roy last night with some performance issues a customer in the US encountered recently during their upgrade testing

One issue the customer encountered has to do with tons of parallel slaves creating a massive noise on the system when they are doing a CTAS (Create Table As Select) - and the same thing happens with an IAS (Insert Append Select).

What caused this change?

In this case the behavior change is well documented, even though not linked to the responsible underscore parameter. 

Quoting from the first paper: 

Online statistics gathering

In Oracle Database 12c, online statistics gathering “piggybacks” statistics gather as part of a direct-path data loading operation such as, create table as select (CTAS) and insert as select (IAS) operations. Gathering statistics as part of the data loading operation, means no additional full data scan is required to have statistics available immediately after the data is loaded.

The parameter controlling this change is not mentioned:

  • _optimizer_gather_stats_on_load

The default is TRUE since Oracle - the parameter or functionality did not exist before Oracle Database 12c.

Things to Know

The online stats gathering for IAS can happen only if the object you are loading data into is empty. You'll recognize the feature when you see a line saying OPTIMIZER STATISTICS GATHERING in the execution plan. Additionally you'll find STATS_ON_LOAD in the NOTES column of below query:


Consider now that first of all immediate stats gathering may not be desired as it will mean additional load to the system. Even though the feature has been designed to generate as little load as possible it's still doing something in the background. Hence there may be situations where you'd like to switch it off, e.g. with a hint:

insert /*+append NO_GATHER_OPTIMIZER_STATISTICS*/ into MYTAB select ...

And how about the number of parallel slaves creating the statistics? 

There's no easy answer to this based on the information I have at the moment - but I'd highly recommend this article about parallel execution in Oracle:


Tuesday Sep 29, 2015

No OS Authentication? datapatch will fail in every upgrade

Thanks to Daniel from SimCorp for bringing this to my attention:Patch
Actually, command line upgrades are affected as well,
if you do not use OS authentication. Apparently, datapatch
is not able to execute in non-OS authentication mode.
See MOS note 1635007.1. 


You are doing a command line upgrade to Oracle Database 12c with - and you don't use OS authentication allowing connections with "/ as sysdba" then won't be able to execute the SPU/PSU/BP related SQL commands as it will fail to connect to your database with an ORA-1017 (invalid username/password) error.


Bug 18361221 is fixed in Oracle 12.2 and got backported to and but not actually included in any bundles at the moment. Without this fix, datapatch will only connect with '/ as sysdba'. 

Either apply generic patch 18361221 to your destination Oracle Home or switch on OS authentication by setting:

temporarily in your sqlnet.ora for the duration of the upgrade only. See the documentation for further information about SQLNET.AUTHENTICATION_SERVICES. Or, of course, run -verbose after upgrading your database in any case ...

Further Information and Links:

Related Blog Posts


Thursday Sep 17, 2015

SE2 - Some questions, some answers ...

Oracle Standard Edition SE2*** Updated on Nov 6  to reflect changes***

There were a lot of questions regarding Oracle Database Standard Edition SE2 in the past days.And you may find some things mentioned especially in the COMMENT section of the blog post from Sep 1, 2015.

And please find the official Oracle SE2 "brief" document here giving you a good overview on SE2:

I'll try to summarize some topics I'm able to answer by myself. And please don't expect me to assist with license or license migration questions - that is far beyond my scope or knowledge or responsibility, and you may please contact your Oracle sales person regarding these topics instead.

Please find all our articles about Oracle Database Standard Edition SE2:

Software and Support 

  • Q:
    How long will Premier Support offered for Oracle Database Standard Edition SE and SE1?
  • A:
    Premier Support for Oracle Database Standard Edition SE and SE1 will continue until Aug 31, 2016. After this date (as of Sep 1, 2016) Oracle SE/SE1 will enter Sustaining Support.
  • Q:
    Will there be Extended Support offered for Oracle Database Standard Edition SE and SE1?
  • A:
    No. Extended Support for 12.1 SE and SE1 is not offered. The Lifetime Support Policy document has been updated to reflect this.
  • Q:
    Is the extension of the Waived Extended Support and the Paid Extended Support for Oracle valid for SE and SE1 as well?
  • A:
    Yes, it is - there's actually no distinction (as far as I know) between support periods for SE, SE1 and EE.
  • Q:
    Are there plans to release Oracle SE/SE1?
  • A:
    Oracle Standard Edition will be offered as SE2 only.
  • Q:
    Is hard partitioning allowed with SE2?
  • A:
    Yes, it is as long as there are no more that 2 physical sockets in the server and you are using a supported hard partitioning software to bind a VM to a specific CPU. SE2 is not allowed to run on servers with more than 2 sockets.
    For an explanation and a list of supported hard partitioning technologies please see here:
  • Q:
    Is Oracle Multitenant available with SE2?
  • A:
    Oracle Multitenant is an Oracle Enterprise Edition only license. But you can have Oracle Single Tenant with many benefits meaning you'll have one pluggable database within one container database. Features such as remote cloning will be fully supported. See:
  • Q:
    Can we move PDB from SE2 Single Tenant to a EE Single/Multitenant database? 
  • A:
    Yes, of course - this is fully supported.

Database Installation and Patching

  • Q:
    Can I install Oracle Standard Edition SE2 into the existing home (in-place)?
  • A:
    Yes, this is possible even though I would never recommend to do this for the simple reason that wiping out your current home will increase the potential downtime and cause you plenty of extra work in case of fallback. If you still want to install for whatever reason into the existing home there's no change in handling to any other Oracle release since Oracle
  • Q:
    Which PSU should I apply on top of the releases Oracle Database Standard Edition SE2 installation?
  • A:
    Take the same PSU as you would take for an EE database - there's no difference and there won't be specific PSUs (or SPU/CPUs or BPs) released for SE2. Check out MOS Note:1683799.1 ( Patch Set - Availability and Known Issues) for the most recent recommended PSU
  • Q:
    Is RAC (Real Application Clusters) still included in SE2?
  • A:
    Yes it is - limited to 2 nodes, and each node must be a single-socket server. See above: there's the possibility to either remove a CPU physically - or hard partitioning with a supported virtualization solution such as OVM.
  • Q:
    I would like to use SE2 with RAC. Which Grid Infrastructure will I need to download?
  • A:
    When deploying a SE2 RAC Cluster please download the regular Oracle Grid Infrastructure (GI) packages from the official download locations (OTN, MOS, eDelivery). There's no separate download for an SE2 GI.
  • Q:
    Can I install/use SE2 on a 4-socket server?
  • A:
    No - SE2 is limited to be deployed on 2-socket servers only. And physically removing 2 CPUs from a 4-socket-machine does not satisfy the license agreement.
  • Q: 
    Can I deploy more than one SE2 database on a server?
  • A:
    Yes, of course you can.

Database Upgrade

  • Q:
    I want to upgrade from Oracle SE/SE1 to Oracle SE2. Is there any specific procedure or tool to use?
  • A:
    Upgrade works exactly as expected. There's no difference for SE2 compared to the upgrade procedure from Oracle EE to Oracle EE. 
  • Q:
    I would like to upgrade from Oracle SE/SE1 to Oracle EE. Is there any specific procedure or tool to use?
  • A:
    Upgrade is always the same procedure, regardless of SE, SE1, SE2 or EE. But if you'll convert from SE/1/2 to EE please follow the advises in MOS Note:2046103.1 (How to Convert Oracle Database 12c from Standard to Enterprise Edition ?)

Other topics

  • Q:
    Does the thread limitation in SE2 (16 in single instance mode, 8 per node in RAC mode) include background processes?
  • A:
    No, background processes such as LGWR or PMON are not included in this limitation.
  • Q:
    Is the thread limitation valid across all instances on the same server?
  • A:
    No, the limit is enforced per database instance and not per server.
  • Q:
    Does the thread limitation happen based on number of OS threads or CPU threads?
  • A:
    Actually the use of the term "threads" may be a bit misleading. Please have a look into the documentation about Instance Caging. That will explain how the thread limitation will be enforced. Views to monitor the resource usage are: V$RSRC_CONSUMER_GROUPV$RSRCMGRMETRIC and V$RSRCMGRMETRIC_HISTORY.
  • Q:
    Is there a core limitation for the hardware SE2 is installed on?
  • A:
    No, the box you'll use Oracle SE2 on can have as many cores as the CPUs offer. But there's a socket limitation of a maximum of 2 physical sockets. But the most modern CPUs can present 36 cores to SE2 on a 2-socket machine. 
  • Q:
    Can I disable Hyper Threading to present more "real" threads to the database?
  • A:
    Yes, this is possible but the effect may not be huge.


Monday Sep 14, 2015

SQL Plan Management - Known Issues in Oracle

Our Support colleagues released the patch recommendation note for SQL Plan Management (SPM) for Oracle Database


SPM Note

In the unlikely event you'd like to upgrade to Oracle Database or (very very unlikely hopefully) please see these matching notes:


Some additional things to mention:

  • SPM is an Oracle Enterprise Edition feature at no extra cost
  • SPM is THE feature to ensure plan stability tackling changes such as (of course) upgrades and migrations
  • SPM has been improved a lot internally in Oracle Database
    • We now store entire plans instead of a large accumulation of hints in the SQL Management Base (SMB) in SYSAUX tablespace
    • The "Evolve" task does happen automatically (SYS_AUTO_SPM_EVOLVE_TASK) as part of the Automatic SQL Tuning Task 
  • You should always adjust the retention when starting to play with SQL Plan Management as the default retention of 53 weeks may lead to a too large LOB segment in SYSAUX tablespace (and LOB segments never shrink)
    • SQL> exec DBMS_SPM.CONFIGURE('plan_retention_weeks',5);
  • See the Oracle Database 12c documentation about SPM:



Thursday Sep 10, 2015

Don't get puzzled by "sqlpatch" messages during Upgrade

During my last Hands-On-Labs in Uruguay and Argentina I've had several people wondering about these messages below when running the command line upgrade with - sqlpatch

This (and another) message breaks the nicely structured format of the output. And as it ends with an "err" extension it looks to many people as if the upgrade had gotten an error,

But please don't feel disturbed. It's just messages from sqlpatch invocation - and the "err" extension is just pointing to an error file in case something has gone wrong.

In a future release such messages will be written to the logfiles only but not to the screen output anymore.


Wednesday Sep 09, 2015

Different Metrics for SPA (SQL Performance Analyzer)

I'm more the command line type of person. Once I've understand what's going on behind the curtains I certainly switch to the GUI-click-click tools. But in the case of Real Application Testing - even though the support via the OEM GUI is excellent - sometimes I prefer to run my procedures from the command line and check my reports in the browser.

Recently Thomas, a colleague from Oracle ACS Support, and I were asking ourselves about the different comparison metrics for the SQL Performance Analyzer reporting We did scan the documentation but we found only examples but no complete list. Then we did ask a colleague but thanks to OEM we got an incomplete list as well.

Finally Thomas dug it out - it's stored in the dictionary in the table V$SQLPA_METRIC

SQL> SELECT metric_name FROM v$sqlpa_metric;


9 rows selected.

What do you do with these metrics now?

You can use them in such a way:

set timing on

   execution_name=>'Compare workload Elapsed',
   execution_type=>'compare performance',
                     'execution_name2','TEST 11107 workload'),
   execution_desc=>'Compare 11107 Workload on 12102 Elapsed');

You can vary the elapsed_time in my example with the various comparison metrics mentioned in v$sqlpa_metric


Tuesday Sep 08, 2015

MOS Download for Oracle Database including SE2

Please find all our articles about Oracle Database Standard Edition SE2:


You have 3 options to download Oracle Database Enterprise Edition and Oracle Database Standard Edition SE2.

Regarding OTN and eDelivery nothing has been changed since Sep 1, 2015 when Oracle Database Standard Edition SE2 got published. But the download from MOS now has changed.

When you search in the under Patches and Updates tab ...

Patches And Updates - MOS

... and display the Latest Patch Sets ...

Latest Patch Sets - MOS

... check for instance for platform Linux x86-64bit ...

MOS - Linux

... then you'll wonder about the two patch numbers ...

Patch Numbers Oracle SE2

The only difference of 2.5 GB in size results from two more zip files included in the new patch number 2141921 ...

... you'll have to check the README button to find out what's hidden behind each file ...

Files 3 and 4 contain Oracle Database Standard Edition SE2.

So please don't get puzzled by the different patch numbers - the only real difference is the inclusion of SE2 into the download package but the included patches etc are exactly the same as in the previous patch number. 



Monday Sep 07, 2015

Oracle Database SE2 - Support and Patches for Oracle Database SE/SE1

Oracle SE2

Please find all our articles about Oracle Database Standard Edition SE2:


Some questions regarding support for Oracle Database Standard Edition (SE/SE1) came up in the past days.

Most of those are answered already in MOS Note 2027072.1 (Oracle Database 12c Standard Edition 2 ( )

How long will Oracle Database in any edition remain under Premier Support? 

Full patching support for for all versions of 12gR1 (Enterprise Edition, Standard Edition and Standard One Edition) will be proviced for an additional 12 months from the release of SE2, so through until end August 2016. 

After that period Oracle Database will enter Sustaining Support. There won't be any Extended Support for Oracle Database in any edition.

Will there be PSUs and SPUs/CPUs available?

Yes, quarterly Patch Set Updates and Critical Patch Updates for will continue to be delivered until end of Premier Support for Oracle Database  

Will there be an Oracle Database Standard Edition SE/SE1? 

Beginning with the release of Oracle Database,  Oracle Database Standard Edition (SE) and Oracle Database Standard Edition One (SE1) are no longer being released. was the final edition that we will produce for SE and SE1.  

MOS Note:742060.1 Release Schedule of Current Database Releases does reflect this extension already:

Release Patching Ends

Notes and Exceptions* 31-Aug-2016



Thursday Sep 03, 2015

Can you have Oracle Multitenant in Oracle SE2?

Please find all our articles about Oracle Database Standard Edition SE2:


Can you have Oracle Multitenant in Oracle Standard Edition SE2?

No, you can't as Oracle Multitenant is a licensable option for Enterprise Edition (EE) databases only.

But wait a second ...

You can do Oracle Single Tenant with SE2 of course meaning you can have one active pluggable database within one container database at a time. That is possible and does not require any additional licenses.

See the DBCA (Database Configuration Assistant) screen when you'll try to create a container database:

DBCA - Single Tenant

More information? 

You'll find more information about the differences in handling and such between Oracle non-CDB, Oracle Single Tenant and Oracle Multitenant databases in this presentation:


Tuesday Sep 01, 2015

Upgrade downtime credited to APEX

Upgrade Blog posts about Oracle Application Express: 

What do you think when you see this post-upgrade result?

Oracle Database 12.1 Post-Upgrade Status Tool           08-07-2015 15:08:26

Component                               Current         Version  Elapsed Time
Name                                    Status          Number   HH:MM:SS

Oracle Server                          UPGRADED  00:19:26
JServer JAVA Virtual Machine              VALID  00:10:52
Oracle Workspace Manager                  VALID  00:01:52
OLAP Analytic Workspace                   VALID  00:00:34
OLAP Catalog                         OPTION OFF  00:00:00
Oracle OLAP API                           VALID  00:00:42
Oracle XDK                                VALID  00:01:07
Oracle Text                               VALID  00:01:36
Oracle XML Database                       VALID  00:03:55
Oracle Database Java Packages             VALID  00:00:22
Oracle Multimedia                         VALID  00:03:57
Spatial                                UPGRADED  00:08:56
Oracle Application Express                VALID  00:46:19
Final Actions                                                    00:03:48

Total Upgrade Time: 01:44:16

I've got a bit worried as the time to upgrade APEX took 44% of the complete database upgrade downtime. APEX (Oracle Application Express) is a fantastic piece of software which is still completely underrated - potentially because it is for free for everybody who has an Oracle Database license. And things not costing anything are just worth nothing, ey? 

Simply be aware when you have APEX in your databases installed - and especially if you ACTIVELY use APEX - it may be a very good idea to upgrade APEX upfront without causing downtime for your entire database.

See this blog post here about how to upgrade APEX upfront: 


Friday Aug 21, 2015

DBMS_STATS. GATHER_DICTIONARY_STATS fails with ORA-20001 ORA-6502 ORA-6512 - Concurrent Stats

I really have to say "Thank you very much" to the people out there alerting me about issues I haven't seen before. Just in the past week I've got to learn about three issues which are related to the upgrade - and I haven't seen before. Please don't expect me always to follow up with the progress of your SRs or the related bugs. But your experiences are such an important source for me - so thanks again!

The most recent issue (thanks to Bernd Tuba from MM Warburg) ...


execute dbms_stats.gather_dictionary_stats

ORA-06502: PL/SQL: numeric or value error: character string buffer too small
ORA-06512: at "SYS.DBMS_STATS", line 24268
ORA-20001: Unexpected configuration: sofar: 41 objList.count: 41 sofar_part: 0 partObjList.count: 0 sofar_ind: 0 indObjList.count: 21 concurrent: TRUE runPartTable: TRUE jstats.Running: -19
ORA-06512: at "SYS.DBMS_STATS", line 27383
ORA-06512: at "SYS.DBMS_STATS", line 27402
ORA-06512: at line 1

I see the word "CONCURRENT" - and it immediately rings a bell. Wasn't there an issue with the change of setting for default stats gathering in Oracle Database being now CONCURRENT=TRUE?

Yes ... the reason for this blog's existence is not only to give you some interesting useful information to read about but also to dump of details from my limited brain capacity :-) I have written something about a similar issue in October 2014:


This is interesting. Whereas in my other blog post the concurrent stats gathering conflicted with the resource manager settings and is fixed by a patch (Patch 19664340: ORA-20000: UNABLE TO GATHER STATISTICS CONCURRENTLY: RESOURCE MANAGER IS NOT ENABLED) this one is a different topic.

(unpublished bug - therefore no link included here)


Very simple to solve - switch CONCURRENT stats gathering to FALSE

SQL> exec dbms_stats.set_global_prefs('CONCURRENT', 'FALSE');

In the Exadata Upgrade Note (MOS Note: 1681467.1) you'll find the same recommendation. 

More Information? 


Tuesday Aug 18, 2015

Ouch, this hurts: bug 17325413 - patch BEFORE upgrade!

PatchI really don't want to turn this blog into something making our database look bad. But in this case it is really necessary as it is VERY UNUSUAL that we recommend to patch the database BEFORE upgrade

Just for clarification:

The following topic will affect all databases between and - those (and only those) need to be patched BEFORE upgrade. The topic is fixed in but as it gets introduced with the BEFORE upgrade database version you'll have to apply the fix before upgrade. The inclusion of the fix in means only that the misbehavior won't happen there again. But as it is a meta data dictionary corruption you'll have to apply the fix before as otherwise it will break during or after the upgrade.

First of all, thanks to Ehtiram Hasanov (cleverbridge AG) and Oliver Pyka ( for highlighting this to me. And sorry for hitting this issue ...


After upgrading to Oracle Database you'll get one of the below errors when trying to read data: 

  • ORA-07445: exception encountered: core dump [qcsIsColInFro()+358] [SIGSEGV] [ADDR:0x4] [PC:0xCDB4A26] [Address not mapped to object] []
  • ORA-12899 / ORA-607
  • ORA-600 [kdmv_check_row_2:IMCU row has wrong contents]
  • ORA-600 [kddummy_blkchk]
  • ORA-600 [kdBlkCheckError]
  • ORA-600 [klaprs_12]
  • ORA-600 [13013]
  • ORA-600 [17182] 


Basically this happens when you try to drop a column with a DEFAULT value and a NOT NULL definition - it ends up with dropped column data being written to disk leading to block corruptions. This causes problems for generating undo which cannot be applied; a ROLLBACK fails.

If you need more information please look up this MOS Note about
Bug 17325413 - Drop column with DEFAULT value and NOT NULL definition ends up with dropped column data hitting disk leading to corruption

Versions being affected:

  • These versions require to be patched BEFORE upgrade:
    • Oracle Database and above (may happen with earlier PSUs as well)
      Solution: Apply the fix 17325413  on top - see below
    • Oracle Database and 
      Solution: Apply the most recent PSU
  • These versions can get you the issue if you haven't patched BEFORE upgrade:
    • Oracle Database
    • Oracle Database

Workaround and/or Fix:

The MOS Note about Bug 17325413 - Drop column with DEFAULT value and NOT NULL definition ends up with dropped column data hitting disk leading to corruption explains the workaround WHEN you hit this issues. 

As a precaution you will have to make sure that you applied one of those fixes BEFORE upgrading to Oracle Database as the fix for Bug 17325413 is included in all those mentioned below (list is taken from above MOS Note as well).

The best way to avoid this is really to apply the patch (or the PSU/BP including the patch) before upgrading.

The issue has been mentioned in "Oracle - Known Issues and Alerts" (MOS Note:1562139.1)  under "Issues Introduced":

Issues introduced

But that does jump into your eye as a thing you need to fix before upgrade.
We'll see if we can get the issue added to the 12c MOS Notes as "Upgrade Issues".


Thursday Jul 30, 2015

SQL Monitoring - Limitation at 300 lines per statement

One of the best parts of my job at Oracle:
I still learn something new every day.

Yesterday I've learned from my colleague from Oracle Switzerland, Thomas Teske, that SQL Real Time Monitoring has an embedded default limitation on the number of lines in the statement. If the limit (default: 300 lines) is exceeded the statement won't be monitored. We both work with a leading Swiss company and we wanted to monitor a complex plan. 

Now you may think: Who the heck has statements longer than 300 lines?
Well ... sometimes that is beyond your influence as in this particular case this is of course done by the application.


SQL> alter system set "_sqlmon_max_planlines"=800 scope=both;

or set in your spfile:


This limitation is described in:

MOS Note:1613163.1
How to Monitor SQL Statements with Large Plans Using Real-Time SQL Monitoring?

If you'd like to read a bit more about SQL Real Time Monitoring please follow one of these links - and be aware that it's part of the Tuning Pack license and VERY helpful in many everyday situations. You'll have to have STATISTICS_LEVEL either TYPICAL (the default) or ALL and CONTROL_MANAGEMENT_PACK_ACCESS='DIAGNOSTIC+TUNING' (the default as well).



Things to consider BEFORE upgrading to Oracle to AVOID poor performance and wrong results

Finally it got published on MyOracle Support (MOS) portal - one of the most helpful notes when we prep for an upgrade or a migration - and potentially the one with the longest title in MOS:

MOS Note: 2034610.1
Things to consider BEFORE upgrading to Oracle Database
to AVOID poor performance and wrong results 

Avoid Poor Performance and Wrong Results when upgrading to

Just in case you are NOT upgrading/migrating to Oracle Database there are three other helpful notes for earlier releases available as well:

Document 1320966.1
Things to Consider Before Upgrading to
to Avoid Poor Performance or Wrong Results

Document 1392633.1
Things to Consider Before Upgrading to
to Avoid Poor Performance or Wrong Results
Document 1645862.1
Things to Consider Before Upgrading to
to Avoid Poor Performance or Wrong Results


Tuesday Jul 28, 2015

Optimizer Issue in Oracle "Reduce Group By"

Wrong Query Results BugDBAs biggest fears I'd guess are Optimizer Wrong Query Results bugs as usually the optimizer does not write a message into the alert.log saying "Sorry, I was in a bad mood today ..."

The Oracle Database Optimizer is a complex piece - and in Oracle 12c it delivers great performance results. Plus (my personal experience when you know what to do) it is more predictable which I like a lot when changing databases from one to another release. But due to its complexity sometimes we see issues - and sometimes it is necessary to switch off tiny little pieces until a fix is available.

Roy just came across this one - and we believe it's worth to tell you about it. Again, our intention is only to prevent issues when upgrading or migrating to Oracle Database


An outer join query with a bind variable and a group by clause can produce wrong results in some cases.


 If all of the following match, you may be hitting this bug:
 - two or more subquery views are outer-joined on column C1
 - column C1 is specified on select list of top-most query block
 - column C1 is filtered on a bind value


 create table test1(c1 number(5),c2 varchar2(16));
 insert into test1 values(1,'3');

 variable num1 number
 execute :num1 :=1;

 -- Following query retuns wrong result(NULL), this should return 1.

 select V.c1 from
  (SELECT c1 FROM test1 GROUP BY c1) V,
  (SELECT c1 FROM test1 WHERE c2 = '1' GROUP BY c1) V2
 where  V.c1 = :num1
    and V.c1 = V2.c1(+);


alter session set "_optimizer_reduce_groupby_key" = false;

Please don't use the workaround:
alter session set optimizer_features_enable='';
as this will switch off other good optimizer features working very well.

More information:

See MOS Note:20634449.8 describing:
Bug 20634449 - Wrong results from OUTER JOIN with a bind variable and a GROUP BY clause in

As far as I can see there are no interim (one-off/single) patches available right now. 


Friday Jul 24, 2015

Why does a PDB require an upgrade?

Why do I need to upgrade (or downgrade) a Pluggable Database (PDB) once I unplug it from version A and replug into version B?

This question is one of the most often asked questions in our workshops when Roy and I present Upgrades and Oracle Multitenant.

If you take a look into the documentation you'll find:

But unfortunately this is not 100% correct for every object.

When you do a simple query for basic dictionary structures such as OBJ$ you'll easily find out that a PDB has its own Data Dictionary.  Some things are really linked into the PDB only - check the SHARING column of DBA_OBJECTS for instance. If it says "METADATA LINK" it will give you an indication that it exchanges information with its parent in the CDB$ROOT. But that doesn't mean necessarily that it's just an empty meta object. Some tables do exist in the PDB as well and allocate space. Check it by yourself and you'll find out that OBJ$ inside a PDB has in fact the same attribute - but still owns segments in the PDB and in the CDB$ROOT - as other objects do allocate space as well. And of course the object's definition exists in the PDB as well. 


    OBJ$ in CDB$ROOT

  • PDB 

    OBJ$ in PDB

So the answer is simple:
A Pluggable Database (PDB) must be upgraded (or downgraded) when it get moved between versions simply because it has its own data dictionary. And this doesn't get upgraded automatically.



Friday Jul 03, 2015

News on Oracle Database STANDARD EDITION

Standard EditionJust fyi in case you had bookmarked this blog post or found a link to it:

Oracle Database Standard Edition (SE2) is now available for download.

Please find the updated information here:


Wednesday Jul 01, 2015

Log Writer Slave Issues in - mainly on IBM AIX

Currently we see a lot of issues with the Multiple Logwriter feature in Oracle Database, especially on the IBM AIX platform.

What are Multiple LGWRs?

You will see multiple LGnn (Log Writer Worker) processes on multiprocessor systems, The LGWR (Log Writer) creates worker processes (slaves) to improve the performance of writing to the redo log. LGnn (Log Writer Worker) processes are not used when there is a SYNC standby destination. Possible processes include LG00-LG99.

Here is a list of new background processes in Oracle Database 12.1:
MOS Note 1625912.1 - New Background Processes In 12c 

For deep dive information about how to trace the LGWR (and DBWR) and the differences 11.2/12.1 and wait events and much more, please see this Deep Dive PDF from an UKOUG talk from Frits Hoogland.

Known Symptoms:


Turn off multiple logwriters on IBM AIX at the moment - in some cases this may solve issues on other platforms as well but please don't take this as a generic recommendation for all platforms. We are seeing the issues mainly on IBM AIX.

Set in your spfile: 


See also:




Mike Dietrich - Oracle Mike Dietrich
Master Product Manager - Database Upgrade & Migrations - Oracle

Based in Germany. Interlink between customers/partners and the Upgrade Development. Running workshops between Arctic and Antartica. Assisting customers in their reference projects onsite and remotely. Connect via:

- -


« December 2015
Slides Download Center
Visitors since 17-OCT-2011
White Paper and Docs
Viewlets and Videos
Workshop Map
x Oracle related Tech Blogs
This week on my Rega & Pono
Upgrade Reference Papers