ORA-00907 in a simple query from dual

Hi,
Anybody knows the reason for obtain ora-00907 when we enclose between parenthesis a SQL sentence whith an orderby clause?. Look at the last example:
--> SQL fine
select 'A' zz from dual order by 1;
(select 'A' zz from dual) order by 1;
select * from (select 'A' zz from dual order by 1);
--> ORA-00907 Why?
(select 'A' zz from dual order by 1);
Regards
Carlos

you don't need order by in inlinew view
if you want order by use
select * from (select 'A' zz from dual ) order by 1;

Similar Messages

Query from DUAL

I am calling a Pl/sql function in a select query which has a statement as below
SELECT SUBSTR(5/2,2,1) INTO m_delim FROM DUAL;
The number of records returned from the calling select query is more 1 million.
How much adversly the query from DUAL table affects the performance of the select query?

user557052 wrote:
I am calling a Pl/sql function in a select query which has a statement as below
SELECT SUBSTR(5/2,2,1) INTO m_delim FROM DUAL;
The number of records returned from the calling select query is more 1 million.
How much adversly the query from DUAL table affects the performance of the select query?Even if you are selecting from dual, querying once would be enough based on your select statement.
It does not seem like it is varying, you are trying to find the delimiter, which can be done once.
Ss

Ora-6000 with a simple query

Hi,
I registered three XSD schemas, they were created by "trang" as you can read at:
XML schema register , tables and types.
After I corrected namespace and i added following options: storeVarrayAsTable="true", maintainDOM="false" and a defaultTable.
They were register successfull, and all tables was created either. I insert three little XMl files in the default table. Three rows were created (I try: select count(*))
Then I try this query:
Query:
select extract(object_value,'/') from mitablename;
but I got this error:
Error:
ORA-00600: código de error interno, argumentos: [kokax_oct_adtcbk5], [], [], [], [], [], [], []
If I try the same query in SQLdeveloper i get this:
http://img484.imageshack.us/img484/7017/ora00600lu7.jpg
I'm trying with oracle XE here at home.
Did anyone know anything about this error ?
thanks!
Message was edited by:
pollopolea

It is a long shot, but because of "XE", the ORA-0600, and maybe because you don't have a customer support id.; you could re-install XDB. This will invalidate all your schema based structures and repos. stuff (if dependend on the XDB schema). The XDB schema will be dropped be dropped during this excercise...so make a backup if needed !!!
For *nix OS systems the following could be done to re-install XDB - MAKE A FULL (RMAN) BACKUP of your DATABASE
conn / as sysdba
spool /tmp/reinstall.log
@?/rdbms/admin/catnoqm.sql
shutdown immediate
startup
@?/rdbms/admin/catqm.sql
spool off
No "mayor" errors should be notified in the spooled log file. If so re-try once to run catqm.sql
-- to enable HTTP agian
call dbms_xdb.setHTTPport(8080)
-- to enable FTP again
call dbms_xdb.setFTPport(2100)Message was edited by:
mgralike

Error ORA-00907 with query SDO_GEOM.SDO_DIFFERENCE

