Re: Oracle Standard Edition & RAC

Hi,

what I would NEVER recommend to anybody is the scaling with RAC on Win 32-bit.

The customer decided to "protect the investments in the hardware", so one of 3 node RAC was equipped with 8 32-bit Xeons. The other 2 were 64-bit capable. There also was VLM.

I'll never forget that implementation. Count it as my biggest failure in ~10 years of Oracle experience, though it was not purely my fault (I've joined the project just before going into production and was unable to stop that mess).

I know now, that use_indirect_data_buffers leads to ~doubling the space required for buffer headers. I've seen 20-30 thousands of reloads/hour on the normally loaded system. I've seen how LMD loses the info about global lock (in our case it was mainly LB, but two of tens cases might be attributed to losing BH). The bug (5595214) was opened but didn't resolved, as we managed to convince the customer to continue to "protect his investment" in a reporting server :-).

The version was 10.2.0.2.8P if anybody is interested.

HTH
--Andrey

Niall Litchfield wrote:
> On 1/5/07, *Alex Gorbachev* <gorbyx_at_gmail.com
> <mailto:gorbyx_at_gmail.com>> wrote:
>
> A single node 4 CPU SE should scale even better than 2 node x 2 CPU SE
> RAC so using SE RAC for scalability is luxury and company doing so has
> way too much money.
>
>
> Hi Alex
>
> I'd say it depends on the app and the platform. There are systems - it
> would be purely posturing to say what proportion of them as I have no
> idea - that will require more than the 1.7gb process limit on a 32bit
> platform before they exhaust the CPU capacity of the opteron based
> machines that you use as an example.
> --
> Niall Litchfield
> Oracle DBA
> http://www.orawin.info <http://www.orawin.info>

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