SQL Query Plan BUG

Hi all I am looking at the Query plan of a store proc. I found a very strange situation:
There is an index seek of a table which DOES NOT query inside the SP..how does it happen~?
i search around the SP , no where I can find a word related to that table. (Actually the table and index is really there inside the database!!!! )
I am using SQL 2008 R2 SP2, Standard version.Help.

I this perhaps an INSERT statement? In that case, the target table might have a foreign key constraint that references another table so the plan includes a seek to enforce the constraint.
Dan Guzman, SQL Server MVP, http://www.dbdelta.com

Similar Messages

Sql Query Plan with ROWNUM

Oracle 10g:
I have a table with index, when I run that query on that index it's fine. I get into problem if I add ROWNUM in that query, query slows down from 1 sec to 30 sec. I don't know why. for eg:
select * from (select * from A where b = 1) where ROWNUM < 1000 becomes very slow:
Query Plan for select * from A where b = 1 (Query is just an example):
Rows     Plan
208912     SELECT STATEMENT
208912     SORT ORDER BY
208912     HASH JOIN RIGHT OUTER
408     INDEX FULL SCAN PK_BAD_ACK_TASK
208912     HASH JOIN RIGHT OUTER
16     INDEX FULL SCAN PK_INFORMATIONAL_TASK
208912     HASH JOIN RIGHT OUTER
1     INDEX FULL SCAN PK_SYSTEM_ERROR_TASK
208912     HASH JOIN RIGHT OUTER
1     INDEX FULL SCAN PK_REJECTED_TRANSMISSION
208912     HASH JOIN RIGHT OUTER
1     INDEX FULL SCAN PK_ONHOLD_TASK
208912     HASH JOIN RIGHT OUTER
329465     INDEX FAST FULL SCAN PK_FAILED_MESSAGE
208912     TABLE ACCESS FULL TASK
Query when I add ROWNUM (slow query as mentioned above):
Rows     Plan
999     SELECT STATEMENT
<NULL>     COUNT STOPKEY
208912     VIEW
208912     SORT ORDER BY STOPKEY
208912     HASH JOIN RIGHT OUTER
408     INDEX FULL SCAN PK_BAD_ACK_TASK
208912     NESTED LOOPS OUTER
208912     NESTED LOOPS OUTER
208912     NESTED LOOPS OUTER
208912     HASH JOIN RIGHT OUTER
329465     INDEX FAST FULL SCAN PK_FAILED_MESSAGE
208912     HASH JOIN RIGHT OUTER
16     INDEX FULL SCAN PK_INFORMATIONAL_TASK
208912     TABLE ACCESS FULL TASK
1     INDEX FAST FULL SCAN PK_ONHOLD_TASK
1     INDEX FAST FULL SCAN PK_REJECTED_TRANSMISSION
1     INDEX FAST FULL SCAN PK_SYSTEM_ERROR_TASK

