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

From: Crisler, Jon <Jon.Crisler_at_usi.com>
Date: Thu, 16 Oct 2008 16:34:13 -0400
Message-ID: <56211FD5795F8346A0719FEBC0DB0675033A987C@mds3aex08.USIEXCHANGE.COM>


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_at_gmail.com] Sent: Thursday, October 16, 2008 4:20 PM To: Crisler, Jon
Cc: ashoke.k.mandal_at_medtronic.com; 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_at_usi.com> 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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] 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
--

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

--

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

--

Andrew W. Kerber

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

--

http://www.freelists.org/webpage/oracle-l Received on Thu Oct 16 2008 - 15:34:13 CDT

Original text of this message