Parallel query problem

problem:
In this explain plan 3 indexes are used and I altered these indexes with no parallel degree 1. after that its again using the parallel query...
How to disable the parallel query use for the mentioned above....
Plz help me out....
PLAN_TABLE_OUTPUT
| Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | TQ |IN-OUT| PQ Distrib |
| 0 | SELECT STATEMENT | | 1 | 54 | 3 | | | | | |
| 1 | PX COORDINATOR | | | | | | | | | |
| 2 | PX SEND QC (RANDOM) | :TQ10001 | 1 | 54 | 3 | | | Q1,01 | P->S | QC (RAND) |
| 3 | NESTED LOOPS | | 1 | 54 | 3 | | | Q1,01 | PCWP | |
| 4 | NESTED LOOPS ANTI | | 1 | 42 | 3 | | | Q1,01 | PCWP | |
| 5 | NESTED LOOPS | | 1 | 28 | 3 | | | Q1,01 | PCWP | |
| 6 | BUFFER SORT | | | | | | | Q1,01 | PCWC | |
| 7 | PX RECEIVE | | | | | | | Q1,01 | PCWP | |
| 8 | PX SEND BROADCAST | :TQ10000 | | | | | | | S->P | BROADCAST |
| 9 | TABLE ACCESS BY GLOBAL INDEX ROWID| LEA_AGREEMENT_DTL | 1 | 10 | 1 | 1 | 1 | | | |
| 10 | INDEX UNIQUE SCAN | LEA_AGREEMENT_DTL_UQ | 1 | | 1 | | | | | |
| 11 | PX BLOCK ITERATOR | | 1 | 18 | 2 | | | Q1,01 | PCWC | |
| 12 | TABLE ACCESS FULL | PDC_DISBURSAL_TXN_D | 1 | 18 | 2 | | | Q1,01 | PCWP | |
| 13 | INDEX RANGE SCAN | PDC_MULTIPLE_LOAN_TXN_DE | 1 | 14 | 1 | | | Q1,01 | PCWP | |
| 14 | TABLE ACCESS BY INDEX ROWID | PDC_DISBURSAL_TXN_H | 1 | 12 | 1 | | | Q1,01 | PCWP | |
| 15 | INDEX UNIQUE SCAN | PDC_DISBURSAL_TXN_H_PK_01 | 1 | | 1 | | | Q1,01 | PCWP | |
-----------------------------------------------------------------------------------------------------------------------------------------------------_

please try to use "noparallel hints" in your query.
R.Wang
http://www.oraclepoint.com

Similar Messages

Oracle11g RAC with partitioning and cross instance parallel query problem

I have set up a 300gb TPC-H database using a 4 node RAC environment (8 cpu per node, 16 GB memory, 2 GHz processors) the system is served by 2.5 terabytes of SSD for its IO subsystem managed by a combination of ASM and OCFS2.
When I run a large parallel query (number 9 in the TPCH query set) I get:
ORA-00600: internal error code, arguments [kxfrGraDistNum3],[65535],[4]
with all other arguments blank. There were some reports of this in version 9, but it was supposedly fixed. Has any one seen this behavior or have a work around?
Mike

Good Idea! Why didn't I think of that? Oh yea...I did. Unfortunately TMS CSI is an update only partner type CSI so I cannot submit a SR. The 600 lookup was how I found the old stuff, but it didn't have any 11g references. I hoped maybe someone in the community had encountered this and had a workaround. By the way, the querey looks like so:
select
nation,
o_year,
sum(amount) as sum_profit
from
select
n_name as nation,
extract(year from o_orderdate) as o_year,
l_extendedprice * (1 - l_discount) - ps_supplycost * l_quantity as amount
from
h_part,
h_supplier,
h_lineitem,
h_partsupp,
h_order,
h_nation
where
s_suppkey = l_suppkey
and ps_suppkey = l_suppkey
and ps_partkey = l_partkey
and p_partkey = l_partkey
and o_orderkey = l_orderkey
and s_nationkey = n_nationkey
and p_name like '%spring%'
) as profit
group by
nation,
o_year
order by
nation,
o_year desc;
the other 21 queries, all using the same tables and degrees of paralell and cross instance settings, executed ok.
Mike

ORA-1555 with Parallel query problem

