Database Problems after Moving to other Server
-
I/O ? Disks,..
How about the filesizes for the databases, are they the same, do they extend the same.
Has the new db been allocate at least the same size as the current old db ?
After the load you should dbcc dbreindex all loaded objects !
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data and code to get the best help- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
-
Database filesize is the same on both system, they extend in the same way.
I think dbcc dbreindex can't be the way for me, because of the follwoing situation:
I create a couple of empty temp tables, fill them with data from an external import process. After finishing the import, i drop the live tables and replace them with the temp tables. This is what i do on both systems, dev and test, so i think dbreindex won't bring much performance.
-
... Hardware is nearly the same ...
- What are the HW differences ? (ram, disk,..)
- how about filefragmentation (disk level) ?
- If you just create empty objects and load with data, then a dbreindex will not do any good because there are no indexes to be optimized and a heap is just a pile of pages....
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data and code to get the best help- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
-
Ok, I'll give you an overview of the hardware currently used...
Dev System:
- Windows Server 2003 Standard Edition
- SP 1
- 1.5 Gb RAM
- 3.00 GHz DualCore
- 100 MBit Network
Test System:
- Windows 2003 Standard Edition
- SP 1
- 2.0 Gb RAM
- 3.2 GHz DualCore
- 100 MBit Network
On both systems i've running SQL Server 2000 in the following version:
- SQL Server Developer Edition
- Version 8.00.2039 (SP4)
No fragmentation of Databasefile/Log in dev system and test system. Overall Fragmentation is on both system 80%. After running defragmentation, the time for import data in the "slow" test system is as it was before
Do you need any other informations from me?
-
So far, so good
how about disksubsystems ?
number of disks ?
type of disks ?
cache ?
rpm ?
write performance ? (ms)
Johan
Learn to play, play to learn !Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:- How to post Performance Problems
- How to post data and code to get the best help- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
-
"fast" dev system:
- single disk, contains only sql databases
- Seagate ST3808110AS Barracuda 80 GB
- 7200 RPM
- 8,5 ms
- S-ATA II
- 8 MB Cache
"slow" test system:
- contains only sql databases
- SATA Raid1, 2 disks
- same as above
May the raid be the reason for the decreasing performance? As it looks, this seems to be the only big difference between the two systems.
-
Is that software or hard raid?
Only time I have seen that radical difference in performance between two very similar systems someone had turned on software compression on the slow system in the OS...
-
It's a hardware raid, no software is used...
-
Have you compared the write cache options on both servers?
Use Device Manger, Disk Drives, select a disk, right click ==> properties and then select the "Disk Properties" tab. Is "write caching enabled" on ?
Note that you MUST disable "write caching enabled" or your database may become corrupt and not recoverable.
See "Using hard disk controller caching with SQL Server" at http://support.microsoft.com/kb/46091/
Once you disable write caching on ATA or SATA drives, you will see thruput drop by a factor of between 10 to 50.
Time to get some SCSI disks.
SQL = Scarcely Qualifies as a Language
-
Writing cache is enabled on the "fast" developer system, so it is on the "slow" system. I'll check if there is an performance increase when disabling write cache on the raid of the "slow" system...
thx so long for our answers...
-
Have you compared query plans on something that performs differently?
-
I found checking the query plans that the INSERT's seem to cause the trouble.
On "fast" devsystem, i've 0-1 duration and 0-1 reads
On "slow" testsystem, 've about 16-20 duration and ~20 reads
So it looks as if the INSERT takes much more time to complete an the testsystem. But i cant find a bottleneck anywhere.
-
Does your table has indexes ? If yes, drop them. After the table is loaded, then create the indexes.
-
as well as indexes, make sure your stats are up to date on the slow server.
-
The inserts sound strange. Does the query plan give you an idea on where the reads are occurring? Are there perhaps triggers or extra keys on the slow system?
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply