A short mail on behalf of Dirk Verkens, there seems to be a problem for him
when posting to the list, if you have issues send me a mail (you should have it
)
As promised my experience migrating to 12c on Exadata.
Used versions
GI and DB : 12.1.0.2.7
Exadata version : 12.1.2.1.0
The upgrade went very smootly.
we had already set following hidden parameters to fix bugs with invalid result
see
12.1.0.2 Patch Set - Availability and Known Issues (Doc ID 1683799.1)
Bug 20634449 : alter session set "_optimizer_reduce_groupby_key" = false;
Bug 19567916 : alter session set "_optimizer_aggr_groupby_elim"=false;
First checks
With the first basic checks we faced problems with jdbc thin connections and
some expected security issues.
- The security issues are related to INHERIT PRIVILEGES for the SYS user.
- The jdbc connections received ORA-28040: No matching authentication protocol
for JDBC Thin drivers
which is fixed by specifying folowing sqlnet.ora enty
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
We also noticed that all autotask are re-enabled because upgrade executes to
dbms_auto_task_admin.default_reset('ALL');
So you might want re-disable those who were disabled before .
Regression tests
During our regression tests, we faced again some bugs with invalid results all
cases are related to GROUP BY and or SUM ( CASE ...)
The First one resulted in either no rows or the result was a null value
This is fixed by exadata 12.1.2.1.2 (Exadata issue EX23 bug 21174310)
So we applied the exadata patch on our NON-production Exdata (which is faster
as before because of less backups) and balanced the DB to this side for further
regression test.
As the NON-producion Exadata is a mix of X3 & X5 we faced a lot of enqueue
contentions
found note 2028503.1 and by setting “_ges_server_processes” the problem was
fixed.
The 2nd invalid result bug used again a SUM ( CASE .. GROUP BY)
the invalid result is either an extreme high value like
3.75757619900002580546136E99 or the statement aborts with ORA-07445
an SR has been opened but until now no solution for it, we could work-around
this issue by adding a function on the case column (in our case upper(col)
Also notice that between the start of our 12c POC (beginning July 2015) and now
there are 4 new exadata issues raised by the Exachk (EX23/EX24/DB30/DB31)
So we have applied GI/DB patch 12.1.0.2.11 however it does not fixed the 2nd
invalid result issue.
Conclusion
I don't want to scare off anyone migrating to 12c but there seems to be a lot
of issues with the optimizer resulting in invalid results.
one might consider specifying optimizer_features_enable=11.2.0.4 instead of
specifying all hidden parameters.
But make sure you plan enough time for regression tests.
Kind Regards,
Verkens Dirk
Philippe Fierens
philippe@xxxxxxxxxxxxxxxxxxxx
