Performance - Parallel Queries

For query performance reason ,I know we can execute query  in sequential and parallel.But i want to increase the number of work processes for the query execution,how to increase that?
thanks

In table RSADMIN, Parameter QUERY_MAX_WP_DIAG .
The maximum value can be changed to a value between 1 and 100 in the QUERY_MAX_WP_DIAG entry in table RSADMIN.
<b>Rationale -</b>
The actual degree to which queries are executed in parallel depends on the load on the system at any given time and lies between 1 (sequential processing) and the maximum value. If the number of sub-queries is greater than the maximum level of parallelism, all existing sub-queries are divided between the work processes determined by the degree of parallelism.
The results of all sub-queries are collected at a synchronization point and collated to form an overall result.
In sequential processing, the sub-queries are processed one after another. The interim result is immediately passed on to the analytic engine.
Hope it Helps
Chetan
@CP..

Similar Messages

  • Warehouse partitioning - performance of queries across multiple partitions?

    Hi,
    We are using Oracle 11.2.0.3 and have a large central fact table with several surrogate ids which have bitmap indexes on them and have fks looking at dimension tables + several measures
    (PRODUCT_ID,
    CUSTOMER_ID,
    DAY_ID,
    TRANS_TYPE_ID,
    REGION_ID,
    QTY
    VALUE)
    We have 2 distinct sets of queries users look to run for most part, ones accessing all transactions for products regradless of the time those transactions happened (i.e. non-financial queries - about 70%,
    queries determining what happened in a particular week - 20% of queries.
    Table will have approx 4bn rows in eventually.
    Considering adding extra column to this DATE and range partition this to allow us to drop old partitions every year - however this data wouldn't be joined to any other table.
    Then considering sub-partitioning by hash of product_id which is surrogate key for product dimension.
    Thoughts on performance?
    Queries by their nature would hit several sub-partitions.
    Thoughts on query performance of queries which access several sub-partitions/partitions versus queries running aganist a single table.
    Any other thoughts on partitioning strategy in our situation much apprecaited.
    Thanks

    >
    Thoughts on query performance of queries which access several sub-partitions/partitions versus queries running aganist a single table.
    >
    Queries that access multiple partitions can improve performance for two use cases: 1) only a subset of the entire table is needed and 2) if the access is done in parallel.
    Even if 9 of 10 partitions are needed that can still be better than scanning a single table containing all of the data. And when there is a logical partitioning key (transaction date) that matches typical query predicate conditions then you can get guaranteed benefits by limiting a query to only 1 (or a small number) partition when an index on a single table might not get used at all.
    Conversely, if all table data is needed (perhaps there is no good partition key) and parallel option is not available then I wouldn't expect any performance benefit for either single table or partitioning.
    You don't mention if you have licensed the parallel option.
    >
    Any other thoughts on partitioning strategy in our situation much apprecaited.
    >
    You provide some confusing information. On the one hand you say that 70% of your queries are
    >
    ones accessing all transactions for products regradless of the time those transactions happened
    >
    But then you add that you are
    >
    Considering adding extra column to this DATE and range partition this to allow us to drop old partitions every year
    >
    How can you drop old partitions every year if 70% of the queries need product data 'regardless of the time those transactions happened'?
    What is the actual 'datetime' requirement'? And what is your definition of 'a particular week'? Does a week cross Month and Year boundaries? Does the requirement include MONTHLY, QUARTERLY or ANNUAL reporting?
    Those 'boundary' requirements (and the online/offline need) are critical inputs to the best partitioning strategy. A MONTHLY partitioning strategy means that for some weeks two partitions are needed. A weekly partitioning strategy means that for some months two partitions are needed. Which queries are run more frequently weekly or monthly?
    Why did you mention sub-partitioning? What benefit do you expect or what problem are you trying to address? And why hash? Hash partitioning guarantees that ALL partitions will be needed for predicate-based queries since Oracle can't prune partitions when it evaluates execution plans.
    The biggest performance benefit of partitioning is when the partition keys used have a high correspondence with the filter predicates used in the queries that you run.
    Contrarily the biggest management benefit of partitioning is when you can use interval partitioning to automate the creation of new partitions (and subpartitions if used) based solely on the data.
    The other big consideration for partitioning, for both performance and management, is the use of global versus local indexes. WIth global indexes (e.g. a global primary key) you can't just drop a partition in isolation; the global primary key needs to be maintained by deleting the corresponding index entries.
    On the other hand if your partition key includes the primary key column(s) then you can use a local index for the primary key. Then partition maintenance (drop, exchange) is very efficient.

  • Regarding parallel queries in ABAP same as in oracle 10g

    Hi,
       Is there any way we can write parallel queries in ABAP, in the same way we do in oracle 10g.Kindly see below;
    alter table emp parallel (degree 4);
    select degree from user_tables where table_name = 'EMP';
    select count(*) from emp;
    alter table emp noparallel;
    SELECT /*+ PARALLEL(emp,4) / COUNT()
    FROM emp;
    The idea here is to distribute the load of select query in multiple CPUs for load balancing & performance improvement.
    Kindly advise.
    Thanks:
    Gaurav

    Hi,
    >    Is there any way we can write parallel queries in ABAP, in the same way we do in oracle 10g.
    sure. Since it is just a hint...
    SELECT *
      FROM t100 INTO TABLE it100
      %_HINTS ORACLE 'PARALLEL(T100,4)'.
    will give you such an execution plan for example:
    SELECT STATEMENT ( Estimated Costs = 651 , Estimated #Rows = 924.308 )
           4 PX COORDINATOR
               3 PX SEND QC (RANDOM) :TQ10000
                 ( Estim. Costs = 651 , Estim. #Rows = 924.308 )
                 Estim. CPU-Costs = 33.377.789 Estim. IO-Costs = 646
                   2 PX BLOCK ITERATOR
                     ( Estim. Costs = 651 , Estim. #Rows = 924.308 )
                     Estim. CPU-Costs = 33.377.789 Estim. IO-Costs = 646
                       1 TABLE ACCESS FULL T100
                         ( Estim. Costs = 651 , Estim. #Rows = 924.308 )
                         Estim. CPU-Costs = 33.377.789 Estim. IO-Costs = 646
    PX = Parallel eXecution...
    But be sure that you know what you do with the parallel execution option... it is not scalable.... .
    Kind regards,
    Hermann

  • How To Perform Parallel UPDATE When Trigger is ENABLE On Table.

    select *from v$version;
    BANNER
    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 - ProductionIs there any way to perform PARALLEL UPATE on a table which has a trigger?
    One of my ETL performs a large UPDATE (14 Million update) everyday on a production hot table. Eventhough PDML is enable at session level (also TABLE.DEGREE=8), Oracle is doing serialized UPDATE.
    As per Oracle documents, it is documented behavior.
    Here is my Execution plan when i put the trigger ENABLE
    | Id  | Operation              | Name                | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |    TQ  |IN-OUT| PQ Distrib |
    |   0 | UPDATE STATEMENT       |                     |       |       |  6443 (100)|          |       |       |        |      |            |
    |   1 |  UPDATE                | ACCOUNT             |       |       |            |          |       |       |        |      |            |
    |*  2 |   PX COORDINATOR       |                     |       |       |            |          |       |       |        |      |            |
    |   3 |    PX SEND QC (RANDOM) | :TQ10000            | 72487 |  3610K|  6443   (3)| 00:01:18 |       |       |  Q1,00 | P->S | QC (RAND)  |
    |*  4 |     FILTER             |                     |       |       |            |          |       |       |  Q1,00 | PCWC |            |
    |   5 |      PX BLOCK ITERATOR |                     | 72487 |  3610K|  6443   (3)| 00:01:18 |   KEY |   KEY |  Q1,00 | PCWC |            |
    |*  6 |       TABLE ACCESS FULL| ACCOUNT             | 72487 |  3610K|  6443   (3)| 00:01:18 |   KEY |   KEY |  Q1,00 | PCWP |            |
    Predicate Information (identified by operation id):
         8 - filter("SET_OF_BOOKS"='1' AND "GL_BATCH_ID">(-10) AND ("JOURNAL_ENTRY_TYPE_ID"<2400 OR
                  "JOURNAL_ENTRY_TYPE_ID">=3000) AND "ACCOUNTING_DATE">=TO_DATE(' 2010-08-11 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND "ACCOUNTING_DATE"<TO_DATE(' 2010-08-12 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))When i disable trigger
    | Id  | Operation                | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | UPDATE STATEMENT         |          |   726 | 27588 | 11899   (2)| 00:02:23 |        |      |            |
    |   1 |  PX COORDINATOR          |          |       |       |            |          |        |      |            |
    |   2 |   PX SEND QC (RANDOM)    | :TQ10001 |   726 | 27588 | 11899   (2)| 00:02:23 |  Q1,01 | P->S | QC (RAND)  |
    |   3 |    INDEX MAINTENANCE     | ACCOUNT  |       |       |            |          |  Q1,01 | PCWP |            |
    |   4 |     PX RECEIVE           |          |   726 | 27588 | 11899   (2)| 00:02:23 |  Q1,01 | PCWP |            |
    |   5 |      PX SEND RANGE       | :TQ10000 |   726 | 27588 | 11899   (2)| 00:02:23 |  Q1,00 | P->P | RANGE      |
    |   6 |       UPDATE             | ACCOUNT  |       |       |            |          |  Q1,00 | PCWP |            |
    |   7 |        PX BLOCK ITERATOR |          |   726 | 27588 | 11899   (2)| 00:02:23 |  Q1,00 | PCWC |            |
    |*  8 |         TABLE ACCESS FULL| ACCOUNT  |   726 | 27588 | 11899   (2)| 00:02:23 |  Q1,00 | PCWP |            |
    Predicate Information (identified by operation id):
       8 - filter("SET_OF_BOOKS"='1' AND "GL_BATCH_ID">(-10) AND ("JOURNAL_ENTRY_TYPE_ID"<2400 OR
                  "JOURNAL_ENTRY_TYPE_ID">=3000) AND "ACCOUNTING_DATE">=TO_DATE(' 2010-08-11 00:00:00', 'syyyy-mm-dd
                  hh24:mi:ss') AND "ACCOUNTING_DATE"<TO_DATE(' 2010-08-12 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))I cannot disable trigger due to some business reasons.
    Is there any way to speed up UPDATE ?

    No, you cannot perform parallel dml with a trigger present.
    If you are updating the bulk of the rows and can take an outage, you can
    disable the trigger, perform the update, enable the trigger
    OR
    copy to another table, performing the update in the select, rename the tables and add the trigger on the new table
    Hemant K Chitale

  • Gather_Plan_Statistics + DBMS_XPLAN A-rows for parallel queries

    Looks like gather_plan_statistics + dbms_xplan displays incorrect A-rows for parallel queries. Is there any way to get the correct A-rows for a parallel query?
    Version details:
    Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi on HPUX
    Create test tables:
    -- Account table
    create table test_tacprof
    parallel (degree 2) as
    select object_id ac_nr,
           object_name ac_na
    from all_objects;      
    alter table test_tacprof add constraint test_tacprof_pk primary key (ac_nr);
    -- Account revenue table
    create table test_taccrev
    parallel (degree 2) as
    select apf.ac_nr         ac_nr,
           fiv.r             tm_prd,
           apf.ac_nr * fiv.r ac_rev
    from   (select rownum r from all_objects where rownum <= 5) fiv,
           test_tacprof apf;
    alter table test_taccrev add constraint test_taccrev_pk primary key (ac_nr, tm_prd);
    -- Table to hold query results
    create table test_4accrev as
    select apf.ac_nr, apf.ac_na, rev.tm_prd, rev.ac_rev
    from test_taccrev rev,
         test_tacprof apf
    where 1=2;
    Run query with parallel dml/query disabled:
    ALTER SESSION DISABLE PARALLEL QUERY;
    ALTER SESSION DISABLE PARALLEL DML;
    INSERT INTO test_4accrev
       SELECT /*+ gather_plan_statistics */
              apf.ac_nr,
              apf.ac_na,
              rev.tm_prd,
              rev.ac_rev
         FROM test_taccrev rev, test_tacprof apf
        WHERE apf.ac_nr = rev.ac_nr AND tm_prd = 4;
    SELECT *
      FROM TABLE (DBMS_XPLAN.display_cursor (NULL, NULL, 'ALLSTATS LAST'));
    | Id  | Operation          | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Use
    |*  1 |  HASH JOIN         |              |      1 |  30442 |  23412 |00:00:00.27 |     772 |  1810K|  1380K| 2949K (0)|
    |   2 |   TABLE ACCESS FULL| TEST_TACPROF |      1 |  26050 |  23412 |00:00:00.01 |     258 |       |       |    
    |*  3 |   TABLE ACCESS FULL| TEST_TACCREV |      1 |  30441 |  23412 |00:00:00.03 |     514 |       |       |    
    ROLLBACK ;
    A-rows are correctly reported with no parallel.
    Run query with parallel dml/query enabled:
    ALTER SESSION enable PARALLEL QUERY;
    alter session enable parallel dml;
    insert into test_4accrev
    select /*+ gather_plan_statistics */ apf.ac_nr, apf.ac_na, rev.tm_prd, rev.ac_rev
    from test_taccrev rev,
         test_tacprof apf
    where apf.ac_nr = rev.ac_nr
    and   tm_prd = 4;    
    select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));                
    | Id  | Operation                | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-M
    |   1 |  PX COORDINATOR          |              |      1 |        |  23412 |00:00:00.79 |       6 |       |       |          |
    |   2 |   PX SEND QC (RANDOM)    | :TQ10001     |      0 |  30442 |      0 |00:00:00.01 |       0 |       |       |          |
    |*  3 |    HASH JOIN             |              |      0 |  30442 |      0 |00:00:00.01 |       0 |  2825K|  1131K|          |
    |   4 |     PX BLOCK ITERATOR    |              |      0 |  30441 |     0 |00:00:00.01 |       0 |       |       |          |
    |*  5 |      TABLE ACCESS FULL   | TEST_TACCREV |      0 |  30441 |      0 |00:00:00.01 |       0 |       |       |       
    |   6 |     BUFFER SORT          |              |      0 |        |      0 |00:00:00.01 |       0 | 73728 | 73728 |          |
    |   7 |      PX RECEIVE          |              |      0 |  26050 |      0 |00:00:00.01 |       0 |       |       |          |
    |   8 |       PX SEND BROADCAST  | :TQ10000     |      0 |  26050 |      0 |00:00:00.01 |       0 |       |       |          |
    |   9 |        PX BLOCK ITERATOR |              |      0 |  26050 |      0 |00:00:00.01 |       0 |       |       |          |
    |* 10 |         TABLE ACCESS FULL| TEST_TACPROF |      0 |  26050 |      0 |00:00:00.01 |       0 |       |       |          |
    rollback;
    A-rows are zero execpt for final step.

    I'm sorry for posting following long test case.
    But it's the most convenient way to explain something. :-)
    Here is my test case, which is quite similar to yours.
    Note on the difference between "parallel select" and "parallel dml(insert here)".
    (I know that Oracle implemented psc(parallel single cursor) model in 10g, but the details of the implementation is quite in mystery as Jonathan said... )
    SQL> select * from v$version;
    BANNER                                                                         
    Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod               
    PL/SQL Release 10.2.0.1.0 - Production                                         
    CORE     10.2.0.1.0     Production                                                     
    TNS for 32-bit Windows: Version 10.2.0.1.0 - Production                        
    NLSRTL Version 10.2.0.1.0 - Production                                         
    SQL>
    SQL> alter system flush shared_pool;
    System altered.
    SQL>
    SQL> alter table t parallel 4;
    Table altered.
    SQL>
    SQL> select /*+ gather_plan_statistics */ count(*) from t t1, t t2
      2  where t1.c1 = t2.c1 and rownum <= 1000
      3  order by t1.c2;
      COUNT(*)                                                                     
          1000                                                                     
    SQL>
    SQL> select sql_id from v$sqlarea
    where sql_text like 'select /*+ gather_plan_statistics */ count(*) from t t1, t t2%';
    SQL_ID                                                                         
    bx61bkyh9ffb6                                                                  
    SQL>
    SQL> select * from table(dbms_xplan.display_cursor('&sql_id',null,'allstats last'));
    Enter value for sql_id: bx61bkyh9ffb6
    PLAN_TABLE_OUTPUT                                                              
    SQL_ID  bx61bkyh9ffb6, child number 0          <-- Cooridnator and slaves shared the cursor                          
    select /*+ gather_plan_statistics */ count(*) from t t1, t t2 where t1.c1 = t2.c
    1 and rownum <= 1000 order by t1.c2                                            
    Plan hash value: 3015647771                                                    
    PLAN_TABLE_OUTPUT                                                              
    | Id  | Operation                  | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers |  OMem |  1Mem | Used-Mem |                               
    |   1 |  SORT AGGREGATE            |          |      1 |      1 |      1 |00:00:00.62 |       6 |       |       |          |                                   
    |*  2 |   COUNT STOPKEY            |          |      1 |        |   1000 |00:00:00.62 |       6 |       |       |          |                                   
    |   3 |    PX COORDINATOR          |          |      1 |        |   1000 |00:00:00.50 |       6 |       |       |          |                                   
    |   4 |     PX SEND QC (RANDOM)    | :TQ10002 |      0 |     16M|      0 |00:00:00.01 |       0 |       |       |          |                                   
    |*  5 |      COUNT STOPKEY         |          |      0 |        |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |*  6 |       HASH JOIN BUFFERED   |          |      0 |     16M|      0 |00:00:00.01 |       0 |  1285K|  1285K|  717K (0)|                                   
    |   7 |        PX RECEIVE          |          |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |   8 |         PX SEND HASH       | :TQ10000 |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |   9 |          PX BLOCK ITERATOR |          |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |* 10 |           TABLE ACCESS FULL| T        |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |  11 |        PX RECEIVE          |          |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |  12 |         PX SEND HASH       | :TQ10001 |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |  13 |          PX BLOCK ITERATOR |          |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    |* 14 |           TABLE ACCESS FULL| T        |      0 |  10000 |      0 |00:00:00.01 |       0 |       |       |          |                                   
    38 rows selected.
    SQL>
    SQL> select sql_id, child_number, executions, px_servers_executions
      2  from v$sql where sql_id = '&sql_id';
    SQL_ID                                  CHILD_NUMBER EXECUTIONS                
    PX_SERVERS_EXECUTIONS                                                          
    bx61bkyh9ffb6                                      0          1                
                        8                                                          
    SQL>
    SQL> insert /*+ gather_plan_statistics */ into t select * from t;
    10000 rows created.
    SQL>
    SQL> select sql_id from v$sqlarea
    where sql_text like 'insert /*+ gather_plan_statistics */ into t select * from t%';
    SQL_ID                                                                         
    9dkmu9bdhg5h0                                                                  
    SQL>
    SQL> select * from table(dbms_xplan.display_cursor('&sql_id', null, 'allstats last'));
    Enter value for sql_id: 9dkmu9bdhg5h0
    PLAN_TABLE_OUTPUT                                                              
    SQL_ID  9dkmu9bdhg5h0, child number 0       <-- Coordinator Cursor                         
    insert /*+ gather_plan_statistics */ into t select * from t                    
    Plan hash value: 3050126167                                                    
    | Id  | Operation            | Name     | Starts | E-Rows | A-Rows |   A-Time   | Buffers |                                                                    
    |   1 |  PX COORDINATOR      |          |      1 |        |  10000 |00:00:00.20 |       3 |                                                                    
    |   2 |   PX SEND QC (RANDOM)| :TQ10000 |      0 |  10000 |      0 |00:00:00.01 |       0 |                                                                    
    |   3 |    PX BLOCK ITERATOR |          |      0 |  10000 |      0 |00:00:00.01 |       0 |                                                                    
    |*  4 |     TABLE ACCESS FULL| T        |      0 |  10000 |      0 |00:00:00.01 |       0 |                                                                    
    SQL_ID  9dkmu9bdhg5h0, child number 1        <-- Slave(s)
    insert /*+ gather_plan_statistics */ into t select * from t                    
    PLAN_TABLE_OUTPUT                                                              
    Plan hash value: 3050126167                                                    
    | Id  | Operation            | Name     | Starts | E-Rows | A-Rows |   A-Time  | Buffers |                                                                    
    |   1 |  PX COORDINATOR      |          |      0 |        |      0 |00:00:00.01 |       0 |                                                                    
    |   2 |   PX SEND QC (RANDOM)| :TQ10000 |      0 |  10000 |      0 |00:00:00.01 |       0 |                                                                    
    |   3 |    PX BLOCK ITERATOR |          |      1 |  10000 |   2628 |00:00:00.20 |      16 |                                                                    
    |*  4 |     TABLE ACCESS FULL| T        |      4 |  10000 |   2628 |00:00:00.02 |      16 |                                                                    
    SQL>
    SQL> select sql_id, child_number, executions, px_servers_executions
      2  from v$sql where sql_id = '&sql_id';  <-- 2 child cursors here
    SQL_ID                                  CHILD_NUMBER EXECUTIONS                
    PX_SERVERS_EXECUTIONS                                                          
    9dkmu9bdhg5h0                                      0          1                
                        0                                                          
    9dkmu9bdhg5h0                                      1          0                
                        4                                                          
    SQL>
    SQL> set serveroutput on
    -- check mismatch
    SQL> exec print_table('select * from v$sql_shared_cursor where sql_id = ''&sql_id''');
    Enter value for sql_id: 9dkmu9bdhg5h0
    SQL_ID                        : 9dkmu9bdhg5h0                                  
    ADDRESS                       : 6AD85A70                                       
    CHILD_ADDRESS                 : 6BA596A8                                       
    CHILD_NUMBER                  : 0                                              
    UNBOUND_CURSOR                : N                                              
    SQL_TYPE_MISMATCH             : N                                              
    OPTIMIZER_MISMATCH            : N                                              
    OUTLINE_MISMATCH              : N                                              
    STATS_ROW_MISMATCH            : N                                              
    LITERAL_MISMATCH              : N                                              
    SEC_DEPTH_MISMATCH            : N                                              
    EXPLAIN_PLAN_CURSOR           : N                                              
    BUFFERED_DML_MISMATCH         : N                                              
    PDML_ENV_MISMATCH             : N                                              
    INST_DRTLD_MISMATCH           : N                                              
    SLAVE_QC_MISMATCH             : N                                              
    TYPECHECK_MISMATCH            : N                                              
    AUTH_CHECK_MISMATCH           : N                                              
    BIND_MISMATCH                 : N                                              
    DESCRIBE_MISMATCH             : N                                              
    LANGUAGE_MISMATCH             : N                                              
    TRANSLATION_MISMATCH          : N                                              
    ROW_LEVEL_SEC_MISMATCH        : N                                              
    INSUFF_PRIVS                  : N                                              
    INSUFF_PRIVS_REM              : N                                              
    REMOTE_TRANS_MISMATCH         : N                                              
    LOGMINER_SESSION_MISMATCH     : N                                              
    INCOMP_LTRL_MISMATCH          : N                                              
    OVERLAP_TIME_MISMATCH         : N                                              
    SQL_REDIRECT_MISMATCH         : N                                              
    MV_QUERY_GEN_MISMATCH         : N                                              
    USER_BIND_PEEK_MISMATCH       : N                                              
    TYPCHK_DEP_MISMATCH           : N                                              
    NO_TRIGGER_MISMATCH           : N                                              
    FLASHBACK_CURSOR              : N                                              
    ANYDATA_TRANSFORMATION        : N                                              
    INCOMPLETE_CURSOR             : N                                              
    TOP_LEVEL_RPI_CURSOR          : N                                              
    DIFFERENT_LONG_LENGTH         : N                                              
    LOGICAL_STANDBY_APPLY         : N                                              
    DIFF_CALL_DURN                : N                                              
    BIND_UACS_DIFF                : N                                              
    PLSQL_CMP_SWITCHS_DIFF        : N                                              
    CURSOR_PARTS_MISMATCH         : N                                              
    STB_OBJECT_MISMATCH           : N                                              
    ROW_SHIP_MISMATCH             : N                                              
    PQ_SLAVE_MISMATCH             : N                                              
    TOP_LEVEL_DDL_MISMATCH        : N                                              
    MULTI_PX_MISMATCH             : N                                              
    BIND_PEEKED_PQ_MISMATCH       : N                                              
    MV_REWRITE_MISMATCH           : N                                              
    ROLL_INVALID_MISMATCH         : N                                              
    OPTIMIZER_MODE_MISMATCH       : N                                              
    PX_MISMATCH                   : N                                              
    MV_STALEOBJ_MISMATCH          : N                                              
    FLASHBACK_TABLE_MISMATCH      : N                                              
    LITREP_COMP_MISMATCH          : N                                              
    SQL_ID                        : 9dkmu9bdhg5h0                                  
    ADDRESS                       : 6AD85A70                                       
    CHILD_ADDRESS                 : 6B10AA00                                       
    CHILD_NUMBER                  : 1                                              
    UNBOUND_CURSOR                : N                                              
    SQL_TYPE_MISMATCH             : N                                              
    OPTIMIZER_MISMATCH            : N                                              
    OUTLINE_MISMATCH              : N                                              
    STATS_ROW_MISMATCH            : N                                              
    LITERAL_MISMATCH              : N                                              
    SEC_DEPTH_MISMATCH            : N                                              
    EXPLAIN_PLAN_CURSOR           : N                                              
    BUFFERED_DML_MISMATCH         : N                                              
    PDML_ENV_MISMATCH             : N                                              
    INST_DRTLD_MISMATCH           : N                                              
    SLAVE_QC_MISMATCH             : N                                              
    TYPECHECK_MISMATCH            : N                                              
    AUTH_CHECK_MISMATCH           : N                                              
    BIND_MISMATCH                 : N                                              
    DESCRIBE_MISMATCH             : N                                              
    LANGUAGE_MISMATCH             : N                                              
    TRANSLATION_MISMATCH          : N                                              
    ROW_LEVEL_SEC_MISMATCH        : N                                              
    INSUFF_PRIVS                  : N                                              
    INSUFF_PRIVS_REM              : N                                              
    REMOTE_TRANS_MISMATCH         : N                                              
    LOGMINER_SESSION_MISMATCH     : N                                              
    INCOMP_LTRL_MISMATCH          : N                                              
    OVERLAP_TIME_MISMATCH         : N                                              
    SQL_REDIRECT_MISMATCH         : N                                              
    MV_QUERY_GEN_MISMATCH         : N                                              
    USER_BIND_PEEK_MISMATCH       : N                                              
    TYPCHK_DEP_MISMATCH           : N                                              
    NO_TRIGGER_MISMATCH           : N                                              
    FLASHBACK_CURSOR              : N                                              
    ANYDATA_TRANSFORMATION        : N                                              
    INCOMPLETE_CURSOR             : N                                              
    TOP_LEVEL_RPI_CURSOR          : N                                              
    DIFFERENT_LONG_LENGTH         : N                                              
    LOGICAL_STANDBY_APPLY         : N                                              
    DIFF_CALL_DURN                : Y      <-- Mismatch here. diff_call_durn
    BIND_UACS_DIFF                : N                                              
    PLSQL_CMP_SWITCHS_DIFF        : N                                              
    CURSOR_PARTS_MISMATCH         : N                                              
    STB_OBJECT_MISMATCH           : N                                              
    ROW_SHIP_MISMATCH             : N                                              
    PQ_SLAVE_MISMATCH             : N                                              
    TOP_LEVEL_DDL_MISMATCH        : N                                              
    MULTI_PX_MISMATCH             : N                                              
    BIND_PEEKED_PQ_MISMATCH       : N                                              
    MV_REWRITE_MISMATCH           : N                                              
    ROLL_INVALID_MISMATCH         : N                                              
    OPTIMIZER_MODE_MISMATCH       : N                                              
    PX_MISMATCH                   : N                                              
    MV_STALEOBJ_MISMATCH          : N                                              
    FLASHBACK_TABLE_MISMATCH      : N                                              
    LITREP_COMP_MISMATCH          : N                                              
    PL/SQL procedure successfully completed.

  • Performance of queries against large AD CS databases - how to optimize?

    I am asking experts with experience with AD CS databases with 100.000s or millions of certificate to confirm or correct my "theories".
    I am aware of these two articles that state performance is not an issue for millions of certificates:
    Windows CA Performance Numbers and
    Evaluating CA Capacity, Performance, and Scalability
    However, here performance is mainly evaluated in terms of database size and request / certificate throughput. I am more interested in the performance of queries as I have seen that it might take minutes to build up views for databases with 100.000s of certificates
    - no matter if you use certutil -view, certsrv.msc, or access to CCertview.
    Could this just be due to an "unfortunate" combination of non-indexed fields? Any advice on which queries to avoid?
    Or is the solution just as simple as to throw more memory or CPU or both at the problem?
    In case it hinges on an unfortunate choice fields and you absolutely have to do this query my guess is that you have to use a custom policy(*) module (FIM or third-party) to dump certificates to a SQL database and do your queries there.
    Am I right or did I miss something? Any input is highly appreciated!
    Elke
    PS / edit: That should have been 'Exit module' - I don't know why I wrote Policy Module. Thanks for Vadims for pointing it out.

    > I meant 'exit module'
    exit module is correct one. However, it is notified by a CA only when new request is issued/processed. This means that you can use Exit Module to copy certificate information to SQL only for new requests, for existing requests you are still sticking
    with a database dump.
    > but I should probably check how I dealt with the row handles
    I don't know how COM handle are working in VBS, but in PowerShell (and other CLR languages) COM handle may not be handled properly by a garbage collector, therefore, when COM object is not necessary, you should set reference count to zero. In CLR it is made
    by calling Marshal.ReleaseComObject method. This will mark COM object as safe for garbage collector. For example, the typical row/column iterator scheme is:
    $Row = $ICertView.OpenView()
    # do row iteration
    while ($Row.Next() -ne -1) {
    # acquire IEnumCERTVIEWCOLUMN COM object
    $Column = $Row.EnumCertViewColumn()
    # do column iteration for the current row
    while ($Column.Next() -ne -1) {
    # collect column information and other stuff
    # do other stuff if necessary
    # release IEnumCERTVIEWCOLUMN object. This is the last line in the while/do loop.
    [Runtime.InteropServices.Marshall]::ReleaseComObject($Column)
    # release IEnumCERTVIEWROW COM object as well
    [Runtime.InteropServices.Marshall]::ReleaseComObject($Row)
    My weblog: en-us.sysadmins.lv
    PowerShell PKI Module: pspki.codeplex.com
    PowerShell Cmdlet Help Editor pscmdlethelpeditor.codeplex.com
    Check out new: SSL Certificate Verifier
    Check out new:
    PowerShell FCIV tool.

  • Performing sql queries in java without using java libraries

    i wonder whether its possible to perform sql queries beginning from create table to updating queries without using the java sql library.
    has anyone written such code.

    You could use JNI to talk to a native driver like the Oracle OCI driver. Doing this is either exiting or asking for trouble depending on your attitude to lots of low level bugs.

  • Precision Changes when running parallel queries in Oracle?

    I am trying to speed up our SQL queries and database draws by running parallel queries. However, we are noticing a slight difference in one of our queries. We have identified two possible reasons. One of those reasons is parallel queries for some reason have either less or more precision than what we were doing.
    Has this ever been reported before? Is it even possible? Thanks for any help.

    One of those reasons is parallel queries for some reason have either less or more precision than what we were doing.What do you mean? Show us an example of that happening and exactly what you mean.

  • How many parallel queries?

    We are planing to install Ultra Search on Linux SUSE 8.1 with
    Oracle Webserver : APACHE
    ca.30 GB , gigabit ethernet ,
    3GB RAM
    searchengine: ORACLE ULTRA SEARCH
    we have ca 10.000 users, who are interested to search on our webserver
    9iAs , the index-database and the crawler will be installed on the same machine.
    Ist it possible to answer in general :
    How many parallel queries Ultra Search enables?

    We are planing to install Ultra Search on Linux SUSE 8.1 with
    Oracle Webserver : APACHE
    ca.30 GB , gigabit ethernet ,
    3GB RAM
    searchengine: ORACLE ULTRA SEARCH
    we have ca 10.000 users, who are interested to search on our webserver
    9iAs , the index-database and the crawler will be installed on the same machine.
    Ist it possible to answer in general :
    How many parallel queries Ultra Search enables?

  • How to detect sessions that are currently running parallel queries?

    Hi everyone,
    How to detect session that are currently running parallel queries?
    - The only way i can think of is querying pdml_Status from gv$session?
    - Is there a better way to do this?
    Follow up question:
    After detecting sessions that are running parallel queries how do i identify which sessions are slaves of which session?
    thanks!

    Start with V$PX_SESSION, however also take a look at V$PQ_* and V$PX_* tables.

  • Parallel Queries

    Dear friends,
    Can anyone tell me more about PARALLEL QUERIES. How do you parallelize query operations in Oracle?
    Thanks

    http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/a76965/c22paral.htm#14893
    null

  • Oracle 11.2 - Perform parallel DML on a non partitioned table with LOB column

    Hi,
    Since I wanted to demonstrate new Oracle 12c enhancements on SecureFiles, I tried to use PDML statements on a non partitioned table with LOB column, in both Oracle 11g and Oracle 12c releases. The Oracle 11.2 SecureFiles and Large Objects Developer's Guide of January 2013 clearly says:
    Parallel execution of the following DML operations on tables with LOB columns is supported. These operations run in parallel execution mode only when performed on a partitioned table. DML statements on non-partitioned tables with LOB columns continue to execute in serial execution mode.
    INSERT AS SELECT
    CREATE TABLE AS SELECT
    DELETE
    UPDATE
    MERGE (conditional UPDATE and INSERT)
    Multi-table INSERT
    So I created and populated a simple table with a BLOB column:
    SQL> CREATE TABLE T1 (A BLOB);
    Table created.
    Then, I tried to see the execution plan of a parallel DELETE:
    SQL> EXPLAIN PLAN FOR
      2  delete /*+parallel (t1,8) */ from t1;
    Explained.
    SQL> select * from table(dbms_xplan.display);
    PLAN_TABLE_OUTPUT
    Plan hash value: 3718066193
    | Id  | Operation             | Name     | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | DELETE STATEMENT      |          |  2048 |     2   (0)| 00:00:01 |        |      |            |
    |   1 |  DELETE               | T1       |       |            |          |        |      |            |
    |   2 |   PX COORDINATOR      |          |       |            |          |        |      |            |
    |   3 |    PX SEND QC (RANDOM)| :TQ10000 |  2048 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
    |   4 |     PX BLOCK ITERATOR |          |  2048 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
    |   5 |      TABLE ACCESS FULL| T1       |  2048 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
    PLAN_TABLE_OUTPUT
    Note
       - dynamic sampling used for this statement (level=2)
    And I finished by executing the statement.
    SQL> commit;
    Commit complete.
    SQL> alter session enable parallel dml;
    Session altered.
    SQL> delete /*+parallel (t1,8) */ from t1;
    2048 rows deleted.
    As we can see, the statement has been run as parallel:
    SQL> select * from v$pq_sesstat;
    STATISTIC                      LAST_QUERY SESSION_TOTAL
    Queries Parallelized                    1             1
    DML Parallelized                        0             0
    DDL Parallelized                        0             0
    DFO Trees                               1             1
    Server Threads                          5             0
    Allocation Height                       5             0
    Allocation Width                        1             0
    Local Msgs Sent                        55            55
    Distr Msgs Sent                         0             0
    Local Msgs Recv'd                      55            55
    Distr Msgs Recv'd                       0             0
    11 rows selected.
    Is it normal ? It is not supposed to be supported on Oracle 11g with non-partitioned table containing LOB column....
    Thank you for your help.
    Michael

    Yes I did it. I tried with force parallel dml, and that is the results on my 12c DB, with the non partitionned and SecureFiles LOB column.
    SQL> explain plan for delete from t1;
    Explained.
    | Id  | Operation             | Name     | Rows  | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | DELETE STATEMENT      |          |     4 |     2   (0)| 00:00:01 |        |      |            |
    |   1 |  DELETE               | T1       |       |            |          |        |      |            |
    |   2 |   PX COORDINATOR      |          |       |            |          |        |      |            |
    |   3 |    PX SEND QC (RANDOM)| :TQ10000 |     4 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
    |   4 |     PX BLOCK ITERATOR |          |     4 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
    |   5 |      TABLE ACCESS FULL| T1       |     4 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
    The DELETE is not performed in Parallel.
    I tried with another statement :
    SQL> explain plan for
    2        insert into t1 select * from t1;
    Here are the results:
    11g
    | Id  | Operation                | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | INSERT STATEMENT         |          |     4 |  8008 |     2   (0)| 00:00:01 |        |      |            |
    |   1 |  LOAD TABLE CONVENTIONAL | T1       |       |       |            |          |        |      |            |
    |   2 |   PX COORDINATOR         |          |       |       |            |          |        |      |            |
    |   3 |    PX SEND QC (RANDOM)   | :TQ10000 |     4 |  8008 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
    |   4 |     PX BLOCK ITERATOR    |          |     4 |  8008 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
    |   5 |      TABLE ACCESS FULL   | T1       |     4 |  8008 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
    12c
    | Id  | Operation                          | Name     | Rows  | Bytes | Cost (%CPU)| Time     |    TQ  |IN-OUT| PQ Distrib |
    |   0 | INSERT STATEMENT                   |          |     4 |  8008 |     2   (0)| 00:00:01 |        |      |            |
    |   1 |  PX COORDINATOR                    |          |       |       |            |          |        |      |            |
    |   2 |   PX SEND QC (RANDOM)              | :TQ10000 |     4 |  8008 |     2   (0)| 00:00:01 |  Q1,00 | P->S | QC (RAND)  |
    |   3 |    LOAD AS SELECT                  | T1       |       |       |            |          |  Q1,00 | PCWP |            |
    |   4 |     OPTIMIZER STATISTICS GATHERING |          |     4 |  8008 |     2   (0)| 00:00:01 |  Q1,00 | PCWP |            |
    |   5 |      PX BLOCK ITERATOR             |          |     4 |  8008 |     2   (0)| 00:00:01 |  Q1,00 | PCWC |            |
    It seems that the DELETE statement has problems but not the INSERT AS SELECT !

  • Performance: many queries used in dashboard

    Hi experts,
    My dashboard contains more than 30 queries runing on 2 multiproviders. When looking in sm50 it seems as though only 2 queries are run in parallel after pressing the submit button. Moreover the queries that should provide results on the first tabpage in my model only give results after all other tables and charts are already filled.
    I would like more queries to run parallel and to give the highest priority to queries on the first tabpage. Is there somewehere that I can make this setting (f.e. on multiprovider level)?
    Answers are appreciated and will be awarded with points.
    Thanks in advance,
    Ralph

    Hi,
    I am facing a similar problem with our customer's application. However, activating the dedicated connections for nested iViews did not help. We have several iView, each containg 1 to 7 queries, approx. 30 Queries in the whole model. Each query runs about 1 sec, the whole model approx. 35 seconds. Even though the data flow is modeled in a parallel way (i.e. queries should be executed simultaneously).
    Who can help?
    Thanks in advance an kiond regards,
      Benni

  • Poorly Performing SQL Queries and AWR

    version : 10.2.0.4 on OEL 5.
    Snapshot duration is 30 mins. Its long, but sorry that is what is available right now.
    I have three queries in my database which are performing pretty slow. I took AWR reports for these queries and they are as follows:
    Query 1:
    ======
        Plan Hash           Total Elapsed                 1st Capture   Last Capture
    #   Value                    Time(ms)    Executions       Snap ID        Snap ID
    1   3714475000                113,449             9         60539          60540
    -> % Total DB Time is the Elapsed Time of the SQL statement divided  into the Total Database Time multiplied by 100
    Stat Name                                Statement   Per Execution % Snap
    Elapsed Time (ms)                           113,449       12,605.4     3.9
    CPU Time (ms)                               108,620       12,068.9     4.0
    Executions                                        9            N/A     N/A
    Buffer Gets                                4.25E+07    4,722,689.0    11.7
    Disk Reads                                        0            0.0     0.0
    Parse Calls                                       9            1.0     0.0
    Rows                                             20            2.2     N/A
    User I/O Wait Time (ms)                           0            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                252            N/A     N/AQuery 2:
    ======
        Plan Hash           Total Elapsed                 1st Capture   Last Capture
    #   Value                    Time(ms)    Executions       Snap ID        Snap ID
    1   4197000940              1,344,458             3         60539          60540
    -> % Total DB Time is the Elapsed Time of the SQL statement divided   into the Total Database Time multiplied by 100
    Stat Name                                Statement   Per Execution % Snap
    Elapsed Time (ms)                         1,344,458      448,152.7    46.5
    CPU Time (ms)                             1,353,670      451,223.3    49.7
    Executions                                        3            N/A     N/A
    Buffer Gets                                3.42E+07   11,383,856.7     9.4
    Disk Reads                                        0            0.0     0.0
    Parse Calls                                       3            1.0     0.0
    Rows                                             48           16.0     N/A
    User I/O Wait Time (ms)                           0            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                270            N/A     N/AQuery 3:
    ======
        Plan Hash           Total Elapsed                 1st Capture   Last Capture
    #   Value                    Time(ms)    Executions       Snap ID        Snap ID
    1   2000299266                104,060             7         60539          60540
    -> % Total DB Time is the Elapsed Time of the SQL statement divided   into the Total Database Time multiplied by 100
    Stat Name                                Statement   Per Execution % Snap
    Elapsed Time (ms)                           104,060       14,865.7     3.6
    CPU Time (ms)                               106,150       15,164.3     3.9
    Executions                                        7            N/A     N/A
    Buffer Gets                                4.38E+07    6,256,828.1    12.1
    Disk Reads                                        0            0.0     0.0
    Parse Calls                                       7            1.0     0.0
    Rows                                             79           11.3     N/A
    User I/O Wait Time (ms)                           0            N/A     N/A
    Cluster Wait Time (ms)                            0            N/A     N/A
    Application Wait Time (ms)                        0            N/A     N/A
    Concurrency Wait Time (ms)                        0            N/A     N/A
    Invalidations                                     0            N/A     N/A
    Version Count                                     2            N/A     N/A
    Sharable Mem(KB)                                748            N/A     N/AAny Ideas please as what is wrong with the above statistics? And what should I do next with it?
    Thanks.

    Here is one of the plan for query:
    | Id  | Operation                            | Name                   | Rows  | Bytes | Cost (%CPU)|
    Time     |
    |   0 | SELECT STATEMENT                     |                        |       |       |  9628 (100)|
              |
    |   1 |  VIEW                                |                        |    73 | 58546 |  9628   (1)|
    00:01:56 |
    |   2 |   WINDOW SORT PUSHED RANK            |                        |    73 | 22630 |  9628   (1)|
    00:01:56 |
    |   3 |    FILTER                            |                        |       |       |            |
              |
    |   4 |     NESTED LOOPS                     |                        |    73 | 22630 |  9627   (1)|
    00:01:56 |
    |   5 |      NESTED LOOPS                    |                        |    73 | 20586 |  9554   (1)|
    00:01:55 |
    |   6 |       NESTED LOOPS OUTER             |                        |    72 | 15552 |  9482   (1)|
    00:01:54 |
    |   7 |        NESTED LOOPS                  |                        |    72 | 13320 |  9410   (1)|
    00:01:53 |
    |   8 |         NESTED LOOPS                 |                        |    72 | 12168 |  9338   (1)|
    00:01:53 |
    |   9 |          NESTED LOOPS                |                        |  4370 |   277K|    29   (0)|
    00:00:01 |
    |  10 |           TABLE ACCESS BY INDEX ROWID| test_ORG                |     1 |    34 |     2   (0)|
    00:00:01 |
    |  11 |            INDEX UNIQUE SCAN         | test_ORG_PK             |     1 |       |     1   (0)|
    00:00:01 |
    |  12 |           TABLE ACCESS FULL          | test_USER               |  4370 |   132K|    27   (0)|
    00:00:01 |
    |  13 |          TABLE ACCESS BY INDEX ROWID | REF_CLIENT_FOO_ACCT   |     1 |   104 |     7   (0)|
    00:00:01 |
    |  14 |           INDEX RANGE SCAN           | RCFA_test_ORG_IDX       |   165 |       |     2   (0)|
    00:00:01 |
    |  15 |         TABLE ACCESS BY INDEX ROWID  | test_ACCOUNT            |     1 |    16 |     1   (0)|
    00:00:01 |
    |  16 |          INDEX UNIQUE SCAN           | test_CUSTODY_ACCOUNT_PK |     1 |       |     0   (0)|
              |
    |  17 |        TABLE ACCESS BY INDEX ROWID   | test_USER               |     1 |    31 |     1   (0)|
    00:00:01 |
    |  18 |         INDEX UNIQUE SCAN            | test_USER_PK_IDX        |     1 |       |     0   (0)|
              |
    |  19 |       TABLE ACCESS BY INDEX ROWID    | REF_FOO               |     1 |    66 |     1   (0)|
    00:00:01 |
    |  20 |        INDEX UNIQUE SCAN             | REF_FOO_PK            |     1 |       |     0   (0)|
              |
    |  21 |      TABLE ACCESS BY INDEX ROWID     | REF_FOO_FAMILY        |     1 |    28 |     1   (0)|
    00:00:01 |
    PLAN_TABLE_OUTPUT
    |  22 |       INDEX UNIQUE SCAN              | REF_FOO_FAMILY_PK     |     1 |       |     0   (0)|
              |
    40 rows selected.
    SQL>

  • Parallel queries are failing in 8 node RAC DB

    While running queries with parallel hints , the queries are failing with
    ORA-12805 parallel query server died unexpectedly
    Upon checking the alert logs, I couldnt find any thing about ORA-12805, But the i find this error: Please help me to fix this problem
    Fatal NI connect error 12537, connecting to:
    (LOCAL=NO)
    VERSION INFORMATION:
    TNS for Linux: Version 11.1.0.7.0 - Production
    Oracle Bequeath NT Protocol Adapter for Linux: Version 11.1.0.7.0 - Production
    TCP/IP NT Protocol Adapter for Linux: Version 11.1.0.7.0 - Production
    Time: 15-MAY-2012 16:49:15
    Tracing not turned on.
    Tns error struct:
    ns main err code: 12537
    TNS-12537: TNS:connection closed
    ns secondary err code: 12560
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
    ORA-609 : opiodr aborting process unknown ospid (18807_47295439087424)
    Tue May 15 16:49:16 2012

    A couple of thoughts come immediately to mind:
    1. When I read ... "Tracing not turned on" ... I wonder to myself ... why not turn on tracing?
    2. When I read ... "Version 11.1.0.7.0" ... I wonder to myself ... why not apply all of the patches Oracle has created in the last 3 years and see if having a fully patched version addresses the issue?
    3. When I read ... "parallel query server died" ... I wonder whether you have gone to support.oracle.com and looked up the causes and solutions for Parallel Query Server dying?
    Of course I also wonder why you have an 8 node cluster as that is adding substantial complexity and which leads me to wonder ... "is it happening on only one node or all nodes?"
    Hope this helps.

Maybe you are looking for

  • Pool Table Creation in ABAP Dictionary

    Please Help How to create Pool table in ABAP DDIC ? I Tried with the Existing Transparent Table Changing Its Category to Pool Table by going through EXTRA menu and then Change Table Category Option but After this it is asking for Table Pool name in D

  • Why doesn't my HP deskjet x64 printer print to the bottom of the page

    When I print a document it only prints upto about 3cm above the bottom of the page. I have tried changing margins on the documents abd the prints. i have tried selecting different options (eg legal document size which is bigger than A4) I have tried

  • Itunes photo sync tab won't load

    Hello, when I want to sync photos with my iphone, the photos tab in itunes is not loading, there is that loading circle spinning and nothing happens, could somebody help me? thank you in advance!

  • Batch editing of files names....

    Hi- I have several hundred files I need to rename, specifically I need to be able to remove the first five or six characters from each file. Is there a program (Automator?) that would do that sort of thing? Or some kind of AppleScript shortcut? Other

  • Uploading data from various sources

    Folks, I currently have an access database which I would like to replace with HTMLDB but can't seem to resolve a data upload issue. Currently I am running a mainframe program which outputs to a file which can then be read from a browser. Then an exce