all groups > sql server programming > july 2005 >
You're in the

sql server programming

group:

Query Tuning.


Query Tuning. Sagar
7/30/2005 12:11:13 PM
sql server programming:
Hi,

I have the following query which takes 12- 15 seconds to return almost
900,000 rows. I would like the query to return in less than 4 seconds
(1-3). I have added indexes where needed but was not successful. I am
wondering if this query can be rewritten in anyway to respond in lesser
time. Well the question every one will ask is why are you returning so many
rows?. Thats something we cant do away at present but may be later we might.
The query and query plan are as follows:

SELECT cdp.SerialNumber, PB.ProductId , c.ClaimID, cd.ClaimDetailID, 'spif'
AS Program,
cdp.SerialNumber + '-PID-' + convert(varchar,PB.ProductId) As
SerialNumberProductId
FROM dbo.tblClaimDetailProduct cdp (NOLOCK)
INNER JOIN dbo.tblClaimDetailBundle cdb (NOLOCK)
ON cdp.ClaimDetailBundleID = cdb.ClaimDetailBundleID
AND cdb.ClaimDetailBundleStatusID = 1
INNER JOIN dbo.tblClaimDetail cd (NOLOCK)
ON cdb.ClaimDetailID = cd.ClaimDetailID
AND cd.ClaimDetailStatusID = 1
INNER JOIN dbo.tblClaim c (NOLOCK)
ON cd.ClaimID = c.ClaimID
AND c.ClaimStatusID IN (1, 2, 5, 6, 7, 8, 9, 10, 11,12,14)
INNER JOIn dbo.tblProductBundle PB (NOLOCK)
ON PB.ProductBundleId = cdp.ProductBundleId



|--Compute
Scalar(DEFINE:([Expr1006]=[cdp].[SerialNumber]+'-PID-'+Convert([PB].[ProductID])))
|--Hash Match(Inner Join, HASH:([c].[ClaimID])=([cd].[ClaimID]))
|--Index
Seek(OBJECT:([HPSpifCentral].[dbo].[tblClaim].[IX_tblClaim_1] AS [c]),
SEEK:([c].[ClaimStatusID]=1 OR [c].[ClaimStatusID]=2 OR
[c].[ClaimStatusID]=5 OR [c].[ClaimStatusID]=6 OR [c].[ClaimStatusID]=7 OR
[c].[ClaimStatusID]=8 OR [c].[Cla
|--Hash Match(Inner Join,
HASH:([cd].[ClaimDetailID])=([cdb].[ClaimDetailID]))
|--Index
Scan(OBJECT:([HPSpifCentral].[dbo].[tblClaimDetail].[IX_tblClaimDetail_CDCS]
AS [cd]), WHERE:([cd].[ClaimDetailStatusID]=1))
|--Hash Match(Inner Join,
HASH:([PB].[ProductBundleID])=([cdp].[ProductBundleID]))
|--Index
Scan(OBJECT:([HPSpifCentral].[dbo].[tblProductBundle].[IX_tblProductBundle8]
AS [PB]))
|--Merge Join(Inner Join,
MERGE:([cdb].[ClaimDetailBundleID])=([cdp].[ClaimDetailBundleID]),
RESIDUAL:([cdp].[ClaimDetailBundleID]=[cdb].[ClaimDetailBundleID]))
|--Index
Scan(OBJECT:([HPSpifCentral].[dbo].[tblClaimDetailBundle].[PK_tblClaimDetailBundle]
AS [cdb]), WHERE:([cdb].[ClaimDetailBundleStatusID]=1) ORDERED FORWARD)
|--Index
Scan(OBJECT:([HPSpifCentral].[dbo].[tblClaimDetailProduct].[IX_tblClaimDetailProduct_SNo]
AS [cdp]), ORDERED FORWARD)


I would be happy to provide the table schemas as well.

Any help is greatly appreciated.

Thanks

M

Re: Query Tuning. Mowgli
7/30/2005 12:44:13 PM
Do you have other queries that do return 900,000 rows in less than 4
seconds?
Re: Query Tuning. Sagar
7/30/2005 3:20:42 PM
Thanks for all your replies. I appreciate it. Well Here is the table schema:


if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimDetail_tblClaim]') and OBJECTPROPERTY(id,
N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimDetail] DROP CONSTRAINT
FK_tblClaimDetail_tblClaim
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimInvoice_tblClaim]') and OBJECTPROPERTY(id,
N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimInvoice] DROP CONSTRAINT
FK_tblClaimInvoice_tblClaim
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimNote_tblClaim]') and OBJECTPROPERTY(id,
N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimNote] DROP CONSTRAINT FK_tblClaimNote_tblClaim
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimStatusHistory_tblClaim]') and
OBJECTPROPERTY(id, N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimStatusHistory] DROP CONSTRAINT
FK_tblClaimStatusHistory_tblClaim
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblUserRequest_tblClaim]') and OBJECTPROPERTY(id,
N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblUserRequest] DROP CONSTRAINT
FK_tblUserRequest_tblClaim
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimDetailBundle_tblClaimDetail]') and
OBJECTPROPERTY(id, N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimDetailBundle] DROP CONSTRAINT
FK_tblClaimDetailBundle_tblClaimDetail
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimDetailProduct_tblClaimDetailBundle]') and
OBJECTPROPERTY(id, N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimDetailProduct] DROP CONSTRAINT
FK_tblClaimDetailProduct_tblClaimDetailBundle
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[FK_tblClaimDetailProduct_tblProductBundle]') and
OBJECTPROPERTY(id, N'IsForeignKey') = 1)
ALTER TABLE [dbo].[tblClaimDetailProduct] DROP CONSTRAINT
FK_tblClaimDetailProduct_tblProductBundle
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblClaim]') and OBJECTPROPERTY(id, N'IsUserTable') = 1)
drop table [dbo].[tblClaim]
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblClaimDetail]') and OBJECTPROPERTY(id, N'IsUserTable')
= 1)
drop table [dbo].[tblClaimDetail]
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblClaimDetailBundle]') and OBJECTPROPERTY(id,
N'IsUserTable') = 1)
drop table [dbo].[tblClaimDetailBundle]
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblClaimDetailProduct]') and OBJECTPROPERTY(id,
N'IsUserTable') = 1)
drop table [dbo].[tblClaimDetailProduct]
GO

