Re: Memory issue with Oracle 10g database on Sun Server T5140 with Solaris 10
- From: "Bradd Piontek" <piontekdd@xxxxxxxxx>
- To: Jon.Crisler@xxxxxxx
- Date: Thu, 16 Oct 2008 15:43:58 -0500
As far as I know, the T2 chipset gets no special licensing from Oracle (it
is .75 per core like any other non-Intel/AMD processor). The T1 chipset that
was found on the T2000 had the .25 per core.
There is an article from Sun that talks about all the oracle related things
you may see regarding performance on the CoolThread chips.
http://blogs.sun.com/glennf/resource/Optimizing_Oracle_CMT_v1.pdf
Bradd Piontek
"Next to doing a good job yourself,
the greatest joy is in having someone
else do a first-class job under your
direction."
-- William Feather
On Thu, Oct 16, 2008 at 3:34 PM, Crisler, Jon <Jon.Crisler@xxxxxxx> wrote:
> 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:
