Showing posts with label std. Show all posts
Showing posts with label std. Show all posts

Wednesday, March 28, 2012

Performance difference between Std & Enterprise Editions

Our main server is a Compaq Quad 700Mhz server with 4GB RAM and one instance
of SQLServer that was standard edition. We upgraded the SQLServer to
Enterprise edition and set the max memory to 3584MB. Performance is worse
now. Is this coincidental or should we expect it? Is there some other
setting that we need to do?
BTW, we implemented log shipping and found that the msdb DB did not contain
the tables and stored procedures we needed. Apparently the upgrade from Std
to Enterprise edition did not upgrade the msdb DB. We backed up an msdb DB
on another Enterprise SQLServer system and restored it on our main server.
The resored msdb DB has the tables and stored procedures we needed and we
were able to fire up the log shipping. Is this situation normal?
Picine Karppehd
Look at the topics "UPDATE STATISTICS" and "Reading Pages" in Books Online.
The former will show you how to update the statistics on your database,
which may not be optimal after the upgrade. The latter describes "advanced
scan," a type of read-ahead I/O which Ent uses but Std doesn't, and may
account for some of the differences.
Might also see http://support.microsoft.com/?kbid=243589
http://www.aspfaq.com/
(Reverse address to reply.)
"Picine Karppehd" <PicineKarppehd@.hotmail.com.(donotspam)> wrote in message
news:E1126808-7BF5-4802-A4FD-DACE5E8965A9@.microsoft.com...
> Our main server is a Compaq Quad 700Mhz server with 4GB RAM and one
instance
> of SQLServer that was standard edition. We upgraded the SQLServer to
> Enterprise edition and set the max memory to 3584MB. Performance is worse
> now. Is this coincidental or should we expect it? Is there some other
> setting that we need to do?
> BTW, we implemented log shipping and found that the msdb DB did not
contain
> the tables and stored procedures we needed. Apparently the upgrade from
Std
> to Enterprise edition did not upgrade the msdb DB. We backed up an msdb
DB
> on another Enterprise SQLServer system and restored it on our main server.
> The resored msdb DB has the tables and stored procedures we needed and we
> were able to fire up the log shipping. Is this situation normal?
> --
> Picine Karppehd
>

Performance difference between Std & Enterprise Editions

Our main server is a Compaq Quad 700Mhz server with 4GB RAM and one instance
of SQLServer that was standard edition. We upgraded the SQLServer to
Enterprise edition and set the max memory to 3584MB. Performance is worse
now. Is this coincidental or should we expect it? Is there some other
setting that we need to do?
BTW, we implemented log shipping and found that the msdb DB did not contain
the tables and stored procedures we needed. Apparently the upgrade from Std
to Enterprise edition did not upgrade the msdb DB. We backed up an msdb DB
on another Enterprise SQLServer system and restored it on our main server.
The resored msdb DB has the tables and stored procedures we needed and we
were able to fire up the log shipping. Is this situation normal?
Picine KarppehdLook at the topics "UPDATE STATISTICS" and "Reading Pages" in Books Online.
The former will show you how to update the statistics on your database,
which may not be optimal after the upgrade. The latter describes "advanced
scan," a type of read-ahead I/O which Ent uses but Std doesn't, and may
account for some of the differences.
Might also see http://support.microsoft.com/?kbid=243589
http://www.aspfaq.com/
(Reverse address to reply.)
"Picine Karppehd" <PicineKarppehd@.hotmail.com.(donotspam)> wrote in message
news:E1126808-7BF5-4802-A4FD-DACE5E8965A9@.microsoft.com...
> Our main server is a Compaq Quad 700Mhz server with 4GB RAM and one
instance
> of SQLServer that was standard edition. We upgraded the SQLServer to
> Enterprise edition and set the max memory to 3584MB. Performance is worse
> now. Is this coincidental or should we expect it? Is there some other
> setting that we need to do?
> BTW, we implemented log shipping and found that the msdb DB did not
contain
> the tables and stored procedures we needed. Apparently the upgrade from
Std
> to Enterprise edition did not upgrade the msdb DB. We backed up an msdb
DB
> on another Enterprise SQLServer system and restored it on our main server.
> The resored msdb DB has the tables and stored procedures we needed and we
> were able to fire up the log shipping. Is this situation normal?
> --
> Picine Karppehd
>

Performance difference between Std & Enterprise Editions

