We do have another database oriented site – http://www.dbsnaps.com, but as we’re now concentrating with building the Israeli one, it wasn’t updated much since the beginning of the year (It has many database HOW-TOs clips).

Anyway, thanks again,
You have now a new follower for you site
Roni.

Google’s Translate site also makes it possible to read the page with a left justified text, although code sections are problematic.

Cheers,
Roni.

Thank you for the comment.

My blog only sends out shortened blog articles in the RSS feed. I searched WordPress and found the following article that shows how to subscribe to an RSS feed for a WordPress blog:
http://en.support.wordpress.com/feeds/

Based on the above article, it appears that there are several variations of RSS feeds for WordPress blogs. The main RSS feed for this blog appears to be:
http://hoopercharles.wordpress.com/feed/

You might also take a look at the OakTable Network site, where my blog articles are listed, along with the blog articles of other (much more knowledgeable) OakTable Network members:
http://www.oaktable.net/

And the RSS feed for the OakTable Network site:
http://www.oaktable.net/feed/blog-rss.xml

Cheers
Roni.

PS – I didn’t find anywhere a link for general RSS for your blog, only for the specific posts’ comments.
Can you please send me the rss feed?
I don’t like notifications by mails.

Thank you for adding value to this blog article with your answers. Just as was the case with Fidelinho’s answers, your answers were a little different from what I had in mind when I wrote the questions – but that is an improvement, I think. Your answers included information that I had hoped that someone would include in their responses. Article #1 attempted to answer questions #1 through #4 – I think , while questions 5 and 6 require much more investigation to answer.

The answers that I put together continue:
#4 The * at the end of the question links to the documentation for Oracle Database 11.2.0.1 that describes the PARALLEL_DEGREE_POLICY parameter: “When the parameter PARALLEL_DEGREE_POLICY is set to AUTO, Oracle Database decides if an object that is accessed using parallel execution would benefit from being cached in the SGA (buffer cache)… If the size of the object is larger than the size of the buffer cache (single instance) or the size of the buffer cache multiplied by the number of active instances in an Oracle RAC cluster, then it is read using direct path reads.” So, as of 11.2.0.1 parallel query is able to automatically take advantage of the buffer cache – therefore this question is false.

Donatello mentioned that a checkpoint (object check point?) is performed to write the dirty blocks to disk before the parallel operation is able to start, and therefore parallel query does not completely avoid the buffer cache. This is not something that I planned to include in my answer, but I am happy that someone mentioned this behavior.

—

#5 I initially planned to cheat on the answer to this question. _SERIAL_DIRECT_READ is a hidden parameter, and should NOT be modified without the consent of Oracle support. So, the answer is FALSE, this parameter should not be modified. (The excellent answers provided by the other responders demonstrate why I should not be answering all of the questions ).

#6 To an extent the _SMALL_TABLE_THRESHOLD parameter value controls whether or not recent releases of Oracle Database perform direct path reads when the _SERIAL_DIRECT_READ parameter is set to TRUE. The linked blog article that was written by Dion Cho indicates that the tipping point is reached when the number of block exceeds 5 times the value of _SMALL_TABLE_THRESHOLD. I would probably need to perform first-hand tests to confirm that this is always the tipping point in 11.1.0.6, 11.1.0.7, and 11.2.0.1. So, this is the one and only question that I could answer with TRUE, although Donatello makes a good point that the answer could also be false.

1. Direct path read waits will only appear when parallel query is used,
for example, a full table scan executed in parallel.

False, direct reads can be performed with a serial table scan

2. Parallel query is enabled at the session and instance level
by setting a table’s parallel degree to 32.

False. I had too the same question, why 32? just use
hint / * + PARALLEL (table-name integer) * /

3. Setting a parallel degree for a table or index forces the cost-based optimizer to calculate the cost of a full scan of the table (or index) with a lower value than the cost of the corresponding index’s range scan access path.

False. Even for me is false, I’m fully agree with your assertion
“False, setting the degree of parallel will decrease the calculated cost of the full table scan, but will not necessarily decrease the calculated cost so that it is lower than the calculated cost for an index range access path. ”

SQL> create table t1 as select rownum as id , 'x' as c from dual connect by level  commit;

SQL> create index ix on t1(id);

SQL> exec DBMS_STATS.GATHER_TABLE_STATS (ownname => user, tabname => 'T1');

SQL> set autotrace traceonly;
 
SQL> select /*+ index(t1 ix) */ count(*) from t1 where id between 5000 and 70000;

---------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    13 |    82   (2)|
|   1 |  SORT AGGREGATE   |      |     1 |    13 |            |
|   2 |   INDEX RANGE SCAN| IX   | 82653 |  1049K|    82   (2)|
---------------------------------------------------------------

SQL> select /*+ parallel(t1 4) */ count(*) from t1 where id between 5000  and 70000;

