As pointed out by Greg Rahn in the comments to Mark Rittman’s blog post, new Oracle 11gR2 feature called In-Memory Parallel Execution work well in a single-instance environment.
Before reading the post I didn’t fully understand key point of this feature: I thought it is applicable to a single PX statement irrespective of the current database usage pattern. And because usually PX statements are written & executed in a way that require access to the needed data once per execution, I was a little bit concerned on the feature profits. One case where this isn’t true is Parallel DML (PDML):
------------------------------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib | ------------------------------------------------------------------------------------------------------------------ | 0 | UPDATE STATEMENT | | | | 100 (100)| | | | | | 1 | PX COORDINATOR | | | | | | | | | | 2 | PX SEND QC (RANDOM) | :TQ10001 | 1000K| 4882K| 100 (2)| 00:00:02 | Q1,01 | P->S | QC (RAND) | | 3 | INDEX MAINTENANCE | T1 | | | | | Q1,01 | PCWP | | | 4 | PX RECEIVE | | 1000K| 4882K| 100 (2)| 00:00:02 | Q1,01 | PCWP | | | 5 | PX SEND RANGE | :TQ10000 | 1000K| 4882K| 100 (2)| 00:00:02 | Q1,00 | P->P | RANGE | | 6 | UPDATE | T1 | | | | | Q1,00 | PCWP | | | 7 | PX BLOCK ITERATOR | | 1000K| 4882K| 100 (2)| 00:00:02 | Q1,00 | PCWC | | |* 8 | TABLE ACCESS FULL| T1 | 1000K| 4882K| 100 (2)| 00:00:02 | Q1,00 | PCWP | | ------------------------------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 8 - access(:Z>=:Z AND :Z<=:Z)
The execution plan is for a simple parallel update of a table without indexes (step #3 is always there). Two steps – 8 and 6 – access table T1 concurrently by many PX slaves (of the same PX group; their number is statement DOP – degree of parallelism). Big difference is in the way they work: while #8 will perform direct path reads to process’ address space, #6 will do T1′s UPDATE by rowid. Which means accessing table T1′s data once again, but now using single-block reads to the buffer cache. According to the white paper Oracle 11gR2 won’t consider this issue as a choice for in-memory PX.
This is crucial quotes from a paper:
The decision to use the aggregated buffer cache is based on an advanced set of heuristics that include: the size of an object, the frequency at which the object changes and is accessed, and the size of the aggregated buffer cache.
If a subsequent parallel SQL statement that requires the same data is issued from anywhere in the cluster, the PX servers on the nodes where the data resides will access the data in its buffer cache and return only the result to the node where the statement was issued; no data is moved between nodes via Cache Fusion.
So in-memory PX (iPX? iMPX? can’t decide which one is better) kicks in when you have multiple PX statements, not a single silly PDML.
Words “frequency at which the object changes” looks interesting. As a positive side-effect iPX (I’ve made the choice! 
) eliminates segment-level checkpoint since there’s no need to ensure up-to-date data is present on disk – we’ll use standard buffer cache for that data. Because a decision such as “is it better to iPX or to do a segment-level checkpoint and old-style PX?” is challenging, a question arises: is (will) it be costed by CBO? I guess it will be some time in the future.
PS. The paper didn’t cover how iPX works with Exadata/Oracle Database Machine. I think iPX can work with it, but will require disabled smart-scan – one of the main Exadata advantages.
Posted in Oracle, Performance Tagged: 11gR2, Exadata, iPX, PDML, PX, RAC
