Hi,
Im noticing a performance diff when i execute a proc from the application
the duration shown in the profiler is higher than when i execute the same
proc from query analyze.
Does anyone have any clue on why this difference is occuring. What could be
causing the overhead.
Thanks.
Arzan wrote:
> Hi,
> Im noticing a performance diff when i execute a proc from the
> application the duration shown in the profiler is higher than when i
> execute the same proc from query analyze.
> Does anyone have any clue on why this difference is occuring. What
> could be causing the overhead.
> Thanks.
Duration is sometimes an application issue. The duration for a query is
determined by how long a query takes to execute plus how long the
application takes to fetch all the results in the result set. QA fetches
rows immediately and performs little to no processing on the returning
data, so durations are as fast as they can be. OTOH, an application may
be performing row processing on the result set or not fetching all at
once causing delays in the final duration figure.
You can test this from SQL EM and Profiler.
Run Profiler with the SQL:StmtStarting and SQL:StmtCompleted events.
Find a table with a lot of rows and right-click and select Return All
Rows.
You'll see the SQL:StmtStarting event with the Select * From...
Go back to SQL EM and CTLR + END to move to the end of the result set
Now you see the SQL:StmtCompleted in Profiler.
I'm not saying this is your problem. Can you provide more details about
your app and what's it's doing with the results, if any.
David Gugick
Imceda Software
www.imceda.com
Showing posts with label diff. Show all posts
Showing posts with label diff. Show all posts
Monday, March 26, 2012
Performance diff when sp executed from apps and from query analyze
Hi,
Im noticing a performance diff when i execute a proc from the application
the duration shown in the profiler is higher than when i execute the same
proc from query analyze.
Does anyone have any clue on why this difference is occuring. What could be
causing the overhead.
Thanks.Arzan wrote:
> Hi,
> Im noticing a performance diff when i execute a proc from the
> application the duration shown in the profiler is higher than when i
> execute the same proc from query analyze.
> Does anyone have any clue on why this difference is occuring. What
> could be causing the overhead.
> Thanks.
Duration is sometimes an application issue. The duration for a query is
determined by how long a query takes to execute plus how long the
application takes to fetch all the results in the result set. QA fetches
rows immediately and performs little to no processing on the returning
data, so durations are as fast as they can be. OTOH, an application may
be performing row processing on the result set or not fetching all at
once causing delays in the final duration figure.
You can test this from SQL EM and Profiler.
Run Profiler with the SQL:StmtStarting and SQL:StmtCompleted events.
Find a table with a lot of rows and right-click and select Return All
Rows.
You'll see the SQL:StmtStarting event with the Select * From...
Go back to SQL EM and CTLR + END to move to the end of the result set
Now you see the SQL:StmtCompleted in Profiler.
I'm not saying this is your problem. Can you provide more details about
your app and what's it's doing with the results, if any.
David Gugick
Imceda Software
www.imceda.com
Im noticing a performance diff when i execute a proc from the application
the duration shown in the profiler is higher than when i execute the same
proc from query analyze.
Does anyone have any clue on why this difference is occuring. What could be
causing the overhead.
Thanks.Arzan wrote:
> Hi,
> Im noticing a performance diff when i execute a proc from the
> application the duration shown in the profiler is higher than when i
> execute the same proc from query analyze.
> Does anyone have any clue on why this difference is occuring. What
> could be causing the overhead.
> Thanks.
Duration is sometimes an application issue. The duration for a query is
determined by how long a query takes to execute plus how long the
application takes to fetch all the results in the result set. QA fetches
rows immediately and performs little to no processing on the returning
data, so durations are as fast as they can be. OTOH, an application may
be performing row processing on the result set or not fetching all at
once causing delays in the final duration figure.
You can test this from SQL EM and Profiler.
Run Profiler with the SQL:StmtStarting and SQL:StmtCompleted events.
Find a table with a lot of rows and right-click and select Return All
Rows.
You'll see the SQL:StmtStarting event with the Select * From...
Go back to SQL EM and CTLR + END to move to the end of the result set
Now you see the SQL:StmtCompleted in Profiler.
I'm not saying this is your problem. Can you provide more details about
your app and what's it's doing with the results, if any.
David Gugick
Imceda Software
www.imceda.com
Monday, February 20, 2012
Percentage Difference Calculation!
I have a table as follows:
Year Month Value %Diff
2004 Jul 200
Aug 100
etc etc
2003 Jul 300
Aug 400
etc etc
I need to be able to calculate the % difference for each month compared to
the same month for the previous year. The Previous() function is close to
what I need but not close enough. Any help would be much appreciated?If you have control over the source query, a LEFT OUTER JOIN ... ON
a.Month=b.Month and a.Year=b.Year-1 would bring back the data you need on
each row to calculate the diff. As you can see from this post and others,
my philosophy is not to jump through major coding hoops in the report if you
can easily solve it in the SQL query.
--
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"St Matthew" <StMatthew@.discussions.microsoft.com> wrote in message
news:676C6EB0-0383-4BE6-86E5-58DFF89AA30B@.microsoft.com...
>I have a table as follows:
> Year Month Value %Diff
> 2004 Jul 200
> Aug 100
> etc etc
> 2003 Jul 300
> Aug 400
> etc etc
> I need to be able to calculate the % difference for each month compared to
> the same month for the previous year. The Previous() function is close to
> what I need but not close enough. Any help would be much appreciated?|||I should have mentioned in my SQL examples below that a and b are aliases
for the same table.
Cheers,
--
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
news:OZdTrAb0EHA.3584@.TK2MSFTNGP11.phx.gbl...
> If you have control over the source query, a LEFT OUTER JOIN ... ON
> a.Month=b.Month and a.Year=b.Year-1 would bring back the data you need on
> each row to calculate the diff. As you can see from this post and others,
> my philosophy is not to jump through major coding hoops in the report if
> you can easily solve it in the SQL query.
> --
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "St Matthew" <StMatthew@.discussions.microsoft.com> wrote in message
> news:676C6EB0-0383-4BE6-86E5-58DFF89AA30B@.microsoft.com...
>>I have a table as follows:
>> Year Month Value %Diff
>> 2004 Jul 200
>> Aug 100
>> etc etc
>> 2003 Jul 300
>> Aug 400
>> etc etc
>> I need to be able to calculate the % difference for each month compared
>> to
>> the same month for the previous year. The Previous() function is close
>> to
>> what I need but not close enough. Any help would be much appreciated?
>
Year Month Value %Diff
2004 Jul 200
Aug 100
etc etc
2003 Jul 300
Aug 400
etc etc
I need to be able to calculate the % difference for each month compared to
the same month for the previous year. The Previous() function is close to
what I need but not close enough. Any help would be much appreciated?If you have control over the source query, a LEFT OUTER JOIN ... ON
a.Month=b.Month and a.Year=b.Year-1 would bring back the data you need on
each row to calculate the diff. As you can see from this post and others,
my philosophy is not to jump through major coding hoops in the report if you
can easily solve it in the SQL query.
--
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"St Matthew" <StMatthew@.discussions.microsoft.com> wrote in message
news:676C6EB0-0383-4BE6-86E5-58DFF89AA30B@.microsoft.com...
>I have a table as follows:
> Year Month Value %Diff
> 2004 Jul 200
> Aug 100
> etc etc
> 2003 Jul 300
> Aug 400
> etc etc
> I need to be able to calculate the % difference for each month compared to
> the same month for the previous year. The Previous() function is close to
> what I need but not close enough. Any help would be much appreciated?|||I should have mentioned in my SQL examples below that a and b are aliases
for the same table.
Cheers,
--
'(' Jeff A. Stucker
\
Business Intelligence
www.criadvantage.com
---
"Jeff A. Stucker" <jeff@.mobilize.net> wrote in message
news:OZdTrAb0EHA.3584@.TK2MSFTNGP11.phx.gbl...
> If you have control over the source query, a LEFT OUTER JOIN ... ON
> a.Month=b.Month and a.Year=b.Year-1 would bring back the data you need on
> each row to calculate the diff. As you can see from this post and others,
> my philosophy is not to jump through major coding hoops in the report if
> you can easily solve it in the SQL query.
> --
> '(' Jeff A. Stucker
> \
> Business Intelligence
> www.criadvantage.com
> ---
> "St Matthew" <StMatthew@.discussions.microsoft.com> wrote in message
> news:676C6EB0-0383-4BE6-86E5-58DFF89AA30B@.microsoft.com...
>>I have a table as follows:
>> Year Month Value %Diff
>> 2004 Jul 200
>> Aug 100
>> etc etc
>> 2003 Jul 300
>> Aug 400
>> etc etc
>> I need to be able to calculate the % difference for each month compared
>> to
>> the same month for the previous year. The Previous() function is close
>> to
>> what I need but not close enough. Any help would be much appreciated?
>
Subscribe to:
Posts (Atom)