Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: 9.0.2 64-bit on redhat 3.0r2 AMD64 (4-way) 17G RAM

Re: 9.0.2 64-bit on redhat 3.0r2 AMD64 (4-way) 17G RAM

From: Artis Gripemore <wealtheow1_at_yahoo.com>
Date: 28 Aug 2004 01:57:52 -0700
Message-ID: <69750f44.0408280057.d96afc3@posting.google.com>


Sybrand Bakker <gooiditweg_at_sybrandb.verwijderdit.demon.nl> wrote in message news:<7ncvi09665grktpu1t2v701quva84j084p_at_4ax.com>...

> Probably you are using a 32-bit version of Oracle.

Yes, I thought of that. I am assured that I am using the 64-bit version. (Of course, that is 16G RAM, not 17.)

> On the whole this configuration is fully and utterly ridiculous.

I don't doubt it. But the problem is not whether it is practical, but why it cannot be done. All I want to know is why, no matter what I do, I can't get cache over 2G. The machine does nothing else, so I do not need to be conservative. Oracle's site tells me that the formula is 50% RAM for oracle, half SGA and half PGA. I want to know why I can't do this.

> Block size should be 8k not 2k, as most Unixes have a block size of
> 8k.

We are stuck with 2048K blocks, and a request to increase the setting was rejected. I cannot remake the db, only tune the machine and initSID.ora to handle what up to now has been a horribly slow setup.

> db_cache_size is ridiculous, get it down to 256m

We get thrashing and very high i/o wait when we reduce it. We have a huge db, and a lot of transactions. But I will try it. All I want to do is set it up to have every resource it can on the server. I have no reason to limit things; the goal is to exploit the server fully.

> pga_aggregate_target is ridiculous as this is a *per session* limit.
> 64 to 128m should be more than enough.

Thanks! Nothing I have read at Oracle mentioned this, and indeed I'm only following "expert" Internet advice with these settings.

> Shared pool should be 40M min.

Thanks. This was set by the vendor. I can ask.

> All in all I would recommend you to read, and to read, and to read
> those manuals. You obviously heard the bell ring, but don't have a
> clue.

No I don't. Nor do I have manuals. What I have is a db that killed an HP PA-RISC 2-way with 4G (now transferred to a much more capable machine), a vendor who is loathe to share information about said db and could not / would not improve performance on the old machine, and you guys. If that is pathetic, so be it. I am really quite grateful for your help. Received on Sat Aug 28 2004 - 03:57:52 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US