Our main server is a Compaq Quad 700Mhz server with 4GB RAM and one instance
of SQLServer that was standard edition. We upgraded the SQLServer to
Enterprise edition and set the max memory to 3584MB. Performance is worse
now. Is this coincidental or should we expect it? Is there some other
setting that we need to do?
BTW, we implemented log shipping and found that the msdb DB did not contain
the tables and stored procedures we needed. Apparently the upgrade from Std
to Enterprise edition did not upgrade the msdb DB. We backed up an msdb DB
on another Enterprise SQLServer system and restored it on our main server.
The resored msdb DB has the tables and stored procedures we needed and we
were able to fire up the log shipping. Is this situation normal?
--
Picine KarppehdLook at the topics "UPDATE STATISTICS" and "Reading Pages" in Books Online.
The former will show you how to update the statistics on your database,
which may not be optimal after the upgrade. The latter describes "advanced
scan," a type of read-ahead I/O which Ent uses but Std doesn't, and may
account for some of the differences.
Might also see http://support.microsoft.com/?kbid=243589
--
http://www.aspfaq.com/
(Reverse address to reply.)
"Picine Karppehd" <PicineKarppehd@.hotmail.com.(donotspam)> wrote in message
news:E1126808-7BF5-4802-A4FD-DACE5E8965A9@.microsoft.com...
> Our main server is a Compaq Quad 700Mhz server with 4GB RAM and one
instance
> of SQLServer that was standard edition. We upgraded the SQLServer to
> Enterprise edition and set the max memory to 3584MB. Performance is worse
> now. Is this coincidental or should we expect it? Is there some other
> setting that we need to do?
> BTW, we implemented log shipping and found that the msdb DB did not
contain
> the tables and stored procedures we needed. Apparently the upgrade from
Std
> to Enterprise edition did not upgrade the msdb DB. We backed up an msdb
DB
> on another Enterprise SQLServer system and restored it on our main server.
> The resored msdb DB has the tables and stored procedures we needed and we
> were able to fire up the log shipping. Is this situation normal?
> --
> Picine Karppehd
>

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, 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:

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

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:
>

Monday, March 12, 2012

Performance affecting users only

Hi,
I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
experience slowness in accessing the database but users with elevated access
such as domain admins never experience such slowness when everybody else is
sufferring.
Please help i am going insane.
Thanks
Pablo
Are the two groups connecting using different networks?
"pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
> Hi,
> I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
> experience slowness in accessing the database but users with elevated
> access
> such as domain admins never experience such slowness when everybody else
> is
> sufferring.
> Please help i am going insane.
> Thanks
> Pablo
|||No Jay, they are on the same network and even sometimes I ask them to login
into the same computer.
I must also add that when slowness happens and I reboot the SQL server
everything normalizes again.
Thanks
Pablo
"Jay" wrote:

> Are the two groups connecting using different networks?
> "pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
> news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
>
>
|||Hi Pablo
Ive got a similar situation.
SP calls from IIS (logged in to sql server with a certain sql server login)
time outs while same call with same parameters (captured from profiler) run
from Query Analyzer (logged in with another account, higher permission level)
have normal response times.
After restart of the sql server service boot situations (IIS and QA) works
fine.
Did you find out anymore on this?
Any other who can direct me regarding this?
SQL Server 2000, IIS 6. Memory, CPU etc looks fine.
Thanks!
/Tore
"pfrank61" wrote:
[vbcol=seagreen]
> No Jay, they are on the same network and even sometimes I ask them to login
> into the same computer.
> I must also add that when slowness happens and I reboot the SQL server
> everything normalizes again.
> Thanks
> Pablo
> "Jay" wrote:
|||Hi Tore,
My situation hasn't change and I am still rebooting the server evertime it
happens.\
Hello Guys we can't be the only guys experiencing this, Please help us out
with suggestions.
Thanks
Paul
"Tore" wrote:
[vbcol=seagreen]
> Hi Pablo
> Ive got a similar situation.
> SP calls from IIS (logged in to sql server with a certain sql server login)
> time outs while same call with same parameters (captured from profiler) run
> from Query Analyzer (logged in with another account, higher permission level)
> have normal response times.
> After restart of the sql server service boot situations (IIS and QA) works
> fine.
> Did you find out anymore on this?
> Any other who can direct me regarding this?
> SQL Server 2000, IIS 6. Memory, CPU etc looks fine.
> Thanks!
> /Tore
>
> "pfrank61" wrote:

Performance affecting users only

Hi,
I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
experience slowness in accessing the database but users with elevated access
such as domain admins never experience such slowness when everybody else is
sufferring.
Please help i am going insane.
Thanks
PabloAre the two groups connecting using different networks?
"pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
> Hi,
> I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
> experience slowness in accessing the database but users with elevated
> access
> such as domain admins never experience such slowness when everybody else
> is
> sufferring.
> Please help i am going insane.
> Thanks
> Pablo|||No Jay, they are on the same network and even sometimes I ask them to login
into the same computer.
I must also add that when slowness happens and I reboot the SQL server
everything normalizes again.
Thanks
Pablo
"Jay" wrote:

