SQL Server Installation - Verzeichnis für TempDB, LOG und DB-Data
Hallo, es ist Freitag und ich stehe mal wieder vor einer Fragestellung.
Ich möchte einen MS SQL Server installieren und habe dafür einen Server neben mir stehen.
Der Server bietet dedizierte Festplatten für: SQL-Application(Install Folder), TempDB, LOG und DB-Data.
Habe gerade den Installations-Dialog vor der Nase, bei dem ich die Verzeichnisse wählen kann.
Da ich noch nicht viel Erfahrung mit der Installation von SQL Server habe, bitte ich euch um eine kleine Hilfestellung bei der Wahl der richtigen Verzeichnisse.
Ich sehe folgende Tabs:
Server Configuration (Erledigt ! )
Data Directories->
Data root directory
System database directory
User Database directory
User Database log directory
Backup directory
TempDB->
Data directories
Log directory
Offensichtlich ist mein Vorhaben in diesen beiden Tabs festzulegen.
Es soll die eigentliche Datenbank auf eine eigene Platte.
TempDB auf eine eigene Platte und LOG bekommt auch eine eigene Platte.
Wo wähle ich nun die richtigen Verzeichnisse??
Ich möchte einen MS SQL Server installieren und habe dafür einen Server neben mir stehen.
Der Server bietet dedizierte Festplatten für: SQL-Application(Install Folder), TempDB, LOG und DB-Data.
Habe gerade den Installations-Dialog vor der Nase, bei dem ich die Verzeichnisse wählen kann.
Da ich noch nicht viel Erfahrung mit der Installation von SQL Server habe, bitte ich euch um eine kleine Hilfestellung bei der Wahl der richtigen Verzeichnisse.
Ich sehe folgende Tabs:
Server Configuration (Erledigt ! )
Data Directories->
Data root directory
System database directory
User Database directory
User Database log directory
Backup directory
TempDB->
Data directories
Log directory
Offensichtlich ist mein Vorhaben in diesen beiden Tabs festzulegen.
Es soll die eigentliche Datenbank auf eine eigene Platte.
TempDB auf eine eigene Platte und LOG bekommt auch eine eigene Platte.
Wo wähle ich nun die richtigen Verzeichnisse??
Please also mark the comments that contributed to the solution of the article
Content-ID: 41582424099
Url: https://administrator.de/contentid/41582424099
Printed on: September 1, 2024 at 08:09 o'clock
8 Comments
Latest comment
Moin,
folgende Annahme:
C:\ ist das Systemlaufwerk
D:\ die Disk für die Daten mdbs
E:\ für die LogFiles
F:\ für Backups
WIR handhaben das so:
System-, Temp- und Data-MDB liegen im selben Verzeichnis:
LogFile unter
Backup:
und die ganzen Funktionsdateien liegen dann im Standardverzeichnis unter
folgende Annahme:
C:\ ist das Systemlaufwerk
D:\ die Disk für die Daten mdbs
E:\ für die LogFiles
F:\ für Backups
WIR handhaben das so:
System-, Temp- und Data-MDB liegen im selben Verzeichnis:
D:\Database\{Funktion}.{Instanzname}\
LogFile unter
E:\Database\{Funktion}.{Instanzname}\
Backup:
F:\Database\{Funktion}.{Instanzname}\
und die ganzen Funktionsdateien liegen dann im Standardverzeichnis unter
C:\Program Files\Microsoft SQL Server
bzw. C:\Program Files (x86)\Microsoft SQL Server
User Database directory
User Database log directory
User Database log directory
Denke das sie sind die werte die du einpassen kannst.
Dann einfach testweise eine neue Datenbank erstellen und schauen obs richtig vorgeblendet wird bei der zu erstellenden datenbank.
Wenn nicht , dann wieder so zurücksetzen wie es war (dann lag ich halt falsch).
Aber im Prinzip kann man das auch jedesmal manuell beim erstellen einer Datenbank richtig einstellen...
Moin,
Für Backup solltest du zumindest eine eigene Partition festlegen =4
Data Directories->
System database directory ->3
User Database directory ->3
User Database log directory ->2
Backup directory ->4
TempDB->
Data directories =1
Log directory =1
lg,
Slainte
[...] dedizierte Festplatten für: [...] TempDB, =1 LOG =2 und DB-Data. =3 [...]
Für Backup solltest du zumindest eine eigene Partition festlegen =4
Data Directories->
System database directory ->3
User Database directory ->3
User Database log directory ->2
Backup directory ->4
TempDB->
Data directories =1
Log directory =1
lg,
Slainte
noch ne kleine Frage an SQLSpezis hier.
das ganze mit den verschiedenen Paritionen... kommt das nicht von damals als alles noch auf Physikalischen Servern lief.
weil heute lauft das ja meist virtuell und alle Partitionen laufen auf dem selben storage und meist gleichen LUN.
Ergo macht das überhaupt noch irgend einen Sinn das so zu trennen ausser das es schön aufgedröselt ist?
Nur mal so die Frage in den Raum![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
das ganze mit den verschiedenen Paritionen... kommt das nicht von damals als alles noch auf Physikalischen Servern lief.
weil heute lauft das ja meist virtuell und alle Partitionen laufen auf dem selben storage und meist gleichen LUN.
Ergo macht das überhaupt noch irgend einen Sinn das so zu trennen ausser das es schön aufgedröselt ist?
Nur mal so die Frage in den Raum
Moin,
es ist nach wie vor BP (VMware und Microsoft) die Partitionen auf dedizierte VDMKs bzw. Controllers zu legen. In der Regel bei einer 10, 50, 100, 250 GB Datenbank mit relativ wenigen Operationen merkst du vermutlich nichts. Aber bei großen Instanzen (mehrere TB - 5, 10, 50) macht es deutlich was aus. Hier hast du neben Themen wie Backup & Restore, auch das Storage mit seinem Speicher (SSD, NVMe, Caching) sowie Funktionen (Dedup, Compression, etc.) sowie das Dateisystem im Hinterkopf zu behalten.
Es ist bei Performance Problemen bei VMware und Microsoft auch immer der erste Ansatz...![face-smile face-smile](/images/icons/fa/light/face-smile.svg)
Gruß,
Dani
es ist nach wie vor BP (VMware und Microsoft) die Partitionen auf dedizierte VDMKs bzw. Controllers zu legen. In der Regel bei einer 10, 50, 100, 250 GB Datenbank mit relativ wenigen Operationen merkst du vermutlich nichts. Aber bei großen Instanzen (mehrere TB - 5, 10, 50) macht es deutlich was aus. Hier hast du neben Themen wie Backup & Restore, auch das Storage mit seinem Speicher (SSD, NVMe, Caching) sowie Funktionen (Dedup, Compression, etc.) sowie das Dateisystem im Hinterkopf zu behalten.
Es ist bei Performance Problemen bei VMware und Microsoft auch immer der erste Ansatz...
Gruß,
Dani