user628400 wrote:
Oracle 10g:
I have a table with index, when I run that query on that index it's fine. I get into problem if I add ROWNUM in that query, query slows down from 1 sec to 30 sec. I don't know why. for eg:Some notes:
* When using ROWNUM the cost based optimizer switches to a FIRST_ROWS_N mode, this might explain the significant difference in the execution plan
* Try to get a more meaningful output using DBMS_XPLAN.DISPLAY
* Since you're already on 10g, try to compare the actual cardinalities to the estimates using DBMS_XPLAN.DISPLAY_CURSOR with the "ALLSTATS LAST" option and the GATHER_PLAN_STATISTICS hint.
See e.g. here for more information how to do it: http://jonathanlewis.wordpress.com/2006/11/09/dbms_xplan-in-10g/
This way you should be able to tell where the optimizer assumptions go wrong so that it thinks that the second one is better than the first one
A simple remedy you might want to try that should get you back to plan 1 is the following:
select * from (
select ROWNUM as rn, a.* from (select * from A where b = 1 ORDER BY<your_order_criteria>) a
where rn < 1000;Regards,
Randolf
Oracle related stuff blog:
http://oracle-randolf.blogspot.com/
SQLTools++ for Oracle (Open source Oracle GUI for Windows):
http://www.sqltools-plusplus.org:7676/
http://sourceforge.net/projects/sqlt-pp/
Edited by: Randolf Geist on Jan 11, 2009 9:33 PM
Added the obvious sort ORDER BY

Bad query plan for self-referencing CTE view query and variable in WHERE clause. Is there way out or this is SQL Server defect?

Please help. Thank you for your time and expertise.
Prerequisites: sql query needs to be a view. Real view is more than recursion. It computes location path, is used in JOINs and returns this path.
Problem: no matter what I tried, sql server does not produce 'index seek' when using variable but does with literal.
See full reproduction code below.
I expect that query SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID will seek UNIQUE index but it does not.
I tried these:
1. Changing UX and/or PK to be CLUSTERED.
2. query OPTION(RECOMPILE)
3. FORCESEEK on view
4. SQL Server 2012/2014
5. Wrap it into function and CROSS APPLY. On large outer number of rows this just dies, no solution
but to no avail. This smells like a bug in SQL Server. I am seeking your confirmation.
I am thinking it is a bug as variable value is high-cardinality, 1, and query is against unique key. This must produce single seek, depending if clustered or nonclustred index is unique
Thanks
Vladimir
use tempdb
BEGIN TRAN
-- setup definition
CREATE TABLE dbo.LocationHierarchy(
lcID int NOT NULL ,
lcHID hierarchyid NOT NULL,
lcCode nvarchar(25) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
lcHIDParent AS lcHID.GetAncestor(1) PERSISTED,
CONSTRAINT PK_LocationHierarchy_lcID PRIMARY KEY NONCLUSTERED (lcID ASC),
CONSTRAINT UX_LocationHierarchy_pltID_lcHID UNIQUE CLUSTERED (lcHID ASC)
-- add some data
INSERT INTO dbo.LocationHierarchy
VALUES
(1, '/', 'A')
,(2, '/1/', 'B')
,(3, '/1/1/', 'C')
,(4, '/1/1/1/', 'D')
--DROP VIEW dbo.vwLocationCodes
GO
CREATE VIEW dbo.vwLocationCodes
AS
WITH ru AS
SELECT
lh.lcID
,lh.lcCode
,lh.lcHID
,CAST('/' + lh.lcCode + '/' as varchar(8000)) as LocationPath
-- to support recursion
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
UNION ALL
SELECT
ru.lcID
,ru.lcCode
,ru.lcHID
,CAST('/' + lh.lcCode + ru.LocationPath as varchar(8000)) as LocationPath
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
JOIN ru ON ru.lcHIDParent = lh.lcHID
SELECT
lh.lcID
,lh.lcCode
,lh.LocationPath
,lh.lcHID
FROM ru lh
WHERE lh.lcHIDParent IS NULL
GO
-- get data via view
SELECT
CONCAT(SPACE(l.lcHID.GetLevel() * 4), lcCode) as LocationIndented
FROM dbo.vwLocationCodes l
ORDER BY lcHID
GO
SET SHOWPLAN_XML ON
GO
DECLARE @lcID int = 2
-- I believe this produces bad plan and is defect in SQL Server optimizer.
-- variable value cardinality is 1 and SQL Server should know that. Optiomal plan is to do index seek with key lookup.
-- This does not happen.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID -- bad plan
-- this is a plan I expect.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = 2 -- good plan
-- I reviewed these but I need a view here, can't be SP
-- http://sqlblogcasts.com/blogs/tonyrogerson/archive/2008/05/17/non-recursive-common-table-expressions-performance-sucks-1-cte-self-join-cte-sub-query-inline-expansion.aspx
-- http://social.msdn.microsoft.com/Forums/sqlserver/en-US/22d2d580-0ff8-4a9b-b0d0-e6a8345062df/issue-with-select-using-a-recursive-cte-and-parameterizing-the-query?forum=transactsql
GO
SET SHOWPLAN_XML OFF
GO
ROLLBACK
Vladimir Moldovanenko

Here is more... note that I am creating table Items and these can be in Locations.
I am trying LEFT JOIN and OUTER APLLY to 'bend' query into NESTED LOOP and SEEK. There has to be nested loop, 2 rows against 4. But SQL Server fails to generate optimal plan with SEEK. Even RECOMPILE does not help
use tempdb
BEGIN TRAN
-- setup definition
CREATE TABLE dbo.LocationHierarchy(
lcID int NOT NULL ,
lcHID hierarchyid NOT NULL,
lcCode nvarchar(25) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
lcHIDParent AS lcHID.GetAncestor(1) PERSISTED,
CONSTRAINT PK_LocationHierarchy_lcID PRIMARY KEY NONCLUSTERED (lcID ASC),
CONSTRAINT UX_LocationHierarchy_pltID_lcHID UNIQUE CLUSTERED (lcHID ASC)
-- add some data
INSERT INTO dbo.LocationHierarchy
VALUES
(1, '/', 'A')
,(2, '/1/', 'B')
,(3, '/1/1/', 'C')
,(4, '/1/1/1/', 'D')
--DROP VIEW dbo.vwLocationCodes
GO
--DECLARE @Count int = 10;
--WITH L0 AS (SELECT N FROM (VALUES(1),(1),(1),(1),(1),(1),(1),(1),(1),(1)) N (N))-- 10 rows
--,L1 AS (SELECT n1.N FROM L0 n1 CROSS JOIN L0 n2) -- 100 rows
--,L2 AS (SELECT n1.N FROM L1 n1 CROSS JOIN L1 n2) -- 10,000 rows
--,L3 AS (SELECT n1.N FROM L2 n1 CROSS JOIN L2 n2) -- 100,000,000 rows
--,x AS
-- SELECT TOP (ISNULL(@Count, 0))
-- ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) as Number
-- FROM L3 n1
--SELECT Number as itmID, NTILE(4)OVER(ORDER BY Number) as lcID
--INTO dbo.Items
--FROM x
----ORDER BY n1.N
--ALTER TABLE dbo.Items ALTER COLUMN itmID INT NOT NULL
--ALTER TABLE dbo.Items ADD CONSTRAINT PK PRIMARY KEY CLUSTERED (itmID)
CREATE TABLE dbo.Items (itmID int NOT NULL PRIMARY KEY, lcID int NOT NULL)
INSERT INTO dbo.items
VALUES(1, 1)
,(2, 3)
GO
CREATE VIEW dbo.vwLocationCodes
AS
WITH ru AS
SELECT
lh.lcID
,lh.lcCode
,lh.lcHID
,CAST('/' + lh.lcCode + '/' as varchar(8000)) as LocationPath
-- to support recursion
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
UNION ALL
SELECT
ru.lcID
,ru.lcCode
,ru.lcHID
,CAST('/' + lh.lcCode + ru.LocationPath as varchar(8000)) as LocationPath
,lh.lcHIDParent
FROM dbo.LocationHierarchy lh
JOIN ru ON ru.lcHIDParent = lh.lcHID
SELECT
lh.lcID
,lh.lcCode
,lh.LocationPath
,lh.lcHID
FROM ru lh
WHERE lh.lcHIDParent IS NULL
GO
-- get data via view
SELECT
CONCAT(SPACE(l.lcHID.GetLevel() * 4), lcCode) as LocationIndented
FROM dbo.vwLocationCodes l
ORDER BY lcHID
GO
--SET SHOWPLAN_XML ON
GO
DECLARE @lcID int = 2
-- I believe this produces bad plan and is defect in SQL Server optimizer.
-- variable value cardinality is 1 and SQL Server should know that. Optiomal plan is to do index seek with key lookup.
-- This does not happen.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = @lcID-- OPTION(RECOMPILE) -- bad plan
-- this is a plan I expect.
SELECT lcCode FROM dbo.vwLocationCodes l WHERE l.lcID = 2 -- good plan
SELECT *
FROM dbo.Items itm
LEFT JOIN dbo.vwLocationCodes l ON l.lcID = itm.lcID
OPTION(RECOMPILE)
SELECT *
FROM dbo.Items itm
OUTER APPLY
SELECT *
FROM dbo.vwLocationCodes l
WHERE l.lcID = itm.lcID
) l
-- I reviewed these but I need a view here, can't be SP
-- http://sqlblogcasts.com/blogs/tonyrogerson/archive/2008/05/17/non-recursive-common-table-expressions-performance-sucks-1-cte-self-join-cte-sub-query-inline-expansion.aspx
-- http://social.msdn.microsoft.com/Forums/sqlserver/en-US/22d2d580-0ff8-4a9b-b0d0-e6a8345062df/issue-with-select-using-a-recursive-cte-and-parameterizing-the-query?forum=transactsql
GO
--SET SHOWPLAN_XML OFF
GO
ROLLBACK
Vladimir Moldovanenko

SQL query with Bind variable with slower execution plan

I have a 'normal' sql select-insert statement (not using bind variable) and it yields the following execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=7 Card=1 Bytes=148)
1 0 HASH JOIN (Cost=7 Card=1 Bytes=148)
2 1 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=4 Card=1 Bytes=100)
3 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=3 Card=1)
4 1 INDEX (FAST FULL SCAN) OF 'TABLEB_IDX_003' (NON-UNIQUE)
(Cost=2 Card=135 Bytes=6480)
Statistics
0 recursive calls
18 db block gets
15558 consistent gets
47 physical reads
9896 redo size
423 bytes sent via SQL*Net to client
1095 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
I have the same query but instead running using bind variable (I test it with both oracle form and SQL*plus), it takes considerably longer with a different execution plan:-
Execution Plan
0 INSERT STATEMENT Optimizer=CHOOSE (Cost=407 Card=1 Bytes=148)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'TABLEA' (Cost=3 Card=1 Bytes=100)
2 1 NESTED LOOPS (Cost=407 Card=1 Bytes=148)
3 2 INDEX (FAST FULL SCAN) OF TABLEB_IDX_003' (NON-UNIQUE) (Cost=2 Card=135 Bytes=6480)
4 2 INDEX (RANGE SCAN) OF 'TABLEA_IDX_2' (NON-UNIQUE) (Cost=2 Card=1)
Statistics
0 recursive calls
12 db block gets
3003199 consistent gets
54 physical reads
9448 redo size
423 bytes sent via SQL*Net to client
1258 bytes received via SQL*Net from client
3 SQL*Net roundtrips to/from client
1 sorts (memory)
0 sorts (disk)
55 rows processed
TABLEA has around 3million record while TABLEB has 300 records. Is there anyway I can improve the speed of the sql query with bind variable? I have DBA Access to the database
Regards
Ivan

