2
Frage zur Performanz fragmentierter MS SQL 2000 Datenbanken im Hauptspeicher
Hallo Zusammen,
wir planen gerade ein SQL Server Hardware Update und haben 2 Datenbanken á 20GB auf einem Windows 2003 Server mit MS SQL 2000 Enterprise. Die DB macht täglich viele Änderungen mit, was sich auch auf die Fragmentierung der Indizes auswirkt.
Problemstellung:
Wir haben auf dem neuen System 8 Kerne,Samsung 830 SSDs und 64GB schnellen DDR3 Ram zur Verfügung. Die beiden DBs nehmen insgesamt ~40 GB vom RAM in Anspruch wenn sie komplett hineingeladen werden. Soweit so gut.
Die DBs wurden bisher mit ddbc shrinkdatabase nach dem ddbc dbreindex der Tabellen von 35GB auf 20GB geschrumpft,aus Mangel an Platz auf dem Server bisher. (Wir wissen, dass das Shrinken das Reindexieren quasi zu nichte macht.)
Die Datenbanken haben je 35GB nach dem DBREINDEX und passen somit nicht mehr in den RAM von max 64GB.
Das die DBs komplett im RAM liegen können war eines unserer Primärziele.
Nun ist die Frage die wir uns stellen:
Ist es Performanztechnisch optimaler die DBs nicht mehr zu shrinken und die logische Fragmentierung der Indizes damit auf 0% zu bekommen? Was dann aber zur Folge hätte,dass die DBs nicht mehr in den RAM passen und wir mehr Disk I/Os haben.
oder
Ist es besser die DBs weiterhin mit DBREINDEX und folgendem shrink komplett in den RAM zu bekommen, um so die schnellen RAM Zugriffszeiten auszureizen. (Die log. Fragmentierung der Tabellen nach dem shrink beträgt immer über 60%.)
Ich lese mich gerade in die Speicher- und Dateiverwaltung vom SQL Server ein, wäre aber über jeden kompetenten Ratschlag, Hinweis oder Literaturverweis dankbar!
lg
Alikz
Wir haben auf dem neuen System 8 Kerne,Samsung 830 SSDs und 64GB schnellen DDR3 Ram zur Verfügung. Die beiden DBs nehmen insgesamt ~40 GB vom RAM in Anspruch wenn sie komplett hineingeladen werden. Soweit so gut.
Die DBs wurden bisher mit ddbc shrinkdatabase nach dem ddbc dbreindex der Tabellen von 35GB auf 20GB geschrumpft,aus Mangel an Platz auf dem Server bisher. (Wir wissen, dass das Shrinken das Reindexieren quasi zu nichte macht.)
Die Datenbanken haben je 35GB nach dem DBREINDEX und passen somit nicht mehr in den RAM von max 64GB.
Das die DBs komplett im RAM liegen können war eines unserer Primärziele.
Nun ist die Frage die wir uns stellen:
Ist es Performanztechnisch optimaler die DBs nicht mehr zu shrinken und die logische Fragmentierung der Indizes damit auf 0% zu bekommen? Was dann aber zur Folge hätte,dass die DBs nicht mehr in den RAM passen und wir mehr Disk I/Os haben.
oder
Ist es besser die DBs weiterhin mit DBREINDEX und folgendem shrink komplett in den RAM zu bekommen, um so die schnellen RAM Zugriffszeiten auszureizen. (Die log. Fragmentierung der Tabellen nach dem shrink beträgt immer über 60%.)
Ich lese mich gerade in die Speicher- und Dateiverwaltung vom SQL Server ein, wäre aber über jeden kompetenten Ratschlag, Hinweis oder Literaturverweis dankbar!
lg
Alikz
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 185991
Url: https://administrator.de/contentid/185991
Printed on: April 20, 2024 at 15:04 o'clock
2 Comments
Latest comment
Ich würde empfehlen nicht so billige SSD's zu nehmen und über ein Upgrade auf zumindest SQL 2005 nachzudenken. Das die DBs komplett im RAM sein müssen versteh ich nicht. Wenn das aber eingehalten werden soll, müsst ihr deutlich mehr Geld ausgeben. Bei Server 2003 R2 x64 geht das super, das Limit von dem ist 1TB (bzw 32GB bei 'standard').
Hol lieber ein RAID 1+0 oder 5+0 mit einem Controller der 1GB Puffer hat und darunter dann gute SAS-Platten. Hardware-Interrupts wegen Disk-IO ist schon fast das übelste, aber das "shrink" und Gebastel zieht die CPU runter und andere Fehlerquellen an und zwingt Dich dazu die Hardware anzupassen sobald die DB wieder etwas größer ist.
Hol lieber ein RAID 1+0 oder 5+0 mit einem Controller der 1GB Puffer hat und darunter dann gute SAS-Platten. Hardware-Interrupts wegen Disk-IO ist schon fast das übelste, aber das "shrink" und Gebastel zieht die CPU runter und andere Fehlerquellen an und zwingt Dich dazu die Hardware anzupassen sobald die DB wieder etwas größer ist.
Hi,
danke für deine Antwort.
Ein Upgrade auf SQL 2005 kommt nicht in Frage und der OS Wechsel ebensowenig(interne Entscheidung).
Die Samsung SSDs sind ausreichend und haben sehr gute Latenzzeiten+Datendurchsatzraten.
Im Raid1 macht man damit nichts verkehrt.
Wenn die DBs komplett im RAM liegen sind die Queryzeiten und Cachetreffer unübertroffen hoch (so die Theorie).
Wir haben das Problem aber mittlerweile gelöst.
DBBC INDEXDEFRAG defragementiert die Tabellenindizes ohne zusätzlichen Speicherplatz zu verbrauche, ergo die DB Datei wächst nicht unnötige 10 GB an und kann somit (hoffentlich effekktiv) im Speicher verweilen.
lg
aliks
danke für deine Antwort.
Ein Upgrade auf SQL 2005 kommt nicht in Frage und der OS Wechsel ebensowenig(interne Entscheidung).
Die Samsung SSDs sind ausreichend und haben sehr gute Latenzzeiten+Datendurchsatzraten.
Im Raid1 macht man damit nichts verkehrt.
Wenn die DBs komplett im RAM liegen sind die Queryzeiten und Cachetreffer unübertroffen hoch (so die Theorie).
Wir haben das Problem aber mittlerweile gelöst.
DBBC INDEXDEFRAG defragementiert die Tabellenindizes ohne zusätzlichen Speicherplatz zu verbrauche, ergo die DB Datei wächst nicht unnötige 10 GB an und kann somit (hoffentlich effekktiv) im Speicher verweilen.
lg
aliks
