A Primer on Hardware Sizing for Oracle E-Business Suite

[Aug. 22, 2011: Updated benchmark whitepaper link]

[Editor: This article from Nick Quarmby presents an introductory-level survey of of the general areas that you should consider when sizing an E-Business Suite environment.  Please remember that this blog's mandate is to provide conceptual guidance; we cannot assist directly with specific sizing inquiries for your requirements.  If you have specific questions about sizing for your own environment, we strongly recommend that you engage a specialist from your hardware vendor, Oracle Consulting, or both.]

We're often asked in Service Requests (SRs) to advise on the appropriate hardware specification for an Oracle Applications environment. The term most commonly used term for this exercise is 'sizing' and it is the process of working out how much disk space, memory and processing power you will need to run your Oracle Applications environment.  Our Applications Performance group publishes performance benchmarks and sizing-related whitepapers here:

The reality is that sizing an Oracle Applications environment is far too complex a task to carry out through the limited interface of a Service Request (SR). There are a lot of factors to take into consideration. Underestimating the hardware that you need will have performance and budgetary consequences and overestimating the hardware you need wastes valuable resources. Poor performance of a system when it is rolled out will easily undermine confidence in a project. The functionality of the software may be perfectly good but if it is delivered on inappropriately sized hardware it may take time to fix and the integrity of the whole project may be called into question.

db_console_screenshot.png
This article will not conclude by telling you exactly how to size your hardware and the reasons for that will become apparent, but what I hope it will do is help you, as an Applications DBA, understand what factors you might need to consider when you are required to specify hardware for your Oracle Applications environment.

Remember, sizing hardware is not just about making sure the system you plan to implement shortly will run. You need to take into account future expansion. You might be lucky and just have an instinctive feel for the right size hardware for the job. Alternatively, you might currently have an Oracle Applications environment on hardware that you know intimately and therefore you also know that if you simply upgrade to the latest model then that's going to serve your purpose. Easy. Wouldn't it be nice if all decisions were so straightforward?

Sizing for the rest of us is not such a simple process and has to take into account many factors. With that in mind, I'd like to go into a bit more detail of what you need to think about when sizing your hardware.

Choosing your server hardware

Oracle Applications Support will cannot tell you what hardware or operating system to use. You should already have a very good idea what hardware supplier you are going to go with. We will happily advise on certified combinations once you know the platform you plan to use. Remember Oracle Applications is certified on operating systems, not specific models of hardware.  Here's a useful definition of 'platform' within the context of Oracle E-Business Suite.

Number of concurrent E-Business Suite users


Each user that connects to Oracle E-Business Suite will require an amount of memory on the application and database tier. You should consider:
  • The maximum number of users that will need to be logged in concurrently on your system
  • The nature of the work (the transactional mix) these users will be performing
  • Whether they will require access via the Oracle Forms interface or whether they will only access Oracle Applications through the Oracle Applications Framework (Self Service) interface.
Remember, only a proportion of the registered EBS users will be using it concurrently. You may have users accessing the system from different timezones; in this case, usage is distributed throughout a 24 hour period. You probably do not need hardware that can cope with all registered users accessing the system simultaneously but you should also consider times when there may be surges in demand and ensure you size your system accordingly for these busy periods.

Considerations for user load analysis

Look at a typical day for your production environment:
  • When are the periods of peak usage?
  • Is your hardware sized to handle these peaks?
  • Does your system have surges in demand at month end or year end?
  • Is your system overloaded at certain times of the day?
  • If so, can some of the load be moved to quieter periods in the day and therefore maximize the resources you currently have?
Consider using automated stress testing software that can simulate user load on a system and see how your pre-production test environment reacts to different loads.

Forms Users vs Self Service Users

Find out how many users will use the Self Service interface. These users require a small amount of fixed memory on the application tier. Depending on their activity, additional memory is then allocated and de-allocated on an ad hoc basis via the Java Virtual Machine (JVM).

Find out how many users will require the Oracle Forms (classic) interface. These users also require the same small amount of fixed memory as Self Service users but each user also requires a fixed allocation of memory on the application tier for the Oracle Forms service. This fixed memory is required for the duration of their Oracle Forms session, or until their session times out due to inactivity.

All users initially connect to a JVM and correctly sizing JVMs on the application tier is a frequently discussed topic. For more information about performance tuning and JVM optimization, see:
Your users' memory requirements on the database tier are dependent on the nature of the queries they execute. Controlling the nature of these queries should be part of the planning process for your implementation.

Planning for load from Concurrent (Batch) Processing runs


Consider the amount of concurrent processing your system will be required to handle. There may be quiet periods during which you can use the Work Shift functionality of the Concurrent Manager to schedule non-urgent concurrent processing but in a busy 24/7 environment you will always be required to schedule some concurrent processing simultaneously with normal usage. Your system must be sized to take this usage into account.

Scalability and additional server nodes

Load-balancer diagram showing multiple users being rerouted to multiple application server nodes
When a machine's resources are so heavily-used that performance begins to be affected then you must consider additional hardware. Adding more memory, disk, or processing capability to an existing node is one option. Consider the memory and processor limitations of the hardware you plan to purchase and consider what it would take to fully load that environment. Is this sufficient for your anticipated future needs? You may find that instead of upgrading an existing node that you could add an additional machine to share the load.

Adding nodes at the application or database tier and distributing utilisation across nodes using load balancers and/or Oracle Real Application Clusters (RAC) is a common way of creating an easily (and often very cost-effective) scalable environment. Consider a multi-node architecture using low cost hardware when sizing your environment rather than specifying very high specification single node solutions.

Taking future requirements into account


Consider the scalability of the hardware you are implementing and whether it will be expandable to fulfill your future requirements.  Sizing new hardware not only needs to take into account your immediate needs; you also need to consider your future requirements:
  • You may be planning a new system offering a number of Oracle Applications products but your future plans may include implementing additional products at a later date.
  • You may be considering installing additional languages.
  • You may be considering a phased rollout of Oracle Applications across your organisation where the number of users will increase over the implementation period.
  • You may be considering external feeds coming into your system. Are there plans to to implement an external portal to allow your customers to access Oracle Applications?
Homogenous vs heterogenous deployment architectures

It may seem strange to consider mixing platforms within a single E-Business Suite environment, but this is not as unusual as some people think. A common arrangement is to have multiple commodity Linux boxes running the application tier, accessing a database tier that is running on different hardware and operating system.  We run this kind of architecture at Oracle with our own E-Business Suite implementation:

Oracles own global single implementation architecture for the E-Business Suite
It may cost-effective -- and in some cases desirable -- to use one platform at the application tier and another platform at the database tier. We generally do not recommend mixing platforms at the application tier level as this introduces patching complications and also an element of uncertainty when tracing problems.

In a mixed platform environment the database tier should be dedicated to running the database. Concurrent processing should ideally be handled at the application tier level. This again reduces duplication during patching and should also simplify scalability. This strategy makes it comparatively easier to increase the throughput of your system by adding a node at the application tier or adding a RAC node at the database tier.

Monitor usage on an ongoing basis


Several tools allowing you to monitor the usage of resources in your Oracle Applications environment.  Oracle Enterprise Manager can be used to monitor the database. The Applications Management Pack can be used to monitor Oracle E-Business Suite-specific resources.

High Availability (HA) and Disaster Recovery (DR)

If your Oracle Applications environment is critical to your business you will need to consider what happens in the event of any sort of failure.  These are factors that need to be considered at the sizing stage:
  • Can your business afford to lose the system for any amount of time?
  • Can you identify single points of failure?
  • Do you need to design contingency into your system to avoid such failures?
Once you have sized your system to run your production environment you will need to consider whether you might need some sort of standby system running in a separate data centre in the event that you lose your production environment. If you need this standby system to take over and effectively replace your production environment it will need to be correspondingly sized. If you only wish your standby to offer a reduced service then you can downsize it accordingly, but you must still size it correctly.

Considerations for test systems

Your test system will need to be able to run copy of your production environment. Whilst test hardware may not require the raw processing power or memory of your production environment, it will still need to have sufficient disk capacity to accommodate at least one and (possibly more) copies of your production environment. All patches and upgrades should be tested on a full copy of your production environment before you contemplate applying them in production.

Your test platform should always use the same operating system as your production platform. This not only means you are testing as true a copy of production as possible but also allows you to exploit cloning functionality to quickly create and deploy exact copies of Oracle Applications environments for test and development purposes.

Sizing desktop clients


The following Notes suggest minimum specifications for desktop clients to Oracle Applications. These are very modest specifications and are likely to produce correspondingly modest performance. I think it's always a good idea to get end users involved and establish what their expectations regarding performance are. An overspecified client will not hide an under-performing back end application but a poorly specified client can easily undermine a user's willingness to use an application.
For a more detailed discussion about determining your specific desktop client requirements, see:
Conclusions

So, having considered all of the above, who can you talk to in order to get more information about sizing? Your best friend at this time is your hardware supplier and perhaps, a third party consulting organisation (or better still Oracle Consulting) who are helping you to implement your system.

Most of the major hardware manufacturers can help with sizing their hardware for the E-Business Suite.  They can also advise on the latest technologies available in their hardware to exploit virtualisation, scalability, high availability etc.  They will probably ask you to consider some, or all, of the above factors.

Remember there is usually more than one answer to a question. Consider whether you require a hardware or software solution to your particular requirements. Make sure the recommendations you get from your hardware supplier will add value and are compatible with your Oracle Applications implementation. Review software solutions against hardware solutions and decide which provides the best performance, scalabilty and availability for your requirements.

This article does not offer a conclusive approach to sizing as it is always specific to the organisation implementing the system. What I hope it does is help you appreciate that sizing is more complicated than taking a headcount of your users, listing the products you plan to use and running these figures through a simple algorithm. Correct sizing is key to a successful implementation.

Related Articles

Comments:

Hi Steven, thanks for a great article. I wanted to let your readers know that if they need Oracle sizing assistance (for E-Business Suite, and/or any Oracle application and technology) on HP, they can reach out to our team via www.hporacle.com -> Sizing. We will gladly assist end-user customers, the Oracle Sales Force, and our joint Partners, free of charge! Keep up the great blog! Thanks! Keith.

Posted by Keith F - HP on August 25, 2010 at 10:14 AM PDT #

Nice general overview of the areas to consider for sizing Apps, but what us Apps DBAs really need are details on the baseline footprint:

- How much CPU/memory does each JVM consume on the Apps tier (without any users connected)?

- How much CPU/memory does each dedicated TNS connection from the JVMs/CMs consume on the DB tier (without any users connected)?

- How much CPU/memory do we need for the Concurrent Managers, Forms and Web processes, without any users connected?

- How much CPU does the database need (before any users are connected)? Oracle tells us how much memory we need for the SGA (Note 396009.1), but offers no information on CPU.

It would also be very useful if we could see some real-world sizings on different platforms, e.g. 1000 users on IBM, 500 users on HP, etc. The White Papers are not very useful in this regard, since they are conducted in lab conditions.

As a consultant, I'm often asked to offer a quick sizing for a customer, and then to justify this - there is nothing from Oracle that I can use as a reference.

It seems to me that Oracle is holding back this kind of information to force customers to use consulting, but even for a consulting company it's not that easy to get a sizing from the hardware vendor - for example, to get an HP or Sun sizing you have to be an HP or Sun partner.

Posted by JustAnotherAppsDBA on August 25, 2010 at 03:21 PM PDT #

Hi Keith

Thanks for the additional information. It's always helpful when co-suppliers such as yourselves add something here to help our mutual customers.

Regards

Nick

Posted by Nick Quarmby on August 26, 2010 at 05:19 PM PDT #

This is a slightly overdue response to JustAnotherAppsDBA regarding the request for typical sizings for different EBS environments...

The Oracle White Paper at http://www.oracle.com/technetwork/articles/systems-hardware-architecture/oo-soln-ent-bus-suite-170239.pdf offers some sizing guidelines for three different EBS implementations.

Regards

Nick

Posted by Nick Quarmby on October 11, 2010 at 06:31 PM PDT #

I would like to know any documents that will be of help since whitepapers or benchmarks links are not existing.

Thanks in advance

Posted by guest on August 21, 2011 at 08:42 AM PDT #

Hi, Guest,

The benchmarking site moved. The new address is here:

http://www.oracle.com/us/solutions/benchmark/apps-benchmark/index.html

Article updated.

Regards,
Steven

Posted by Steven Chan on August 22, 2011 at 04:49 AM PDT #

Hi Steven,

my company plan to upgrade EBS to a different platform:
source:
-------
Apps = EBS v.11.5.10.2 on HP UX 4 x 2C PA-RISC 1GHz, mem 8GB, disc 62GB
DB = Oracle 9i on HP UX 4 x 2C iTanium 1GHz, mem 8GB, disc 631GB

target:
-------
Apps = EBS v.12.1.3 on RHEL 5, IBM System x3620 M3 2 x 6C Xeon 1GHz, mem 8GB, disc 300GB
DB = 11gR2 on RHEL5, IBM System x3650 M3 2 x 6C Xeon 1GHz, mem 16GB, Disc 1TB

Could you comment on this target spec, whether is doable to do the migrate or not.
since we want to take the history data into new platform, could you advise on the strategy of migrate ? there is an input to migrate the data into the same version in target, and upgrade it on new target server until v.12.1.3 / 11gR2.

Appreciate your advise, and thank you very much.

Regards,
Robert

Posted by guest on September 12, 2011 at 04:01 PM PDT #

Hi Robert

Your new target platform looks to increase the resources available to your migrated and upgraded environment and so looks like it should offer improved performance however we cannot comment on any specifics.

To migrate and upgrade to the new platform you will need to upgrade on source to 11.5.10.2/11gR2. You then migrate the 11gR2 database tier to your new IBM database node so you are running a split configuration (Apps = EBS v.11.5.10.2 on HP UX 4 x 2C PA-RISC 1GHz, mem 8GB, disc 62GB and DB = 11gR2 on RHEL5, IBM System x3650 M3 2 x 6C Xeon 1GHz, mem 16GB, Disc 1TB).

You should investigate the most appropriate method to migrate the database tier. This could require an export/import or you may be able to use transportable tablespace/database functionality.

You then perform the R12 upgrade pre-requisite steps on the split configuration. After this, your application tier on the HP platform is now effectively redundant. You then perform the fresh rapidwiz upgrade installation on the new application tier host(s) before running the main upgrade driver to upgrade the new environment on the IBM platform to 12.1.1. You then upgrade to 12.1.3.

This is a major upgrade/migration. You should ensure your new hardware is in place early in the project in order for you to perform several test migration/upgrades before contemplating the production upgrade and migration.

Regards

Nick

Posted by Nick Quarmby on September 12, 2011 at 08:43 PM PDT #

Hi Robert

We cannot provide accurate sizing estimates as this is dependent on the way the system is used and many other factors. You should discuss E-Business Suite sizing with your hardware supplier. Having said that, you appear to be increasing the specification of your hardware so if you are not significantly changing the products you use and the number of users, your new hardware would appear to be adequately sized to handle the upgraded environment but we do advise you seek more detailed advice.

You must upgrade to a minimum of 10gr2 on source in order to perform an export/import as you are required to use datapump which was only available with 10g or later.

Your source and target platforms are not of the same "endian" format and therefore you cannot use transportable database functionality to migrate your database.

You could use transportable tablespace functionality but this is only valid with 10gR2 so you would need to upgrade to 10gR2 on source, migrate the database and then upgrade again to 11gR2.

I'd therefore suggest that upgrading to 11gR2 on source (see Note 881505.1) then migrating the database using export/import (see Note 557738.1) appears to be your best option.

I believe with sufficient testing (you should perform a minimum of three completely successful test migration/upgrades) you should be able to complete the migration and upgrade within your one week downtime.

Regards

Nick

Posted by Nick Quarmby on September 14, 2011 at 01:08 AM PDT #

Look like the disscussion is going in different direction and this is basically disscussion on Sizing the database and application and hardware .

Posted by Shivaraddi on May 19, 2012 at 07:50 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
19
20
21
24
25
26
27
28
29
30
   
       
Today