Primary purpose of RAC is to provide continuous availability (NOT HIGH AVAILABILITY) additionally it also provides the potential for faster performance by allowing potentially more CPUs to be employed.
What it means ?
For OLTP :-
In an OLTP application, SQL(s) are usually very efficient, with queries accessing data via a very selective index; most of data blocks are cached at either the Oracle or SAN level and hence application is CPU-LIMITED. With more CPU(s) available in RAC environment OLTP systems will gain more performance.
For Batch Jobs :-
Most batch jobs tend to select large chunks of data and generally heavy on disk i/o, or I/O LIMITED. Hence, it is trickier to analyse and more trickier to benefit from RAC using more number of threads (different from parallelism, which is different thing.)
Understanding potential performance road blocks :-
Queries Of Objects Spanning Nodes May Degrade A Little :-
Here’s why: Every time a session accesses an Oracle block, RAC must ensure that the session is provided the correct version of the block—which may actually reside on a different node. When this occurs, there is a slight, but not negligible delay, as the block is transferred via the cache fusion technology. Additionally, if the sending node has modified the block, but not yet written the transaction to the redo log, there is a further delay whilst the redo block is written.
Undo Considerations :-
When RAC nodes are variously updating, inserting, or querying the same data block it adds complication. Any node doing a query of these active blocks must undo the uncommitted changes—wherever they originated from, local or remote. Thus, the requesting node must request, wait for, combine, and apply undo changes from multiple nodes. Shipping of undo blocks can thus potentially add significant delays.
Full Table Scans Issue :-
Delays due to full table scans can be exacerbated in RAC. When a block is not found cached in the local node, Oracle first attempts to find the block in a remote node (before resorting to a disk read.) Potentially, these extra calls lead to longer delays.
Important :- If you plan to use RAC database as source for GOLDEN GATE replication purpose please note that XA and DISTRIBUTED transactions are not
supported.
What it means ?
For OLTP :-
In an OLTP application, SQL(s) are usually very efficient, with queries accessing data via a very selective index; most of data blocks are cached at either the Oracle or SAN level and hence application is CPU-LIMITED. With more CPU(s) available in RAC environment OLTP systems will gain more performance.
For Batch Jobs :-
Most batch jobs tend to select large chunks of data and generally heavy on disk i/o, or I/O LIMITED. Hence, it is trickier to analyse and more trickier to benefit from RAC using more number of threads (different from parallelism, which is different thing.)
Understanding potential performance road blocks :-
Queries Of Objects Spanning Nodes May Degrade A Little :-
Here’s why: Every time a session accesses an Oracle block, RAC must ensure that the session is provided the correct version of the block—which may actually reside on a different node. When this occurs, there is a slight, but not negligible delay, as the block is transferred via the cache fusion technology. Additionally, if the sending node has modified the block, but not yet written the transaction to the redo log, there is a further delay whilst the redo block is written.
Undo Considerations :-
When RAC nodes are variously updating, inserting, or querying the same data block it adds complication. Any node doing a query of these active blocks must undo the uncommitted changes—wherever they originated from, local or remote. Thus, the requesting node must request, wait for, combine, and apply undo changes from multiple nodes. Shipping of undo blocks can thus potentially add significant delays.
Full Table Scans Issue :-
Delays due to full table scans can be exacerbated in RAC. When a block is not found cached in the local node, Oracle first attempts to find the block in a remote node (before resorting to a disk read.) Potentially, these extra calls lead to longer delays.
Important :- If you plan to use RAC database as source for GOLDEN GATE replication purpose please note that XA and DISTRIBUTED transactions are not
supported.
No comments:
Post a Comment