RE: Memory issue with Oracle 10g database on Sun Server T5140 with Solaris 10

  • From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
  • To: "Andrew Kerber" <andrew.kerber@xxxxxxxxx>
  • Date: Thu, 16 Oct 2008 16:34:13 -0400

The T2 processors get some sort special licensing deal from Oracle (not
sure, but like .25 per core or something...).

I agree that this was the wrong server for the job but only in this one
aspect (RMAN compression or any compress utility).

In all other cases the server has been lightening fast.  We are still
playing around with possible workarounds.   IIRC 11g has a tunable
compression method for RMAN (but I am not sure) so this might address
the issue in the future.   For cases where small bits of info (less than
1mb) are encrypted or compressed, it seems to work fine.

 

________________________________

From: Andrew Kerber [mailto:andrew.kerber@xxxxxxxxx] 
Sent: Thursday, October 16, 2008 4:20 PM
To: Crisler, Jon
Cc: ashoke.k.mandal@xxxxxxxxxxxxx; oracle-l
Subject: Re: Memory issue with Oracle 10g database on Sun Server T5140
with Solaris 10

 

You might want to consider re-evaluating your hardware.  Have you looked
at your probable licensing costs with that sort of configuration?  I
dont think its going to cost effective.

On Thu, Oct 16, 2008 at 3:12 PM, Crisler, Jon <Jon.Crisler@xxxxxxx>
wrote:

This is unrelated, but I wanted to warn you of a possible issue on this
machine if you are using any sort of compression programs, such as
compress, gzip, RMAN using compressed backup sets.  Programs that make
extensive use of floating point operations tend to run slower on these
boxes, sometimes dramatically slower.  The design of the processors put
emphasis on other areas of performance, with the result that floating
point performance was deemphasized.

In one particular test, I have a 170gb database in 10g.  Backing that db
up via RMAN compressed backup sets to disk, using 8 streams, takes 12+
hours.  Running the same backup without compressed backupsets takes 30
minutes (and takes twice the disk space).  I am getting some positive
news from coworkers when using pbzip2 on this class of Sun servers.


-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Mandal, Ashoke
Sent: Thursday, October 16, 2008 10:16 AM
To: oracle-l
Subject: Memory issue with Oracle 10g database on Sun Server T5140 with
Solaris 10

Greetings All,

I am trying to create an Oracle 10.2.0.4 database with SGA_TARGET=256M
on Sun T-5140 server with Solaris 10 but getting the following error
ORA-00821: Specified value of sga_target 256M is too small, needs to be
at least 536M

When I increased the SGA_TARGET to 536M and tried creating the database
then I received the following error:
ORA-12853: insufficient memory for PX buffers: current 0K, max needed
11088K
ORA-04031: unable to allocate 65560 bytes of shared memory ("large
pool","unknown object","large pool","PX msg pool")

When I set the large_pool_size to 11088K and tried creating the database
then I received the following error:
ORA-00821: Specified value of sga_target 536M is too small, needs to be
at least 548M

When I increased the SGA_TARGET to 548M and set large_pool_size to
11088K then it moves little further but failed again with the following
errors:
error 4031 detected in background process
ORA-04031: unable to allocate 2840 bytes of shared memory ("shared
pool","unknown object","sga heap(1,1)","KQR XPO"

If I specify the SGA_TARGET as 900M then I was able to create the
database without any problem. But I am looking for a solution so that I
can create 10.2.0.4 database on this hardware with SGA_TARGET as 256M.
T5140 server has total of 16 CPUs and with 8 threads it has 128 virtual
CPUs. We have also experimented that if we set the cpu_count to 4 in the
init.ora then we were able to create the database with SGA_TARGET as
256M.

I am wondering if any of you have experienced such problem and have
recommendation to this issue as I can't afford to allocate 1GB of SGA to
each of  70 databases on the same server having only 64GB of RAM.

Thanks,
Ashoke Mandal


[CONFIDENTIALITY AND PRIVACY NOTICE]

Information transmitted by this email is proprietary to Medtronic and is
intended for use only by the individual or entity to which it is
addressed, and may contain information that is private, privileged,
confidential or exempt from disclosure under applicable law. If you are
not the intended recipient or it appears that this mail has been
forwarded to you without proper authority, you are notified that any use
or dissemination of this information in any manner is strictly
prohibited. In such cases, please delete this mail from your records.

To view this notice in other languages you can either select the
following link or manually copy and paste the link into the address bar
of a web browser: http://emaildisclaimer.medtronic.com
--
//www.freelists.org/webpage/oracle-l


--
//www.freelists.org/webpage/oracle-l






-- 
Andrew W. Kerber

'If at first you dont succeed, dont take up skydiving.'

Other related posts: