Parallel Query/Execution

Guys,
What is parallel quering/execution? How does it help to improve the performance.
Thanks

Hi,
Parallel query is an Oracle feature designed to solve large-scale data warehouse reporting and DML I/O performance issues. It is easy to implement
PARALLEL_AUTOMATIC_TUNING=TRUE, include PARALLEL option on table DDL definition and it is in place.
This feature improves performance when used on a multi-cpu platform, with PARTITIONED tables (i.e... typcially FACT, or transaction records, where rowcount is approaching or greater than 100million). Oracle distributes the SQL workload against each table partition to an individual CPU. Rather than 1 CPU scanning a table, many CPUs are used to scan different table partitions of the same table at the same time (i.e. in parallel).

Similar Messages

  • Data Driven Subscriptions Error - the query processor could not start the necessary thread resources for parallel query execution

    Hi,
    We are getting the following error when certain data driven subscriptions are fired off: "the query processor could not start the necessary thread resources for parallel query execution".  I've read other posts that have the same error, and
    the solution usually involves adjusting MaxDOP to limit the number of queries that are fired off in parallel.  
    Unfortunately, we cannot change this setting on our server for performance reasons (outside of data driven subscriptions, it negatively impacts our ETL processing times).  We tried putting query hints like "OPTION (MAXDOP 2);" in the reports
    that are causing the error, but it did not resolve the problem.
    Are there any settings within Reporting Services that can be adjusted to limit the number of subscriptions that get fired off in parallel?
    Any help is appreciated - thanks!

    Yes, that is correct.  It's a painful problem, because you don't know which specific subscription failed. For example, we have a data driven subscription that sends out about 800 emails. Lately, we've been having a handful of them fail. You don't know
    which ones out of the 800 failed though, even from the RS log files - all it tells you is that "the
    query processor could not start the necessary thread resources for parallel query execution".
    Thanks, I'll try changing <MaxQueueThreads> and will let you know if it works.
    On a side note: I've noticed that it is only reports with cascading parameters (ex. where parameter 2 is dependent on the selection from parameter 1) that get this error message...

  • Partitioning For Optimal Parallel Query Execution

    Hi All,
    We are trying to design an architecture that benefits from partitioning and parallel query to obtain the best query response times for our system.
    Let me start by describing the main table which has five columns:
    Columns:
    1) DocId ------- Numeric Primary Key Constraint (Unique)
    2) Text ------- CLOB of XML Content
    3) SCode ------- Varchar 12 ( service code Can be one of 200 values)
    4) A_Date ------- Oracle Date ( The arrival date )
    5) A_Month ------- Numeric partition key, the month number (1-12)
    We insert 100,000 records daily so a month of data will contain 3,000,000 rows. The Text varies from 4k to 200k bytes and on average is around 30k bytes per document. A_Date is obtained when the C++ application receives a client connection. After document transmission is complete the DocId is obtained from an Oracle sequence. It is true that A_Date and DocId increase together. However because of varying document sizes and transmission rates, there is no guarantee that consistent order between the two columns exists.
    For Example: If time (t) increases and the connection times are: t1, t2, t3, t4 and the document at t2 took long to transmit, we can have:
    A_Date -------- DocId (From Oracle Sequence)
    t2 -------------- 1004
    t4 -------------- 1003
    t3 -------------- 1002
    t1 -------------- 1001
    A_Month is simply the month number (1-12) extracted from the transmission entry timestamp. It is also our Partition Key (see below). When the year wraps around from 2006 to 2007, data for January will simpy fall into the 1st partition bucket, and so on..
    QUERY NEEDS: Our queries are centered around a DateTime interval Where the left endpoint is current day/time. They can query the current day, current to 1 month back, current to 2 months back, .. current to 15 months back. We MUST RETURN a list of DocId's sorted in DESCENDING ORDER for screen display purposes.
    In General we need to return sub-second for the 1st month. As we query further back in time longer response times between 1 and 4 seconds are acceptable.
    PARTITIONING AND INDEXES:
    The table is partitioned by A_Month as shown below:
    Create Table IndexTable
    PARTITION BY RANGE (A_Month)
    ( PARTITION p1 VALUES LESS THAN 1.1 ...
    PARTITION p2 VALUES LESS THAN 2.1 ...
    PARTITION p3 vALUES LESS THAN 3.1 ...
    There are GLOBAL INDEXES on DocId, Text(Domain Index), and SCode.
    A_Date is a LOCAL INDEX.
    QUERY STRUCTURE:
    My Query structure looks like this (for a 2 month query):
    SELECT DocId from IndexTable WHERE
    Contains (Text, 'BUSH and EARNINGS') > 0 AND
    SCode in ('S1', 'S2', 'S3', 'S4') AND
    A_Date Between '2006-01-15 11:00:00' AND '2006-03-15 11:00:00'
    Order By DocId DESC;
    QUESTIONS (THERE ARE THREE)
    #### QUESTION 1 ####
    As I examine various explain plans, the PSTART and PSTOP do not reflect consistency with my A_Date range. It seems to always display:
    PStart PStop
    RowId RowId
    no matter what my A_Date range is.. I don't see it pruning my partitions. I cannot find documentation as to what RowId means or how it affects the optimizer's plan.
    #### QUESTION 2 ####
    I have tried parallelization hints on the table and indexes such as
    /*+ PARALLEL( IndexTable, 4) */ and on the A_Date index
    /*+ PARALLEL_INDEX( IndexTable, A_Date_Index, 4) */.
    I can't really tell if the parallel hints make a difference.
    However, the FIRST_ROWS hint makes a big difference if I nest the query inside a rownum clause as:
    SELECT * from
    ( Select /+* first_rows */ ... WHERE CONTAINS... > 0 AND... )
    Where ROWNUM <=20;
    #### QUESTION 3 ####
    I'm running close to the latest RedHat Linux and Oracle 10g2 and I have read about Parallel Slave Processes in Tom Kyte's Expert Oracle Architecture book in which he says you should see processes like:
    ora...p000..
    ora...p001..
    ora...pnnn..
    Which are the parallel slave processes. I have NEVER seen any oracle processes numbered as such running on my system when I run test queries. I have seen some q_ processes and others, but not the pnnn processes..
    Can I benefit from parallel query without ever seeing these processes??
    I Greatly Appreciate Any Advice To Any Of These Questions..
    Joe

    Well I can tell you this much. You will never get partition pruning if you don't have the partition key in the where clause.
    I'm not sure about the parallel query. There was a time that this wasn't supported with Text indexes, but not sure if that still applies today.
    In theory there are two levels of partitioning that can be defined that you may want to test out.
    1st, range partition the base table and create a partitioned text index based on that. This is what you are currently doing.
    2nd, in the storage preference for the $I table specify a range or hash partition (I've never tried this, but in theory it should work) on the token_text column. Try this out and see if it works.

  • Parallel query execution on Multiprovider with noncumulative KF

    Hello !
    We built a multiprovider (MP) on three not overlapping (disjunct?) basis cubes, which are all stock cubes, partitioned by 0PLANT and copies of 0IC_C03.
    The Multiprovider-explain of TX RSRT says:
    "The MultiProvider query is executed sequentially (reason: NCUM)".
    Ok so far, maybe its not possible to execute queries in parallel on that multiprovider even if desirable.
    But I found note 781921 which says as symptom:
    "If a MultiProvider query with non-cumulative key figures is processed in a parallel way, the system terminates due to a type conflict". That means that queries CAN be executed in parallel on MPs with noncumulative key figures.
    Does anybody know if that type of queries can run in parallel or not ??
    Any advice is appreciated.
    Kind regards, Philipp

    Note 717451 solves this.

  • 9i Query Execution (Parallel vs Serial)

    I have a table (test) containing 1000000 (10 lac) records.
    1) I issued the Query with parallel option "SELECT /*+ parallel (test,4) */count(*) FROM test". The query will use 4 parallel servers to execute.
    2) After this i executed the Query without parallel option "SELECT /*+ parallel count(*) FROM test".
    The execution time of both the queries is same. Why the parallel option is not executing the query will shorter time as compared to serial execution?
    Thanks in Advance,
    Shafiq

    Hi,
    To optimize parrallel query, the number of CPUs is very important. How have you CPU ? If not least 4 CPUs, it's not very recommend.
    Have you make explain plan ?
    explain plan for ....
    and
    @$ORACLE_HOME/rdbms/admin/utlxplp (for parallel query)
    @$ORACLE_HOME/rdbms/admin/utlxpls (for serial quey)
    Is your table partionned ?
    Please post explain.
    Btw, I don't think that for a count(*) parallel query improve performance...
    Nicolas.

  • Problem with temp space allocation in parallel query

    Hello
    I've got a query which matches two large result sets (25m+ rows) against each other and does some basic filtering and aggregation. When I run this query in serial it takes about 30 mins and completes successfully. When I specify a parallel degree of 4 for each result set, it also completes successfully in about 20 minutes. However, when I specify that it should be run in parallel but don't specify a degree for each result set, it spawns 10 parallel servers and after a couple of minutes, bombs out from one of the parallel servers with:
    ORA-12801: error signaled in parallel query server P000
    ORA-01652: unable to extend temp segment by 64 in tablespace TEMPThis appears to be when it is about to perform a large hash join. The execution plan does not change whether the parallel degree is specified or not, and there is several GB of temp space available.
    I'm at a bit of a loss as to how to track down specifically what is causing this problem. I've looked at v$sesstat for all of the sessions involved and it hasn't really turned anything up. I've tried tracing the main session and that hasn't really turned up much either. From what I can tell, one of the sessions seems to try to allocate massive amounts of temp space that it just does not need, but I can figure out why.
    Any ideas of how to approach finding the cause of the problem?
    David

    Hello
    I've finally resolved this and the resolution was relatively simple - and was also the main thing that Mark Rittman said he did in his article: reduce the size of the hash join.
    After querying v$sql_workarea_active I could see what was happening which was that the sum of the temp space for all of the parallel slaves was exceeding the total amount of temp space available on the system. When run in serial, it was virtually at the limit. I guess the extra was just the overhead for each slave maintaining it's own hash table.
    I also made the mistake of misreading the exectuion plan - assuming that the data being pushed to the hash join was filtered to eliminate the data that was not of interest. Upon reflection, this was a rather stupid assumption on my part. Anyway, I used sub query factoring with the materialize hint to ensure that the hash join was only working on the data it should have been. This significantly reduced the size of the hash table and therefore the amount of temp space required.
    I did speak to oracle support and they suggested using pga_aggregate_target rather than the separate *area_size parameters.  I found that this had very little impact as the problem was related to the volume of data rather than whether it was being processed in memory or not.  That said, I did try upping the hash_area_size for the session with some initial success, but ultimately it didn't prove to be scalable.  We are however now using pga_aggregate_target in prod.
    So that's that. Problem sorted. And as the title of Mark Rittman's article suggests, I was trying to be too clever! :-)
    HTH
    David

  • Oracle 10g and parallel query question

    Hi Oracle on SAP Gurus!
    We are currently thinking of activating parallel query for certain segments (large application tables and indexes). We searched in SAPNet and SDN and have also studied the SAP Note 651060. But we did not find a complete answer to the following question which is very important for us:
    Which kinds of queries (despite from full table scan and index scan in partitioned indexes) support parallel queries and which ones do not support parallel queries?
    This is important for us to find out whether we have candidates for parallel queries or not.
    Thanx for any hint!
    Regards,
    Volker

    But why do you not propose to use parallel query in OLTP systems?
    If the queries are accessed very frequently you will just run out of cpu and io ressources. OLTP systems are (historical) typically multi user systems. You can off course use PQ for 'single user' activities, like index rebuilds, some batchjobs, but you shouldn't do for frequent user queries.
    If you have time look at this interesting Article [Suck It Dry - Tuning Parallel Execution|http://doug.burns.tripod.com/px.html]
    It is quite old, and you don't have to read all tech details, but i recommend having a look at the conclusions at the end.
    May it make sense to use partitioning of these tables in conjunction with parallel query?
    I know some guys, who do partitioning on OLTP systems, even SAP systems. But they don't use PQ then. The use partitioning to work on a smaller set of data. In your case the range scans, would need to scan only one partition, saving buffer cache and effectively speeding up execution. So you don't need PQ to scan all partitions at all, this would be a typical OLAP approach.
    Best regards
    Michael

  • Parallel  query in Oracle 11g

    We use Oracle 11g DB on windows2008R2.
    We wrote very long and heavy SELECT SQL query usign several table join and sub-queries and it take very long time to get result.
    We did SQL statement tuning as much as we can do so far. ( I will get the Execution Plan and ADDM, etc access right)
    I today notice about Parallel query function.
    Where could I write parallel hint phrases in very long SELECT SQL query ?
    In each selected tables like below ?
    /sample in Oracle Doc/
    SELECT /*+ PARALLEL(employees 4) PARALLEL(departments 4)
           USE_HASH(employees) ORDERED */ MAX(salary), AVG(salary)
    FROM employees, departments
    WHERE employees.department_id = departments.department_id
    GROUP BY employees.department_id;

    You need to be careful with some of the examples in the docs. The example you quote includes an unnecessary join. Before considering parallel query, it should have been re-written to this:
    SELECT MAX(salary), AVG(salary)
    FROM employees
    WHERE department_id is not null
    GROUP BYdepartment_id;
    Later versions of the CBO may do this re-write for you, but it is important to understand why the SQL is inefficient before throwing parallel servers at it. Are you sure that all your joins are actually necessary? (I know you are just going to say "yes", but you might want to think about it first.)

  • Parallel Query Error - 1008 Not All Variables Bound

    Using DB 10g Enterprise Edition Release 10.2.0.1.0
    I am trying to query a table in SQL plus using a bind variable. When I run the query the first time it fails but if I run it again, it works! See the following :
    SQL> var b1 number;
    SQL> exec :b1 := 133348;
    PL/SQL procedure successfully completed.
    SQL> set autot on exp stat
    SQL> select 2 from pension_details where party_id = :b1;
    select 2 from pension_details where party_id = :b1
    ERROR at line 1:
    ORA-12801: error signaled in parallel query server P001
    ORA-01008: not all variables bound
    SQL> /
    2
    2
    Execution Plan
    0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=11)
    1 0 INDEX (RANGE SCAN) OF 'PENDTL_PK' (INDEX (UNIQUE)) (Cost=2
    Card=1 Bytes=11)
    If I add a hint suppressing the parallel index option, then it works first time :
    1* select /*+NOPARALLEL_INDEX (PENSION_DETAILS) */ 4 from pension_details where party_id = :b1
    SQL> /
    4
    4
    Execution Plan
    0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=11)
    1 0 INDEX (RANGE SCAN) OF 'PENDTL_PK' (INDEX (UNIQUE)) (Cost=2
    Card=1 Bytes=11)
    Can anyone shed any light on why this happens or what I need to check on the table and index? I have tried to replicate this on a different table (and a different db) with the parallel option on both the table and index but it works fine!

    Seeing as there have been no replies, I thought I would update my own thread!
    It turns out this is a bug that has been fixed in 11i. The fix has been back-ported to certain versions/os's.
    I will post the bug reference (it is on Metalink somewhere!) later. In the meantime, a workaround is to use the noparrallel_index hint.

  • VC 7.0 - Performance during query execution

    Hi Experts,
    we have built an VC cockpit wich includes ~35 Querys.
    When the user opens the cockpit the VC modell starts all 35 querys.
    When we start the querys in the SAP BI System (RSRT) they all need less than 1 sek each.
    Our BI system is able to handel 40 querys simultaneous.
    Our problem is that the cockpit need ~40 sec. until all querys have been finished.
    We suppose, that the VC starts all querys seriell instead of parallel.
    Is there any configuration where i can switch between parallel and serial mode?
    Thanks for your help
    Regards
    Florian

    Hello,
    Using the dedicated connection for nested iViews feature, was good thinking.
    But - since the execution time of your queries is relatively short compared to the overall time for the "running a query" process, i.e. the HTTP request for execution,  creating the connection on portal side, executing the query, returning the result and displaying it on the Flex runtime. --
    all the other factors in this equations takes more time (relatively) than the query execution itself. (~1 seconds).
    That is the reason why you don't observe major changes between running your 40 queries on a single connection or on multiple connections.
    This feature was intended for queries that run for a long period of time. (tens of seconds or minutes)
    in such queries, you will see the difference.
    Mark,
    Visual Composer 7.0 development and maintenance team.

  • ORA-12827 insufficient parallel query slaves available

    Hi,
    In our sql statements , we are using PARALLEL_MIN_PERCENT = 100 for getting 100% parallel slaves.
    But sometimes,it fails with ORA-12827.
    if we remove PARALLEL_MIN_PERCENT = 100 , then obviously the query execution time will increase.
    How to make sure that the query always get 100% parallel query slaves?
    Is there any work around for this other than removing or changing PARALLEL_MIN_PERCENT?
    Thanks

    Increase parallel_min_servers. What happens is as follows. At instance startup oracle starts parallel_min_servers processes to handle PQO (Parallel Query Option). Assume, for example parallel_min_servers = 4. Assume table has degree of parallelism 6. When you set PARALLEL_MIN_PERCENT = 100 you are requesting PQO to start 6 slave processes while only 4 are available.
    SY.

  • Avoid Unnecessary Parallel Query

    I am using Oracle 10.2.0.3 RAC on 2 x Sun Solaris box with 32 CPUs. In general I wish to allow parallel execution, so parallel_server is set to TRUE.
    Our database is running, amongst other things, the Oracle Internet Directory schema. The application using this was experiencing a poor response time to a number of its queries. A quick investigation identified that a high percentage of time was spent on waits for events related to parallel execution.
    I ran a "select count(*)..." against one of the commonly used tables (ODS.CT_DN) to establish what volume of data was being queried, which took ~1s to count ~1,500 rows. This table has some indexes on it which have parallel enabled, and a trace of the query showed that parallel query was being used.
    If I disable parallel execution on the indexes in question, and re-run the query, as expected it completes far quicker (~10ms). It seems therefore that with parallel enabled on the indexes, with such a low number of rows, the query is spending most of its time spawning and coordinating slave processes.
    The table and all the indexes have statistics gathered (by GATHER_STATS_JOB ), so my question is, why doesn't the optimizer reach the same conclusion as me, that based on the low number of rows in the table it would be far quicker to execute the query in serial rather than in parallel?
    The table in question, and others experiencing a similar problem, belong to Oracle Internet Directory, hence I would prefer not to resolve the problem using schema changes, i.e. disabling parallel execution on the schema objects. Furthermore, though the tables may have few rows now, in the future they may reach a point where it makes sense to execute these queries in parallel, so I guess I would like the optimizer to do its job and adjust the plan accordingly as the statistics change.
    Any ideas?
    Thanks,
    Simon.

    comments embedded
    I am using Oracle 10.2.0.3 RAC on 2 x Sun Solaris box
    with 32 CPUs. In general I wish to allow parallel
    execution, so parallel_server is set to TRUE.
    That is an unwise decision. Apart from that the parallel_server parameter doesn't have anything to do with parallel execution. In fact, the default is TRUE in a RAC configuration.
    Parallel execution only makes sense when you've striped your tables against multiple drives. If you didn't do that, all your queries slaves will hit the same drive and cause an I/O bottleneck.
    Our database is running, amongst other things, the
    Oracle Internet Directory schema. The application
    using this was experiencing a poor response time to a
    number of its queries. A quick investigation
    identified that a high percentage of time was spent
    on waits for events related to parallel execution.
    As was to be expected.
    I ran a "select count(*)..." against one of the
    commonly used tables (ODS.CT_DN) to establish what
    volume of data was being queried, which took ~1s to
    count ~1,500 rows. This table has some indexes on it
    which have parallel enabled, and a trace of the query
    showed that parallel query was being used.
    If I disable parallel execution on the indexes in
    question, and re-run the query, as expected it
    completes far quicker (~10ms). It seems therefore
    that with parallel enabled on the indexes, with such
    a low number of rows, the query is spending most of
    its time spawning and coordinating slave processes.
    The table and all the indexes have statistics
    gathered (by GATHER_STATS_JOB ), so my question is,
    why doesn't the optimizer reach the same conclusion
    as me, that based on the low number of rows in the
    table it would be far quicker to execute the query in
    serial rather than in parallel?This is because the optimizer divides the cost of the access by the number of query slaves involved. The optimizer doesn't know the query slaves are going to hit one disk.
    >
    The table in question, and others experiencing a
    similar problem, belong to Oracle Internet Directory,
    hence I would prefer not to resolve the problem using
    schema changes, i.e. disabling parallel execution on
    the schema objects. Furthermore, though the tables
    may have few rows now, in the future they may reach a
    point where it makes sense to execute these queries
    in parallel, so I guess I would like the optimizer to
    do its job and adjust the plan accordingly as the
    statistics change.
    Any ideas?You should disable parallel execution.
    As Tom Kyte puts it 'Paralllel query is for queries which are essentially unscalable'. The queries in Oracle Internet Directory do not belong to that category.
    Please note it also makes little sense to post this, using various aliases, to all Oracle groups you can spell.
    Sybrand Bakker
    Senior Oracle DBA
    >
    Thanks,
    Simon.

  • Asynchronous query execution?

    Experts,
    I am trying to figure out if there is a way to configure BO so that it executes SQL queries via the Universe in a parallel fashion as opposed to sequential.
    We have a Xcelsius dashboard which runs off of 4 different QaaWS services, and hence makes 4 calls to the Oracle DB. What we are seeing is that these 4 queries are being fired one after the other, as opposed to concurrently. Is it possible to make this happen asynchronously so that the data fetch takes much less time?
    This could be the case for any Univ-based query (WebI, DeskI etc) and not just Xcelsius.
    Thanks,
    Sarang

    Hi,
    We are developing a complex reporting application and
    have the following high-level requirements for the
    app/DB layer.
    1.Asynchronous DB Query execution - User will place
    the report in a queue and view it later on.Spin off your own threads or use JMS.
    2. Synchronous DB Query execution - User will wait to
    see the reportPretty much standard for any JDBC driver.
    3. Transaction Management - Should support commit,
    rollback.Pretty much standard for any JDBC driver
    4. Multithreaded - The query has to be executed using
    multithreading.Apples and Oranges. Your J2EE container will provide multi-threading. All modern databases support servicing multiple connections. No work for you to do here either.
    5. Queuing - The DB queries will be placed in a queue
    for execution.Again, not your concern.
    6. Priority of execution - The application should be
    able to set priorities for DB query execution so that
    queries which returns small resutlsets should be
    executed first when compared to large result sets.Some drivers may support this. If not, create two connection pools. One will service high-availability connections and the other normal availability connections.
    7. Connection Pooling and Thread pooling.
    Connection pooling is widely available. Jakarta's DBCP is a good, stable, free pool implementation. Why do you need thread pooling?
    For the above set of reqs, is it best to use any of
    the tools or write our own custom logic. Need your
    help to design this app.
    Regards,
    venkat- Saish

  • Parallel Query Restirction

    Hi there,
    i was wondering if there is any option to restrict the parallel execution of queries for user, so if a specific user exceutes select /*+ parallel*/ from table
    i want the query to be executed as noparallel??
    thank you in advance.
    My Oracle Version is:
    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
    PL/SQL Release 11.1.0.7.0 - Production
    "CORE     11.1.0.7.0     Production"
    TNS for Linux: Version 11.1.0.7.0 - Production
    NLSRTL Version 11.1.0.7.0 - Production

    1) You can put suspicious users in certain Resource Consumer Groups and limit the Parallel Degree of that group to 1 (no parallelism).
    2) If the parallel query is obviously not appropriate, you may also implement Automatic DOP to prevent senseless parallelism.
    See here for an example for 2):
    http://uhesse.wordpress.com/2009/11/24/automatic-dop-in-11gr2/
    Kind regards
    Uwe Hesse
    http://uhesse.wordpress.com
    Edited by: Uwe Hesse on 13.07.2011 20:22
    corrected -> certain

  • Need Parallel Querying

    Hi Friends,
    What you get from the following info?
    Will I be able to use parallel query effectively in my datawarehousing database.
    Oracle DB version Enterprise Edition 10g 10.2.0.3.0 64 bit
    SQL> show parameter parallel
    NAME                                 TYPE        VALUE
    fast_start_parallel_rollback         string      LOW
    parallel_adaptive_multi_user         boolean     TRUE
    parallel_automatic_tuning            boolean     FALSE
    parallel_execution_message_size      integer     2152
    parallel_instance_group              string
    parallel_max_servers                 integer     160
    parallel_min_percent                 integer     0
    parallel_min_servers                 integer     0
    parallel_server                      boolean     FALSE
    parallel_server_instances            integer     1
    parallel_threads_per_cpu             integer     2
    recovery_parallelism                 integer     0
    SQL> select name,value from v$sysstat where name like 'Parallel%';
    NAME                                                                  VALUE
    Parallel operations not downgraded                                   461273
    Parallel operations downgraded to serial                              91484
    Parallel operations downgraded 75 to 99 pct                              33
    Parallel operations downgraded 50 to 75 pct                              10
    Parallel operations downgraded 25 to 50 pct                            1474
    Parallel operations downgraded 1 to 25 pct                                9
    6 rows selected.
    SQL>Thanks.
    Edited by: user523372 on Jun 18, 2010 7:43 AM

    What was unclear in 'multipe disks'?
    If all of those parallel query slaves are going to hit 1 single disk, you will get an IO bottleneck.
    And performance problems are typically NOT resolved by enabling parallel execution.
    It is not unlikely it will make things worse.
    I was afraid you are a fan of silver bullets. It appears indeed you are.
    Sybrand Bakker
    Senior Oracle DBA

Maybe you are looking for