Performance Hits within EM After Upgrading OS to Windows 2003

We have recently upgraded 4 SQL servers to Windows 2003, running SQL Server
2000. Many people are complaining that Enterprise Manager now takes 4-20
seconds to expand the databases on those servers, where before it was either
instant or 1-2 seconds. Once the intial connection has been made, there are
no further performance issues. Do you know if there is a fix, or have others
experienced this slow performance after the upgrade?
We have compared user desktops' memory, processors, hard drives, etc, and
there is no trend there.
We would appreciate any advice before moving forward w/ our other servers'
upgrades!To answer my own question, in case others have experienced this, there was a
database with the "AutoClose" option checked. This was causing the
performance hit in Enterprise Manager after we upgraded to 2003. For
whatever reason, this did not cause problems on a 2000 OS, but definitely
caused issues on 2003 OS.
Resolution, just went into properties for the database and unchecked it.
This increased performance back to its original state. We now have a script
that checks and ensures database properties are set correctly.
Hope this saves someone else out there the headaches we went through trying
to determine the performance issues after upgrading to Windows 2003.
"JaneDoe" wrote:
> We have recently upgraded 4 SQL servers to Windows 2003, running SQL Server
> 2000. Many people are complaining that Enterprise Manager now takes 4-20
> seconds to expand the databases on those servers, where before it was either
> instant or 1-2 seconds. Once the intial connection has been made, there are
> no further performance issues. Do you know if there is a fix, or have others
> experienced this slow performance after the upgrade?
> We have compared user desktops' memory, processors, hard drives, etc, and
> there is no trend there.
> We would appreciate any advice before moving forward w/ our other servers'
> upgrades!

Performance Hits within EM After Upgrading OS to Windows 2003

We have recently upgraded 4 SQL servers to Windows 2003, running SQL Server
2000. Many people are complaining that Enterprise Manager now takes 4-20
seconds to expand the databases on those servers, where before it was either
instant or 1-2 seconds. Once the intial connection has been made, there are
no further performance issues. Do you know if there is a fix, or have other
s
experienced this slow performance after the upgrade?
We have compared user desktops' memory, processors, hard drives, etc, and
there is no trend there.
We would appreciate any advice before moving forward w/ our other servers'
upgrades!To answer my own question, in case others have experienced this, there was a
database with the "AutoClose" option checked. This was causing the
performance hit in Enterprise Manager after we upgraded to 2003. For
whatever reason, this did not cause problems on a 2000 OS, but definitely
caused issues on 2003 OS.
Resolution, just went into properties for the database and unchecked it.
This increased performance back to its original state. We now have a script
that checks and ensures database properties are set correctly.
Hope this saves someone else out there the headaches we went through trying
to determine the performance issues after upgrading to Windows 2003.
"JaneDoe" wrote:

> We have recently upgraded 4 SQL servers to Windows 2003, running SQL Serve
r
> 2000. Many people are complaining that Enterprise Manager now takes 4-20
> seconds to expand the databases on those servers, where before it was eith
er
> instant or 1-2 seconds. Once the intial connection has been made, there a
re
> no further performance issues. Do you know if there is a fix, or have oth
ers
> experienced this slow performance after the upgrade?
> We have compared user desktops' memory, processors, hard drives, etc, and
> there is no trend there.
> We would appreciate any advice before moving forward w/ our other servers'
> upgrades!sql

Performance Hits within EM After Upgrading OS to Windows 2003

We have recently upgraded 4 SQL servers to Windows 2003, running SQL Server
2000. Many people are complaining that Enterprise Manager now takes 4-20
seconds to expand the databases on those servers, where before it was either
instant or 1-2 seconds. Once the intial connection has been made, there are
no further performance issues. Do you know if there is a fix, or have others
experienced this slow performance after the upgrade?
We have compared user desktops' memory, processors, hard drives, etc, and
there is no trend there.
We would appreciate any advice before moving forward w/ our other servers'
upgrades!
To answer my own question, in case others have experienced this, there was a
database with the "AutoClose" option checked. This was causing the
performance hit in Enterprise Manager after we upgraded to 2003. For
whatever reason, this did not cause problems on a 2000 OS, but definitely
caused issues on 2003 OS.
Resolution, just went into properties for the database and unchecked it.
This increased performance back to its original state. We now have a script
that checks and ensures database properties are set correctly.
Hope this saves someone else out there the headaches we went through trying
to determine the performance issues after upgrading to Windows 2003.
"JaneDoe" wrote:

> We have recently upgraded 4 SQL servers to Windows 2003, running SQL Server
> 2000. Many people are complaining that Enterprise Manager now takes 4-20
> seconds to expand the databases on those servers, where before it was either
> instant or 1-2 seconds. Once the intial connection has been made, there are
> no further performance issues. Do you know if there is a fix, or have others
> experienced this slow performance after the upgrade?
> We have compared user desktops' memory, processors, hard drives, etc, and
> there is no trend there.
> We would appreciate any advice before moving forward w/ our other servers'
> upgrades!

Performance dropped after upgraded to MS SQL 2000

Dear all,
Last Saturday, I upgraded my SQL 7.0 database to SQL 2000 Standard Edition
succesfully.
I also executed "sp_updatestats" and reindexed all the databases, but I
found the server's overall performance is worse than before.
That means SQL 2000 is slower than SQL 7.0, why ?
Possibly you have bad luck with some queries for which SQL Server picks less good execution plans in
2000 compared to 7.0. You need to work those queries and see why. One plausible reason is below:
WHERE col = value
If col and value (or parameter or variable) aren't of the same datatype, then 7.0 would convert the
non-column side toe the column datatype. 2000 converts more correctly, according to datatype
precedence documentation in Books Online. This can case your queries be effectively the same as:
WHERE CAST(col AS dt) = value
And since the column side isn't alone (it is wrapped in a function), typically index on that column
cannot be used.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"John" <cpjohn@.netvigator.com> wrote in message news:d7cem9$b4i20@.imsp212.netvigator.com...
> Dear all,
> Last Saturday, I upgraded my SQL 7.0 database to SQL 2000 Standard Edition
> succesfully.
> I also executed "sp_updatestats" and reindexed all the databases, but I
> found the server's overall performance is worse than before.
> That means SQL 2000 is slower than SQL 7.0, why ?
>
>
|||Thanks a lot.
I will try it.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:O5p6mi0ZFHA.3784@.TK2MSFTNGP12.phx.gbl...
> Possibly you have bad luck with some queries for which SQL Server picks
less good execution plans in
> 2000 compared to 7.0. You need to work those queries and see why. One
plausible reason is below:
> WHERE col = value
> If col and value (or parameter or variable) aren't of the same datatype,
then 7.0 would convert the
> non-column side toe the column datatype. 2000 converts more correctly,
according to datatype
> precedence documentation in Books Online. This can case your queries be
effectively the same as:
> WHERE CAST(col AS dt) = value
> And since the column side isn't alone (it is wrapped in a function),
typically index on that column
> cannot be used.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "John" <cpjohn@.netvigator.com> wrote in message
news:d7cem9$b4i20@.imsp212.netvigator.com...[vbcol=seagreen]
Edition
>

Performance dropped after upgraded to MS SQL 2000

Dear all,
Last Saturday, I upgraded my SQL 7.0 database to SQL 2000 Standard Edition
succesfully.
I also executed "sp_updatestats" and reindexed all the databases, but I
found the server's overall performance is worse than before.
That means SQL 2000 is slower than SQL 7.0, why ?Possibly you have bad luck with some queries for which SQL Server picks less
good execution plans in
2000 compared to 7.0. You need to work those queries and see why. One plausi
ble reason is below:
WHERE col = value
If col and value (or parameter or variable) aren't of the same datatype, the
n 7.0 would convert the
non-column side toe the column datatype. 2000 converts more correctly, accor
ding to datatype
precedence documentation in Books Online. This can case your queries be effe
ctively the same as:
WHERE CAST(col AS dt) = value
And since the column side isn't alone (it is wrapped in a function), typical
ly index on that column
cannot be used.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"John" <cpjohn@.netvigator.com> wrote in message news:d7cem9$b4i20@.imsp212.netvigator.com...[
vbcol=seagreen]
> Dear all,
> Last Saturday, I upgraded my SQL 7.0 database to SQL 2000 Standard Edition
> succesfully.
> I also executed "sp_updatestats" and reindexed all the databases, but I
> found the server's overall performance is worse than before.
> That means SQL 2000 is slower than SQL 7.0, why ?
>
>[/vbcol]|||Thanks a lot.
I will try it.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:O5p6mi0ZFHA.3784@.TK2MSFTNGP12.phx.gbl...
> Possibly you have bad luck with some queries for which SQL Server picks
less good execution plans in
> 2000 compared to 7.0. You need to work those queries and see why. One
plausible reason is below:
> WHERE col = value
> If col and value (or parameter or variable) aren't of the same datatype,
then 7.0 would convert the
> non-column side toe the column datatype. 2000 converts more correctly,
according to datatype
> precedence documentation in Books Online. This can case your queries be
effectively the same as:
> WHERE CAST(col AS dt) = value
> And since the column side isn't alone (it is wrapped in a function),
typically index on that column
> cannot be used.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "John" <cpjohn@.netvigator.com> wrote in message
news:d7cem9$b4i20@.imsp212.netvigator.com...
Edition[vbcol=seagreen]
>

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
>

Performance decrease after OS upgrade

We were running a 4 processor server with 8 GB RAM and 800GB hard disk
space on Windows 2000 server and SQL Server 2000.
Recently we have upgraded the server to 8 processor and added another
800GB. The OS was upgradded to Windows 2003 enterprise edition.
All the processor are 2.5GHz Xeon preocessors.

After upgradation the performance of the server has gone down from what
it was giving before the upgrade.

It seems that multiprocessing is not ocurring.

The model of the server is HP DL740

The OS is installed in a built in array(5i controller) of the server
and the SQL server is installed in a external array(6400 controller).

I will really aprecite if anyone can give any clue to improve the
performance.

Thanks in advance.

Taw.Really need more details... One thought, when you added the 800 GB of
disk space -- I assumed you added a new array? How was it configured?
i.e. Was the existing array named drive E and then the new array named
drive F? Or did you span it into one giant 1.6T array?|||Before the upgrade the OS(Windows200) and the SQLServer was both in the
external array. OS was in one logical drive (C:) and Sqlserver in
another logical drive (D:). The built in array was not used.

For upgrading the system we have added 2X36.4 GB harddisk in the built
in array and clean installed the OS(Windows 2003). Now there is one
1.6TB (14X146 GB) external array,RAID 5. The external array is the
logical drive D: and the OS(RAID1) is the logical drive C:|||Taw,

From the limited information provided, your biggest performance hit here is
the use of RAID 5. RAID1 is much faster, especially for the transaction
log. If we assume that the configuration is generally the same just more
processors and more spindles, I would look into pulling back your max degree
of parallelism.

Also is SQL completely installed on the external array? The default install
is to the C: drive and this may be where tempdb is located.

<tawfiq.choudhury@.grameenphone.com> wrote in message
news:1108442363.222496.139900@.g14g2000cwa.googlegr oups.com...
> Before the upgrade the OS(Windows200) and the SQLServer was both in the
> external array. OS was in one logical drive (C:) and Sqlserver in
> another logical drive (D:). The built in array was not used.
> For upgrading the system we have added 2X36.4 GB harddisk in the built
> in array and clean installed the OS(Windows 2003). Now there is one
> 1.6TB (14X146 GB) external array,RAID 5. The external array is the
> logical drive D: and the OS(RAID1) is the logical drive C:|||My only guess is that you have a "HP Modular Smart Array 30". I
remember buried somewhere in it's documentation, the optimal number of
disks per logical drive is 8. But the array is top-of-the-line and
having 14 disks in one logical drive shouldn't impact it that much.
You can try playing with the Parallellism Query Plan Threshold setting.
Otherwise, sorry, I have no other ideas.|||Yes SQL is installed completely in the external array.