if exists (select * from dbo.sysobjects where id =
object_id(N'[dbo].[tblProductBundle]') and OBJECTPROPERTY(id,
N'IsUserTable') = 1)
drop table [dbo].[tblProductBundle]
GO

CREATE TABLE [dbo].[tblClaim] (
[ClaimID] [int] IDENTITY (10000, 1) NOT NULL ,
[ClaimDate] [datetime] NOT NULL ,
[PromotionID] [int] NOT NULL ,
[UserID] [int] NOT NULL ,
[UserEmail] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[HistoricalOutletID] [int] NULL ,
[HistoricalCompanyID] [int] NULL ,
[ClaimStatusID] [int] NOT NULL ,
[ClaimStatusReason] [varchar] (255) COLLATE SQL_Latin1_General_CP1_CI_AS
NULL ,
[ClaimExpirationDate] [datetime] NULL ,
[FaxDate] [datetime] NULL ,
[FaxTime] [int] NULL ,
[PaymentTypeID] [int] NULL ,
[PaymentDate] [datetime] NULL ,
[PaymentNumber] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[PaymentAmount] [money] NULL ,
[ClaimSourceTypeID] [int] NULL ,
[BatchID] [int] NULL ,
[ExpiryEmailSentDate] [datetime] NULL ,
[FraudAuditStatusID] [int] NOT NULL ,
[InDepthAudit] [bit] NULL ,
[TicketId] [int] NULL ,
[InsertDate] [datetime] NOT NULL ,
[InsertUser] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
,
[UpdateDate] [datetime] NULL ,
[UpdateUser] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[RecordStatus] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[tblClaimDetail] (
[ClaimDetailID] [int] IDENTITY (1, 1) NOT NULL ,
[ClaimID] [int] NOT NULL ,
[BundleID] [int] NOT NULL ,
[ClaimInvoiceID] [int] NULL ,
[BenefitDescription] [varchar] (100) COLLATE SQL_Latin1_General_CP1_CI_AS
NOT NULL ,
[BenefitAmount] [money] NULL ,
[ClaimDetailStatusID] [int] NOT NULL ,
[InsertDate] [datetime] NOT NULL ,
[InsertUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[UpdateDate] [datetime] NULL ,
[UpdateUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[RecordStatus] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[tblClaimDetailBundle] (
[ClaimDetailBundleID] [int] IDENTITY (1, 1) NOT NULL ,
[ClaimDetailID] [int] NOT NULL ,
[BundleID] [int] NOT NULL ,
[ClaimDetailBundleStatusID] [int] NOT NULL ,
[DeniedReasonID] [int] NULL ,
[InsertDate] [datetime] NOT NULL ,
[InsertUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[UpdateDate] [datetime] NULL ,
[UpdateUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[RecordStatus] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[tblClaimDetailProduct] (
[ClaimDetailProductID] [int] IDENTITY (1, 1) NOT NULL ,
[ProductBundleID] [int] NOT NULL ,
[ClaimDetailBundleID] [int] NOT NULL ,
[SerialNumber] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[BenefitAmount] [money] NULL ,
[InsertDate] [datetime] NOT NULL ,
[InsertUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[UpdateDate] [datetime] NULL ,
[UpdateUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[RecordStatus] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[tblProductBundle] (
[ProductBundleID] [int] IDENTITY (1, 1) NOT NULL ,
[ProductID] [int] NULL ,
[ProductCode] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
,
[PCProductID] [int] NULL ,
[BundleID] [int] NOT NULL ,
[IsSNRequired] [bit] NOT NULL ,
[BenefitAmount] [money] NULL ,
[InsertDate] [datetime] NOT NULL ,
[InsertUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
[UpdateDate] [datetime] NULL ,
[UpdateUser] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL ,
[RecordStatus] [char] (1) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[tblClaim] WITH NOCHECK ADD
CONSTRAINT [PK_tblClaim] PRIMARY KEY CLUSTERED
(
[ClaimID]
) WITH FILLFACTOR = 90 ON [PRIMARY]
GO

CREATE CLUSTERED INDEX [IX_tblClaimDetail] ON
Re: Query Tuning. Michael C#
7/30/2005 3:20:44 PM
Check out UPDATE STATISTICS and see if you get a performance boost.

[quoted text, click to view]

Re: Query Tuning. Mowgli
7/30/2005 4:16:52 PM
Sagar

I would like to know (if possible) how long the much simpler query
below takes to return the data...

SELECT TOP 900000
cdp.SerialNumber
, cdp.ClaimDetailBundleID
, cdp.ProductBundleId
, 'spif' AS Program
, cdp.SerialNumber + '-PID-' AS SerialNumberProductId
FROM dbo.tblClaimDetailProduct cdp

If this takes longer than 4 seconds then I think that you may have to
revise your performance expectations.
Re: Query Tuning. Brian Selzer
7/30/2005 4:34:24 PM
Are you sure that the problem is the query and not communication/application
related? To test this, change the select to a select into #tempTable and
then select from #tempTable in your app/sp. That way you can separate the
amount of time the query takes to build the information from the time that
it takes to transfer/read out the result set in a trace.
[quoted text, click to view]
Scalar(DEFINE:([Expr1006]=[cdp].[SerialNumber]+'-PID-'+Convert([PB].[Product
ID])))
[quoted text, click to view]
Scan(OBJECT:([HPSpifCentral].[dbo].[tblClaimDetailBundle].[PK_tblClaimDetail
Bundle]
[quoted text, click to view]
Scan(OBJECT:([HPSpifCentral].[dbo].[tblClaimDetailProduct].[IX_tblClaimDetai
lProduct_SNo]
[quoted text, click to view]

Re: Query Tuning. Brian Selzer
7/30/2005 8:06:20 PM
Why aren't the clustered indexes on the primary keys? The key of a
clustered index should be as small as possible. In SQL Server 2000, if a
table has a clustered index, then instead of record pointers, nonclustered
indexes contain the key value from the clustered index. (Record pointers
are only used if the table is a heap.) Thus, the clustered index (if it
exists) is always used to locate a row. This differs from previous versions
of SQL Server. This means that every join of a table that has a
nonclustered primary key requires an additional index seek per row. This is
documented in BOL. I suggest you read up on it, create a testing database
with clustered primary keys, and try it out. I think you'll be pleasantly
surprised.


[quoted text, click to view]
Re: Query Tuning. Gert-Jan Strik
7/30/2005 10:29:02 PM
Without DDL and index information this is hard to say. It looks as if
you have no clustered indexes, and that the indexes that you do have
could be better placed.

So yes, the table schema is very welcome, because that is the place to
improve this query's performance.

As a general rule: make sure each table has a Primary Key (which will
automatically result in a unique index) and index all foreign key
constraints. It is generally a good idea for each table to have
clustered index. If there are several indexing on a table, then make
sure the clustered index is a narrow index.

HTH,
Gert-Jan


[quoted text, click to view]
Re: Query Tuning. Gert-Jan Strik
7/31/2005 10:40:12 PM
M,

A note about your schema. It seems you have a policy of adding an
Identity column to each table, and calling it the Primary Key. However,
you haven't named the natural key, since there are no Unique constraints
(or unique indexes).

Take table ClaimDetails as an example. Maybe (ClaimID, BundleID) is the
natural key. If it is, then it is a good practice to either make it the
Primary Key, or at least create a Unique Constraint for it. You can make
the Unique constraint clustered if you like. The point is, that it will
get a unique index, and that is important for the query optimizer.

The disadvantage of adding a surrogate key like this Identity column, is
that it makes it harder to efficiently join tables if selection is done
based on the natural key (especially if it is not unique, as noted
before). For example, if the primary key of table ClaimDetails was
indeed (ClaimID, BundleID), then table tblClaimDetailBundle would have a
ClaimID column (and no ClaimDetailID) and the join between
tblClaimDetailBundle - tblClaimDetail - tblClaim would be much more
efficient, since it would not require a hash.

Unfortunately, redesigning your schema will have a lot of impact, and
might not be possible. But it would make the decision about the
clustered index easier, because if you don't have to choose between the
surrogate key and the natural key then it will always be the Primary Key
that you want to have clustered.

You could try the following tips, and see if they help:
- make the index IX_tblClaimDetailProduct_1 on table
tblClaimDetailProduct clustered
- for all indexes that will contain only unique values, please create
the index with the Unique keyword
- if you have an SMP machine, then make sure parallelism is available,
because your query is likely to benefit from parallelism (because of the
many hashes).

I guess it won't help much. Although I must say that I think SQL-Server
is doing a pretty good job (given the circumstances).

Gert-Jan


[quoted text, click to view]
AddThis Social Bookmark Button