Join hint ignored - very bad query plan results

I'm trying to get a query that's being generated by SSAS to perform acceptably. Because this query is (at least partially) generated by SSAS, I don't have complete control over the query text.
The problem - The query looks roughly like this:
select
-- a bunch of columns
from
T1 -- table with ~40,000,000 rows
inner loop join T2 on T2.t2id = T1.t2id -- table with ~16,000 rows
inner loop join T3 on T3.t3id = T1.t3id -- table with ~200,000 rows inner loop join T4 on T4.t4id = T1.t4id -- table with ~200,000 rows
left loop join T5 on T5.t3id = T1.t3id and T5.t6id = T4.t6id -- table with 0 rows
where
-- some uninteresting conditions
T1 is a Fact (or Measure) table, T2, T3 and T4 are Dimension tables, T5 and T6 are involved in the filtering of the query. Every row of T1 WILL match exactly one row in each of T1, T2 and T3.
You'll note that I've hinted all of the joins - according to the documentation, using join hints forces join order (which is consistent with the plan that's produced). There's no mention that join hints can be transparently ignored by the optimizer,
but that seems to be precisely what's happening.
In the plan that results, the join to T4 is done as a hash join, with T1*T2*T3 (40,000,000 rows) on the "top", so it ends up trying to build a hash table with 40,000,000 rows, resulting in very high tempdb activity and very poor performance (I
don't know how poor - I've never let it finish).
I can see part of the reason why it's making this join choice - the estimate of T1*T2*T3 is only 35,000 rows, even though T1 has 40,000,000 rows and the join will hit on every row.
Questions:
1. What can I do to the query or the database to improve the estimate on the join to T3?
2. What can I do to the query to force the optimizer to use a loop join like I asked?
Version is SQL Server 2008 R2 SP2 Developer Edition X64.
OS is Windows 2008 R2
Machine is dual-quad-hyper-threaded CPU with 96Gb of RAM and several Tb of disk spread over 8 spindles and SSDs.
I've seen this query perform well before - I've been tuning this query for going on 7 years now and I've never seen it perform this badly that I can recall. Not sure if it's something that's changed in SP2, or something about the distribution
of data in this particular database that's changed, but something's sure changed.
-cd Mark the best replies as answers!

That would indicate that there are no foreign-key constraints, or if they, they are not trusted. (Assuming here that there WHERE clause includes no filter on T1.)
That, or the statistics on T1 are giving a completely wrong estimates for the number of NULL values in t2id and t3id.
Erland Sommarskog, SQL Server MVP, [email protected]
Thanks, Erland.
There are foreign key constraints, but they're NOCHECK. I've tried creating and updating statistics on various columns of the tables involved - I'll re-check that I've got up to date statistics on all of the columns involved in these joins.
What about the join-hint being ignored? Is there anything I can do, or has something changed here recently? Interestingly, when I run this query from SSMS, I get loop-joins all around, but when SSAS runs the query, the one join always comes out
a hash join. Before I added the hints, all joins were hash joins - the hints worked on all joins but the one.
-cd Mark the best replies as answers!

Similar Messages

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

Very Slow Query with CTE inner join

I have 2 tables (heavily simplified here to show relevant columns):
CREATE TABLE tblCharge
(ChargeID int NOT NULL,
ParentChargeID int NULL,
ChargeName varchar(200) NULL)
CREATE TABLE tblChargeShare
(ChargeShareID int NOT NULL,
ChargeID int NOT NULL,
TotalAmount money NOT NULL,
TaxAmount money NULL,
DiscountAmount money NULL,
CustomerID int NOT NULL,
ChargeShareStatusID int NOT NULL)
I have a very basic View to Join them:
CREATE VIEW vwBASEChargeShareRelation as
Select c.ChargeID, ParentChargeID, s.CustomerID, s.TotalAmount, isnull(s.TaxAmount, 0) as TaxAmount, isnull(s.DiscountAmount, 0) as DiscountAmount
from tblCharge c inner join tblChargeShare s
on c.ChargeID = s.ChargeID Where s.ChargeShareStatusID < 3
GO
I then have a view containing a CTE to get the children of the Parent Charge:
ALTER VIEW [vwChargeShareSubCharges] AS
WITH RCTE AS
SELECT ParentChargeId, ChargeID, 1 AS Lvl, ISNULL(TotalAmount, 0) as TotalAmount, ISNULL(TaxAmount, 0) as TaxAmount,
ISNULL(DiscountAmount, 0) as DiscountAmount, CustomerID, ChargeID as MasterChargeID
FROM vwBASEChargeShareRelation Where ParentChargeID is NULL
UNION ALL
SELECT rh.ParentChargeID, rh.ChargeID, Lvl+1 AS Lvl, ISNULL(rh.TotalAmount, 0), ISNULL(rh.TaxAmount, 0), ISNULL(rh.DiscountAmount, 0) , rh.CustomerID
, rc.MasterChargeID
FROM vwBASEChargeShareRelation rh
INNER JOIN RCTE rc ON rh.PArentChargeID = rc.ChargeID and rh.CustomerID = rc.CustomerID
Select MasterChargeID as ChargeID, CustomerID, Sum(TotalAmount) as TotalCharged, Sum(TaxAmount) as TotalTax, Sum(DiscountAmount) as TotalDiscount
from RCTE
Group by MasterChargeID, CustomerID
GO
So far so good, I can query this view and get the total cost for a line item including all children.
The problem occurs when I join this table. The query:
Select t.* from vwChargeShareSubCharges t
inner join
tblChargeShare s
on t.CustomerID = s.CustomerID
and t.MasterChargeID = s.ChargeID
Where s.ChargeID = 1291094
Takes around 30 ms to return a result (tblCharge and Charge Share have around 3.5 million records).
But the query:
Select t.* from vwChargeShareSubCharges t
inner join
tblChargeShare s
on t.CustomerID = s.CustomerID
and t.MasterChargeID = s.ChargeID
Where InvoiceID = 1045854
Takes around 2 minutes to return a result - even though the only charge with that InvoiceID is the same charge as the one used in the previous query.
The same thing occurs if I do the join in the same query that the CTE is defined in.
I ran the execution plan for each query. The first (fast) query looks like this:
The second(slow) query looks like this:
I am at a loss, and my skills at decoding execution plans to resolve this are lacking.
I have separate indexes on tblCharge.ChargeID, tblCharge.ParentChargeID, tblChargeShare.ChargeID, tblChargeShare.InvoiceID, tblChargeShare.ChargeShareStatusID
Any ideas? Tested on SQL 2008R2 and SQL 2012

>> The database is linked [sic] to an established app and the column and table names can't be changed. <<
Link? That is a term from pointer chains and network databases, not SQL. I will guess that means the app came back in the old pre-RDBMS days and you are screwed.
>> I am not too worried about the money field [sic], this is used for money and money based calculations so the precision and rounding are acceptable at this level. <<
Field is a COBOL concept; columns are totally different. MONEY is how Sybase mimics the PICTURE clause that puts currency signs, commas, period, etc in a COBOL money field.
Using more than one operation (multiplication or division) on money columns will produce severe rounding errors. A simple way to visualize money arithmetic is to place a ROUND() function calls after
every operation. For example,
Amount = (Portion / total_amt) * gross_amt
can be rewritten using money arithmetic as:
Amount = ROUND(ROUND(Portion/total_amt, 4) *
gross_amt, 4)
Rounding to four decimal places might not seem an
issue, until the numbers you are using are greater
than 10,000.
BEGIN
DECLARE @gross_amt MONEY,
@total_amt MONEY,
@my_part MONEY,
@money_result MONEY,
@float_result FLOAT,
@all_floats FLOAT;
SET @gross_amt = 55294.72;
SET @total_amt = 7328.75;
SET @my_part = 1793.33;
SET @money_result = (@my_part / @total_amt) *
@gross_amt;
SET @float_result = (@my_part / @total_amt) *
@gross_amt;
SET @Retult3 = (CAST(@my_part AS FLOAT)
/ CAST( @total_amt AS FLOAT))
* CAST(FLOAT, @gross_amt AS FLOAT);
SELECT @money_result, @float_result, @all_floats;
END;
@money_result = 13525.09 -- incorrect
@float_result = 13525.0885 -- incorrect
@all_floats = 13530.5038673171 -- correct, with a -
5.42 error
>> The keys are ChargeID(int, identity) and ChargeShareID(int, identity). <<
Sorry, but IDENTITY is not relational and cannot be a key by definition. But it sure works just like a record number in your old COBOL file system.
>> .. these need to be int so that they are assigned by the database and unique. <<
No, the data type of a key is not determined by physical storage, but by logical design. IDENTITY is the number of a parking space in a garage; a VIN is how you identify the automobile.
>> What would you recommend I use as keys? <<
I do not know. I have no specs and without that, I cannot pull a Kabbalah number from the hardware. Your magic numbers can identify Squids, Automobile or Lady Gaga! I would ask the accounting department how they identify a charge.
>> Charge_Share_Status_ID links [sic] to another table which contains the name, formatting [sic] and other information [sic] or a charge share's status, so it is both an Id and a status. <<
More pointer chains! Formatting? Unh? In RDBMS, we use a tiered architecture. That means display formatting is in a presentation layer. A properly created table has cohesion – it does one and only one data element. A status is a state of being that applies
to an entity over a period time (think employment, marriage, etc. status if that is too abstract).
An identifier is based on the Law of Identity from formal logic “To be is to be something in particular” or “A is A” informally. There is no entity here! The Charge_Share_Status table should have the encoded values for a status and perhaps a description if
they are unclear. If the list of values is clear, short and static, then use a CHECK() constraint.
On a scale from 1 to 10, what color is your favorite letter of the alphabet? Yes, this is literally that silly and wrong.
>> I understand what a CTE is; is there a better way to sum all children for a parent hierarchy? <<
There are many ways to represent a tree or hierarchy in SQL. This is called an adjacency list model and it looks like this:
CREATE TABLE OrgChart
(emp_name CHAR(10) NOT NULL PRIMARY KEY,
boss_emp_name CHAR(10) REFERENCES OrgChart(emp_name),
salary_amt DECIMAL(6,2) DEFAULT 100.00 NOT NULL,
<< horrible cycle constraints >>);
OrgChart
emp_name boss_emp_name salary_amt
==============================
'Albert' NULL 1000.00
'Bert' 'Albert' 900.00
'Chuck' 'Albert' 900.00
'Donna' 'Chuck' 800.00
'Eddie' 'Chuck' 700.00
'Fred' 'Chuck' 600.00
This approach will wind up with really ugly code -- CTEs hiding recursive procedures, horrible cycle prevention code, etc. The root of your problem is not knowing that rows are not records, that SQL uses sets and trying to fake pointer chains with some
vague, magical non-relational "id".
This matches the way we did it in old file systems with pointer chains. Non-RDBMS programmers are comfortable with it because it looks familiar -- it looks like records and not rows.
Another way of representing trees is to show them as nested sets.
Since SQL is a set oriented language, this is a better model than the usual adjacency list approach you see in most text books. Let us define a simple OrgChart table like this.
CREATE TABLE OrgChart
(emp_name CHAR(10) NOT NULL PRIMARY KEY,
lft INTEGER NOT NULL UNIQUE CHECK (lft > 0),
rgt INTEGER NOT NULL UNIQUE CHECK (rgt > 1),
CONSTRAINT order_okay CHECK (lft < rgt));
OrgChart
emp_name lft rgt
======================
'Albert' 1 12
'Bert' 2 3
'Chuck' 4 11
'Donna' 5 6
'Eddie' 7 8
'Fred' 9 10
The (lft, rgt) pairs are like tags in a mark-up language, or parens in algebra, BEGIN-END blocks in Algol-family programming languages, etc. -- they bracket a sub-set. This is a set-oriented approach to trees in a set-oriented language.
The organizational chart would look like this as a directed graph:
Albert (1, 12)
Bert (2, 3) Chuck (4, 11)
/ | \
/ | \
/ | \
/ | \
Donna (5, 6) Eddie (7, 8) Fred (9, 10)
The adjacency list table is denormalized in several ways. We are modeling both the Personnel and the Organizational chart in one table. But for the sake of saving space, pretend that the names are job titles and that we have another table which describes the
Personnel that hold those positions.
Another problem with the adjacency list model is that the boss_emp_name and employee columns are the same kind of thing (i.e. identifiers of personnel), and therefore should be shown in only one column in a normalized table. To prove that this is not
normalized, assume that "Chuck" changes his name to "Charles"; you have to change his name in both columns and several places. The defining characteristic of a normalized table is that you have one fact, one place, one time.
The final problem is that the adjacency list model does not model subordination. Authority flows downhill in a hierarchy, but If I fire Chuck, I disconnect all of his subordinates from Albert. There are situations (i.e. water pipes) where this is true, but
that is not the expected situation in this case.
To show a tree as nested sets, replace the nodes with ovals, and then nest subordinate ovals inside each other. The root will be the largest oval and will contain every other node. The leaf nodes will be the innermost ovals with nothing else inside them
and the nesting will show the hierarchical relationship. The (lft, rgt) columns (I cannot use the reserved words LEFT and RIGHT in SQL) are what show the nesting. This is like XML, HTML or parentheses.
At this point, the boss_emp_name column is both redundant and denormalized, so it can be dropped. Also, note that the tree structure can be kept in one table and all the information about a node can be put in a second table and they can be joined on employee
number for queries.
To convert the graph into a nested sets model think of a little worm crawling along the tree. The worm starts at the top, the root, makes a complete trip around the tree. When he comes to a node, he puts a number in the cell on the side that he is visiting
and increments his counter. Each node will get two numbers, one of the right side and one for the left. Computer Science majors will recognize this as a modified preorder tree traversal algorithm. Finally, drop the unneeded OrgChart.boss_emp_name column
which used to represent the edges of a graph.
This has some predictable results that we can use for building queries. The root is always (left = 1, right = 2 * (SELECT COUNT(*) FROM TreeTable)); leaf nodes always have (left + 1 = right); subtrees are defined by the BETWEEN predicate; etc. Here are
two common queries which can be used to build others:
1. An employee and all their Supervisors, no matter how deep the tree.
SELECT O2.*
FROM OrgChart AS O1, OrgChart AS O2
WHERE O1.lft BETWEEN O2.lft AND O2.rgt
AND O1.emp_name = :in_emp_name;
2. The employee and all their subordinates. There is a nice symmetry here.
SELECT O1.*
FROM OrgChart AS O1, OrgChart AS O2
WHERE O1.lft BETWEEN O2.lft AND O2.rgt
AND O2.emp_name = :in_emp_name;
3. Add a GROUP BY and aggregate functions to these basic queries and you have hierarchical reports. For example, the total salaries which each employee controls:
SELECT O2.emp_name, SUM(S1.salary_amt)
FROM OrgChart AS O1, OrgChart AS O2,
Salaries AS S1
WHERE O1.lft BETWEEN O2.lft AND O2.rgt
AND S1.emp_name = O2.emp_name
GROUP BY O2.emp_name;
4. To find the level and the size of the subtree rooted at each emp_name, so you can print the tree as an indented listing.
SELECT O1.emp_name,
SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt
THEN O2.sale_amt ELSE 0.00 END) AS sale_amt_tot,
SUM(CASE WHEN O2.lft BETWEEN O1.lft AND O1.rgt
THEN 1 ELSE 0 END) AS subtree_size,
SUM(CASE WHEN O1.lft BETWEEN O2.lft AND O2.rgt
THEN 1 ELSE 0 END) AS lvl
FROM OrgChart AS O1, OrgChart AS O2
GROUP BY O1.emp_name;
5. The nested set model has an implied ordering of siblings which the adjacency list model does not. To insert a new node, G1, under part G. We can insert one node at a time like this:
BEGIN ATOMIC
DECLARE rightmost_spread INTEGER;
SET rightmost_spread
= (SELECT rgt
FROM Frammis
WHERE part = 'G');
UPDATE Frammis
SET lft = CASE WHEN lft > rightmost_spread
THEN lft + 2
ELSE lft END,
rgt = CASE WHEN rgt >= rightmost_spread
THEN rgt + 2
ELSE rgt END
WHERE rgt >= rightmost_spread;
INSERT INTO Frammis (part, lft, rgt)
VALUES ('G1', rightmost_spread, (rightmost_spread + 1));
COMMIT WORK;
END;
The idea is to spread the (lft, rgt) numbers after the youngest child of the parent, G in this case, over by two to make room for the new addition, G1. This procedure will add the new node to the rightmost child position, which helps to preserve the idea
of an age order among the siblings.
6. To convert a nested sets model into an adjacency list model:
SELECT B.emp_name AS boss_emp_name, E.emp_name
FROM OrgChart AS E
LEFT OUTER JOIN
OrgChart AS B
ON B.lft
= (SELECT MAX(lft)
FROM OrgChart AS S
WHERE E.lft > S.lft
AND E.lft < S.rgt);
7. To find the immediate parent of a node:
SELECT MAX(P2.lft), MIN(P2.rgt)
FROM Personnel AS P1, Personnel AS P2
WHERE P1.lft BETWEEN P2.lft AND P2.rgt
AND P1.emp_name = @my_emp_name;
I have a book on TREES & HIERARCHIES IN SQL which you can get at Amazon.com right now. It has a lot of other programming idioms for nested sets, like levels, structural comparisons, re-arrangement procedures, etc.
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL

Error message: "Warning: unresponsive script". Afterward, the system freezes and will then crash. Crash reports have been submitted many, many times without response. I have tried the fore-mentioned solutions with either no results or very bad results

Error message: "Warning: unresponsive script". Afterward, the system freezes and will then crash. Crash reports have been submitted many, many times without response. I have tried the fore-mentioned solutions with either no results or very bad results which I filed a report but did not receive an answer. The application to block scripts actually worsened the problem and I could not correct the situation for a while (no response from Firefox, at all). I have also been through this procedure without any one contacting me, AT ALL.
== URL of affected sites ==
http://http://www.facebook.com (always) and www.YouTube.com (sometimes)

There does appear to be any support whatsoever from mighty "non caring" FIREFOX & people are getting fed up. We may as well try another system, if they can't be bothered to provide any support for their system, we can't be bothered to use their system.
Brianeng

Merge cartesian join in query plan

Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.

user8650395 wrote:
Hi All
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
W are using many GTT's in our code, the query plan have Merge Cartesain join showing cardinality as '1' which is incorrect, as GTT tables have many rows. Due to this query is taking ages to execute.
I am trying to sue dynamic sampling, but it doesn't seem to work.
please help on this.Interesting.
There was a a thread a day or two ago about when dynamic sampling does not work. You can search OTN for it if you like. Also check the docs to make sure that dynamic sampling works with GTTS
One problem with GTTS is getting accurate statistics. Have you considered using DBMS_STATISTICS to set the statistics on the table to adjust the cardinality?
Your cardinality of 1 sounds incorrect. In theory a cartesian join against one row should be painelss; unfortunately your cardinality figure seems to be off! Sometimes in cases like yours the cost-based optimizer will choose a Cartesian join even when the table joins are properly specified.

