Herausfinden, wann eine Partition/ein Datenträger unter Windows hinzugefügt wurde

[Blase 15]

Hallo,

 

ich bräuchte mal bitte eine verlässliche Aussage zu folgendem Sachverhalt.

 

Kurzer Hintergrund:

 

Ich habe auf einem virtualisiertem (glaube das läuft unter VM Ware) Server 2012 R2 ein SQL Server 2014 installiert. Da es nur die Partition C:\ gab habe ich halt in den Standard Pfaden installiert - ist ja kein Thema.

 

Nun sehe ich mich mit der Frage konfrontiert, warum ich nicht auf der eigens hierfür erstellten Partition D: installiert habe. Es gab zum Zeitpunkt meiner Installation keine Partition D: Der IT Betreuer behauptet das aber.

 

Lange Rede kurzer Sinn - an welcher Stelle kann ich unter Windows selbst auslesen, wann die Partition D: erstmalig hinzugefügt worden ist? Ich weiß nicht, was er da gemacht hat und ich will auch gar nicht unterstellen, dass er hier dreist lügt, aber zum Zeitpunkt meiner Installation (insgesamt über 2 Tage für verschiedene Dinge) gab es diese Partition nicht. Nun ist sie natürlich da, aber von wann ist sie tatsächlich...?!

 

Danke!

 

MfG Björn

[Sunny61 810]

Losgelöst von der Diskussion um LW D:\, es fehlt IMHO noch das LW T:\ für die TempDB(s), und ein LW L:\ für die Logdateien. Auch ist bei beiden Laufwerken auf Details bei der Formatierung zu achten. Auch die weiterführenden Links können interessant sein:

http://serverfault.com/questions/175034/64k-cluster-size-for-sql-server-log-files

[Blase 15]

Wenn ich mal tippen sollte, würde ich sagen, dass ohnehin alles auf dem selben Storage mit dem selben EINEN RAID Level liegt. Wo wäre also der Nutzen bezüglich dedizierterer Partitionierung und Auslagerung der einzelnen Datenbanken/Logs...? Dachte das spielt nur ne Rolle, wenn man wirklich verschiedene Festplattensysteme/RAID Level für die verschiedenen Aufgabenbereiche einrichtet. Wird hier aber sicherlich nicht passiert sein. Werde da trotzdem mal nachhaken...

[blub 115]

bei mir finde ich im SystemLog das Event 98

"Volume \\?\Volume{347da9e0-a97c-11e5-80ea-000c29c55446} (\Device\HarddiskVolume2) is healthy.  No action is needed."

samt "Date and Time"

Das Event wird offenbar nach erfolgreicher Formatierung erzeugt. Wenn du nicht selbst formatiert hast, ...

[Blase 15]

Ok, das behalte ich mal im Hinterkopf. Wenn das Log nicht regelmäßig gelöscht wird, müsste man es zumindest über einen gewissen Zeitraum hin finden können.

 

Danke Dir!

 

Sonstige Möglichkeiten / Vorschläge?

[blub 115]

mit einer solchen Antwort hatte ich nicht gerechnet :confused:

[NilsK 2.969]

Moin,

 

mal ganz abgesehen von der direkt gestellten Frage dieses Threads würde ich mal eine andere in den Raum werfen: Warum sollte man überhaupt die Programminstallation des SQL Servers auf einem anderen als dem Systemlaufwerk machen? Da geht es nur um eine überschaubare Datenmenge, die auch nicht wesentlich anwächst. Relevant sind die Datenbanken und die Logs, und die kann man unabhängig vom Speicherort der Binaries an beliebigen Orten anlegen und prinzipiell auch nachträglich verschieben.

 

Aus meiner Erfahrung sorgen separate Volumes für installierte Binaries in den meisten Fällen eher für Ärger als dass sie was nützen. Insofern könnte man den Ball sehr einfach zurückspielen.

 

Gruß, Nils

[Sunny61 810]

Wenn ich mal tippen sollte, würde ich sagen, dass ohnehin alles auf dem selben Storage mit dem selben EINEN RAID Level liegt. Wo wäre also der Nutzen bezüglich dedizierterer Partitionierung und Auslagerung der einzelnen Datenbanken/Logs...? Dachte das spielt nur ne Rolle, wenn man wirklich verschiedene Festplattensysteme/RAID Level für die verschiedenen Aufgabenbereiche einrichtet. Wird hier aber sicherlich nicht passiert sein. Werde da trotzdem mal nachhaken...

Auf einem SQL Server Workshop im Frühjahr wurde insbesonders die Blockgröße bei der Formatierung hervorgehoben und auch die unterschiedlichen Laufwerke. Details sollte ein SQL Server Spezi hier besser aussagen und rüber bringen können.

 

