Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are in the process of upgrading our Oracle database server at work, from SUSE Linux Enterprise Server 10.4 / Oracle 10g / 4GB RAM (Intel 32-bit) to Scientific Linux 6.4 / Oracle 12c / 8GB RAM (Intel 64-bit).

As the first step, the additional RAM has been installed, but due to some application-related issue we had to pend the rest of the planned upgrade. To clarify, the server is still running Oracle 10g and SLES 10.4. No change has been made on the software side

Since the installation of the additional RAM, however, the only database instance on that machine has been running out of shared memory (with the error in the title) two afternoons in a row. The depletion was severe enough that the only way to recover was using SHUTDOWN ABORT.

No configuration change has been made, e.g. to the memory settings of the database:

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 1632M
sga_target                           big integer 1632M
pga_aggregate_target                 big integer 384M
db_16k_cache_size                    big integer 0
db_2k_cache_size                     big integer 0
db_32k_cache_size                    big integer 0
db_4k_cache_size                     big integer 0
db_8k_cache_size                     big integer 0
db_cache_advice                      string      ON
db_cache_size                        big integer 960M

It seems that the extra RAM actually cause the Oracle database software to have less RAM available to itself than before, but how exactly is this happening?

share|improve this question
You've upgraded to Oracle 12 already? A few months after its release? You must be mad. It really is best practice to wait 6 months to a year before even pondering such an upgrade - god knows what crappy bugs are still there. – Phil Sep 17 '13 at 21:45
cursor_sharing=FORCE or something similar may have been set on the 10g instance. Have you compared v$parameter on both instances? – Phil Sep 17 '13 at 21:51
To clarify, we've only upgraded RAM, and not the Oracle installation as yet. We've tested Oracle 12 and have deployed it on some of our servers just fine. And no, we're not using forced cursor sharing. Tried that and some of the applications couldn't cope, so both before and after, the server is still using cursor_sharing=EXACT – michel-slm Sep 17 '13 at 22:04
Fix your question so that it's clear about what you've done. – Colin 't Hart Sep 18 '13 at 8:24
If the server still have a 32bit OS, it cannot benefit of the RAM upgrade. – Emyl Sep 26 '13 at 15:48

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.