Many thanks for your reply.
I have run the statistic already for the both tableA and tableB as well all the indexes associated with both table (using dbms_stats, I am on 9i db ) but not the indexed columns.
for table I use:-
begin
dbms_stats.gather_table_stats(ownname=> 'IVAN', tabname=> 'TABLEA', partname=> NULL);
end;
for index I use:-
begin
dbms_stats.gather_index_stats(ownname=> 'IVAN', indname=> 'TABLEB_IDX_003', partname=> NULL);
end;
Is it possible to show me a sample of how to collect statisc for INDEX columns stats?
regards
Ivan

SQL 2012 SP1 - How to determine a query that causes Error 8623 in SQL Log: The query processor ran out of internal resources and could not produce a query plan. This is a rare event...

We are getting multiple 8623 Errors in SQL Log while running Vendor's software.
How can you catch which Query causes the error?
I tried to catch it using SQL Profiler Trace but it doesn't show which Query/Sp is the one causing an error.
I also tried to use Extended Event session to catch it, but it doesn't create any output either.
Error:
The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that
reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
Extended Event Session that I used;
CREATE EVENT SESSION
overly_complex_queries
ON SERVER
ADD EVENT sqlserver.error_reported
ACTION (sqlserver.sql_text, sqlserver.tsql_stack, sqlserver.database_id, sqlserver.username)
WHERE ([severity] = 16
AND [error_number] = 8623)
ADD TARGET package0.asynchronous_file_target
(SET filename = 'E:\SQLServer2012\MSSQL11.MSSQLSERVER\MSSQL\Log\XE\overly_complex_queries.xel' ,
metadatafile = 'E:\SQLServer2012\MSSQL11.MSSQLSERVER\MSSQL\Log\XE\overly_complex_queries.xem',
max_file_size = 10,
max_rollover_files = 5)
WITH (MAX_DISPATCH_LATENCY = 5SECONDS)
GO
-- Start the session
ALTER EVENT SESSION overly_complex_queries
ON SERVER STATE = START
GO
It creates only .xel file, but not .xem
Any help/advice is greatly appreciated

