We are having a similar problem. We have a 3rd party application that uses
sp_prepare and then executes it. The problem is the query plan from the
sp_prepare statement is different than if you run the statement using
sp_execute or sp_executesql. I run the following statements:
declare @.P1 int
exec sp_prepare @.P1 output, N'@.P1 bigint,@.P2 bigint,@.P3 bigint,@.P4
bigint,@.P5 bigint,@.P6 bigint,@.P7 bigint,@.P8 bigint', 'SELECT SHAPE
,S_.eminx,S_.eminy,S_.emaxx,S_.emaxy ,SHAPE.fid F_fid,SHAPE.numofpts
F_numofpts,SHAPE.entity F_entity,SHAPE.points F_points FROM (SELECT DISTINC
T
sp_fid,eminx,eminy,emaxx,emaxy FROM SDE.SDE.s162 SP_ WHERE SP_.gx >= @.P1 AN
D
SP_.gx <= @.P2 AND SP_.gy >= @.P3 AND SP_.gy <= @.P4 AND SP_.eminx <= @.P5 AND
SP_.eminy <= @.P6 AND SP_.emaxx >= @.P7 AND SP_.emaxy >= @.P8 ) S_
,SDE.SDE.ENTORDERLINESEGMENT, SDE.SDE.f162 SHAPE WHERE S_.sp_fid = SHAPE.fi
d
AND SDE.SDE.ENTORDERLINESEGMENT.SHAPE = S_.sp_fid AND (( ORDERID in (16320,
16825) ))', 1 select @.P1
exec sp_execute 1, 166, 169, 219, 224, 90269119, 119480870, 88777840,
117193071
This takes almost a minute to return.
Then I run this statement:
declare @.P1 int
exec sp_prepare @.P1 output, N'@.P1 bigint,@.P2 bigint,@.P3 bigint,@.P4
bigint,@.P5 bigint,@.P6 bigint,@.P7 bigint,@.P8 bigint', 'SELECT SHAPE
,S_.eminx,S_.eminy,S_.emaxx,S_.emaxy ,SHAPE.fid F_fid,SHAPE.numofpts
F_numofpts,SHAPE.entity F_entity,SHAPE.points F_points FROM (SELECT DISTINC
T
sp_fid,eminx,eminy,emaxx,emaxy FROM SDE.SDE.s162 SP_ WHERE SP_.gx >= @.P1 AN
D
SP_.gx <= @.P2 AND SP_.gy >= @.P3 AND SP_.gy <= @.P4 AND SP_.eminx <= @.P5 AND
SP_.eminy <= @.P6 AND SP_.emaxx >= @.P7 AND SP_.emaxy >= @.P8 ) S_
,SDE.SDE.ENTORDERLINESEGMENT, SDE.SDE.f162 SHAPE WHERE S_.sp_fid = SHAPE.fi
d
AND SDE.SDE.ENTORDERLINESEGMENT.SHAPE = S_.sp_fid AND (( ORDERID in (16320,
16825) ))', 1 select @.P1
DBCC Freeproccache
exec sp_execute 1, 166, 169, 219, 224, 90269119, 119480870, 88777840,
117193071
This returns in under 1 second. The only difference is the freeproccache.
The first sp_execute is using the store query plan from cache. The second i
s
forced to compile a new execution plan which is much faster.
Does anyone know why the sp_prepare query execution plan would be slower?
Shouldn't it create the same plan?
Also, how did you change sp_prepare to use varchar instead of nvarchar? I
get an error stating the sp_prepare expects @.statement of type
ntext/nchar/nvarchar.
Thanks for any help.
Doug Matney
"lorinda" wrote:
> This makes sense. Looks like I will have to find a work around. Thanks
> again for your help!
>dmatney (dmatney@.discussions.microsoft.com) writes:
> We are having a similar problem. We have a 3rd party application that
> uses sp_prepare and then executes it. The problem is the query plan
> from the sp_prepare statement is different than if you run the statement
> using sp_execute or sp_executesql. I run the following statements:
>...
> This returns in under 1 second. The only difference is the
> freeproccache. The first sp_execute is using the store query plan from
> cache. The second is forced to compile a new execution plan which is
> much faster.
> Does anyone know why the sp_prepare query execution plan would be slower?
> Shouldn't it create the same plan?
Since I have never understood the point with sp_prepare, or what it really
achieves, this had me stumped at first, but I think I know the answer.
SQL Server is fond of parameter sniffing. This means that when you
run something that has parameters, be that a stored procedure or
sp_executesql, it looks at the parameter values and take these as
guidance for the plan.
But when you run sp_prepare there are no actual parameter values. Still
SQL Server builds a plan this point, using standard assumptions. Your
query includs a lot of >=. I believe the standard assumption here is
a 30% hit-rate. This is far above the limit where a non-clustered index
is deemed to be more expensive than a table scan.
When you flush the cache, there is no plan for sp_execute to use, so
a new plan has to be created, and since the parameter values are now
available, the optimizer can "sniff" them, and build a plan that better
fits the actual values. Presumably, the input values are close to the
edges.
Since this is from a third-party app, I guess your options to address
this are limited. You could investigate if you could make any of the
involved indexes clustered, but assuming that there is a clustered index
already, this could have ramifications elsewhere in the application.
If you are on SQL 2005, you could add a plan guide, which is quite an
advanced exercise.
> Also, how did you change sp_prepare to use varchar instead of nvarchar? I
> get an error stating the sp_prepare expects @.statement of type
> ntext/nchar/nvarchar.
I guess you don't. It's the same with sp_executesql. The parameter is
ntext (nvarchar(MAX) in SQL 2005), and since this is a built-in stored
procedure, there is no implicit conversion from varchar.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Thanks. I think you are correct about the parameter sniffing. I have tried
creating a plan guide using a Recompile hint and it works for this particula
r
sp_prepare but since the application doesn't use parameters for all values (
the OrderID in clause uses real values) I can't get it to work every time.
I'm going to do a little more research and see if we can't convince the
application developer to use a different method. Thanks again for your help
.
"Erland Sommarskog" wrote:
> dmatney (dmatney@.discussions.microsoft.com) writes:
> Since I have never understood the point with sp_prepare, or what it really
> achieves, this had me stumped at first, but I think I know the answer.
> SQL Server is fond of parameter sniffing. This means that when you
> run something that has parameters, be that a stored procedure or
> sp_executesql, it looks at the parameter values and take these as
> guidance for the plan.
> But when you run sp_prepare there are no actual parameter values. Still
> SQL Server builds a plan this point, using standard assumptions. Your
> query includs a lot of >=. I believe the standard assumption here is
> a 30% hit-rate. This is far above the limit where a non-clustered index
> is deemed to be more expensive than a table scan.
> When you flush the cache, there is no plan for sp_execute to use, so
> a new plan has to be created, and since the parameter values are now
> available, the optimizer can "sniff" them, and build a plan that better
> fits the actual values. Presumably, the input values are close to the
> edges.
> Since this is from a third-party app, I guess your options to address
> this are limited. You could investigate if you could make any of the
> involved indexes clustered, but assuming that there is a clustered index
> already, this could have ramifications elsewhere in the application.
> If you are on SQL 2005, you could add a plan guide, which is quite an
> advanced exercise.
>
> I guess you don't. It's the same with sp_executesql. The parameter is
> ntext (nvarchar(MAX) in SQL 2005), and since this is a built-in stored
> procedure, there is no implicit conversion from varchar.
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx
>
Showing posts with label execution. Show all posts
Showing posts with label execution. Show all posts
Monday, March 19, 2012
Another Slow Execution Plan with sp_prepare
Thanks to Erland, my issue with sp_prepare of NVarchar and Varchar has been
resolved by changing a parameter in JDBC to force it to use Varchar instead
of NVarchar. JDBC's default setting uses NVarchar. Look under Subject "Slo
w
Query with sp_prepare and sp_execute" to see the thread.
However, I now have a problem with the INT datatype in my prepare
statements. I have tried using various numeric data types with sp_prepare.
But none gives me a response time as fast as running a single query.
For example, I have the following table:
CREATE TABLE Segment (
SegmentId int NOT NULL,
SegmentSetId int NOT NULL,
Sequence varchar (255) NOT NULL,
CONSTRAINT PK_Segment PRIMARY KEY CLUSTERED (SegmentId)
With the below index:
CREATE INDEX IX_Segment ON Segment(SegmentSetId)
The table has 6 million rows. I am using prepare statments in a JDBC
environment. When the below prepare statement is used, the execution plan
uses index scan which generates a slow response time:
Declare @.P1 int
Exec sp_prepare @.P1 output,
N'@.P1 int',
N'select * from Segment where SegmentSetId=@.P1'
Select @.P1
Exec sp_execute @.P1,649
Execution Tree
--
Parallelism(Gather Streams)
|--Clustered Index Scan(OBJECT:([Dev].[dbo].[Segment].[PK_Segment]),
WHERE:([Segment].[SegmentSetId]=[@.P1]))
Now, if I just run the query with all the parameters already provided, the
execution plan
uses index s
which generates a fast response time:
select * from Segment where SegmentSetId=649
Execution Tree
--
Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Dev].[dbo].[Segment]))
|--Index S(OBJECT:([Dev].[dbo].[Segment].[IX_Segment]),
SEEK:([Segment].[SegmentSetId]=Convert([@.1])) ORDERED FORWARD)
Can anyone give me a hint how to resolve this one? What can I use in my
prepared statement to force the optimizer to use an index s instead of an
index scan?
Again, any help will be greatly appreciated!Hi
If you add to this statement (AND 1=1) do you see an index s?
N'select * from Segment where SegmentSetId=@.P1 and 1=1'
"lorinda" <lorinda@.community.nospam> wrote in message
news:121EF92B-554B-4D96-AFCA-C6E6F0A5D757@.microsoft.com...
> Thanks to Erland, my issue with sp_prepare of NVarchar and Varchar has
> been
> resolved by changing a parameter in JDBC to force it to use Varchar
> instead
> of NVarchar. JDBC's default setting uses NVarchar. Look under Subject
> "Slow
> Query with sp_prepare and sp_execute" to see the thread.
> However, I now have a problem with the INT datatype in my prepare
> statements. I have tried using various numeric data types with
> sp_prepare.
> But none gives me a response time as fast as running a single query.
> For example, I have the following table:
> CREATE TABLE Segment (
> SegmentId int NOT NULL,
> SegmentSetId int NOT NULL,
> Sequence varchar (255) NOT NULL,
> CONSTRAINT PK_Segment PRIMARY KEY CLUSTERED (SegmentId)
> With the below index:
> CREATE INDEX IX_Segment ON Segment(SegmentSetId)
> The table has 6 million rows. I am using prepare statments in a JDBC
> environment. When the below prepare statement is used, the execution plan
> uses index scan which generates a slow response time:
> Declare @.P1 int
> Exec sp_prepare @.P1 output,
> N'@.P1 int',
> N'select * from Segment where SegmentSetId=@.P1'
> Select @.P1
> Exec sp_execute @.P1,649
> Execution Tree
> --
> Parallelism(Gather Streams)
> |--Clustered Index Scan(OBJECT:([Dev].[dbo].[Segment].[PK_Segment]),
> WHERE:([Segment].[SegmentSetId]=[@.P1]))
> Now, if I just run the query with all the parameters already provided, the
> execution plan
> uses index s which generates a fast response time:
> select * from Segment where SegmentSetId=649
> Execution Tree
> --
> Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Dev].[dbo].[Segment]))
> |--Index S(OBJECT:([Dev].[dbo].[Segment].[IX_Segment]),
> SEEK:([Segment].[SegmentSetId]=Convert([@.1])) ORDERED FORWARD)
> Can anyone give me a hint how to resolve this one? What can I use in my
> prepared statement to force the optimizer to use an index s instead of
> an
> index scan?
> Again, any help will be greatly appreciated!
>|||lorinda (lorinda@.community.nospam) writes:
> However, I now have a problem with the INT datatype in my prepare
> statements. I have tried using various numeric data types with
> sp_prepare. But none gives me a response time as fast as running a
> single query.
> For example, I have the following table:
> CREATE TABLE Segment (
> SegmentId int NOT NULL,
> SegmentSetId int NOT NULL,
> Sequence varchar (255) NOT NULL,
> CONSTRAINT PK_Segment PRIMARY KEY CLUSTERED (SegmentId)
> With the below index:
> CREATE INDEX IX_Segment ON Segment(SegmentSetId)
> The table has 6 million rows. I am using prepare statments in a JDBC
> environment. When the below prepare statement is used, the execution plan
> uses index scan which generates a slow response time:
>...
> Now, if I just run the query with all the parameters already provided, the
> execution plan
> uses index s which generates a fast response time:
> select * from Segment where SegmentSetId=649
So this is a completely different issue from the varchar thing.
This is the classical choice between using a non-clustered index or
scanning the table. If there are two rows with SegmentSetID = 649 the
index is alright. But if there is a million, it's faster to find them
by scanning the table, because using the index would require many
page accesses to the same page.
SQL Server has statistics from which it makes estimates. At least for
stored procedure it sniffs the input parameter value when it builds
the plan and puts in cache. I would assume that this is the case
with sp_prepare as well. So I would expect it to use the index. Then
again, if you first attempt was with SegmentSetID = 0, and there are
a million rows with id 0, then what ended up in the cache was the
clustered index scan.
You can force the index with an index hint:
SELECT * FROM Segment WITH (INDEX = IX_Segment) WHERE ...
but this can come back bite when you are asking for that SegmentSetID
with lots of rows.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||This makes sense. Looks like I will have to find a work around. Thanks
again for your help!
resolved by changing a parameter in JDBC to force it to use Varchar instead
of NVarchar. JDBC's default setting uses NVarchar. Look under Subject "Slo
w
Query with sp_prepare and sp_execute" to see the thread.
However, I now have a problem with the INT datatype in my prepare
statements. I have tried using various numeric data types with sp_prepare.
But none gives me a response time as fast as running a single query.
For example, I have the following table:
CREATE TABLE Segment (
SegmentId int NOT NULL,
SegmentSetId int NOT NULL,
Sequence varchar (255) NOT NULL,
CONSTRAINT PK_Segment PRIMARY KEY CLUSTERED (SegmentId)
With the below index:
CREATE INDEX IX_Segment ON Segment(SegmentSetId)
The table has 6 million rows. I am using prepare statments in a JDBC
environment. When the below prepare statement is used, the execution plan
uses index scan which generates a slow response time:
Declare @.P1 int
Exec sp_prepare @.P1 output,
N'@.P1 int',
N'select * from Segment where SegmentSetId=@.P1'
Select @.P1
Exec sp_execute @.P1,649
Execution Tree
--
Parallelism(Gather Streams)
|--Clustered Index Scan(OBJECT:([Dev].[dbo].[Segment].[PK_Segment]),
WHERE:([Segment].[SegmentSetId]=[@.P1]))
Now, if I just run the query with all the parameters already provided, the
execution plan
uses index s
which generates a fast response time:select * from Segment where SegmentSetId=649
Execution Tree
--
Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Dev].[dbo].[Segment]))
|--Index S
(OBJECT:([Dev].[dbo].[Segment].[IX_Segment]),SEEK:([Segment].[SegmentSetId]=Convert([@.1])) ORDERED FORWARD)
Can anyone give me a hint how to resolve this one? What can I use in my
prepared statement to force the optimizer to use an index s
instead of anindex scan?
Again, any help will be greatly appreciated!Hi
If you add to this statement (AND 1=1) do you see an index s
?N'select * from Segment where SegmentSetId=@.P1 and 1=1'
"lorinda" <lorinda@.community.nospam> wrote in message
news:121EF92B-554B-4D96-AFCA-C6E6F0A5D757@.microsoft.com...
> Thanks to Erland, my issue with sp_prepare of NVarchar and Varchar has
> been
> resolved by changing a parameter in JDBC to force it to use Varchar
> instead
> of NVarchar. JDBC's default setting uses NVarchar. Look under Subject
> "Slow
> Query with sp_prepare and sp_execute" to see the thread.
> However, I now have a problem with the INT datatype in my prepare
> statements. I have tried using various numeric data types with
> sp_prepare.
> But none gives me a response time as fast as running a single query.
> For example, I have the following table:
> CREATE TABLE Segment (
> SegmentId int NOT NULL,
> SegmentSetId int NOT NULL,
> Sequence varchar (255) NOT NULL,
> CONSTRAINT PK_Segment PRIMARY KEY CLUSTERED (SegmentId)
> With the below index:
> CREATE INDEX IX_Segment ON Segment(SegmentSetId)
> The table has 6 million rows. I am using prepare statments in a JDBC
> environment. When the below prepare statement is used, the execution plan
> uses index scan which generates a slow response time:
> Declare @.P1 int
> Exec sp_prepare @.P1 output,
> N'@.P1 int',
> N'select * from Segment where SegmentSetId=@.P1'
> Select @.P1
> Exec sp_execute @.P1,649
> Execution Tree
> --
> Parallelism(Gather Streams)
> |--Clustered Index Scan(OBJECT:([Dev].[dbo].[Segment].[PK_Segment]),
> WHERE:([Segment].[SegmentSetId]=[@.P1]))
> Now, if I just run the query with all the parameters already provided, the
> execution plan
> uses index s
which generates a fast response time:> select * from Segment where SegmentSetId=649
> Execution Tree
> --
> Bookmark Lookup(BOOKMARK:([Bmk1000]), OBJECT:([Dev].[dbo].[Segment]))
> |--Index S
(OBJECT:([Dev].[dbo].[Segment].[IX_Segment]),> SEEK:([Segment].[SegmentSetId]=Convert([@.1])) ORDERED FORWARD)
> Can anyone give me a hint how to resolve this one? What can I use in my
> prepared statement to force the optimizer to use an index s
instead of> an
> index scan?
> Again, any help will be greatly appreciated!
>|||lorinda (lorinda@.community.nospam) writes:
> However, I now have a problem with the INT datatype in my prepare
> statements. I have tried using various numeric data types with
> sp_prepare. But none gives me a response time as fast as running a
> single query.
> For example, I have the following table:
> CREATE TABLE Segment (
> SegmentId int NOT NULL,
> SegmentSetId int NOT NULL,
> Sequence varchar (255) NOT NULL,
> CONSTRAINT PK_Segment PRIMARY KEY CLUSTERED (SegmentId)
> With the below index:
> CREATE INDEX IX_Segment ON Segment(SegmentSetId)
> The table has 6 million rows. I am using prepare statments in a JDBC
> environment. When the below prepare statement is used, the execution plan
> uses index scan which generates a slow response time:
>...
> Now, if I just run the query with all the parameters already provided, the
> execution plan
> uses index s
which generates a fast response time:> select * from Segment where SegmentSetId=649
So this is a completely different issue from the varchar thing.
This is the classical choice between using a non-clustered index or
scanning the table. If there are two rows with SegmentSetID = 649 the
index is alright. But if there is a million, it's faster to find them
by scanning the table, because using the index would require many
page accesses to the same page.
SQL Server has statistics from which it makes estimates. At least for
stored procedure it sniffs the input parameter value when it builds
the plan and puts in cache. I would assume that this is the case
with sp_prepare as well. So I would expect it to use the index. Then
again, if you first attempt was with SegmentSetID = 0, and there are
a million rows with id 0, then what ended up in the cache was the
clustered index scan.
You can force the index with an index hint:
SELECT * FROM Segment WITH (INDEX = IX_Segment) WHERE ...
but this can come back bite when you are asking for that SegmentSetID
with lots of rows.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||This makes sense. Looks like I will have to find a work around. Thanks
again for your help!
Thursday, March 8, 2012
Another execution plan question
SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
t1.col3=t2.col3
The total number of rows in Table1 are just 100. But the estimated row count
shows 75,000.
Its a production environment and probably cannot drop any procedure caches .
How can I make the estimated row count to show me the actual count or
atleast drop it to within the 100s range. Table1 has only 1 clustered index
on (col2,col3) . IF i have to use hints, what hints can i use and if not,
what else can i do to reflect the actual count"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> t1.col3=t2.col3
> The total number of rows in Table1 are just 100. But the estimated row
count
> shows 75,000.
> Its a production environment and probably cannot drop any procedure caches
.
> How can I make the estimated row count to show me the actual count or
> atleast drop it to within the 100s range. Table1 has only 1 clustered
index
> on (col2,col3) . IF i have to use hints, what hints can i use and if not,
> what else can i do to reflect the actual count
How many rows are there in table 2? If there is a one to many relationship
then a single row in table 1 will be counted for every row in table 2 it is
paired with.
If you only want a row to appear once from table 1 then change the query to
SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
t1.col3=t2.col3
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003|||You didnt follow my question Bob..
When i talk about estimated row count, I mean when i click on the operators
in the execution plan under the clustered index scan of table1 which only
has 100 rows but the estimated row count shown there is around 75000.
Probably at one point in time it was that much and hence the adhoc query
plan is reflecting that. I would like to change it to show me atleast in a
100s range...
"Bob Simms" <bob_simms@.hotmail.com> wrote in message
news:AB7fb.820$Wm6.21@.news-binary.blueyonder.co.uk...
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > t1.col3=t2.col3
> >
> > The total number of rows in Table1 are just 100. But the estimated row
> count
> > shows 75,000.
> > Its a production environment and probably cannot drop any procedure
caches
> .
> > How can I make the estimated row count to show me the actual count or
> > atleast drop it to within the 100s range. Table1 has only 1 clustered
> index
> > on (col2,col3) . IF i have to use hints, what hints can i use and if
not,
> > what else can i do to reflect the actual count
> How many rows are there in table 2? If there is a one to many
relationship
> then a single row in table 1 will be counted for every row in table 2 it
is
> paired with.
> If you only want a row to appear once from table 1 then change the query
to
> SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2
and
> t1.col3=t2.col3
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003
>|||Did you try updating statistics with fullscan. I'm not sure it'll help, but worth a try...
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Hassan" <fatima_ja@.hotmail.com> wrote in message news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> t1.col3=t2.col3
> The total number of rows in Table1 are just 100. But the estimated row count
> shows 75,000.
> Its a production environment and probably cannot drop any procedure caches .
> How can I make the estimated row count to show me the actual count or
> atleast drop it to within the 100s range. Table1 has only 1 clustered index
> on (col2,col3) . IF i have to use hints, what hints can i use and if not,
> what else can i do to reflect the actual count
>|||I did all that... As I was hoping the plan might change...but no luck...
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:OzlahhXiDHA.2248@.TK2MSFTNGP12.phx.gbl...
> Did you try updating statistics with fullscan. I'm not sure it'll help,
but worth a try...
> --
> Tibor Karaszi, SQL Server MVP
> Archive at: http://groups.google.com/groups?oi=djq&as
ugroup=microsoft.public.sqlserver
>
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > t1.col3=t2.col3
> >
> > The total number of rows in Table1 are just 100. But the estimated row
count
> > shows 75,000.
> > Its a production environment and probably cannot drop any procedure
caches .
> > How can I make the estimated row count to show me the actual count or
> > atleast drop it to within the 100s range. Table1 has only 1 clustered
index
> > on (col2,col3) . IF i have to use hints, what hints can i use and if
not,
> > what else can i do to reflect the actual count
> >
> >
>|||On Thu, 2 Oct 2003 21:16:28 -0700, "Hassan" <fatima_ja@.hotmail.com>
wrote:
>SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
>t1.col3=t2.col3
>The total number of rows in Table1 are just 100. But the estimated row count
>shows 75,000.
>Its a production environment and probably cannot drop any procedure caches .
>How can I make the estimated row count to show me the actual count or
>atleast drop it to within the 100s range. Table1 has only 1 clustered index
>on (col2,col3) . IF i have to use hints, what hints can i use and if not,
>what else can i do to reflect the actual count
I seldom even look at the estimated numbers, and even more seldom am
able to make any sense out of them. I suspect many, many bugs, as
well as unexplained complexities, in the numbers displayed.
When you actually run the query, what kind of statistics do you get?
And, how many rows get returned?
Joshua Stern|||you have indexes on the columns in both t1 and t2 AND you have updated
statistics with FULLSCAN on both tables? And you still are getting widely
off estimated row counts showing in the graphical showplan? I just want to
make sure I understand...
that would be bit wierd to be off SOO much on such simple queries if the
columns are indexed and you did FULLSCAN...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:e9cqgmXiDHA.1796@.TK2MSFTNGP10.phx.gbl...
> I did all that... As I was hoping the plan might change...but no luck...
> "Tibor Karaszi"
<tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> wrote in message news:OzlahhXiDHA.2248@.TK2MSFTNGP12.phx.gbl...
> > Did you try updating statistics with fullscan. I'm not sure it'll help,
> but worth a try...
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > Archive at: http://groups.google.com/groups?oi=djq&as
> ugroup=microsoft.public.sqlserver
> >
> >
> > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > t1.col3=t2.col3
> > >
> > > The total number of rows in Table1 are just 100. But the estimated row
> count
> > > shows 75,000.
> > > Its a production environment and probably cannot drop any procedure
> caches .
> > > How can I make the estimated row count to show me the actual count or
> > > atleast drop it to within the 100s range. Table1 has only 1 clustered
> index
> > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> not,
> > > what else can i do to reflect the actual count
> > >
> > >
> >
> >
>|||On Thu, 2 Oct 2003 21:16:28 -0700, "Hassan" <fatima_ja@.hotmail.com>
wrote:
>SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
>t1.col3=t2.col3
>The total number of rows in Table1 are just 100. But the estimated row count
>shows 75,000.
>Its a production environment and probably cannot drop any procedure caches .
>How can I make the estimated row count to show me the actual count or
>atleast drop it to within the 100s range. Table1 has only 1 clustered index
>on (col2,col3) . IF i have to use hints, what hints can i use and if not,
>what else can i do to reflect the actual count
You've got no where clause.
Actually, if it's a clustered index, and the 100 rows remaining are
spread over a space that used to have 75,000 rows, maybe it's telling
you that it has to physically scan the space that would normally take
75k rows? Maybe someone here with more experience with these plans
and clustered indexes can confirm this.
J.|||Dropped all indexes and recreated them to resolve this.. It was weird. The
adhoc query plan was still being cached I guess.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:OBan2MeiDHA.1200@.TK2MSFTNGP09.phx.gbl...
> you have indexes on the columns in both t1 and t2 AND you have updated
> statistics with FULLSCAN on both tables? And you still are getting widely
> off estimated row counts showing in the graphical showplan? I just want to
> make sure I understand...
> that would be bit wierd to be off SOO much on such simple queries if the
> columns are indexed and you did FULLSCAN...
> --
> Brian Moran
> Principal Mentor
> Solid Quality Learning
> SQL Server MVP
> http://www.solidqualitylearning.com
>
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:e9cqgmXiDHA.1796@.TK2MSFTNGP10.phx.gbl...
> > I did all that... As I was hoping the plan might change...but no luck...
> >
> > "Tibor Karaszi"
> <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> > wrote in message news:OzlahhXiDHA.2248@.TK2MSFTNGP12.phx.gbl...
> > > Did you try updating statistics with fullscan. I'm not sure it'll
help,
> > but worth a try...
> > >
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > Archive at: http://groups.google.com/groups?oi=djq&as
> > ugroup=microsoft.public.sqlserver
> > >
> > >
> > > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> > news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > > t1.col3=t2.col3
> > > >
> > > > The total number of rows in Table1 are just 100. But the estimated
row
> > count
> > > > shows 75,000.
> > > > Its a production environment and probably cannot drop any procedure
> > caches .
> > > > How can I make the estimated row count to show me the actual count
or
> > > > atleast drop it to within the 100s range. Table1 has only 1
clustered
> > index
> > > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> > not,
> > > > what else can i do to reflect the actual count
> > > >
> > > >
> > >
> > >
> >
> >
>|||Hi Hassan.
I think that Bob is probably on the money - I've carefully re-read your
original post, what Bob's responded with & the other posts too, but I think
Bob most likely right.
Does table2 have 75000 rows? If so, I think that you won't get the estimated
rowcount down below this because, critically, your query is selecting
t2.col1 which is from the right hand side (table2) of the join statement.
This means that the estimated rows will be however many rows are in table2 &
as you have no where clause (either on table1 or table2) there is no way for
the optimizer to short cut a full scan of table2.col1. If table2 has 75000
rows, then the only valid estimate is 75000 rows.
Regards,
Greg Linwood
SQL Server MVP
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:e#IhICXiDHA.2984@.TK2MSFTNGP11.phx.gbl...
> You didnt follow my question Bob..
> When i talk about estimated row count, I mean when i click on the
operators
> in the execution plan under the clustered index scan of table1 which only
> has 100 rows but the estimated row count shown there is around 75000.
> Probably at one point in time it was that much and hence the adhoc query
> plan is reflecting that. I would like to change it to show me atleast in a
> 100s range...
>
> "Bob Simms" <bob_simms@.hotmail.com> wrote in message
> news:AB7fb.820$Wm6.21@.news-binary.blueyonder.co.uk...
> > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> > news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > t1.col3=t2.col3
> > >
> > > The total number of rows in Table1 are just 100. But the estimated row
> > count
> > > shows 75,000.
> > > Its a production environment and probably cannot drop any procedure
> caches
> > .
> > > How can I make the estimated row count to show me the actual count or
> > > atleast drop it to within the 100s range. Table1 has only 1 clustered
> > index
> > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> not,
> > > what else can i do to reflect the actual count
> >
> > How many rows are there in table 2? If there is a one to many
> relationship
> > then a single row in table 1 will be counted for every row in table 2 it
> is
> > paired with.
> >
> > If you only want a row to appear once from table 1 then change the query
> to
> > SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2
> and
> > t1.col3=t2.col3
> >
> >
> >
> > --
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003
> >
> >
>|||Table T2 has 20 millions rows and the estimated row count for that shows
around the same. But T1 has only 100 rows and the estimated row count for T1
showed 75000. I dropped and recreated all indexes and it worked fine now.
Just some plan being cached I guess.
"Greg Linwood" <g_linwood@.hotmail.com> wrote in message
news:%234MVFakiDHA.2536@.TK2MSFTNGP10.phx.gbl...
> Hi Hassan.
> I think that Bob is probably on the money - I've carefully re-read your
> original post, what Bob's responded with & the other posts too, but I
think
> Bob most likely right.
> Does table2 have 75000 rows? If so, I think that you won't get the
estimated
> rowcount down below this because, critically, your query is selecting
> t2.col1 which is from the right hand side (table2) of the join statement.
> This means that the estimated rows will be however many rows are in table2
&
> as you have no where clause (either on table1 or table2) there is no way
for
> the optimizer to short cut a full scan of table2.col1. If table2 has 75000
> rows, then the only valid estimate is 75000 rows.
> Regards,
> Greg Linwood
> SQL Server MVP
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:e#IhICXiDHA.2984@.TK2MSFTNGP11.phx.gbl...
> > You didnt follow my question Bob..
> >
> > When i talk about estimated row count, I mean when i click on the
> operators
> > in the execution plan under the clustered index scan of table1 which
only
> > has 100 rows but the estimated row count shown there is around 75000.
> > Probably at one point in time it was that much and hence the adhoc query
> > plan is reflecting that. I would like to change it to show me atleast in
a
> > 100s range...
> >
> >
> > "Bob Simms" <bob_simms@.hotmail.com> wrote in message
> > news:AB7fb.820$Wm6.21@.news-binary.blueyonder.co.uk...
> > > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> > > news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > > t1.col3=t2.col3
> > > >
> > > > The total number of rows in Table1 are just 100. But the estimated
row
> > > count
> > > > shows 75,000.
> > > > Its a production environment and probably cannot drop any procedure
> > caches
> > > .
> > > > How can I make the estimated row count to show me the actual count
or
> > > > atleast drop it to within the 100s range. Table1 has only 1
clustered
> > > index
> > > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> > not,
> > > > what else can i do to reflect the actual count
> > >
> > > How many rows are there in table 2? If there is a one to many
> > relationship
> > > then a single row in table 1 will be counted for every row in table 2
it
> > is
> > > paired with.
> > >
> > > If you only want a row to appear once from table 1 then change the
query
> > to
> > > SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on
t1.col2=t2.col2
> > and
> > > t1.col3=t2.col3
> > >
> > >
> > >
> > > --
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003
> > >
> > >
> >
> >
>|||On Fri, 3 Oct 2003 17:14:09 -0700, "Hassan" <fatima_ja@.hotmail.com>
wrote:
>Dropped all indexes and recreated them to resolve this.. It was weird. The
>adhoc query plan was still being cached I guess.
Did you drop a clustered index on table1?
J.
t1.col3=t2.col3
The total number of rows in Table1 are just 100. But the estimated row count
shows 75,000.
Its a production environment and probably cannot drop any procedure caches .
How can I make the estimated row count to show me the actual count or
atleast drop it to within the 100s range. Table1 has only 1 clustered index
on (col2,col3) . IF i have to use hints, what hints can i use and if not,
what else can i do to reflect the actual count"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> t1.col3=t2.col3
> The total number of rows in Table1 are just 100. But the estimated row
count
> shows 75,000.
> Its a production environment and probably cannot drop any procedure caches
.
> How can I make the estimated row count to show me the actual count or
> atleast drop it to within the 100s range. Table1 has only 1 clustered
index
> on (col2,col3) . IF i have to use hints, what hints can i use and if not,
> what else can i do to reflect the actual count
How many rows are there in table 2? If there is a one to many relationship
then a single row in table 1 will be counted for every row in table 2 it is
paired with.
If you only want a row to appear once from table 1 then change the query to
SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
t1.col3=t2.col3
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003|||You didnt follow my question Bob..
When i talk about estimated row count, I mean when i click on the operators
in the execution plan under the clustered index scan of table1 which only
has 100 rows but the estimated row count shown there is around 75000.
Probably at one point in time it was that much and hence the adhoc query
plan is reflecting that. I would like to change it to show me atleast in a
100s range...
"Bob Simms" <bob_simms@.hotmail.com> wrote in message
news:AB7fb.820$Wm6.21@.news-binary.blueyonder.co.uk...
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > t1.col3=t2.col3
> >
> > The total number of rows in Table1 are just 100. But the estimated row
> count
> > shows 75,000.
> > Its a production environment and probably cannot drop any procedure
caches
> .
> > How can I make the estimated row count to show me the actual count or
> > atleast drop it to within the 100s range. Table1 has only 1 clustered
> index
> > on (col2,col3) . IF i have to use hints, what hints can i use and if
not,
> > what else can i do to reflect the actual count
> How many rows are there in table 2? If there is a one to many
relationship
> then a single row in table 1 will be counted for every row in table 2 it
is
> paired with.
> If you only want a row to appear once from table 1 then change the query
to
> SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2
and
> t1.col3=t2.col3
>
> --
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003
>|||Did you try updating statistics with fullscan. I'm not sure it'll help, but worth a try...
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Hassan" <fatima_ja@.hotmail.com> wrote in message news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> t1.col3=t2.col3
> The total number of rows in Table1 are just 100. But the estimated row count
> shows 75,000.
> Its a production environment and probably cannot drop any procedure caches .
> How can I make the estimated row count to show me the actual count or
> atleast drop it to within the 100s range. Table1 has only 1 clustered index
> on (col2,col3) . IF i have to use hints, what hints can i use and if not,
> what else can i do to reflect the actual count
>|||I did all that... As I was hoping the plan might change...but no luck...
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:OzlahhXiDHA.2248@.TK2MSFTNGP12.phx.gbl...
> Did you try updating statistics with fullscan. I'm not sure it'll help,
but worth a try...
> --
> Tibor Karaszi, SQL Server MVP
> Archive at: http://groups.google.com/groups?oi=djq&as
ugroup=microsoft.public.sqlserver
>
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > t1.col3=t2.col3
> >
> > The total number of rows in Table1 are just 100. But the estimated row
count
> > shows 75,000.
> > Its a production environment and probably cannot drop any procedure
caches .
> > How can I make the estimated row count to show me the actual count or
> > atleast drop it to within the 100s range. Table1 has only 1 clustered
index
> > on (col2,col3) . IF i have to use hints, what hints can i use and if
not,
> > what else can i do to reflect the actual count
> >
> >
>|||On Thu, 2 Oct 2003 21:16:28 -0700, "Hassan" <fatima_ja@.hotmail.com>
wrote:
>SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
>t1.col3=t2.col3
>The total number of rows in Table1 are just 100. But the estimated row count
>shows 75,000.
>Its a production environment and probably cannot drop any procedure caches .
>How can I make the estimated row count to show me the actual count or
>atleast drop it to within the 100s range. Table1 has only 1 clustered index
>on (col2,col3) . IF i have to use hints, what hints can i use and if not,
>what else can i do to reflect the actual count
I seldom even look at the estimated numbers, and even more seldom am
able to make any sense out of them. I suspect many, many bugs, as
well as unexplained complexities, in the numbers displayed.
When you actually run the query, what kind of statistics do you get?
And, how many rows get returned?
Joshua Stern|||you have indexes on the columns in both t1 and t2 AND you have updated
statistics with FULLSCAN on both tables? And you still are getting widely
off estimated row counts showing in the graphical showplan? I just want to
make sure I understand...
that would be bit wierd to be off SOO much on such simple queries if the
columns are indexed and you did FULLSCAN...
--
Brian Moran
Principal Mentor
Solid Quality Learning
SQL Server MVP
http://www.solidqualitylearning.com
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:e9cqgmXiDHA.1796@.TK2MSFTNGP10.phx.gbl...
> I did all that... As I was hoping the plan might change...but no luck...
> "Tibor Karaszi"
<tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> wrote in message news:OzlahhXiDHA.2248@.TK2MSFTNGP12.phx.gbl...
> > Did you try updating statistics with fullscan. I'm not sure it'll help,
> but worth a try...
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > Archive at: http://groups.google.com/groups?oi=djq&as
> ugroup=microsoft.public.sqlserver
> >
> >
> > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > t1.col3=t2.col3
> > >
> > > The total number of rows in Table1 are just 100. But the estimated row
> count
> > > shows 75,000.
> > > Its a production environment and probably cannot drop any procedure
> caches .
> > > How can I make the estimated row count to show me the actual count or
> > > atleast drop it to within the 100s range. Table1 has only 1 clustered
> index
> > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> not,
> > > what else can i do to reflect the actual count
> > >
> > >
> >
> >
>|||On Thu, 2 Oct 2003 21:16:28 -0700, "Hassan" <fatima_ja@.hotmail.com>
wrote:
>SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
>t1.col3=t2.col3
>The total number of rows in Table1 are just 100. But the estimated row count
>shows 75,000.
>Its a production environment and probably cannot drop any procedure caches .
>How can I make the estimated row count to show me the actual count or
>atleast drop it to within the 100s range. Table1 has only 1 clustered index
>on (col2,col3) . IF i have to use hints, what hints can i use and if not,
>what else can i do to reflect the actual count
You've got no where clause.
Actually, if it's a clustered index, and the 100 rows remaining are
spread over a space that used to have 75,000 rows, maybe it's telling
you that it has to physically scan the space that would normally take
75k rows? Maybe someone here with more experience with these plans
and clustered indexes can confirm this.
J.|||Dropped all indexes and recreated them to resolve this.. It was weird. The
adhoc query plan was still being cached I guess.
"Brian Moran" <brian@.solidqualitylearning.com> wrote in message
news:OBan2MeiDHA.1200@.TK2MSFTNGP09.phx.gbl...
> you have indexes on the columns in both t1 and t2 AND you have updated
> statistics with FULLSCAN on both tables? And you still are getting widely
> off estimated row counts showing in the graphical showplan? I just want to
> make sure I understand...
> that would be bit wierd to be off SOO much on such simple queries if the
> columns are indexed and you did FULLSCAN...
> --
> Brian Moran
> Principal Mentor
> Solid Quality Learning
> SQL Server MVP
> http://www.solidqualitylearning.com
>
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:e9cqgmXiDHA.1796@.TK2MSFTNGP10.phx.gbl...
> > I did all that... As I was hoping the plan might change...but no luck...
> >
> > "Tibor Karaszi"
> <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> > wrote in message news:OzlahhXiDHA.2248@.TK2MSFTNGP12.phx.gbl...
> > > Did you try updating statistics with fullscan. I'm not sure it'll
help,
> > but worth a try...
> > >
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > Archive at: http://groups.google.com/groups?oi=djq&as
> > ugroup=microsoft.public.sqlserver
> > >
> > >
> > > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> > news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > > t1.col3=t2.col3
> > > >
> > > > The total number of rows in Table1 are just 100. But the estimated
row
> > count
> > > > shows 75,000.
> > > > Its a production environment and probably cannot drop any procedure
> > caches .
> > > > How can I make the estimated row count to show me the actual count
or
> > > > atleast drop it to within the 100s range. Table1 has only 1
clustered
> > index
> > > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> > not,
> > > > what else can i do to reflect the actual count
> > > >
> > > >
> > >
> > >
> >
> >
>|||Hi Hassan.
I think that Bob is probably on the money - I've carefully re-read your
original post, what Bob's responded with & the other posts too, but I think
Bob most likely right.
Does table2 have 75000 rows? If so, I think that you won't get the estimated
rowcount down below this because, critically, your query is selecting
t2.col1 which is from the right hand side (table2) of the join statement.
This means that the estimated rows will be however many rows are in table2 &
as you have no where clause (either on table1 or table2) there is no way for
the optimizer to short cut a full scan of table2.col1. If table2 has 75000
rows, then the only valid estimate is 75000 rows.
Regards,
Greg Linwood
SQL Server MVP
"Hassan" <fatima_ja@.hotmail.com> wrote in message
news:e#IhICXiDHA.2984@.TK2MSFTNGP11.phx.gbl...
> You didnt follow my question Bob..
> When i talk about estimated row count, I mean when i click on the
operators
> in the execution plan under the clustered index scan of table1 which only
> has 100 rows but the estimated row count shown there is around 75000.
> Probably at one point in time it was that much and hence the adhoc query
> plan is reflecting that. I would like to change it to show me atleast in a
> 100s range...
>
> "Bob Simms" <bob_simms@.hotmail.com> wrote in message
> news:AB7fb.820$Wm6.21@.news-binary.blueyonder.co.uk...
> > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> > news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > t1.col3=t2.col3
> > >
> > > The total number of rows in Table1 are just 100. But the estimated row
> > count
> > > shows 75,000.
> > > Its a production environment and probably cannot drop any procedure
> caches
> > .
> > > How can I make the estimated row count to show me the actual count or
> > > atleast drop it to within the 100s range. Table1 has only 1 clustered
> > index
> > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> not,
> > > what else can i do to reflect the actual count
> >
> > How many rows are there in table 2? If there is a one to many
> relationship
> > then a single row in table 1 will be counted for every row in table 2 it
> is
> > paired with.
> >
> > If you only want a row to appear once from table 1 then change the query
> to
> > SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2
> and
> > t1.col3=t2.col3
> >
> >
> >
> > --
> > Outgoing mail is certified Virus Free.
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003
> >
> >
>|||Table T2 has 20 millions rows and the estimated row count for that shows
around the same. But T1 has only 100 rows and the estimated row count for T1
showed 75000. I dropped and recreated all indexes and it worked fine now.
Just some plan being cached I guess.
"Greg Linwood" <g_linwood@.hotmail.com> wrote in message
news:%234MVFakiDHA.2536@.TK2MSFTNGP10.phx.gbl...
> Hi Hassan.
> I think that Bob is probably on the money - I've carefully re-read your
> original post, what Bob's responded with & the other posts too, but I
think
> Bob most likely right.
> Does table2 have 75000 rows? If so, I think that you won't get the
estimated
> rowcount down below this because, critically, your query is selecting
> t2.col1 which is from the right hand side (table2) of the join statement.
> This means that the estimated rows will be however many rows are in table2
&
> as you have no where clause (either on table1 or table2) there is no way
for
> the optimizer to short cut a full scan of table2.col1. If table2 has 75000
> rows, then the only valid estimate is 75000 rows.
> Regards,
> Greg Linwood
> SQL Server MVP
> "Hassan" <fatima_ja@.hotmail.com> wrote in message
> news:e#IhICXiDHA.2984@.TK2MSFTNGP11.phx.gbl...
> > You didnt follow my question Bob..
> >
> > When i talk about estimated row count, I mean when i click on the
> operators
> > in the execution plan under the clustered index scan of table1 which
only
> > has 100 rows but the estimated row count shown there is around 75000.
> > Probably at one point in time it was that much and hence the adhoc query
> > plan is reflecting that. I would like to change it to show me atleast in
a
> > 100s range...
> >
> >
> > "Bob Simms" <bob_simms@.hotmail.com> wrote in message
> > news:AB7fb.820$Wm6.21@.news-binary.blueyonder.co.uk...
> > > "Hassan" <fatima_ja@.hotmail.com> wrote in message
> > > news:ef9LfUWiDHA.616@.TK2MSFTNGP11.phx.gbl...
> > > > SELECT t2.col1 FROM Table1 t1 JOIN table2 t2 on t1.col2=t2.col2 and
> > > > t1.col3=t2.col3
> > > >
> > > > The total number of rows in Table1 are just 100. But the estimated
row
> > > count
> > > > shows 75,000.
> > > > Its a production environment and probably cannot drop any procedure
> > caches
> > > .
> > > > How can I make the estimated row count to show me the actual count
or
> > > > atleast drop it to within the 100s range. Table1 has only 1
clustered
> > > index
> > > > on (col2,col3) . IF i have to use hints, what hints can i use and if
> > not,
> > > > what else can i do to reflect the actual count
> > >
> > > How many rows are there in table 2? If there is a one to many
> > relationship
> > > then a single row in table 1 will be counted for every row in table 2
it
> > is
> > > paired with.
> > >
> > > If you only want a row to appear once from table 1 then change the
query
> > to
> > > SELECT DISTINCT t2.col1 FROM Table1 t1 JOIN table2 t2 on
t1.col2=t2.col2
> > and
> > > t1.col3=t2.col3
> > >
> > >
> > >
> > > --
> > > Outgoing mail is certified Virus Free.
> > > Checked by AVG anti-virus system (http://www.grisoft.com).
> > > Version: 6.0.522 / Virus Database: 320 - Release Date: 29/09/2003
> > >
> > >
> >
> >
>|||On Fri, 3 Oct 2003 17:14:09 -0700, "Hassan" <fatima_ja@.hotmail.com>
wrote:
>Dropped all indexes and recreated them to resolve this.. It was weird. The
>adhoc query plan was still being cached I guess.
Did you drop a clustered index on table1?
J.
Wednesday, March 7, 2012
Another cryptic message from SQL 2005 SSIS
It reminds me of the "opearation was successful the patient died" scenario.
Compare this to the SSIS Error message:
The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
Why can't they write meaningful messages?
YOu need enable the logging for SSIS packages in order to see what was that error : http://www.databasejournal.com/features/mssql/article.php/3562406 fyi.|||Did they fix this bug finally?|||I forgot to indicate my blog entry for this:
http://hodentek.blogspot.com/2007/03/ssis-migration-fiasco.html
|||I was actaully trying to find an answer for the question I posted:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1393552&SiteID=1
Please forgive.
|||Moved this thread from SQL Server Tools General to the SSIS forum.You should know that your error likely has to do with the ProtectionLevel property of the package. Right click on the control flow and select properties. What is it set to?|||
Jayaram Krishnaswamy wrote:
Did they fix this bug finally?
What bug? I don't believe there is a bug here, rather I think there is a lack of understanding of how differently SSIS operates compared to DTS.|||
Reply was not helpful.
Tried all options (somewhat unprofessional, fortunately fewer options). The same result.
Details follow:
Protection Level of package:
DontSaveSensitive: failed
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (4) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptSensitiveWithPassowrd: failed
Provided a password for the package, myPubs.dtsx.
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptAllwithPassword:failed
failed
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptAllwithUserkey:failed (ola didn't ask for a key or anything, it must have assumed some default)
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure
ServerStorage: failed
TITLE: Microsoft Visual Studio
Failure saving package.
ADDITIONAL INFORMATION:
Failed to apply package protection with error 0xC0014061 "The protection level, ServerStorage, cannot be used when saving to this destination. The system could not verify that the destination supports secure storage capability.". This error occurs when saving to Xml.
(myPubs)
Failed to apply package protection with error 0xC0014061 "The protection level, ServerStorage, cannot be used when saving to this destination. The system could not verify that the destination supports secure storage capability.". This error occurs when saving to Xml.
(myPubs)
BUTTONS:
OK
Open for suggestions
|||Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.|||
I forgot to indicate my blog entry for this:
http://hodentek.blogspot.com/2007/03/ssis-migration-fiasco.html
You haven't understood the inherent differences between SSIS and DTS. SSIS is a much more secure environment and will not allow you to store passwords with the same freedom as DTS did. Can I politely suggest that you familiarise yourself totally with this new tool before you start to blog about it and thus post inaccurate information. You are not helping the SSIS community by doing so.
-Jamie
|||If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.|||
If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.
REPORTING WHAT, *exactly*?
WHAT *IS* THE PROBLEM?|||
If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.
huh?
If SSIS is proprietary software then show me some software that ISN'T proprietary.
I haven't seen anyone else on this thread reporting any problem, only you. In fact, you haven't actually articulated a problem as far as I can see. In summary, what is the prolem that you speak of?
-Jamie
|||
Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.
This did not help in my case.
Jayaram, have you resolved this problem finally?
|||
Phil Brammer wrote:
Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.
This did not help in my case.
Jayaram, have you resolved this problem finally?
I don't know what that means. What exactly is your issue? What are you trying to achieve?
Another cryptic message from SQL 2005 SSIS
It reminds me of the "opearation was successful the patient died" scenario.
Compare this to the SSIS Error message:
The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
Why can't they write meaningful messages?
YOu need enable the logging for SSIS packages in order to see what was that error : http://www.databasejournal.com/features/mssql/article.php/3562406 fyi.|||Did they fix this bug finally?|||I forgot to indicate my blog entry for this:
http://hodentek.blogspot.com/2007/03/ssis-migration-fiasco.html
|||
I was actaully trying to find an answer for the question I posted:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1393552&SiteID=1
Please forgive.
|||Moved this thread from SQL Server Tools General to the SSIS forum.You should know that your error likely has to do with the ProtectionLevel property of the package. Right click on the control flow and select properties. What is it set to?|||
Did they fix this bug finally?
What bug? I don't believe there is a bug here, rather I think there is a lack of understanding of how differently SSIS operates compared to DTS.|||
Reply was not helpful.
Tried all options (somewhat unprofessional, fortunately fewer options). The same result.
Details follow:
Protection Level of package:
DontSaveSensitive: failed
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (4) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptSensitiveWithPassowrd: failed
Provided a password for the package, myPubs.dtsx.
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptAllwithPassword:failed
failed
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptAllwithUserkey:failed (ola didn't ask for a key or anything, it must have assumed some default)
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure
ServerStorage: failed
TITLE: Microsoft Visual Studio
Failure saving package.
ADDITIONAL INFORMATION:
Failed to apply package protection with error 0xC0014061 "The protection level, ServerStorage, cannot be used when saving to this destination. The system could not verify that the destination supports secure storage capability.". This error occurs when saving to Xml.
(myPubs)
Failed to apply package protection with error 0xC0014061 "The protection level, ServerStorage, cannot be used when saving to this destination. The system could not verify that the destination supports secure storage capability.". This error occurs when saving to Xml.
(myPubs)
BUTTONS:
OK
Open for suggestions
|||Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.|||I forgot to indicate my blog entry for this:
http://hodentek.blogspot.com/2007/03/ssis-migration-fiasco.html
You haven't understood the inherent differences between SSIS and DTS. SSIS is a much more secure environment and will not allow you to store passwords with the same freedom as DTS did. Can I politely suggest that you familiarise yourself totally with this new tool before you start to blog about it and thus post inaccurate information. You are not helping the SSIS community by doing so.
-Jamie
|||If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.|||
If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.
REPORTING WHAT, *exactly*?
WHAT *IS* THE PROBLEM?|||
If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.
huh?
If SSIS is proprietary software then show me some software that ISN'T proprietary.
I haven't seen anyone else on this thread reporting any problem, only you. In fact, you haven't actually articulated a problem as far as I can see. In summary, what is the prolem that you speak of?
-Jamie
|||
Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.
This did not help in my case.
Jayaram, have you resolved this problem finally?|||
Phil Brammer wrote: Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.
This did not help in my case.
Jayaram, have you resolved this problem finally?
I don't know what that means. What exactly is your issue? What are you trying to achieve?
Another cryptic message from SQL 2005 SSIS
It reminds me of the "opearation was successful the patient died" scenario.
Compare this to the SSIS Error message:
The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
Why can't they write meaningful messages?
YOu need enable the logging for SSIS packages in order to see what was that error : http://www.databasejournal.com/features/mssql/article.php/3562406 fyi.|||Did they fix this bug finally?|||I forgot to indicate my blog entry for this:
http://hodentek.blogspot.com/2007/03/ssis-migration-fiasco.html
|||I was actaully trying to find an answer for the question I posted:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1393552&SiteID=1
Please forgive.
|||Moved this thread from SQL Server Tools General to the SSIS forum.You should know that your error likely has to do with the ProtectionLevel property of the package. Right click on the control flow and select properties. What is it set to?|||
Did they fix this bug finally?
What bug? I don't believe there is a bug here, rather I think there is a lack of understanding of how differently SSIS operates compared to DTS.|||
Reply was not helpful.
Tried all options (somewhat unprofessional, fortunately fewer options). The same result.
Details follow:
Protection Level of package:
DontSaveSensitive: failed
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (4) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptSensitiveWithPassowrd: failed
Provided a password for the package, myPubs.dtsx.
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptAllwithPassword:failed
failed
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure.
EncryptAllwithUserkey:failed (ola didn't ask for a key or anything, it must have assumed some default)
SSIS package "myPubs.dtsx" starting.
Error: 0xC002F325 at Copy SQL Server Objects, Transfer SQL Server Objects Task: Execution failed with the following error: "Cannot apply value null to property Login: Value cannot be null..".
Task failed: Copy SQL Server Objects
Warning: 0x80019002 at myPubs: The Execution method succeeded, but the number of errors raised (1) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "myPubs.dtsx" finished: Failure
ServerStorage: failed
TITLE: Microsoft Visual Studio
Failure saving package.
ADDITIONAL INFORMATION:
Failed to apply package protection with error 0xC0014061 "The protection level, ServerStorage, cannot be used when saving to this destination. The system could not verify that the destination supports secure storage capability.". This error occurs when saving to Xml.
(myPubs)
Failed to apply package protection with error 0xC0014061 "The protection level, ServerStorage, cannot be used when saving to this destination. The system could not verify that the destination supports secure storage capability.". This error occurs when saving to Xml.
(myPubs)
BUTTONS:
OK
Open for suggestions
|||Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.|||
I forgot to indicate my blog entry for this:
http://hodentek.blogspot.com/2007/03/ssis-migration-fiasco.html
You haven't understood the inherent differences between SSIS and DTS. SSIS is a much more secure environment and will not allow you to store passwords with the same freedom as DTS did. Can I politely suggest that you familiarise yourself totally with this new tool before you start to blog about it and thus post inaccurate information. You are not helping the SSIS community by doing so.
-Jamie
|||If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.|||
If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.
REPORTING WHAT, *exactly*?
WHAT *IS* THE PROBLEM?|||
If the number of people reporting this is large surely somebody should take the responsibility of putting the matter to rest. This is probably one of the problems with proprietary software.
huh?
If SSIS is proprietary software then show me some software that ISN'T proprietary.
I haven't seen anyone else on this thread reporting any problem, only you. In fact, you haven't actually articulated a problem as far as I can see. In summary, what is the prolem that you speak of?
-Jamie
|||
Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.
This did not help in my case.
Jayaram, have you resolved this problem finally?
|||
Phil Brammer wrote:
Try EncryptSensitiveWithUserKey and then go back in and retype in your credentials for the connections. Make sure you check the save password box.
This did not help in my case.
Jayaram, have you resolved this problem finally?
I don't know what that means. What exactly is your issue? What are you trying to achieve?
Subscribe to:
Posts (Atom)