Hi,
I have following query:
SELECT SDO_GEOM.SDO_DIFFERENCE(
SDO_RELATE(square.geometry, SDO_GEOM.SDO_BUFFER(MDSYS.SDO_GEOMETRY(3001, 1, MDSYS.SDO_POINT_TYPE(424, 1272, 0) , NULL, NULL), 100, 0.05,'unit=m arc_tolerance=0.005'), 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE',
SDO_RELATE(square.geometry, SDO_GEOM.SDO_BUFFER(MDSYS.SDO_GEOMETRY(3001, 1, MDSYS.SDO_POINT_TYPE(276, 1274, 0) , NULL, NULL), 100, 0.05,'unit=m arc_tolerance=0.005'), 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE',
0.001
Always get the ora-00907: a bracket is missing-error.
Any help is really appreciated. Is there a error in the query?
Regards Ronald.

Hi Ronald,
try following:
SELECT SDO_GEOM.SDO_DIFFERENCE(
    SELECT square.geometry from square where
      SDO_RELATE (square.geometry, SDO_GEOM.SDO_BUFFER(
          MDSYS.SDO_GEOMETRY(
            3001, 1, MDSYS.SDO_POINT_TYPE(424, 1272, 0) , NULL, NULL
          ), 100, 0.05,'unit=m arc_tolerance=0.005'
        ), 'mask=ANYINTERACT querytype=WINDOW'
      ) = 'TRUE'
    SELECT square.geometry from square where
      SDO_RELATE (square.geometry, SDO_GEOM.SDO_BUFFER(
          MDSYS.SDO_GEOMETRY(
            3001, 1, MDSYS.SDO_POINT_TYPE(276, 1274, 0) , NULL, NULL
          ), 100, 0.05,'unit=m arc_tolerance=0.005'
        ), 'mask=ANYINTERACT querytype=WINDOW'
      ) = 'TRUE'
    0.001
FROM DUAL

ORA-27092 Error while executing any query from client

Hello
I am getting following error while executing any query from client remotly.
IAMDBA@TEST_OAT.ABCD > select userid from dual;
select userid from dual
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01116: error in opening database file 1
ORA-01110: data file 1: '/u01/prod/system/system01.dbf'
ORA-27092: size of file exceeds file size limit of the process
Additional information: 131071
Additional information: 286209
But while local connection,its working.

hi,
ulimit command- Limit user resources
su - oracle
ulimit -n (this command will show you the current value for ulimit the default value is 1024)
to increase its value:---
ulimit -n <some value> ( this command will change value for current session only)
example
ulimit -n 101062
once done check the value as:--
ulimit -n( for verification)
search in google for more explanation or revert back to me for any suggestions.... :)
Edited by: varun4dba on Jan 31, 2011 4:09 PM

Best design for Boolean function from simple query

Hello,
what is the most efficient, shorter, readable, simple way to make a boolean function that simply return true or false from a simple query that return 0 or 1 to n records?
Is this solution using a cursor's the best (working...):
   FUNCTION is_date_present (p_date IN DATE)
      RETURN BOOLEAN
   IS
      CURSOR chk_cursor
      IS
         SELECT COUNT (*)
           FROM target_dates
          WHERE target_date = p_date;
      nb   NUMBER := 0;
   BEGIN
      OPEN chk_cursor;
      FETCH chk_cursor
       INTO nb;
      CLOSE chk_cursor;
      IF nb >= 1
      THEN
         RETURN TRUE;
      ELSE
         RETURN FALSE;
      END IF;
   END;Performance, clarity and simplicity are important...
Thanks

Well, I prefer (not tested):
FUNCTION is_date_present (p_date IN DATE)
RETURN BOOLEAN
IS
nb NUMBER := 0;
BEGIN
SELECT COUNT (*)
INTO nb
FROM target_dates
WHERE target_date = p_date;
IF nb >= 1 THEN
RETURN TRUE;
LSE
RETURN FALSE;
IF;
END;Regards,
MiguelWhy count multiple records when you only care if you get at least 1 occurrence? Just wasted cycles.
FUNCTION is_date_present (p_date IN DATE)
RETURN BOOLEAN
IS
nb NUMBER := 0;
BEGIN
SELECT COUNT (*)
INTO nb
FROM DUAL
WHERE EXISTS
      SELECT NULL
      FROM target_dates
      WHERE target_date = p_date
IF nb >= 1 THEN
     RETURN TRUE;
ELSE
     RETURN FALSE;
END IF;
END;Or you could just add a ROWNUM = 1 on to yours, either way.

Query Issue with select level from dual

Hi,
I have a question regarding this query. The problem seems that when selecting level from dual while including another table the rows returned seem to increase exponentially.
I can add distinct and get the correct number of rows but am worried that this will cause a possible performance issue. Am I using the level option wrong?
I have included details below.
There are 4 rows in tbl_incidents
When I run the following queries I get rows returned based on the total number of rows
select start_date + level - 1, tbl_incidents.incident_id, level
from dual, tbl_incidents
where incident_id = 6
connect by level <= 1;
returns 1 row
select start_date + level - 1, tbl_incidents.incident_id, level
from dual, tbl_incidents
where incident_id = 6
connect by level <= 2;
returns 5 rows
select start_date + level - 1, tbl_incidents.incident_id, level
from dual, tbl_incidents
connect by level <= 3 and incident_id = 6;
returns 21 rows
select start_date + level - 1, tbl_incidents.incident_id, level
from dual, tbl_incidents
connect by level <= 4 and incident_id = 6;
returns 85 rows
select start_date + level - 1, tbl_incidents.incident_id, level
from dual, tbl_incidents
connect by level <= 5 and incident_id = 6;
returns 341 rows
So with
     r being the number of rows in tbl_incidents and
     l being the number used in the connect by for level and
     q being the number of rows returned by the query
     it appears that
q(l) = r * q(l-1) + 1
level 2:     4 * 1 + 1 = 5
level 3:     4 * 5 + 1 = 21
level 4:     4 * 21 + 1 = 85
level 5:     4 * 85 + 1 = 341
Thanks much,
Nora

Hi,
The dual table is used when you want to do something in SQL when you are not otherwise using a table.
Generating a "counter table" of the integers 1, 2, 3,..., X is an example
SELECT LEVEL   AS n
FROM    dual
WHERE   LEVEL   <= x;There is never any point in joining dual to another table, as in
select start_date + level - 1
,       tbl_incidents.incident_id
,       level
from    dual
,       tbl_incidents
where    incident_id = 6
connect by level <= x;You will always get the same more easily by just eliminating dual:
select start_date + level - 1
,       incident_id
,       level
from    tbl_incidents
where    incident_id = 6
connect by level <= x;It is quite useful and common to join a counter-table to a real table, like this cross-join:
WITH    counter_table AS
    SELECT LEVEL   AS n
    FROM    dual
    WHERE   LEVEL   <= x
select start_date + n - 1
,       incident_id
,       n
from    tbl_incidents
,       counter_table
where    incident_id = 6

Simple Query Failure? from 2 tables: pull First [DATE] Where [OIL] 0

I am a novice Access 2010 user, and I do not know how to write VBA code. I have written many queries, some built upon others and packaged them into macros, but that's about the extent of my experience, to date.
My problem. I built a query from 2 tables: [AC_PROPERTY] and [AC_PRODUCT]
I have linked the tables by PROPNUM. Designed the query to give me every PROPNUM in the db, then give me the 'First' [DATE] 'Where' [OIL] is >0.
When I run the query with 1 PROPNUM qualified, it works brilliant. Every case I check is working, on a one-PROPNUM-at-a-time basis. As soon as I remove the PROPNUM from criteria, so it will pull all PROPNUMs in the db, it appear to work -- that
is, until you check the data.
For some reason, it's not consistently picking the correct First date where Oil >0. I cannot figure out why it's working on some and not on others. I thought it was a date format problem, but haven't been able to determine or solve the issue.
I have always (historically) figured out my query problems, but this one has me stumped! Help!?
thank you :-)

I have linked the tables by PROPNUM. Designed the query to give me every PROPNUM in the db, then give me the 'First' [DATE] 'Where' [OIL] is >0.
The problem is that FIRST will not always give you the oldest date. Access uses FIRST to get the first record it finds, not the earliest date.
Use MIN to find oldest date.
Build a little, test a little

Limiting results from simple query

Hi all can you help.
WITH trt AS
(SELECT 7501 chart_id, 8 transaction_type from dual union all
SELECT 7501 chart_id, 44 transaction_type from dual union all
SELECT 12 chart_id, 44 transaction_type from dual
)select distinct chart_id from trt
where transaction_type IN (8,44)I have the above table, and would like to return only the chart_id which matches both IN transaction_types. i.e ONLY chart_id 7501
Thanks for your time
David

Christian Balz wrote:
Hello,
Try this,Maybe not..
SQL> WITH trt AS (SELECT 7501 chart_id, 8 transaction_type from dual union all
2               SELECT 7501 chart_id, 44 transaction_type from dual union all
3               SELECT   12 chart_id, 44 transaction_type from dual)
4 SELECT CHART_ID
5    FROM (SELECT CHART_ID,
6                 ROW_NUMBER() OVER(PARTITION BY CHART_ID ORDER BY CHART_ID) NUM
7            FROM TRT
8           WHERE TRANSACTION_TYPE IN (8, 44, 55))
9   WHERE NUM >= 2
10
SQL> /
CHART_ID
      7501
SQL> ed
Wrote file afiedt.buf
1 WITH trt AS (SELECT 7501 chart_id, 8 transaction_type from dual union all
2               SELECT 7501 chart_id, 44 transaction_type from dual union all
3               SELECT   12 chart_id, 44 transaction_type from dual)
4 SELECT CHART_ID
5    FROM (SELECT CHART_ID,
6                 ROW_NUMBER() OVER(PARTITION BY CHART_ID ORDER BY CHART_ID) NUM
7            FROM TRT
8           WHERE TRANSACTION_TYPE IN (44))
9* WHERE NUM >= 2
SQL> /
no rows selected
SQL>Both give results I wouldn't expect. The first should have given no rows and the second should have given both chart_id's

'Order By' in Exists / Not Exists condition causing ORA-00907 in Apex4.1.1

Hi Guys,
We have just upgraded from apex 3.2.1 to 4.1.1. on Oracle DB V11.2.0.1, while testing the apps in apex, I come across this problem.
When I have a page process that has a condition defined.
When Condition Type is Exists (SQL query returns at least one row) or Not Exists (SQL query returns no rows) and the Expression 1 is a query with an 'Order By' clause, e.g.
SELECT 123 FROM DUAL
ORDER BY 1
When the process is triggered, Apex 3.2.1 would evaluate the condition and run the process just fine, however Apex 4.1.1 would throw an error : ORA-00907: missing right parenthesis
I totally understand that an Order by clause in an Exists or Not Exists condition is unnecessary and agree that they shouldn't be there in the first place.
But unfortunately I am dealing with other developers codes and these conditions have been coded like these, probably from copy & paste codes.
Saying that, I also believe that an Apex upgrade should not stop anything that is working in previous releases without warning or provide a workaround, right?
I don't know if this affects other types of artifacts that can have a condition in apex when upgrading from 3.2.1, e.g Regions/Items/Computations/Validations etc.
Does anyone else get this behaviour? and is there an easy solution to fix these?
Ideally I don't want to go through all processes (and whatever other artifacts might be affected too) in all apps in all workspaces to check the condition type and remove the 'Order By' clause manually.
Thanks for any advises
Just did some more testing
'Computation' , 'Validations', 'Processes' and 'Branches' have the same problem, 3.2.1 takes 'Order By' fine in Exists/Not Exists condition, but 4.1.1 throws error.
'Regions', 'Buttons', 'Items' have consistent behaviour - both 3.2.1 and 4.1.1 throw error ORA-00907: missing right parenthesis, when page is rendered.
Edited by: Danny on 25/04/2012 20:07

Hi Danny,
that's interesting. I just had a look what happens when you use an EXISTS or NOT EXISTS condition type. The following final SQL statement will be generated with your above example. You can also see that if you run your application in debug mode.
select count(*) from sys.dual where exists (select 123 from dual order by 1)Executing that statement in SQL*Plus will also show the ORA-00907 error. It appears that the SQL parser doesn't allow an order by clause in an EXIST clause.
I wonder why this should have worked in previous versions, but I can only suspect that in the past we may just have executed
select 123 from dual order by 1which can be slightly slower because with the new EXISTS statement the SQL engine can stop processing earlier if it finds a record.
We try to be backward compatible as much as possible, but I doubt that we will change that back to the way it was before because of the performance penalty 99.9% of our customers would face.
Possible Workaround: You might be able to use the new "Application Search" to scan your application for "order by" and fix it for all hits where the attribute name is "Expression 1".
Regards
Patrick
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Twitter: http://www.twitter.com/patrickwolf

How to improve the query performance or tune query from Explain Plan

Hi
The following is my explain plan for sql query. (The plan is generated by Toad v9.7). How to fix the query?
SELECT STATEMENT ALL_ROWSCost: 4,160 Bytes: 25,296 Cardinality: 204
     8 NESTED LOOPS Cost: 3 Bytes: 54 Cardinality: 1
          5 NESTED LOOPS Cost: 2 Bytes: 23 Cardinality: 1
               2 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 13 Cardinality: 1
                    1 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               4 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_CUST_ACCOUNTS Cost: 1 Bytes: 10 Cardinality: 1
                    3 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_CUST_ACCOUNTS_U1 Cost: 1 Cardinality: 1
          7 TABLE ACCESS BY INDEX ROWID TABLE AR.HZ_PARTIES Cost: 1 Bytes: 31 Cardinality: 1
               6 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.HZ_PARTIES_U1 Cost: 1 Cardinality: 1
     10 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          9 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     15 NESTED LOOPS Cost: 2 Bytes: 29 Cardinality: 1
          12 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
               11 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
          14 TABLE ACCESS BY INDEX ROWID TABLE ONT.OE_ORDER_HEADERS_ALL Cost: 1 Bytes: 17 Cardinality: 1
               13 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Cardinality: 1
     21 FILTER
          16 TABLE ACCESS FULL TABLE ONT.OE_TRANSACTION_TYPES_TL Cost: 2 Bytes: 1,127 Cardinality: 49
          20 NESTED LOOPS Cost: 2 Bytes: 21 Cardinality: 1
               18 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
                    17 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
               19 INDEX RANGE SCAN INDEX (UNIQUE) ONT.OE_ORDER_HEADERS_U2 Cost: 1 Bytes: 9 Cardinality: 1
     23 TABLE ACCESS BY INDEX ROWID TABLE AR.RA_CUSTOMER_TRX_ALL Cost: 1 Bytes: 12 Cardinality: 1
          22 INDEX UNIQUE SCAN INDEX (UNIQUE) AR.RA_CUSTOMER_TRX_U1 Cost: 1 Cardinality: 1
     45 NESTED LOOPS Cost: 4,160 Bytes: 25,296 Cardinality: 204
          42 NESTED LOOPS Cost: 4,150 Bytes: 23,052 Cardinality: 204
               38 NESTED LOOPS Cost: 4,140 Bytes: 19,992 Cardinality: 204
                    34 NESTED LOOPS Cost: 4,094 Bytes: 75,850 Cardinality: 925
                         30 NESTED LOOPS Cost: 3,909 Bytes: 210,843 Cardinality: 3,699
                              26 PARTITION LIST ALL Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                   25 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_HEADERS Cost: 2,436 Bytes: 338,491 Cardinality: 14,717 Partition #: 29 Partitions accessed #1 - #18
                                        24 INDEX SKIP SCAN INDEX XLA.XLA_AE_HEADERS_N1 Cost: 264 Cardinality: 1,398,115 Partition #: 29 Partitions accessed #1 - #18
                              29 PARTITION LIST ITERATOR Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                   28 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_AE_LINES Cost: 1 Bytes: 34 Cardinality: 1 Partition #: 32
                                        27 INDEX RANGE SCAN INDEX (UNIQUE) XLA.XLA_AE_LINES_U1 Cost: 1 Cardinality: 1 Partition #: 32
                         33 PARTITION LIST ITERATOR Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                              32 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_DISTRIBUTION_LINKS Cost: 1 Bytes: 25 Cardinality: 1 Partition #: 35
                                   31 INDEX RANGE SCAN INDEX XLA.XLA_DISTRIBUTION_LINKS_N3 Cost: 1 Cardinality: 1 Partition #: 35
                    37 PARTITION LIST SINGLE Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 38
                         36 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_EVENTS Cost: 1 Bytes: 16 Cardinality: 1 Partition #: 39 Partitions accessed #2
                              35 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_EVENTS_U1 Cost: 1 Cardinality: 1 Partition #: 40 Partitions accessed #2
               41 PARTITION LIST SINGLE Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 41
                    40 TABLE ACCESS BY LOCAL INDEX ROWID TABLE XLA.XLA_TRANSACTION_ENTITIES Cost: 1 Bytes: 15 Cardinality: 1 Partition #: 42 Partitions accessed #2
                         39 INDEX UNIQUE SCAN INDEX (UNIQUE) XLA.XLA_TRANSACTION_ENTITIES_U1 Cost: 1 Cardinality: 1 Partition #: 43 Partitions accessed #2
          44 TABLE ACCESS BY INDEX ROWID TABLE GL.GL_CODE_COMBINATIONS Cost: 1 Bytes: 11 Cardinality: 1
               43 INDEX UNIQUE SCAN INDEX (UNIQUE) GL.GL_CODE_COMBINATIONS_U1 Cost: 1 Cardinality: 1

damorgan wrote:
Tuning is NOT about reducing the cost of i/o.
i/o is only one of many contributors to cost and only one of many contributors to waits.
Any time you would like to explore this further run this code:
SELECT 1 FROM dual
WHERE regexp_like(' ','^*[ ]*a');but not on a production box because you are going to experience an extreme tuning event with zero i/o.
And when I say "extreme" I mean "EXTREME!"
You've been warned.I think you just need a faster server.
SQL> set autotrace traceonly statistics
SQL> set timing on
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');
no rows selected
Elapsed: 00:00:00.00
Statistics
          1 recursive calls
          0 db block gets
          0 consistent gets
          0 physical reads
          0 redo size
        243 bytes sent via SQL*Net to client
        349 bytes received via SQL*Net from client
          1 SQL*Net roundtrips to/from client
          0 sorts (memory)
          0 sorts (disk)
          0 rows processedRepeated from an Oracle 10.2.0.x instance:
SQL> SELECT DISTINCT SID FROM V$MYSTAT;
       SID
       310
SQL> ALTER SESSION SET EVENTS '10053 TRACE NAME CONTEXT FOREVER, LEVEL 1';
Session altered.
SQL> select 1 from dual
2 where
3 regexp_like   (' ','^*[ ]*a');The session is hung. Wait a little while and connect to the database using a different session:
COLUMN STAT_NAME FORMAT A35 TRU
SET PAGESIZE 200
SELECT
STAT_NAME,
VALUE
FROM
V$SESS_TIME_MODEL
WHERE
SID=310;
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0Seems to be using a bit of time for the hard parse (hard parse elapsed time). Wait a little while, then re-execute the query:
STAT_NAME                                VALUE
DB time                                   9247
DB CPU                                    9247
background elapsed time                      0
background cpu time                          0
sequence load elapsed time                   0
parse time elapsed                        6374
hard parse elapsed time                   5997
sql execute elapsed time                  2939
connection management call elapsed        1660
failed parse elapsed time                    0
failed parse (out of shared memory)          0
hard parse (sharing criteria) elaps          0
hard parse (bind mismatch) elapsed           0
PL/SQL execution elapsed time               95
inbound PL/SQL rpc elapsed time              0
PL/SQL compilation elapsed time              0
Java execution elapsed time                  0
repeated bind elapsed time                  48
RMAN cpu time (backup/restore)               0The session is not reporting additional CPU usage or parse time.
Let's check one of the session's statistics:
SELECT
SS.VALUE
FROM
V$SESSTAT SS,
V$STATNAME SN
WHERE
SN.NAME='consistent gets'
AND SN.STATISTIC#=SS.STATISTIC#
AND SS.SID=310;
     VALUE
       163Not many consistent gets after 20+ minutes.
Let's take a look at the plan:
SQL> SELECT SQL_ID,CHILD_NUMBER FROM V$SQL WHERE SQL_TEXT LIKE 'select 1 from du
al%';
SQL_ID        CHILD_NUMBER
04mpgrzhsv72w            0
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('04mpgrzhsv72w',0,'TYPICAL'))
select 1 from dual where regexp_like   (' ','^*[ ]*a')
NOTE: cannot fetch plan for SQL_ID: 04mpgrzhsv72w, CHILD_NUMBER: 0
      Please verify value of SQL_ID and CHILD_NUMBER;
      It could also be that the plan is no longer in cursor cache (check v$sql_p
lan)No plan...
Let's take a look at the 10053 trace file:
Registered qb: SEL$1 0x19157f38 (PARSER)
signature (): qb_name=SEL$1 nbfros=1 flg=0
    fro(0): flg=4 objn=258 hint_alias="DUAL"@"SEL$1"
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
CBQT: Validity checks failed for 7uqx4guu04x3g.
CVM: Considering view merge in query block SEL$1 (#0)
CBQT: Validity checks failed for 7uqx4guu04x3g.
Subquery Unnest
SU: Considering subquery unnesting in query block SEL$1 (#0)
Set-Join Conversion (SJC)
SJC: Considering set-join conversion in SEL$1 (#0).
Predicate Move-Around (PM)
PM: Considering predicate move-around in SEL$1 (#0).
PM:   Checking validity of predicate move-around in SEL$1 (#0).
PM:     PM bypassed: Outer query contains no views.
FPD: Considering simple filter push in SEL$1 (#0)
FPD:   Current where clause predicates in SEL$1 (#0) :
          REGEXP_LIKE (' ','^*[ ]*a')
kkogcp: try to generate transitive predicate from check constraints for SEL$1 (#0)
predicates with check contraints: REGEXP_LIKE (' ','^*[ ]*a')
after transitive predicate generation: REGEXP_LIKE (' ','^*[ ]*a')
finally: REGEXP_LIKE (' ','^*[ ]*a')
apadrv-start: call(in-use=592, alloc=16344), compile(in-use=37448, alloc=42256)
kkoqbc-start
            : call(in-use=592, alloc=16344), compile(in-use=38336, alloc=42256)
kkoqbc-subheap (create addr=000000001915C238)Looks like the query never had a chance to start executing - it is still parsing after 20 minutes.
I am not sure that this is a good example - the query either executes very fast, or never has a chance to start executing. But, it might still make your point physical I/O is not always the problem when performance problems are experienced.
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

Passing Multiple Parameters values to a command- ORA-00907

I am trying to create a report in CR2008 using a SQL query against an Oracle 9i database. The field ( im."Report_No") I am using the parameter ({?CaseNo}) on is a VarChar, even though it only contains numbers. The number is 9 digits in the database (like 123456789), but is used differently by the users (12-456789) omitting the 3rd character. The query below works with a single value in the parameter, but returns ORA-00907 when multiple values are used.
SELECT im."Report_No"
--, ic."Report_No" Redundant from IM
, im."Reported_Date"
, im."Assignment"
, CASE
WHEN ip."Address" IS NOT NULL
THEN ip."Address"
WHEN ip."Address" IS NULL
AND ia."Address" IS NOT NULL
THEN ia."Address"
WHEN ip."Address" IS NULL
AND ia."Address" IS NULL
THEN im."Location"
END Address
, CASE
WHEN ip."City" IS NOT NULL
THEN ip."City"
WHEN ip."City" IS NULL
AND ia."City" IS NOT NULL
THEN ia."City"
WHEN ip."City" IS NULL
AND ia."City" IS NULL
THEN im."City"
END City
, CASE
WHEN ip."State" IS NOT NULL
THEN ip."State"
WHEN ip."State" IS NULL
AND ia."State" IS NOT NULL
THEN ia."State"
WHEN ip."State" IS NULL
AND ia."State" IS NULL
THEN 'NV'
END State
, CASE
WHEN ip."ZIP_Code" IS NOT NULL
THEN ip."ZIP_Code"
WHEN ip."ZIP_Code" IS NULL
AND ia."ZIP_Code" IS NOT NULL
THEN ia."ZIP_Code"
WHEN ip."ZIP_Code" IS NULL
AND ia."ZIP_Code" IS NULL
THEN im."ZIP_Code"
END Zip_Code
, ip."First_Name" || ' ' || ip."Last_Name" Name
, ip."Involvement"
FROM "TIBURON"."RP_INMAST_VIEW" im
INNER JOIN "TIBURON"."RP_INCASE_VIEW" ic
ON im."Report_No" = ic."Report_No"
INNER JOIN "TIBURON"."RP_INPER6_VIEW" ip
ON im."Report_No" = ip."Report_No"
LEFT OUTER JOIN "TIBURON"."RP_INADRS_VIEW" ia
ON ip."INPER6_ID" = ia."INPER6_ID"
WHERE im."Report_No" IN (substr({?CaseNo}, 1, 2))|| '0' || (substr({?CaseNo}, 4, 6))
AND ip."Involvement" = '{?InvCode}'
Thanks in advance for any help.
Edited by: James Cody on Dec 29, 2011 8:49 PM

Hi James,
Does the query accept commad separated values? Could you check if the query runs fine (with multiple values passed as a command separated string) on the database (using SQL+)?
-Abhilash

JDBC Lookup in PI 7.1 - SELECT ? FROM DUAL and Connection timed out

Hi,
We have a scenarios (Idoc to JMS) with JDBC lookup. We have used graphical JDBC lookup functionality.
We are reading country names for a given country code from SAP in an external database table. The query is so simple. That should not take much time
Now the actual issues is,
When we are executing the scenario, its taking quite a long time. Almost 6 minutes to excute a mapping. Which causing high performance issue in the Porduction.
We started the inviestigation about found some interesting stuff. Here we have used Willy Introscope for the investigation.
1. First few messages are taking quite a long time. LIke 6 minutes per messages. As i can see in the log i am getting below error in Willy,
I dont know why PI is executing below queury apart from real secelt query to fetch the country name. I am getting below error: Error Message: Backends|ABCD2 mydatabase01-1526 (Oracle DB)|SQL|Dynamic|Query|SELECT ? FROM DUAL: java.sql.SQLException: Io exception: Connection timed out
2. After couple of messages, interface works very normal. I mean rest of the messages works pretty fine.
Please let me know if you have any idea about this error. What could be the problem for the issue.
Thank you in advnace.
Best Regards,
Prasad.

Did you check how many SQL requests were executed per one message ? Do you have a log of these SQL requests ?
I assume that the country table is quite small, so that lookup should not be an issue.
About this:
>Message: Backends|ABCD2 mydatabase01-1526 (Oracle DB)|SQL|Dynamic|Query|SELECT ? FROM DUAL: >java.sql.SQLException: Io exception: Connection timed out
1. I only know SELECT * FROM DUAL, not SELECT ? FROM DUAL. Better use the former
2. the exception means that the database server can not be reached => check your network configuration
So I assume that there is a network (performance) problem between PI and this Oracle server. Or the Oracle Server is so overloaded that it has (sometimes) problems in processing new requests.
CSY
Edited by: Christian Sy on Mar 9, 2010 10:17 AM

Using DBMS_METADATA.GET_DDL get error: ORA-00907: missing right parenthesis

Hi,
I'm trying to extract schema DDL from a database (10.2.0.4.0 - 64bit Enterprise Edition on Solaris 10). I run the query below and get an ORA-00907: missing right parenthesis error.
SELECT DBMS_METADATA.GET_DDL( REPLACE(object_type,' ','_') AS object_type, object_name) FROM user_objects WHERE object_type NOT IN ('TABLE_PARTITION','INDEX_PARTITION','LOB');
This is the output when running the above in sqlplus worksheet
select DBMS_METADATA.GET_DDL( REPLACE(object_type,' ','_') as object_type, object_name) FROM user_objects where object_type not in ('TABLE_PARTITION','INDEX_PARTITION','LOB')
ERROR at line 1:
ORA-00907: missing right parenthesis
removing the where clause gives the following:
select DBMS_METADATA.GET_DDL( REPLACE(object_type,' ','_') as object_type, object_name) FROM user_objects
ERROR at line 1:
ORA-00907: missing right parenthesis
Any pointers would be gratefully received. I know I could get the DDL out using exp/imp but I want to understand why I'm getting the missing parenthesis error.
cheers,
Ewan

SELECT DBMS_METADATA.GET_DDL( REPLACE(object_type,' ','_') AS object_type, object_name) FROM user_objects WHERE object_type NOT IN You don't need an alias here. Get rid of " AS object_type" and it should work.

Simple Query working on 10G and not working on 11gR2 after upgrade

Hi Folks,
This is the first time i am posting the query in this Blog.
I have a small issue which preventing the UAT Sigoff.
Simple query working fine on 10.2.0.1 and after upgrade to 11.2.0.1 its error out
10.2.0.4:
=====
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=1;
COUNT(*)
1
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=00001;
COUNT(*)
1
SQL> select ATTRIBUTE1 FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=1;
ATTRIBUTE1
00001
11.2.0.1:
=====
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=1
ERROR at line 1:
ORA-01722: invalid number
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1=00001
ERROR at line 1:
ORA-01722: invalid number
SQL> select ATTRIBUTE1 FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1='1';
no rows selected
SQL> SELECT COUNT(*) FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1='00001';
COUNT(*)
1
SQL> select ATTRIBUTE1 FROM APPS.HZ_PARTIES HP WHERE ATTRIBUTE_CATEGORY= 'PROPERTY' AND ATTRIBUTE1='00001';
ATTRIBUTE1
00001
++++++++++++++++++++++++++++++++++++++++++++++
SQL > desc APPS.HZ_PARTIES
Name Type
======== ======
ATTRIBUTE1 VARCHAR2(150)
++++++++++++++++++++++++++++++++++++++++++++++
Changes:
Recently i upgraded the DB from 10.2.0.4 to 11.2.0.1
Query:
1.If the type of that row is VARCHAR,why it is working in 10.2.0.4 and why not working in 11.2.0.1
2.after upgrade i analyzed the table with "analyze table " query for all AP,AR,GL,HR,BEN,APPS Schemas--Is it got impact if we run analyze table.
Please provide me the answer for above two questions or refer the document is also well enough to understand.Based on the Answer client will sigoff to-day.
Thanks,
P Kumar

WhiteHat wrote:
the issue has already been identified: in oracle versions prior to 11, there was an implicit conversion of numbers to characters. your database has a character field which you are attempting to compare to a number.
i.e. the string '000001' is not in any way equivalent to the number 1. but Oracle 10 converts '000001' to a number because you are asking it to compare to the number you have provided.
version 11 doesn't do this anymore (and rightly so).
the issue is with the bad code design. you can either: use characters in the predicate (where field = 'parameter') or you can do a conversion of the field prior to comparing (where to_num(field) = parameter).
I would suggest that you should fix your code and don't assume that '000001' = 1I don't think that the above is completely correct, and a simple demonstration will show why. First, a simple table on Oracle Database 10.2.0.4:
CREATE TABLE T1(C1 VARCHAR2(20));
INSERT INTO T1 VALUES ('1');
INSERT INTO T1 VALUES ('0001');
COMMIT;A select from the above table, relying on implicit data type conversion:
SELECT
FROM
T1
WHERE
C1=1;
C1
1
0001Technically, the second row should not have been returned as an exact match. Why was it returned, let's take a look at the actual execution plan:
SELECT
FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
SQL_ID g6gvbpsgj1dvf, child number 0
SELECT   * FROM   T1 WHERE   C1=1
Plan hash value: 3617692013
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |       |       |     2 (100)|          |
|* 1 | TABLE ACCESS FULL| T1   |     2 |    24 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(TO_NUMBER("C1")=1)
Note
   - dynamic sampling used for this statementNotice that the VARCHAR2 column was converted to a NUMBER, so if there was any data in that column that could not be converted to a number (or NULL), we should receive an error (unless the bad rows are already removed due to another predicate in the WHERE clause). For example:
INSERT INTO T1 VALUES ('.0001.');
SELECT
FROM
T1
WHERE
C1=1;
SQL> SELECT
2    *
3 FROM
4    T1
5 WHERE
6    C1=1;
ERROR:
ORA-01722: invalid numberNow the same test on Oracle Database 11.1.0.7:
CREATE TABLE T1(C1 VARCHAR2(20));
INSERT INTO T1 VALUES ('1');
INSERT INTO T1 VALUES ('0001');
COMMIT;
SELECT
FROM
T1
WHERE
C1=1;
C1
1
0001
SELECT
FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL,NULL,NULL));
SQL_ID g6gvbpsgj1dvf, child number 0
SELECT   * FROM   T1 WHERE   C1=1
Plan hash value: 3617692013
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |       |       |     2 (100)|          |
|* 1 | TABLE ACCESS FULL| T1   |     2 |    24 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter(TO_NUMBER("C1")=1)
Note
   - dynamic sampling used for this statement
INSERT INTO T1 VALUES ('.0001.');
SELECT
FROM
T1
WHERE
C1=1;
SQL> SELECT
2    *
3 FROM
4    T1
5 WHERE
6    C1=1;
ERROR:
ORA-01722: invalid numberAs you can see, exactly the same actual execution plan, and the same end result.
The OP needs to determine if non-numeric data now exists in the column. Was the database characterset possibly changed during/after the upgrade?
Charles Hooper
Co-author of "Expert Oracle Practices: Oracle Database Administration from the Oak Table"
http://hoopercharles.wordpress.com/
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.

ORA-00907 in a simple query from dual

Similar Messages

Maybe you are looking for