A Primer on Hardware Sizing for Oracle E-Business Suite
By Nick Quarmby on Aug 24, 2010
[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:
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.
Considerations for user load analysis
Look at a typical day for your production environment:
- When are the periods of peak usage?
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?
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:
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
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
- 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
- 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?
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:
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?
you identify single points of failure?
- Do you need to design
contingency into your system to avoid such failures?
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.
- Oracle Applications Release Notes, Release 11i (18.104.22.168)
- Oracle Applications Release Notes, Release 12.0.4
- Oracle Applications Release Notes, Release 12.1.1
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.
- Oracle E-Business Suite Platform Smörgåsbord
- Case Study Redux: Oracle's Own Oracle E-Business Suite Release 12 Upgrade (OpenWorld 2008 Recap)
- Analyzing Memory vs Performance of Apps 11i and 12 Clients
- In-Depth: Load-Balancing E-Business Suite Environments
- Using RAC and ASM with E-Business Suite Databases
- Three Options for Scaling Up E-Business Suite for Reporting