Wenn man eine SQL-Server-Datenbank auf einem Festplattensystem mit einer Sektor-Größe von 512 Bytes, das ist die derzeit übliche Größe, angelegt hat, dann kann man diese Datenbanken nicht einfach dateiweise auf eine Festplatte mit einer anderen Sektorgröße verschieben und dann dort erneut anhängen.<\/p>\n
Disclaimer: Ich meine hier nicht die "logische" Cluster-Size<\/a>, die beim Formatieren der Laufwerke angegeben wird, sondern die physische Sector-Size<\/a>, die vom Hersteller festgelegt wird.<\/p>\n Bisher hatten Festplatten eigentlich immer eine Sektor-Größe von 512 Bytes. Aber das wird sich bald ändern, weil bestimmte Größen damit nicht mehr machbar sind. Angekündigt sind die neuen Festplatten von der IDEMA ja schon lange<\/a>. Aber heute las ich erstmals<\/a> von Festplatten, die nun tatsächlich mit der neuen Sektor-Größe von 4096 Bytes produziert werden. Bisher hatte man nur mit SAN und manchen NAS die Möglichkeit eine andere Sektor-Größe zu konfigurieren.<\/p>\n Wo ist nun das Problem? <\/p>\n In den Dateien der SQL-Server-Datenbank ist festgehalten mit welcher Sektor-Größe die Datenbank angelegt wurde. Verschiebt man die Dateien auf eine Festplatte mit der Sektor-Größe 4096, dann weiter sich der SQL-Server die Datenbank anzuhängen. Fällt also beispielsweise die Festplatte aus und dann führt auf einer Neuen (mit abweichender Sektor-Größe) eine Rücksicherung durch, dann kann man die Datenbanken nicht mehr in Betrieb nehmen. Es gibt laut Microsoft keine Möglichkeit die Daten da wieder herauszuholen.<\/p>\n Das gilt leider auch, wenn man eine Sicherung mittels BACKUP anlegte, weil der RESTORE die Seiten genauso wiederherstellt. Daher hat die so wiederhergestellte Datenbank wieder eine Sektorgröße von 512 Bytes. Microsoft empfiehlt von irgendwoher eine alte Platte zu besorgen, die Datenbank dort anzuhängen, eine neue Datenbank auf der neuen Platte (leer) anzulegen und die Daten dann von der alten in die neue zu kopieren. Die Datenbanken erhalten den Stempel beim Anlegen und behalten ihn auf Lebenszeit. Die Sektor-Size wird dabei von der des Festplattensystem bestimmt. Das ist leider nicht konfigurierbar.<\/p>\n Der umgekehrte Fall ist hingegen unproblematisch: Wurde eine Datenbank auf einer Festplatte mit 4K Sektor-Größe angelegt, dann kann sie einfach auf Festplatten mit 512Bytes betrieben werden. Microsoft kennt das Problem<\/a> und hat daher schon beim SQL Server 2005 die Systemdatenbanken mit der Sektor-Größe 4096 Bytes angelegt.<\/p>\n Warum muss der der SQL Server diese Infos speichern? Ich fand bisher nur konkrete Hinweise darauf, dass das Transaktionslog sektorweise geschrieben wird. Die Datenseiten werden immer gemeinsam behandelt, hier wäre das daher vermutlich nicht nötig, aber ich fand noch keinen Weg das zu umgehen. Das leigt aber vermutlich auch daran, dass ich noch kein Festplattensystem mit 4096 Bytes habe. Details zum Hintergrund finden sich im Artikel "Microsoft SQL Server I\/O subsystem requirements for the tempdb database<\/a>".<\/p>\n Zu dem Thema gäbe es noch viel zu sagen, falls Interesse besteht bitte einen Kommentar reinstellen… <\/p>\n","protected":false},"excerpt":{"rendered":" Wenn man eine SQL-Server-Datenbank auf einem Festplattensystem mit einer Sektor-Größe von 512 Bytes, das ist die derzeit übliche Größe, angelegt hat, dann kann man diese Datenbanken nicht einfach dateiweise auf eine Festplatte mit einer anderen Sektorgröße verschieben und dann dort erneut anhängen. Disclaimer: Ich meine hier nicht die "logische" Cluster-Size, die beim Formatieren der Laufwerke […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[41,16],"tags":[651,650],"_links":{"self":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/3988"}],"collection":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/comments?post=3988"}],"version-history":[{"count":4,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/3988\/revisions"}],"predecessor-version":[{"id":3992,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/posts\/3988\/revisions\/3992"}],"wp:attachment":[{"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/media?parent=3988"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/categories?post=3988"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.glorf.it\/blog\/wp-json\/wp\/v2\/tags?post=3988"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}