Showing posts with label individual. Show all posts
Showing posts with label individual. Show all posts

Monday, March 26, 2012

individual SqlDataSource() or common SqlDataSource() ?

i am using visual web developer 2005 with SQL Express 2005 with VB as the code behind

i haveone database andthree tables in it

for manipulating each table i am using separate SqlDataSource()

is it sufficient to use one SqlDataSource() for manipulating all the three tables ?

i am manipulating all the tables in the same page only

please help me

Hi,
In my opinion I think that the best would be to use a different SqlDataSource object for each database table. I think that to give you a better answer you should have to give us a little piece of your code.

Luis Ramirez.
www.sqlnetframework.com
The SQL framework for .NET.

Friday, March 23, 2012

Individual Process CPU utilization

MS SQL Server 2000 Enterprise with SP3a
Is there a way to known which process is causing 100% cpu.
Is cpu column in sysprocesses gives that.
How can we see the plan of current running process. Sybase has sp_showplan.
Is there any equivalent stored proc in sql server.
Thanks.
Satwinder..Hi
The CPU column is the cumulative CPU usage, therefore you should be looking
at the rate of change for this value. You may want to look at SET STATISTICS
TIME. Also check out SQL Profiler which will show what statements (including
a duration and I/O details) are being run on the server.
John
"Satwinder" wrote:
> MS SQL Server 2000 Enterprise with SP3a
> Is there a way to known which process is causing 100% cpu.
> Is cpu column in sysprocesses gives that.
> How can we see the plan of current running process. Sybase has sp_showplan.
> Is there any equivalent stored proc in sql server.
> Thanks.
> Satwinder..|||yesterday my server had cpu of 100% for an hour. During that time i did not
want to run profiler and put more load on server.
By looking at processes can we tell which process is utilising max. cpu.
cheers
Satwinder
"John Bell" wrote:
> Hi
> The CPU column is the cumulative CPU usage, therefore you should be looking
> at the rate of change for this value. You may want to look at SET STATISTICS
> TIME. Also check out SQL Profiler which will show what statements (including
> a duration and I/O details) are being run on the server.
> John
> "Satwinder" wrote:
> > MS SQL Server 2000 Enterprise with SP3a
> > Is there a way to known which process is causing 100% cpu.
> >
> > Is cpu column in sysprocesses gives that.
> >
> > How can we see the plan of current running process. Sybase has sp_showplan.
> > Is there any equivalent stored proc in sql server.
> >
> > Thanks.
> > Satwinder..|||Hi,
run the following querry
select spid,hostname,program_name, cpu from master..sysprocesses order by
cpu desc
Amo Lembhe
"Satwinder" wrote:
> yesterday my server had cpu of 100% for an hour. During that time i did not
> want to run profiler and put more load on server.
> By looking at processes can we tell which process is utilising max. cpu.
> cheers
> Satwinder
> "John Bell" wrote:
> > Hi
> >
> > The CPU column is the cumulative CPU usage, therefore you should be looking
> > at the rate of change for this value. You may want to look at SET STATISTICS
> > TIME. Also check out SQL Profiler which will show what statements (including
> > a duration and I/O details) are being run on the server.
> >
> > John
> >
> > "Satwinder" wrote:
> >
> > > MS SQL Server 2000 Enterprise with SP3a
> > > Is there a way to known which process is causing 100% cpu.
> > >
> > > Is cpu column in sysprocesses gives that.
> > >
> > > How can we see the plan of current running process. Sybase has sp_showplan.
> > > Is there any equivalent stored proc in sql server.
> > >
> > > Thanks.
> > > Satwinder..|||CPU in sysprocesses does not indicate currently process comsuning high cpu.
cheers
"Amol Lembhe" wrote:
> Hi,
> run the following querry
> select spid,hostname,program_name, cpu from master..sysprocesses order by
> cpu desc
> Amo Lembhe
> "Satwinder" wrote:
> > yesterday my server had cpu of 100% for an hour. During that time i did not
> > want to run profiler and put more load on server.
> > By looking at processes can we tell which process is utilising max. cpu.
> >
> > cheers
> >
> > Satwinder
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > The CPU column is the cumulative CPU usage, therefore you should be looking
> > > at the rate of change for this value. You may want to look at SET STATISTICS
> > > TIME. Also check out SQL Profiler which will show what statements (including
> > > a duration and I/O details) are being run on the server.
> > >
> > > John
> > >
> > > "Satwinder" wrote:
> > >
> > > > MS SQL Server 2000 Enterprise with SP3a
> > > > Is there a way to known which process is causing 100% cpu.
> > > >
> > > > Is cpu column in sysprocesses gives that.
> > > >
> > > > How can we see the plan of current running process. Sybase has sp_showplan.
> > > > Is there any equivalent stored proc in sql server.
> > > >
> > > > Thanks.
> > > > Satwinder..|||Anyone in the world who can help me on this. We have 500 process and finding
which one is causing cpu to go 100.
Is this at all possible in SQL server.
Help...
"Satwinder" wrote:
> CPU in sysprocesses does not indicate currently process comsuning high cpu.
> cheers
> "Amol Lembhe" wrote:
> > Hi,
> > run the following querry
> > select spid,hostname,program_name, cpu from master..sysprocesses order by
> > cpu desc
> >
> > Amo Lembhe
> >
> > "Satwinder" wrote:
> >
> > > yesterday my server had cpu of 100% for an hour. During that time i did not
> > > want to run profiler and put more load on server.
> > > By looking at processes can we tell which process is utilising max. cpu.
> > >
> > > cheers
> > >
> > > Satwinder
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > The CPU column is the cumulative CPU usage, therefore you should be looking
> > > > at the rate of change for this value. You may want to look at SET STATISTICS
> > > > TIME. Also check out SQL Profiler which will show what statements (including
> > > > a duration and I/O details) are being run on the server.
> > > >
> > > > John
> > > >
> > > > "Satwinder" wrote:
> > > >
> > > > > MS SQL Server 2000 Enterprise with SP3a
> > > > > Is there a way to known which process is causing 100% cpu.
> > > > >
> > > > > Is cpu column in sysprocesses gives that.
> > > > >
> > > > > How can we see the plan of current running process. Sybase has sp_showplan.
> > > > > Is there any equivalent stored proc in sql server.
> > > > >
> > > > > Thanks.
> > > > > Satwinder..|||Hi
If you are running at 100% for that length of time it sounds like you are
already in trouble, therefore the faster you fix it the better regardless of
short term inconvenience. A server side trace will use less resources than
using the GUI and using a disc not used by SQL Server for the output will
reduce any resource conflicts further. It would not require a great deal of
profiling to identify what is wrong especially if you already have a baseline
for the performance, and you will know exactly what piece of code the problem
is occuring. You could even automate the collection of a trace using a
perfmon alert.
John
"Satwinder" wrote:
> yesterday my server had cpu of 100% for an hour. During that time i did not
> want to run profiler and put more load on server.
> By looking at processes can we tell which process is utilising max. cpu.
> cheers
> Satwinder
> "John Bell" wrote:
> > Hi
> >
> > The CPU column is the cumulative CPU usage, therefore you should be looking
> > at the rate of change for this value. You may want to look at SET STATISTICS
> > TIME. Also check out SQL Profiler which will show what statements (including
> > a duration and I/O details) are being run on the server.
> >
> > John
> >
> > "Satwinder" wrote:
> >
> > > MS SQL Server 2000 Enterprise with SP3a
> > > Is there a way to known which process is causing 100% cpu.
> > >
> > > Is cpu column in sysprocesses gives that.
> > >
> > > How can we see the plan of current running process. Sybase has sp_showplan.
> > > Is there any equivalent stored proc in sql server.
> > >
> > > Thanks.
> > > Satwinder..|||On Tue, 1 Aug 2006 04:56:01 -0700, Satwinder
<Satwinder@.discussions.microsoft.com> wrote:
>MS SQL Server 2000 Enterprise with SP3a
>Is there a way to known which process is causing 100% cpu.
>Is cpu column in sysprocesses gives that.
>How can we see the plan of current running process. Sybase has sp_showplan.
>Is there any equivalent stored proc in sql server.
exec sp_who2
>Thanks.
>Satwinder..|||Hi,
get cpu consume for each program
select program_name, sum(cpu) from master..sysprocesses
group by program_name
u can querry system tables to get required info.
"Satwinder" wrote:
> CPU in sysprocesses does not indicate currently process comsuning high cpu.
> cheers
> "Amol Lembhe" wrote:
> > Hi,
> > run the following querry
> > select spid,hostname,program_name, cpu from master..sysprocesses order by
> > cpu desc
> >
> > Amo Lembhe
> >
> > "Satwinder" wrote:
> >
> > > yesterday my server had cpu of 100% for an hour. During that time i did not
> > > want to run profiler and put more load on server.
> > > By looking at processes can we tell which process is utilising max. cpu.
> > >
> > > cheers
> > >
> > > Satwinder
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > The CPU column is the cumulative CPU usage, therefore you should be looking
> > > > at the rate of change for this value. You may want to look at SET STATISTICS
> > > > TIME. Also check out SQL Profiler which will show what statements (including
> > > > a duration and I/O details) are being run on the server.
> > > >
> > > > John
> > > >
> > > > "Satwinder" wrote:
> > > >
> > > > > MS SQL Server 2000 Enterprise with SP3a
> > > > > Is there a way to known which process is causing 100% cpu.
> > > > >
> > > > > Is cpu column in sysprocesses gives that.
> > > > >
> > > > > How can we see the plan of current running process. Sybase has sp_showplan.
> > > > > Is there any equivalent stored proc in sql server.
> > > > >
> > > > > Thanks.
> > > > > Satwinder..|||My question is whenever cpu is 100%, then i start the sql profiler, will it
capture the query causing high cpu. Profiler does not capture already running
queries.
cheers, satwinder
"Satwinder" wrote:
> MS SQL Server 2000 Enterprise with SP3a
> Is there a way to known which process is causing 100% cpu.
> Is cpu column in sysprocesses gives that.
> How can we see the plan of current running process. Sybase has sp_showplan.
> Is there any equivalent stored proc in sql server.
> Thanks.
> Satwinder..|||On Wed, 2 Aug 2006 02:26:01 -0700, Satwinder
<Satwinder@.discussions.microsoft.com> wrote:
>My question is whenever cpu is 100%, then i start the sql profiler, will it
>capture the query causing high cpu. Profiler does not capture already running
>queries.
Yes, it will capture that when complete, even if it was started before
the profiler. I'm pretty certain of that, because I've done traces
catching both begins and ends, and had orphans!
J.sql

