The bug fixing support for Oracle Database 11.2.0.3 will end soon.
From my visits in the past months seeing some really large customer environments with easily over 1000 production databases each I can tell you that there may be many Oracle 11.2.0.3 installations out there. So maybe not everybody is aware of this fact.
It’s hard to believe but the Error Correction Support for Oracle Database 11.2.0.3 will end shortly on August 27,2015.
See MOS Note:742060.1 for further details.
And does it need to be said?
Yes, you can – of course – upgrade directly to Oracle Database 12.1.0.2.
–Mike
Will Oracle be providing Critcial Security Patches for 11.2.0.3 past Aug 27 2015?
Easy answer: No.
When bug fixing support has ended there won’t be any bug fixes anymore – and this will apply of course to PSUs/CPUs/BPs as well. Latest PSU will be the July 2015 one.
Cheers
Mike
Hello Mike Dietrich,
I am reaching out to get advice on the post upgrade plans for upgrading a 110TB RAC Database currently on 11.2.0.3 to 11.2.0.4.
I have learnt about the Bug 15898932 – Wrong Cardinality estimation with predicates over nchar columns. (Doc ID 15898932.8), which we are planning to address but the issue is we are hitting around 2600+ tables of which some are in greater than couple of TB in size and really looking at ways if we can avoid re gather statistics /global statistics etc.
SQL oracle provided to identify Bug 18255105 Patch for upgrade scripts to identify histograms affected by fix of bug 15898932
select distinct OWNER, OBJECT_NAME TABLE_NAME from dba_objects where OBJECT_ID in (
select t.obj# from sys.tab$ t, sys.col$ c /* non-partitoined tables */
where bitand(t.property,32+512+4194304+8388608+2147483648) = 0
and bitand(t.flags,536870912) = 0
and bitand(t.flags,2097152) = 0 /* monitoring is off */
and bitand(t.flags,16) != 0 /* analyzed */
and t.obj# = c.obj#
and c.type# = 96 /* char type column */
union all /* table partitions */
select tp.obj# from sys.tabpart$ tp, sys.tab$ t, sys.col$ c
where tp.bo# = t.obj#
and bitand(t.flags,2097152) = 0 /* monitoring is off */
and bitand(tp.flags,2) != 0 /* analyzed */
and t.obj# = c.obj#
and c.type# = 96 /* char type column */
union all /* table subpartitions */
select tsp.obj# from sys.tabsubpart$ tsp,
sys.tabcompart$ tp, sys.tab$ t,
sys.col$ c
where tsp.pobj# = tp.obj# and tp.bo# = t.obj#
and bitand(t.flags,2097152) = 0 /* monitoring is off */
and bitand(tsp.flags,2) != 0 /* analyzed */
and t.obj# = c.obj#
and c.type# = 96 /* char type column */)
order by owner;
Thanks
Rana,
which type of advice are you seeking from me?
Cheers
Mike
Would you have any recommendations for post upgrade steps to avoid collecting global stats etc and avoid hitting the bug or general performance problems for slowness from your thoughts or experience?
Hi Rana,
I think it’s unavoidable. What comes to my mind is the new “hyperloglog” algorithm in 12.2 which will create significant smaller synopsis for inc stats. But apart from that I don’t see any relief to avoid this recalc.
For general advice, you may please check our slide deck (see: https://MikeDietrichDE.com/slides ) – use the “big deck” and scroll to slide ca. 450. There we have a lot of performance advice – and most of it is valid form 12.1.0.2 as well.
Cheers
Mike