Hi
We are getting many ora-1555 errors with parallel query stuff. Few queries are throwing with hint /* Q98989129 NO_EXPAND INDEX or /* Q908231094 INDEX_RRS. Our applicaiton is like DSS kind with bulk loading and big reports. I have doubled the undo retention and undo size to 200G and set the trace event. But most of the queries are parallel queries. We are not using the following query in applicaiton. seems like it is parallel sub queries. I need to know the exact mechanism how to devide the parallel queries with its degree of parallalism.
SELECT /*+ Q277874009 INDEX_RRS(A1 "PK_TF_UTRAN_UCELL10_TAB") */ A1."TSTAMP" C0,A1."INSTANCE_ID" C1,A1."PMNOFOIRATHOM
ULTIGSMFAILURE" C2,A1."PMNOFOIRATHOCS57GSMFAIL" C3,A1."PMNOFOSPEECHGSMFAILURE" C
4,A1."PMNOFOHOSTANDGSMFAILURE" C5 FROM "FLEXPM"."ERC_TF_UTRAN_UCELL10_TAB" PX_G
RANULE(0, BLOCK_RANGE, DYNAMIC) A1 WHERE A1."TSTAMP"(+)<=TO_DATE('2006-09-25 23:
45:00', 'yyyy-mm-dd hh24:mi:ss')
Thanks

Hi,
probably the error is due to wrong execution plans choosen by the optimizer.
Are the table statistics up to date? Did You use parallel w/o and degree (ex. defining parallel on object using DEFAULT clause instead of a DEGREE)?
Normally, parallel execution can be done in 2 ways, considering the driving object:
1. like in previous versions, like 7.3, w/o partitioning, the object is split, by rowid, directly from the parallel coordinator to the query slaves (normally a number that can be equivalent to the degree of parallelism or the double in case of sort e/o joins).
2. considering a partitioned object, for every partition/subpartition (phisical segment), a query slaves is made in charge.
In both ways, the original session (SID) is the parallel coordinator that coordinates the salves executions.
The hints and statements that You've reported are tipical queries used by slave process.
In my experience, setting the PARALLEL degree to DEFAULT (no degree during CREATE or ALTER of the object after PARALLEL clause) will cause an "explosion" of slaves startup that can conduct to yr errors.
Hope this helps
Max

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

Problem in running parallel query

Hi All,
We have an Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 installed on Microsoft Windows 2000 Advanced Server 5.0.2195 Service Pack 4 Build 2195.
And we have a stored procedure which does lots of works.
In this procedure, there is a select statement which joins a huge table with milions of records(lets call it table X) to some other almost huge tables. This table X
is partitioned and parallel processing has been enabled on it. Every thing has been fine until a week ago. From then on, we are getting the following error in that procedure:
ORA-12801: error signaled in parallel query server P014
ORA-04030: out of process memory when trying to allocate 4194328 bytes (QERHJ hash-joi,QERHJ list array)
We have made some changes in that select statement which are very common changes like adding some additional where clauses and selecting some additional columns. The From List of select statement has not been changed.
I don't exactly know what is realy going on.
The available memory is about 2 GB when the mentioned procedure crashes.
Any Idea?
My Best,
Alireza Vali

Is it a 32bit installation (32bit Windows, 32bit Oracle) ?
What are your MEMORY_TARGET, SGA_TARGET, SGA_MAX_SIZE and PGA_AGGREGATE_TARGET parameters set to ? (If you have MEMORY_TARGET set, it is not necessary that the other parameters be set).
ORA-4030 relates to PGA memory, not SGA memory. But Oracle on Windows is a single, multi-threaded process. Therefore, all Oracle "processes" (threads in the Windows process) share the same memory (address) space, even the SGA and PGA.
Hemant K Chitale

Error on Parallel Query

Hi,
My application throws the following error when Iam processing a parallel query on my database. Can any one help me to resolve this.
ERROR at line 1:
ORA-29903: error in executing ODCIIndexFetch() routine
ORA-20000: Oracle Text error:
DRG-50857: oracle error in drekrgm (one piece lob read)
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old
Regards
Venkat

HI,
Thanks for the article. I read the article but my problem is getting addressed. I have enough disk space and rollback segments.
7 rollback segments (1 default 200 MB + 6 created for my executing wtih 1GB each ). All of them are auto extended 10M per block.
Apart from this I have a free space for 25 GB in the drive left out. Inspite of all of these. I am getting this error.
I am not able to understand the "DreKrgm" part.
Can you throw some light on this part.

Error signaled in parallel query server p005 DATE format comparison

Hello All,
I have a data like this.
{code}
j_id   s_id     b_id    lc   t_date                             my_val1     my_val2
100    200    300     prs   2013-07-17 16:01:47         myval1     myval2
100    200   300     prs    2013-07-17 16:01:47         myCval1   myCval2
{code}
When i am running a query like this
{code}
update my_tab b
        set my_col = 'X'
        where rowid <> ( select max(t.rowid) from my_tab t
                         where
                                t.J_ID        = b.J_ID   and
                                t.S_ID = b.S_ID and
                                t.B_ID      = b.B_ID and
                                t.LC   = b.LC
                              and TO_TIMESTAMP(trim(t.t_DATE), 'YYYY-MM-DD HH24:MI:SS.FF')
                               = TO_TIMESTAMP(trim(b.t_DATE), 'YYYY-MM-DD HH24:MI:SS.FF')
{code}
I know i have a DATE format but converting it into TIMESTAMP because my data is random and could contain the time stamp as well.
My concern here is when i run above update statement i get error
{code}
ORA-12801: error signaled in parallel query server P005
ORA-01862: the numeric value does not match the length of the format item
{code}
but when i do like below.. It runs fine. Not sure what i am missing here or doing something wrong. Please help.
{code}
select to_timestamp('2013-07-08 17:58:47', 'YYYY-MM-DD HH24:MI:SS.FF') from dual
where
to_timestamp('2013-07-08 17:58:47', 'YYYY-MM-DD HH24:MI:SS.FF') = to_timestamp('2013-07-08 17:58:47', 'YYYY-MM-DD HH24:MI:SS.FF')
{code}
Thanks!

user10647455 wrote:
Hello All,
I have a data like this.
{code}
j_id   s_id     b_id    lc   t_date                             my_val1     my_val2
100    200    300     prs   2013-07-17 16:01:47         myval1     myval2
100    200   300     prs    2013-07-17 16:01:47         myCval1   myCval2
{code}
When i am running a query like this
{code}
update my_tab b
        set my_col = 'X'
        where rowid <> ( select max(t.rowid) from my_tab t
                         where
                                t.J_ID        = b.J_ID   and
                                t.S_ID = b.S_ID and
                                t.B_ID      = b.B_ID and
                                t.LC   = b.LC
                              and TO_TIMESTAMP(trim(t.t_DATE), 'YYYY-MM-DD HH24:MI:SS.FF')
                               = TO_TIMESTAMP(trim(b.t_DATE), 'YYYY-MM-DD HH24:MI:SS.FF')
{code}
I know i have a DATE format but converting it into TIMESTAMP because my data is random and could contain the time stamp as well.
My concern here is when i run above update statement i get error
{code}
ORA-12801: error signaled in parallel query server P005
ORA-01862: the numeric value does not match the length of the format item
{code}
but when i do like below.. It runs fine. Not sure what i am missing here or doing something wrong. Please help.
{code}
select to_timestamp('2013-07-08 17:58:47', 'YYYY-MM-DD HH24:MI:SS.FF') from dual
where
to_timestamp('2013-07-08 17:58:47', 'YYYY-MM-DD HH24:MI:SS.FF') = to_timestamp('2013-07-08 17:58:47', 'YYYY-MM-DD HH24:MI:SS.FF')
{code}
Thanks!
If you have a date column, converting that to a timestamp isn't going to magically add more information to the date.
Date data types hold time information (not to the fractional precision like timestamps, but up to the second) ... if you are having a problem seeing that information, it's likely because of your NLS_DATE_FORMAT setting (whatever client you are using to view the data isn't showing you all of the information, but it's still there).
So basically, this boils down to your code not "making sense" at the moment
Cheers,

ORA-12801: error signaled in parallel query server P000

Hello All,
Week before one of the APPLY process ABORTED with following error:
ORA-12801: error signaled in parallel query server P000
ORA-04031: unable to allocate 104 bytes of shared memory ("streams pool","unknown object","apply shared t","knalfGetTxn:lcr")
We are using ORACLE 10.2.0.4.0 on HP unix B.11.23
For now, I have started the APPLY process again and it's working properly.
When I looked into the trace file it shows following
A001: [enq: TM - contention] name|mode=544d0002, object #=2a67, table/partition=0
*** 2009-06-15 10:53:57.897
A001: warning -- apply server 1, sid 302 waiting on user sid 267 for event (since 302 seconds):
A001: [enq: TM - contention] name|mode=544d0002, object #=2a67, table/partition=0
*** 2009-06-15 10:58:58.792
A001: warning -- apply server 1, sid 302 waiting on user sid 267 for event (since 603 seconds):
A001: [enq: TM - contention] name|mode=544d0002, object #=2a67, table/partition=0
*** 2009-06-15 12:14:36.679
A001: [enq: TX - row lock contention] name|mode=54580004, usn<<16 | slot=90028, sequence=1b743
*** 2009-06-15 12:19:36.961
A001: warning -- apply server 1, sid 302 waiting on user sid 181 for event (since 300 seconds):
A001: [enq: TX - row lock contention] name|mode=54580004, usn<<16 | slot=90028, sequence=1b743
*** 2009-06-15 12:24:37.417
A001: warning -- apply server 1, sid 302 waiting on user sid 181 for event (since 600 seconds):
A001: [enq: TX - row lock contention] name|mode=54580004, usn<<16 | slot=90028, sequence=1b743
*** 2009-06-15 12:29:37.906
A001: warning -- apply server 1, sid 302 waiting on user sid 181 for event (since 901 seconds):
A001: [enq: TX - row lock contention] name|mode=54580004, usn<<16 | slot=90028, sequence=1b743
*** 2009-06-15 12:34:37.428
A001: warning -- apply server 1, sid 302 waiting on user sid 181 for event (since 1201 seconds):
A001: [enq: TX - row lock contention] name|mode=54580004, usn<<16 | slot=90028, sequence=1b743
*** 2009-06-19 11:26:44.601
A001: [enq: TX - row lock contention] name|mode=54580006, usn<<16 | slot=8001e, sequence=1a4af
*** 2009-06-19 11:31:43.753
A001: warning -- apply server 1, sid 302 waiting on user sid 212 for event (since 300 seconds):
A001: [enq: TX - row lock contention] name|mode=54580006, usn<<16 | slot=8001e, sequence=1a4af
*** 2009-06-19 11:36:44.149
A001: warning -- apply server 1, sid 302 waiting on user sid 212 for event (since 600 seconds):
A001: [enq: TX - row lock contention] name|mode=54580006, usn<<16 | slot=8001e, sequence=1a4af
*** 2009-06-19 11:41:43.775
A001: warning -- apply server 1, sid 302 waiting on user sid 212 for event (since 900 seconds):
A001: [enq: TX - row lock contention] name|mode=54580006, usn<<16 | slot=8001e, sequence=1a4af
*** 2009-06-23 16:55:24.002
A001: [enq: TM - contention] name|mode=544d0004, object #=2c05, table/partition=0
*** 2009-06-29 09:48:58.166
A001: [enq: TM - contention] name|mode=544d0004, object #=2c05, table/partition=0
*** 2009-07-01 06:02:37.236
A001: [enq: TM - contention] name|mode=544d0004, object #=2c05, table/partition=0
*** 2009-07-01 11:46:43.672
error 12801 in STREAMS process
ORA-12801: error signaled in parallel query server P000
ORA-04031: unable to allocate 104 bytes of shared memory ("streams pool","unknown object","apply shared t","knalfGetTxn:lcr")
OPIRIP: Uncaught error 447. Error stack:
ORA-00447: fatal error in background process
ORA-12801: error signaled in parallel query server P000
ORA-04031: unable to allocate 104 bytes of shared memory ("streams pool","unknown object","apply shared t","knalfGetTxn:lcr")
Can you please help to provide details on that how i can fix this problem permanetely.
Any suggestions would be great!
Thanks,
Nick

It seems that you are using Oracle database and not Berkeley Database.
To fix ORA-04031 errors on streams pool, you need to increase streams pool size with
alter system set streams_pool_size=<the right value>;See recommandations in http://download.oracle.com/docs/cd/B19306_01/server.102/b14229/strms_mprep.htm#i1006278

Urgent, ORA-12801: error signaled in parallel query server P000

Hi Guys,
I am using Oracle 9i Enterprise Edition Release 9.2.0.1.0 with Windows 2000 Server.
I have just upgrade my database from 8i to 9i. I am facing this problem in a lot of queries in my application after upgrade. I tried to searched out but unable to find the reason yet.
Is there any parameter which i should /should not use? Or need to change any parameter.
Oracle Error Occured: ORA-12801: error signaled in parallel query server P000
Thanks in advance.
Brgs,
Hassan

Well, the error stack should be displayed along with the 12801 error.
If not, look the comment for the error I posted above: use event 10397 to display the actual error.ALTER SESSION SET EVENTS '10397 trace name context forever, level 1'; and if the error raises, then you'll get the source message, not the PQ message.
See note 21281.1 on Metalink.
Regards,
Yoann.

"ORA-12801: error signalled in parallel query server"

A client of ours is using our reporting tool, Impromptu 6, to report from an Oracle 8.1.6 database connecting with Net8. He has built a simple report which displays a single item from a single table but it fails with:-
Query Server Error
"ORA-12801: error signalled in parallel query server"
Error number -9:
DMS-E-GENERAL, A general exception has occurred during operation 'asynchronous open'.
According to Oracle documentation, there should be an accompanying error message with the ORA-12801 which gives more information.
The last few lines of the DMAUDFIL show:-
OCI OEXEC LINE 5219:orsgbl.C
OCI OEXEC LINE 5219:orsgbl.C
CHECK_CODE2 -12801 LINE 5249:orsgbl.C
OCI OERHMS -12801,ORA-12801: error signaled in parallel query server
LINE 858:orsmisc.C
The DMAPIFIL shows no error.
The query being sent to the database is:-
select T1."PRD_LVL_PARENT" "c1"
from "JDAOPRD"."PRDMSTEE" T1
where PRD_LVL_PARENT is defined as NUMBER(12)
If they paste the above into SQL*Plus, it works fine.
Reporting any other items from the database do not give this error.
If they use the Oracle ODBC driver, they don't get the problem but it runs a lot slower.

As your ORA-12801 is followed by a ORA-0600 this should be a database bug. First of all I'd bring the database on the last patchlevel (10.2.0.5), and if the error persists you can use the ORA-600/ORA-7445 Troubleshooter (Metalink Note 153788.1). If this doesn't help either you should log a SR with oracle support (you need a support contract to do all those steps).
Also I don't think forms 5 is certified against a 10gR2 database, so this might cause your trouble. For 6i you should use the latest patchset.
If you don't have a valid support contract you might have a chance in putting your query in a database procedure.
cheers

ORA-12801: error signaled in parallel query server P002

We are encountering the below problem frequently in SUN SOLARIS BOX
ORA-12801: error signaled in parallel query server P002
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP

Hi,
This is TEMP tablespace issue.
1. Identify the query(s) for which it is happening.
2. Size your TEMP tablespace by monitoring usage of it.
set lines 200
column osuser format A20
column tablespace format A20
SELECT b.tablespace, b.segfile#, b.segblk#, b.blocks, a.sid, a.serial#,
a.username, a.osuser, a.status
FROM v$session a,v$sort_usage b
WHERE a.saddr = b.session_addr
and a.osuser = nvl('&osuser',a.osuser)
ORDER BY b.tablespace, b.segfile#, b.segblk#, b.blocks;
3. Check all queries have required join conditions or not. Cartezian product of two huge tables creates problem.
Dilipkumar Patel.

Apply process is aborting with:ORA-12801: error signaled in parallel query

hi,
We created a queue of a specific type, capture and apply process on the queue. Then we started the queue capture and the apply process. The problem is that the apply process is getting enabled and with in moments going into aborted state. wea re getting the follwoing error:
ORA-12801: error signaled in parallel query server P000
ORA-00600: internal error code, arguments: [kwqiceval:anyconv], [], [], [], [], [], [], []
Any idea what could have gone wrong?
scripts:
exec dbms_aqadm.create_queue_table(queue_table=>'qt_anc',queue_payload_type=>'type_anc',multiple_consumers=> true, compatible => '9.0');
exec dbms_aqadm.create_queue (queue_name => 'q_anc',queue_table=>'qt_anc');
EXEC DBMS_AQADM.START_QUEUE (queue_name => 'q_anc');
DECLARE
emp_rule_name_dml VARCHAR2(300);
emp_rule_name_ddl VARCHAR2(300);
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'ops.t_anc',
streams_type => 'capture',
streams_name => 'capture_anc',
queue_name => 'strmadmin.q_anc',
include_dml => true,
include_ddl => false,
source_database => null,
dml_rule_name => emp_rule_name_dml,
ddl_rule_name => emp_rule_name_ddl);
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION(
rule_name => emp_rule_name_dml,
destination_queue_name => 'strmadmin.q_anc');
END;
DECLARE
emp_rule_name_dml VARCHAR2(300);
emp_rule_name_ddl VARCHAR2(300);
BEGIN
DBMS_STREAMS_ADM.ADD_TABLE_RULES(
table_name => 'ops.t_anc',
streams_type => 'apply',
streams_name => 'apply_anc',
queue_name => 'strmadmin.q_anc',
include_dml => true,
include_ddl => false,
source_database => null,
dml_rule_name => emp_rule_name_dml,
ddl_rule_name => emp_rule_name_ddl);
DBMS_APPLY_ADM.SET_ENQUEUE_DESTINATION(
rule_name => emp_rule_name_dml,
destination_queue_name => 'strmadmin.q_anc');
END;
BEGIN
DBMS_APPLY_ADM.START_APPLY(
apply_name => 'apply_anc');
END;
BEGIN
DBMS_CAPTURE_ADM.START_CAPTURE(
capture_name => 'capture_anc');
END;
/

Hello
The above configuration is never supported. The implicit capture expects the queue payload to be SYS.ANYDATA and same with implicit apply also.
However you can use Streams Messaging capability to achieve this. You need to wrap the messages with SYS.ANYDATA for this to work. The implicit capture uses a persistent logminer session to generate LCRs and it then wraps it with SYS.ANYDATA and enqueues into the capture queue, it then propagated to apply queue. You can generate LCRs and wrap it with SYS.ANYDATA and then enqueue into the capture queue then apply can recognise the messages.
Here is an example on creating LCRs (tested in 10g):
CREATE TABLE lcr_test (col1 NUMBER);
DECLARE
     l_lcr SYS.LCR$_ROW_RECORD;
BEGIN
     l_lcr :=
SYS.LCR$_ROW_RECORD.CONSTRUCT
     source_database_name=>SYS_CONTEXT('USERENV','DB_NAME'),
     command_type=>'INSERT',
     object_owner=>USER,
     object_name=>'LCR_TEST'
     l_lcr.ADD_COLUMN('new','col1',SYS.AnyData.ConvertNumber(99));
     l_lcr.EXECUTE(TRUE);
     COMMIT;
END;
SELECT * FROM lcr_test;
Converting to SYS.ANYDATA:
DECLARE
     l_lcr SYS.LCR$_ROW_RECORD;
     l_anydata SYS.ANYDATA;
BEGIN
     l_lcr :=
SYS.LCR$_ROW_RECORD.CONSTRUCT
     source_database_name=>SYS_CONTEXT('USERENV','DB_NAME'),
     command_type=>'INSERT',
     object_owner=>USER,
     object_name=>'LCR_TEST'
     l_lcr.ADD_COLUMN('new','col1',SYS.AnyData.ConvertNumber(99));
     l_anydata:=SYS.ANYDATA.ConvertObject(l_lcr);
     ENQ_PROC(l_anydata);
     COMMIT;
END;
Thanks,
Rijesh

ORA-12801 error signalled in parallel query with ORA-00018 max # session

Hello,
I've just run dbca to create a new database. On completion I received the following:
ORA-12801 error was signalled in parallel query server
ORA-00018 maximum number of sessions exceeded
ORA-06512 at sys_utl_recomp line 760
ORA-06512 as sys_utl_recomp line 773
ORA-06512 as sys_utl_recomp line 1
The processes are set at 100, sessions is set at 115?
Can you tell how to address this error and resolve the problem? I'm thinking that I should rerun sys_utl_recomp

Hi,
You didn't mention oracle version as well OS.
might be you hit a bug.
check the below link for reference
https://metalink2.oracle.com/metalink/plsql/f?p=130:14:8051847734518941130::::p14_database_id,p14_docid,p14_show_header,p14_show_help,p14_black_frame,p14_font:NOT,21564.1,1,1,1,helvetica
Regards,
Taj

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.

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

Parallel query problem

Similar Messages

Maybe you are looking for