RE: 64-Bit Oracle on Windows 2003

>> There are a number of reasons, but one of them is that certain
data structures will grow in size. I did a presentation on this and looked at the latch structure. This one grew 25 percent in size (I think it was oracle9i). The simple reason for that is that sizeof(ptr_t *) has become twice as large. Now if that really impacts the overall performance I don't know, but moving to 64 bit from 32 bit and leaving the init.ora parameters the same, doesn't help performance. Infact you need to bump shared pool just to overcome the growth of the library cache structures. The number of buffers per hash chain in the library cache is also different from 32 bit to 64 bit, (due to size and hashing).          

...Anjo, I know that you know that I know these facts. However, memory/cache lines
on 64bit processors are larger to accommodate the latch dynamic (klst) and it is simple to increase the shared pool and to configure enough memory
to accommodate the variable SGA component. Not to mention most 32->64 bit
upgrades coincide with enough other system improvements (e.g., bus speed/architecture
improvements ala northbridge->hypertransport) to further make the sheer size of SGA structures not as important.

   The comment that was made in the original thread was that "migrating from
32-bit to 64-bit alone (all other variables remaining the same)". I was hoping
for real measured differences and I think such would have to come from Sol/HPUX or
AIX (maybe windows) since Linux x86 Oracle on x86_64 HW is a bit dodgy.

   I have tested 32bit (x86) verses x86_64 Oracle on the same hardware and
did not see differences that would back up these claims...there again, that is not the same as going from a 32bit env to a 64 bit env...that is more of an apples/apples SW-only test.    

   In my previous life I did all that other testing too :)

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