Conversion away from column type may result in sub-optimal query plan

Hello all,
I have the following select statement in a cursor compiled in a package.
SELECT id
FROM table
WHERE TRUNC(ts) >= TRUNC(SYSDATE - p_days)
However I get 4 warnings that read:
PLW-07204: conversion away from column type may result in sub-optimal query plan
Does anyone know of a way to rewrite the query to avoid the compilation warnings?
I'm just trying to compare the date without the time...
Thanks in advance
Dan

For what it is worth, whenever you compare a date column to either sysdate or any built-in function returning a date you will get that warning.
SQL> desc t
Name                                      Null?    Type
ID                                                 NUMBER
DT                                                 DATE
SQL> SELECT DUMP(dt), DUMP(trunc(dt)), dump(sysdate)
2 FROM t;
DUMP(DT)                            DUMP(TRUNC(DT))                  DUMP(SYSDATE)
Typ=12 Len=7: 120,107,7,12,15,16,43 Typ=13 Len=8: 7,215,7,12,0,0,0,0 Typ=13 Len=8: 7,215,7,12,14,16,11,0But,
SQL> CREATE FUNCTION f(p_v IN VARCHAR2) RETURN DATE AS
2 BEGIN
3     RETURN TO_DATE(p_v, 'dd-mon-yyyy');
4 END;
5 /
Function created.
SQL> SELECT DUMP(f('01-jan-2000')) FROM dual;
DUMP(F('01-JAN-2000'))
Typ=12 Len=7: 120,100,1,1,1,1,1John