> Are the two groups connecting using different networks?
> "pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
> news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
>
>|||Hi Pablo
Ive got a similar situation.
SP calls from IIS (logged in to sql server with a certain sql server login)
time outs while same call with same parameters (captured from profiler) run
from Query Analyzer (logged in with another account, higher permission level
)
have normal response times.
After restart of the sql server service boot situations (IIS and QA) works
fine.
Did you find out anymore on this?
Any other who can direct me regarding this?
SQL Server 2000, IIS 6. Memory, CPU etc looks fine.
Thanks!
/Tore
"pfrank61" wrote:
[vbcol=seagreen]
> No Jay, they are on the same network and even sometimes I ask them to logi
n
> into the same computer.
> I must also add that when slowness happens and I reboot the SQL server
> everything normalizes again.
> Thanks
> Pablo
> "Jay" wrote:
>|||Hi Tore,
My situation hasn't change and I am still rebooting the server evertime it
happens.\
Hello Guys we can't be the only guys experiencing this, Please help us out
with suggestions.
Thanks
Paul
"Tore" wrote:
[vbcol=seagreen]
> Hi Pablo
> Ive got a similar situation.
> SP calls from IIS (logged in to sql server with a certain sql server login
)
> time outs while same call with same parameters (captured from profiler) ru
n
> from Query Analyzer (logged in with another account, higher permission lev
el)
> have normal response times.
> After restart of the sql server service boot situations (IIS and QA) works
> fine.
> Did you find out anymore on this?
> Any other who can direct me regarding this?
> SQL Server 2000, IIS 6. Memory, CPU etc looks fine.
> Thanks!
> /Tore
>
> "pfrank61" wrote:
>

Performance affecting users only

Hi,
I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
experience slowness in accessing the database but users with elevated access
such as domain admins never experience such slowness when everybody else is
sufferring.
Please help i am going insane.
Thanks
PabloAre the two groups connecting using different networks?
"pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
> Hi,
> I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
> experience slowness in accessing the database but users with elevated
> access
> such as domain admins never experience such slowness when everybody else
> is
> sufferring.
> Please help i am going insane.
> Thanks
> Pablo|||No Jay, they are on the same network and even sometimes I ask them to login
into the same computer.
I must also add that when slowness happens and I reboot the SQL server
everything normalizes again.
Thanks
Pablo
"Jay" wrote:
> Are the two groups connecting using different networks?
> "pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
> news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
> > Hi,
> > I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
> > experience slowness in accessing the database but users with elevated
> > access
> > such as domain admins never experience such slowness when everybody else
> > is
> > sufferring.
> >
> > Please help i am going insane.
> >
> > Thanks
> > Pablo
>
>|||Hi Pablo
Ive got a similar situation.
SP calls from IIS (logged in to sql server with a certain sql server login)
time outs while same call with same parameters (captured from profiler) run
from Query Analyzer (logged in with another account, higher permission level)
have normal response times.
After restart of the sql server service boot situations (IIS and QA) works
fine.
Did you find out anymore on this?
Any other who can direct me regarding this?
SQL Server 2000, IIS 6. Memory, CPU etc looks fine.
Thanks!
/Tore
"pfrank61" wrote:
> No Jay, they are on the same network and even sometimes I ask them to login
> into the same computer.
> I must also add that when slowness happens and I reboot the SQL server
> everything normalizes again.
> Thanks
> Pablo
> "Jay" wrote:
> > Are the two groups connecting using different networks?
> >
> > "pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
> > news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
> > > Hi,
> > > I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
> > > experience slowness in accessing the database but users with elevated
> > > access
> > > such as domain admins never experience such slowness when everybody else
> > > is
> > > sufferring.
> > >
> > > Please help i am going insane.
> > >
> > > Thanks
> > > Pablo
> >
> >
> >|||Hi Tore,
My situation hasn't change and I am still rebooting the server evertime it
happens.\
Hello Guys we can't be the only guys experiencing this, Please help us out
with suggestions.
Thanks
Paul
"Tore" wrote:
> Hi Pablo
> Ive got a similar situation.
> SP calls from IIS (logged in to sql server with a certain sql server login)
> time outs while same call with same parameters (captured from profiler) run
> from Query Analyzer (logged in with another account, higher permission level)
> have normal response times.
> After restart of the sql server service boot situations (IIS and QA) works
> fine.
> Did you find out anymore on this?
> Any other who can direct me regarding this?
> SQL Server 2000, IIS 6. Memory, CPU etc looks fine.
> Thanks!
> /Tore
>
> "pfrank61" wrote:
> > No Jay, they are on the same network and even sometimes I ask them to login
> > into the same computer.
> > I must also add that when slowness happens and I reboot the SQL server
> > everything normalizes again.
> >
> > Thanks
> > Pablo
> >
> > "Jay" wrote:
> >
> > > Are the two groups connecting using different networks?
> > >
> > > "pfrank61" <pfrank61@.discussions.microsoft.com> wrote in message
> > > news:FAF8FA18-A4E9-42CC-8FA5-4EC4FD77B08B@.microsoft.com...
> > > > Hi,
> > > > I have mssql 2000 std sp4 running on w2k3 std sp2. intermittently users
> > > > experience slowness in accessing the database but users with elevated
> > > > access
> > > > such as domain admins never experience such slowness when everybody else
> > > > is
> > > > sufferring.
> > > >
> > > > Please help i am going insane.
> > > >
> > > > Thanks
> > > > Pablo
> > >
> > >
> > >