Aber evtl. kann man in diesem Fall ja noch extra Festplatten auf anderen Storages nutzen. Dein Kunde meinte aber vermutlich die Ablage der Daten, nicht die Programmdateien des SQL Servers.

[NilsK 2.969]

Moin,

 

natürlich kann man bei einem SQL Server schon einiges beim Storage "optimieren". Die Frage ist aber immer, ob das auch nötig ist - und das hängt immer von der konkreten Nutzung ab.

 

Bei vielen SQL Servern ist es überhaupt kein Problem, alle Daten auf einem Volume ohne weitere Besonderheiten abzulegen. Bei anderen lohnt es sich, Tage oder Wochen in Design und Testing zu investieren und auch kleine Stellschrauben wie die Blockgröße, den Plattentyp für Log- und Datenbank-Dateien (vielleicht sogar noch nach Datenbanknutzung unterschieden) oder die Fragmentierung zu beachten. Eine Konfiguration die "pauschal gut" oder "richtig" ist, gibt es nicht.

 

Gruß, Nils

[NorbertFe 2.098]

Naja es gibt aber einige Standardfehler, die man auch pauschal lösen kann. ;) ich tendiere aber genau wie du dazu, erstmal dem Auftraggeber die Frage zu stellen, wo denn das Problem sei.

 

Bye

Norbert

[XP-Fan 220]

Hallo,

 

an welcher Stelle kann ich unter Windows selbst auslesen, wann die Partition D: erstmalig hinzugefügt worden ist?

 

wenn das Volume über Windows erstellt wurde, wird mit dem Datum ein Verzeichnis "System Volume Information" auf dem Datenträger erstellt.

Nun ist es noch eine Einstellung der Ansicht im Windows Explorer mit welcher du das Erstellungsdatum siehst.

Geschützte Systemdateien dürfen nicht ausgeblendet sein, Ansicht auf Details stellen und in der Kopfzeile (Name, Änderungsdatum, Typ, Größe)

mittels Rechtsklick das Erstellungsdatum anzeigen lassen.

[Blase 15]

mit einer solchen Antwort hatte ich nicht gerechnet :confused:

 

Ähm, habe ich was falsches gesagt?! :shock: Ich weiß lediglich nicht, wann ich die nächste Gelegenheit bekommen werde, auf das betroffene System zu schauen und ich kenne eben Dienstleister, die hier regelmäßig die Protokolle "warten", sprich sichten und anschließend löschen...

 

@Nils - ich habe mich hier wohl schlicht unglücklich ausgedrückt. Natürlich soll das Programm des SQL Servers in den Standard Pfaden installiert werden/sein, aber das Daten- bzw. Instanzverzeichnis nicht. Dieser soll auf das D: Laufwerk. Ich könnte einfach auf Dateiebene Pfade auf D: anlegen und meine Datenbank dort hin verschieben, aber der "Standard" Datenpfad des SQL Servers ändert sich dadurch ja nicht. Der SQL Server würde in dieser Konstellation immer in seinem Standard Datenbanken anlegen und sichern wollen - und der Standard wäre ja immer C:\... Kann man diesen so einfach (!) ändern?

 

@XP-Fan - auch wenn das ein virtueller Server ist, wird das Volume ja letztlich über die Datenträgerverwaltung des virtuellen Servers hinzugefügt - müsste also passen. Habe das grade mal an meinem Notebook getestet - hätte vom Gefühl her gesagt, dass das älter sein müsste, kann mich aber irren.

 

Habe noch was gefunden:

 

Eigenschaften des Datenträgers => Reiter "Hardware" => HDD auswählen und "Eigenschaften" starten => Reiter "Details" und als Eigenschaft "Datum der Erstinstallation" auswählen.

 

Ist identisch mit dem Wert des Erstellungsdatums "System Volume Information" :D

 

Super - danke euch! Wüsche allen Beteiligten eine ruhige Woche.

 

MfG Björn

[Dukel 457]

Der SQL Server würde in dieser Konstellation immer in seinem Standard Datenbanken anlegen und sichern wollen - und der Standard wäre ja immer C:\... Kann man diesen so einfach (!) ändern?

 

Natürlich kann man diesen einfach ändern. Schau mal in die Eigenschaften der SQL Instanz im SQL Management Studio.

[NilsK 2.969]

Moin,

 

natürlich kann man den Standardpfad für neue Datenbanken ändern. Man sollte sich bei der Gelegenheit aber auch gleich angewöhnen, Datenbanken auf einem Produktionssystem niemals per Weiter-Weiter-Fertigstellen einzurichten. Es hat schon seinen Sinn, dass man für jede einzelne Datenbank die Speicheroptionen angeben kann.

 

Zur Not kriegt man sowas für einzelne Datenbanken auch nachträglich geändert, aber das kann schon einigen Aufwand und auch Downtime erzeugen.

 

Gruß, Nils