Hi VK_DBA,
According to your error message, about which query statement may fail with error message 8623, as other post, you can use trace flag 4102 & 4118 for overcoming this error. Another way is looking for queries with very long IN lists, a large number of
UNIONs, or a large number of nested sub-queries. These are the most common causes of this particular error message.
The error 8623 occurs when attempting to select records through a query with a large number of entries in the "IN" clause (> 10,000). For avoiding this error, I suggest that you could apply the latest Cumulative Updates media for SQL Server 2012 Service
Pack 1, then simplify the query. You may try divide and conquer approach to get part of the query working (as temp table) and then add extra joins / conditions. Or You could try to run the query using the hint option (force order), option (hash join), option
(merge join) with a plan guide.
For more information about error 8623, you can review the following article.
http://blogs.technet.com/b/mdegre/archive/2012/03/13/8623-the-query-processor-ran-out-of-internal-resources-and-could-not-produce-a-query-plan.aspx
Regards,
Sofiya Li
Sofiya Li
TechNet Community Support

How to setup a query plan in effective at any time for SP or SQL query?

I have a SP which include a group by SQL statement. It retrieve data from a couple of tables which are over 1G size,
When I run this SP at first time, it take more than 5 minutes to get the result. then I run it again and again, Finally, it become very quick, I can get the result within second.
Not sure why. I guess it is because of query plan.
How to make it running at first time to get result within second? How to force a better best query plan in effective at first time to run the query?
If the engine has better plan in memory, could it be lost at some point? because I have the complain from end user said some times it is fast, sometime it is very slow.
How to resolve this problem?

thanks, kevin. Here is the pesudo query( I modify table name as business rule from my company). you are right, mytab3 is a lookup table.
Select d.stock,i.description,c.categoryname,
Round(IsNull(Sum(d.qty),0),2) AS qty,
From mytab1 d,mytab2 s,invent i,mytab3 c
Where
d.stock != 'param1'
And d.id1 = s.id1    --id1: univarchar(11)
And i.code = c.code   --code:univarchar(2)
And d.stock = i.stock --stock: univarchar(12)
And i.code2 = d.code2 --code2: univarchar(2)
And d.code2 = 'param2'
And s.id2 = 'param3'   --id2: univarchar(6)
Group By c.categoryname,d.stock,i.description
Order By d.stock
here is the query plan when run this query:
The command completed with no results returned
QUERY PLAN FOR STATEMENT 1 (at line 1).
Executed in parallel by coordinating process and 4 worker processes.
    STEP 1
        The type of query is SELECT (into Worktable1).
        GROUP BY
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Evaluate Grouped SUM OR AVERAGE AGGREGATE.
        Executed in parallel by coordinating process and 4 worker processes.
        FROM TABLE
            mytab2
            s
        Nested iteration.
        Index : ind_mytab2 _id2
        Forward scan.
        Positioning by key.
        Keys are:
            id2 ASC
        Executed in parallel with a 4-way hash scan.
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab1
            d
        Nested iteration.
        Index : ind_det_inv
        Forward scan.
        Positioning by key.
        Keys are:
            id1 ASC
        Using I/O Size 16 Kbytes for index leaf pages.
        With LRU Buffer Replacement Strategy for index leaf pages.
        Using I/O Size 16 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            invent
            i
        Nested iteration.
        Using Clustered Index.
        Index : invent_pk
        Forward scan.
        Positioning by key.
        Keys are:
            stock ASC
            code2 ASC
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        FROM TABLE
            mytab3
            c
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 2 Kbytes for data pages.
        With LRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable1.
        Parallel work table merge.
    STEP 2
        The type of query is INSERT.
        The update mode is direct.
        Executed by coordinating process.
        Worktable2 created, in allpages locking mode, for ORDER BY.
        FROM TABLE
            Worktable1.
        Nested iteration.
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
        TO TABLE
            Worktable2.
    STEP 3
        The type of query is SELECT.
        Executed by coordinating process.
        This step involves sorting.
        FROM TABLE
            Worktable2.
        Using GETSORTED
        Table Scan.
        Forward scan.
        Positioning at start of table.
        Using I/O Size 8 Kbytes for data pages.
        With MRU Buffer Replacement Strategy for data pages.
Total estimated I/O cost for statement 1 (at line 1): 1409882.
The sort for Worktable2 is done in Serial

Can users see the query plan of a SQL query in Oracle?

Hi,
I wonder for a given sql query, after the system optimization, can I see the query plan in oracle? If yes, how to do that? thank you.
Xing

