The following suggested best practices are applicable to all Oracle BI EE deployments on Sun hardware (CMT and M-class) running Solaris 10 or later. These recommendations are based on our observations from the
28,000 user benchmark on Sun SPARC Enterprise T5440. It is not the complete list, and your mileage may vary.
On larger systems with more CPUs or CPU cores, try not to deploy Oracle BI EE in the global zone.
If the BI catalog is hosted on a local file system, create a ZFS file system to store the catalog.
If there are more than 25,000 authorized users in a BI deployment, the default UFS file system may run into Too many links
error when the Presentation Server tries to create more than 32,767 sub-directories (refer to LINK_MAX on Solaris)
Ensure that all the BI components in the cluster are configured in a many-to-many fashion
For proper load balancing, configure all BI nodes to be almost identical in the BI Cluster
When planning to add an identically configured new node to the BI Cluster, simply clone an existing well-configured BI node running in a non-global zone.
Cloning a BI node running in a dedicated zone results in an exact copy of the BI node being cloned. This approach is simple, less error prone and eliminates the need to configure the newly added node from scratch.
Increase the file descriptors limit. Edit SAROOTDIR/setup/systunesrv.sh to increase the value from 1024 to any other value of your choice. In addition you must increase the shell limit using the ulimit -n
command
Configure 256M large pages for the JVM heap of Chart server and OC4J web server (this recommendation is equally applicable to other web servers such as WebLogic or Sun Java system Web Server). Also use parallel GC, and restrict the number of parallel GC threads to 1/8th of the number of virtual CPUs.
eg.,
-XX:LargePageSizeInBytes=256M -XX:+UseParallelGC -XX:ParallelGCThreads=8
The Oracle BI Presentation Server keeps the access information of all the users in the Web Catalog. When there are large number of unique BI users, it can take a significant amount of time to look up a user if all the users reside in one single directory. To avoid this, hash the user directories. It can be achieved by having the following entry in SADATADIR/web/config/instanceconfig.xml
eg.,
<Catalog>
<HashUserHomeDirectories>2</HashUserHomeDirectories>
</Catalog>
HashUserHomeDirectories
specifies the number of characters to use to hash user names into sub directories. When this element is turned on, for example, the default name for user Steve's home directory would become /users/st/steve.
BI Server and BI Presentation Server processes create many temporary files while rendering reports and dashboards for a user. This can result in significant I/O activity on the system. The I/O waits can be minimized by pointing the temporary directories to a memory resident file system such as /tmp on Solaris OS. To achieve this, add the following line to the instanceconfig.xml configuration file.
eg.,
<TempDir>/tmp/OracleBISAW</TempDir>
Similarly the Temporary directory (SATEMPDIR) can be pointed to a memory resident file system such as /tmp to minimize the I/O waits.
Related Blog Posts:
(Originally posted on blogs.sun.com at:
http://blogs.sun.com/mandalika/entry/oracle_business_intelligence_on_sun)
________________
Technorati Tags:
Oracle | BI | Business Intelligence | Solaris | Performance