Wednesday, June 6, 2012

E-Business Suite and the 32-bit vs. 64-bit question


Before I get flamed on this, I want to make clear that, for the purpose of this posting, I'm speaking specifically about operating systems (not hardware). Most of the hardware being sold today is already 64-bit, however, you can run most 32-bit operating systems on 64-bit hardware. It's that distinction that I'm discussing here.

The first thing that you need to know here is that the big benefit of using a 64-bit operating system really is memory. In particular, it is not about the total amount of memory that can be installed in the machine (that tends to be hardware), but, about the addressable size of "per process" memory.

In the case of components such as those used on an appsTier in EBS, per-process addressable memory doesn't matter so much, as each process has it's own private memory (and isn't depending on "shared memory" like the database server is). So, aside from the fact that it makes our life much easier from an administrative standpoint (and the industry is going that way), there really isn't much of technical advantage to a 64-bit appsTier.
For EBS 11i (where the DB is certified on x86-64, but the appsTier is only certified on x86-32), you can still use much more than 4GB on an appsTier node (the operating system has a way of addressing large memory). It's just that the amount of memory that can be addressed by a single process is limited to something between 3 and 4 GB.

In the case of EBS R12, the appsTier binaries are still 32-bit, even when you're running on a 64-bit operating system. This makes sense because the only component that can really take advantage of it is the database (because the database processes all attach to the same large chunk of memory [the SGA]).

Note that EBS R12 appsTier is certified on both Linux x86-32 and Linux x86-64.

So, for 11i, the best that they can hope for is to have a separate dbTier (database only) running on Linux x86-64 and use Linux x86-32 for their appsTier nodes. Remember, that the 11i appsTier is NOT certified on Linux x86-64. That doesn't mean that it can't be done, but I seriously doubt that Oracle has any intention to certify a release that old on, what is effectively, a different platform. In both cases, they can/should be 5.X (5.7 is current). Having, effectively, two different platforms will be something of a headache from a Linux administration standpoint, but it's something that they'll have to deal with.

When they get to R12, they should use Linux x86-64 on all tiers (to simplify administrative tasks, as well as being "among the mainstream" of installations). Keep in mind that 64-bit is where "the market" is going. Even though you can (It is certified) do R12 on x86-32, you're better positioned if you're on x86-64.

James

18 comments:

  1. hi James,

    My company is planning to migrate 32-bit EBS 11i dbTier (9.2.0.3) to new server (64-bit RHEL AS 4.x) when retain appTier 11.5.9 in old server (7 years old).

    Will there be any performance issue since there are old (4Gb RAM for 32-bit appsTier) vs new hardware (16Gb RAM for 64-bit dbTier)?

    tks,
    Darrell

    ReplyDelete
  2. Assuming that you're otherwise "apples to apples", 64-bit shouldn't have any NEGATIVE performance impact. That said, it shouldn't really have any positive one either. Now, what this does do for you is open up some opportunities for performance improvement. You can now address more RAM (larger SGA, more users) and, if you're looking at new hardware, you'll probably end up with faster processors. Also, if the new hardware will support it, I highly recommend "loading up" on RAM. It's a relatively inexpensive part of the system price and does NOT impact Oracle's licensing model. Plus, I've never complained that a system had too much memory.

    Also, I'd strongly consider moving to a newer version of RHEL and upgrading the database to 11gR2 if you can. RHEL 6.x is now certified with 11gR2. I'm not certain if 11.5.9 is, however. But, for that matter, if you're on 11.5.9, you're below the "minimum baseline" described in 883202.1. So, it may work well for you to combine all of these into one project and reduce the overall testing effort.

    -- James

    ReplyDelete
  3. Hi James,

    Thank for the reply. Does Oracle still support if we migrate 32-bit dbTier 9.2.0.3 to 64-bit dbTier 9.2.0.3?

    ReplyDelete
  4. This is off the top of my head, so please double check. If you're ultimately planning to upgrade to a higher version (10g or 11g), then you should be patching your 9i to 9.2.0.8. 9.2.0.8 IS CERTIFIED on Linux RHEL4 x86-64. (MOS doesn't seem to indicate which platforms 9.2.0.3 is certified on... quite possibly because it's way past end-of-life). So, you should be OK once you upgrade to at least 9.2.0.8. Follow 209766.1 and 550042.1 for the migration. Once you've done that, you should be clear for an upgrade to 10g or 11gR2 (recommended).

    -- James

    ReplyDelete
  5. Our local supplier was suggesting us to migrate both 32-bit appsTier 11.9.5 & dbTier 9.2.0.3 to 32-bit RHEL / OEL 4. They said Oracle will not continue to support us if we migrate our dbTier to 64-bit.
    Due to some constraint, my company has no plan to upgrade either apps or database to newer version.

    ReplyDelete
  6. If you want a definitive answer, don't rely on your vendor, log a SR with Oracle Support detailing your current platform/versions and your intended target platform/versions.

    That said, the 9i database IS certified on RHEL 4 64-bit, although E-Business Suite 11i is NOT. What that means is that none of the EBS appsTier components (the "applmgr" stuff) can run on a 64-bit Linux. There is a certified configuration called "split configuration dbTier" where the database can be 64-bit and the appsTier is 32-bit. That is where you want to go.

    Oracle WILL support you if you migrate your database from 32-bit Linux to 64-bit Linux following the MOS notes that I mentioned above. Your only real concern here is that you're dealing with VERY OLD versions (and Oracle might insist that you deal with newer versions in order to be fully supported).

    RDBMS 9.2.0.3 is a VERY OLD version of the database. Similarly, RHEL 4 is also VERY OLD. If you are moving to new hardware, I would highly recommend going to a newer version of RHEL (RHEL 6 is certified with EBS 11i). I would also highly recommend upgrading your database to AT LEAST 9.2.0.8 (the terminal release for 9i) and, preferably, to 11.2.0.3.

    From a support standpoint, you really need to be at the minimums specified in 883202.1. (RDBMS 10.2.0.4, EBS 11.5.10.2 + ATG_PF.H.RUP6 + minimum patches).

    -- James

    ReplyDelete
  7. This comment has been removed by the author.

    ReplyDelete
  8. hi James,

    Even RHEL 6 is certified with EBS 11i (appsTier 11.5.9)? Talking about 32-bit database, your article mentioned '...It's just that the amount of memory that can be addressed by a single process is limited to something between 3 and 4 GB.'

    With dual cpu Xeon 2.30Ghz,15Mb cache,32Gb RAM, will it help to overcome the limitation 32-bit linux OS when running oracle (especially database)? What do you mean by 'single process'?

    Your explanations are very much appreciated.

    ReplyDelete
  9. Actually, upon looking, it appears that 11.5.9 is only certified against RHEL 4. And 11.5.10.2 is certified against RHEL 4 and RHEL 5. (You can find this information under the "Certify" tab on MOS).

    As to the 32-bit database (vs. the 64-bit database). There are some "tricks" you can use to get more usable RAM on a 32-bit Linux box. One is to use the "HugeMem" kernel. That will allow the operating system to use up to 64GB of RAM.

    But here's the deal. A single 32-bit process can only address ("attach to") about 4GB of RAM. So, when it comes to your dbTier, what you have is a whole bunch of processes attaching to your SGA. Which is, therefore, limited to 4GB.

    On the appsTier, 32-bit + HugeMem will also allow you to see up to 64GB on the operating system. But, since the appsTier processes each attach to their own memory, you can actually make more use of the 64GB in your system. This is because each Linux process is only using less than 4GB of RAM (so, for example, 20 processes, each with their own 1GB of RAM will consume 20GB and handle it just fine on 32 Bit Linux.)

    On the dbTier, if you stay with 32-bit Linux, you will get *some* advantage by having 32GB of RAM (if you use the HugeMem kernel). But, your SGA will still be limited to ~4GB in size. (Due to the per-process memory limitation).

    A single process would be what you see when you do "ps -ef" at the Linux prompt.

    -- James

    ReplyDelete
  10. hi James,

    The following link describes the SGA can be increased to about 62GB (depending on block size) on a 32-bit system with 64GB RAM.

    http://docs.oracle.com/cd/B28359_01/server.111/b32009/appi_vlm.htm

    ReplyDelete
  11. Hello james,

    i have linux 64 bit installed on my virtual box and i have R12.1.1(32 bit). would it be possible to install R12 on the configuration i have ?

    ReplyDelete
  12. Hello James,

    When you mentioned EBS R12, the appsTier binaries are still 32-bit, is it only $APPL_TOP or entire apps tier? Are 10.1.2 and 10.1.3 homes 32 bit too?

    ReplyDelete
    Replies
    1. On most platforms (I think that AIX is the one outlier), ALL major components of the appsTier are 32-bit, even if you're on a 64-bit platform.

      This is fine, because the database is really the only place where large per-process memory is really important.

      Delete
  13. Hi James:

    We are using Oracle Applications 12.0.6 on RHEL Linux 4.7 32 bit and planning to migrate on Oracle Linux 5.7.

    Can you please guide us, if this is good to move from RHEL to Oracle Linux or we should stick with RHEL 5.7? Appreciate, if you can share any document that can help us in this decision.

    Thanks
    MIM

    ReplyDelete
  14. The differences between RHEL and OEL are pretty subtle. From a user standpoint (even a Unix Admin standpoint), they're basically the same thing. The commands are the same and the package management system is the same. There are a few cosmetic differences (you will see an "oracle" logo in places...)

    OEL does add a few nice bits. There is an "oracle-validated" package (rpm) that can provide a one-stop install for most of the prerequisite packages (it also handles some kernel settings and user/group creation).

    Also, there is the "Unbreakable Enterprise Kernel" (UEK), which is Oracle's particular take on the OS kernel. (I'm not sure if you can run UEK on RHEL).

    You also add the "one-stop-shop" for support (and blame, since there is nobody else to point fingers at!).

    ReplyDelete
  15. Hi James,
    Currently we are using 12.0.6 application with 10.2.0.2.0 database with RHEL 4.4 (32-bit) on server IBM X3500 and we are planning to upgrade database from 10.2.0.2 to 11.2.0.2 and migrate it on OEL-6.5 (64-bit) on Oracle Sun Server X5-2 from RHEL 4.4 (32-bit). Is that possible to migrate 12.0.6 application as it is on 64-bit linux. Please provide doc id .
    Thanks

    ReplyDelete
  16. First of all, from the standpoint of certifications (particularly Linux certifications), the hardware vendor doesn't matter.

    That said, 12.0.6 Is certified on RHEL/OEL 4 and 5. It isn't certified on RHEL/OEL 6.

    Best you can hope for without upgrading from EBS 12.0.6 to a newer EBS release is to get EBS to RHEL5/OEL5 (x86 and x86-64 appear to be supported for the appsTiers). (MOS 416305.1).

    As far as the database is concerned, EBS 12.0.6 is certified with RDBMS 12.1.0.2.0 and 12.1.0.1.0 as well as with 11gR2 If you're planning on sticking with 11gR2, do 11.2.0.4 instead of 11.2.0.2. (At least get you on the terminal release).

    All that said, ALL support for 12.0.6 has lapsed (Extended support expired 31-Jan-2015) and for 11gR2 is in "Extended Suport" already (as of 31-Jan-2015).

    So, you really should be planning for/working on upgrading both. AT THE VERY LEAST, get the database up to 11.2.0.4

    HOWEVER, what you've described isn't *really* a platform migration. You're going from 32-bit x86 Linux to 64-bit x86 Linux.

    From the appsTier standpoint, make sure that the TARGET meets all of the prerequisites for E-Business Suite on 64-bit Linux and clone it over. You may have to apply some interoperability patches on the appsTier side. (See 416305.1).

    From the dbTier standpoint, you'll need a new $ORACLE_HOME, you'll need to migrate the database (and convert it from 32-bit to 64-bit), and you'll need to autoconfig enable that new ORACLE_HOME.

    Here are the specific MOS notes you need to review (these should at least get you started):

    Migrating Oracle E-Business Suite R12 from Linux 32-bit to Linux 64-bit (Doc ID 471566.1)
    Master Note For Oracle Database Upgrades and Migrations (Doc ID 1152016.1)
    How to Convert a 32-bit Database to 64-bit Database on Linux? (Doc ID 341880.1)

    -- James

    ReplyDelete
  17. Thanks James for your quick reply.It will support me in my upgarde and migration activity.

    ReplyDelete