Documente Academic
Documente Profesional
Documente Cultură
August 2013
Introduction ..................................................................................................................... 3
Oracle BI EE Components .............................................................................................. 4
Oracle BI EE Server Environment ................................................................................... 4
BI Sizing Assumptions .............................................................................................. 4
1) Small Size Oracle BI EE implementation .............................................................. 6
2) Medium Size Oracle BI EE implementation .......................................................... 6
3) Large Size Oracle BI EE implementation ............................................................. 8
Network Requirements ................................................................................................ 9
Clustering, Load Balancing, and Fail over in Oracle Business Intelligence ..................... 9
Backup and Disaster Recovery .................................................................................. 10
Logical Partitioning, Virtualization & HW resources partitioning ................................. 10
Appendix A: Useful metrics to monitor .......................................................................... 11
Key BI Metrics......................................................................................................... 11
Operating System Server Resources Utilization Statistics ...................................... 11
Network data........................................................................................................... 11
Database Server ..................................................................................................... 12
Web Servers and Application Server ...................................................................... 12
Appendix B: BI Sizing Spreadsheet .............................................................................. 14
11g Sizing Spreadsheet .......................................................................................... 14
Concurrent Users.................................................................................................... 14
Appendix C: Processing a Capacity Plan ...................................................................... 16
Locate and Resolve Over-Utilized Resources ........................................................ 16
Resolve High-Latency Transactions ....................................................................... 16
Address Under-Utilized Resources ......................................................................... 17
Final Analysis.......................................................................................................... 17
REFERENCE:......................................................................................................... 18
Physical hardware
Database Performance
Network
Database and BI model
BI system configuration
Application Server Performance
Deployment architecture and topology
The performance test that BI sizing is based upon tries to represent a customer scenario where the user
population is divided between administrative users and business users. The typical workload scenarios
demonstrate 95% of business users viewing reports and navigating within dashboards. The remaining 5%
of the concurrent users are categorized as administrative users or users performing application
development. The mix of reports include varying business user roles utilizing a mix of dashboards, charts,
tables, drill-downs, and pivot tables that return a number of rows (anywhere from 5-500) of aggregated
data. Administrative users include users performing concurrent application development and ad-hoc
reporting; i.e. navigating catalogs, creating new reports, modifying existing reports, and saving reports.
Sizing will take into consideration the user population, concurrent users, users using formatted reports,
and Scorecard.
The primary purpose of this paper is to present the OBIEE 11g Sizing Spreadsheet from pre-installation
capacity planning perspective. This paper will introduce topics that impacts performance with pointers to
the BI documentation where more detailed information is available. Finally, the paper will provide
architectural examples of small, medium, and large BI systems for the purpose of demonstrating how a BI
System could be deployed.
Oracle BI EE Components
The Oracle Business Intelligence components consist of:
Oracle Business Intelligence Presentation Services
o Ad-hoc query and reporting, highly interactive dashboards for accessing business
intelligence and applications
Oracle Business Intelligence Server
o Common enterprise business model and abstraction layer
Oracle Business Intelligence Publisher
o Oracle Business Intelligence Publisher generates highly-formatted, pixel-perfect
enterprise reports
Oracle Business Intelligence Javahost
o The Oracle Business Intelligence Javahost provides services to BI Presentation Services
for Charts, Gauges and PDFs.
Fusion Middleware Control
o Fusion Middleware Control is the browser-based management tool used to manage,
monitoring, and configure Oracle Business Intelligence components
This section contains BI Sizing assumptions to consider when using data based on the BI Sizing
Spreadsheet. See Appendix B The Small, Medium, and Large Architectures are also based on this
information.
The users that place a load the OBIEE system are those who are actually performing processing. These
users are termed concurrent users. The number of concurrent users is based on the total named user
population and determining a percentage of concurrent users:
This is the complete user population that will be utilizing the targeted hardware
Concurrent users
This is the maximum percent of users in the total user population that will be active at any
one time
We do not calculate active users or users logged into the system not actively demanding
system resources.
Formatting of reports has overhead on the system verse executing HTML based reports only (i.e.
Dashboards)
In the case of single core chips, the recommendation is to deploy a minimum of 2 CPU's given
the contention of all the OBI EE processes. For modern multi-core chips one CPU can be
recommend, however, 1CPU should NOT be recommended for single-core chips
Note: Multi-Core CPUs are replacing single and dual core CPUs in Server applications
making the availability of those processors rare in newer Servers.
The hardware assumptions are based on capacity of the Oracle BI EE components only and NOT
the database. Recommended sizing for Essbase can be found in Chapter 4 of the following
documentation:
http://download.oracle.com/docs/cd/E17236_01/epm.1112/epm_install_start_here_11121.pdf
Upgrading the hardware of the Oracle BI EE environment will not necessarily make queries run
faster. Good query performance generally assumes good DB design and/or aggregation
strategies.
Scaling scenarios are performed against a chipset verses the operating system environment. As
an example for an Intel P4 we size similarly for both Windows and Linux. This sizing data
represents Windows and Linux.
User concurrency varies over the lifecycle of the deployment and is impacted by many factors. As a BI
environment becomes more mature the system can grow from being low named users with a high
percentage of concurrent users to higher named users and lower concurrency yet demanding more
hardware capacity. Initial sizing helps in determining what is required and how to process demand over
time.
To determine the BI capacity requirements, collect the following information:
The number of BI users you expect to have, and when you expect them to use OBIEE.
Assess the complexity of the processing that users will demand of BI and the design of
the architecture and infrastructure.
Capacity planning is an ongoing process. After deploying and implementing OBIEE the systems needs to
be monitored to ensure the performance expectations are met.
It is worth noting that sizing guidelines for the small, medium, and large implementation are for OBIEE components only
and not for typical implementation which could include BI Applications or other Oracle technology.
The estimated hardware for a small sized Oracle Business Intelligence Suite Enterprise Edition
implementation can be utilized for a wide range of concurrent users. For a typical implementation the
estimated HW specifications required to support 100-200 total and 10-20 concurrent users could
technically meet the needs required to support < 3000 total users at 10% concurrency resulting in < 300
concurrent users. A small sized system can be characterized as:
x86 CPU 2-4 Cores with the recommended 2GB of RAM per Core
< 1200 Concurrent Users
Due to the scalability and performant nature of OBIEE a medium sized implementation covers a wide
range and overlaps with the small sized system and large sized systems in regards to the kind of
hardware that can be used to accomplish the business need.
While the HW specifications for a typical medium sized OBIEE implementation can support 1000-5000
total and 100-500 concurrent users, hardware sizing for medium sized implementations are characterized
as systems between 1200 and 5000 concurrent users:
x86 CPU 4-16 Cores with the recommended 2GB of RAM per Core
1200 5000 Concurrent Users
BI Suites Components
Example HW System Specs Description
A large number of concurrent users can be deployed on the typical large sized Oracle BI EE system. The
estimated HW for a large sized Oracle Business Intelligence Suite Enterprise Edition that is capable of
supporting 50,000 or more total and 5000 or more concurrent users are as follows:
x86 CPU 16+ Cores with the recommended 2GB of RAM per Core
5000+ Concurrent Users
BI Suites Components
Example HW System Specs Description
Firewall
Intranet
Load Balancer
Clustered WLS
OBIPS
OBIS
Clustered WLS
OBIPS
OBIS
OBIPS
OBIS
OBIPS
OBIS
NAS
NAS
Firewall
Network Requirements
It is recommended to deploy the BI servers on a dedicated subnet using > 100 MBPS (1Gbit if possible)
to reduce latency between each server.
HTTP Response
Size
(Kbytes)
11g
HTTP Response
Size with
Compression
(KB)
Compression
ratio
(%)
297.5
39
86
210
28.5
86
938
79
91
Pages
Dashboard with 3
Tables and 3 Charts
For the compression mentioned above the compression/decompression occurs between the client
browser and HTTP server (usually Oracle HTTP Server (based on Apache 2.2)). The compression is
performed by Apache 2.2 which has a compression module. Compression has minimal impact on the
CPU of the HTTP server.
http://download.oracle.com/docs/cd/E21764_01/bi.1111/e10541/cluster.htm#BGBHFCJF
Enterprise Deployment Guide for Oracle BI
http://download.oracle.com/docs/cd/E21764_01/doc.1111/e15722/toc.htm
Load Balancing HTTP Server
http://download.oracle.com/docs/cd/E15523_01/core.1111/e12036/install.htm#CBHDDEFJ
10
o
o
o
o
o
o
o
o
o
o
o
o
o
o
o
% Privileged Time
The percentage of time the operating system was busy
CPU data
% Processor Time
The percentage of time the processor was busy
Available memory in Bytes
The amount of free space in memory
Memory data
Page Faults per sec
The number of page fault per sec.
(Page faults are normal system occurrences that used to retrieve data
from the disk. If the system needs certain code page and it is in memory,
a logical I/O occurs. The data is read from the memory the transaction
that needs data is processed. If the code page or data page is not in the
memory, the system performs a physical I/O to read the needed page
from the disk. This is accomplished through page faulting.)
Pages/sec
The number of actual pages being moved from disk to memory or back to disk.
Only data
pages are written back to disk when they are modified Code pages do not get
modified
Network data
o
o
o
o
o
11
The total number of bytes sent and received by this system per second,
averaged over time interval. It comprises of the sum of Bytes Received/sec and
Bytes Sent/sec
Database Server
Web Servers
o Request Throughput
throughput requests per second and response times in seconds per request
o Current Connections
The number of current connections to the Web server
o Connection Attempts/sec
shows the number of attempts to connect the Web server
o Anonymous Users
count of users that established a connection with the Web Server since service
started
o Total Accesses
information on the total number of hits on the Apache HTTP Server
o Total Traffic
information about the total bytes sent and received by the Apache HTTP Server
o CPU Load
information about the total CPU time consumed by the Apache HTTP Server
http://download.oracle.com/docs/cd/E17904_01/core.1111/e10108/http.htm
Application Servers
o % Processor Time
The percentage of processor time
o Elapsed Time
The time, in seconds, that the process instance has been running
o I/O Data Operations
The number of read and write operations generated by the process instance
12
Request Throughput
throughput requests per second and response times in seconds per request
o Server Response Time
Average response times and request rates
http://download.oracle.com/docs/cd/E12840_01/wls/docs103/perform/
13
The 11g Sizing Spreadsheet as described in the BI Sizing Assumptions section of this paper.
Figure 4
Concurrent Users
The following table is based on the spreadsheet in figure 4. It is based on the minimal requirements. The
total named users is set, SSL is not selected, Scorecard analysis is not considered, and user concurrency
is determined to be 10%. The result is the Estimated CPU/CORE required.
14
15
In the capacity planning processing over capacity or under utilization can occur when determining the
sizing between small to medium and medium to large configurations. In all scenarios the Oracle expert
services team is recommended to provide in depth analysis. During the process some hardware
resources can be recognized as over-utilized. Resource over utilization causes performance issues by
placing unnecessary burdens on the OS to manage resources which in the end impacts the BI Application
performance. In this case it is important to determine the over-utilized resources and address how the
problems can be resolved. Some factors include:
With the monitoring of OBIEE via FMW Control, OS management tools, and other management tools,
some changes that might be considered include the following:
A trial and error process may be required to correct over utilization and repeating the process above until
utilization is optimal.
Resolve High-Latency Transactions
During the capacity planning process, system use, design and model design is usually an underappreciated aspect of the planning. When planning, it is worthy to note transactions with high latency to
be able to determine the order in which these problems will be addressed. Factors that influence the
priority of a particular latency issue might include the following:
How will users be impacted by high cost transactions and set plans to alleviate impact
Resolution of high-latency transactions is a costly portion of capacity planning. Items that can impact
latency include the following for potential changes:
Inquire about network bandwidth and the impact it may have on reducing transaction time
Another key in capacity planning is preparing for the potential of resources that can be identified as
under-utilized. The objective is to prepare for what could be deemed as excess resources that may or
may not impact utilization or transaction latencies.
In many deployments and capacity planning exercises the prospect of under-utilized resources is not the
primary determining factor in the planning. Some items are crucial and impactful when considering the
small to medium to large implementation without negative impact to the enterprise architecture some of
those areas include:
Security
Stability
Recognize the fine line between a small, medium, and large configurations
To reduce and prevent under-utilized resources the direct path is to reduce the hardware sizing. In this
case it would be difficult to determine if the overall performance would be impacted beyond an acceptable
level.
Final Analysis
Whether dealing with a workload based on simple queries with a small dataset to complex queries with
enormous datasets, optimal results that start with results obtained from the OBIEE Performance,
Scalability and Reliability (PSR) team and ends with Professional Services can provide a scenario where
capacity planning helps with the following:
Maximize availability
Optimize utilization
17
18
REFERENCE:
http://www.specbench.org/
http://oreilly.com/catalog/9780596518585
http://httpd.apache.org/docs/2.2/mod/mod_deflate.html
http://www.spec.org/
http://download.oracle.com/docs/cd/E14571_01/bi.htm
https://support.us.oracle.com/oip/faces/secure/km/DocumentDisplay.jspx?id=1333049.1 (Support note
OBIEE 11g Infrastructure Performance Tuning Guide Doc ID 1333049.1)
https://blogs.oracle.com/pa/resource/Oracle_OBIEE_Tuning_Guide_v1.pdf
http://www.rittmanmead.com/2013/03/performance-and-obiee-introduction
Copyright 2012, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only and the
Capacity Planning
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
December 2012
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability
or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual
obligations are formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any
form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license
and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark licensed through
Worldwide Inquiries:
X/Open
Phone: +1.650.506.7000
Fax: +1.650.506.7200
oracle.com
19
20