Individual Process CPU utilization

MS SQL Server 2000 Enterprise with SP3a
Is there a way to known which process is causing 100% cpu.
Is cpu column in sysprocesses gives that.
How can we see the plan of current running process. Sybase has sp_showplan.
Is there any equivalent stored proc in sql server.
Thanks.
Satwinder..Hi
The CPU column is the cumulative CPU usage, therefore you should be looking
at the rate of change for this value. You may want to look at SET STATISTICS
TIME. Also check out SQL Profiler which will show what statements (including
a duration and I/O details) are being run on the server.
John
"Satwinder" wrote:

> MS SQL Server 2000 Enterprise with SP3a
> Is there a way to known which process is causing 100% cpu.
> Is cpu column in sysprocesses gives that.
> How can we see the plan of current running process. Sybase has sp_showplan
.
> Is there any equivalent stored proc in sql server.
> Thanks.
> Satwinder..|||yesterday my server had cpu of 100% for an hour. During that time i did not
want to run profiler and put more load on server.
By looking at processes can we tell which process is utilising max. cpu.
cheers
Satwinder
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> The CPU column is the cumulative CPU usage, therefore you should be lookin
g
> at the rate of change for this value. You may want to look at SET STATISTI
CS
> TIME. Also check out SQL Profiler which will show what statements (includi
ng
> a duration and I/O details) are being run on the server.
> John
> "Satwinder" wrote:
>|||Hi,
run the following querry
select spid,hostname,program_name, cpu from master..sysprocesses order by
cpu desc
Amo Lembhe
"Satwinder" wrote:
[vbcol=seagreen]
> yesterday my server had cpu of 100% for an hour. During that time i did no
t
> want to run profiler and put more load on server.
> By looking at processes can we tell which process is utilising max. cpu.
> cheers
> Satwinder
> "John Bell" wrote:
>|||CPU in sysprocesses does not indicate currently process comsuning high cpu.
cheers
"Amol Lembhe" wrote:
[vbcol=seagreen]
> Hi,
> run the following querry
> select spid,hostname,program_name, cpu from master..sysprocesses order by
> cpu desc
> Amo Lembhe
> "Satwinder" wrote:
>|||Anyone in the world who can help me on this. We have 500 process and finding
which one is causing cpu to go 100.
Is this at all possible in SQL server.
Help...
"Satwinder" wrote:
[vbcol=seagreen]
> CPU in sysprocesses does not indicate currently process comsuning high cpu
.
> cheers
> "Amol Lembhe" wrote:
>|||Hi
If you are running at 100% for that length of time it sounds like you are
already in trouble, therefore the faster you fix it the better regardless of
short term inconvenience. A server side trace will use less resources than
using the GUI and using a disc not used by SQL Server for the output will
reduce any resource conflicts further. It would not require a great deal of
profiling to identify what is wrong especially if you already have a baselin
e
for the performance, and you will know exactly what piece of code the proble
m
is occuring. You could even automate the collection of a trace using a
perfmon alert.
John
"Satwinder" wrote:
[vbcol=seagreen]
> yesterday my server had cpu of 100% for an hour. During that time i did no
t
> want to run profiler and put more load on server.
> By looking at processes can we tell which process is utilising max. cpu.
> cheers
> Satwinder
> "John Bell" wrote:
>|||On Tue, 1 Aug 2006 04:56:01 -0700, Satwinder
<Satwinder@.discussions.microsoft.com> wrote:

>MS SQL Server 2000 Enterprise with SP3a
>Is there a way to known which process is causing 100% cpu.
>Is cpu column in sysprocesses gives that.
>How can we see the plan of current running process. Sybase has sp_showplan.
>Is there any equivalent stored proc in sql server.
exec sp_who2

>Thanks.
>Satwinder..|||Hi,
get cpu consume for each program
select program_name, sum(cpu) from master..sysprocesses
group by program_name
u can querry system tables to get required info.
"Satwinder" wrote:
[vbcol=seagreen]
> CPU in sysprocesses does not indicate currently process comsuning high cpu
.
> cheers
> "Amol Lembhe" wrote:
>|||My question is whenever cpu is 100%, then i start the sql profiler, will it
capture the query causing high cpu. Profiler does not capture already runnin
g
queries.
cheers, satwinder
"Satwinder" wrote:

> MS SQL Server 2000 Enterprise with SP3a
> Is there a way to known which process is causing 100% cpu.
> Is cpu column in sysprocesses gives that.
> How can we see the plan of current running process. Sybase has sp_showplan
.
> Is there any equivalent stored proc in sql server.
> Thanks.
> Satwinder..

Wednesday, March 7, 2012

indexes are slowing down my query

>It seems that your individual indexes DO NOT cover your
>query. Each time you run your query, the optimizer is
>using 4 different index (one at a time) and it has
>increased disk i/o. Increased disk i/o means slow query
>response.
Has anyone else EVER encountered this before. I know I
never have. I built individual indexes on the same 4
columns that the ITW wanted to build a covered index on.
It slowed down my query by 40%. This is bizarre behavior.
I've only been a DBA for a few years, but I've NEVER had
this happen or even heard of it. Has anyone else? Is this
a bug?

