Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: 9.0.2 64-bit on redhat 3.0r2 AMD64 (4-way) 17G RAM
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