---------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)|
---------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |     1 |    13 |    82   (2)|
|   1 |  SORT AGGREGATE   |      |     1 |    13 |            |
|   2 |   INDEX RANGE SCAN| IX   | 82653 |  1049K|    82   (2)|
---------------------------------------------------------------

forcing parallels the CBO doesn’t consider to use it. The cost by using index is less. In fact, if I make the index unusable …

SQL> alter index ix unusable;

SQL> select /*+ parallel(t1 4) */ count(*) from t1 where id between 5000  and 70000;

----------------------------------------------------------------------------------------------------
| Id  | Operation              | Name     | Rows  | Bytes | Cost (%CPU)|    TQ  |IN-OUT| PQ Distrib |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |          |     1 |    13 |    84   (8)|        |      |            |
|   1 |  SORT AGGREGATE        |          |     1 |    13 |            |        |      |            |
|   2 |   PX COORDINATOR       |          |       |       |            |        |      |            |
|   3 |    PX SEND QC (RANDOM) | :TQ10000 |     1 |    13 |            |  Q1,00 | P->S | QC (RAND)  |
|   4 |     SORT AGGREGATE     |          |     1 |    13 |            |  Q1,00 | PCWP |            |
|   5 |      PX BLOCK ITERATOR |          | 82653 |  1049K|    84   (8)|  Q1,00 | PCWC |            |
|   6 |       TABLE ACCESS FULL| T1       | 82653 |  1049K|    84   (8)|  Q1,00 | PCWP |            |
----------------------------------------------------------------------------------------------------

…the cost achieved by the parallel is greater than that obtained using the index

4. Physical block reads performed during parallel query operations are always brought directly into the program global area (PGA), completely avoiding the buffer cache.

False. “completely avoiding the buffer cache”..hmmm, teorically, the blocks are taken and brought to the PGA, but if some of these blocks are dirty and are therefore in the buffer cache, Oracle will perform a checkpoint (so will be downloaded to disk) and retrieve the blocks from disk

5. The hidden parameter _SERIAL_DIRECT_READ should be set to FALSE to prevent problems caused by excessive direct path reads.

False (in some cases). In 10g _SERIAL_DIRECT_READ setting to FALSE causes Oracle to not perform direct reads (even if the number of blocks requested exceeds the threshold defined on the hidden parameter _small_table_threshold).
In 11g, with _serial_direct_read = FALSE and if the number of blocks exceeds 5 times the value of _small_table_threshold the direct reads are applied
You can see the test case that I have done the following link

http://antognini.ch/2009/07/impact-of-direct-reads-on-delayed-block-cleanouts/#comment-6068

6. The hidden parameter _SMALL_TABLE_THRESHOLD affects Oracle’s decision to perform direct path reads.

True or False depends by versions .My interpretation is always at the following link

http://antognini.ch/2009/07/impact-of-direct-reads-on-delayed-block-cleanouts/#comment-6068

Regards

I like Fidelinho’s suggestion that a hint is also able to cause a parallel execution – something that I did not consider while writing the question.

#3 False, setting the degree of parallel will decrease the calculated cost of the full table scan, but will not necessarily decrease the calculated cost so that it is lower than the calculated cost for an index range access path.

For question #1 the keyword “waits” is critical in the phrasing of the question (for non-native English readers, this distinction may have been lost in translation). If the word “waits” did not appear, then this question becomes one of when are direct path reads used. Most of the possibilities are listed in the linked article #6, a book with a copyright date of 2004 if I recall correctly, and I believe that Fidelinho covered this possibility also. Oracle 11g R1, introduced in August 2007 based on the dates I listed in this blog article, enabled the capability for non-parallel (serial) operations to perform direct path reads, and these direct path reads appear as direct path waits in 10046 trace files. Articles #3, #4 and #5 above describe this behavior, and article #2 shows that the feature may be enabled in Oracle 10g by modifying a hidden initialization parameter.

Once again, the keyword “waits” is key for answering this question as it was originally intended. Prior to Oracle Database 10g R1 direct path reads that accessed the TEMP tablespace were lumped into the same ‘direct path read’ wait event that appears when parallel query operations were used. With Oracle Database 10g R1 reads of the TEMP tablespace appear as ‘direct path read temp’ waits in a 10046 trace file. With Oracle Database 11g R1 direct path read waits may appear automatically during a full table scan without the use of parallel query.

Correctly answering question #1 therefore requires either the specification of a specific Oracle Database release (11.1.0.6, 10.2.0.4, 9.2.0.8, etc.) or a specific “as of” date. Article #1 has a date that falls between the release of Oracle Database 11.1.0.7 and 11.2.0.1. Question #1 is a restatement of an assertion that appears in article #1. The short answer for question #1 is False.

I encourage readers to provide their answers to the above questions. Even if the answers are not 100% what I had in mind, the answers might provide additional detail that allows the message of the blog article to expand into additional, new directions as happened with Fidelinho’s justification for question #1. The hope is that blog articles like this one cause people to stop, think, and understand (even if my answers are not completely correct due to translation problems or a mistake that I might have made).