Disabling parallel query?

Hi All,
I have a simple query
SELECT XXXX FROM <table> WHERE <conditions> GROUP BY XXXX;
When I look at the execution plan for this query, it uses Parallel Execution Servers even if I disabled it (DOP for this table is 1, no hint)
Does anyone have an idea?

set parallel_max_servers to 0.

Similar Messages

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

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.

Parallell query performance

Hi Experts,
I could not find any reference with regards to performance of parallel query when the SMT(simultaneous multi-thread) enabled on AIX. Could you please share your thoughts based on experience?

What are you asking to compare? The performance of parallel query on AIX vs the performance of a single-threaded query? The performance of parallel query on AIX with SMT enabled vs. the performance of parallel query on AIX with SMT disabled? Something else?
Realistically, any sort of discussion about performance will be highly dependent on the specifics of your query/ queries and the load characteristics of your system. It is entirely possible for parallel query to make a single-threaded query slower. It is entirely possible for parallel query to allow a single poorly-performing query to consume all the available resources on the system and to make every other session grind to a halt. It is entirely possible for parallel query to create large improvements in the performance of a query and of a system. Without knowing your queries, your workload, your system, your configuration, etc it is impossible to guess what would happen on your system. That is even more true when we're talking about tweaking operating system configuration knowing nothing about your database.
Justin

Turn off Parallel Query for instance

I have a new 10g RAC instance, on Windows 2003 64, which was just converted from 8i. It is currently a 1 node cluster. The database was built with parallelism turned on and now we are experiencing severe performance degradation. Quest spotlight keeps raising alarms regarding queries being forced to serialize. I have been told it would probably be better to turn parallelism off entirely (this is an OLTP instance). What parms and what settings do I need to set them to in order to shut of parallel query for the instance?

There must have been a specific reason why it was built as an RAC database
on a single node. Is it running 2 instances ?
If there's no reason to be running RAC on a single node, you could shut down
one instance.
PARALLEL_MAX_SERVERS determines the maximum number of ParallelQuery
processes (not PARALLEL_SERVER ! PARALLEL_SERVER what was for OPS).
Either
a) you really need Parallel Query Server processes for some user queries
and PARALLEL_MAX_SERVERS is too low (forcing serialisation of queries)
or
b) you should not be using ParallelQuery
b) is more likely for your OLTP environment.
Therefore, you could disable parallelism at table level or set
PARALLEL_MAX_SERVERS down to 0.

ORA-12801: error signaled in parallel query server

Hi all
What are the basic reasons of this error:
ORA-12801: error signaled in parallel query server
I have received this error while running report

>>>What are the basic reasons of this error:
ORA-12801: error signaled in parallel query server string
Cause: A parallel query server reached an exception condition.
Action: Check the following error message for the cause, and consult your error manual for the appropriate action.

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

Partitioning For Optimal Parallel Query Execution

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

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

Oracle 10g and parallel query question

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

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

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.

Parallel query in Oracle 11g

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

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

Oracle error-parallel query

Hi Experts,
While i'm running a parallel query through a procedure...
its throwing the below error.....
when others Error ORA-12801: error signaled in parallel query server P006
ORA-01114: IO error writing block to file (block # )
ORA-01114: IO error writing block to file 1025 (block # 2790848)
ORA-27063: number of byte with query
Can you people suggest me?
Thanks in advance!!!

You probably meant 11.2.0.3 instead of 11.2.3.0?
Did you (or your DBA) check the alert log?
What happens if you remove your WHEN OTHERS and rerun the code?
Do you get any additional information?

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 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,

Input Value long enough for date format ,Error in executing parallel query

Hi,
My Table: ANML( ID, STATUS,B_DATE,B_MONTH,B_YEAR, DEATH_DATE)
status 1 for alive and 2 for dead.
i wrote a view to get age.
as
create or relace view view1 as
select top."ID",top."STATUS",top."DOB",top."DEATH_DATE",top."ANML_AGE",top."DAYSDIFF",
CASE
WHEN anml_age < 1
THEN 'D'
ELSE 'M'
END age_unit,
CASE
WHEN anml_age < 1
THEN TO_CHAR (daysdiff || ' Day(s)')
WHEN anml_age < 12
THEN TO_CHAR (anml_age || ' Month(s)')
WHEN MOD (anml_age, 12) = 0
THEN TO_CHAR (ROUND (anml_age / 12, 0) || ' Year(s) '
ELSE TO_CHAR ( ROUND (anml_age / 12, 0)
|| ' Year(s) '
|| MOD (anml_age, 12)
|| ' Month(s)'
END age_string
from
(SELECT a.*,
CASE WHEN status IN ( 1)
THEN FLOOR(MONTHS_BETWEEN(TRUNC(SYSDATE),dob))
WHEN death_date IS NOT NULL AND status IN (2)
THEN FLOOR(MONTHS_BETWEEN(death_date,dob))
END anml_age,
CASE WHEN status IN (1)
THEN FLOOR(TRUNC(SYSDATE)-TRUNC(dob))
WHEN death_date IS NOT NULL AND status IN (2)
THEN FLOOR(TRUNC(death_date) - TRUNC(dob))
END daysdiff
from (
SELECTanml.id, status,
TO_DATE ( DECODE (b_date,
NULL, 1,
b_date
|| '-'
|| DECODE (b_month,
NULL, 1,
b_month
|| '-'
|| b_year,
'dd-mm-yyyy'
) DOB,
death_date
FROM anml
WHERE b_year IS NOT NULL
) a) top
when i tried to fetch all values from view its working fine.
But when i tried to fetch values based on condition like as follows,
select * from view1 where anml_age > 20 and anml_age<30
I am getting error like:
Input Value long enough for date format and Error in executing parallel query
Please tell me wht is wrong.

Here is your formatted code
create or relace view view1 as
select top."ID",top."STATUS",top."DOB",top."DEATH_DATE",top."ANML_AGE",top."DAYSDIFF",
CASE
WHEN anml_age < 1
THEN 'D'
ELSE 'M'
END age_unit,
CASE
WHEN anml_age < 1
THEN TO_CHAR (daysdiff || ' Day(s)')
WHEN anml_age < 12
THEN TO_CHAR (anml_age || ' Month(s)')
WHEN MOD (anml_age, 12) = 0
THEN TO_CHAR (ROUND (anml_age / 12, 0) || ' Year(s) '
ELSE TO_CHAR ( ROUND (anml_age / 12, 0)
|| ' Year(s) '
|| MOD (anml_age, 12)
|| ' Month(s)'
END age_string
from
(SELECT a.*,
CASE WHEN status IN ( 1)
THEN FLOOR(MONTHS_BETWEEN(TRUNC(SYSDATE),dob))
WHEN death_date IS NOT NULL AND status IN (2)
THEN FLOOR(MONTHS_BETWEEN(death_date,dob))
END anml_age,
CASE WHEN status IN (1)
THEN FLOOR(TRUNC(SYSDATE)-TRUNC(dob))
WHEN death_date IS NOT NULL AND status IN (2)
THEN FLOOR(TRUNC(death_date) - TRUNC(dob))
END daysdiff
from (
SELECTanml.id, status,
TO_DATE ( DECODE (b_date,
NULL, 1,
b_date
|| '-'
|| DECODE (b_month,
NULL, 1,
b_month
|| '-'
|| b_year,
'dd-mm-yyyy'
) DOB,
death_date
FROM anml
WHERE b_year IS NOT NULL
) a) top

Disabling parallel query?

Similar Messages

Maybe you are looking for