6120 Camera Results (very bad)

hey... i've just bought 6120 Classic...
it takes pictures good in daylight but very bad in low light (even light behind the camera)... i see alot of green lines (noise) on screen n in the picture
it says on the lable underneath battery 'Nokia 6120 C1'... wht does that mean? should i claim the warranty? n further y 6120 has no update yet where as my brother has 5300 n he has updated it once...
please help me wid this problem... i'm very disappointed wid this kind of camera result... thanks!

Yes it's very bad in low light, it tries to make it brighter by pixelating the whole image by green and red pixels.
I think you mean Nokia 6120C-1?
It's the type of 6120c i think.
Like the N95, It has three types, N95-1 (Normal version), N95-2 (Black 8GB version) and N95-3 (the Amercian version).
Nokia N95
V 20.0.015
0546553

Query Plan Question for Outer Join

I have the following join query:
select unique ep.ACT_UID,
ep.SE_REQ_TS,
sr.SERVICE_NM
from
eaisvcs.Service_requests sr,
eaisvcs.SERVICE_EPISODE ep
where
ep.ACT_UID = sr.ACT_UID;
I have an index on the act_uid in both tables, and the statistics are up-to-date. There are about 3.2 million rows in each table. 10% of the act_uid's that are in the ep table that do not have a match in the sr table. Other than that, most id's match up between the tables.
Here is the query plan:
ID PARENT_ID OPERATION OPTIONS
0 SELECT STATEMENT
1 0 SORT UNIQUE
2 1 MERGE JOIN
3 2 SORT JOIN
4 3 TABLE ACCESS FULL
5 2 SORT JOIN
6 5 TABLE ACCESS FULL
I cannot figure out why a table scan is being performed every time on both tables. The Act_UID is the PK in the ep table. There is a composite index (act_uid, sev_seq_no) in the sr table. the act_id is a varchar2 column in both tables. The sev_seq_no column is numeric.
Any ideas or insights about this would be greatly appreciated.
Thanks!