You can use explain plan in SQLPlus
SQL> explain plan for select * from user_tables;
Explained.
Elapsed: 00:00:01.63
SQL> select * from table(dbms_xplan.display());
PLAN_TABLE_OUTPUT
Plan hash value: 806004009
| Id | Operation                       | Name     | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|* 1 | HASH JOIN RIGHT OUTER          |          | 2014 | 1123K|   507   (6)| 00:00:07 |
|   2 |   TABLE ACCESS FULL             | SEG$     | 4809 |   206K|    34   (3)| 00:00:01 |
|* 3 |   HASH JOIN RIGHT OUTER         |          | 1697 |   873K|   472   (6)| 00:00:06 |
|   4 |    TABLE ACCESS FULL            | USER$    |    74 | 1036 |     3   (0)| 00:00:01 |
|* 5 |    HASH JOIN OUTER              |          | 1697 |   850K|   468   (6)| 00:00:06 |
|   6 |     NESTED LOOPS OUTER          |          | 1697 |   836K|   315   (6)| 00:00:04 |
|* 7 |      HASH JOIN                  |          | 1697 |   787K|   226   (8)| 00:00:03 |
|   8 |       TABLE ACCESS FULL         | TS$      |    13 |   221 |     5   (0)| 00:00:01 |
|   9 |       NESTED LOOPS              |          | 1697 |   759K|   221   (8)| 00:00:03 |
| 10 |        MERGE JOIN CARTESIAN     |          | 1697 |   599K|   162 (10)| 00:00:02 |
|* 11 |         HASH JOIN               |          |     1 |   326 |     1 (100)| 00:00:01 |
|* 12 |          FIXED TABLE FULL       | X$KSPPI |     1 |    55 |     0   (0)| 00:00:01 |
| 13 |          FIXED TABLE FULL       | X$KSPPCV |   100 | 27100 |     0   (0)| 00:00:01 |
| 14 |         BUFFER SORT             |          | 1697 | 61092 |   162 (10)| 00:00:02 |
|* 15 |          TABLE ACCESS FULL      | OBJ$     | 1697 | 61092 |   161 (10)| 00:00:02 |
|* 16 |        TABLE ACCESS CLUSTER     | TAB$     |     1 |    96 |     1   (0)| 00:00:01 |
|* 17 |         INDEX UNIQUE SCAN       | I_OBJ#   |     1 |       |     0   (0)| 00:00:01 |
| 18 |      TABLE ACCESS BY INDEX ROWID| OBJ$     |     1 |    30 |     1   (0)| 00:00:01 |
|* 19 |       INDEX UNIQUE SCAN         | I_OBJ1   |     1 |       |     0   (0)| 00:00:01 |
| 20 |     TABLE ACCESS FULL           | OBJ$     | 52728 |   411K|   151   (4)| 00:00:02 |
Predicate Information (identified by operation id):
   1 - access("T"."FILE#"="S"."FILE#"(+) AND "T"."BLOCK#"="S"."BLOCK#"(+) AND
              "T"."TS#"="S"."TS#"(+))
   3 - access("CX"."OWNER#"="CU"."USER#"(+))
   5 - access("T"."DATAOBJ#"="CX"."OBJ#"(+))
   7 - access("T"."TS#"="TS"."TS#")
11 - access("KSPPI"."INDX"="KSPPCV"."INDX")
12 - filter("KSPPI"."KSPPINM"='_dml_monitoring_enabled')
15 - filter("O"."OWNER#"=USERENV('SCHEMAID') AND BITAND("O"."FLAGS",128)=0)
16 - filter(BITAND("T"."PROPERTY",1)=0)
17 - access("O"."OBJ#"="T"."OBJ#")
19 - access("T"."BOBJ#"="CO"."OBJ#"(+))
42 rows selected.
Elapsed: 00:00:03.61
SQL> If your plan table does not exist, execute the script $ORACLE_HOME/RDBMS/ADMIN/utlxplan.sql to create the table.

Possible Bug? SQL query changing the Cursor Type from Scrollable to non Scrollable in a ResultSet

Hi all,
I've been beating my head against this for a few days now, and while
there is a workaround, I haven't found out what's causing this to
happen.
Every other SQL query except for this one particular query works fine
and returns a scrollable result set. That one query on the other hand,
returns a non-scrollable result set.
Here's the code which is calling the query:
sqlStatement = getSQLFromFile();
debug("SQL statment = " + sqlStatement);
stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
debug(sqlStatement);
rst = stmt.executeQuery(sqlStatement);
debug("The type is " + rst.getType());
rst.last();
For most queries, the output is "The type is 1004" - which means the
resultset is scrollable - as it should be.
For one particular query, the output is "The type is 1003" which means
that the result set is of type forward-only.
Of course, calling rst.last() fails in the second case.
If the difference between the queries was drastic, I might have
something to go on. I've tested this out with different size queries,
but the switch between having the type incorrectly changed is the
deletion of a 0x0a 0x0d on the first line.
I.E. this means the failing query reads :
"select
from........."
and the query which works reads
"select *
from........."
I've looked at the failing query in it's binary format, and that's the
only difference I can discern.
To further confuse things, there are other queries which have a
similar format - and which work.
I've read about a bug in Weblogic 5.1 SP9 which ignores the setting of
the Statement to return a ResultSet with a scrollable cursor, and
while this seems to be a bug, it doesn't seem the same bug at all -
besides, I'm using Weblogic 6.0 with SP1 on a W2K system.
Does anyone have any ideas as to what might be causing this? I'm
stumped..