>--Original Message--
>Hi,
>Here is a bit of information I found in BOL:
>"
>Covered queries can improve performance. Covered queries
>are queries where all the columns specified in the query
>are contained within the same index. For example, a query
>retrieving columns a and b from a table that has a
>composite index created on columns a, b, and c is
>considered covered. Creating indexes that cover a query
>can improve performance because all the data for the
query
>is contained within the index itself; only the index
>pages, not the data pages, of the table must be
referenced
>to retrieve the data, thereby reducing overall I/O.
>Although adding columns to an index to cover queries can
>improve performance, maintaining the extra columns in the
>index incurs update and storage costs.
>"
>It seems that your individual indexes DO NOT cover your
>query. Each time you run your query, the optimizer is
>using 4 different index (one at a time) and it has
>increased disk i/o. Increased disk i/o means slow query
>response.
>hth
>DeeJay
>transdtl
>SERVICE','DTV*DIRECTV
on[vbcol=seagreen]
is[vbcol=seagreen]
this[vbcol=seagreen]
>in
>performance.com/composite_indexes.asp
to[vbcol=seagreen]
>table
>soooooo
>the
index.[vbcol=seagreen]
query[vbcol=seagreen]
>.
>On Thu, 24 Jun 2004 08:39:28 -0700, ChrisR wrote:

>This is bizarre behavior.
Hi Chris,
No, it is not. Both Greg and DeeJay already pointed out that one index on
all columns required for the query means that SQL Server has to access
this index only. Individual indexes are not covering; SQL Server might
choose to read all indexes and merge the results, or use one index and
fetch the data pages through that index. In both cases, more disk access
is required than when one covering index on all columns can be used.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

indexes are slowing down my query

>It seems that your individual indexes DO NOT cover your
>query. Each time you run your query, the optimizer is
>using 4 different index (one at a time) and it has
>increased disk i/o. Increased disk i/o means slow query
>response.
Has anyone else EVER encountered this before. I know I
never have. I built individual indexes on the same 4
columns that the ITW wanted to build a covered index on.
It slowed down my query by 40%. This is bizarre behavior.
I've only been a DBA for a few years, but I've NEVER had
this happen or even heard of it. Has anyone else? Is this
a bug?

>--Original Message--
>Hi,
>Here is a bit of information I found in BOL:
>"
>Covered queries can improve performance. Covered queries
>are queries where all the columns specified in the query
>are contained within the same index. For example, a query
>retrieving columns a and b from a table that has a
>composite index created on columns a, b, and c is
>considered covered. Creating indexes that cover a query
>can improve performance because all the data for the
query
>is contained within the index itself; only the index
>pages, not the data pages, of the table must be
referenced[vbcol=seagreen]
>to retrieve the data, thereby reducing overall I/O.
>Although adding columns to an index to cover queries can
>improve performance, maintaining the extra columns in the
>index incurs update and storage costs.
>"
>It seems that your individual indexes DO NOT cover your
>query. Each time you run your query, the optimizer is
>using 4 different index (one at a time) and it has
>increased disk i/o. Increased disk i/o means slow query
>response.
>hth
>DeeJay
>transdtl
>SERVICE','DTV*DIRECTV
on[vbcol=seagreen]
is[vbcol=seagreen]
this[vbcol=seagreen]
>in
>performance.com/composite_indexes.asp
to[vbcol=seagreen]
>table
>soooooo
>the
index.[vbcol=seagreen]
query
>.
>
On Thu, 24 Jun 2004 08:39:28 -0700, ChrisR wrote:

>This is bizarre behavior.
Hi Chris,
No, it is not. Both Greg and DeeJay already pointed out that one index on
all columns required for the query means that SQL Server has to access
this index only. Individual indexes are not covering; SQL Server might
choose to read all indexes and merge the results, or use one index and
fetch the data pages through that index. In both cases, more disk access
is required than when one covering index on all columns can be used.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)