Short notes taken during the test phase for installation of patchset 10.2.0.4

Let me start with a bit harsh, but nevertheless a realistic warning: if your search engine landed you here and if you’re looking for quick and dirty list of steps to upgrade your Oracle database, then please, stop reading and keep searching! And don’t make fool of yourself asking on public forums questions like this: “…can you please give me step by step instructions for patchset installation…it’s really URGENT…” – someone asking questions like this one should not be the one who is installing anything on the server, including patchset. Personally, I’ll always make sure to keep such people as far away as I can from the back office (and hence away from myself!).
If you’re totally new to Oracle patchset installation, you need one and only one starting document, with interesting name – readme.html.

At the time of this writing (end of July 2008) there are some known issues listed in Metalink note 555579.1 “10.2.0.4 Patch Set – Availability and Known Issues”. Make sure you read it. In particular the following notes:

• Note:580561.1 “ORA-600 [kddummy_blkchk][file#][block#][18038] during extent operations like TRUNCATE”; if you’re using ASSM tablespaces and direct path loads/inserts (as well as drop/truncate on those segments), you should apply patch 5386204 (at the time of this writing patch is not yet available for Windows x64)
• if you’re running Oracle10g on Windows 2003 SP1 make sure you read Metalink note 464683.1 “Unexplained Database Slowdown Seen on Windows 2003 Service Pack 1”
• and a non-critical one; Metalink note:726418.1ALERT: “The 10.2.0.4 Windows Patchset Overwrites %ORACLE_HOME%\network\admin\sqlnet.ora”, nevertheless Oracle republished 10.2.0.4 patchset on 10. July 2008 (first release for x64 was on 19. May 2008). You can simply backup sqlnet.ora file an restore it after wards – meaning that you don’t need to re-download updated version just to fix this bug, if you have version from 19th of May.
• Bug 5082178 – Bind peeking may occur when it should not — this bug was fixed in 10.2.0.4, meaning that some queries that’re now running fine (due to the bind peeking taking place, even when it should not) can now experience performance problems. I don’t think we can truly test this due to a large number of schemas, applications etc. We’ll see how lucky we’re ;-)

We’ll take particular care for these three critical bugs introduced in 10.2.0.4:

• Bug 7038750 – Dump (ksuklms) / instance crash — it’s less likely to happen on non-RAC but still possible…fortunately there is workaround available to avoid crash.
• Bug 5868257 – Dump / memory corruption from UPDATE DML
• Bug 6917874 – Wrong results from multi level push of join predicates

In readme.html you’ll find in section “15.19 Native Full Outer Join Implementation” Oracle recommendation to turn on hidden parameter:

_optimizer_native_full_outer_join =force

I’ll certainly not follow their advice. If they’re confident in the benefit of turning this parameter on, then why is it listed in patchset as as step that should be performed by DBA. Are they afraid of possible regression? ;-)

It’s always interesting to examine platform specifix bugs that were fixed by patchset. The bugs fixed in 10.2.0.4 on Windows x64 that caught my attention:

• 5940550 VIRTUAL MEMORY OF ORACLE.EXE GROWS ON 64 BIT X86 WINDOWS PLATFORM
• 5205552 EXCEPTIONAL HIG VM SIZE USAGE FOR ORACLE.EXE ON 64 BIT X86 WINDOWS PLATFORM
• 5041672 64-BIT WIN2K3 OS IS INCORRECTLY REPORTED AS 32-BIT WIN2K3
• 4927774 UNRESPONSIVE SYSTEM WITH HIGH KERNEL CPU UTLIZATION

One thing that remains open at this stage of testing 10.2.0.4 is Large Pages support in 10g. We failed miserably trying to setup Oracle10g to use Large pages with 10.2.0.3. For now, it remains unclear which fault it is; Oracle, Microsoft or simply ours.