The plan can be good.
Oracle choose a full table scan for these reason too:
- sr.SERVICE_NM is not a part of the index and so a full table scan is less expensive. If you will add this field to your composite index Oracle will probably take this new index.
Bye, Aron

IPhoto v9.3.2 = v9.4.2 I feel it unfair and unjustifiable to charge for an upgrade of a pre-installed iphoto programme. Please refer to the above version. This will result in payment on your very bad App Store of £10 Extremely unhappy loyal Mac user!

iPhoto v9.3.2 => v9.4.2
I feel it unfair and unjustifiable to charge for an upgrade of a pre-installed iphoto programme. Please refer to the above version.
This will result in payment on your very bad App Store of £10+
Extremely unhappy loyal Mac user!!!!!!

iPhoto v9.3.2 => v9.4.2
Thank you for your response but in App Store it shows a price of £10+ for this down load.
(This is a free update. Contact with Mac App Store support > http://www.apple.com/support/mac/app-store/contact)
Perhaps you are correct but this is not made clear in the update window of this App Store.

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

Query plan changes when query is used in CREATE TABLE AS

We've puzzled by the fact that EXPLAIN PLAN gives a much different output for a SELECT statement than it does when the same statement is used for CREATE TABLE . . . AS SELECT.
The bad part is that the CREATE TABLE version performs very badly, and that's what we want the query for.
Why does this happen? Is there a difference (from the database's point of view) between retrieving a set of rows to display to the user and putting that same set into a new table? Doesn't this make it harder to diagnose and fix query performance problems?
Here's our query:
create table query_test AS
select term, parentTerm, apidb.tab_to_string(cast(collect(trim(to_char(internal)))
                   as apidb.varchartab), ', ') as internal
             from (
                 select distinct ga.organism as term,
                                 ga.species as parentTerm,
                                 tn.taxon_id as internal
                 from apidb.GeneAttributes ga, SRES.TaxonName tn, sres.Taxon t,
                      dots.AaSequence aas, dots.SecondaryStructure ss
                 where ga.organism = tn.name
           and tn.taxon_id = t.taxon_id
                   and t.taxon_id = aas.taxon_id
   and aas.aa_sequence_id = ss.aa_sequence_id
           and t.rank != 'species'
           union
                 select distinct ga.species as term,
                   '' as parentTerm,
                                 ts.taxon_id as internal
                 from apidb.GeneAttributes ga, SRES.TaxonName tn, apidb.taxonSpecies ts,
                      dots.aasequence aas, dots.SecondaryStructure ss
                 where ga.organism = tn.name
                  and tn.taxon_id = ts.taxon_id
                  and ts.taxon_id = aas.taxon_id
                 and aas.aa_sequence_id = ss.aa_sequence_id
   group by term,parentTerm;Without the CREATE TABLE, the plan looks like this:
| Id | Operation                             | Name                      | Rows | Bytes |TempSpc| Cost (%CPU)| Time     |
|   0 | CREATE TABLE STATEMENT                |                           | 2911 | 5986K|       | 18840   (1)| 00:03:47 |
|   1 | LOAD AS SELECT                       | QUERY_TEST                |       |       |       |            |          |
|   2 |   VIEW                                |                           | 2911 | 5986K|       | 18669   (1)| 00:03:45 |
|   3 |    SORT GROUP BY                      |                           | 2911 |   332K|       | 18660   (1)| 00:03:44 |
|   4 |     VIEW                              |                           | 2911 |   332K|       | 18659   (1)| 00:03:44 |
|   5 |      SORT UNIQUE                      |                           | 2911 |   292K|       | 18659   (6)| 00:03:44 |
|   6 |       UNION-ALL                       |                           |       |       |       |            |          |
|* 7 |        HASH JOIN                      |                           | 2907 |   292K| 2160K| 17762   (1)| 00:03:34 |
|   8 |         TABLE ACCESS FULL             | GENEATTRIBUTES10650       | 40957 | 1679K|       |   795   (1)| 00:00:10 |
|* 9 |         HASH JOIN                     |                           | 53794 | 3204K| 1552K| 16675   (1)| 00:03:21 |
|* 10 |          HASH JOIN                    |                           | 37802 | 1107K|       | 12326   (1)| 00:02:28 |
|* 11 |           HASH JOIN                   |                           | 37945 |   629K|       | 10874   (1)| 00:02:11 |
| 12 |            INDEX FAST FULL SCAN       | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|       |    33   (0)| 00:00:01 |
| 13 |            INDEX FAST FULL SCAN       | AASEQUENCEIMP_REVIX6      | 7886K|    82M|       | 10816   (1)| 00:02:10 |
|* 14 |           TABLE ACCESS FULL           | TAXON                     |   514K| 6530K|       | 1450   (1)| 00:00:18 |
| 15 |          TABLE ACCESS FULL            | TAXONNAME                 |   760K|    22M|       | 2721   (1)| 00:00:33 |
|* 16 |        HASH JOIN                      |                           |     4 |   380 |       |   886   (1)| 00:00:11 |
| 17 |         NESTED LOOPS                  |                           |   730 | 64970 |       |   852   (1)| 00:00:11 |
|* 18 |          HASH JOIN                    |                           |     1 |    78 |       |   847   (1)| 00:00:11 |
| 19 |           NESTED LOOPS                |                           |       |       |       |            |          |
| 20 |            NESTED LOOPS               |                           |    17 |   612 |       |    51   (0)| 00:00:01 |
| 21 |             TABLE ACCESS FULL         | TAXONSPECIES10646         |    12 |    60 |       |     3   (0)| 00:00:01 |
|* 22 |             INDEX RANGE SCAN          | TAXONNAME_IND01           |     1 |       |       |     2   (0)| 00:00:01 |
| 23 |            TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |       |     4   (0)| 00:00:01 |
| 24 |           TABLE ACCESS FULL           | GENEATTRIBUTES10650       | 40957 | 1679K|       |   795   (1)| 00:00:10 |
|* 25 |          INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |   768 | 8448 |       |     5   (0)| 00:00:01 |
| 26 |         INDEX FAST FULL SCAN          | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|       |    33   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   7 - access("GA"."ORGANISM"="TN"."NAME")
   9 - access("TN"."TAXON_ID"="T"."TAXON_ID")
10 - access("T"."TAXON_ID"="TAXON_ID")
11 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
14 - filter("T"."RANK"<>'species')
16 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
18 - access("GA"."ORGANISM"="TN"."NAME")
22 - access("TN"."TAXON_ID"="TS"."TAXON_ID")
25 - access("TS"."TAXON_ID"="TAXON_ID")
46 rows selected.With the CREATE TABLE, the plan for the SELECT alone looks like this:
| Id | Operation                           | Name                      | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT                    |                           |     2 |   234 | 1786   (1)| 00:00:22 |
|   1 | SORT GROUP BY                      |                           |     2 |   234 | 1786   (1)| 00:00:22 |
|   2 |   VIEW                              |                           |     2 |   234 | 1785   (1)| 00:00:22 |
|   3 |    SORT UNIQUE                      |                           |     2 |   198 | 1785 (48)| 00:00:22 |
|   4 |     UNION-ALL                       |                           |       |       |            |          |
|* 5 |      HASH JOIN                      |                           |     1 |   103 |   949   (1)| 00:00:12 |
|   6 |       NESTED LOOPS                  |                           |   199 | 19303 |   915   (1)| 00:00:11 |
|   7 |        NESTED LOOPS                 |                           |    13 | 1118 |   850   (1)| 00:00:11 |
|   8 |         NESTED LOOPS                |                           |    13 |   949 |   824   (1)| 00:00:10 |
|   9 |          VIEW                       | VW_DTP_E387155E           |    13 |   546 |   797   (1)| 00:00:10 |
| 10 |           HASH UNIQUE               |                           |    13 |   546 |   797   (1)| 00:00:10 |
| 11 |            TABLE ACCESS FULL        | GENEATTRIBUTES10650       | 40957 | 1679K|   795   (1)| 00:00:10 |
| 12 |          TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |     3   (0)| 00:00:01 |
|* 13 |           INDEX RANGE SCAN          | TAXONNAME_IND02           |     1 |       |     2   (0)| 00:00:01 |
|* 14 |         TABLE ACCESS BY INDEX ROWID | TAXON                     |     1 |    13 |     2   (0)| 00:00:01 |
|* 15 |          INDEX UNIQUE SCAN          | PK_TAXON                  |     1 |       |     1   (0)| 00:00:01 |
|* 16 |        INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |    15 |   165 |     5   (0)| 00:00:01 |
| 17 |       INDEX FAST FULL SCAN          | SECONDARYSTRUCTURE_REVIX9 | 37945 |   222K|    33   (0)| 00:00:01 |
| 18 |      NESTED LOOPS                   |                           |     1 |    95 |   834   (1)| 00:00:11 |
| 19 |       NESTED LOOPS                  |                           |     1 |    89 |   833   (1)| 00:00:10 |
|* 20 |        HASH JOIN                    |                           |     1 |    78 |   828   (1)| 00:00:10 |
| 21 |         NESTED LOOPS                |                           |       |       |            |          |
| 22 |          NESTED LOOPS               |                           |    13 |   949 |   824   (1)| 00:00:10 |
| 23 |           VIEW                      | VW_DTP_2AAE9FCE           |    13 |   546 |   797   (1)| 00:00:10 |
| 24 |            HASH UNIQUE              |                           |    13 |   546 |   797   (1)| 00:00:10 |
| 25 |             TABLE ACCESS FULL       | GENEATTRIBUTES10650       | 40957 | 1679K|   795   (1)| 00:00:10 |
|* 26 |           INDEX RANGE SCAN          | TAXONNAME_IND02           |     1 |       |     2   (0)| 00:00:01 |
| 27 |          TABLE ACCESS BY INDEX ROWID| TAXONNAME                 |     1 |    31 |     3   (0)| 00:00:01 |
| 28 |         TABLE ACCESS FULL           | TAXONSPECIES10646         |    12 |    60 |     3   (0)| 00:00:01 |
|* 29 |        INDEX RANGE SCAN             | AASEQUENCEIMP_REVIX6      |   768 | 8448 |     5   (0)| 00:00:01 |
|* 30 |       INDEX RANGE SCAN              | SECONDARYSTRUCTURE_REVIX9 |     1 |     6 |     1   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   5 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
13 - access("ITEM_1"="TN"."NAME")
14 - filter("T"."RANK"<>'species')
15 - access("TN"."TAXON_ID"="T"."TAXON_ID")
16 - access("T"."TAXON_ID"="TAXON_ID")
20 - access("TN"."TAXON_ID"="TS"."TAXON_ID")
26 - access("ITEM_1"="TN"."NAME")
29 - access("TS"."TAXON_ID"="TAXON_ID")
30 - access("AA_SEQUENCE_ID"="SS"."AA_SEQUENCE_ID")
50 rows selected.Edited by: JohnI on Jul 18, 2011 2:19 PM
Edited by: JohnI on Jul 18, 2011 2:28 PM

Charles Hooper wrote a series of blog entries on a similar topic some time ago: http://hoopercharles.wordpress.com/2010/12/15/select-statement-is-fast-insert-into-using-the-select-statement-is-brutally-slow-1/ (including a lot of useful comments) and two following articles. I have to confess that I did not read the posts again - but I think you will find some good ideas how to analyze the problem.
Regards
Martin Preiss

SQL Server 2012 Physical vs. Hyper-V Same Query Different Results

I have a database that is on physical hardware (16 CPU's, 32GB Ram).
I have a copy of the database that was attached to a virtual Hyper-V server (16 CPU's, 32GB Ram).
Both Servers and SQL Servers are identical OS=2008R2 Standard, SQL Server 2012R2 Standard same patch level SP1 CU8.
Same query run on both servers return same data set, but the time is much different 26 Sec on Physical, 5 minutes on virtual.
Statistics are identical on both databases, query execution plane is identical on both queries.
Indices are identical on both databases.
When I use set statistics IO, I get different results between the two servers.
One table in particular (366k rows) on physical shows logical reads of 15400, on Hyper-V reports logical reads of 418,000,000 that is four hundred eighteen million for the same table.
When the query is run on the physical it uses no CPU, when run on the Hyper-V it takes 100% of all 16 processors.
I have experimented with Maxdop and it does exactly what it should by limiting processors but it doesn't fix the issue.

A massive difference in logical reads usually hints at differences in the query plan.
When you compare query plans, it is essential that you look at actual query plans.
Please note that if your server / Hyper-V supports parallelism (which is almost always nowadays), then you are likely to have two query plans: a parallel and a serial query plan. Of course the actual query plan will make clear which one is used in which
case.
To say this again, this is by far the most likely reason for your problem.
There are other (unlikely) reasons that could be the case here:
runaway parallel threads or other bugs in the optimizer or engine. Make sure you have installed the latest service pack
Maybe the slow server (Hyper-V) has extreme fragmentation in the relevant tables
As mentioned by Erland, you have much much more information about the query and query plan than we do. You already know whether or not parallelism is used, how many threads are being used in it, if you have no, one or several Loop Joins in the query (my
bet is on at least one, possibly more), etc. etc.
With the limited information you can share (or choose to share), involving PSS is probably your best course of action.
Gert-Jan

Question about bad query

Hi all ,
I have small question related to bad query .
what is the affecting happens to database if there is lot of bad query , i know the performance issue is there what's other things .like archive log generated database time , IO , TMP tablespace , please give me information about it's .
thanks & regards.

user11969912 wrote:
I have small question related to bad query . What do you consider a bad query? A bad query can be the result of poorly written and illogical SQL. It can be due to not using bind variables. It can be due to a on-optimal execution plan generated by the CBO. It can be due to poorly designed code that uses what seems to be a "good query", badly and in the wrong way (using bulk collection when a native SQL alone suffices, or hitting the very same data multiple times, etc).
what is the affecting happens to database if there is lot of bad query Each of these have a different impact on the database. A "bad query" can cause a snapshot-too-old error. A deadlock error. A shared pool memory allocation error. Can cause no error and simple increase I/O. Or increase CPU. Etc.
It is a lot more complex than what you seem to think, given your question.

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

Join hint ignored - very bad query plan results

Similar Messages

Maybe you are looking for