Ryan D'Silva wrote:
Hi Joe,
I'm using the Oracle thin driver -
oracle.jdbc.driver.OracleDriver - version #8.1.6.0.0
and the DBMS is
"Oracle9i Enterprise Edition Release 9.2.0.2.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.2.0 - Production"
Does that help?Yes. Two things: TYou should probably upgrade the oracle thin
driver, by downloading the latest appropriate one from their site,
and make sure it's ahead of all weblogic jars in the classpath the
server builds for itself. Also, let's see how simple we can make the
problem. Would you please repeat the JDBC that demonstrated the problem,
in a small standalone java program that uses a direct thin driver connection,
getting weblogic out of the picture? (The problem does sound like
and oracle driver issue).
Joe
>
>
Thanks,
- ryan
You don't say what DBMS and what JDBC driver you're using for the pool.
That is likely to be the issue. Let me know.
Joe
Here's the code which is calling the query:
sqlStatement = getSQLFromFile();
debug("SQL statment = " + sqlStatement);
stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE,ResultSet.CONCUR_READ_ONLY);
debug(sqlStatement);
rst = stmt.executeQuery(sqlStatement);
debug("The type is " + rst.getType());
rst.last();
For most queries, the output is "The type is 1004" - which means the
resultset is scrollable - as it should be.
For one particular query, the output is "The type is 1003" which means
that the result set is of type forward-only.
Of course, calling rst.last() fails in the second case.
If the difference between the queries was drastic, I might have
something to go on. I've tested this out with different size queries,
but the switch between having the type incorrectly changed is the
deletion of a 0x0a 0x0d on the first line.
I.E. this means the failing query reads :
"select
from........."
and the query which works reads
"select *
from........."
I've looked at the failing query in it's binary format, and that's the
only difference I can discern.
To further confuse things, there are other queries which have a
similar format - and which work.
I've read about a bug in Weblogic 5.1 SP9 which ignores the setting of
the Statement to return a ResultSet with a scrollable cursor, and
while this seems to be a bug, it doesn't seem the same bug at all -
besides, I'm using Weblogic 6.0 with SP1 on a W2K system.
Does anyone have any ideas as to what might be causing this? I'm
stumped..

SQL Server Query Plan Generation take longer

Dear all,
We are dealing with a wired issue where queries on there first execution take approx 1 min to 2 mins to execute and later execution completes in less than a second,Can you please help us understand why sql server is taking longer time to generated the query
plan
Below is the result of files stats
Mohd Sufian www.sqlship.wordpress.com Please mark the post as Answered if it helped.

SYS.DM_OS_MEMORY_CLERKS
MEMORYCLERK_SQLOPTIMIZER 136 912
CACHESTORE_PHDR 1864 0
CACHESTORE_XMLDBTYPE 8 0
CACHESTORE_EVENTS 16 0
USERSTORE_OBJPERM 824 0
USERSTORE_TOKENPERM 840 968
MEMORYCLERK_SQLSTORENG 2736 4312
CACHESTORE_FULLTEXTSTOPLIST 32 0
MEMORYCLERK_XE 64 168
CACHESTORE_XPROC 72 0
OBJECTSTORE_SNI_PACKET 3336 112
CACHESTORE_BROKERRSB 8 0
OBJECTSTORE_SERVICE_BROKER 424 0
MEMORYCLERK_SQLSERVICEBROKERTR MEMORYCLERK_XE_BUFFER 0 0
MEMORYCLERK_SQLGENERAL 1608 4144
CACHESTORE_XMLDBATTRIBUTE 8 0
MEMORYCLERK_SQLHTTP 8 0
CACHESTORE_STACKFRAMES 0 16
MEMORYCLERK_SQLCONNECTIONPOOL 2440 0
CACHESTORE_XMLDBELEMENT 8 0
OBJECTSTORE_LOCK_MANAGER 24 0
MEMORYCLERK_SQLBUFFERPOOL 0 1688
MEMORYCLERK_SQLSOAP 0 0
MEMORYCLERK_TRACE_EVTNOTIF 0 0
CACHESTORE_OBJCP 6576 512
CACHESTORE_CONVPRI 64 0
MEMORYCLERK_QSRANGEPREFETCH 0 0
CACHESTORE_BROKERREADONLY 80 0
MEMORYCLERK_SQLCLRASSEMBLY 0 0
MEMORYCLERK_SOSNODE 8 16320
MEMORYCLERK_SQLQUERYPLAN 0 0
OBJECTSTORE_SECAUDIT_EVENT_BUFFER 16 0
CACHESTORE_SQLCP 22680 3544
OBJECTSTORE_LBSS 96 192
CACHESTORE_SYSTEMROWSET 1832 0
MEMORYCLERK_FULLTEXT 24 0
USERSTORE_SCHEMAMGR 2632 328
MEMORYCLERK_SQLQUERYCOMPILE 0 0
CACHESTORE_TEMPTABLES 16 0
CACHESTORE_BROKERTBLACS 200 0
CACHESTORE_BROKERTO 8 0
CACHESTORE_BROKERKEK 8 0
MEMORYCLERK_SQLXML 0 0
USERSTORE_SXC 64 0
MEMORYCLERK_SNI 240 32
MEMORYCLERK_FULLTEXT_SHMEM 0 0
CACHESTORE_BROKERUSERCERTLOOKUP 8 0
MEMORYCLERK_SQLSOAPSESSIONSTORE 0 0
MEMORYCLERK_HOST 16 0
MEMORYCLERK_SQLCLR 8 0
MEMORYCLERK_SQLXP 16 0
USERSTORE_DBMETADATA 1912 0
MEMORYCLERK_SQLUTILITIES 112 0
CACHESTORE_VIEWDEFINITIONS 16 0
MEMORYCLERK_SQLQUERYEXEC 80 0
sys.dm_os_performance_counters
object_name counter_name cntr_value
/> /> /> /> /> /> Buffer cache hit ratio 556
Buffer cache hit ratio base 612
Page lookups/sec 4054066
Free list stalls/sec 0
Free pages 483
Total pages 503088
Target pages 1710080
Database pages 494479
Reserved pages 0
Stolen pages 8126
Lazy writes/sec 0
Readahead pages/sec 378700
Page reads/sec 493985
Page writes/sec 2421
Checkpoint pages/sec 0
AWE lookup maps/sec 0
AWE stolen maps/sec 0
AWE write maps/sec 0
AWE unmap calls/sec 0
AWE unmap pages/sec 0
Page life expectancy 262
Cache Hit Ratio 0
Cache Hit Ratio Base 0
Cached Cursor Counts 0
Cursor Cache Use Counts/sec 0
Cursor Requests/sec 0
Active cursors 0
Cursor memory usage 0
Cursor worktable usage 0
Number of active cursor plans 0
Cache Hit Ratio 0
Cache Hit Ratio Base 0
Cached Cursor Counts 0
Cursor Cache Use Counts/sec 0
Cursor Requests/sec 0
Active cursors 0
Cursor memory usage 0
Cursor worktable usage 0
Number of active cursor plans 0
Cache Hit Ratio 0
Cache Hit Ratio Base 0
Cached Cursor Counts 0
Cursor Cache Use Counts/sec 0
Cursor Requests/sec 0
Active cursors 0
Cursor memory usage 0
Cursor worktable usage 0
Number of active cursor plans 0
Cache Hit Ratio 0
Cache Hit Ratio Base 0
Cached Cursor Counts 0
Cursor Cache Use Counts/sec 0
Cursor Requests/sec 0
Active cursors 0
Cursor memory usage 0
Cursor worktable usage 0
Number of active cursor plans 0
Cursor conversion rate 0
Async population count 0
Cursor flushes 0
Connection Memory (KB) 2864
Granted Workspace Memory (KB) 0
Lock Memory (KB) 7944
Lock Blocks Allocated 40550
Lock Owner Blocks Allocated 43550
Lock Blocks 10003
Lock Owner Blocks 10133
Maximum Workspace Memory (KB) 10280520
Memory Grants Outstanding 0
Memory Grants Pending 0
Optimizer Memory (KB) 1048
SQL Cache Memory (KB) 2080
Target Server Memory (KB) 13680640
Total Server Memory (KB) 4024704
Please mark the post as Answered if it helped.

