Have a Wetpaint account? Sign in
OLAP option - RAC & GRID
The Oracle OLAP option is a great addition to any Oracle database including those running Real Application Clusters (RAC).
Since the OLAP option is inside the database core nothing special needs to be done outside of standard RAC best practices. Such as isolating parallelism (for builds) to specific nodes using parallel instance groups or services, making sure your interconnect is high bandwidth, low latency and that your instances are tuned. Monitoring ADDM, AWR on instances (or as a whole in 11g) is good practice. Keep in mind that RAC is a scale-out solution. Adding nodes will increase the amount of work that can be done so perhaps builds can be faster since you can load more partitions at the same time and that you can scale out how ever many users you intend to connect. Oracle has many customers running OLAP option on RAC and has been an option for customers since Oracle 9i Release 2.
Key parameter considerations (but not requirements):
If OLAP option is added to an OLTP (or other hybrid) environment you may need to have builds occur on a node separate from the OLTP nodes if builds need to occur at peak times. This flexibility is what makes RAC so appealing.
<< STAY TUNED ... MORE CONTENT WILL BE ADDED SOON ... >>
Since the OLAP option is inside the database core nothing special needs to be done outside of standard RAC best practices. Such as isolating parallelism (for builds) to specific nodes using parallel instance groups or services, making sure your interconnect is high bandwidth, low latency and that your instances are tuned. Monitoring ADDM, AWR on instances (or as a whole in 11g) is good practice. Keep in mind that RAC is a scale-out solution. Adding nodes will increase the amount of work that can be done so perhaps builds can be faster since you can load more partitions at the same time and that you can scale out how ever many users you intend to connect. Oracle has many customers running OLAP option on RAC and has been an option for customers since Oracle 9i Release 2.
Key parameter considerations (but not requirements):
- _OLAP_PARALLEL_UPDATE_THRESHOLD and _OLAP_PARALLEL_UPDATE_SMALL_THRESHOLD --> default is 1000 which allows parallelism to occur during the update phase of OLAP option multidimensional datatype builds. When you set these parameters to a value of 2147483647 parallelism is turned off. This should be considered in environments with unpredictable system loads or when you are submitting jobs (specified as parallel in Analytic Workspace Manager) matching the CPUs you wish consume in logically partitioned cubes during refresh or build. When in RAC and your system isn't configured to isolate parallelism or you want to limit the load on the machine turning off update parallelism may be a consideration.
- PGA_AGGREGATE_TARGET --> Just as in standalone databases the OLAP option makes use of this memory for all activities in a DEDICATED server environment related to OLAP multidimensional datatypes. Setting this to a reasonable value (e.g., 35% of available RAM) is good practice. OLAP multidimensional database sessions make use of a special (dynamic) memory whose algorithm is based off of this value.
- SGA_TARGET --> Set this to a reasonable value based on standard data warehouse best practices or your standard configuration. Typically in RAC there is a slight overhead (vs. SMP environments of the same hardware quantity) so adding 5-10% is prudent.
If OLAP option is added to an OLTP (or other hybrid) environment you may need to have builds occur on a node separate from the OLTP nodes if builds need to occur at peak times. This flexibility is what makes RAC so appealing.
<< STAY TUNED ... MORE CONTENT WILL BE ADDED SOON ... >>
olapdba |
Latest page update: made by olapdba
, Mar 21 2008, 12:13 PM EDT
(about this update
About This Update
Edited by olapdba
view changes - complete history) |
|
Keyword tags:
None
More Info: links to this page
|
There are no threads for this page.
Be the first to start a new thread.
