0

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?

Improve this question
6
  • 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, 2013 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, 2013 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, 2013 at 22:04
  • Fix your question so that it's clear about what you've done.
    – Colin 't Hart
    Sep 18, 2013 at 8:24
  • If the server still have a 32bit OS, it cannot benefit of the RAM upgrade.
    – Emyl
    Sep 26, 2013 at 15:48

1 Answer 1

Reset to default
0

The error just means that the shared_pool ran out of free space. This can be caused by many things, mostly application related. Make sure your shared_pool has a minimum size needed to run your application. Sometimes it helps to increase the shared_pool_reserved_size so larger objects can be loaded in there.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.