RAC is not a requirement for in-memory PX

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.

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 291 other followers