Tool to find the execution plan of a SQL query

Hi,
I new to Oracle. I come from the SQL Server world.
I would like to know what tool(s) should I use to identify the execution plan for a SQL statement and to see if a query is missing indices.
Thanks,
Paul

Use SQL*PLUS.
SQL> select dummy from dual;
D
X
SQL> set autotrace on explain
SQL> r
1* select dummy from dual
D
X
Execution Plan
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=2 Card=1 Bytes=2)
   1    0   TABLE ACCESS (FULL) OF 'DUAL' (TABLE) (Cost=2 Card=1 Bytes
          =2)
SQL> set autot off
SQL> explain plan for select dummy from dual;
Explained.
SQL> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 1157671242
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |     1 |     2 |     2   (0)| 00:00:01 |
|   1 | TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |
8 rows selected.
SQL> disconnect
Disconnected from Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Data Mining options
SQL>

BUG IN JDEVELOPER !!! SQL QUERY

Hi JDev Forumers ;o)
I was wondering how I could accomplish to set my attribute labels and display the customized ones in a JSP page.
I would like to display employee numer instead of empno, how did you do this?
When i try to set the databse columns on entity level he's building the query wrongly in the view object it's a BIG BUG in JDeveloper!
He's building the SQL Query statement wrong:
This is my query statement of the employee view after i've set the database columns:
SELECT Emp.Employee Number AS EMPNO,
Emp.Employee Name AS ENAME,
Emp.JOB,
Emp.Manager AS MGR,
Emp.HIREDATE,
Emp.Salary AS SAL,
Emp.Commission AS COMM,
Emp.Department Number AS DEPTNO
FROM EMP Emp
it has to be the other way around!!
Nathalie Roman

Nathalie:
I didn't realize JDeveloper was a 'he'! I was able to change the attribute name from empno to Employee_Name in the attribute settings for the app module. I then built a BC4J application and when I run the JSP, the column is showing as 'Employee_Name'. Additionally, I was able to create a data tag in a JSP that refers to the attribute as such:
<jbo:ShowValue datasource="dsemp" dataitem="Employee_Number" ></jbo:ShowValue>
In both cases, the query is built correctly. Is this what you were trying to do? If so, please reply with your steps and I'll see if I can help further.
Thanks,
Lynn
null

Explain SQL Query execution plan: Oracle

