Momentan muss ich für einen Kunden einen ausfallsicheren performanten Micrsoft SQL-Server zusammenstellen, aufbauen und dann auch später administrieren. Alleine die Hardware-Planung hat eine Menge Nerven und Zeit gekostet, so tief wollte ich in die Materie gar nicht einsteigen aber wenn man alles richtig machen will muss man manchmal auch tiefer gehen.

Der Kunde hat momentan zwei alte Windows Server 2003 x86 auf denen Datenbanken laufen, durch das ständige Wachsen ist das bestehende System langsam an seine Grenzen gekommen. Bzgl. Micrsoft SQL-Server gibt es eine Menge “Best-Practice-Witepaper” für sowas, ich haben (unfreiwillig) einige davon gelesen um das Thema besser zu verstehen.
Mit einem Partner von mir wollte ich das zusammen machen dieser schwört auf die SAN’s von NetApp, also dachte ich mir ok probieren wir es bevor wir das Zeug gleich kaufen. NetApp war so net mir eine FAS2020 eine Woche zum testen zu überlassen. Ich habe mit IOMeter (Test’s liefen nur 60 Sekunden mit den selben Einstellungen) die maximale Performance der Geräte gemessen und war über das Ergebniss überrascht, aber seht selbst:

Wie Ihr seht schmeichelt dies der NetApp FAS2020 nicht wirklich! Ich habe auch öfter mit einem NetApp-Techniker telefoniert aber keiner konnte sich erklären warum die Werte so gering waren. Lt. einer Aussage eines Vertrieblers sollte diese 13.000 IOPs schaffen, er wollte mir aber nicht sagen wie diese Werte geschafft worden sind bzw. konnte es nicht.

Kürzlich habe ich mit einem Bekannten gesprochen der setzt nur HP ein und hat mir das ganze mal etwas näher gebracht und vorgerechnet, wenn man davon ausgeht das eine 15k 3,5″ SAS 300GB alleine 200 IOPs schafft und diese mal 12 nimmt kommt man auf eine Wert von 2400 IOPs dann muss man noch etwas vom Raid usw. abziehen dann hast dann den wirklichen Wert. Mehr Platten (Spindeln) mehr Power ganz einfach. Er zeigt mir ein Merkblatt einer HP-SAN die schaffte ca. 19.000 IOPs aber nur mit 96 SAS Platten im Backround!

Diese Werte sind auch ohne Gewähr und ich übernehme dafür keine Garantie. Könnte auch an einer falschen Konfiguration liegen, aber das ist bis jetzt nicht geklärt.

Hier ist auch noch ein Link zu einer VMWare Communitie die sich mit dem Thema auch beschäftigt und jeder seine Ergebnisse postet:
VMware Communitie

Würde mich freuen, wenn ihr euere Werte hiermal postet evtl. vielleicht sogar von eurer FAS 2020.

Also für das ist die FAS2020 von NetApp für mich nicht die richtige SAN um den Kunden und auch mich zufrieden zu stellen.

Heute habe ich was schönes gefunden und zwar wie mache ich ein Backup von allen Datenbanken wenn Microsoft SQL 2005 Express Edition verwendet wird.
Beim normalen SQL 2000, 2005 oder 2008 gibt es ja die schönen Verwaltungspläne oder im Englischen “Maintenance Plans”. Da es die aber leider nicht gibt in der Express Edition musste man sich selber helfen.

Auf folgender Website habe ich dazu eine schöne Anleitung gefunden und diese auch gleich umgesetzt, diese funktioniert einwandfrei.

Hier der Link.

Scho wieder mal ein leidiges Thema welches immer und immer wieder in Foren oder sonstiges diskutiert wird. Unter anderem habe ich auch einige SQL-Srv zu betreuen darunter MSSQL und MySQL und ganz ehrlich gesagt ist mir persönlich der MySQL-Srv lieber da er schöner zu administrieren und verwalten ist wie der von Microsoft, aber ich ganz mir nicht aussuchen!

Folgendes Problem hatte ich ein Windows Server 2003 Enterprise x64 mit SQL-Srv-2005 Enterprise Edition eine Datenbank mit einer Größe von ca. 8 GB. Alles nicht so spektakulär. Bei den Routine-Arbeiten auf den Servern viel mir auf fast kein Speicher mehr auf dem Laufwerk wo die DB-Logs liegen, mal kurz reingekuckt und siehe da ein Log das 63 GB groß war und die DB war gerade mal 8 GB groß. Ja, wo gibt’s denn sowas! Mit der üblichen Vorgehensweise liesse sich das Log nicht verkleinern!
Bei den Kollegen nachgefragt ob die irgendwelche Sachen machen die das Log so ansteigen lassen und ob noch irgendwelche Vorgänge geöffnet sind, nein natürlich kein Erfolg so und weiter im Geschehen. Nach längerem durchsuchen des INet mit der Hilfe von… natürlich eh klar “Mr. Google” fand ich in einem Forum einen Hinweis und zwar auf Probleme mit Replikation zwischen SQL-Servern und großen Logs die sich nicht verkleinern lassen.
Darauf hin das gleich mal gecheckt und im Hinterkopf hatte ich noch so einen Gedanken da war mal was mit Replikation einrichten für diese DB. Das Problem war dann das der Server zwar die DB richtig repliziert hat, aber es Probleme gab bei dem Setzen für die Markierungen wo und was er repliziert wurde und auch noch im zusammenspiel mit einem SQL-Server-2000. Laut Microsoft hat der SQL-Srv-2000 einen Bug bezüglich Replikation und das dadurch das Log so groß werden kann. Leider weiß ich den Link zu dem Bug-Report nicht mehr, in dem haben sie zwei Wege beschrieben entweder die Replikation über DTS-Paket erledigen oder mit dem Befehl “sp_repldone”.

Wie jetzt in unserem Fall ist das auch genau eingetreten der Quell-Server ist MSSQL-2005 und der Ziel-Server ist MSSQL-2000.

Hier die Lösung mit der ich das DB-Log dann doch noch erfolgreich verkleinern konnte:

1. Diesen Befehl auf die DB ausgeführt:
   Use DATABASE
   GO
   
   EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,     @time = 0, @reset = 1
   GO
   
   Quelle: http://msdn.microsoft.com/de-de/library/ms173775.aspx

2. Dann den Befehl zum verkleinern des Logs:
   Use DATABASE
   GO
   BACKUP LOG DATABASE with WITH TRUNCATE_ONLY
   GO
   DBCC SHRINKFILE(DATABASE_Log, 10)
   GO

Dann war das Log wieder richtig schön klein.

Wie immer alles auf eigene Gefahr.