We have a series of SPs, poorly written, but that's not the issue here.
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ? We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
KlK, MCSE
Hi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off http://msmvps.com/epprecht/archive/2.../24/10591.aspx
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ? We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE
|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Production
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off http://msmvps.com/epprecht/archive/2.../24/10591.aspx
> EE does have some performance enhancements over standard (pre-fetch) but the
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
Showing posts with label sps. Show all posts
Showing posts with label sps. Show all posts
Monday, March 26, 2012
Performance Developer vs. Std
We have a series of SPs, poorly written, but that's not the issue here.
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
--
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Production
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
> EE does have some performance enhancements over standard (pre-fetch) but the
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
> > We have a series of SPs, poorly written, but that's not the issue here.
> >
> > Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> > (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> >
> > But we've even tried the local Dasd on the Prod (Std) box.
> >
> > The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> > even everything on a single RAID drive. Prod at least has db and log
> > separate, more at times.
> >
> > We've checked everything, and can't find any differences. Running on Prod
> > Off hours when it's not even breaking a sweat.
> >
> > The proc does nothing special, except a cursor for Update (Ooouugghh).
> >
> > Any ideas what to look at ' We compared everything we can think of, no
> > differences SQL, Win2000... No errors in the event log ..., Query plans
> > match even cost estimates.
> >
> > Could Developer (which is Enterprise, right) provide that much boost vs.
> > Std, even with nothing, that I know of that would be using EE features.
> >
> > Note to date everything I've wrritten, even some larger procs (10 to 20
> > million row processes) seem to run as expected. Slightly faster on Prod.
> >
> >
> >
> > --
> > KlK, MCSEsql
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
--
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Production
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx
> EE does have some performance enhancements over standard (pre-fetch) but the
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
> > We have a series of SPs, poorly written, but that's not the issue here.
> >
> > Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> > (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> >
> > But we've even tried the local Dasd on the Prod (Std) box.
> >
> > The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> > even everything on a single RAID drive. Prod at least has db and log
> > separate, more at times.
> >
> > We've checked everything, and can't find any differences. Running on Prod
> > Off hours when it's not even breaking a sweat.
> >
> > The proc does nothing special, except a cursor for Update (Ooouugghh).
> >
> > Any ideas what to look at ' We compared everything we can think of, no
> > differences SQL, Win2000... No errors in the event log ..., Query plans
> > match even cost estimates.
> >
> > Could Developer (which is Enterprise, right) provide that much boost vs.
> > Std, even with nothing, that I know of that would be using EE features.
> >
> > Note to date everything I've wrritten, even some larger procs (10 to 20
> > million row processes) seem to run as expected. Slightly faster on Prod.
> >
> >
> >
> > --
> > KlK, MCSEsql
Performance Developer vs. Std
We have a series of SPs, poorly written, but that's not the issue here.
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/ur
l]
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Productio
n
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/
url]
> EE does have some performance enhancements over standard (pre-fetch) but t
he
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
>
Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
(Dev), dual P3, 2gig ram. Pretty much just DB servers.
But we've even tried the local Dasd on the Prod (Std) box.
The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
even everything on a single RAID drive. Prod at least has db and log
separate, more at times.
We've checked everything, and can't find any differences. Running on Prod
Off hours when it's not even breaking a sweat.
The proc does nothing special, except a cursor for Update (Ooouugghh).
Any ideas what to look at ' We compared everything we can think of, no
differences SQL, Win2000... No errors in the event log ..., Query plans
match even cost estimates.
Could Developer (which is Enterprise, right) provide that much boost vs.
Std, even with nothing, that I know of that would be using EE features.
Note to date everything I've wrritten, even some larger procs (10 to 20
million row processes) seem to run as expected. Slightly faster on Prod.
KlK, MCSEHi
As a good benchmark, run the SQL IO stress tools on your Dev and Production
server. It will indicate if your SAN is considerably slower than the local
drives.
Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/ur
l]
EE does have some performance enhancements over standard (pre-fetch) but the
Disk might be your issue.
Regards
Mike
"KevinK" wrote:
> We have a series of SPs, poorly written, but that's not the issue here.
> Two machines, hardware identical, except mostly SAN (Prod) vs. Local Dasd
> (Dev), dual P3, 2gig ram. Pretty much just DB servers.
> But we've even tried the local Dasd on the Prod (Std) box.
> The process runs 2 1/2 to 3 hours on Dev, 9 to 10 on Prod. On Dev that's
> even everything on a single RAID drive. Prod at least has db and log
> separate, more at times.
> We've checked everything, and can't find any differences. Running on Prod
> Off hours when it's not even breaking a sweat.
> The proc does nothing special, except a cursor for Update (Ooouugghh).
> Any ideas what to look at ' We compared everything we can think of, no
> differences SQL, Win2000... No errors in the event log ..., Query plans
> match even cost estimates.
> Could Developer (which is Enterprise, right) provide that much boost vs.
> Std, even with nothing, that I know of that would be using EE features.
> Note to date everything I've wrritten, even some larger procs (10 to 20
> million row processes) seem to run as expected. Slightly faster on Prod.
>
> --
> KlK, MCSE|||Thanks Mike, unfortunately we have tested it using only the local drive on
Prod.
We have a 70gig local raid drive that is normally used for Backups etc.
It didn't help.
We do know the SAN drives are slower than locals, but it isn't that
significant, maybe 20% (I think 12 to 15 was the official number.
But when we run it on the SAN we are using multiple drives, log and data.
I am trying to get them to do a DBHammer
"Mike Epprecht (SQL MVP)" wrote:
[vbcol=seagreen]
> Hi
> As a good benchmark, run the SQL IO stress tools on your Dev and Productio
n
> server. It will indicate if your SAN is considerably slower than the local
> drives.
> Look at the links off [url]http://msmvps.com/epprecht/archive/2004/07/24/10591.aspx[/
url]
> EE does have some performance enhancements over standard (pre-fetch) but t
he
> Disk might be your issue.
> Regards
> Mike
> "KevinK" wrote:
>
Friday, March 23, 2012
Performance decline in parallel SPs execution
Hi,
We have a process that builds our data warehouse.
The processes execute SPs in serial order.
Each SP builds separate table.
Each table is build destructive (truncate and Insert Into).
I've tried to change the configuration by running 4 SP in parallel by SSIS to shorten the update time.
I've noticed in two declines in performance:
1. Each SP execution time is higher in the parallel execution in around 50% then in the serial execution. The CPU utilization is the same.
2. On each parallel execution we have a decline in performance of around 5 -10% compare to the previous parallel execution.
Do you have any directions to inquire?
Btw – we have Itanium 64bit x8 with 32GB memory
Thanks,
Assaf
It sounds like the stored procedures may be blocking each other when running in parallel.
You can verify if there is blocking by querying sys.dm_exec_requests and looking at the blocking_session_id column.
If you do see blocking you will want to look at the locks that stored procedure is taking, and determine if there is any way to reduce the locks held.
|||Hi,
Sorry that I forgot mention it.
There is no locks between tables.
each SP right to only single table and Other SP do not read from other written tables.
Also validated it on server level.
Any other ideas?
Thanks,
Assaf
|||If the stored procedures are inserting into tables in the same database then they could be contending for both physical IO on the data device and also be writing to the same log devices. The storage devices are quite often the bottlenecks in systems like this, and regardless of how fast the processors can run the disk can only write at a certain rate.
As for the 10% degredation I'm not so sure. Is the 10% cumulative run on run or are the subsequent run all just 10% faster than the first? What is the recovery model of your database? If it is not Simple then it may be having to extend the logs if they are not being cleared between runs. On a data warehouse which is completely rebuilt and does not then have data written to it you can probably just use Simple recovery and do a full backup after the load if necessary.
Saturday, February 25, 2012
Perfomance Questions
I have a few questions.
First: We have a quad Xeon 500MHz server running SQL2K
and Win2K. All SPs are applied. Sometimes the
performance becomes an issue. My boss wants me to go
through and kill some processes when that happens. Are
there any adverse reactions to that?
Second: We also have a Terminal Server with Win2k3
running. Does anyone know of any performance issues with
this?
Thanks.
DonDon,
If the solution is to kill processes, you need a better solution.
Killing a process naturally affects the user of that process. Depending on
how the client and T-SQL code is written this can range from harmless but
annoying to leaving data in a logically incomplete state. (It will not
physically corrupt the database, but logical corruption is just as
troublesome.)
The thing to do is investigate the processes that are candidates for
killing, figure out what is wrong, and help the developer/user to correct
the problems. (Famous bad query: multi-table cartesian product to get just
a few rows. Done by people who do not understand joining.)
Russell Fields
"Don" <donolwert@.hotmail.com> wrote in message
news:0d3301c35c30$a7ecb780$a401280a@.phx.gbl...
> I have a few questions.
> First: We have a quad Xeon 500MHz server running SQL2K
> and Win2K. All SPs are applied. Sometimes the
> performance becomes an issue. My boss wants me to go
> through and kill some processes when that happens. Are
> there any adverse reactions to that?
> Second: We also have a Terminal Server with Win2k3
> running. Does anyone know of any performance issues with
> this?
> Thanks.
> Don|||One time I puked because a process was killed.. I couldn't stand it.
MS
"chris" <chrisr@.fingps.com> wrote in message
news:057901c35c45$0c1de350$a101280a@.phx.gbl...
> My boss wants me to go
> >through and kill some processes when that happens. Are
> >there any adverse reactions to that?
> Other than users losing the work they were doing, no.
>
> >--Original Message--
> >I have a few questions.
> >
> >First: We have a quad Xeon 500MHz server running SQL2K
> >and Win2K. All SPs are applied. Sometimes the
> >performance becomes an issue. My boss wants me to go
> >through and kill some processes when that happens. Are
> >there any adverse reactions to that?
> >
> >Second: We also have a Terminal Server with Win2k3
> >running. Does anyone know of any performance issues with
> >this?
> >
> >Thanks.
> >Don
> >.
> >|||Russell,
Thanks for the good detailed information.
Don
>--Original Message--
>Don,
>If the solution is to kill processes, you need a better
solution.
>Killing a process naturally affects the user of that
process. Depending on
>how the client and T-SQL code is written this can range
from harmless but
>annoying to leaving data in a logically incomplete
state. (It will not
>physically corrupt the database, but logical corruption
is just as
>troublesome.)
>The thing to do is investigate the processes that are
candidates for
>killing, figure out what is wrong, and help the
developer/user to correct
>the problems. (Famous bad query: multi-table cartesian
product to get just
>a few rows. Done by people who do not understand
joining.)
>Russell Fields
>"Don" <donolwert@.hotmail.com> wrote in message
>news:0d3301c35c30$a7ecb780$a401280a@.phx.gbl...
>> I have a few questions.
>> First: We have a quad Xeon 500MHz server running SQL2K
>> and Win2K. All SPs are applied. Sometimes the
>> performance becomes an issue. My boss wants me to go
>> through and kill some processes when that happens. Are
>> there any adverse reactions to that?
>> Second: We also have a Terminal Server with Win2k3
>> running. Does anyone know of any performance issues
with
>> this?
>> Thanks.
>> Don
>
>.
>
First: We have a quad Xeon 500MHz server running SQL2K
and Win2K. All SPs are applied. Sometimes the
performance becomes an issue. My boss wants me to go
through and kill some processes when that happens. Are
there any adverse reactions to that?
Second: We also have a Terminal Server with Win2k3
running. Does anyone know of any performance issues with
this?
Thanks.
DonDon,
If the solution is to kill processes, you need a better solution.
Killing a process naturally affects the user of that process. Depending on
how the client and T-SQL code is written this can range from harmless but
annoying to leaving data in a logically incomplete state. (It will not
physically corrupt the database, but logical corruption is just as
troublesome.)
The thing to do is investigate the processes that are candidates for
killing, figure out what is wrong, and help the developer/user to correct
the problems. (Famous bad query: multi-table cartesian product to get just
a few rows. Done by people who do not understand joining.)
Russell Fields
"Don" <donolwert@.hotmail.com> wrote in message
news:0d3301c35c30$a7ecb780$a401280a@.phx.gbl...
> I have a few questions.
> First: We have a quad Xeon 500MHz server running SQL2K
> and Win2K. All SPs are applied. Sometimes the
> performance becomes an issue. My boss wants me to go
> through and kill some processes when that happens. Are
> there any adverse reactions to that?
> Second: We also have a Terminal Server with Win2k3
> running. Does anyone know of any performance issues with
> this?
> Thanks.
> Don|||One time I puked because a process was killed.. I couldn't stand it.
MS
"chris" <chrisr@.fingps.com> wrote in message
news:057901c35c45$0c1de350$a101280a@.phx.gbl...
> My boss wants me to go
> >through and kill some processes when that happens. Are
> >there any adverse reactions to that?
> Other than users losing the work they were doing, no.
>
> >--Original Message--
> >I have a few questions.
> >
> >First: We have a quad Xeon 500MHz server running SQL2K
> >and Win2K. All SPs are applied. Sometimes the
> >performance becomes an issue. My boss wants me to go
> >through and kill some processes when that happens. Are
> >there any adverse reactions to that?
> >
> >Second: We also have a Terminal Server with Win2k3
> >running. Does anyone know of any performance issues with
> >this?
> >
> >Thanks.
> >Don
> >.
> >|||Russell,
Thanks for the good detailed information.
Don
>--Original Message--
>Don,
>If the solution is to kill processes, you need a better
solution.
>Killing a process naturally affects the user of that
process. Depending on
>how the client and T-SQL code is written this can range
from harmless but
>annoying to leaving data in a logically incomplete
state. (It will not
>physically corrupt the database, but logical corruption
is just as
>troublesome.)
>The thing to do is investigate the processes that are
candidates for
>killing, figure out what is wrong, and help the
developer/user to correct
>the problems. (Famous bad query: multi-table cartesian
product to get just
>a few rows. Done by people who do not understand
joining.)
>Russell Fields
>"Don" <donolwert@.hotmail.com> wrote in message
>news:0d3301c35c30$a7ecb780$a401280a@.phx.gbl...
>> I have a few questions.
>> First: We have a quad Xeon 500MHz server running SQL2K
>> and Win2K. All SPs are applied. Sometimes the
>> performance becomes an issue. My boss wants me to go
>> through and kill some processes when that happens. Are
>> there any adverse reactions to that?
>> Second: We also have a Terminal Server with Win2k3
>> running. Does anyone know of any performance issues
with
>> this?
>> Thanks.
>> Don
>
>.
>
Subscribe to:
Posts (Atom)