Dear Masters,
Kindly help me to understand execution plan for an SQL statement. I have following SQL execution plan for a query in system. How should I interpret it. I thank You in advace for your guidance.
SELECT STATEMENT ( Estimated Costs = 1.372.413 , Estimated #Rows = 0 )
       5 NESTED LOOPS
         ( Estim. Costs = 1.372.413 , Estim. #Rows = 3.125 )
         Estim. CPU-Costs = 55.798.978.498 Estim. IO-Costs = 1.366.482
           2 TABLE ACCESS BY INDEX ROWID MSEG
             ( Estim. Costs = 1.326.343 , Estim. #Rows = 76.717 )
             Estim. CPU-Costs = 55.429.596.575 Estim. IO-Costs = 1.320.451
             Filter Predicates
               1 INDEX RANGE SCAN MSEG~R
                 ( Estim. Costs = 89.322 , Estim. #Rows = 60.069.500 )
                 Search Columns: 1
                 Estim. CPU-Costs = 2.946.739.229 Estim. IO-Costs = 89.009
                 Access Predicates
           4 TABLE ACCESS BY INDEX ROWID MKPF
             ( Estim. Costs = 1 , Estim. #Rows = 1 )
             Estim. CPU-Costs = 4.815 Estim. IO-Costs = 1
             Filter Predicates
               3 INDEX UNIQUE SCAN MKPF~0
                 Search Columns: 3
                 Estim. CPU-Costs = 3.229 Estim. IO-Costs = 0
                 Access Predicates

Hi Panjak,
Yeahh, there's a huge unperformatic SQL statment, what I can see from this acces plan is:
1 DBO decided to start the query on index R on MSEG, using only part of the index (only one column) with no good uniqueness, accessing disk IO-Costs for this (60mi records), and expecting many interactions (loops) in memory to filter, see CPU-Costs.
So with the parameters you gave to SQL, they start in a very bad way.
2 After that program will access the MSEG commanded by what was found on First step, also with a huge loading from DB and filtering (another where criteria on MSEG fields, not found on index R), reducing the result set to 76.717 rows.
3/4 With this, program goes direct to primary key index on MKPF with direct access (optimized access) and follow to access database table MKPF.
5 At last will "loop" the result sets from MSEG and MKPF, mixing the tuplas generating the final result set.
Do you want to share your SQL, the parameters you are sending and code which generate it with us?
Regards, Fernando Da Ró

SQL Query C# Using Execution Plan Cache Without SP

I have a situation where i am executing an SQL query thru c# code. I cannot use a stored procedure because the database is hosted by another company and i'm not allowed to create any new procedures. If i run my query on the sql mgmt studio the first time
is approx 3 secs then every query after that is instant. My query is looking for date ranges and accounts. So if i loop thru accounts each one takes approx 3 secs in my code. If i close the program and run it again the accounts that originally took 3 secs
now are instant in my code. So my conclusion was that it is using an execution plan that is cached. I cannot find how to make the execution plan run on non-stored procedure code. I have created a sqlcommand object with my queary and 3 params. I loop thru each
one keeping the same command object and only changing the 3 params. It seems that each version with the different params are getting cached in the execution plans so they are now fast for that particular query. My question is how can i get sql to not do this
by either loading the execution plan or by making sql think that my query is the same execution plan as the previous? I have found multiple questions on this that pertain to stored procedures but nothing i can find with direct text query code.
Bob;

I did the query running different accounts and different dates with instant results AFTER the very first query that took the expected 3 secs. I changed all 3 fields that i've got code for parameters for and it still remains instant in the mgmt studio but
still remains slow in my code. I'm providing a sample of the base query i'm using.
select i.Field1, i.Field2,
d.Field3 'Field3',
ip.Field4 'Field4',
k.Field5 'Field5'
from SampleDataTable1 i,
SampleDataTable2 k,
SampleDataTable3 ip,
SampleDataTable4 d
where i.Field1 = k.Field1 and i.Field4 = ip.Field4
i.FieldDate between '<fromdate>' and '<thrudate>'
and k.Field6 = <Account>
Obviously the field names have been altered because the database is not mine but other then the actual names it is accurate. It works it just takes too long in code as described in the initial post.
My params setup during the init for the connection and the command.
sqlCmd.Parameters.Add("@FromDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@ThruDate", SqlDbType.DateTime);
sqlCmd.Parameters.Add("@Account", SqlDbType.Decimal);
Each loop thru the code changes these 3 fields.
sqlCommand.Parameters["@FromDate"].Value = dtFrom;
sqlCommand.Parameters["@ThruDate"].Value = dtThru;
sqlCommand.Parameters["@Account"].Value = sAccountNumber;
SqlDataReader reader = sqlCommand.ExecuteReader();
while (reader.Read())
reader.Close();
One thing i have noticed is that the account field is decimal(20,0) and by default the init i'm using defaults to decimal(10) so i'm going to change the init to
sqlCmd.Parameters["@Account"].Precision = 20;
sqlCmd.Parameters["@Account"].Scale = 0;
I don't believe this would change anything but at this point i'm ready to try anything to get the query running faster.
Bob;

Bug with readonly view (through sql query)

HI , I'm using JDEV11.1.1.2
I found the following problem which I consider a bug:
When you create a readonly view object based on sql query the first attribute gets type: VARCHAR2(255) although it is VARCHAR2(10) in the database. All other attributes get the correct type and length only the first one is not correct.
Can you confirm this behavior to be a bug ?
Thanks
agruev

Hi,
of other string attributes show the correct length then this indeed sounds like a bug. However, a bug is a bug when it is getting filed.
Frank

Sql Query need to extract the Work Flow information from Hyperion Planning

Can Any one give me the sql query to extract the Work flow from Hyperion Planning in 11.1.2.1.
I can extract from the Hyperion Planning but it is not in required format again I need to do lot of formating. I need the information as per the flow structure is showing linke in one perticular planning unit in all coloumn format. Hence only sql query will help me to extract this kind of information. could any one provide the sql query to extract this kind of request.
Thanks in Advance.
Edited by: 987185 on Feb 9, 2013 10:57 PM

If you have a look at the data models in - http://www.oracle.com/technetwork/middleware/bi-foundation/epm-data-models-11121-354684.zip
There is the structure of the planning application tables, have a look at the HSP_PM_* tables
Alternatively you can look at extracting the information using LCM.
Cheers
John
http://john-goodwin.blogspot.com/

SQL Query Plan BUG

Similar Messages

Maybe you are looking for