Hi all...

Will Oracle 10g 64-bit database run on RHEL 5.4 32 bit OS ?

Because for our Oracle applicatons to run we need RHEL 32 bit OS...

Thanks in advnace...

no, you can't run 64 bit software on a 32 bit operating system. The opposite way round works, but not that way.

Thanks a lot acid_kewpie,

Is it necessary to have two servers one for Database with 64 bit OS and another for apps with 32 bit OS ?

Yes, sure you can

No. 64-bit RHEL or Centos can run 32 bit applications just fine (generally better than a 32 bit Linux can run 32 bit applications).

If you were severely short of ram or disk space, you wouldn't want to have both 32 and 64 bit versions of all the .so files in use at once. But if you were even moderately short on ram or disk space, I don't think you would want a 64 bit database.

What is the basis for that statement?

In Debian based Linux, there seem to be rare cases where you need to go all the way to a fake root to get 32 bit software working in a 64 bit system. But you can get it working even in Debian. RHEL and Centos have less issues with 32 bit applications in a 64 bit OS.

Thanks johnsfine,

But the problem is Oracle Applications prerequisites document specifies, it can run only on 32 bit OS if the machine architecture is 64 bit..

Below is the Note specified in Prerequisite document...

In that case you either run 32 bit Oracle DB, or get another system..
It's pretty strange though. On RHEL/Centos (5.x), both sets of libs (32 & 64 bit) are installed on a 64 bit version, and usually everything (32 & 64 bit) apps run fine.

To John Fine: I'm curious, why do you say this?: " generally better than a 32 bit Linux can run 32 bit applications" - wouldn't the mode switch to 32-bit mode made every time there was a task switch to that program slow down the system?

I have tested some 32 bit applications on both 32 bit and 64 bit Linux on the same hardware. There is a slight advantage to 64 bit Linux. I don't know enough internal details to know why. I don't know how the switch to kernel mode with/without the switch of address size compares. I don't know whether that is a tiny disadvantage to a 64 bit OS (as you might expect) that is balanced by some factor I know even less about. Subtle differences can be hard to understand or quantify.

I have tested some 32 bit applications on both 32 bit and 64 bit Windows XP. The difference is more significant. On systems with 2 GB to 3.X GB of ram, XP 32 gets very stupid about the way file caching works because of bad design combined with limited kernel virtual address space. XP 64 has the same "bad" design, but that design does no harm as long as kernel virtual address space is a significant multiple larger than physical memory. 32 bit applications that depend on the kernel to do file caching well run much better on XP64 than on XP32. (Obviously on systems with over 3.X GB of ram, XP 32 is license limited to not use the extra ram, so its file caching gets a LOT worse).


I don't know whether 32 bit Linux does a good job with file caching on systems with large ram. Doing so would be harder due to limited kernel virtual address space. But I don't know Linux internals well enough to know whether 32 bit Linux does large ram file caching well despite the difficulties, or whether file caching is better in Linux64 than in Linux32.

Also, 32 bit Linux with up to 896MB of ram keeps all physical ram mapped into the kernel, so it can directly work on I/O operations in support of processes other than the one whose virtual address space is currently mapped. But 32 bit Linux with over 896MB of ram must do extra mapping every time it needs to access buffers for any process that might not by currently mapped.

I'm pretty sure 64 bit Linux has simplified back to the design that 32 bit Linux could only use with under 896MB of ram. That simpler design would be practical in 64 bit Linux all the way up to around 100000GB of physical ram. So it may save a bunch of remapping operations and related TLB misses.