Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 








Bad slow performance after upgrade to 64-bit server

Oracle Database Tips by Donald Burleson


Question:  I just upgraded my server from 32-bit to 64-bit and my performance has gotten significantly worse.  The 64-bit server has 16 CPU's and 32 gig of RAM.  All SQL was optimized on the 32-bit server and there are no changes to SQL execution plans on the 64-bit server.  This is my SGA data:


SQL> show sga

Total System Global Area 7516192768 bytes
Fixed Size 2082816 bytes
Variable Size 4731176960 bytes
Database Buffers 2768240640 bytes
Redo Buffers 14692352 bytes


These are my top-5 timed events:


Top 5 Timed Events

Event                   Waits Time(s) Avg Wait(ms) % Total Call Time Wait Class
CPU time                     16,945    53.0
db file sequential read   1,875,284              13,918 7 43.5 User I/O
db file scattered read       94,370                 686 7  2.1 User I/O
read by other session       126,271                 676 5  2.1 User I/O
control file sequential read 66,023                 225 3   .7 System I/O


Also, the vmstat shows high runqueue values, far more than my CPU count::


r b swpd free buff cache si so bi bo in cs us sy id wa
60 0 240 166312 985452 24778704 0 0 185 40 1 0 9 1 88 2
53 0 240 135488 985468 24782300 0 0 480 341 1861 2572 84 2 14 0
57 0 240 95872 985484 24782800 0 0 264 969 1629 1120 84 3 13 0


How do I adjust poor performance when migrating from 32-bit to 64-bit Oracle?

Update - The problem we eventually found out wasn't an Oracle problem at all. We had a hardware problem that wasn't NUMA aware. Oracle had made changes to its code to best manage memory on NUMA aware systems (i.e. Sun Solaris, HP-UX etc).


Apparently we had an IBM machine with Redhat Linux that wasn't and hence made the machine do much work in trying to allocate memory from the slave machines. In any case, we have the wrong machine and we are making alternative plans towards addressing that issue.   I understand SLES-9 is NUMA aware, but there may be additional patches required to fully enable it:


Answer:  I have seen vast differences in performance after an upgrade to a 64-bit server with performance ranging from a 20% decease to a 300% increase, depending on the type of database load.  Some applications become more CPU-intensive under 64-bit architectures, that's just how they work.


In your case, your server is clearly CPU constrained (high vmstat runqueue values), and if your SQL has not changed execution plans then:

  • Try MOSC notes on 64-bit migrations (see below)

  • If SQL and library cache are optimized, add 8 more processors.

Also, note that Oracle has changed the optimizer costing model from "IO" to CPU" in 10g, and shops that combine an upgrade to 64-bit servers with a 10g migration may want to look at changing the new default for _optimizer_cost_model.


MOSC recommends trying adjustment of some hidden parms, but only at the direct request of Oracle technical support:

_b_tree_bitmap_plans = FALSE
_index_join_enabled = false
optimizer_secure_view_merging = FALSE
_complex_view_merging = FALSE


Going 64-bit means that you can now allocate very large RAM data buffers and increase your shared_pool_size above two gigabytes.  However, it is important to remember that there are downsides to having a super-large db_cache_size. While direct access to data is done with hashing, there are times when the database must examine all of the blocks in the RAM cache.  These types of database may not always benefit from an upgrade to a 64 bit server:

  • Systems with high Invalidations: Whenever a program issues a truncated table, uses temporary tables, or runs a large data purge, Oracle must sweep all of the blocks in the db_cache_size to remove dirty blocks. This can cause excessive overhead for system with a db_cache_size greater than 10 gigabytes.

  • High Update Systems: The database writer (DBWR) process must sweep all of the blocks in db_cache_size when performing an asynchronous write. Having a huge db_cache_size can cause excessive work for the database writer.  Some shops dedicate a separate, smaller data buffer (of a different blocksize) for high-update objects.

  • RAC systems: Oracle RAC and Grid does not perform optimally with super-large data buffer RAM, as available in 64-bit systems. You may experience high cross-instance calls when using a large db_cache_size in multiple RAC instances. This inter-instance "pinging" can cause excessive overhead, and that is why RAC DBA's try to segregate RAC instances to access specific areas of the database. This is why Oracle 10g grid server blades generally contain only 4-gig RAM.

MOSC notes on 64-bit upgrades


  • Note 258167.1 Upgrading from 8.1.X to 9.X - Potential Query Tuning Related Issues

  • Note 295819.1 Upgrading from 9i to 10g - Potential Query Tuning Related Issues

  • Note 209766.1 - Make sure to set disk_async_io, increase the size of the shared_pool

  • Note 223806.1 Query with unchanged execution plan is slower after database upgrade

  • Note 160089.1 - Server Upgrade Results in Slow Query Performance 

If you like Oracle tuning, see the book "Oracle Tuning: The Definitive Reference", with 950 pages of tuning tips and scripts. 

You can buy it direct from the publisher for 30%-off and get instant access to the code depot of Oracle tuning scripts.



Oracle Training at Sea
oracle dba poster

Follow us on Twitter 
Oracle performance tuning software 
Oracle Linux poster


Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.